> Based on experience and discussions with various people, we
> explicitly included an option for originators to protect their
> public keys. Insofar as we chose to include this option, I
> guess that makes it a design goal. However, as this option
> was implicitly available from 1421, I do not consider this a
> new precept.
It is not an "option" in the least, because of the arbitrary key
selector which was created to support the new requirement that
users can keep their public keys unbublished. This key selector
appears in the identifier forms which all implementations *must*
support.
I am trying to bring the severity of this to the attention of
everyone. The MIME/PEM security protocol mandated by the key
selector is not open and allowing at all. It obsoletes every
certificate database out there, rather than hooking into
existing systems, because these databases don't store and
authenticate arbitrary key selectors. MIME/PEM has universally
imposed a new procedure.
Jeff,
I'm having a great deal of trouble understanding the problem you're
trying to describe. As someone who has implemented both RFC 1421 and
PEM/MIME I had no trouble with what I understand to be your problem
(which could be wrong, of course). Let me try to describe what I
perceive to be your problem so I can test my understanding.
In your particular implementation of RFC 1421, you take the
issuer-name/serial-number identifier, break out the pieces, and use each
individual to help you identifier the certificate/public-key you need.
In other words, your implementation takes advantage of knowledge of the
structure of the elements of the identifier, that is, you know the name
form is a distinguished name and that the key selector is serial number.
Of course, we did the same thing in our implementation of 1421 but only
because we had to with the particular choice of database we had in that
implementation. The database we have now allows us to treat each
element of the identifier as an arbitrary string (yes, we do still
separate the two pieces). However, I assert that it is possible to
simply treat the pair as a single string and use that as index into a
database.
In any case, the problem you're raising is a local implementation issue.
It's always possible to make poor mechanism choices in an
implementation; we've certainly made our fair share in the code we've
distributed over the years.
Jim