From f1eeaf316205cfd73874a19c80fb80393c8de39a Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Wed, 18 Jan 2006 10:01:37 +0000 Subject: Add. --- doc/protocol/draft-ietf-tls-openpgp-keys-08.txt | 784 ++++++++++++++++++++++++ 1 file changed, 784 insertions(+) create mode 100644 doc/protocol/draft-ietf-tls-openpgp-keys-08.txt diff --git a/doc/protocol/draft-ietf-tls-openpgp-keys-08.txt b/doc/protocol/draft-ietf-tls-openpgp-keys-08.txt new file mode 100644 index 0000000000..9e52fd2189 --- /dev/null +++ b/doc/protocol/draft-ietf-tls-openpgp-keys-08.txt @@ -0,0 +1,784 @@ + + + +TLS Working Group N. Mavrogiannopoulos +Internet-Draft Independent Consultant +Expires: July 19, 2006 January 15, 2006 + + + Using OpenPGP keys for TLS authentication + draft-ietf-tls-openpgp-keys-08 + +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 July 19, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +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. + + + + + + + + +Mavrogiannopoulos Expires July 19, 2006 [Page 1] + +Internet-Draft Using OpenPGP keys for TLS authentication January 2006 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Extension Type . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Certificate 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. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 + 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 + Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 + Intellectual Property and Copyright Statements . . . . . . . . . . 14 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mavrogiannopoulos Expires July 19, 2006 [Page 2] + +Internet-Draft Using OpenPGP keys for TLS authentication January 2006 + + +1. Introduction + + At the time of writing, TLS [1] uses the PKIX [4] 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 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 [1] 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. + + + + + + + + + + + + + + + + + + + + + + + +Mavrogiannopoulos Expires July 19, 2006 [Page 3] + +Internet-Draft Using OpenPGP keys for TLS authentication January 2006 + + +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. + + The new extension type will be used for certificate type negotiation + and contains an indicator of the type of the certificate to be used. + +2.1. Certificate Type + + As it can be seen from the CertificateType type at Section 3.1 below, + the allowed certificate types are up to 256. These are segmented in + the following way: + + 1. Values 0 (zero) and 1 are defined in this document. + + 2. Values from 2 through 223 decimal (0xDF) inclusive are reserved + to be defined by other documents or a future version of this + document. + + 3. Values from 224 decimal (0xE0) through 255 decimal (0xFF) + inclusive are reserved for private use. Interoperability with + these certificate types is a local matter. + + + + + + + + + + + + + + + + + + + + + + + + + + +Mavrogiannopoulos Expires July 19, 2006 [Page 4] + +Internet-Draft Using OpenPGP keys for TLS authentication January 2006 + + +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 SHOULD + 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. + + + + + + +Mavrogiannopoulos Expires July 19, 2006 [Page 5] + +Internet-Draft Using OpenPGP keys for TLS authentication January 2006 + + +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. + + + + + + + + + + +Mavrogiannopoulos Expires July 19, 2006 [Page 6] + +Internet-Draft Using OpenPGP keys for TLS authentication January 2006 + + + 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. + + + + + +Mavrogiannopoulos Expires July 19, 2006 [Page 7] + +Internet-Draft Using OpenPGP keys for TLS authentication January 2006 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mavrogiannopoulos Expires July 19, 2006 [Page 8] + +Internet-Draft Using OpenPGP keys for TLS authentication January 2006 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mavrogiannopoulos Expires July 19, 2006 [Page 9] + +Internet-Draft Using OpenPGP keys for TLS authentication January 2006 + + +5. 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 could cause arbitrary code execution. + + Security considerations about the use of the web of trust or the + verification procedure are outside the scope of this document and + they are considered an issue to be handled by local policy. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mavrogiannopoulos Expires July 19, 2006 [Page 10] + +Internet-Draft Using OpenPGP keys for TLS authentication January 2006 + + +6. References + +6.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. + +6.2. Informative References + + [4] 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. + + [5] "Recommendation X.509: The Directory - Authentication + Framework", 1988. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mavrogiannopoulos Expires July 19, 2006 [Page 11] + +Internet-Draft Using OpenPGP keys for TLS authentication January 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 and Timo Schulz + for their suggestions on improving this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mavrogiannopoulos Expires July 19, 2006 [Page 12] + +Internet-Draft Using OpenPGP keys for TLS authentication January 2006 + + +Author's Address + + Nikos Mavrogiannopoulos + Independent Consultant + Arkadias 8 + Halandri, Attiki 15234 + Greece + + Email: nmav@gnutls.org + URI: http://www.gnutls.org/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mavrogiannopoulos Expires July 19, 2006 [Page 13] + +Internet-Draft Using OpenPGP keys for TLS authentication January 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 July 19, 2006 [Page 14] + -- cgit v1.2.1