idnits 2.17.1 draft-mavrogiannopoulos-rfc5081bis-02.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 345. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 369. 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 '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 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 26, 2008) is 5654 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 5081 (Obsoleted by RFC 6091) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) 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 Independent 4 Obsoletes: rfc5081 October 26, 2008 5 (if approved) 6 Intended status: Informational 7 Expires: April 29, 2009 9 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication 10 draft-mavrogiannopoulos-rfc5081bis-02 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 April 29, 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 . . . . . . . . . . . . . . . . . . . . . . . 7 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" to the extended 96 client hello message. The "cert_type" TLS extension is assigned the 97 value of 9 from the TLS ExtensionType registry. This value is used 98 as the extension number for the extensions in both the client hello 99 message and the server hello message. The hello extension mechanism 100 is described in [RFC4366]. 102 This extension carries a list of supported certificate types the 103 client can use, sorted by client preference. This extension MUST be 104 omitted if the client only supports X.509 certificates. The 105 "extension_data" field of this extension contains a 106 CertificateTypeExtension structure. 108 enum { client, server } ClientOrServerExtension; 110 enum { X.509(0), OpenPGP(1), (255) } CertificateType; 112 struct { 113 select(ClientOrServerExtension) { 114 case client: 115 CertificateType certificate_types<1..2^8-1>; 116 case server: 117 CertificateType certificate_type; 118 } 119 } CertificateTypeExtension; 121 No new cipher suites are required to use OpenPGP certificates. All 122 existing cipher suites that support a compatible, with the key, key 123 exchange method can be used in combination with OpenPGP certificates. 125 3.2. Server Hello 127 If the server receives a client hello that contains the "cert_type" 128 extension and chooses a cipher suite that requires a certificate, 129 then two outcomes are possible. The server MUST either select a 130 certificate type from the certificate_types field in the extended 131 client hello or terminate the session with a fatal alert of type 132 "unsupported_certificate". 134 The certificate type selected by the server is encoded in a 135 CertificateTypeExtension structure, which is included in the extended 136 server hello message using an extension of type "cert_type". Servers 137 that only support X.509 certificates MAY omit including the 138 "cert_type" extension in the extended server hello. 140 It is perfectly legal for a server to ignore this message. In that 141 case the normal TLS handshake should be used. Other certificate 142 types than the default MUST NOT be used. 144 3.3. Server Certificate 146 The contents of the certificate message sent from server to client 147 and vice versa are determined by the negotiated certificate type and 148 the selected cipher suite's key exchange algorithm. 150 If the OpenPGP certificate type is negotiated, then it is required to 151 present an OpenPGP certificate in the certificate message. The 152 certificate must contain a public key that matches the selected key 153 exchange algorithm, as shown below. 155 Key Exchange Algorithm OpenPGP Certificate Type 157 RSA RSA public key that can be used for 158 encryption. 160 DHE_DSS DSS public key that can be used for 161 authentication. 163 DHE_RSA RSA public key that can be used for 164 authentication. 166 An OpenPGP certificate appearing in the certificate message is sent 167 using the binary OpenPGP format. The certificate MUST contain all 168 the elements required by Section 11.1 of [RFC4880]. 170 OpenPGP certificates to be transferred are placed in the Certificate 171 structure and tagged with the OpenPGPCertDescriptorType 172 "subkey_cert". Since those certificates might contain several 173 subkeys the subkey to be used for this session is explicitely 174 specified in the OpenPGPKeyID field, even if the certificate has a 175 single subkey. The peer once receiving this type has to either use 176 the specified subkey or terminate the session with a fatal alert of 177 "unsupported_certificate". 179 The option is also available to send an OpenPGP fingerprint, instead 180 of sending the entire certificate, by using the 181 "subkey_cert_fingerprint" tag. This tag uses the 182 OpenPGPSubKeyFingerprint structure and requires the subkey ID to be 183 specified as well. The peer shall respond with a 184 "certificate_unobtainable" fatal alert if the certificate with the 185 given fingerprint cannot be found. The "certificate_unobtainable" 186 fatal alert is defined in Section 4 of [RFC4366]. 188 The process of fingerprint generation is described in Section 12.2 of 189 [RFC4880]. 191 The types "cert_fingerprint" and "cert" of OpenPGPCertDescriptorType 192 that were defined in [RFC5081] are not used and are marked as 193 obsolete by this document. 195 enum { 196 empty_cert (1), subkey_cert (2), subkey_cert_fingerprint (3), 197 (255) 198 } OpenPGPCertDescriptorType; 200 uint24 OpenPGPEmptyCert = 0; 202 struct { 203 opaque OpenPGPKeyID<1..8>; 204 opaque OpenPGPCert<0..2^24-1>; 205 } OpenPGPSubKeyCert; 207 struct { 208 opaque OpenPGPKeyID<1..8>; 209 opaque OpenPGPCertFingerprint<16..20>; 210 } OpenPGPSubKeyFingerprint; 212 struct { 213 OpenPGPCertDescriptorType descriptorType; 214 select (descriptorType) { 215 case empty_cert: OpenPGPEmptyCert; 216 case subkey_cert: OpenPGPSubKeyCert; 217 case subkey_cert_fingerprint: 218 OpenPGPSubKeyCertFingerprint; 219 } 220 } Certificate; 222 3.4. Certificate Request 224 The semantics of this message remain the same as in the TLS 225 specification. However, if this message is sent, and the negotiated 226 certificate type is OpenPGP, the "certificate_authorities" list MUST 227 be empty. 229 3.5. Client Certificate 231 This message is only sent in response to the certificate request 232 message. The client certificate message is sent using the same 233 formatting as the server certificate message, and it is also required 234 to present a certificate that matches the negotiated certificate 235 type. If OpenPGP certificates have been selected and no certificate 236 is available from the client, then a certificate structure of type 237 "empty_cert" that contains an OpenPGPEmptyCert value MUST be sent. 238 The server SHOULD respond with a "handshake_failure" fatal alert if 239 client authentication is required. 241 3.6. Other Handshake Messages 243 All the other handshake messages are identical to the TLS 244 specification. 246 4. Security Considerations 248 All security considerations discussed in [RFC4346], [RFC4366], and 249 [RFC4880] apply to this document. Considerations about the use of 250 the web of trust or identity and certificate verification procedure 251 are outside the scope of this document. These are considered issues 252 to be handled by the application layer protocols. 254 The protocol for certificate type negotiation is identical in 255 operation to ciphersuite negotiation of the [RFC4346] specification 256 with the addition of default values when the extension is omitted. 257 Since those omissions have a unique meaning and the same protection 258 is applied to the values as with ciphersuites, it is believed that 259 the security properties of this negotiation are the same as with 260 ciphersuite negotiation. 262 When using OpenPGP fingerprints instead of the full certificates, the 263 discussion in Section 6.3 of [RFC4366] for "Client Certificate URLs" 264 applies, especially when external servers are used to retrieve keys. 265 However, a major difference is that although the 266 "client_certificate_url" extension allows identifying certificates 267 without including the certificate hashes, this is not possible in the 268 protocol proposed here. In this protocol, the certificates, when not 269 sent, are always identified by their fingerprint, which serves as a 270 cryptographic hash of the certificate (see Section 12.2 of 271 [RFC4880]). 273 The information that is available to participating parties and 274 eavesdroppers (when confidentiality is not available through a 275 previous handshake) is the number and the types of certificates they 276 hold, plus the contents of certificates. 278 5. IANA Considerations 280 This document uses a registry originally defined in [RFC5081] and no 281 new actions are required by IANA. 283 6. Acknowledgements 285 This document was based on earlier work made by Will Price and 286 Michael Elkins. 288 The author wishes to thank Werner Koch, David Taylor, Timo Schulz, 289 Pasi Eronen, Jon Callas, Stephen Kent, Robert Sparks, and Hilarie 290 Orman for their suggestions on improving this document. 292 7. References 294 7.1. Normative References 296 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 297 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 299 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 300 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 302 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport 303 Layer Security (TLS) Authentication", RFC 5081, 304 November 2007. 306 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 307 and T. Wright, "Transport Layer Security (TLS) 308 Extensions", RFC 4366, April 2006. 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, March 1997. 313 7.2. Informative References 315 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 316 Housley, R., and W. Polk, "Internet X.509 Public Key 317 Infrastructure Certificate and Certificate Revocation List 318 (CRL) Profile", RFC 5280, May 2008. 320 Author's Address 322 Nikos Mavrogiannopoulos 323 Independent 324 Arkadias 8 325 Halandri, Attiki 15234 326 Greece 328 EMail: nmav@gnutls.org 329 URI: http://www.gnutls.org/ 331 Full Copyright Statement 333 Copyright (C) The IETF Trust (2008). 335 This document is subject to the rights, licenses and restrictions 336 contained in BCP 78, and except as set forth therein, the authors 337 retain all their rights. 339 This document and the information contained herein are provided on an 340 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 341 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 342 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 343 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 344 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 345 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 347 Intellectual Property 349 The IETF takes no position regarding the validity or scope of any 350 Intellectual Property Rights or other rights that might be claimed to 351 pertain to the implementation or use of the technology described in 352 this document or the extent to which any license under such rights 353 might or might not be available; nor does it represent that it has 354 made any independent effort to identify any such rights. Information 355 on the procedures with respect to rights in RFC documents can be 356 found in BCP 78 and BCP 79. 358 Copies of IPR disclosures made to the IETF Secretariat and any 359 assurances of licenses to be made available, or the result of an 360 attempt made to obtain a general license or permission for the use of 361 such proprietary rights by implementers or users of this 362 specification can be obtained from the IETF on-line IPR repository at 363 http://www.ietf.org/ipr. 365 The IETF invites any interested party to bring to its attention any 366 copyrights, patents or patent applications, or other proprietary 367 rights that may cover technology that may be required to implement 368 this standard. Please address the information to the IETF at 369 ietf-ipr@ietf.org.