On Tue, 3 Jan 1995 Jueneman(_at_)gte(_dot_)com wrote:
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. 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). 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.
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.
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.
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.
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.
Cheers,
Rhys.
--
Rhys Weatherley, Queensland University of Technology, Brisbane, Australia.
E-mail: rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au "net.maturity is knowing
when NOT to followup"