pem-dev
[Top] [All Lists]

Originator-ID-Asymmetric and X.500

1994-03-14 10:45:00

JeffT at RSA writes:
Let me ask the following question: Why have an
Originator-ID-Asymmetric field at all when an Originator-Certificate
works just fine?  Why was it put in the standard?  It is an
implementor's nightmare.

Bob J at GTE responds:
I think the assumption was that it was desirable to cut down on
all of the clutter that results from including all of this information
in the message every time.

Whether or not we ever have an X.500 DUA which will support
this, it is still desirable to retrieve a certificate from your local 
cache based on the Originator-ID-Asymmetric, rather than 
having to spend the bandwidth of including the certificate
in every message.

Since the Originator-ID-Asymmetric lists the Issuer Name and Serial
number of the sender's certificate, a recipient who didn't have the
sender's certificate would only have the certificate Issuer Name as a
starting point for a certificate lookup.

This would appear to be a major roadblock in using X.500 to serve PEM
certificates. 

The conclusion I would draw then is that unless a CA makes all of
their issued certificates available by serial number the current
Originator-ID-Asymmetric will only be used when a sender assumes that
the all recipients already have their certificate.

It seems that inclusion of the Originator-Certificate is the safest
thing to do in all cases, perhaps it should always be required.

If there really is a desire to cut down some bandwidth, I would
propose a replacement to the Originator-ID-Asymmetric which would
appear to be more useful.  Why not identify the sender by the Sender's
Name and Public Key (or hash of the public key as Carl Ellison
annually suggests) ?  In case a recipient already has the right
certificate, this would seem to be a fine way to look it up.  If the
recipient does not already have the right certificate, an X.500 search
could start with the sender's DN.

Perhaps the Originator identification mechanism should be even more
flexible to accomodate other more "local" means of identifying a
sender to a recipient (like email address or something).

Cheers,

Steve Dusse
Mud-stirrer

<Prev in Thread] Current Thread [Next in Thread>