I guess that my overriding concern is that the hidden agenda behind the use
of a key selector as opposed to the certificate issuer name and serial
number is the desire to abandon the use of certificates entirely and simply
embrace the PGP direct trust model directly.
*sigh* You are obviously biased.
I never claimed that I wasn't! It's just that our biases differ.
The key selector (really identifier)
mechanism of MIME/PEM has nothing whatsoever to do with PGP beyond borrowing
a few convenient identification forms (which PEM should have had in the
first place anyway).
This is what wasn't clear, and still isn't. No one has yet made a compelling
case
for why keys need to be identified indepently of certificates, or alternately,
why
a different scheme for naming certificates is required.
Direct trust is not aided by key selectors one whit.
Direct trust is a process by which person A signs person B's identifier I
and key K to say "person B is known by the identifier I and is indeed in
possession of key K". This can be done with certificates, as ably
demonstrated by a document posted to this mailing list quite some time
ago. The key selector of MIME/PEM merely provides the I portion. The
direct trust itself needs additional steps.
Perhaps I was overly broad. I agree that direct trust can be implemented by the
use
of several forms of certificates, and I am not all opposed to that, especially
as a
means of bootstrapping ourselves into operation. My concern, however, is that if
keys are referred to directly, in the absence of a certificate issued by
SOMEBODY,
even the user himself, then the key/certificate distribution problem will tend
to
go completely out of control, and certificate revocation mechanisms will be
almost
impossible. This concern is compounded by the lack of any compelling reason to
change, to date. But I'm still willing to keep an open mind.
If that really is the
bottom-line issue, then I am absolutely adamently opposed to approving the
PEM/MIME spec as an Internet standard, no matter how many potential users
there might be, because of the damage I think that would do to other
potential users of a more far-reaching national or international public
key infrastructure.
There will be no potentional users of this public key infrastructure at
all until we actually get the software deployed. As Amanda said, every
day that MIME/PEM is delayed is a day in which she loses money. The
infrastructure will not be deployed at all if she and others say "Stuff
it, I'll clone PGP instead". I myself am giving serious consideration
to implementing a product which supports both PEM and PGP. I am also
realistic enough to realise that most users will switch it into
"PGP mode" and leave the PEM code sitting there doing exactly nothing.
One doesn't argue with users. One loses customers that way.
There clearly isn't anything stopping Amada, Ned, Jim, or anyone else from
releasing and selling their products, with or without a standard or someone's
imprimature, most certainly not mine. (In fact, your concern for their welfare
is
rather touching. I didn't realize that you were actually willing to PAY for any
of
this stuff! :-)
However, at least here in the US there are a number of other applications that
are
waiting in the wings that might end up dwarfing MIME, and even e-mail itself as
the
"killer application," including the use of the PKI infrastructure for income tax
reporting, insurance/benefits claims processing, etc., with agencies such as
the US
Postal Service getting geared up to play a major role. Although I would like to
support interested vendors in this community as much as possible, I don't want
to
do it at the expense of screwing up the broader base without due deliberation.
Others may and undoubtedly will disagree with me, both with respect to my
vision of
the future and how we should get there. It is also fair game for those members
of
the WG who are outside of the US to scream bloodly blue murder about my applying
what I consider to be national objectives and considerations to this discussion.
But that's how I feel.
What I really don't understand is how the use of an e-mail address as a key
selector is helpful at all, since I may have many different keys/certificates
that I use for dfferent roles at the same e-mail address.
This problem is solved on the sender side with a handy little program gadget
called a "menu". You type in an e-mail address and it gives you a list of
all attached keys and certificates together with whatever role information
you have assigned to them. This role information may even be embedded in
the certificate. You then choose the one which is most convenient for your
purposes.
Paraphrasing what you said, you type in some form of a directory lookup index
into
your local directory of certificates, and it returns a possible choice of
certificate/roles. I would certainly rather type in "Rhys," rather than a full
fledged e-mail name, and I would rather have the directory return both the
e-mail
name and the choice of certificates. But I still don't understand why the e-mail
address or other form of key selector other than the certificate issuer/serial
has
to be conveyed in the protocol or even addressed in the spec, as it appears be
purely a local matter.
Maybe I am particularly dense today (flame-bait on! :-), but I still haven't
seen
any justification for this "feature" other than arm-waving.
Sending along the key selector thus found to the recipient helps their
software choose the right key to use without going through the guess-work
of "try all of them until one works". A person with 20+ smart cards is not
going to be very happy putting them all into the slot one after the other
until one works so he can read an encrypted message. He wants his computer
to say "insert smart card number 12". A recipient of a signed message is not
going to be too happy if a database lookup returns the wrong key because
the search could not finely pinpoint the right one based on the name alone.
Anything the sender can do to aid this process is a bonus. It used to be
done with issuer names and serial numbers. Now it is done with arbitrary
strings. Big deal. Conceptually there is no difference.
I'll buy the need to facilitate this process. When I cavalierly suggested that
the
recipient try all his keys, I clearly wasn't thinking about individual smart
cards.
Point well taken. Now tell me how the sender knows anything about where and how
the
recipient's keys are stored, and how the originator and the recipient are
supposed
to coordinate their knowledge of this facilitating information?? If the
identification of the right certificate/key can be accomplished using issuer
names
and serial numbers, what is the motivation to do something else?
Likewise, I don't
understand the intent behind specifying some completely arbitrary private
name
string as a key selector.
For all intents and purposes, DN's are completely arbitrary private name
strings with no verifiable mapping onto real Internet entities. Big deal.
The DN can and should represent the user in some fashion. Whether that is the
organizational style DN that is used to look up an e-mail address, or whether
the
e-mail address itself is used as a DN (or the international telephone number, or
the DUNS number, or a digest of the certificate or key itself) really doesn't
matter too much, as long as there is SOME kind of a directory. What I am trying
to
avoid, however, is having to support N-squared different relationships between
all
possible originator and recipient directories.
Regards,
Bob