Jeff, I hate to waste the bandwidth exposing my ignorance , but I am at home
and don't have the PEM/MIME spec to refer to. I guess I didn't understand
their
key selector requirement -- can you educate me?
If I wanted to store PEM/MIME certificates in an X.500 directory, perhaps
using
the Bell Northern Entrust program, do I have to do something new?
Yes.
If I create and certify a certificate using the RSA/BBN SafeKeyPer box, do I
have to do anything new?
Yes.
Bob
All databases which currently store a certificate must be modified to
store a key selector also. This means the certificate server at
RSADSI won't work with MIME/PEM. The RIPEM 2.0 database which
implements RFC 142x won't work with MIME/PEM.
Also, instead of opening up the trust mechanisms, MIME/PEM now imposes
a new and universal constraint. All keypair holders must now choose a
key selector to place in the Originator-ID field. This means the
Macintosh AOCE signer file, which works great with PKCS and could
easily be used to format an RFC 1421 signed message, cannot be used
for MIME/PEM because it doesn't contain a key selector. If you use
the Bell Northern Entrust program the maintain one keypair for
signatures and another for encryption, it must now be modified to
conform to the MIME/PEM imposed scheme by maintaining a new key
selector field to distinguish them. It won't work as it is.
Jim Galvin writes:
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.
What he's saying is: "So what's the problem? Just modify your
implementation the same way we had to modify TIS/PEM to get it to work
with the new scheme." The "poor mechanism choices" already exist in
AOCE, Persona server, and every other deployed system. These will all
require a redesign their "local implementation issues". I think this
is an unacceptable approach for a standard which is supposed to be
accomodating to a variety of models. We need to remove the arbitrary
key selector field from the identifiers.
- Jeff