--- /dev/null
+
+
+TLS Working Group N. Mavroyanopoulos
+Internet-Draft April 2, 2004
+Expires: October 1, 2004
+
+
+ Using OpenPGP keys for TLS authentication
+ draft-ietf-tls-openpgp-keys-05
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ 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 October 1, 2004.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This memo proposes extensions to the TLS protocol to support the
+ OpenPGP trust model and keys. The extensions discussed here include
+ a certificate type negotiation mechanism, and the required
+ modifications to the TLS Handshake Protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires October 1, 2004 [Page 1]
+\f
+Internet-Draft Using OpenPGP keys for TLS authentication April 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Extension Type . . . . . . . . . . . . . . . . . . . . . . . . 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 Server key exchange . . . . . . . . . . . . . . . . . . . . . 8
+ 3.7 Certificate verify . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.8 Finished . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4. Cipher suites . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 5. Internationalization Considerations . . . . . . . . . . . . . 10
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
+ Normative References . . . . . . . . . . . . . . . . . . . . . 12
+ Informative References . . . . . . . . . . . . . . . . . . . . 13
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
+ A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
+ Intellectual Property and Copyright Statements . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires October 1, 2004 [Page 2]
+\f
+Internet-Draft Using OpenPGP keys for TLS authentication April 2004
+
+
+1. Introduction
+
+ At the time of writing, TLS [1] uses the PKIX [6] infrastructure, to
+ provide certificate services. Currently the PKIX protocols are
+ limited to a hierarchical key management and as a result,
+ applications which follow different - non hierarchical - trust
+ models, like the "web of trust" model, could not be benefited by TLS.
+
+ OpenPGP keys (sometimes called OpenPGP certificates), provide
+ security services for electronic communications. They are widely
+ deployed, especially in electronic mail applications, provide public
+ key authentication services, and allow distributed key management.
+
+ This document will extend the TLS protocol to support OpenPGP keys
+ and trust model using the existing TLS cipher suites. In brief this
+ would be achieved by adding a negotiation of the certificate type in
+ addition to the normal handshake negotiations. Then the required
+ modifications to the handshake messages, in order to hold OpenPGP
+ keys as well, will be described. The the normal handshake procedure
+ with X.509 certificates will not be altered, to preserve
+ compatibility with existing TLS servers and clients.
+
+ This document uses the same notation used in the TLS Protocol
+ specification.
+
+ 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 RFC 2119.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires October 1, 2004 [Page 3]
+\f
+Internet-Draft Using OpenPGP keys for TLS authentication April 2004
+
+
+2. Extension Type
+
+ A new value, "cert_type(7)", is added to the enumerated
+ ExtensionType, defined in TLSEXT [3]. This value is used as the
+ extension number for the extensions in both the client hello message
+ and the server hello message. This new extension type will be used
+ for certificate type negotiation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires October 1, 2004 [Page 4]
+\f
+Internet-Draft Using OpenPGP keys for TLS authentication April 2004
+
+
+3. Changes to the Handshake Message Contents
+
+ This section describes the changes to the TLS handshake message
+ contents when OpenPGP keys are to be used for authentication.
+
+3.1 Client Hello
+
+ In order to indicate the support of multiple certificate types
+ clients will include an extension of type "cert_type" to the extended
+ client hello message. The hello extension mechanism is described in
+ TLSEXT [3].
+
+ This extension carries a list of supported certificate types the
+ client can use, sorted by client preference. This extension MAY be
+ omitted if the client only supports X.509 certificates. The
+ "extension_data" field of this extension will contain 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;
+
+
+3.2 Server Hello
+
+ Servers that receive an extended client hello containing the
+ "cert_type" extension, and have chosen a cipher suite that supports
+ certificates, then they MUST 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.
+
+
+
+
+
+Mavroyanopoulos Expires October 1, 2004 [Page 5]
+\f
+Internet-Draft Using OpenPGP keys for TLS authentication April 2004
+
+
+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 key in the Certificate message. The OpenPGP key
+ must contain a public key that matches the selected key exchange
+ algorithm, as shown below.
+
+
+ Key Exchange Algorithm OpenPGP Key Type
+
+ RSA RSA public key which can be used for
+ encryption.
+
+ DHE_DSS DSS public key.
+
+ DHE_RSA RSA public key which can be used for
+ signing.
+
+ An OpenPGP public key appearing in the Certificate message will be
+ sent using the binary OpenPGP format. The term public key is used to
+ describe a composition of OpenPGP packets to form a block of data
+ which contains all information needed by the peer. This includes
+ public key packets, user ID packets and all the fields described in
+ "Transferable Public Keys" section in OpenPGP [2].
+
+ The option is also available to send an OpenPGP fingerprint, instead
+ of sending the entire key. The process of fingerprint generation is
+ described in OpenPGP [2]. The peer shall respond with a
+ "certificate_unobtainable" fatal alert if the key with the given key
+ fingerprint cannot be found. The "certificate_unobtainable" fatal
+ alert is defined in section 4 of TLSEXT [3].
+
+ If the key is not valid, expired, revoked, corrupt, the appropriate
+ fatal alert message is sent from section A.3 of the TLS
+ specification. If a key is valid and neither expired nor revoked, it
+ is accepted by the protocol. The key validation procedure is a local
+ matter outside the scope of this document.
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires October 1, 2004 [Page 6]
+\f
+Internet-Draft Using OpenPGP keys for TLS authentication April 2004
+
+
+ enum {
+ key_fingerprint (0), key (1), (255)
+ } PGPKeyDescriptorType;
+
+ opaque PGPKeyFingerprint<16..20>;
+
+ opaque PGPKey<0..2^24-1>;
+
+ struct {
+ PGPKeyDescriptorType descriptorType;
+ select (descriptorType) {
+ case key_fingerprint: PGPKeyFingerprint;
+ case key: PGPKey;
+ }
+ } Certificate;
+
+
+3.4 Certificate request
+
+ The semantics of this message remain the same as in the TLS
+ specification. However the structure of this message has been
+ modified for OpenPGP keys. The PGPCertificateRequest structure will
+ only be used if the negotiated certificate type is OpenPGP.
+
+
+ enum {
+ rsa_sign(1), dss_sign(2), (255)
+ } ClientCertificateParamsType;
+
+ struct {
+ ClientCertificateParamsType certificate_params_types<1..2^8-1>;
+ } PGPCertificateRequest;
+
+ The certificate_params_types is a list of accepted client certificate
+ parameter types, sorted in order of the server's preference.
+
+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 keys have been selected, and no key is available
+ from the client, then a Certificate that contains an empty PGPKey
+ should be sent. The server may respond with a "handshake_failure"
+ fatal alert if client authentication is required. This transaction
+ follows the TLS specification.
+
+
+
+
+Mavroyanopoulos Expires October 1, 2004 [Page 7]
+\f
+Internet-Draft Using OpenPGP keys for TLS authentication April 2004
+
+
+3.6 Server key exchange
+
+ The server key exchange message for OpenPGP keys is identical to the
+ TLS specification.
+
+3.7 Certificate verify
+
+ The certificate verify message for OpenPGP keys is identical to the
+ TLS specification.
+
+3.8 Finished
+
+ The finished message for OpenPGP keys is identical to the description
+ in the specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires October 1, 2004 [Page 8]
+\f
+Internet-Draft Using OpenPGP keys for TLS authentication April 2004
+
+
+4. Cipher suites
+
+ No new cipher suites are required to use OpenPGP keys. OpenPGP keys
+ can be combined with existing cipher suites defined in TLS [1],
+ except the ones marked as "Exportable". Exportable cipher suites
+ SHOULD NOT be used with OpenPGP keys.
+
+ Some additional cipher suites are defined here in order to support
+ algorithms which are defined in OpenPGP [2], and are always available
+ in OpenPGP implementations but are not present in TLS [1].
+
+ CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_RMD = { 0x00, 0x72 };
+
+ CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_RMD = { 0x00, 0x73 };
+
+ CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_RMD = { 0x00, 0x74 };
+
+ CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_RMD = { 0x00, 0x77 };
+
+ CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_RMD = { 0x00, 0x78 };
+
+ CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_RMD = { 0x00, 0x79 };
+
+ CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_RMD = { 0x00, 0x7C };
+
+ CipherSuite TLS_RSA_WITH_AES_128_CBC_RMD = { 0x00, 0x7D };
+
+ CipherSuite TLS_RSA_WITH_AES_256_CBC_RMD = { 0x00, 0x7E };
+
+ All of the above cipher suites use either the AES [5] and 3DES block
+ ciphers in CBC mode. The choice of hash is the RIPEMD-160 [4]
+ algorithm. Implementations are not required to support the above
+ cipher suites.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires October 1, 2004 [Page 9]
+\f
+Internet-Draft Using OpenPGP keys for TLS authentication April 2004
+
+
+5. Internationalization Considerations
+
+ All the methods defined in this document are represented as machine
+ readable structures. As such issues of human internationalization and
+ localization are not introduced.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires October 1, 2004 [Page 10]
+\f
+Internet-Draft Using OpenPGP keys for TLS authentication April 2004
+
+
+6. Security Considerations
+
+ As with X.509 ASN.1 formatted keys, OpenPGP keys need specialized
+ parsers. Care must be taken to make those parsers safe against
+ maliciously modified keys, that may crash or modify the application's
+ memory.
+
+ Security considerations about the use of the web of trust or the
+ verification procedure are outside the scope of this document, since
+ they are considered a local policy matter.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires October 1, 2004 [Page 11]
+\f
+Internet-Draft Using OpenPGP keys for TLS authentication April 2004
+
+
+Normative References
+
+ [1] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
+ 1999.
+
+ [2] Callas, J., Donnerhacke, L., Finey, H. and R. Thayer, "OpenPGP
+ Message Format", RFC 2440, November 1998.
+
+ [3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T.
+ Wright, "TLS Extensions", RFC 3546, June 2003.
+
+ [4] Dobbertin, H., Bosselaers, A. and B. Preneel, "RIPEMD-160: A
+ Strengthened Version of RIPEMD", April 1996.
+
+ [5] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
+ Transport Layer Security (TLS)", RFC 3268, June 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires October 1, 2004 [Page 12]
+\f
+Internet-Draft Using OpenPGP keys for TLS authentication April 2004
+
+
+Informative References
+
+ [6] 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.
+
+ [7] "Recommendation X.509: The Directory - Authentication
+ Framework", 1988.
+
+
+Author's Address
+
+ Nikos Mavroyanopoulos
+
+ EMail: nmav@gnutls.org
+ URI: http://www.gnutls.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires October 1, 2004 [Page 13]
+\f
+Internet-Draft Using OpenPGP keys for TLS authentication April 2004
+
+
+Appendix A. Acknowledgements
+
+ The author wishes to thank Werner Koch, David Taylor and Timo Schulz
+ for their suggestions on improving this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires October 1, 2004 [Page 14]
+\f
+Internet-Draft Using OpenPGP keys for TLS authentication April 2004
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property 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; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication 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 implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+
+
+
+Mavroyanopoulos Expires October 1, 2004 [Page 15]
+\f
+Internet-Draft Using OpenPGP keys for TLS authentication April 2004
+
+
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires October 1, 2004 [Page 16]
+\f
+
--- /dev/null
+
+TLS Working Group N. Mavroyanopoulos
+Internet-Draft January 25, 2005
+Expires: July 26, 2005
+
+ Using OpenPGP keys for TLS authentication
+ draft-ietf-tls-openpgp-keys-06
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ 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 July 26, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ This memo proposes extensions to the TLS protocol to support the
+ OpenPGP trust model and keys. The extensions discussed here include
+ a certificate type negotiation mechanism, and the required
+ modifications to the TLS Handshake Protocol.
+
+
+
+
+Mavroyanopoulos Expires July 26, 2005 [Page 1]
+Internet-Draft Using OpenPGP keys for TLS authentication January 2005
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Extension Type . . . . . . . . . . . . . . . . . . . . . . . . 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 Server key exchange . . . . . . . . . . . . . . . . . . . 8
+ 3.7 Certificate verify . . . . . . . . . . . . . . . . . . . . 8
+ 3.8 Finished . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4. Cipher suites . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 5. Internationalization Considerations . . . . . . . . . . . . . 10
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 12
+ 7.2 Informative References . . . . . . . . . . . . . . . . . . . 12
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
+ A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
+ Intellectual Property and Copyright Statements . . . . . . . . 14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires July 26, 2005 [Page 2]
+Internet-Draft Using OpenPGP keys for TLS authentication January 2005
+
+1. Introduction
+
+ At the time of writing, TLS [1] uses the PKIX [6] infrastructure, to
+ provide certificate services. Currently the PKIX protocols are
+ limited to a hierarchical key management and as a result,
+ applications which follow different - non hierarchical - trust
+ models, like the "web of trust" model, could not be benefited by TLS.
+
+ OpenPGP keys (sometimes called OpenPGP certificates), provide
+ security services for electronic communications. They are widely
+ deployed, especially in electronic mail applications, provide public
+ key authentication services, and allow distributed key management.
+
+ This document will extend the TLS protocol to support OpenPGP keys
+ and trust model using the existing TLS cipher suites. In brief this
+ would be achieved by adding a negotiation of the certificate type in
+ addition to the normal handshake negotiations. Then the required
+ modifications to the handshake messages, in order to hold OpenPGP
+ keys as well, will be described. The the normal handshake procedure
+ with X.509 certificates will not be altered, to preserve
+ compatibility with existing TLS servers and clients.
+
+ This document uses the same notation used in the TLS Protocol
+ specification.
+
+ 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 RFC 2119.
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires July 26, 2005 [Page 3]
+Internet-Draft Using OpenPGP keys for TLS authentication January 2005
+
+2. Extension Type
+
+ A new value, "cert_type(7)", is added to the enumerated
+ ExtensionType, defined in TLSEXT [3]. This value is used as the
+ extension number for the extensions in both the client hello message
+ and the server hello message. This new extension type will be used
+ for certificate type negotiation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires July 26, 2005 [Page 4]
+Internet-Draft Using OpenPGP keys for TLS authentication January 2005
+
+3. Changes to the Handshake Message Contents
+
+ This section describes the changes to the TLS handshake message
+ contents when OpenPGP keys are to be used for authentication.
+
+3.1 Client Hello
+
+ In order to indicate the support of multiple certificate types
+ clients will include an extension of type "cert_type" to the extended
+ client hello message. The hello extension mechanism is described in
+ TLSEXT [3].
+
+ This extension carries a list of supported certificate types the
+ client can use, sorted by client preference. This extension MAY be
+ omitted if the client only supports X.509 certificates. The
+ "extension_data" field of this extension will contain 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;
+
+3.2 Server Hello
+
+ Servers that receive an extended client hello containing the
+ "cert_type" extension, and have chosen a cipher suite that supports
+ certificates, then they MUST 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.
+
+
+
+Mavroyanopoulos Expires July 26, 2005 [Page 5]
+Internet-Draft Using OpenPGP keys for TLS authentication January 2005
+
+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 key in the Certificate message. The OpenPGP key
+ must contain a public key that matches the selected key exchange
+ algorithm, as shown below.
+
+ Key Exchange Algorithm OpenPGP Key Type
+
+ RSA RSA public key which can be used for
+ encryption.
+
+ DHE_DSS DSS public key.
+
+ DHE_RSA RSA public key which can be used for
+ signing.
+
+ An OpenPGP public key appearing in the Certificate message will be
+ sent using the binary OpenPGP format. The term public key is used to
+ describe a composition of OpenPGP packets to form a block of data
+ which contains all information needed by the peer. This includes
+ public key packets, user ID packets and all the fields described in
+ "Transferable Public Keys" section in OpenPGP [2].
+
+ The option is also available to send an OpenPGP fingerprint, instead
+ of sending the entire key. The process of fingerprint generation is
+ described in OpenPGP [2]. The peer shall respond with a
+ "certificate_unobtainable" fatal alert if the key with the given key
+ fingerprint cannot be found. The "certificate_unobtainable" fatal
+ alert is defined in section 4 of TLSEXT [3].
+
+ If the key is not valid, expired, revoked, corrupt, the appropriate
+ fatal alert message is sent from section A.3 of the TLS
+ specification. If a key is valid and neither expired nor revoked, it
+ is accepted by the protocol. The key validation procedure is a local
+ matter outside the scope of this document.
+
+
+
+
+
+Mavroyanopoulos Expires July 26, 2005 [Page 6]
+Internet-Draft Using OpenPGP keys for TLS authentication January 2005
+
+ enum {
+ key_fingerprint (0), key (1), (255)
+ } PGPKeyDescriptorType;
+
+ opaque PGPKeyFingerprint<16..20>;
+
+ opaque PGPKey<0..2^24-1>;
+
+ struct {
+ PGPKeyDescriptorType descriptorType;
+ select (descriptorType) {
+ case key_fingerprint: PGPKeyFingerprint;
+ case key: PGPKey;
+ }
+ } Certificate;
+
+3.4 Certificate request
+
+ The semantics of this message remain the same as in the TLS
+ specification. However the structure of this message has been
+ modified for OpenPGP keys. The PGPCertificateRequest structure will
+ only be used if the negotiated certificate type is OpenPGP.
+
+ enum {
+ rsa_sign(1), dss_sign(2), (255)
+ } ClientCertificateParamsType;
+
+ struct {
+ ClientCertificateParamsType certificate_params_types<1..2^8-1>;
+ } PGPCertificateRequest;
+
+ The certificate_params_types is a list of accepted client certificate
+ parameter types, sorted in order of the server's preference.
+
+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 keys have been selected, and no key is available
+ from the client, then a Certificate that contains an empty PGPKey
+ should be sent. The server may respond with a "handshake_failure"
+ fatal alert if client authentication is required. This transaction
+ follows the TLS specification.
+
+
+Mavroyanopoulos Expires July 26, 2005 [Page 7]
+Internet-Draft Using OpenPGP keys for TLS authentication January 2005
+
+3.6 Server key exchange
+
+ The server key exchange message for OpenPGP keys is identical to the
+ TLS specification.
+
+3.7 Certificate verify
+
+ The certificate verify message for OpenPGP keys is identical to the
+ TLS specification.
+
+3.8 Finished
+
+ The finished message for OpenPGP keys is identical to the description
+ in the specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires July 26, 2005 [Page 8]
+Internet-Draft Using OpenPGP keys for TLS authentication January 2005
+
+4. Cipher suites
+
+ No new cipher suites are required to use OpenPGP keys. OpenPGP keys
+ can be combined with existing cipher suites defined in TLS [1],
+ except the ones marked as "Exportable". Exportable cipher suites
+ SHOULD NOT be used with OpenPGP keys.
+
+ Some additional cipher suites are defined here in order to support
+ algorithms which are defined in OpenPGP [2], and are always available
+ in OpenPGP implementations but are not present in TLS [1].
+
+ CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_RMD160 = { 0x00, 0x72 };
+ CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_RMD160 = { 0x00, 0x73 };
+ CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_RMD160 = { 0x00, 0x74 };
+ CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_RMD160 = { 0x00, 0x77 };
+ CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_RMD160 = { 0x00, 0x78 };
+ CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_RMD160 = { 0x00, 0x79 };
+ CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_RMD160 = { 0x00, 0x7C };
+ CipherSuite TLS_RSA_WITH_AES_128_CBC_RMD160 = { 0x00, 0x7D };
+ CipherSuite TLS_RSA_WITH_AES_256_CBC_RMD160 = { 0x00, 0x7E };
+
+ All of the above cipher suites use either the AES [5] and 3DES block
+ ciphers in CBC mode. The choice of hash is the RIPEMD-160 [4]
+ algorithm. Implementations are not required to support the above
+ cipher suites.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires July 26, 2005 [Page 9]
+Internet-Draft Using OpenPGP keys for TLS authentication January 2005
+
+5. Internationalization Considerations
+
+ All the methods defined in this document are represented as machine
+ readable structures. As such issues of human internationalization
+ and localization are not introduced.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires July 26, 2005 [Page 10]
+Internet-Draft Using OpenPGP keys for TLS authentication January 2005
+
+6. Security Considerations
+
+ As with X.509 ASN.1 formatted keys, OpenPGP keys need specialized
+ parsers. Care must be taken to make those parsers safe against
+ maliciously modified keys, that may crash or modify the application's
+ memory.
+
+ Security considerations about the use of the web of trust or the
+ verification procedure are outside the scope of this document, since
+ they are considered a local policy matter.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires July 26, 2005 [Page 11]
+Internet-Draft Using OpenPGP keys for TLS authentication January 2005
+
+7. References
+
+7.1 Normative References
+
+ [1] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
+ 1999.
+
+ [2] Callas, J., Donnerhacke, L., Finey, H. and R. Thayer, "OpenPGP
+ Message Format", RFC 2440, November 1998.
+
+ [3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T.
+ Wright, "TLS Extensions", RFC 3546, June 2003.
+
+ [4] Dobbertin, H., Bosselaers, A. and B. Preneel, "RIPEMD-160: A
+ Strengthened Version of RIPEMD", April 1996.
+
+ [5] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
+ Transport Layer Security (TLS)", RFC 3268, June 2002.
+
+7.2 Informative References
+
+ [6] 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.
+
+ [7] "Recommendation X.509: The Directory - Authentication
+ Framework", 1988.
+
+Author's Address
+
+ Nikos Mavroyanopoulos
+ Arkadias 8
+ Halandri, Attiki 15234
+ Greece
+
+ EMail: nmav@gnutls.org
+ URI: http://www.gnutls.org/
+
+
+
+
+
+
+
+Mavroyanopoulos Expires July 26, 2005 [Page 12]
+Internet-Draft Using OpenPGP keys for TLS authentication January 2005
+
+Appendix A. Acknowledgements
+
+ The author wishes to thank Werner Koch, David Taylor and Timo Schulz
+ for their suggestions on improving this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mavroyanopoulos Expires July 26, 2005 [Page 13]
+Internet-Draft Using OpenPGP keys for TLS authentication January 2005
+
+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 (2005). 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.
+
+
+Mavroyanopoulos Expires July 26, 2005 [Page 14]
projects / thirdparty / gnutls.git / commitdiff
