idnits 2.17.1 draft-mavrogiannopoulos-rfc5081bis-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 draft header indicates that this document obsoletes RFC5081, but the abstract doesn't seem to mention this, which it should. 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 (October 3, 2010) is 4926 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-tls-rfc4366-bis-10 ** 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: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Mavrogiannopoulos 3 Internet-Draft KUL 4 Obsoletes: 5081 (if approved) D. Gillmor 5 Intended status: Informational Independent 6 Expires: April 6, 2011 October 3, 2010 8 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication 9 draft-mavrogiannopoulos-rfc5081bis-09 11 Abstract 13 This memo defines Transport Layer Security (TLS) extensions and 14 associated semantics that allow clients and sever to negotiate the 15 use of OpenPGP certificates for a TLS session, and specifies how to 16 transport OpenPGP certificates via TLS. It also defines the registry 17 for non-X.509 certificate types. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 6, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Changes to the Handshake Message Contents . . . . . . . . . . . 3 56 3.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.3. Server Certificate . . . . . . . . . . . . . . . . . . . . 4 59 3.4. Certificate Request . . . . . . . . . . . . . . . . . . . . 6 60 3.5. Client Certificate . . . . . . . . . . . . . . . . . . . . 7 61 3.6. Other Handshake Messages . . . . . . . . . . . . . . . . . 7 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 68 Appendix A. Changes from RFC 5081 . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 The IETF has two sets of standards for public key certificates, one 73 set for use of X.509 certificates [RFC5280] and one for OpenPGP 74 certificates [RFC4880]. At the time of writing, TLS [RFC5246] 75 standards are defined to use X.509 certificates. This document 76 specifies a way to negotiate use of OpenPGP certificates for a TLS 77 session, and specifies how to transport OpenPGP certificates via TLS. 78 The proposed extensions are backward compatible with the current TLS 79 specification, so that existing client and server implementations 80 that make use of X.509 certificates are not affected. 82 These extensions are not backward-compatible with [RFC5081] and the 83 major differences are summarized in Appendix A. Although the OpenPGP 84 CertificateType value is being reused by this memo with the same 85 number as in [RFC5081] but different semantics, we believe that this 86 causes no interoperability issues because the latter was not widely 87 deployed. 89 2. Terminology 91 The term "OpenPGP key" is used in this document as in the OpenPGP 92 specification [RFC4880]. We use the term "OpenPGP certificate" to 93 refer to OpenPGP keys that are enabled for authentication. 95 This document uses the same notation and terminology used in the TLS 96 Protocol specification [RFC5246]. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. Changes to the Handshake Message Contents 104 This section describes the changes to the TLS handshake message 105 contents when OpenPGP certificates are to be used for authentication. 107 3.1. Client Hello 109 In order to indicate the support of multiple certificate types, 110 clients MUST include an extension of type "cert_type" to the extended 111 client hello message. The "cert_type" TLS extension is assigned the 112 value of 9 from the TLS ExtensionType registry. This value is used 113 as the extension number for the extensions in both the client hello 114 message and the server hello message. The hello extension mechanism 115 is described in [RFC5246]. 117 This extension carries a list of supported certificate types the 118 client can use, sorted by client preference. This extension MUST be 119 omitted if the client only supports X.509 certificates. The 120 "extension_data" field of this extension contains a 121 CertificateTypeExtension structure. Note that the 122 CertificateTypeExtension structure is being used both by the client 123 and the server, although specified once in this document, a practice 124 common in the TLS protocol specification [RFC5246]. 126 enum { client, server } ClientOrServerExtension; 128 enum { X.509(0), OpenPGP(1), (255) } CertificateType; 130 struct { 131 select(ClientOrServerExtension) { 132 case client: 133 CertificateType certificate_types<1..2^8-1>; 134 case server: 135 CertificateType certificate_type; 136 } 137 } CertificateTypeExtension; 139 No new cipher suites are required to use OpenPGP certificates. All 140 existing cipher suites that support a key exchange method compatible 141 with the key in the certificate can be used in combination with 142 OpenPGP certificates. 144 3.2. Server Hello 146 If the server receives a client hello that contains the "cert_type" 147 extension and chooses a cipher suite that requires a certificate, 148 then two outcomes are possible. The server MUST either select a 149 certificate type from the certificate_types field in the extended 150 client hello or terminate the session with a fatal alert of type 151 "unsupported_certificate". 153 The certificate type selected by the server is encoded in a 154 CertificateTypeExtension structure, which is included in the extended 155 server hello message using an extension of type "cert_type". Servers 156 that only support X.509 certificates MAY omit including the 157 "cert_type" extension in the extended server hello. 159 3.3. Server Certificate 161 The contents of the certificate message sent from server to client 162 and vice versa are determined by the negotiated certificate type and 163 the selected cipher suite's key exchange algorithm. 165 If the OpenPGP certificate type is negotiated, then it is required to 166 present an OpenPGP certificate in the certificate message. The 167 certificate must contain a public key that matches the selected key 168 exchange algorithm, as shown below. 170 Key Exchange Algorithm OpenPGP Certificate Type 172 RSA RSA public key that can be used for 173 encryption. 175 DHE_DSS DSA public key that can be used for 176 authentication. 178 DHE_RSA RSA public key that can be used for 179 authentication. 181 An OpenPGP certificate appearing in the certificate message is sent 182 using the binary OpenPGP format. The certificate MUST contain all 183 the elements required by Section 11.1 of [RFC4880]. 185 OpenPGP certificates to be transferred are placed in the Certificate 186 structure and tagged with the OpenPGPCertDescriptorType 187 "subkey_cert". Since those certificates might contain several 188 subkeys the subkey ID to be used for this session is explicitely 189 specified in the OpenPGPKeyID field. The key ID must be specified 190 even if the certificate has only a primary key. The peer once 191 receiving this type has to either use the specified subkey or 192 terminate the session with a fatal alert of 193 "unsupported_certificate". 195 The option is also available to send an OpenPGP fingerprint, instead 196 of sending the entire certificate, by using the 197 "subkey_cert_fingerprint" tag. This tag uses the 198 OpenPGPSubKeyFingerprint structure and requires the primary key 199 fingerprint to be specified, as well as the subkey ID to be used for 200 this session. The peer shall respond with a 201 "certificate_unobtainable" fatal alert if the certificate with the 202 given fingerprint cannot be found. The "certificate_unobtainable" 203 fatal alert is defined in Section 5 of [I-D.ietf-tls-rfc4366-bis]. 205 Implementations of this protocol MUST ensure that the sizes, of key 206 IDs and fingerprints, in the OpenPGPSubKeyCert and 207 OpenPGPSubKeyFingerprint structures comply with [RFC4880]. Moreover 208 it is RECOMMENDED that the keys to be used with this protocol have 209 the authentication flag (0x20) set. 211 The process of fingerprint generation is described in Section 12.2 of 213 [RFC4880]. 215 The enumerated types "cert_fingerprint" and "cert" of 216 OpenPGPCertDescriptorType that were defined in [RFC5081] are not used 217 and are marked as obsolete by this document. The "empty_cert" type 218 has replaced "cert" and is a backwards compatible way to specify an 219 empty certificate; cert_fingerprint" MUST NOT be used with this 220 updated specification, and hence that old alternative has been 221 removed from the Certificate struct description. 223 enum { 224 empty_cert(1), 225 subkey_cert(2), 226 subkey_cert_fingerprint(3), 227 (255) 228 } OpenPGPCertDescriptorType; 230 uint24 OpenPGPEmptyCert = 0; 232 struct { 233 opaque OpenPGPKeyID<8..255>; 234 opaque OpenPGPCert<0..2^24-1>; 235 } OpenPGPSubKeyCert; 237 struct { 238 opaque OpenPGPKeyID<8..255>; 239 opaque OpenPGPCertFingerprint<20..255>; 240 } OpenPGPSubKeyFingerprint; 242 struct { 243 OpenPGPCertDescriptorType descriptorType; 244 select (descriptorType) { 245 case empty_cert: OpenPGPEmptyCert; 246 case subkey_cert: OpenPGPSubKeyCert; 247 case subkey_cert_fingerprint: 248 OpenPGPSubKeyCertFingerprint; 249 } 250 } Certificate; 252 3.4. Certificate Request 254 The semantics of this message remain the same as in the TLS 255 specification. However, if this message is sent, and the negotiated 256 certificate type is OpenPGP, the "certificate_authorities" list MUST 257 be empty. 259 3.5. Client Certificate 261 This message is only sent in response to the certificate request 262 message. The client certificate message is sent using the same 263 formatting as the server certificate message, and it is also required 264 to present a certificate that matches the negotiated certificate 265 type. If OpenPGP certificates have been selected and no certificate 266 is available from the client, then a certificate structure of type 267 "empty_cert" that contains an OpenPGPEmptyCert value MUST be sent. 268 The server SHOULD respond with a "handshake_failure" fatal alert if 269 client authentication is required. 271 3.6. Other Handshake Messages 273 All the other handshake messages are identical to the TLS 274 specification. 276 4. Security Considerations 278 All security considerations discussed in [RFC5246], 279 [I-D.ietf-tls-rfc4366-bis], and [RFC4880] apply to this document. 280 Considerations about the use of the web of trust or identity and 281 certificate verification procedure are outside the scope of this 282 document. These are considered issues to be handled by the 283 application layer protocols. 285 The protocol for certificate type negotiation is identical in 286 operation to ciphersuite negotiation of the [RFC5246] specification 287 with the addition of default values when the extension is omitted. 288 Since those omissions have a unique meaning and the same protection 289 is applied to the values as with ciphersuites, it is believed that 290 the security properties of this negotiation are the same as with 291 ciphersuite negotiation. 293 When using OpenPGP fingerprints instead of the full certificates, the 294 discussion in Section 6.3 of [I-D.ietf-tls-rfc4366-bis] for "Client 295 Certificate URLs" applies, especially when external servers are used 296 to retrieve keys. However, a major difference is that although the 297 "client_certificate_url" extension allows identifying certificates 298 without including the certificate hashes, this is not possible in the 299 protocol proposed here. In this protocol, the certificates, when not 300 sent, are always identified by their fingerprint, which serves as a 301 cryptographic hash of the certificate (see Section 12.2 of 302 [RFC4880]). 304 The information that is available to participating parties and 305 eavesdroppers (when confidentiality is not available through a 306 previous handshake) is the number and the types of certificates they 307 hold, plus the contents of certificates. 309 5. IANA Considerations 311 This document uses a registry and the "cert_type" extension 312 originally defined in [RFC5081]. Existing IANA references should be 313 updated to point to this document. 315 In addition the "TLS Certificate Types" registry established by 316 [RFC5081] has to be updated in the following way: 318 1. Values 0 (X.509) and 1 (OpenPGP) are defined in this document. 320 2. Values from 2 through 223 decimal inclusive are assigned via "RFC 321 Required" [RFC5226]. 323 3. Values from 224 decimal through 255 decimal inclusive are 324 reserved for Private Use [RFC5226]. 326 6. Acknowledgements 328 The authors wish to thank Alfred Hoenes and Ted Hardie for their 329 suggestions on improving this document. 331 7. References 333 7.1. Normative References 335 [RFC2119] Bradner, S., "Key words for use in RFCs 336 to Indicate Requirement Levels", BCP 14, 337 RFC 2119, March 1997. 339 [I-D.ietf-tls-rfc4366-bis] 3rd, D., "Transport Layer Security (TLS) 340 Extensions: Extension Definitions", 341 draft-ietf-tls-rfc4366-bis-10 (work in 342 progress), July 2010. 344 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., 345 Shaw, D., and R. Thayer, "OpenPGP Message 346 Format", RFC 4880, November 2007. 348 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines 349 for Writing an IANA Considerations 350 Section in RFCs", BCP 26, RFC 5226, 351 May 2008. 353 [RFC5246] Dierks, T. and E. Rescorla, "The 354 Transport Layer Security (TLS) Protocol 355 Version 1.2", RFC 5246, August 2008. 357 7.2. Informative References 359 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP 360 Keys for Transport Layer Security (TLS) 361 Authentication", RFC 5081, November 2007. 363 [RFC5280] Cooper, D., Santesson, S., Farrell, S., 364 Boeyen, S., Housley, R., and W. Polk, 365 "Internet X.509 Public Key Infrastructure 366 Certificate and Certificate Revocation 367 List (CRL) Profile", RFC 5280, May 2008. 369 Appendix A. Changes from RFC 5081 371 This document incorporates a major change in the "Server Certificate" 372 and "Client Certificate" TLS messages, that will make implementations 373 following this protocol incompatible with ones following [RFC5081]. 374 This change requires the subkey IDs used for TLS authentication to 375 marked explicitely in the handshake procedure. This was decided in 376 order to place no limitation on the OpenPGP certificates' contents 377 that can be used with with this protocol. 379 [RFC5081] required that an OpenPGP key or subkey was marked with the 380 authentication flag and thus would have failed if this flag was not 381 set, or this flag was set in more than one subkeys. The protocol in 382 this memo has no such limitation. 384 Authors' Addresses 386 Nikos Mavrogiannopoulos 387 ESAT/COSIC Katholieke Universiteit Leuven 388 Kasteelpark Arenberg 10, bus 2446 389 Leuven-Heverlee, B-3001 390 Belgium 392 EMail: nikos.mavrogiannopoulos@esat.kuleuven.be 394 Daniel Kahn Gillmor 395 Independent 396 119 Herkimer St 397 Brooklyn, NY 11216-2801 398 US 400 EMail: dkg@fifthhorseman.net