Add.

1 files changed, 1176 insertions, 0 deletions

diff --git a/doc/protocol/draft-housley-evidence-extns-01.txt b/doc/protocol/draft-housley-evidence-extns-01.txt
new file mode 100644
index 0000000000..639dd0b481
--- /dev/null
+++ b/doc/protocol/draft-housley-evidence-extns-01.txt
@@ -0,0 +1,1176 @@
+
+
+
+
+Internet-Draft                                                  M. Brown
+November 2006                                          RedPhone Security
+Expires: May 2007                                             R. Housley
+                                                          Vigil Security
+
+
+           Transport Layer Security (TLS) Evidence Extensions
+                 <draft-housley-evidence-extns-01.txt>
+
+
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).  All Rights Reserved.
+
+Abstract
+
+   This document specifies evidence creation extensions to the Transport
+   Layer Security (TLS) Protocol.  Extension types are carried in the
+   client and server hello message extensions to confirm that both
+   parties support the protocol features needed to perform evidence
+   creation.  The syntax and semantics of the evidence creation alerts
+   and messages are described in detail.
+
+
+
+
+
+Brown & Housley                                                 [Page 1]
+
+Internet-Draft                                             November 2006
+
+
+1. Introduction
+
+   Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1] is being
+   used in an increasing variety of operational environments, including
+   ones that were not envisioned when the original design criteria for
+   TLS were determined.  The extensions specified in this document
+   support evidence creation in environments where the peers in the TLS
+   session cooperate to create persistent evidence of the TLS-protected
+   application data.  Such evidence may be necessary to meet business
+   requirements, including regulatory requirements.  Also, evidence may
+   be used in tandem with authorization information to make high
+   assurance access control and routing decisions in military and
+   government environments.  Evidence created using this extension may
+   also be used to audit various aspects of the TLS handshake, including
+   the cipher suite negotiation and the use of other TLS extensions.  In
+   many cases, the evidence does not need to be validated by third
+   parties; however, in other cases, the evidence might be validated by
+   third parties.  To accommodate all of these situations, the evidence
+   is generated using a digital signature.  Since validation of a
+   digital signature requires only public information, evidence
+   generated with this mechanism is suitable for sharing with third
+   parties.
+
+   When digital certificates are to be employed in evidence creations,
+   the client must obtain the public key certificate (PKC) for the
+   server, and the server must obtain the PKC for the client.  This is
+   most easily accomplished by using the PKCs provided in the Handshake
+   Protocol Certificate messages.  Further, both parties SHOULD have an
+   opportunity to validate the PKC that will be used by the other party
+   before evidence creation.  Again, this is naturally accomplished
+   using the Handshake Protocol, where the TLS session can be rejected
+   if the PKC cannot be validated.
+
+   This document describes evidence creation TLS extensions supporting
+   both TLS 1.0 and TLS 1.1.  These extensions observe the conventions
+   defined for TLS Extensions [TLSEXT].  The extensions are designed to
+   be backwards compatible, meaning that the protocol alerts and
+   messages associated with the evidence creation extensions will be
+   exchanged only if the client indicates support for them in the client
+   hello message and the server indicates support for them in the server
+   hello message.
+
+   Clients typically know the context of the TLS session before it is
+   established.  As a result, the client can request the use of the
+   evidence creation extensions in sessions where they might be needed.
+   Servers accept extended client hello messages, even if the server
+   does not support the all of the listed extensions.  However, the
+   server will not indicate support for any extensions that are not
+
+
+
+Brown & Housley                                                 [Page 2]
+
+Internet-Draft                                             November 2006
+
+
+   "understood" by the implementation.  At the end of the hello message
+   exchange, the client may reject communications with servers that do
+   not support the evidence creation extensions, or the client may
+   accept the situation and proceed, whichever is appropriate.
+
+1.1. Conventions
+
+   The syntax for the evidence creation messages is defined using the
+   TLS Presentation Language, which is specified in Section 4 of
+   [TLS1.0].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [STDWORDS].
+
+1.2. Overview
+
+   Figure 1 illustrates the placement of the evidence creation alerts
+   and messages in the TLS session.  The first pair of evidence creation
+   alerts indicates the beginning of the protected content that will be
+   covered by the evidence.  The first pair of alerts can appear any
+   place after the TLS Handshake Protocol Finished messages, which
+   ensures that they are integrity protected.  The second pair of
+   evidence creation alerts indicates the ending of the protected
+   content that will be covered by the evidence.  Immediately after the
+   reception of the final alert, a pair of Evidence Protocol messages is
+   exchanged to create the persistent evidence.
+
+   Generating evidence is not compatible with Diffie-Hellman Ephemeral
+   (DHE) key exchanges.  DHE does not permit the same keying material to
+   be generated for validation of the evidence after the TLS session is
+   over.  Persistent evidence requires the use of a digital signature so
+   that it can be validated well after the TLS session is over.
+
+   The ClientHello message includes an indication that the evidence
+   creation messages are supported.  The ServerHello message also
+   includes an indication that the evidence creation messages are
+   supported.  Both the client and the server MUST indicate support for
+   the evidence protocol alerts and messages; otherwise they MUST NOT be
+   employed by either the client or the server.
+
+
+
+
+
+
+
+
+
+
+
+Brown & Housley                                                 [Page 3]
+
+Internet-Draft                                             November 2006
+
+
+      Client                                                 Server
+
+      ClientHello               -------->
+                                                        ServerHello
+                                                       Certificate+
+                                                 ServerKeyExchange*
+                                                CertificateRequest+
+                                <--------           ServerHelloDone
+      Certificate+
+      ClientKeyExchange
+      CertificateVerify+
+      ChangeCipherSpec
+      Finished                  -------->
+                                                   ChangeCipherSpec
+                                <--------                  Finished
+      Application Data          <------->          Application Data
+      Alert(evidence_start1)    -------->
+                                                   Application Data
+                                <--------    Alert(evidence_start2)
+
+      Application Data          <------->          Application Data
+      Alert(evidence_end1)      -------->
+                                                   Application Data
+                                <--------      Alert(evidence_end2)
+      EvidenceRequest           -------->
+                                <--------          EvidenceResponse
+      Application Data          <------->          Application Data
+
+       *  Indicates optional or situation-dependent messages that
+          are not always sent.
+       +  Indicates messages optional to the TLS handshake that
+          MUST be sent when using TLS evidence.
+
+
+           Figure 1. Example TLS Session with Evidence Creation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brown & Housley                                                 [Page 4]
+
+Internet-Draft                                             November 2006
+
+
+2. Evidence Extension Types
+
+   The general extension mechanisms enable clients and servers to
+   negotiate whether to use specific extensions, and how to use specific
+   extensions.  As specified in [TLSEXT], the extension format used in
+   the extended client hello message and extended server hello message
+   within the TLS Handshake Protocol is:
+
+      struct {
+         ExtensionType extension_type;
+         opaque extension_data<0..2^16-1>;
+      } Extension;
+
+   The extension_type identifies a particular extension type, and the
+   extension_data contains information specific to the particular
+   extension type.
+
+   As specified in [TLSEXT], for all extension types, the extension type
+   MUST NOT appear in the extended server hello message unless the same
+   extension type appeared in the preceding client hello message.
+   Clients MUST abort the handshake if they receive an extension type in
+   the extended server hello message that they did not request in the
+   preceding extended client hello message.
+
+   When multiple extensions of different types are present in the
+   extended client hello message or the extended server hello message,
+   the extensions can appear in any order, but there MUST NOT be more
+   than one extension of the same type.
+
+   This document specifies the use of the evidence_creation extension
+   type.  This specification adds one new type to ExtensionType:
+
+      enum {
+         evidence_creation(TBD), (65535)
+      } ExtensionType;
+
+   The evidence_creation extension is relevant when a session is
+   initiated and also for any subsequent session resumption.  However, a
+   client that requests resumption of a session does not know whether
+   the server has maintained all of the context necessary to accept this
+   request, and therefore the client SHOULD send an extended client
+   hello message that includes the evidence_creation extension type.
+   This indicates that the client requests the server's continued
+   cooperation in creating evidence.  If the server denies the
+   resumption request, then the evidence_creation extension will be
+   negotiated normally using the full Handshake protocol.
+
+   Clients MUST include the evidence_creation extension in the extended
+
+
+
+Brown & Housley                                                 [Page 5]
+
+Internet-Draft                                             November 2006
+
+
+   client hello message to indicate their desire to send and receive
+   evidence creation alerts and messages.  The extension_data field
+   indicates the evidence creation algorithms that are supported.  The
+   format is indicated with the EvidenceCreateList type:
+
+      uint16 EvidenceCreateSuite[2];
+
+      struct {
+         EvidenceCreateSuite evidence_suites<2..2^16-1>;
+      } EvidenceCreateList;
+
+   The EvidenceCreateList enumerates the evidence creation algorithms
+   that are supported by the client.  The client MUST order the entries
+   from most preferred to least preferred, but all of the entries MUST
+   be acceptable to the client.  Values are defined in Appendix A, and
+   others can be registered in the future.
+
+   Servers that receive an extended client hello message containing the
+   evidence_creation extension MUST respond with the evidence_creation
+   extension in the extended server hello message if the server is
+   willing to send and receive evidence creation alerts and messages.
+   The evidence_creation extension MUST be omitted from the extended
+   server hello message if the server is unwilling to send and receive
+   using one of the evidence creation algorithm suites identified by the
+   client.  The extension_data field indicates the evidence creation
+   algorithm suite that the server selected from the list provided by
+   the client.  The format is indicated with the EvidenceCreateSuite
+   type defined above.
+
+3. Alert Messages
+
+   This document specifies the use of four new alert message
+   descriptions: the evidence_start1, evidence_start2, evidence_end1,
+   and evidence_end2.  These descriptions are specified in Sections 3.1,
+   3.2, 3.3, and 3.4, respectively.  The alert descriptions are
+   presented below in the order they MUST be sent; sending alerts in an
+   unexpected order results in a fatal error.  These descriptions are
+   always used with the warning alert level.  This specification adds
+   four new types to AlertDescription:
+
+      enum {
+         evidence_start1(TBD),
+         evidence_start2(TBD),
+         evidence_end1(TBD),
+         evidence_end2(TBD),
+         evidence_failure(TBD),
+         (255)
+      } AlertDescription;
+
+
+
+Brown & Housley                                                 [Page 6]
+
+Internet-Draft                                             November 2006
+
+
+3.1. The evidence_start1 Description
+
+   The client and the server need to synchronize evidence creation.
+   Either party may indicate the desire to start creating evidence by
+   sending the evidence_start1 alert.  If the other party is ready to
+   begin creating evidence, then the other party MUST send an
+   evidence_start2 alert in response to the evidence_start1 alert that
+   was sent.  If the other party is unwilling to begin creating
+   evidence, the other party MUST respond with fatal
+   evidence_failure(TBD) alert and terminate the TLS session.
+
+   Evidence may be collected more than once during a TLS session;
+   however, evidence gathering MUST NOT be nested.  That is, a party
+   sending the a second evidence_start1 alert before evidence_end2 alert
+   has occurred and the evidence protocol has completed is a protocol
+   violation.  Reception of an evidence_start1 alert that would result
+   in evidence nesting MUST be responded to with a fatal
+   evidence_failure(TBD) alert and terminating the TLS session.
+
+   Digital signatures are used in evidence creation.  If an
+   evidence_start1 alert is received before the other party has provided
+   a valid PKC, then the evidence_start1 alert recipient MUST terminate
+   the TLS session using a fatal certificate_unknown alert.
+
+3.2. The evidence_start2 Description
+
+   The evidence_start2 alert is sent in response to the evidence_start1
+   alert.  By sending the evidence_start2 alert, the sending party
+   indicates that they are also ready to begin creating evidence.  After
+   this pair of alerts is exchanged, both the client and the server use
+   the hash function indicated in the extended server hello message to
+   start computing the evidence.  Each party computes two independent
+   hash values: one for each octet that is written, and one for each
+   octet that is read.
+
+   Digital signatures are used in evidence creation.  If an
+   evidence_start2 alert is received before the other party has provided
+   a valid PKC, then the evidence_start2 alert recipient MUST terminate
+   the TLS session using a fatal certificate_unknown alert.
+
+3.3. The evidence_end1 Description
+
+   Either party may initiate the closure of an evidence-creating
+   interval and the exchange of evidence messages by sending the
+   evidence_end1 alert.  Upon sending evidence_end1, the sender MUST not
+   send any more application data on this connection until the Evidence
+   Protocol messages are exchanged.
+
+
+
+
+Brown & Housley                                                 [Page 7]
+
+Internet-Draft                                             November 2006
+
+
+   The evidence_end1 alert sender MAY initiate the Evidence Protocol as
+   described in Section 4 at any time following this alert.  The
+   evidence_end1 alert sender SHOULD ensure that it has received all
+   pending application data writes from the other party before
+   initiating the Evidence Protocol.  One way to ensure that all of the
+   application data has been received it to wait for the receipt of an
+   evidence_end2 alert.  If the Evidence Protocol begins before all of
+   the application data is available, the result will be a fatal
+   evidence_failure(TBD) alert when signature verification fails.
+
+3.4. The evidence_end2 Description
+
+   The evidence_end2 alert is sent in response to the evidence_end1
+   alert.  The evidence_end1 alert receiver SHOULD complete any pending
+   writes.  The intent is to include any application data that would be
+   sent in response to application data that was received before the
+   evidence_end1 alert as part of evidence creation.  Once the pending
+   writes are complete, the evidence_end1 alert receiver sends the
+   evidence_end2 alert.
+
+   At this point, each party completes the hash value computations.
+
+   The evidence_end2 alert receiver MUST respond by initiating the
+   Evidence Protocol as described in Section 4, if it has not already
+   done so.
+
+3.5. The evidence_failure Description
+
+   The evidence_failure fatal alert is sent to indicate a failure in
+   evidence creation.  During evidence synchronization, this alert
+   indicates that the sending party is unwilling to begin evidence
+   creation.  During the Evidence Protocol, this alert indicates that
+   the evidence provided by the other party is not acceptable or cannot
+   be validated.
+
+4. Evidence Protocol
+
+   This document specifies an additional TLS Protocol: the Evidence
+   Protocol.  It is used to create persistent evidence of the TLS
+   session content.  This specification adds one new Record layer
+   ContentType:
+
+      enum {
+         evidence(TBD),
+         (255)
+      } ContentType;
+
+
+
+
+
+Brown & Housley                                                 [Page 8]
+
+Internet-Draft                                             November 2006
+
+
+   Persistence evidence of the TLS session content is produced by the
+   TLS Evidence Protocol.  Evidence messages are supplied to the TLS
+   Record Layer, where they are encapsulated within one or more
+   TLSPlaintext structures, which are processed and transmitted as
+   specified by the current active session state.
+
+   The Evidence Protocol structure follows:
+
+      enum {
+         request(1), response(2), (255)
+      } EvidenceMsgType;
+
+      struct {
+         EvidenceMsgType evidence_msg_type;
+         uint24 length; /* number of octets in message */
+         select (EvidenceMsgType) {
+            case request:     EvidenceRequest;
+            case response:    EvidenceResponse;
+         } body;
+      } EvidenceProtocol;
+
+   The Evidence Protocol messages are presented below in the order they
+   MUST be sent; sending evidence messages in an unexpected order
+   results in a fatal unexpected_message(10) alert.  The EvidenceRequest
+   message and the EvidenceResponse message are specified in Section 4.2
+   and Section 4.3, respectively.  Section 4.1 describes structures that
+   are used in the EvidenceRequest and EvidenceResponse messages.
+
+4.1. Certificates and Digital Signatures
+
+   The evidence Protocol makes use of the ASN.1Cert definition used
+   elsewhere in TLS.  It is repeated here for convenience.
+
+      opaque ASN.1Cert<1..2^24-1>;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brown & Housley                                                 [Page 9]
+
+Internet-Draft                                             November 2006
+
+
+   The EvidenceSignature definition is very similar to the Signature
+   definition used elsewhere in TLS.  The EvidenceSignature definition
+   signs hash[hash_size], but the Signature definition used elsewhere in
+   TLS signs a combination of an md5_hash and a sha_hash.  Also, the
+   EvidenceSignature definition excludes the anonymous case.
+
+      enum { rsa, dsa, ecdsa } EvidenceSignatureAlgorithm;
+
+      select (EvidenceSignatureAlgorithm)
+      {   case rsa:
+              digitally-signed struct {
+                  opaque hash[hash_size];
+              };
+          case dsa:
+              digitally-signed struct {
+                  opaque hash[hash_size];
+              };
+          case ecdsa:
+              digitally-signed struct {
+                  opaque hash[hash_size];
+              };
+      } EvidenceSignature;
+
+   The hash algorithm and the hash_size depend on evidence create
+   algorithm suite selected by the server in the evidence_creation
+   extension.
+
+4.2. EvidenceRequest Message
+
+   The EvidenceRequest message contains the evidence_end1 alert sender's
+   contribution to the persistent evidence.  It employs the evidence
+   create algorithm suite selected by the server in the
+   evidence_creation extension in the extended server hello message.
+
+      struct {
+         Evidence evidence<1..2^16-1>;
+         ASN.1Cert party1_certificate;
+         EvidenceSignature party1_signature;
+      } EvidenceRequest;
+
+
+
+
+
+
+
+
+
+
+
+
+Brown & Housley                                                [Page 10]
+
+Internet-Draft                                             November 2006
+
+
+      struct {
+         EvidenceCreateSuite evidence_suite;
+         uint64 gmt_unix_time;
+         uint64 app_data_sent_offset;
+         uint64 app_data_received_offset;
+         opaque handshake_protocol_hash<1..512>;
+         opaque app_data_sent_hash<1..512>;
+         opaque app_data_received_hash<1..512>;
+      } Evidence;
+
+   The elements of the EvidenceRequest structure are described below:
+
+      evidence
+         Contains an evidence create algorithm identifier, a timestamp,
+         and three hash values in the Evidence structure as described
+         below.
+
+      party1_certificate
+         Contains the X.509 certificate of the signer.  While this
+         certificate was probably exchanged and validated in the
+         Handshake Protocol, inclusion here makes it clear which
+         certificate was employed by the signer when the evidence is
+         validated in the future, possibly by a third party.
+
+      party1_signature
+         Contains the digital signature computed by the sender of the
+         evidence_end1 alert using the evidence creation algorithm suite
+         identified in evidence_create_suite.  The hash value is
+         computed as:
+
+            Hash(evidence)
+
+   The elements of the Evidence structure are described below:
+
+      evidence_suite
+         Indicates the evidence creation algorithm suite selected by the
+         server in the evidence_creation extension in the Handshake
+         Protocol.  This value determines the structure of the hash
+         values and digital signatures.
+
+      gmt_unix_time
+         Indicates the current date and time according to the local
+         system clock used by the sender of the evidence_end1 alert.
+         This time value is intended to represent the moment in time
+         that evidence_end1 was sent.  Unlike other places in the TLS
+         protocol, a 64-bit value is used to ensure that time values do
+         not wrap in 2038.
+
+
+
+
+Brown & Housley                                                [Page 11]
+
+Internet-Draft                                             November 2006
+
+
+      app_data_sent_offset
+         Indicates the number of octets that were sent as part of this
+         TLS session before evidence collection began.
+
+      app_data_received_offset
+         Indicates the number of octets that were received as part of
+         this TLS session before evidence collection began.
+
+      handshake_protocol_hash
+         Compute as:
+
+            Hash(handshake_messages),
+
+         where handshake_messages refers to all Handshake Protocol
+         messages sent or received, beginning with the most recent
+         client hello message.  If the double handshake mechanism
+         described in the security considerations of [TLSAUTHZ] is used
+         to encrypt the Handshake Protocol, the plaintext form of these
+         messages is used in calculating this hash value.
+
+         Verification of the handshake_protocol_hash is performed using
+         the plaintext form of the Handshake protocol messages.  For
+         this hash value to be validated at a later time, this
+         information must be saved as part of the overall evidence.  Any
+         attempt to save this data must ensure that it is not
+         inappropriately disclosed by employing suitable physical
+         protection or cryptographic mechanisms that are at least as
+         strong as the selected TLS ciphersuite.  Suitable controls are
+         discussed further in the Security Considerations; see Section
+         6.
+
+         In the case of successful TLS session resumption, the most
+         recent client hello message will contain a valid
+         ClientHello.session_id value as well as extensions, and these
+         extensions may include sensitive data.  The TLS Authorization
+         Extension [AUTHZ] is one example where an extension might
+         contain sensitive information.  Thus, even when session
+         resumption is employed, the content of the Handshake protocol
+         messages ought to be protected.
+
+         TLS users should ensure that the content of the Handshake
+         protocol messages contain sufficient evidence to determine the
+         intent of the signers, where "signers" are defined as the
+         subject identities in the exchanged X.509 certificates.
+         Clients and servers MAY record the protocol messages containing
+         an expression of the intent of the signers using a suitable TLS
+         extension [TLSEXT], such as [TLSAUTHZ].  For example, a client
+         may request access to a resource provided by the server,
+
+
+
+Brown & Housley                                                [Page 12]
+
+Internet-Draft                                             November 2006
+
+
+         provide sufficient authentication and authorization information
+         grounds to convince the server to grant the requested access,
+         and receive an affirmative response from the server.  A record
+         of TLS Handshake protocol messages representing this example
+         may provide a sufficient record of the intent of both the
+         client and the server.
+
+      app_data_sent_hash
+         Compute as:
+
+            Hash(sent_application_data),
+
+         where sent_application_data refers to all of the Application
+         Data messages sent since the most recent evidence_start1 or
+         evidence start2 alert was sent, and ending with the sending of
+         the evidence_end1 alert.  The alerts are not application data,
+         and they are not included in the hash computation.
+
+      app_data_received_hash
+         Compute as:
+
+            Hash(received_application_data),
+
+         where received_application_data refers to all of the
+         Application Data messages received since the most recent
+         evidence_start1 or evidence start2 alert was received, and
+         ending with the receipt of the evidence_end2 alert.  The alerts
+         are not application data, and they are not included in the hash
+         computation.
+
+4.3. EvidenceResponse Message
+
+   The EvidenceResponse message contains the complete persistent
+   evidence.  The value is saved by one or both parties as evidence of
+   the TLS session content identified by the evidence_start1,
+   evidence_start2, evidence_end1, and evidence_end2 alerts.
+
+      struct {
+         Evidence evidence<1..2^16-1>;
+         ASN.1Cert party1_certificate;
+         EvidenceSignature party1_signature;
+         ASN.1Cert party2_certificate;
+         EvidenceSignature party2_signature;
+      } EvidenceResponse;
+
+
+
+
+
+
+
+Brown & Housley                                                [Page 13]
+
+Internet-Draft                                             November 2006
+
+
+   The elements of the EvidenceResponse structure are described below:
+
+      evidence
+         Contains an evidence create algorithm identifier, a timestamp,
+         and three hash values in the Evidence structure as described in
+         section 4.2.  The evidence creation algorithm MUST match the
+         evidence create algorithm suite selected by the server in the
+         evidence_creation extension in the extended server hello
+         message.  The timestamp MUST be acceptable to the
+         EvidenceRequest recipient as the same value is provided in the
+         EvidenceResponse message.  The three hash values received in
+         the EvidenceRequest message MUST match locally computed values
+         over the same data.  Note that the app_data_sent_hash and the
+         app_data_received_hash values represent the session from the
+         perspective of the EvidenceRequest originator, and the values
+         are not swapped to represent the EvidenceRequest recipient
+         perspective.  If any of these conditions is not met, then the
+         EvidenceResponse message MUST NOT be sent, and the TLS session
+         MUST be closed immediately after sending a fatal
+         evidence_failure(TBD) alert.
+
+      party1_certificate
+         Contains the X.509 certificate of the sender of the
+         evidence_end1 alert.  If this certificate cannot be validated,
+         then TLS session must be closed immediately after sending one
+         of the following fatal alerts: bad_certificate(42),
+         unsupported_certificate(43), certificate_revoked(44), or
+         certificate_expired(45).  These alerts are described in Section
+         7.2.2 of [TLS1.1].
+
+      party1_signature
+         Contains the digital signature computed by the sender of the
+         evidence_end1 alert.  If this signature cannot be validated,
+         then TLS session must be closed immediately after sending a
+         fatal evidence_failure(TBD) alert.
+
+      party2_certificate
+         Contains the X.509 certificate of the sender of the
+         evidence_end2 alert.  While this certificate was probably
+         exchanged and validated in the Handshake Protocol, inclusion
+         here make it clear which certificate was employed by the signer
+         when the evidence is validated in the future, possibly by a
+         third party.
+
+
+
+
+
+
+
+
+Brown & Housley                                                [Page 14]
+
+Internet-Draft                                             November 2006
+
+
+      Party2_signature
+         Contains the digital signature computed by the sender of the
+         evidence_end2 alert using the evidence creation algorithm suite
+         identified in evidence_suite.  The hash value is computed as:
+
+            Hash(evidence)
+
+5. IANA Considerations
+
+   This document defines one TLS extension: evidence_creation(TBD).
+   This extension type value is assigned from the TLS Extension Type
+   registry defined in [TLSEXT].
+
+   This document defines five TLS alert descriptions: the
+   evidence_start1(TBD), evidence_start2(TBD), evidence_end1(TBD),
+   evidence_end2(TBD), and evidence_failure(TBD).  These alert
+   descriptions are assigned from the TLS Alert registry defined in
+   [TLS1.1].
+
+   This document defines one TLS ContentType: evidence(TBD).  This
+   ContentType value is assigned from the TLS ContentType registry
+   defined in [TLS1.1].
+
+   This document establishes a registry for TLS Evidence Protocol
+   EvidenceMsgType.  The first two entries in the registry are
+   request(1) and response(2).  All additional TLS Evidence Protocol
+   EvidenceMsgType values are assigned by Standards Action as described
+   in [IANA].
+
+   This document establishes a registry for Evidence Create Algorithm
+   suite identifiers.   Appendix A lists the initial values for this
+   registry.  Evidence Create Algorithm suite identifier values with the
+   first byte in the range 0-191 (decimal) inclusive are assigned by
+   Standards Action as described in [IANA].  Values with the first byte
+   in the range 192-254 (decimal) are assigned by Specification Required
+   as described in [IANA].  Values with the first byte 255 (decimal) are
+   reserved for Private Use as described in [IANA].
+
+6. Security Considerations
+
+   This document describes an extension to the TLS protocol, and the
+   security considerations in [TLS1.1] and [TLSEXT] apply.
+   Additionally, temporal and storage security considerations are
+   discussed below.
+
+
+
+
+
+
+
+Brown & Housley                                                [Page 15]
+
+Internet-Draft                                             November 2006
+
+
+6.1. Temporal Considerations
+
+   Generating evidence that covers Application Data values that do not
+   explicitly or implicitly indicate the point in time at which the
+   Application Data was transferred over the TLS session might give rise
+   to replay attacks, post-dating, pre-dating, or other temporal
+   disputes.  To avoid these concerns, the evidence includes an
+   indication of the date and time.  The TLS implementation MUST NOT
+   attempt to extract date and time values from the Application Data;
+   doing so is likely to be error prone.  Instead, the date and time
+   SHOULD come from a local clock or a trustworthy time server.  Date
+   and time are provided by one of the parties, and the other party
+   determines that the date and time value is sufficiently accurate.
+
+   When a more highly trusted time source is needed, the Time-Stamp
+   Protocol [TSP] can be used to obtain a time-stamp on the evidence
+   from a trusted third party.
+
+6.2. Storage Considerations
+
+   Parties that choose to preserve a plaintext record of Application
+   Data or Handshake Protocol messages for evidence verification at a
+   later time must ensure must ensure that this data is not
+   inappropriately disclosed by employing suitable physical protection
+   or cryptographic mechanisms that are at least as strong as the
+   selected TLS ciphersuite.
+
+   Suitable physical controls for the protection of Application Data or
+   Handshake Protocol messages containing keying material or sensitive
+   data should use removable storage media in conjunction with durable,
+   locking storage containers.  If the removable media is transferred
+   from one location to another or backup copies are made, secure
+   handling protections ought to be employed, which might include the
+   use of insured or bonded couriers.
+
+   A suitable cryptographic mechanism provides confidentiality
+   protection, since the hash value in the evidence itself provides
+   integrity protection.  One reasonable solution is to encrypt the
+   Handshake Protocol messages and Application Data messages with a
+   fresh symmetric encryption key using the same algorithm that was
+   negotiated for the selected TLS ciphersuite.  The key generation
+   should follow the recommendations in [RANDOM].  Then, the symmetric
+   key is encrypted for storage with the party's RSA public key or long-
+   lived key-encryption key.  The Cryptographic Message Syntax (CMS)
+   [CMS] offers a convenient way to keep all of this information
+   together.
+
+
+
+
+
+Brown & Housley                                                [Page 16]
+
+Internet-Draft                                             November 2006
+
+
+   An alternative cryptographic mechanism is to save the TLS session
+   itself.  The negotiated TLS ciphersuite was already used to protect
+   the Application Data messages, and the Handshake Protocol messages
+   contain the keying material necessary to decrypt them if the party
+   retains the private keys and/or pre-shared secrets.
+
+7. References
+
+7.1. Normative References
+
+   [IANA]       Narten, T., and H. Alvestrand, "Guidelines for Writing
+                an IANA Considerations Section in RFCs", RFC 3434,
+                October 1998.
+
+   [DSS]        Federal Information Processing Standards Publication
+                (FIPS PUB) 186, Digital Signature Standard, 2000.
+
+   [PKCS1]      Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
+                RFC 2313, March 1998.
+
+   [PKIX1]      Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
+                Public Key Infrastructure - Certificate and
+                Certificate Revocation List (CRL) Profile", RFC 3280,
+                April 2002.
+
+   [TLS1.0]     Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
+                RFC 2246, January 1999.
+
+   [TLS1.1]     Dierks, T., and E. Rescorla, "The Transport Layer Security
+                (TLS) Protocol, Version 1.1", RFC 4346, April 2006.
+
+   [TLSEXT]     Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
+                and T. Wright, "Transport Layer Security (TLS) Extensions",
+                RFC 4366, April 2006.
+
+   [SHA]        Federal Information Processing Standards Publication
+                (FIPS PUB) 180-2, Secure Hash Algorithm, 2002.
+
+   [STDWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [X9.62]      X9.62-1998, "Public Key Cryptography For The Financial
+                Services Industry: The Elliptic Curve Digital
+                Signature Algorithm (ECDSA)", January 7, 1999.
+
+
+
+
+
+
+
+Brown & Housley                                                [Page 17]
+
+Internet-Draft                                             November 2006
+
+
+7.2. Informative References
+
+   [AUTHZ]      Brown, M., and R. Housley, "Transport Layer Security
+                (TLS) Authorization Extensions", work in progress,
+                draft-housley-tls-authz-extns.
+
+   [CMS]        Housley, R., "Cryptographic Message Syntax (CMS)",
+                RFC 3852, July 2004.
+
+   [TSP]        Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
+                "Internet X.509 Public Key Infrastructure: Time-Stamp
+                Protocol (TSP)", RFC 3161,August 2001.
+
+8.  Acknowledgements
+
+   Thanks to C. Robert Beattie, J.D. and Randy V. Sabett, J.D., CISSP
+   for their observations and comparisons between the Uniform Electronic
+   Transactions Act (1999) prepared by the National Conference of
+   Commissioners on Uniform State Laws versus the American Bar
+   Association's Digital Signature Guidelines (1996), their observations
+   regarding the strengths and weaknesses of these two approaches, and
+   their desire to promote trust and reduce potential for litigation in
+   online transactions.  Their pro bono contribution of time and
+   expertise deserves recognition.
+
+   This material is based, in part, upon work supported by the United
+   States Navy Space and Naval Warfare Systems Command under Contract
+   No. N00039-06-C-0097.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brown & Housley                                                [Page 18]
+
+Internet-Draft                                             November 2006
+
+
+Appendix A.  Evidence Create Algorithms
+
+   The following values define the EvidenceCreateSuite identifiers used
+   in the TLS Evidence Extensions.
+
+   An EvidenceCreateSuite defines a cipher specification supported by
+   TLS Evidence Extensions.  A suite identifier names a public key
+   signature algorithm and an associated one-way hash function.  A
+   registration is named as follows:
+
+      <SignatureAlgorithm>_WITH_<HashFunction>
+
+   These components have the following meaning:
+
+      <SignatureAlgorithm>
+         Specifies the digital signature algorithm and key length
+         associated with the algorithm.  It is used to digitally sign
+         the evidence.  The "RSA_1024" value indicates the use of the
+         PKCS#1 v1.5 [PKCS1] digital signature algorithm using a
+         1024-bit public key.  The "DSS_1024" value indicates the use of
+         the DSS digital signature algorithm [DSS] with a 1024-bit
+         public key.  The "ECDSA_P384" value indicates the use of the
+         ECDSA digital signature algorithm [X9.62] using the P-384 named
+         elliptic curve.
+
+      <HashFunction>
+         Specifies the one-way hash function used as part of the digital
+         signature. The "SHA_1", "SHA_224", "SHA_256", "SHA_384", and
+         "SHA_512" values identify members of the Secure Hash Algorithm
+         family of one-way- hash functions [SHA].
+
+   In most cases it will be appropriate to use the same algorithms and
+   certified public keys that were negotiated in the TLS Handshake
+   Protocol.  The following additional steps are required in order to
+   employ the digital signature aspects of a TLS CipherSuite to a valid
+   EvidenceCreateSuite:
+
+      1) CipherSuites that do not include signature-capable certificates
+         cannot be used as EvidenceCreateSuite.
+
+      2) CipherSuites that specify the use of MD5 one-way hash function
+         should not be used as EvidenceCreateSuite.
+
+   Of course, any aspect of a CipherSuite that deals with symmetric
+   ciphers and symmetric cipher key lengths is not relevant to the
+   EvidenceCreateSuite.
+
+
+
+
+
+Brown & Housley                                                [Page 19]
+
+Internet-Draft                                             November 2006
+
+
+   All public key certificate profiles used in TLS are defined by the
+   IETF PKIX working group in [PKIX1].  When a key usage extension is
+   present, then either the digitalSignature bit or the nonRepudiation
+   bit MUST be set for the public key to be eligible for signing
+   evidence.  If both bits are set, then this requirement is satisfied.
+
+   The following EvidenceCreateSuite definitions are made at this time.
+   Section 5 specifies the procedures for registering additional
+   EvidenceCreateSuite definitions.
+
+      EvidenceCreateSuite RSA_1024_WITH_SHA_1       = { 0x00, 0x01 };
+      EvidenceCreateSuite RSA_1024_WITH_SHA_256     = { 0x00, 0x02 };
+      EvidenceCreateSuite RSA_2048_WITH_SHA_256     = { 0x00, 0x03 };
+
+      EvidenceCreateSuite DSS_1024_WITH_SHA_1       = { 0x00, 0x11 };
+      EvidenceCreateSuite DSS_2048_WITH_SHA_256     = { 0x00, 0x12 };
+
+      EvidenceCreateSuite ECDSA_P256_WITH_SHA_256   = { 0x00, 0x21 };
+      EvidenceCreateSuite ECDSA_P384_WITH_SHA_384   = { 0x00, 0x22 };
+      EvidenceCreateSuite ECDSA_P521_WITH_SHA_512   = { 0x00, 0x23 };
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brown & Housley                                                [Page 20]
+
+Internet-Draft                                             November 2006
+
+
+Author's Address
+
+   Mark Brown
+   RedPhone Security
+   2019 Palace Avenue
+   Saint Paul, MN  55105
+   USA
+   mark <at> redphonesecurity <dot> com
+
+   Russell Housley
+   Vigil Security, LLC
+   918 Spring Knoll Drive
+   Herndon, VA 20170
+   USA
+   housley <at> vigilsec <dot> com
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006). This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works. However, this
+
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+Brown & Housley                                                [Page 21]