Just as a matter of curiosity, why do you think that a bare key is
more useful for encryption than for signature? I have tended to think
that there was a very strong duality between the two concepts, and
almost always what was required for one was required for the other.
I should think that the need to be reasonably sure exactly who it was
that you were confiding your deep dark secrets to would be very similar
to the need to verify your correspondent's bone fides before believe
him. Why then would a bare key be more useful for encryption?
There are cases where I explicitly want anonymous but secure
communication.
There are cases where I have obtained someone's public key through some
other channel, and don't want arbitrary observers to be able to garner
any additional information about what entity that key is associated
with.
Basically, certification does not necessarily happen in-band, and in
such cases all you need or want is the key.
Well, here is something that is at least concrete. Rhys Whetherley observed
something similar:
As you say, it is necessary to verify who you are sending to. But that is
done _before_ the encryption takes place. Once you've verified it,
there's no need to send a full certificate to the recipient. They know
who they are and have a secure copy of their own key (one hopes anyway).
However, they might have multiple keys which necessitates sending some
kind of key selector or bare public key to tell the recipient which of
their many keys was used to encrypt the message.
I agree with both of you, so please pardon me while I think aloud for a
bit...
[ Thinking allowed deleted :-) ]
Unless the recipient uses a different key for each different mailbox address,
I
don't yet see how the key selector mechanism really solves this problem. I
suppose you could put something in the private name space to say "this is from
the friend you met last night -- use your key number 3 and my key number 17."
But did I miss something? All this seems like a lot of trouble for two
consiprators to go to -- they might as well agree on a secret triple-DES key
and be done with it, or just talk in the parking lot while they are secretly
exchanging disks.
Bottom line -- I'm not yet convinced of the need to adopt addition 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.
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.
* 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.
* 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.
- Jeff