idnits 2.17.1 draft-mavrogiannopoulos-rfc5081bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 abstract seems to contain references ([RFC5081]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (November 30, 2009) is 5262 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5081 (Obsoleted by RFC 6091) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 3 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 Obsoletes: rfc5081 November 30, 2009 5 (if approved) 6 Intended status: Informational 7 Expires: June 3, 2010 9 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication 10 draft-mavrogiannopoulos-rfc5081bis-04 12 Abstract 14 This memo proposes extensions to the Transport Layer Security (TLS) 15 protocol to support the OpenPGP key format. The extensions discussed 16 here include a certificate type negotiation mechanism, and the 17 required modifications to the TLS Handshake Protocol. This memo 18 replaces the Experimental [RFC5081]. 20 Status of This Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on June 3, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Changes to the Handshake Message Contents . . . . . . . . . . . 3 63 3.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.3. Server Certificate . . . . . . . . . . . . . . . . . . . . 4 66 3.4. Certificate Request . . . . . . . . . . . . . . . . . . . . 6 67 3.5. Client Certificate . . . . . . . . . . . . . . . . . . . . 7 68 3.6. Other Handshake Messages . . . . . . . . . . . . . . . . . 7 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 72 Appendix A. Changes from RFC 5081 . . . . . . . . . . . . . . . . 8 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 75 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 The IETF has two sets of standards for public key certificates, one 80 set for use of X.509 certificates [RFC5280] and one for OpenPGP 81 certificates [RFC4880]. At the time of writing, TLS [RFC5246] 82 standards are defined to use X.509 certificates. This document 83 specifies a way to negotiate use of OpenPGP certificates for a TLS 84 session, and specifies how to transport OpenPGP certificates via TLS. 85 The proposed extensions are backward compatible with the current TLS 86 specification, so that existing client and server implementations 87 that make use of X.509 certificates are not affected. 89 The major changes from [RFC5081] are summarized in Appendix A. 91 2. Terminology 93 The term "OpenPGP key" is used in this document as in the OpenPGP 94 specification [RFC4880]. We use the term "OpenPGP certificate" to 95 refer to OpenPGP keys that are enabled for authentication. 97 This document uses the same notation and terminology used in the TLS 98 Protocol specification [RFC5246]. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 3. Changes to the Handshake Message Contents 106 This section describes the changes to the TLS handshake message 107 contents when OpenPGP certificates are to be used for authentication. 109 3.1. Client Hello 111 In order to indicate the support of multiple certificate types, 112 clients MUST include an extension of type "cert_type" to the extended 113 client hello message. The "cert_type" TLS extension is assigned the 114 value of 9 from the TLS ExtensionType registry. This value is used 115 as the extension number for the extensions in both the client hello 116 message and the server hello message. The hello extension mechanism 117 is described in [RFC4366]. 119 This extension carries a list of supported certificate types the 120 client can use, sorted by client preference. This extension MUST be 121 omitted if the client only supports X.509 certificates. The 122 "extension_data" field of this extension contains a 123 CertificateTypeExtension structure. Note that the 124 CertificateTypeExtension structure is being used both by the client 125 and the server, although specified once in this document, a practice 126 common in the TLS protocol specification [RFC5246]. 128 enum { client, server } ClientOrServerExtension; 130 enum { X.509(0), OpenPGP(1), (255) } CertificateType; 132 struct { 133 select(ClientOrServerExtension) { 134 case client: 135 CertificateType certificate_types<1..2^8-1>; 136 case server: 137 CertificateType certificate_type; 138 } 139 } CertificateTypeExtension; 141 No new cipher suites are required to use OpenPGP certificates. All 142 existing cipher suites that support a key exchange method compatible 143 with the key in the certificate can be used in combination with 144 OpenPGP certificates. 146 3.2. Server Hello 148 If the server receives a client hello that contains the "cert_type" 149 extension and chooses a cipher suite that requires a certificate, 150 then two outcomes are possible. The server MUST either select a 151 certificate type from the certificate_types field in the extended 152 client hello or terminate the session with a fatal alert of type 153 "unsupported_certificate". 155 The certificate type selected by the server is encoded in a 156 CertificateTypeExtension structure, which is included in the extended 157 server hello message using an extension of type "cert_type". Servers 158 that only support X.509 certificates MAY omit including the 159 "cert_type" extension in the extended server hello. 161 It is perfectly legal for a server to ignore this message. In that 162 case the normal TLS handshake should be used and, other certificate 163 types than the default MUST NOT be used. 165 3.3. Server Certificate 167 The contents of the certificate message sent from server to client 168 and vice versa are determined by the negotiated certificate type and 169 the selected cipher suite's key exchange algorithm. 171 If the OpenPGP certificate type is negotiated, then it is required to 172 present an OpenPGP certificate in the certificate message. The 173 certificate must contain a public key that matches the selected key 174 exchange algorithm, as shown below. 176 Key Exchange Algorithm OpenPGP Certificate Type 178 RSA RSA public key that can be used for 179 encryption. 181 DHE_DSS DSA public key that can be used for 182 authentication. 184 DHE_RSA RSA public key that can be used for 185 authentication. 187 An OpenPGP certificate appearing in the certificate message is sent 188 using the binary OpenPGP format. The certificate MUST contain all 189 the elements required by Section 11.1 of [RFC4880]. 191 OpenPGP certificates to be transferred are placed in the Certificate 192 structure and tagged with the OpenPGPCertDescriptorType 193 "subkey_cert". Since those certificates might contain several 194 subkeys the subkey ID to be used for this session is explicitely 195 specified in the OpenPGPKeyID field. The key ID must be specified 196 even if the certificate has only a primary key. The peer once 197 receiving this type has to either use the specified subkey or 198 terminate the session with a fatal alert of 199 "unsupported_certificate". 201 The option is also available to send an OpenPGP fingerprint, instead 202 of sending the entire certificate, by using the 203 "subkey_cert_fingerprint" tag. This tag uses the 204 OpenPGPSubKeyFingerprint structure and requires the primary key 205 fingerprint to be specified, as well as the subkey ID to be used for 206 this session. The peer shall respond with a 207 "certificate_unobtainable" fatal alert if the certificate with the 208 given fingerprint cannot be found. The "certificate_unobtainable" 209 fatal alert is defined in Section 4 of [RFC4366]. 211 Implementations of this protocol MUST ensure that the sizes, of key 212 IDs and fingerprints, in the OpenPGPSubKeyCert and 213 OpenPGPSubKeyFingerprint structures comply with [RFC4880]. Moreover 214 it is RECOMMENDED that the keys to be used with this protocol have 215 the authentication flag (0x20) set. 217 The process of fingerprint generation is described in Section 12.2 of 218 [RFC4880]. 220 The enumerated types "cert_fingerprint" and "cert" of 221 OpenPGPCertDescriptorType that were defined in [RFC5081] are not used 222 and are marked as obsolete by this document. The "empty_cert" type 223 has replaced "cert" and is a backwards compatible way to specify an 224 empty certificate; cert_fingerprint" MUST NOT be used with this 225 updated specification, and hence that old alternative has been 226 removed from the Certificate struct description. 228 enum { 229 empty_cert(1), 230 subkey_cert(2), 231 subkey_cert_fingerprint(3), 232 (255) 233 } OpenPGPCertDescriptorType; 235 uint24 OpenPGPEmptyCert = 0; 237 struct { 238 opaque OpenPGPKeyID<8..255>; 239 opaque OpenPGPCert<0..2^24-1>; 240 } OpenPGPSubKeyCert; 242 struct { 243 opaque OpenPGPKeyID<8..255>; 244 opaque OpenPGPCertFingerprint<20..255>; 245 } OpenPGPSubKeyFingerprint; 247 struct { 248 OpenPGPCertDescriptorType descriptorType; 249 select (descriptorType) { 250 case empty_cert: OpenPGPEmptyCert; 251 case subkey_cert: OpenPGPSubKeyCert; 252 case subkey_cert_fingerprint: 253 OpenPGPSubKeyCertFingerprint; 254 } 255 } Certificate; 257 3.4. Certificate Request 259 The semantics of this message remain the same as in the TLS 260 specification. However, if this message is sent, and the negotiated 261 certificate type is OpenPGP, the "certificate_authorities" list MUST 262 be empty. 264 3.5. Client Certificate 266 This message is only sent in response to the certificate request 267 message. The client certificate message is sent using the same 268 formatting as the server certificate message, and it is also required 269 to present a certificate that matches the negotiated certificate 270 type. If OpenPGP certificates have been selected and no certificate 271 is available from the client, then a certificate structure of type 272 "empty_cert" that contains an OpenPGPEmptyCert value MUST be sent. 273 The server SHOULD respond with a "handshake_failure" fatal alert if 274 client authentication is required. 276 3.6. Other Handshake Messages 278 All the other handshake messages are identical to the TLS 279 specification. 281 4. Security Considerations 283 All security considerations discussed in [RFC5246], [RFC4366], and 284 [RFC4880] apply to this document. Considerations about the use of 285 the web of trust or identity and certificate verification procedure 286 are outside the scope of this document. These are considered issues 287 to be handled by the application layer protocols. 289 The protocol for certificate type negotiation is identical in 290 operation to ciphersuite negotiation of the [RFC5246] specification 291 with the addition of default values when the extension is omitted. 292 Since those omissions have a unique meaning and the same protection 293 is applied to the values as with ciphersuites, it is believed that 294 the security properties of this negotiation are the same as with 295 ciphersuite negotiation. 297 When using OpenPGP fingerprints instead of the full certificates, the 298 discussion in Section 6.3 of [RFC4366] for "Client Certificate URLs" 299 applies, especially when external servers are used to retrieve keys. 300 However, a major difference is that although the 301 "client_certificate_url" extension allows identifying certificates 302 without including the certificate hashes, this is not possible in the 303 protocol proposed here. In this protocol, the certificates, when not 304 sent, are always identified by their fingerprint, which serves as a 305 cryptographic hash of the certificate (see Section 12.2 of 306 [RFC4880]). 308 The information that is available to participating parties and 309 eavesdroppers (when confidentiality is not available through a 310 previous handshake) is the number and the types of certificates they 311 hold, plus the contents of certificates. 313 5. IANA Considerations 315 This document uses a registry originally defined in [RFC5081]. 316 Existing IANA references should be updated to point to this document. 318 In addition the "TLS Certificate Types" registry established by 319 [RFC5081] has to be updated in the following way: 321 1. Values 0 (X.509) and 1 (OpenPGP) are defined in this document. 323 2. Values from 2 through 223 decimal inclusive are assigned via "RFC 324 Required" [RFC5226]. 326 3. Values from 224 decimal through 255 decimal inclusive are 327 reserved for Private Use [RFC5226]. 329 6. Acknowledgements 331 The author wishes to thank Daniel Kahn Gillmor and Alfred Hoenes for 332 their suggestions on improving this document. 334 Appendix A. Changes from RFC 5081 336 This document incorporates a major and incompatible change in the 337 "Server Certificate" and "Client Certificate" TLS messages. This 338 change requires the subkey IDs used for TLS authentication to marked 339 explicitely in the handshake procedure. This was decided in order to 340 place no limitation on the OpenPGP certificates' contents that can be 341 used with with this protocol. 343 [RFC5081] required that an OpenPGP key or subkey was marked with the 344 authentication flag and thus would have failed if this flag was not 345 set, or this flag was set in more than one subkeys. The protocol in 346 this memo has no such limitation. 348 7. References 350 7.1. Normative References 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, March 1997. 355 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 356 and T. Wright, "Transport Layer Security (TLS) 357 Extensions", RFC 4366, April 2006. 359 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 360 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 362 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 363 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 364 May 2008. 366 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 367 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 369 7.2. Informative References 371 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport 372 Layer Security (TLS) Authentication", RFC 5081, 373 November 2007. 375 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 376 Housley, R., and W. Polk, "Internet X.509 Public Key 377 Infrastructure Certificate and Certificate Revocation List 378 (CRL) Profile", RFC 5280, May 2008. 380 Author's Address 382 Nikos Mavrogiannopoulos 383 Independent 384 Arkadias 8 385 Halandri, Attiki 15234 386 Greece 388 EMail: nmav@gnutls.org 389 URI: http://www.gnutls.org/