summaryrefslogtreecommitdiff
path: root/doc/protocol/draft-ietf-tls-openpgp-keys-11.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/protocol/draft-ietf-tls-openpgp-keys-11.txt')
-rw-r--r--doc/protocol/draft-ietf-tls-openpgp-keys-11.txt729
1 files changed, 729 insertions, 0 deletions
diff --git a/doc/protocol/draft-ietf-tls-openpgp-keys-11.txt b/doc/protocol/draft-ietf-tls-openpgp-keys-11.txt
new file mode 100644
index 0000000000..084e00c4b5
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-openpgp-keys-11.txt
@@ -0,0 +1,729 @@
+
+
+
+TLS Working Group N. Mavrogiannopoulos
+Internet-Draft Independent
+Expires: February 1, 2007 July 31, 2006
+
+
+ Using OpenPGP keys for TLS authentication
+ draft-ietf-tls-openpgp-keys-11
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on February 1, 2007.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This memo proposes extensions to the 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.
+
+
+
+
+
+
+
+
+Mavrogiannopoulos Expires February 1, 2007 [Page 1]
+
+Internet-Draft Using OpenPGP keys for TLS authentication July 2006
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Changes to the Handshake Message Contents . . . . . . . . . . 5
+ 3.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.3. Server Certificate . . . . . . . . . . . . . . . . . . . . 6
+ 3.4. Certificate request . . . . . . . . . . . . . . . . . . . 7
+ 3.5. Client certificate . . . . . . . . . . . . . . . . . . . . 7
+ 3.6. Other Handshake messages . . . . . . . . . . . . . . . . . 7
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
+ 6.2. Informative References . . . . . . . . . . . . . . . . . . 10
+ Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ Intellectual Property and Copyright Statements . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavrogiannopoulos Expires February 1, 2007 [Page 2]
+
+Internet-Draft Using OpenPGP keys for TLS authentication July 2006
+
+
+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, the 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavrogiannopoulos Expires February 1, 2007 [Page 3]
+
+Internet-Draft Using OpenPGP keys for TLS authentication July 2006
+
+
+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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavrogiannopoulos Expires February 1, 2007 [Page 4]
+
+Internet-Draft Using OpenPGP keys for TLS authentication July 2006
+
+
+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.
+
+
+ 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
+
+
+
+Mavrogiannopoulos Expires February 1, 2007 [Page 5]
+
+Internet-Draft Using OpenPGP keys for TLS authentication July 2006
+
+
+ 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 which can be used for
+ encryption.
+
+ DHE_DSS DSS public key which can be used for
+ authentication.
+
+ DHE_RSA RSA public key which 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 10.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 11.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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavrogiannopoulos Expires February 1, 2007 [Page 6]
+
+Internet-Draft Using OpenPGP keys for TLS authentication July 2006
+
+
+ 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.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+Mavrogiannopoulos Expires February 1, 2007 [Page 7]
+
+Internet-Draft Using OpenPGP keys for TLS authentication July 2006
+
+
+4. Security Considerations
+
+ All security considerations discussed in [TLS], [TLSEXT] as well as
+ [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 while the "client_certificate_url"
+ extension allows to identify 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 11.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 Expires February 1, 2007 [Page 8]
+
+Internet-Draft Using OpenPGP keys for TLS authentication July 2006
+
+
+5. IANA Considerations
+
+ This document defines a new TLS extension, "cert_type", assigned a
+ value of TBD-BY-IANA (the value 7 is suggested) 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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavrogiannopoulos Expires February 1, 2007 [Page 9]
+
+Internet-Draft Using OpenPGP keys for TLS authentication July 2006
+
+
+6. References
+
+6.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",
+ draft-ietf-openpgp-rfc2440bis-18 (work in progress),
+ May 2006.
+
+ [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.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997.
+
+6.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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavrogiannopoulos Expires February 1, 2007 [Page 10]
+
+Internet-Draft Using OpenPGP keys for TLS authentication July 2006
+
+
+Appendix A. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavrogiannopoulos Expires February 1, 2007 [Page 11]
+
+Internet-Draft Using OpenPGP keys for TLS authentication July 2006
+
+
+Author's Address
+
+ Nikos Mavrogiannopoulos
+ Independent
+ Arkadias 8
+ Halandri, Attiki 15234
+ Greece
+
+ Email: nmav@gnutls.org
+ URI: http://www.gnutls.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavrogiannopoulos Expires February 1, 2007 [Page 12]
+
+Internet-Draft Using OpenPGP keys for TLS authentication July 2006
+
+
+Intellectual Property Statement
+
+ 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.
+
+
+Disclaimer of Validity
+
+ 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 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.
+
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2006). 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.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Mavrogiannopoulos Expires February 1, 2007 [Page 13]
+
+
View Lorry Controller Status