In any case, it is comforting to know that you only use a bare key in the
particular case of the recipient_ID. And based on what you have said,
although
you have a preference, I assume that the world would not stop if you decided
to
adopt the issuer/serial convention.
You are right. The world would not stop. For RFC 1422 compatibility
mode (i.e. a centralized hierarchy) RIPEM does use the issuer/serial
of the certificate from the recipient's issuer, of course. Using the
public key was just a preferred mode when strict PEM is not required.
For the "direct trust" mode (no third-party issuer) you suggest using
the issuer/serial from the recipient's self-signed certificate. This
could work, but RIPEM doesn't presently store other people's
self-signed certificates, since there has not been a need so far. But
it's not a big change. (Actually what RIPEM does in
1422-compatibility mode is include a Recipient-ID entry for every
issuer/serial that it can find for the recipient, in case the
recipient is certified under different issuers. If the self-signed
certificate were in the database, this issuer/serial would appear
also, making your suggestion work.)
- Jeff
Great!
From the standpoint of ultimately trying to urge some convergence toward a
common set of mechanisms across the various implementations of digital
signatures, I think we have a small stake in the ground on this point from the
RIPEM point of view, at least.
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?
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?
I don't know whether RIPEM currently includes PGP compatibility as a mode, but
would you see any substantial problems with such an approach?
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820