On Tue, 16 Sep 1997, Jon Callas wrote:
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.
Actually it sounds like you are moving toward a model where there are
signature capable entities, and encryption capable entities (and things
that can do both), so you could mix and match.
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.
To clarify, it would access the PGP keyserver so that the key with
signatures would be downloaded and any potential revocation! - even most
X509 implementations don't really do CRLs yet, so there is that function
that would be an immediate improvement. Either it would have enough
validity (e.g. I am accessing your web server and I have more than enough
signatures of trusted introducers that I accept the key as valid), or it
would present to the user a dialog box similar to what netscape does when
it doesn't recognize the CA.