Jeff Thompson asks,
PEM allows a message to only state the issuer name and serial number
of the sender, in the Originator-ID-Asymmetric field. I know you can
use X.500 directories to look up a user's certificate based on their
distinguished name, but how would I use X.500 to look up a certificate
based on the issuer DN and serial number?
Outstanding question, Jeff! You make the Hit Parade for this week,
and get to advance to the semi-finals. You may also get to have a
new attribute named in your honor in my proposed enhancements
to the StrongAuthenticationUser object class. Let's see.
The perhaps not so obvious answer is that the issuer[Name] and
[certificate]serialNumber attributes should be extracted from the
Originator-ID-Asymmetric field in the PEM header, and used to point to
an ALIAS of the user's certificate DN in the directory. That means
that in order for PEM to work efficiently, that alias has to be created
and present in the directory.
(Now let's see -- does that imply anything about the issuerUniqueID field,
which isn't in X.509 ('88) or in PEM? I'm trying to think carefully, but
I don't think so. The issuerUID allows the issuer to have multiple
certificates under the same name, either in time or simultaneously) for
different purposes, but PRESUMABLY (have we said this anywhere?)
the certificateSerialNumber increases monotonically within the name
space of the issuer's name, NOT within the issuer+UID space. The
subject may have different certificates with different UIDs, but they
would all have different serialNumbers.)
The requirement for an alias also implies some very interesting things
about the distributed knowledge that the X.500 directory needs to
function, and I'm not sure that I understand everything in this area.
Lets say that the DN of the subject is
C=US, O=GTE Laboratories Incorporated, CN=Robert R. Jueneman.
Then the alias might be
C=US, O=GTE Laboratories Incorporated, OU=RSA High Assurance CA,
serialNumber=007
Because of the name subordination requirements of PEM, the issuer and
the subject have the same organizational root. so if you can find one
in the directory, you can find the other.
But now lets consider the case of a residential person. The DN of the
subject is
C=US, S=Massachusetts, L=Acton, CN=Robert R. Jueneman
Lets assume that the issuer is the RSA High Assurance CA. The alias
would be:
C=US, O=RSA Data Security Inc., OU=Unaffiliated User Certification
Authority, serialNumber=12345.
Since Massachusetts doesn't operate a monopoly naming authority,
all of the ADDMDs have to share knowledge of how to find my
certificate. Lets say GTE Labs is operating an ADDMD, and that
my certificate is registered with them. If another user accesses the
distributed X.500 directory through MCI, AT&T, Advantis, or the
US Post Office's DSA, all of those ADDMDs would have to know that
C=US, S=Massachusetts, L=Acton, CN=Robert R. Jueneman is an
entry known by the GTE Labs ADDMD. The NADF's CAN function
is supposed to take care of this, although I have some concern
as to how well this is going to work when we have a million residential
users signed up (some time next week :-).
Likewise, suppose that C=US, O=RSA Data Security, Inc. is listed with
MCI. Then all of the rest of the ADDMDs would know that.
But how the alias C=US, O=RSA Data Security Inc., OU=Unaffiliated
User Certification Authority, serialNumber=12345, which is presumably
listed on the MCI ADDMD, is connected to the "real" entry containing
my certificate, which is located within the GTE Labs ADDMD, is
something that I don't yet understand. I'm going to post this to the
NADF, and ask someone to comment on how this process works.
BTW, the same problem will arise between a PCA and a CA. Since
there is no name subordination requirement between a PCA and a CA,
the two organizations may be listed under two different ADDMS,
or an ADDMD and a PRDMD.
Finally, unless or until something like the NADF is set up on an
international basis, it will be necessary to qualify the user and the
issuer's DN with a country code, just to find any entry at all.
Now suppose that RSA issues a residential person certificate
to Rhys Weatherley in Australia. Now we have an alias in the US
pointed to a entry in the C=AU arc. This is getting to be fun!
(The same issue would also apply to the use of e-mail names as
(part of) DNs. Even though Jueneman(_at_)gte(_dot_)com is unique throughout
the Internet world, without at least saying something like
C=US, emailName="Jueneman(_at_)gte(_dot_)com", ther search problem would
be almost impossible. Of course, that is one more thing we could
burden the DUA with. Anyone got a hand-held Cray, so that
I can make all this work over cellular?)
I want to think about it some more, but I am beginning to think
that the requirement to have this alias should be included in the
StrongAuthenticationUser object class. But until I understand how
aliases work across ADDMDs, I'm not sure just how to proceed.
Bob