Add.

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/protocol/rfc5081.txt b/doc/protocol/rfc5081.txt
new file mode 100644
index 0000000000..0d2be0997d
--- /dev/null
+++ b/doc/protocol/rfc5081.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                               N. Mavrogiannopoulos
+Request for Comments: 5081                                   Independent
+Category: Experimental                                     November 2007
+
+
+  Using OpenPGP Keys for Transport Layer Security (TLS) Authentication
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   This memo proposes extensions to the Transport Layer Security (TLS)
+   protocol to support the OpenPGP key format.  The extensions discussed
+   here include a certificate type negotiation mechanism, and the
+   required modifications to the TLS Handshake Protocol.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Terminology .....................................................2
+   3. Changes to the Handshake Message Contents .......................2
+      3.1. Client Hello ...............................................2
+      3.2. Server Hello ...............................................3
+      3.3. Server Certificate .........................................3
+      3.4. Certificate Request ........................................4
+      3.5. Client Certificate .........................................5
+      3.6. Other Handshake Messages ...................................5
+   4. Security Considerations .........................................5
+   5. IANA Considerations .............................................6
+   6. Acknowledgements ................................................6
+   7. References ......................................................6
+      7.1. Normative References .......................................6
+      7.2. Informative References .....................................7
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavrogiannopoulos             Experimental                      [Page 1]
+
+RFC 5081                   Using OpenPGP Keys              November 2007
+
+
+1.  Introduction
+
+   The IETF has two sets of standards for public key certificates, one
+   set for use of X.509 certificates [PKIX] and one for OpenPGP
+   certificates [OpenPGP].  At the time of writing, TLS [TLS] standards
+   are defined to use only X.509 certificates.  This document specifies
+   a way to negotiate 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.
+
+2.  Terminology
+
+   The term "OpenPGP key" is used in this document as in the OpenPGP
+   specification [OpenPGP].  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 [TLS].
+
+   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" (see Section 5)
+   to the extended client hello message.  The hello extension mechanism
+   is described in [TLSEXT].
+
+   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.
+
+
+
+
+
+
+
+
+
+Mavrogiannopoulos             Experimental                      [Page 2]
+
+RFC 5081                   Using OpenPGP Keys              November 2007
+
+
+      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 compatible, with the key, key
+   exchange method can be used in combination with OpenPGP certificates.
+
+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 connection 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.
+
+
+
+
+
+
+
+
+
+Mavrogiannopoulos             Experimental                      [Page 3]
+
+RFC 5081                   Using OpenPGP Keys              November 2007
+
+
+      Key Exchange Algorithm  OpenPGP Certificate Type
+
+      RSA                     RSA public key that can be used for
+                              encryption.
+
+      DHE_DSS                 DSS 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 [OpenPGP].
+
+   The option is also available to send an OpenPGP fingerprint, instead
+   of sending the entire certificate.  The process of fingerprint
+   generation is described in Section 12.2 of [OpenPGP].  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 4 of
+   [TLSEXT].
+
+      enum {
+           cert_fingerprint (0), cert (1), (255)
+      } OpenPGPCertDescriptorType;
+
+      opaque OpenPGPCertFingerprint<16..20>;
+
+      opaque OpenPGPCert<0..2^24-1>;
+
+      struct {
+           OpenPGPCertDescriptorType descriptorType;
+           select (descriptorType) {
+                case cert_fingerprint: OpenPGPCertFingerprint;
+                case cert: OpenPGPCert;
+           }
+      } 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.
+
+
+
+
+
+
+Mavrogiannopoulos             Experimental                      [Page 4]
+
+RFC 5081                   Using OpenPGP Keys              November 2007
+
+
+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 that
+   contains an empty OpenPGPCert vector MUST be sent.  The server SHOULD
+   respond with a "handshake_failure" fatal alert if client
+   authentication is required.
+
+3.6.  Other Handshake Messages
+
+   All the other handshake messages are identical to the TLS
+   specification.
+
+4.  Security Considerations
+
+   All security considerations discussed in [TLS], [TLSEXT], and
+   [OpenPGP] apply to this document.  Considerations about the use of
+   the web of trust or identity and certificate verification procedure
+   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 ciphersuite negotiation of the [TLS] specification 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 ciphersuites, it is believed that the
+   security properties of this negotiation are the same as with
+   ciphersuite negotiation.
+
+   When using OpenPGP fingerprints instead of the full certificates, the
+   discussion in Section 6.3 of [TLSEXT] 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
+   [OpenPGP]).
+
+   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 certificates.
+
+
+
+Mavrogiannopoulos             Experimental                      [Page 5]
+
+RFC 5081                   Using OpenPGP Keys              November 2007
+
+
+5.  IANA Considerations
+
+   This document defines a new TLS extension, "cert_type", assigned a
+   value of 9 from the TLS ExtensionType registry defined in [TLSEXT].
+   This value is used as the extension number for the extensions in both
+   the client hello message and the server hello message.  The new
+   extension type is used for certificate type negotiation.
+
+   The "cert_type" extension contains an 8-bit CertificateType field,
+   for which a new registry, named "TLS Certificate Types", is
+   established in this document, to be maintained by IANA.  The registry
+   is segmented in the following way:
+
+   1.  Values 0 (X.509) and 1 (OpenPGP) are defined in this document.
+
+   2.  Values from 2 through 223 decimal inclusive are assigned via IETF
+       Consensus [RFC2434].
+
+   3.  Values from 224 decimal through 255 decimal inclusive are
+       reserved for Private Use [RFC2434].
+
+6.  Acknowledgements
+
+   This document was based on earlier work made by Will Price and
+   Michael Elkins.
+
+   The author wishes to thank Werner Koch, David Taylor, Timo Schulz,
+   Pasi Eronen, Jon Callas, Stephen Kent, Robert Sparks, and Hilarie
+   Orman for their suggestions on improving this document.
+
+7.  References
+
+7.1.  Normative References
+
+   [TLS]      Dierks, T. and E. Rescorla, "The TLS Protocol Version
+              1.1", RFC 4346, April 2006.
+
+   [OpenPGP]  Callas, J., Donnerhacke, L., Finey, H., Shaw, D., and R.
+              Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
+
+   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
+              and T. Wright, "Transport Layer Security (TLS)
+              Extensions", RFC 4366, April 2006.
+
+   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", RFC 2434,
+              October 1998.
+
+
+
+
+Mavrogiannopoulos             Experimental                      [Page 6]
+
+RFC 5081                   Using OpenPGP Keys              November 2007
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", RFC 2119, March 1997.
+
+7.2.  Informative References
+
+   [PKIX]     Housley, R., Ford, W., Polk, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+Author's Address
+
+   Nikos Mavrogiannopoulos
+   Independent
+   Arkadias 8
+   Halandri, Attiki  15234
+   Greece
+
+   EMail: nmav@gnutls.org
+   URI:   http://www.gnutls.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavrogiannopoulos             Experimental                      [Page 7]
+
+RFC 5081                   Using OpenPGP Keys              November 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Mavrogiannopoulos             Experimental                      [Page 8]
+