-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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:
Werner Koch <wk(_at_)gnupg(_dot_)org> writes:
Let's avoid the X.509
problem of not knowing how to cleany identify a key.
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.
- - --
Will Price, Director of Engineering
PGP Security, Inc.
a division of Network Associates, Inc.
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1.1
iQA/AwUBPEdufKy7FkvPc+xMEQJ6FQCfStNGaVZH3v00PfvlC+K/OKF0fNEAniX7
HwmnVYqVPtvH3TEmFWstFLd/
=L7x2
-----END PGP SIGNATURE-----