From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6091.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc6091.txt (limited to 'doc/rfc/rfc6091.txt') diff --git a/doc/rfc/rfc6091.txt b/doc/rfc/rfc6091.txt new file mode 100644 index 0000000..43fd24f --- /dev/null +++ b/doc/rfc/rfc6091.txt @@ -0,0 +1,507 @@ + + + + + + +Internet Engineering Task Force (IETF) N. Mavrogiannopoulos +Request for Comments: 6091 KUL +Obsoletes: 5081 D. Gillmor +Category: Informational Independent +ISSN: 2070-1721 February 2011 + + + Using OpenPGP Keys for Transport Layer Security (TLS) Authentication + +Abstract + + This memo defines Transport Layer Security (TLS) extensions and + associated semantics that allow clients and servers to negotiate the + use of OpenPGP certificates for a TLS session, and specifies how to + transport OpenPGP certificates via TLS. It also defines the registry + for non-X.509 certificate types. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6091. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + +Mavrogiannopoulos & Gillmor Informational [Page 1] + +RFC 6091 Using OpenPGP Keys February 2011 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology .....................................................2 + 3. Changes to the Handshake Message Contents .......................3 + 3.1. Client Hello ...............................................3 + 3.2. Server Hello ...............................................4 + 3.3. Server Certificate .........................................4 + 3.4. Certificate Request ........................................6 + 3.5. Client Certificate .........................................6 + 3.6. Other Handshake Messages ...................................7 + 4. Security Considerations .........................................7 + 5. IANA Considerations .............................................7 + 6. Acknowledgements ................................................8 + 7. References ......................................................8 + 7.1. Normative References .......................................8 + 7.2. Informative References .....................................8 + Appendix A. Changes from RFC 5081 .................................9 + +1. Introduction + + The IETF has two sets of standards for public key certificates: one + set for the use of X.509 certificates [RFC5280], and one for OpenPGP + certificates [RFC4880]. At the time of this writing, TLS [RFC5246] + standards are defined to use X.509 certificates. This document + specifies a way to negotiate the use of OpenPGP certificates for a + TLS session, and specifies how to transport OpenPGP certificates via + TLS. The proposed extensions are backward-compatible with the + current TLS specification, so that existing client and server + implementations that make use of X.509 certificates are not affected. + + These extensions are not backward-compatible with [RFC5081], and the + major differences are summarized in Appendix A. Although the OpenPGP + CertificateType value is being reused by this memo with the same + number as that specified in [RFC5081] but with different semantics, + we believe that this causes no interoperability issues because the + latter was not widely deployed. + +2. Terminology + + The term "OpenPGP key" is used in this document as in the OpenPGP + specification [RFC4880]. We use the term "OpenPGP certificate" to + refer to OpenPGP keys that are enabled for authentication. + + This document uses the same notation and terminology used in the TLS + Protocol specification [RFC5246]. + + + + + +Mavrogiannopoulos & Gillmor Informational [Page 2] + +RFC 6091 Using OpenPGP Keys February 2011 + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Changes to the Handshake Message Contents + + This section describes the changes to the TLS handshake message + contents when OpenPGP certificates are to be used for authentication. + +3.1. Client Hello + + In order to indicate the support of multiple certificate types, + clients MUST include an extension of type "cert_type" to the extended + client hello message. The "cert_type" TLS extension is assigned the + value of 9 from the TLS ExtensionType registry. This value is used + as the extension number for the extensions in both the client hello + message and the server hello message. The hello extension mechanism + is described in [RFC5246]. + + This extension carries a list of supported certificate types the + client can use, sorted by client preference. This extension MUST be + omitted if the client only supports X.509 certificates. The + "extension_data" field of this extension contains a + CertificateTypeExtension structure. Note that the + CertificateTypeExtension structure is being used both by the client + and the server, even though the structure is only specified once in + this document. Reusing a single specification for both client and + server is common in other specifications, such as the TLS protocol + itself [RFC5246]. + + enum { client, server } ClientOrServerExtension; + + enum { X.509(0), OpenPGP(1), (255) } CertificateType; + + struct { + select(ClientOrServerExtension) { + case client: + CertificateType certificate_types<1..2^8-1>; + case server: + CertificateType certificate_type; + } + } CertificateTypeExtension; + + No new cipher suites are required to use OpenPGP certificates. All + existing cipher suites that support a key exchange method compatible + with the key in the certificate can be used in combination with + OpenPGP certificates. + + + + +Mavrogiannopoulos & Gillmor Informational [Page 3] + +RFC 6091 Using OpenPGP Keys February 2011 + + +3.2. Server Hello + + If the server receives a client hello that contains the "cert_type" + extension and chooses a cipher suite that requires a certificate, + then two outcomes are possible. The server MUST either select a + certificate type from the certificate_types field in the extended + client hello or terminate the session with a fatal alert of type + "unsupported_certificate". + + The certificate type selected by the server is encoded in a + CertificateTypeExtension structure, which is included in the extended + server hello message using an extension of type "cert_type". Servers + that only support X.509 certificates MAY omit including the + "cert_type" extension in the extended server hello. + +3.3. Server Certificate + + The contents of the certificate message sent from server to client + and vice versa are determined by the negotiated certificate type and + the selected cipher suite's key exchange algorithm. + + If the OpenPGP certificate type is negotiated, then it is required to + present an OpenPGP certificate in the certificate message. The + certificate must contain a public key that matches the selected key + exchange algorithm, as shown below. + + Key Exchange Algorithm OpenPGP Certificate Type + + RSA RSA public key that can be used for + encryption. + + DHE_DSS DSA public key that can be used for + authentication. + + DHE_RSA RSA public key that can be used for + authentication. + + An OpenPGP certificate appearing in the certificate message is sent + using the binary OpenPGP format. The certificate MUST contain all + the elements required by Section 11.1 of [RFC4880]. + + OpenPGP certificates to be transferred are placed in the Certificate + structure and tagged with the OpenPGPCertDescriptorType + "subkey_cert". Since those certificates might contain several + subkeys, the subkey ID to be used for this session is explicitly + + + + + + +Mavrogiannopoulos & Gillmor Informational [Page 4] + +RFC 6091 Using OpenPGP Keys February 2011 + + + specified in the OpenPGPKeyID field. The key ID must be specified + even if the certificate has only a primary key. The peer, upon + receiving this type, has to either use the specified subkey or + terminate the session with a fatal alert of + "unsupported_certificate". + + The option is also available to send an OpenPGP fingerprint, instead + of sending the entire certificate, by using the + "subkey_cert_fingerprint" tag. This tag uses the + OpenPGPSubKeyFingerprint structure and requires the primary key + fingerprint to be specified, as well as the subkey ID to be used for + this session. The peer shall respond with a + "certificate_unobtainable" fatal alert if the certificate with the + given fingerprint cannot be found. The "certificate_unobtainable" + fatal alert is defined in Section 5 of [RFC6066]. + + Implementations of this protocol MUST ensure that the sizes of key + IDs and fingerprints in the OpenPGPSubKeyCert and + OpenPGPSubKeyFingerprint structures comply with [RFC4880]. Moreover, + it is RECOMMENDED that the keys to be used with this protocol have + the authentication flag (0x20) set. + + The process of fingerprint generation is described in Section 12.2 of + [RFC4880]. + + The enumerated types "cert_fingerprint" and "cert" of + OpenPGPCertDescriptorType that were defined in [RFC5081] are not used + and are marked as obsolete by this document. The "empty_cert" type + has replaced "cert" and is a backward-compatible way to specify an + empty certificate; "cert_fingerprint" MUST NOT be used with this + updated specification, and hence that old alternative has been + removed from the Certificate struct description. + + + + + + + + + + + + + + + + + + + +Mavrogiannopoulos & Gillmor Informational [Page 5] + +RFC 6091 Using OpenPGP Keys February 2011 + + + enum { + empty_cert(1), + subkey_cert(2), + subkey_cert_fingerprint(3), + (255) + } OpenPGPCertDescriptorType; + + uint24 OpenPGPEmptyCert = 0; + + struct { + opaque OpenPGPKeyID<8..255>; + opaque OpenPGPCert<0..2^24-1>; + } OpenPGPSubKeyCert; + + struct { + opaque OpenPGPKeyID<8..255>; + opaque OpenPGPCertFingerprint<20..255>; + } OpenPGPSubKeyFingerprint; + + struct { + OpenPGPCertDescriptorType descriptorType; + select (descriptorType) { + case empty_cert: OpenPGPEmptyCert; + case subkey_cert: OpenPGPSubKeyCert; + case subkey_cert_fingerprint: + OpenPGPSubKeyCertFingerprint; + } + } Certificate; + +3.4. Certificate Request + + The semantics of this message remain the same as in the TLS + specification. However, if this message is sent, and the negotiated + certificate type is OpenPGP, the "certificate_authorities" list MUST + be empty. + +3.5. Client Certificate + + This message is only sent in response to the certificate request + message. The client certificate message is sent using the same + formatting as the server certificate message, and it is also required + to present a certificate that matches the negotiated certificate + type. If OpenPGP certificates have been selected and no certificate + is available from the client, then a certificate structure of type + "empty_cert" that contains an OpenPGPEmptyCert value MUST be sent. + The server SHOULD respond with a "handshake_failure" fatal alert if + client authentication is required. + + + + +Mavrogiannopoulos & Gillmor Informational [Page 6] + +RFC 6091 Using OpenPGP Keys February 2011 + + +3.6. Other Handshake Messages + + All the other handshake messages are identical to the TLS + specification. + +4. Security Considerations + + All security considerations discussed in [RFC5246], [RFC6066], and + [RFC4880] apply to this document. Considerations about the use of + the web of trust or identity and certificate verification procedures + are outside the scope of this document. These are considered issues + to be handled by the application layer protocols. + + The protocol for certificate type negotiation is identical in + operation to cipher suite negotiation as described in the TLS + specification [RFC5246], with the addition of default values when the + extension is omitted. Since those omissions have a unique meaning + and the same protection is applied to the values as with cipher + suites, it is believed that the security properties of this + negotiation are the same as with cipher suite negotiation. + + When using OpenPGP fingerprints instead of the full certificates, the + discussion in Section 5 of [RFC6066] for "Client Certificate URLs" + applies, especially when external servers are used to retrieve keys. + However, a major difference is that although the + "client_certificate_url" extension allows identifying certificates + without including the certificate hashes, this is not possible in the + protocol proposed here. In this protocol, the certificates, when not + sent, are always identified by their fingerprint, which serves as a + cryptographic hash of the certificate (see Section 12.2 of + [RFC4880]). + + The information that is available to participating parties and + eavesdroppers (when confidentiality is not available through a + previous handshake) is the number and the types of certificates they + hold, plus the contents of the certificates. + +5. IANA Considerations + + This document uses a registry and the "cert_type" extension + originally defined in [RFC5081]. Existing IANA references have been + updated to point to this document. + + + + + + + + + +Mavrogiannopoulos & Gillmor Informational [Page 7] + +RFC 6091 Using OpenPGP Keys February 2011 + + + In addition, the "TLS Certificate Types" registry established by + [RFC5081] has been updated in the following ways: + + 1. Values 0 (X.509) and 1 (OpenPGP) are defined in this document. + + 2. Values from 2 through 223 decimal inclusive are assigned via "RFC + Required" [RFC5226]. + + 3. Values from 224 decimal through 255 decimal inclusive are + reserved for Private Use [RFC5226]. + +6. Acknowledgements + + The authors wish to thank Alfred Hoenes and Ted Hardie for their + suggestions on improving this document. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. + Thayer, "OpenPGP Message Format", RFC 4880, + November 2007. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) + Extensions: Extension Definitions", RFC 6066, + January 2011. + +7.2. Informative References + + [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport + Layer Security (TLS) Authentication", RFC 5081, + November 2007. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation + List (CRL) Profile", RFC 5280, May 2008. + + + +Mavrogiannopoulos & Gillmor Informational [Page 8] + +RFC 6091 Using OpenPGP Keys February 2011 + + +Appendix A. Changes from RFC 5081 + + This document incorporates a major change in the "Server Certificate" + and "Client Certificate" TLS messages that will make implementations + following this protocol incompatible with those following [RFC5081]. + This change requires the subkey IDs used for TLS authentication to be + marked explicitly in the handshake procedure. This was decided in + order to place no limitation on the OpenPGP certificates' contents + that can be used with this protocol. + + [RFC5081] required that an OpenPGP key or subkey be marked with the + authentication flag; thus, authentication would have failed if this + flag was not set or if this flag was set in more than one subkey. + The protocol in this memo has no such limitation. + +Authors' Addresses + + Nikos Mavrogiannopoulos + ESAT/COSIC Katholieke Universiteit Leuven + Kasteelpark Arenberg 10, bus 2446 + Leuven-Heverlee, B-3001 + Belgium + + EMail: nikos.mavrogiannopoulos@esat.kuleuven.be + + + Daniel Kahn Gillmor + Independent + 119 Herkimer St. + Brooklyn, NY 11216-2801 + US + + EMail: dkg@fifthhorseman.net + + + + + + + + + + + + + + + + + + +Mavrogiannopoulos & Gillmor Informational [Page 9] + -- cgit v1.2.3