Re: The purpose of this mailing list

[tzeruch@xxxxxxxxxx]

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.