On Fri, 12 Sep 1997, Jon Callas wrote:
But wait, there's more. If you have two PGP certs that contain the same key
material, PGP will merge them. I think this needs to change sooner or
later, but that's the way things are presently. So from this aspect, the
truest DN is the key itself. The notion that the fingerprint or key itself
is the truest DN sounds pretty SPKI/SDSI-like to me.
The key material is now separated into the DSS section and the DH section.
What if the DSS is the same and the DH is different - does PGP merge them
or not? Which DH material should it use? It may be able to handle
multiple userIDs, but what about multiple subkeys?
The biggest advantage of a PGP cert has is the way that it is "agile" as
I've heard some people call it. If you want to look at how you fit PGP into
a world that thinks names are important, you can use an email address as a
DN. If you want to use PGP in a name where keys are important, use the
fingerprint (or key proper) as a DN. No biggie. In fact, one of the central
points of the way the web of trust is organized relates directly to
resolving this apparent dichotomy. The PGP software, since its earliest
days, manages this apparent dichotomy. The beauty of PGP as a PKI is that
it can easily bridge an X.509-like, name-centric world to a SPKI-like,
key-centric world.
Exactly - I was trying to get at this point. If I take some of the
existing code handling X509 certs and replace that engine with one that
uses a PGP superset, maybe stretching the introducers model a little so
that CA chains would work like X509 intends, I have one program that can
handle both models. If it sees an X509, it just checks the signature
chain such that the root CA is adequate to propogate trust. If it sees a
PGPish cert, it asks a keyserver or user as necessary.