At 12:46 PM 9/13/97 -0400, tzeruch(_at_)ceddec(_dot_)com wrote:
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?
It's presently possible to separately expire or replace a subkey. There is
no reason that you can't have multiple subkeys, and in fact, I see it as
inevitable. The present generation of software doesn't have a lot of
support for that, but that's okay. The basic architecture, where a
signature key provides a framework in which to use a collection of subkeys
is a good one.
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.
Excellent. Actually, though, you don't ask the server for a validity check.
Validity is in the eye of the beholder. You use the user's validity (trust)
information for that.
Jon
-----
Jon Callas jon(_at_)pgp(_dot_)com
Chief Scientist 555 Twin Dolphin Drive
Pretty Good Privacy, Inc. Suite 570
(415) 596-1960 Redwood Shores, CA 94065