ietf-openpgp
[Top] [All Lists]

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

2002-01-17 10:21:28

Nikos Mavroyanopoulos <nmav(_at_)hellug(_dot_)gr> 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.

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:

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:

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).

opaque PGPKeyID<8>
opaque PGPFingerprint<20>

struct {
    PGPKeyID pgp_key_id;
    PGPFingerprint pgp_fingerprint;
} PGPKeyDescriptor;

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 ;)

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.

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

-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
       warlord(_at_)MIT(_dot_)EDU                        PGP key available