Is there anyone else out there tracking this thread? Does anyone else
see the problem or the lack of one? I think Jeff and I could both
really use some alternative insight.
The ">" is from Bob Jueneman and the " " is from Jeff Thompson.
> 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.
No.
> If I create and certify a certificate using the RSA/BBN
> SafeKeyPer box, do I have to do anything new?
Yes.
No.
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.
Jeff, if you're storing certificates in a database what is the index for
looking up in the database? Are you using only the public key? This is
real important, Jeff. Is there more than one index into your database
or is there exactly *ONE* way to retrieve a certificate from your
database, that being the public key?
If you say there is more than one index, than I fail to see a problem.
If you allowing looking up by distinguished name then you are
effectively looking up by a string with structure. Well, an identifier
is just that.
I just don't see how it can be any harder to lookup by distinguished
name than by email-address/selector.
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.
Not true. If you choose to use only your public key or only your
certificate containing your public key you do not need a key selector.
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.
False.
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.
False.
> 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.
I shouldn't have opened this door. We changed our database mechanism
for reasons completely independent of the identifier issue. As it
happens, we could have supported the identifiers in the old
implementation but changing our database made it much easier.
Jim