Now let's think just a moment about how someting like that could work for PGP.
And I'll make the pessimistic assumption that we might be unable to get the
PGP
users to start issuing self-signed certificates for the sake of compatibility,
just for the sake of argument.
I would assume in this case that RIPEM could manufacture an X.509 certificate
which includes the direct-trusted key and the subject's name, and is signed by
the recipient user, with his own DN (excuse my vulgarity) as the issuer, and
an
appropriate serial number?
Yes. RIPEM happens to use a digest of the certificate contents
(without the serial number) as the serial number. Since this includes
validity, subject, public key, etc. it is always unique (barring the
possibility of 1 in 2^128 of collision). This way, there is no need
for a database to track sequential serial numbers - just one more
thing to go wrong. (Note that the BBN SafeKeyper already puts its own
unit number in the high bytes of the serial number, so its serial
numbers are not simply "1", "2", "3", etc.)
The semantics of what such a certificate means would be a "local matter", but
the syntactic validation would be pretty straight-forward, and make use of the
already existing mechanisms. We'd want to be careful of what would happen if a
third user certified the second user -- would that mean that he had implicitly
certified the first user as well?
The issue of "extended" certifications like you mention is strictly
controlled in RIPEM via the "chain length allowed" value. When I make
a certificate for you, the chain length allowed defaults to zero
meaning that RIPEM will not accept certificates you make for others.
I must explicitly set chain length allowed to 1 or more according to
how deep I will accept chains "off of" the certificate I made for you.
(This is how RIPEM hooks into the Commercial Certification hierarchy.
I make a certificate with me as the issuer and the Comm CA as the
subject and then set its chain length allowed to 2.) The chain length
allowed information is of course authenticated with the user's
password to prevent tampering.
I don't know whether RIPEM currently includes PGP compatibility as a mode, but
would you see any substantial problems with such an approach?
PGP uses different encoding mechanisms for public keys, names and
certificates. Also, as far as I understand, PGP's certification
mechanisms are pretty wild and crazy (more than RIPEM, that is :-) ).
For example, someone can be partially trusted by several certifiers
and these trusts must "add up" somehow for you to trust that person.
Also, I don't know whether PGP performs canonicalization of text and
other RFC 1421-required operations that RIPEM follows.
In other words, they use different certification code, text processing
code, key and certificate representation code, etc. One would have
to parallel all the RIPEM code with PGP code anyway, so I don't know
why you wouldn't just use PGP if you want PGP. I appreciate that you
are trying to build bridges to bring people in, so let me ask, what
advantage would you see with putting PGP compatibility in RIPEM? It
is already the case that PGP compatibility at this level is not
planned for PEM, which RIPEM follows. I expect the PGP community to
propose their own MIME formats - that's why the PGP identifier was
removed from this draft of MIME/PEM.
- Jeff