added draft-ietf-tls-openpgp-00.txt

1 files changed, 224 insertions, 0 deletions

diff --git a/doc/draft-ietf-tls-openpgp-00.txt b/doc/draft-ietf-tls-openpgp-00.txt
new file mode 100644
index 0000000000..92e308b1f5
--- /dev/null
+++ b/doc/draft-ietf-tls-openpgp-00.txt
@@ -0,0 +1,224 @@
+TLS Working Group                                               W. Price
+INTERNET-DRAFT                                                 M. Elkins
+                                                Network Associates, Inc.
+                                                        15 December 1999
+
+draft-ietf-tls-openpgp-00.txt
+
+
+                   Extensions to TLS for OpenPGP keys
+
+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.
+
+Abstract
+
+   This document builds upon the TLS Protocol Specification [TLS].  The
+   extensions described herein are intended to apply to Version 1.0 of
+   the TLS specification.
+
+   The purpose of this document is to update the TLS protocol with
+   extensions to support the certificates, public key algorithms,
+   symmetric ciphers, hash algorithms, and trust model used by OpenPGP
+   [OpenPGP].
+
+   This document uses the same notation used in the TLS Protocol draft.
+
+   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.
+
+Certificate
+
+   The X.509.v3 [X509] certificates recommended for use with TLS will
+
+
+
+Price                    Expires 15 June 2000                   [Page 1]
+
+Internet-Draft     Extensions to TLS for OpenPGP keys   15 December 1999
+
+
+   not be used in conjunction with OpenPGP keys.  An implementation
+   SHOULD be able to support both TLS with X509 and TLS with OpenPGP
+   keys.  It is NOT REQUIRED that an implementation support both.  The
+   "peer certificate" in the session state of TLS MAY refer to either
+   X509 or OpenPGP.
+
+   The contents of the Certificate (11) message sent from server to
+   client and vice versa are determined by the Cipher Suite.  Many new
+   Cipher Suites are defined in the Cipher Suites section of this
+   document for use with OpenPGP keys.  All OpenPGP Cipher Suites
+   REQUIRE a OpenPGP key in the Certificate messages.  A OpenPGP key
+   appearing in the Certificate message will be sent in binary OpenPGP
+   format.  The Certificate message includes a OpenPGP key where the
+   X509 certificate would normally appear.  The option is also available
+   to send a 64 bit OpenPGP Key ID instead of sending the entire key.
+   The client will respond with a fatal alert no_certificate if the Key
+   ID cannot be found.  If the key is not valid, expired, revoked, or
+   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.  A particular OpenPGP
+   compatible TLS implementation MAY wish to allow users to designate
+   certain keys specifically as Trusted Server Keys.  This is a local
+   matter outside the scope of this document.
+
+   enum {
+        keyid (0), key (1), (255)
+   } PGPKeyDescriptorType;
+
+   opaque PGPKeyID<8>
+   opaque PGPKey<1..2^24-1>
+   struct {
+        PGPKeyDescriptorType descriptorType;
+        select (descriptorType) {
+             case keyid: PGPKeyID;
+             case key: PGPKey;
+        }
+   } Certificate;
+
+Certificate Request
+
+   The server is allowed to request a client certificate from the
+   client.  The meaning of this message is essentially unchanged to
+   allow OpenPGP keys.
+
+   The rsa_sign and dss_sign certificate types may be requested in
+   conjunction with OpenPGP keys.  The ClientCertificateType field is
+   used identically to the TLS specification.  The subsequent
+   DistinguishedName field is NOT included when using Cipher Suites
+
+
+
+Price                    Expires 15 June 2000                   [Page 2]
+
+Internet-Draft     Extensions to TLS for OpenPGP keys   15 December 1999
+
+
+   based on OpenPGP keys.
+
+   The Client Certificate message is sent using the same formatting as
+   the server Certificate message in response to the Certificate Request
+   message.  If no OpenPGP key is available from the client, the
+   no_certificate alert is returned.  The server MAY then respond with a
+   fatal alert if appropriate.  This transaction follows the TLS
+   specification.
+
+Server Key Exchange
+
+   When using ephemeral Diffie-Hellman, the Server Key Exchange message
+   is sent to pass the Diffie-Hellman public value to the client.  The
+   client and server then use this value to establish the shared secret.
+   This is identical to the operation of standard TLS.
+
+Certificate Verify
+
+   The Certificate Verify message for OpenPGP key types is identical to
+   the specification.  The signature is made using either DSS or RSA
+   depending on the Cipher Suite.
+
+Finished
+
+   The Finished message for OpenPGP key types is identical to the
+   description in the specification.
+
+Cipher Suites
+
+   Since TLS does not have a certificate type field, the Cipher Suites
+   field is used to perform the same function.  A number of additional
+   Cipher Suites are defined for use with OpenPGP keys.
+
+   CipherSuite TLS_PGP_DHE_DSS_WITH_CAST_CBC_SHA          = { 0x01, 0x01 };
+   CipherSuite TLS_PGP_DHE_DSS_WITH_IDEA_CBC_SHA          = { 0x01, 0x02 };
+   CipherSuite TLS_PGP_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x01, 0x03 };
+   CipherSuite TLS_PGP_DHE_DSS_WITH_CAST_CBC_RMD          = { 0x01, 0x04 };
+   CipherSuite TLS_PGP_DHE_DSS_WITH_IDEA_CBC_RMD          = { 0x01, 0x05 };
+   CipherSuite TLS_PGP_DHE_DSS_WITH_3DES_EDE_CBC_RMD = { 0x01, 0x06 };
+   CipherSuite TLS_PGP_DHE_RSA_WITH_CAST_CBC_SHA          = { 0x01, 0x10 };
+   CipherSuite TLS_PGP_RSA_WITH_CAST_CBC_SHA         = { 0x01, 0x20 };
+   CipherSuite TLS_PGP_RSA_WITH_IDEA_CBC_SHA         = { 0x01, 0x21 };
+   CipherSuite TLS_PGP_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x01, 0x22 };
+   CipherSuite TLS_PGP_RSA_WITH_CAST_CBC_RMD         = { 0x01, 0x23 };
+   CipherSuite TLS_PGP_RSA_WITH_IDEA_CBC_RMD         = { 0x01, 0x24 };
+   CipherSuite TLS_PGP_RSA_WITH_3DES_EDE_CBC_RMD          = { 0x01, 0x25 };
+   CipherSuite TLS_PGP_DSA_WITH_NULL_SHA                   = { 0x01, 0xF0 };
+
+
+
+
+Price                    Expires 15 June 2000                   [Page 3]
+
+Internet-Draft     Extensions to TLS for OpenPGP keys   15 December 1999
+
+
+   Note:     The above numeric definitions for Cipher Suites have not
+   yet been registered.
+
+   All of the above Cipher Suites use either the CAST, IDEA, or
+   TripleDES block ciphers in CBC mode.  The choice of hash is either
+   SHA-1 or RIPEMD-160.  Use of any of these Cipher Suites REQUIRES an
+   OpenPGP key in any Certificate and Client Certificate messages.  MD5
+   MAY NOT be used with OpenPGP keys.  "Export" algorithms also MAY NOT
+   be used with OpenPGP keys.
+
+   To be considered compliant with support for OpenPGP in TLS, an
+   implementation MUST support TLS_PGP_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
+
+References
+
+   [TLS]     T. Dierks, and C. Allen, "The TLS Protocol Version 1.0",
+             RFC 2246, January 1999.
+
+   [OpenPGP] J. Callas, L. Donnerhacke, H. Finney, R. Thayer,
+             "OpenPGP Message Format", RFC 2440, November 1998.
+
+Authors
+
+   Will Price <wprice@cyphers.net>
+   Network Associates, Inc.
+
+   Michael Elkins <michael_elkins@nai.com>
+   Network Associates, Inc.
+   Phone: 310-737-1623
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Price                    Expires 15 June 2000                   [Page 4]
+