Hello,
Some days ago I posted to ietf-tls WG mailing list, a modification
of the draft-ietf-tls-openpgp-01. Since this is about openpgp,
I decided to post it here too.
The original post:
I wanted to use openpgp certificates with TLS, but
draft-ietf-tls-openpgp-01 is expired, and had some properties that I did
not like. Here I modified the tls-openpgp draft in a way that:
* no new cipher suites need to be defined, in order to use openpgp keys
* does not use keyIDs but key fingerprints
I'd appreciate any comments on this.
2. Certificates
The X.509v3 [X509] certificates recommended for use with TLS will
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.
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 Hello Messages
3.1.1 Extension Type
A new value, "cert_type(7)", has been added to the enumerated
ExtensionType, 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. This value was chosen based on the version of
defined in [TLSEXT] that was current at the time of writing, so may be
changed in future.
3.1.2 The Client Hello Message
An extension of type CertificateTypeExtension is appended to the standard
client hello message using the client hello extension mechanism
defined in [TLSEXT].
This extension carries a list of supported Certificate types the client
can use. This extension SHOULD NOT be used if the client supports only
X.509 Certificates.
enum { client, server } ClientOrServerExtension;
enum { X.509(0), OpenPGP(1), (255) } CertificateType;
struct {
select(ClientOrServerExtension) {
case client:
CertificateType certificate_type<1..2^8-1>;
case server:
CertificateType certificate_type;
}
} CertificateTypeExtension;
3.1.3 Server Hello
The certificate type selected by the server (certificate_type),
is appended to the server hello message using the hello
extension mechanism defined in [TLSEXT].
The certificate type selected by the server (certificate_type),
is encoded in an CertificateTypeExtension structure, which is
sent in an extended server hello message, using an extension of
type "cert_type".
The CertificateTypeExtension structure may be omited if the server
only supports X.509 certificates.
3.2 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 cipher suite.
In case OpenPGP certificate type is negotiated then it is required
to present an OpenPGP key in the Certificate message. A OpenPGP
key appearing in the Certificate message will be sent in binary
OpenPGP format. The Certificate message includes an OpenPGP key
where the X.509 certificate would normally appear.
The option is also available to send an OpenPGP fingerprint,
instead of sending the entire key. The generation of fingerprints
is defined in [OpenPGP]. The client will respond
with a fatal alert unsupported_certificate if the key with the
given fingerprint cannot be found. 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. 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 {
key (0), key_fingerprint (1), (255)
} PGPKeyDescriptorType;
opaque PGPFingerprint<20>;
opaque PGPKey<1..2^24-1>
struct {
PGPKeyDescriptorType descriptorType;
select (descriptorType) {
case key_fingerprint: PGPFingerprint;
case key: PGPKey;
}
} Certificate;
3.3 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 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, then
an empty certificate is returned. The server MAY then respond with a
fatal alert if appropriate. This transaction follows the TLS
specification.
3.4 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.
3.5 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.
3.6 Finished
The Finished message for OpenPGP key types is identical to the
description in the specification.
4. Supported Key Exchange Algorithms
OpenPGP certificates can be used with the following key exchange
algorithms:
Key Exchange Algorithm Certificate Key Type
RSA RSA public key; the certificate must
allow the key to be used for encryption.
DHE_DSS DSS public key.
DHE_RSA RSA public key which can be used for
signing.
The above key exchange algorithms are defined in [TLS].
5. Cipher Suites
No new Cipher Suites are required, in order to use OpenPGP certificates,
but some additional Cipher Suites are defined here in order to support
algorithms defined in [OpenPGP] but are not present in [TLS].
CipherSuite TLS_DHE_DSS_WITH_CAST_CBC_SHA = { 0x00, 0x?? };
CipherSuite TLS_DHE_DSS_WITH_CAST_CBC_RMD = { 0x00, 0x?? };
CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_RMD = { 0x00, 0x?? };
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_RMD = { 0x00, 0x?? };
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_RMD = { 0x00, 0x?? };
CipherSuite TLS_DHE_RSA_WITH_CAST_CBC_SHA = { 0x00, 0x?? };
CipherSuite TLS_DHE_RSA_WITH_CAST_CBC_RMD = { 0x00, 0x?? };
CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_RMD = { 0x00, 0x?? };
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_RMD = { 0x00, 0x?? };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_RMD = { 0x00, 0x?? };
CipherSuite TLS_RSA_WITH_CAST_CBC_SHA = { 0x00, 0x?? };
CipherSuite TLS_RSA_WITH_CAST_CBC_RMD = { 0x00, 0x?? };
CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_RMD = { 0x00, 0x?? };
CipherSuite TLS_RSA_WITH_AES_128_CBC_RMD = { 0x00, 0x?? };
CipherSuite TLS_RSA_WITH_AES_256_CBC_RMD = { 0x00, 0x?? };
All of the above Cipher Suites use either the CAST, AES, or
TripleDES block ciphers in CBC mode. The choice of hash is either
SHA-1 or RIPEMD-160. "Export" algorithms also MAY NOT
be used with OpenPGP keys. Implementations are not required to support
the above cipher suites.
6. 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.
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T.
Wright, "TLS Extensions", draft-ietf-tls-extensions-02 (work in
progress), June 2001.
[X509] CCITT. Recommendation X.509: "The Directory - Authentication
Framework". 1988.
--
Nikos Mavroyanopoulos
mailto:nmav(_at_)hellug(_dot_)gr