idnits 2.17.1 draft-mavrogiannopoulos-rfc5081bis-01.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 352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 376. 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 (July 25, 2008) is 5746 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Mavrogiannopoulos 3 Internet-Draft Gennet S.A. 4 Updates: rfc5081 July 25, 2008 5 (if approved) 6 Intended status: Informational 7 Expires: January 26, 2009 9 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication 10 draft-mavrogiannopoulos-rfc5081bis-01 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 January 26, 2009. 37 Abstract 39 This memo proposes extensions to the Transport Layer Security (TLS) 40 protocol to support the OpenPGP key format. The extensions discussed 41 here include a certificate type negotiation mechanism, and the 42 required modifications to the TLS Handshake Protocol. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. Changes to the Handshake Message Contents . . . . . . . . . . . 3 49 3.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 3 50 3.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 4 51 3.3. Server Certificate . . . . . . . . . . . . . . . . . . . . 4 52 3.4. Certificate Request . . . . . . . . . . . . . . . . . . . . 6 53 3.5. Client Certificate . . . . . . . . . . . . . . . . . . . . 6 54 3.6. Other Handshake Messages . . . . . . . . . . . . . . . . . 7 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 57 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 60 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 62 1. Introduction 64 The IETF has two sets of standards for public key certificates, one 65 set for use of X.509 certificates [RFC5280] and one for OpenPGP 66 certificates [RFC4880]. At the time of writing, TLS [RFC4346] 67 standards are defined to use only X.509 certificates. This document 68 specifies a way to negotiate use of OpenPGP certificates for a TLS 69 session, and specifies how to transport OpenPGP certificates via TLS. 70 The proposed extensions are backward compatible with the current TLS 71 specification, so that existing client and server implementations 72 that make use of X.509 certificates are not affected. 74 2. Terminology 76 The term "OpenPGP key" is used in this document as in the OpenPGP 77 specification [RFC4880]. We use the term "OpenPGP certificate" to 78 refer to OpenPGP keys that are enabled for authentication. 80 This document uses the same notation and terminology used in the TLS 81 Protocol specification [RFC4346]. 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 3. Changes to the Handshake Message Contents 89 This section describes the changes to the TLS handshake message 90 contents when OpenPGP certificates are to be used for authentication. 92 3.1. Client Hello 94 In order to indicate the support of multiple certificate types, 95 clients MUST include an extension of type "cert_type" (see Section 5) 96 to the extended client hello message. The hello extension mechanism 97 is described in [RFC4366]. 99 This extension carries a list of supported certificate types the 100 client can use, sorted by client preference. This extension MUST be 101 omitted if the client only supports X.509 certificates. The 102 "extension_data" field of this extension contains a 103 CertificateTypeExtension structure. 105 enum { client, server } ClientOrServerExtension; 107 enum { X.509(0), OpenPGP(1), (255) } CertificateType; 109 struct { 110 select(ClientOrServerExtension) { 111 case client: 112 CertificateType certificate_types<1..2^8-1>; 113 case server: 114 CertificateType certificate_type; 115 } 116 } CertificateTypeExtension; 118 No new cipher suites are required to use OpenPGP certificates. All 119 existing cipher suites that support a compatible, with the key, key 120 exchange method can be used in combination with OpenPGP certificates. 122 3.2. Server Hello 124 If the server receives a client hello that contains the "cert_type" 125 extension and chooses a cipher suite that requires a certificate, 126 then two outcomes are possible. The server MUST either select a 127 certificate type from the certificate_types field in the extended 128 client hello or terminate the session with a fatal alert of type 129 "unsupported_certificate". 131 The certificate type selected by the server is encoded in a 132 CertificateTypeExtension structure, which is included in the extended 133 server hello message using an extension of type "cert_type". Servers 134 that only support X.509 certificates MAY omit including the 135 "cert_type" extension in the extended server hello. 137 It is perfectly legal for a server to ignore this message. In that 138 case the normal TLS handshake should be used. Other certificate 139 types than the default MUST NOT be used. 141 3.3. Server Certificate 143 The contents of the certificate message sent from server to client 144 and vice versa are determined by the negotiated certificate type and 145 the selected cipher suite's key exchange algorithm. 147 If the OpenPGP certificate type is negotiated, then it is required to 148 present an OpenPGP certificate in the certificate message. The 149 certificate must contain a public key that matches the selected key 150 exchange algorithm, as shown below. 152 Key Exchange Algorithm OpenPGP Certificate Type 154 RSA RSA public key that can be used for 155 encryption. 157 DHE_DSS DSS public key that can be used for 158 authentication. 160 DHE_RSA RSA public key that can be used for 161 authentication. 163 An OpenPGP certificate appearing in the certificate message is sent 164 using the binary OpenPGP format. The certificate MUST contain all 165 the elements required by Section 11.1 of [RFC4880]. 167 The option is also available to send an OpenPGP fingerprint, instead 168 of sending the entire certificate. The process of fingerprint 169 generation is described in Section 12.2 of [RFC4880]. The peer shall 170 respond with a "certificate_unobtainable" fatal alert if the 171 certificate with the given fingerprint cannot be found. The 172 "certificate_unobtainable" fatal alert is defined in Section 4 of 173 [RFC4366]. 175 In order to facilitate for using a subkey instead for the primary 176 OpenPGP key the "subkey_cert" and "subkey_cert_fingerprint" of 177 OpenPGPCertDescriptorType can be used. Those include an extra field 178 to indicate the OpenPGP subkey to be used in this session. If these 179 types are used the peer has to either use the specified subkeys or 180 terminate the session with a fatal alert of 181 "unsupported_certificate". 183 enum { 184 cert_fingerprint (0), cert (1), subkey_cert (2), 185 subkey_cert_fingerprint (3), (255) 186 } OpenPGPCertDescriptorType; 188 opaque OpenPGPCertFingerprint<16..20>; 190 opaque OpenPGPCert<0..2^24-1>; 192 struct { 193 opaque OpenPGPKeyID<1..8>; 194 opaque OpenPGPCert<0..2^24-1>; 195 } OpenPGPSubKeyCert; 197 struct { 198 opaque OpenPGPKeyID<1..8>; 199 opaque OpenPGPCertFingerprint<16..20>; 200 } OpenPGPSubKeyFingerprint; 202 struct { 203 OpenPGPCertDescriptorType descriptorType; 204 select (descriptorType) { 205 case cert_fingerprint: OpenPGPCertFingerprint; 206 case cert: OpenPGPCert; 207 case subkey_cert: OpenPGPSubKeyCert; 208 case subkey_cert_fingerprint: 209 OpenPGPSubKeyCertFingerprint; 210 } 211 } Certificate; 213 3.4. Certificate Request 215 The semantics of this message remain the same as in the TLS 216 specification. However, if this message is sent, and the negotiated 217 certificate type is OpenPGP, the "certificate_authorities" list MUST 218 be empty. 220 3.5. Client Certificate 222 This message is only sent in response to the certificate request 223 message. The client certificate message is sent using the same 224 formatting as the server certificate message, and it is also required 225 to present a certificate that matches the negotiated certificate 226 type. If OpenPGP certificates have been selected and no certificate 227 is available from the client, then a certificate structure of type 228 "cert" that contains an empty OpenPGPCert vector MUST be sent. The 229 server SHOULD respond with a "handshake_failure" fatal alert if 230 client authentication is required. 232 3.6. Other Handshake Messages 234 All the other handshake messages are identical to the TLS 235 specification. 237 4. Security Considerations 239 All security considerations discussed in [RFC4346], [RFC4366], and 240 [RFC4880] apply to this document. Considerations about the use of 241 the web of trust or identity and certificate verification procedure 242 are outside the scope of this document. These are considered issues 243 to be handled by the application layer protocols. 245 The protocol for certificate type negotiation is identical in 246 operation to ciphersuite negotiation of the [RFC4346] specification 247 with the addition of default values when the extension is omitted. 248 Since those omissions have a unique meaning and the same protection 249 is applied to the values as with ciphersuites, it is believed that 250 the security properties of this negotiation are the same as with 251 ciphersuite negotiation. 253 When using OpenPGP fingerprints instead of the full certificates, the 254 discussion in Section 6.3 of [RFC4366] for "Client Certificate URLs" 255 applies, especially when external servers are used to retrieve keys. 256 However, a major difference is that although the 257 "client_certificate_url" extension allows identifying certificates 258 without including the certificate hashes, this is not possible in the 259 protocol proposed here. In this protocol, the certificates, when not 260 sent, are always identified by their fingerprint, which serves as a 261 cryptographic hash of the certificate (see Section 12.2 of 262 [RFC4880]). 264 The information that is available to participating parties and 265 eavesdroppers (when confidentiality is not available through a 266 previous handshake) is the number and the types of certificates they 267 hold, plus the contents of certificates. 269 5. IANA Considerations 271 This document defines a new TLS extension, "cert_type", assigned a 272 value of 9 from the TLS ExtensionType registry defined in [RFC4366]. 273 This value is used as the extension number for the extensions in both 274 the client hello message and the server hello message. The new 275 extension type is used for certificate type negotiation. 277 The "cert_type" extension contains an 8-bit CertificateType field, 278 for which a new registry, named "TLS Certificate Types", is 279 established in this document, to be maintained by IANA. The registry 280 is segmented in the following way: 282 1. Values 0 (X.509) and 1 (OpenPGP) are defined in this document. 284 2. Values from 2 through 223 decimal inclusive are assigned via IETF 285 Consensus [RFC2434]. 287 3. Values from 224 decimal through 255 decimal inclusive are 288 reserved for Private Use [RFC2434]. 290 6. Acknowledgements 292 This document was based on earlier work made by Will Price and 293 Michael Elkins. 295 The author wishes to thank Werner Koch, David Taylor, Timo Schulz, 296 Pasi Eronen, Jon Callas, Stephen Kent, Robert Sparks, and Hilarie 297 Orman for their suggestions on improving this document. 299 7. References 301 7.1. Normative References 303 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 304 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 306 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 307 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 309 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 310 and T. Wright, "Transport Layer Security (TLS) 311 Extensions", RFC 4366, April 2006. 313 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 314 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 315 October 1998. 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, March 1997. 320 7.2. Informative References 322 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 323 Housley, R., and W. Polk, "Internet X.509 Public Key 324 Infrastructure Certificate and Certificate Revocation List 325 (CRL) Profile", RFC 5280, May 2008. 327 Author's Address 329 Nikos Mavrogiannopoulos 330 Gennet S.A. 331 Arkadias 8 332 Halandri, Attiki 15234 333 Greece 335 EMail: nmav@gnutls.org 336 URI: http://www.gnutls.org/ 338 Full Copyright Statement 340 Copyright (C) The IETF Trust (2008). 342 This document is subject to the rights, licenses and restrictions 343 contained in BCP 78, and except as set forth therein, the authors 344 retain all their rights. 346 This document and the information contained herein are provided on an 347 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 348 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 349 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 350 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 351 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 352 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 354 Intellectual Property 356 The IETF takes no position regarding the validity or scope of any 357 Intellectual Property Rights or other rights that might be claimed to 358 pertain to the implementation or use of the technology described in 359 this document or the extent to which any license under such rights 360 might or might not be available; nor does it represent that it has 361 made any independent effort to identify any such rights. Information 362 on the procedures with respect to rights in RFC documents can be 363 found in BCP 78 and BCP 79. 365 Copies of IPR disclosures made to the IETF Secretariat and any 366 assurances of licenses to be made available, or the result of an 367 attempt made to obtain a general license or permission for the use of 368 such proprietary rights by implementers or users of this 369 specification can be obtained from the IETF on-line IPR repository at 370 http://www.ietf.org/ipr. 372 The IETF invites any interested party to bring to its attention any 373 copyrights, patents or patent applications, or other proprietary 374 rights that may cover technology that may be required to implement 375 this standard. Please address the information to the IETF at 376 ietf-ipr@ietf.org.