ietf-openpgp
[Top] [All Lists]

Re: Proposed Extensions to TLS for OpenPGP

1997-12-30 20:57:19
At 10:03 PM -0800 12/29/97, Tom Weinstein wrote:
Will Price wrote:

The alternative seems to be to include another subpacket in the Hello
packets negotiating certificate type just like compression is negotiated.
This would also be allowed by the spec as per 7.4.1.2.  If it was to be
done that way, I felt that this negotiation should have been included in
the TLS spec.  Since I assume the time for that has passed, I opted for
the ciphersuite overload.

I don't think it can go into TLS 1.0, but it's definitely something we
should work towards for a TLS 1.1 or 2.0.

Great.  When does work start on TLS 1.1/2.0?

Clearly, the TLS/OpenPGP document needs to move forward anyway based on TLS
1.0 and could later be revised for a future version of TLS.

3. Omitting the DistinguishedName field in the CertificateRequest
field seems problematic. I understand PGP doesn't use DNs,
but there should be a way to indicate who might be potential signers
of a given key.

OpenPGP keys generally have all the certs they need attached to them
whereas X509 certs are only a single cert unto themselves thus requiring
a chain if the specified cert is not directly certified by a root CA.
With OpenPGP, if a particular signer key is not found, the client or
server can use a certserver to look it up.

Although TLS uses the X.509 cert formats, it doesn't require an X.500
directory to operate.  I don't think it's a good idea to require an OpenPGP
cert server, either.

I didn't mean to imply any such requirement for a certserver in my message
and the document makes no mention of such.  As stated in the document, this
issue is implementation dependent.  The equivalent of a DN in OpenPGP is
the 64 bit KeyID.  A reading of the OpenPGP spec will show that the "DN" or
KeyID is included in the certificate and can also replace the certificate.
I can see some implementations requiring users to get their OpenPGP key
certified by a particular CA, other implementations which simply accept any
key on first connection and require the authentication from that same key
on future connections like SSH, and other implementations which know the
keys for particular addresses and transmit only the KeyID rather than the
certificate.  A particularly complex implementation could get the key in
the Certificate message, lookup all the certifiers on a certserver and try
to establish validity dynamically that way, but I don't see that as likely
-- only a possible use.

-Will

Will Price, Architect
Network Associates, Inc.
Direct  (650)596-1956
Main    (650)572-0430
Fax     (650)631-1033
Cell/VM (650)533-0399
<pgpfone://clotho.pgp.com>

PGPkey: <http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0xCF73EC4C>