Bottom line -- I'm not yet convinced of the need to adopt
additional mechanisms, when what we have available now can solve the same
problem and be more compatible with existing standards and implementations.
Thanks for writing this out explicitly, Bob. I've gone through
similar thought experiments and come to the same bottom line. When
you asked Jim Galvin to explain why the key selector is in MIME/PEM,
he quoted the spec where it says that we need to distinguish among the
possible keypairs for a users. True, but the public key itself does
this just fine. When I asked why it has to be an arbitrary key
selector instead of just the public key, Jim responded by explaining
how easy it was for him to implement the arbitrary key selector in
TIS/PEM. This is not an explanation of why the public key doesn't
suffice. Your thought experiment shows quite well why identifying a
keypair with anything more than the public key is an unjustifiable
complication.
Thanks, Jeff. I'm well aware of the fact that I often tend to ramble on,
exposing my thinking process as well as the conclusion, to the point that some
people probably have my name in their kill file. But if I don't write out the
steps, I don't understand it, and if I can't convince myself I'm not going to
be able to convince anyone else. At least this allows people to point out flaws
in the logic, assume we agree on the premises.
Even as I comment again on the key selector attached to the name form,
let me be clear about my position. The public key is all we need in
the Originator-ID and Recipient-ID fields. If there is certification
or name information which the recipient of a signed message might
find useful, it should be placed in the application/pemkey-data body
part, and the public key in the Originator-ID can be used to locate the
appropriate certificate or other sort of name/key binding. This is
nice for several reasons:
* There is only one identifier now for Originator-ID and Recipient-ID
fields. (Hooray!)
* People can still convey the same certificates that they use in RFC
1421 Originator-Certificate and Issuer-Certificate fields by placing
them in an application/pemkey-data <certchain> field, just as we
always planned to do with MIME/PEM. The public key in the
Originator-ID can be used to find the intended
"Originator-Certificate".
* People could even stick a PGP certificate in application/pemkey-data
if a field were invented for that. An RSA public key is an RSA public
key, even if the public key in the Originator-ID is encoded in DER as
a SubjectPublicKeyInfo, as opposed to PGP encoding. A PGP-aware
application could still use it to find the PGP certificate. I'm not
proposing that this is where we should integrate PGP into
MIME. It'sonly an example to show how the approach is open.
* I might have a distinguished name certified for my public key under
the RSADSI hierarchy, and I might also have jefft(_at_)netcom(_dot_)com
certified
under a different hierarchy that only does email addresses. Under the
identifier-with-name scheme, I would have to choose whether I want to
put my distinguished name or my email address in the Originator-ID
field of a message I sign. But how do I know which will be useful to
the recipient? I don't. The fact that this problem arises shows that
naming information does not belong in the Originator-ID, which only
needs to say what public key will verify the message. Naming is a
problem for *certification* information, not key identification. The
right thing to do is put my public key in the Originator-ID and put
*both* my distinguished name and email address certificates in the
application/pemkey-data. The recipient can use either of these or any
other available information to find a trusted name/key binding.
Extending that thought a bit, ultimately we may have a number of different
algorithms that might have to be supported, including the NSA MOSAIC/TESSERA
system, DSS, and perhaps others. Likewise, the originator may be certified
under more than one hierarchy, and perhaps the recipient believes one hierarchy
but knows nothing about the others. We should be able to include multiple
certificates as necessary, presumably with different public keys. The recipient
can still sort them out based on the publc key.
* Putting the name form specifications in the application/pemkey-data
area correctly conveys their optional nature. Paul Lambert was right
when he wrote:
This is not a problem of mechanisms, but of requirements. It is true
that many interesting mechanisms can be defined to distribute public
keys. Not all of these mechanisms are necessary. As a working group
we need to focus on what requirements MIME-PEM should address.
The released Internet draft puts the name form definitions right in
the identifiers, indicating that a compliant application must support
them all. This is part of the problem. Not everyone will want to
support them all. Putting the various name forms in the certification
information allows the distinguished name people to skip email names
for now and vice versa. People can get up and running right away.
Better yet, use X.509 v3 and include both the DN form (I presume you mean the
organization/geopolitical naming schme) and the e-mail address and anything
else you want in one certificate, so that those alternate forms are
cryptographically bound with the same degree of certitude, even if that
certitude approaches zero if the certificate is self-signed.
* Finally, it is true that I have a problem with the arbitrary key
selector for many of the reasons that Bob points out and I have
before. But for now, the point I'm making is that the name forms
don't need to be nor belong in the Originator-ID or Recipient-ID at
all. Only the public key. Even though I think the arbitrary key
selectors should be dropped, if I saw them move, along with the
multifarious name forms, into application/pemkey-data, I'd have made
my point.
I guess I could agree with that also, albeit VERY reluctantly.
Bob
--------------------------------
Robert R. Jueneman
Staff Scientist
Wireless and Secure Systems Laboratory
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820