Add.

2 files changed, 1479 insertions, 0 deletions

diff --git a/doc/protocol/draft-ietf-tls-openpgp-keys-05.txt b/doc/protocol/draft-ietf-tls-openpgp-keys-05.txt
new file mode 100644
index 0000000000..b7e70bc2b2
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-openpgp-keys-05.txt
@@ -0,0 +1,897 @@
+
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+
diff --git a/doc/protocol/draft-ietf-tls-openpgp-keys-06.txt b/doc/protocol/draft-ietf-tls-openpgp-keys-06.txt
new file mode 100644
index 0000000000..0120363acc
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-openpgp-keys-06.txt
@@ -0,0 +1,582 @@
+
+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]