Steve,
I not sure that I understand the "implementor's
nightmare" that Jeff Thompson alludes to. I
would be reluctant to change the PEM specs in
so drastic a way as to throw out Originator-ID-Asymmetric
without a really solid reason.
At this time, I think the jury is still out as to how
certificates are to be distributed. I still think that X.500
is a viable candidate, but other mechanisms could be used
as well.
In thinking about my reply some more, a couple of thoughts
crossed my mind. I have not yet received any response from
NADF members regarding the problem of aliases (my machine
was down over the weekend and I'm still trying to recover
some mail). Nonetheless, I don't believe that having an
alias under the Certificate Issuer and certificateNumber
that would point to the real certificate would be a
substantial problem.
I may have missed the point of Jeff's question as to why
the Originator-ID-Asymmetric field was included. If he really
meant, "Why did PEM use this particular scheme, instead
of using the DN and UID of the subject to uniquely
identify the certificate to be used?", that would be
harder to answer. Frankly, I don't recall any discussion
on this point.
Given what we know now about some of the difficulties in
naming, there would seem to be several pros and cons to
this solution:
PRO:
1. The DN of the issuer is likely to be stable, and the DN
plus the certificateNumber makes it easy to check the CRL
list.
2. The PEM specs assume the '88 version of X.509, which
didn't include the UniqueID field. The Issuer plus certNo. is
unambiguous, but the subject DN alone might not be.
3. Including the certificate with the message may disclose
more information than is desired, in addition to being a
substantial waste of bandwidth.
CON:
1. If X.500 is to be used, the certificate issuer has to post
the certificate under his own organizational root, or
at least post an alias to the DN of the certificate. The
user may not want his certificate posted, but he may not
have much control over this.
2. Assuming that retrieving information will have some
cost associated with it, this structure will require
two dereferences rather than one, and will therefore cost
more.
3. There are issues of synchronization and control. Who
decides when the certificate is to be deleted? What if
the issuer deletes the alias pointer immediately after
the certificate expires, but the user might have preferred to
keep his old certificate posted, in order to facilitate
validation of archived documents?
On balance, the existing design seems feasible, even in
an X.500 environment. Although there are some negative
factors, at present these don't seem to be overwhelming,
at least to me.
Bob