doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

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]
+