Internet-Draft M. Brown November 2006 RedPhone Security Expires: May 2007 R. Housley Vigil Security Transport Layer Security (TLS) Evidence Extensions 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: _WITH_ These components have the following meaning: 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. 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 redphonesecurity com Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA housley vigilsec 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]