idnits 2.17.1 draft-ietf-tls-openpgp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 14 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([OpenPGP], [X509], [TLS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: All of the above Cipher Suites use either the CAST, IDEA, or TripleDES block ciphers in CBC mode. The choice of hash is either SHA-1 or RIPEMD-160. Use of any of these Cipher Suites REQUIRES an OpenPGP key in any Certificate and Client Certificate messages. MD5 MAY NOT be used with OpenPGP keys. "Export" algorithms also MAY NOT be used with OpenPGP keys. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (18 February 2002) is 8100 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'TLS' on line 161 looks like a reference -- Missing reference section? 'OpenPGP' on line 164 looks like a reference -- Missing reference section? 'X509' on line 50 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TLS Working Group Will Price 2 INTERNET-DRAFT Michael Elkins 3 Network Associates, Inc. 4 18 February 2002 6 draft-ietf-tls-openpgp-02.txt 8 Extensions to TLS for OpenPGP keys 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document builds upon the TLS Protocol Specification [TLS]. The 34 extensions described herein are intended to apply to Version 1.0 of 35 the TLS specification. 37 The purpose of this document is to update the TLS protocol with 38 extensions to support the certificates, public key algorithms, 39 symmetric ciphers, hash algorithms, and trust model used by OpenPGP 40 [OpenPGP]. 42 This document uses the same notation used in the TLS Protocol draft. 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119. 48 Certificate 50 The X.509.v3 [X509] certificates recommended for use with TLS will 51 not be used in conjunction with OpenPGP keys. An implementation 52 SHOULD be able to support both TLS with X509 and TLS with OpenPGP 53 keys. It is NOT REQUIRED that an implementation support both. The 54 "peer certificate" in the session state of TLS MAY refer to either 55 X509 or OpenPGP. 57 The contents of the Certificate (11) message sent from server to 58 client and vice versa are determined by the Cipher Suite. Many new 59 Cipher Suites are defined in the Cipher Suites section of this 60 document for use with OpenPGP keys. All OpenPGP Cipher Suites 61 REQUIRE a OpenPGP key in the Certificate messages. A OpenPGP key 62 appearing in the Certificate message will be sent in binary OpenPGP 63 format. The Certificate message includes a OpenPGP key where the 64 X509 certificate would normally appear. The option is also available 65 to send a 64 bit OpenPGP Key ID instead of sending the entire key. 66 The client will respond with a fatal alert no_certificate if the Key 67 ID cannot be found. If the key is not valid, expired, revoked, or 68 corrupt, the appropriate fatal alert message is sent from section A.3 69 of the TLS specification. If a key is valid and neither expired nor 70 revoked, it is accepted by the protocol. A particular OpenPGP 71 compatible TLS implementation MAY wish to allow users to designate 72 certain keys specifically as Trusted Server Keys. This is a local 73 matter outside the scope of this document. 75 enum { 76 keyid (0), key (1), (255) 77 } PGPKeyDescriptorType; 79 opaque PGPKeyID<8> 80 opaque PGPKey<1..2^24-1> 81 struct { 82 PGPKeyDescriptorType descriptorType; 83 select (descriptorType) { 84 case keyid: PGPKeyID; 85 case key: PGPKey; 86 } 87 } Certificate; 89 Certificate Request 91 The server is allowed to request a client certificate from the 92 client. The meaning of this message is essentially unchanged to 93 allow OpenPGP keys. 95 The rsa_sign and dss_sign certificate types may be requested in 96 conjunction with OpenPGP keys. The ClientCertificateType field is 97 used identically to the TLS specification. The subsequent 98 DistinguishedName field is NOT included when using Cipher Suites 99 based on OpenPGP keys. 101 The Client Certificate message is sent using the same formatting as 102 the server Certificate message in response to the Certificate Request 103 message. If no OpenPGP key is available from the client, the 104 no_certificate alert is returned. The server MAY then respond with a 105 fatal alert if appropriate. This transaction follows the TLS 106 specification. 108 Server Key Exchange 110 When using ephemeral Diffie-Hellman, the Server Key Exchange message 111 is sent to pass the Diffie-Hellman public value to the client. The 112 client and server then use this value to establish the shared secret. 113 This is identical to the operation of standard TLS. 115 Certificate Verify 117 The Certificate Verify message for OpenPGP key types is identical to 118 the specification. The signature is made using either DSS or RSA 119 depending on the Cipher Suite. 121 Finished 123 The Finished message for OpenPGP key types is identical to the 124 description in the specification. 126 Cipher Suites 128 Since TLS does not have a certificate type field, the Cipher Suites 129 field is used to perform the same function. A number of additional 130 Cipher Suites are defined for use with OpenPGP keys. 132 CipherSuite TLS_PGP_DHE_DSS_WITH_CAST_CBC_SHA = { 0x01, 0x01 }; 133 CipherSuite TLS_PGP_DHE_DSS_WITH_IDEA_CBC_SHA = { 0x01, 0x02 }; 134 CipherSuite TLS_PGP_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x01, 0x03 }; 135 CipherSuite TLS_PGP_DHE_DSS_WITH_CAST_CBC_RMD = { 0x01, 0x04 }; 136 CipherSuite TLS_PGP_DHE_DSS_WITH_IDEA_CBC_RMD = { 0x01, 0x05 }; 137 CipherSuite TLS_PGP_DHE_DSS_WITH_3DES_EDE_CBC_RMD = { 0x01, 0x06 }; 138 CipherSuite TLS_PGP_DHE_RSA_WITH_CAST_CBC_SHA = { 0x01, 0x10 }; 139 CipherSuite TLS_PGP_RSA_WITH_CAST_CBC_SHA = { 0x01, 0x20 }; 140 CipherSuite TLS_PGP_RSA_WITH_IDEA_CBC_SHA = { 0x01, 0x21 }; 141 CipherSuite TLS_PGP_RSA_WITH_3DES_EDE_CBC_SHA = { 0x01, 0x22 }; 142 CipherSuite TLS_PGP_RSA_WITH_CAST_CBC_RMD = { 0x01, 0x23 }; 143 CipherSuite TLS_PGP_RSA_WITH_IDEA_CBC_RMD = { 0x01, 0x24 }; 144 CipherSuite TLS_PGP_RSA_WITH_3DES_EDE_CBC_RMD = { 0x01, 0x25 }; 145 CipherSuite TLS_PGP_DSA_WITH_NULL_SHA = { 0x01, 0xF0 }; 146 Note: The above numeric definitions for Cipher Suites have not 147 yet been registered. 149 All of the above Cipher Suites use either the CAST, IDEA, or 150 TripleDES block ciphers in CBC mode. The choice of hash is either 151 SHA-1 or RIPEMD-160. Use of any of these Cipher Suites REQUIRES an 152 OpenPGP key in any Certificate and Client Certificate messages. MD5 153 MAY NOT be used with OpenPGP keys. "Export" algorithms also MAY NOT 154 be used with OpenPGP keys. 156 To be considered compliant with support for OpenPGP in TLS, an 157 implementation MUST support TLS_PGP_DHE_DSS_WITH_3DES_EDE_CBC_SHA. 159 References 161 [TLS] T. Dierks, and C. Allen, "The TLS Protocol Version 1.0", 162 RFC 2246, January 1999. 164 [OpenPGP] J. Callas, L. Donnerhacke, H. Finney, R. Thayer, 165 "OpenPGP Message Format", RFC 2440, November 1998. 167 Authors 169 Will Price 170 Network Associates, Inc. 172 Michael Elkins 173 Network Associates, Inc.