diff options
Diffstat (limited to 'doc/protocol/draft-ietf-tls-openpgp-keys-09.txt')
| -rw-r--r-- | doc/protocol/draft-ietf-tls-openpgp-keys-09.txt | 616 |
1 files changed, 0 insertions, 616 deletions
diff --git a/doc/protocol/draft-ietf-tls-openpgp-keys-09.txt b/doc/protocol/draft-ietf-tls-openpgp-keys-09.txt deleted file mode 100644 index 84d6393f6a..0000000000 --- a/doc/protocol/draft-ietf-tls-openpgp-keys-09.txt +++ /dev/null @@ -1,616 +0,0 @@ - - - -TLS Working Group N. Mavrogiannopoulos -Internet-Draft Independent -Expires: November 16, 2006 May 15, 2006 - - - Using OpenPGP keys for TLS authentication - draft-ietf-tls-openpgp-keys-09 - -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 November 16, 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 November 16, 2006 [Page 1] - -Internet-Draft Using OpenPGP keys for TLS authentication May 2006 - - -1. Introduction - - At the time of writing, TLS [TLS] uses the PKIX [PKIX] - 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, 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, allow distributed key management and can - be used with a non hierarchical trust model called the "web of trust" - [WOT]. - - This document will extend the TLS protocol to support OpenPGP keys - 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 is not altered, to preserve compatibility with - existing TLS servers and clients. - - This document uses the same notation 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 November 16, 2006 [Page 2] - -Internet-Draft Using OpenPGP keys for TLS authentication May 2006 - - -2. 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. - -2.1. Client Hello - - In order to indicate the support of multiple certificate types - clients will include an extension of type "cert_type" (see Section 4) - 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 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; - - No new cipher suites are required to use OpenPGP keys. All existing - cipher suites defined in [TLS] that support a compatible, with the - key, key exchange method can be used in combination with OpenPGP - keys. - -2.2. Server Hello - - Servers that receive an extended client hello containing the - "cert_type" extension, and have chosen a cipher suite that supports - certificates, 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". - - - -Mavrogiannopoulos Expires November 16, 2006 [Page 3] - -Internet-Draft Using OpenPGP keys for TLS authentication May 2006 - - - Servers that only support X.509 certificates MAY omit including the - "cert_type" extension in the extended server hello. - -2.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 - section 10.1 of [OpenPGP]. - - The option is also available to send an OpenPGP fingerprint, instead - of sending the entire key. 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 key with the given - key fingerprint cannot be found. The "certificate_unobtainable" - fatal alert is defined in section 4 of [TLSEXT]. - - 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 November 16, 2006 [Page 4] - -Internet-Draft Using OpenPGP keys for TLS authentication May 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; - -2.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. - -2.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. - -2.6. Other Handshake messages - - The rest of the handshake messages such as the server key exchange, - the certificate verify and the finished messages are identical to the - TLS specification. - - - - - - - - - - - - -Mavrogiannopoulos Expires November 16, 2006 [Page 5] - -Internet-Draft Using OpenPGP keys for TLS authentication May 2006 - - -3. 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 November 16, 2006 [Page 6] - -Internet-Draft Using OpenPGP keys for TLS authentication May 2006 - - -4. 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 will be - used for certificate type negotiation. - - To accommodate for future additions to the TLS certificate types a - new registry 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 November 16, 2006 [Page 7] - -Internet-Draft Using OpenPGP keys for TLS authentication May 2006 - - -5. References - -5.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., and R. Thayer, - "OpenPGP Message Format", RFC 2440, November 1998. - - [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. - -5.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. - - [WOT] Abdul-Rahman, A., "The PGP Trust Model", EDI Forum: The - Journal of Electronic Commerce, April 1997. - - - - - - - - - - - - - - - - - - - - - - -Mavrogiannopoulos Expires November 16, 2006 [Page 8] - -Internet-Draft Using OpenPGP keys for TLS authentication May 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 and - Pasi Eronen for their suggestions on improving this document. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Mavrogiannopoulos Expires November 16, 2006 [Page 9] - -Internet-Draft Using OpenPGP keys for TLS authentication May 2006 - - -Author's Address - - Nikos Mavrogiannopoulos - Independent - Arkadias 8 - Halandri, Attiki 15234 - Greece - - Email: nmav@gnutls.org - URI: http://www.gnutls.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Mavrogiannopoulos Expires November 16, 2006 [Page 10] - -Internet-Draft Using OpenPGP keys for TLS authentication May 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 November 16, 2006 [Page 11] - |