idnits 2.17.1 draft-mavrogiannopoulos-rfc5081bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 364. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (January 2008) is 5918 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4366 (ref. 'TLSEXT') (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3280 (ref. 'PKIX') (Obsoleted by RFC 5280) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Mavrogiannopoulos 3 Internet-Draft Independent 4 Updates: rfc5081 January 2008 5 (if approved) 6 Intended status: Informational 7 Expires: July 4, 2008 9 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication 10 draft-mavrogiannopoulos-rfc5081bis-00 12 Status of This Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 4, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This memo proposes extensions to the Transport Layer Security (TLS) 44 protocol to support the OpenPGP key format. The extensions discussed 45 here include a certificate type negotiation mechanism, and the 46 required modifications to the TLS Handshake Protocol. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Changes to the Handshake Message Contents . . . . . . . . . . . 3 53 3.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.3. Server Certificate . . . . . . . . . . . . . . . . . . . . 4 56 3.4. Certificate Request . . . . . . . . . . . . . . . . . . . . 6 57 3.5. Client Certificate . . . . . . . . . . . . . . . . . . . . 6 58 3.6. Other Handshake Messages . . . . . . . . . . . . . . . . . 6 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 64 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 The IETF has two sets of standards for public key certificates, one 69 set for use of X.509 certificates [PKIX] and one for OpenPGP 70 certificates [OpenPGP]. At the time of writing, TLS [TLS] standards 71 are defined to use only X.509 certificates. This document specifies 72 a way to negotiate use of OpenPGP certificates for a TLS session, and 73 specifies how to transport OpenPGP certificates via TLS. The 74 proposed extensions are backward compatible with the current TLS 75 specification, so that existing client and server implementations 76 that make use of X.509 certificates are not affected. 78 2. Terminology 80 The term "OpenPGP key" is used in this document as in the OpenPGP 81 specification [OpenPGP]. We use the term "OpenPGP certificate" to 82 refer to OpenPGP keys that are enabled for authentication. 84 This document uses the same notation and terminology used in the TLS 85 Protocol specification [TLS]. 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 3. Changes to the Handshake Message Contents 93 This section describes the changes to the TLS handshake message 94 contents when OpenPGP certificates are to be used for authentication. 96 3.1. Client Hello 98 In order to indicate the support of multiple certificate types, 99 clients MUST include an extension of type "cert_type" (see Section 5) 100 to the extended client hello message. The hello extension mechanism 101 is described in [TLSEXT]. 103 This extension carries a list of supported certificate types the 104 client can use, sorted by client preference. This extension MUST be 105 omitted if the client only supports X.509 certificates. The 106 "extension_data" field of this extension contains a 107 CertificateTypeExtension structure. 109 enum { client, server } ClientOrServerExtension; 111 enum { X.509(0), OpenPGP(1), (255) } CertificateType; 113 struct { 114 select(ClientOrServerExtension) { 115 case client: 116 CertificateType certificate_types<1..2^8-1>; 117 case server: 118 CertificateType certificate_type; 119 } 120 } CertificateTypeExtension; 122 No new cipher suites are required to use OpenPGP certificates. All 123 existing cipher suites that support a compatible, with the key, key 124 exchange method can be used in combination with OpenPGP certificates. 126 3.2. Server Hello 128 If the server receives a client hello that contains the "cert_type" 129 extension and chooses a cipher suite that requires a certificate, 130 then two outcomes are possible. The server MUST either select a 131 certificate type from the certificate_types field in the extended 132 client hello or terminate the connection with a fatal alert of type 133 "unsupported_certificate". 135 The certificate type selected by the server is encoded in a 136 CertificateTypeExtension structure, which is included in the extended 137 server hello message using an extension of type "cert_type". Servers 138 that only support X.509 certificates MAY omit including the 139 "cert_type" extension in the extended server hello. 141 It is perfectly legal for a server to ignore this message. In that 142 case the normal TLS handshake should be used. Other certificate 143 types than the default MUST NOT be used. 145 3.3. Server Certificate 147 The contents of the certificate message sent from server to client 148 and vice versa are determined by the negotiated certificate type and 149 the selected cipher suite's key exchange algorithm. 151 If the OpenPGP certificate type is negotiated, then it is required to 152 present an OpenPGP certificate in the certificate message. The 153 certificate must contain a public key that matches the selected key 154 exchange algorithm, as shown below. 156 Key Exchange Algorithm OpenPGP Certificate Type 158 RSA RSA public key that can be used for 159 encryption. 161 DHE_DSS DSS public key that can be used for 162 authentication. 164 DHE_RSA RSA public key that can be used for 165 authentication. 167 An OpenPGP certificate appearing in the certificate message is sent 168 using the binary OpenPGP format. The certificate MUST contain all 169 the elements required by Section 11.1 of [OpenPGP]. 171 The option is also available to send an OpenPGP fingerprint, instead 172 of sending the entire certificate. The process of fingerprint 173 generation is described in Section 12.2 of [OpenPGP]. The peer shall 174 respond with a "certificate_unobtainable" fatal alert if the 175 certificate with the given fingerprint cannot be found. The 176 "certificate_unobtainable" fatal alert is defined in Section 4 of 177 [TLSEXT]. 179 enum { 180 cert_fingerprint (0), cert (1), subkey_cert (2), (255) 181 } OpenPGPCertDescriptorType; 183 opaque OpenPGPCertFingerprint<16..20>; 185 opaque OpenPGPCert<0..2^24-1>; 187 struct { 188 opaque OpenPGPKeyID<1..8>; 189 opaque OpenPGPCert<0..2^24-1>; 190 } OpenPGPSubKeyCert; 192 struct { 193 OpenPGPCertDescriptorType descriptorType; 194 select (descriptorType) { 195 case cert_fingerprint: OpenPGPCertFingerprint; 196 case cert: OpenPGPCert; 197 case subkey_cert: OpenPGPSubKeyCert; 198 } 199 } Certificate; 201 3.4. Certificate Request 203 The semantics of this message remain the same as in the TLS 204 specification. However, if this message is sent, and the negotiated 205 certificate type is OpenPGP, the "certificate_authorities" list MUST 206 be empty. 208 3.5. Client Certificate 210 This message is only sent in response to the certificate request 211 message. The client certificate message is sent using the same 212 formatting as the server certificate message, and it is also required 213 to present a certificate that matches the negotiated certificate 214 type. If OpenPGP certificates have been selected and no certificate 215 is available from the client, then a certificate structure that 216 contains an empty OpenPGPCert vector MUST be sent. The server SHOULD 217 respond with a "handshake_failure" fatal alert if client 218 authentication is required. 220 3.6. Other Handshake Messages 222 All the other handshake messages are identical to the TLS 223 specification. 225 4. Security Considerations 227 All security considerations discussed in [TLS], [TLSEXT], and 228 [OpenPGP] apply to this document. Considerations about the use of 229 the web of trust or identity and certificate verification procedure 230 are outside the scope of this document. These are considered issues 231 to be handled by the application layer protocols. 233 The protocol for certificate type negotiation is identical in 234 operation to ciphersuite negotiation of the [TLS] specification with 235 the addition of default values when the extension is omitted. Since 236 those omissions have a unique meaning and the same protection is 237 applied to the values as with ciphersuites, it is believed that the 238 security properties of this negotiation are the same as with 239 ciphersuite negotiation. 241 When using OpenPGP fingerprints instead of the full certificates, the 242 discussion in Section 6.3 of [TLSEXT] for "Client Certificate URLs" 243 applies, especially when external servers are used to retrieve keys. 244 However, a major difference is that although the 245 "client_certificate_url" extension allows identifying certificates 246 without including the certificate hashes, this is not possible in the 247 protocol proposed here. In this protocol, the certificates, when not 248 sent, are always identified by their fingerprint, which serves as a 249 cryptographic hash of the certificate (see Section 12.2 of 250 [OpenPGP]). 252 The information that is available to participating parties and 253 eavesdroppers (when confidentiality is not available through a 254 previous handshake) is the number and the types of certificates they 255 hold, plus the contents of certificates. 257 5. IANA Considerations 259 This document defines a new TLS extension, "cert_type", assigned a 260 value of 9 from the TLS ExtensionType registry defined in [TLSEXT]. 261 This value is used as the extension number for the extensions in both 262 the client hello message and the server hello message. The new 263 extension type is used for certificate type negotiation. 265 The "cert_type" extension contains an 8-bit CertificateType field, 266 for which a new registry, named "TLS Certificate Types", is 267 established in this document, to be maintained by IANA. The registry 268 is segmented in the following way: 270 1. Values 0 (X.509) and 1 (OpenPGP) are defined in this document. 272 2. Values from 2 through 223 decimal inclusive are assigned via IETF 273 Consensus [RFC2434]. 275 3. Values from 224 decimal through 255 decimal inclusive are 276 reserved for Private Use [RFC2434]. 278 6. Acknowledgements 280 This document was based on earlier work made by Will Price and 281 Michael Elkins. 283 The author wishes to thank Werner Koch, David Taylor, Timo Schulz, 284 Pasi Eronen, Jon Callas, Stephen Kent, Robert Sparks, and Hilarie 285 Orman for their suggestions on improving this document. 287 7. References 289 7.1. Normative References 291 [TLS] Dierks, T. and E. Rescorla, "The TLS Protocol Version 292 1.1", RFC 4346, April 2006. 294 [OpenPGP] Callas, J., Donnerhacke, L., Finey, H., Shaw, D., and R. 295 Thayer, "OpenPGP Message Format", RFC 4880, October 2007. 297 [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 298 and T. Wright, "Transport Layer Security (TLS) 299 Extensions", RFC 4366, April 2006. 301 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 302 IANA Considerations Section in RFCs", RFC 2434, 303 October 1998. 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", RFC 2119, March 1997. 308 7.2. Informative References 310 [PKIX] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet 311 X.509 Public Key Infrastructure Certificate and 312 Certificate Revocation List (CRL) Profile", RFC 3280, 313 April 2002. 315 Author's Address 317 Nikos Mavrogiannopoulos 318 Independent 319 Arkadias 8 320 Halandri, Attiki 15234 321 Greece 323 EMail: nmav@gnutls.org 324 URI: http://www.gnutls.org/ 326 Full Copyright Statement 328 Copyright (C) The IETF Trust (2008). 330 This document is subject to the rights, licenses and restrictions 331 contained in BCP 78, and except as set forth therein, the authors 332 retain all their rights. 334 This document and the information contained herein are provided on an 335 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 336 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 337 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 338 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 339 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 340 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 342 Intellectual Property 344 The IETF takes no position regarding the validity or scope of any 345 Intellectual Property Rights or other rights that might be claimed to 346 pertain to the implementation or use of the technology described in 347 this document or the extent to which any license under such rights 348 might or might not be available; nor does it represent that it has 349 made any independent effort to identify any such rights. Information 350 on the procedures with respect to rights in RFC documents can be 351 found in BCP 78 and BCP 79. 353 Copies of IPR disclosures made to the IETF Secretariat and any 354 assurances of licenses to be made available, or the result of an 355 attempt made to obtain a general license or permission for the use of 356 such proprietary rights by implementers or users of this 357 specification can be obtained from the IETF on-line IPR repository at 358 http://www.ietf.org/ipr. 360 The IETF invites any interested party to bring to its attention any 361 copyrights, patents or patent applications, or other proprietary 362 rights that may cover technology that may be required to implement 363 this standard. Please address the information to the IETF at 364 ietf-ipr@ietf.org. 366 Acknowledgement 368 Funding for the RFC Editor function is provided by the IETF 369 Administrative Support Activity (IASA).