Subject: Fw: [ietf-tls] using openpgp with tls

From: Nikos Mavroyanopoulos <[email-masked]>
Date: Thu, 17 Jan 2002 08:51:14 +0200

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:[email-masked]

---

From: Derek Atkins <[email-masked]>
Date: 17 Jan 2002 09:52:24 -0500

> I'd appreciate any comments on this.

You probably do not want to assume that the fingerprint is 20 octets
long; fingerprints on v3 RSA keys are only 16 octets long.  So, your
definition of PGPFingerprint<20> wont work with all OpenPGP keys.
Since you're already assuming DSS keys by your 20-octet fingerprint,
it should be noted that the v4 (DSS) keyID is just the lower 64-bits
of the fingerprint. (RFC2440: 11.2)

You probably want to send along the keyID as well as the fingerprint.
Most implementations can only lookup a key based on the keyID.  As a
result, you wont be able to easily lookup v3 RSA keys if you only send
the fingerprint.  I would recommend you change the definition to:

opaque PGPKeyID<8>
opaque PGPFingerprintV3<16>
opaque PGPFingerprintV4<20>

struct {
        PGPKeyVersion keyVersion;
        select (keyVersion) {
                case v3: PGPFingerprintV3;
                case v4: PGPFingerprintV4;
        }
        PGPKeyID;
} PGPKeyDescriptor;

And then use the PGPKeyDescriptor in your Certificate structure.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Nikos Mavroyanopoulos <[email-masked]>
Date: Thu, 17 Jan 2002 18:55:29 +0200

On 17 Jan 2002 09:52:24 -0500 Derek Atkins <[email-masked]> wrote:

Derek, 
 thank you for your comments,

> of the fingerprint. (RFC2440: 11.2)
the notation <20> means an upper limit of 20 bytes in TLS (used in RFC2246), 
so v3 fingerprints can be used. (the specified data are encoded with the size).

> the fingerprint.  I would recommend you change the definition to:
I'm not quite familiar with OpenPGP, and I had the impression that v3
keys were only defined for backwards compatibility. If v3 keys are still 
in use I could use something like:

> opaque PGPKeyID<8>
> opaque PGPFingerprint<20>
> 
> struct {
>     PGPKeyID pgp_key_id;
>     PGPFingerprint pgp_fingerprint;
> } PGPKeyDescriptor;

or

> opaque PGPKeyID<8>
> opaque PGPFingerprint<20>
> enum { v3, v4 } PGPKeyVersion;
>
> struct {
>    PGPFingerprint pgp_fingerprint;
>    select (PGPKeyVersion) {
>          case v3: PGPKeyID;
>          case v4: {};

The first version always sends the keyID (which is redundant in v4 keys).

The second version is a bit complicated, but sends the keyID only for v3
keys. I don't really like it because (at least since today) TLS did not 
have to know about X.509 certificates' version explicitly. I think it's 
better to be that way for OpenPGP keys too.

-- 
Nikos Mavroyanopoulos
mailto:[email-masked]

---

From: Werner Koch <[email-masked]>
Date: Thu, 17 Jan 2002 18:11:43 +0100

> long; fingerprints on v3 RSA keys are only 16 octets long.  So, your

Left pad them with zeroes and store the fingerprint as meta data with
the keys or index a DB using the fingerprint.  It might even be easier
to require the use of v4 keys.

> You probably want to send along the keyID as well as the fingerprint.

Frankly, I suggested to drop the keyID because the few extra bytes for
a fingerprint are not an issue and it makes the code easier if we only
have to lookup by fingerprint.

> Most implementations can only lookup a key based on the keyID.  As a

Then they should be fixed. To lookup by keyID you have to calculate
the fingerprint anyway for v4 keys.  And there won't be many v3 keys
in use with TLS.

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus

---

From: Derek Atkins <[email-masked]>
Date: 17 Jan 2002 12:24:03 -0500

> have to lookup by fingerprint.

Sure, it's redundant for v4 keys but it's required for v3 keys.

> the fingerprint anyway for v4 keys.  And there won't be many v3 keys

I don't think that's a reasonable assumption to make.  Worse, if you
have _ANY_ v3 keys then you need to ship the keyID.  Perhaps there is
some way that if keyID == lower_part(fingerprint) then we only send
the fingerprint, but send keyID if it's !=?

-derek

---

From: Derek Atkins <[email-masked]>
Date: 17 Jan 2002 12:21:26 -0500

Nikos Mavroyanopoulos <[email-masked]> writes:

> the notation <20> means an upper limit of 20 bytes in TLS (used in
> RFC2246), so v3 fingerprints can be used. (the specified data are
> encoded with the size).

Ok.  I am unfamilar with the TLS spec, so thank you for clearing this
up.

> in use I could use something like:

That's ok -- I am.  I'm afraid that yes, v3 keys are still in wide
use.  Anyone who generated their key using PGP 2.x and is still using
PGP with that key is de facto using a v3 key.  I, personally, am one
such user.  It is more than just backwards compatibility (IMHO).

> The first version always sends the keyID (which is redundant in v4 keys).

I'm willing to live with 8 bytes of redundancy.  It's still better
than X.509 ;)

> better to be that way for OpenPGP keys too.

I agree..  Go with the former and always send the extra 8 bytes of
keyID.

-derek

---

From: Werner Koch <[email-masked]>
Date: Thu, 17 Jan 2002 18:33:24 +0100

> have _ANY_ v3 keys then you need to ship the keyID.  Perhaps there is

Why?  Because the HKP keyservers are not able to search by
fingerprint?  Hopefully this will be fixed and the modern key servers
support such a lookup (well, not checked but easy to add).

I can't imagine that anyone will use an old v3 key for TLS
authentication - TLS is always used on a networked machine (surprise)
and as such this machine is much more exposed to attacks than the
secure boxes we all use to handle or secret keys ;-).  If TLS is
configured somewhere, a new key should be used for this and this key
can in turn be signed by certification key.

Using PGP keys with TLS is a new thing and we don't have to take
backwards compatibility into account.

Ciao,

  Werner

---

From: Derek Atkins <[email-masked]>
Date: 17 Jan 2002 12:44:30 -0500

Keep in mind that TLS can use "user certificates" too... Are you
implying that users with v3 certs have to generate a new key
in order to use them in TLS?

-derek

---

From: Werner Koch <[email-masked]>
Date: Thu, 17 Jan 2002 19:01:20 +0100

> in order to use them in TLS?

Yes, for the same reasons as for servers.  The majority of keys is v4
for quite a long time now.  I know only a few people insisting on
using the old keys - even Ted T'so has a v4 key now.

And I still don't see a reason why a keyID is needed in TLS.  We need
the keyIDs to lookup signing keys but this has nothing to do with TLS.

---

From: Derek Atkins <[email-masked]>
Date: 17 Jan 2002 13:07:43 -0500

> Yes, for the same reasons as for servers.  The majority of keys is v4

I disagree that these reasons are valid... But that's not important
right now..

> the keyIDs to lookup signing keys but this has nothing to do with TLS.

Ok, perhaps I am confused.  Could you please explain how the
fingerprint would get used the TLS protocol?  I thought it was being
used to present an "I can use this key" message to the other side,
which implies (to me) that the remote end would need to lookup a key
based on that number.  Could you please explain how this "identifier"
is meant to be used within TLS?

-derek

---

From: Werner Koch <[email-masked]>
Date: Thu, 17 Jan 2002 20:04:28 +0100

> based on that number.  Could you please explain how this "identifier"

That is also my understanding.  The point is whether it is possible
lookup a key based on the fingerprint.  I say yes because for a local
lookup you should index you keyring anyway (think about a server and
millions of users) and then it doesn't matter whether to lookup by
fingerprint or keyID.  There is even no reasonable high overhead when
inserting a new key: Most keys are v4 and to get a keyID you need to
calculate the fingerprint anyway.  For the few v3 keys (cf. dtype.org
for keyserver statistics) you can avoid the fingerprint calculation
but really this doesn't matter anymore.

For a lookup via keyserver there is probably a problem with the HKS
type servers but they have so many problems that they have to replaced
anyway.  I am pretty sure that the NAI certserver is able to do a
lookup by fingerprint and to add this to the ALMI and cryptnet servers
will only take a few hours.

So why not using _only_ the fingerprint in TLS.  IIRC we had a
discussion a long time ago to allow the use of fingerprint in the next
version of signature packets.  My point is that the fingerprint is the
correct way to identify a key and that there is no need for backward
compatibilty when a new protocol is designed.  Let's avoid the X.509
problem of not knowing how to cleany identify a key.

---

From: Derek Atkins <[email-masked]>
Date: 17 Jan 2002 14:52:09 -0500

Werner Koch <[email-masked]> writes:

>   Let's avoid the X.509

Why not add 8 more bytes and you still get this functionality and
backwards compatibility?

Keep in mind that lack-of-backwards-compatibility is what got us
where we are today, a fragmented community of people.  It all started
with PGP 2.5 and got worse with PGP 5.0, let alone OpenPGP.

Backwards compatibility is a Good Thing, in particular when talking
about long-lived identity keys.

-derek

---

From: Will Price <[email-masked]>
Date: Thu, 17 Jan 2002 16:39:20 -0800

Another important point about backwards compatibility: the current
OpenPGP/TLS draft already has well over a million deployed clients.
Every PGP client since I believe 6.0.0 (September 1998) supports
PGPtls as described in the draft, and every PGP Keyserver since that
time period also supports PGPtls.

PGPtls can be used for split key network reconstitution, normal key
searches on keyservers, client authentication to keyservers for the
purpose of deleting or disabling keys, and a whole host of other
things in various products from NAI and others.

While PGPtls in the PGPsdk was the first implementation (for which
source code is currently available at the pgp website, and part of
every source release we've done for the last few years), I know
others have mentioned other implementations as well to me over the
last year or so.

In addition to ignoring all the fielded uses and implementations of
OpenPGP/TLS, Nikos' proposed changes also suffer from the dependency
problem on the TLSEXT draft, and the Fingerprint/KeyID confusion
which I've previously detailed on the ietf-tls list. It would be a
huge mistake to adopt the proposed changes.

Derek Atkins wrote:
> where we are today, a fragmented community of people.  It all
> started with PGP 2.5 and got worse with PGP 5.0, let alone OpenPGP.
> 

- - -- 

Will Price, Director of Engineering
PGP Security, Inc.
a division of Network Associates, Inc.

---

From: Werner Koch <[email-masked]>
Date: Fri, 18 Jan 2002 12:54:19 +0100

[I am not on the tls list, feel free to resend it]

> OpenPGP/TLS draft already has well over a million deployed clients.

This is an expired draft and as such not anymore accessible.

And:

   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

> PGPtls as described in the draft, and every PGP Keyserver since that

PGP has a lot of proprietary features which are either in conflict to
OpenPGP or not documented at all.  NAI folks are talking for years:
"We will write up the specification RSN" - I have never seen more than
these announcements.  Some non-NAI folks reverse engineered the format
of the photo ID from actual PGP output, so that David Shaw could
implement this in GnuPG but most other stuff is unknown and NAI is
even dropping OpenPGP required features (v4 sigs on data) - well may
be this is a bug, but those things have happened far too often.

> every source release we've done for the last few years), I know

And since you re-opened the source for >= 7, you use a license which
makes the source useless and actual dangerous for a programmer to look
at. 

> OpenPGP/TLS, Nikos' proposed changes also suffer from the dependency

There is no documentation on this format - may be PGP implemented that
draft but nobody writing TLS or OpenPGP code is able to even check
this as there is no usable source.

If NAI would have been interested in standard conformace, the draft
should be reissued regulary and the extensions to OpenPGP discussed
with the OpenPGP WG.  The same thing goes for OpenPGP features like
MDC and a new transport format for secret keys - NAI seems not to be
interested in it anymore.

  Werner

---

From: Nikos Mavroyanopoulos <[email-masked]>
Date: Fri, 18 Jan 2002 16:18:46 +0200

On Thu, 17 Jan 2002 20:04:28 +0100 Werner Koch <[email-masked]> wrote:

> fingerprint or keyID. 

I should add here that:

This identifier is used with 2 purposes:
1. To identify the key 
2. To provide equal security with the case where the actual key is sent [0]

The reason I replaced keyIDs with Fingerprints is that this identifier
is covered by the TLS Finished messages. This means that after the Finished 
messages are sent, the parties know that the peer got a key which is identified 
by the fingerprint or keyID. Since keyIDs[1] can be faked, they do not qualify 
for this. If they should be added, they should be added for backwards 
compatibility and only for this reason.

[0]: This is also discussed in the draft-ietf-tls-extensions-02 in the
 security considerations chapter (client certificate URL extension).
[1]: I don't believe that a hash truncated to 64bits provides any security

-- 
Nikos Mavroyanopoulos
mailto:[email-masked]

---

From: Nikos Mavroyanopoulos <[email-masked]>
Date: Sat, 19 Jan 2002 15:09:47 +0200

> > millions of users) and then it doesn't matter whether to lookup by
[...]
> compatibility and only for this reason.

On second thoughts, I think there is not an issue for backwards compatibility,
since a client is not required to send the fingerprint (he may send the key).
A holder of a v3 key may send the key instead of the fingerprint, in the
case he suspects that the server could not retrieve the key.

I think this is the most clean solution. If you agree I'll keep the original
version.

-- 
Nikos Mavroyanopoulos
mailto:[email-masked]