Michel Ranger wrote:
If you are a CA issuing identities to employees, and e-mail UAs force
you to provide e-mail addresses, ISAKMP/IPsec forces you to include
your IP address, your fax number, your department number,
and all sorts of other application info, your certificate
half-life could be weeks instead of months or years. ( ie similar to
getting a new badge everytime a new application rolls out, or a piece
of information changes ).
Email is not just another application. In an enterprise, email is
increasingly mission critical and central to business processes.
Enterprises are in an extremely good position to make their e-mail
identity namespace have the exact permanency and uniqueness properties
they require.
David P. Kemp wrote:
1) User agents MUST be able to map certified identities (DNs) to
email addresses, under control of the user.
So, you're proposing pushing the task of managing identity mappings onto
the end user? This is going to end up giving them an extremely
unpleasant user experience. In this situation, what is the value of
having a CA involved in the process at all? The user could just as
"easily" map email addresses to public keys as to DN's.
From: John Gardiner Myers <jgmyers(_at_)netscape(_dot_)com>
Historically my published email address has been more stable than any of
my employer, residence address, or ISP.
Huh? For how long have you been jgmyers(_at_)netscape(_dot_)com? As of Dec
'96
(sasl draft -07) you were jgm+(_at_)cmu(_dot_)edu(_dot_)
Since the time since I was first jgm+(_at_)cmu(_dot_)edu, my published e-mail
address has changed once. During the same time, my employer has changed
twice and my residence address has changed twice (soon to be three
times.)
How, except for intuition, am I expected to know
that the person with a Netscape address is the same person that wrote
SASL?
How, except for intuition, are you expected to know that the "John
Myers" at my previous address is the same person as at my current
address? How are you expected to know that "c=US, o=Carnegie Mellon
University, cn=John G. Myers" and "c=US, o=Netscape Communications,
cn=John Myers" are the same person?
What you should care about is that I wish to be known as "David P.
Kemp" in some unambiguous naming domain of my choice, regardless of
whether I send/get email from/to dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil or
dpk(_at_)erols(_dot_)com
or 138954,2347(_at_)compuserve(_dot_)com or
host13(_at_)ietf(_dot_)fedex(_dot_)com(_dot_)
Even "Elizabeth Taylor" is really "C=US, O=SAG, CN=Elizabeth Taylor" [...]
For professional e-mail purposes, you seem to have chosen
"missi.ncsc.mil" as the unambiguous naming domain fo your choice, and
that naming domain has assigned you the name "dpkemp".
If the DN is the form of identity that people care about, then that is
the form that UA's should present. In that case, there is no reason for
the UA's to map the identity "people should care about" into the form
"people should not care about".
If you want to use the DNS part of an RFC822 address as the naming
authority for your permanent identity, that is fine. You can choose
to get certs with an RFC822 address as your name. But that is a
totally separate function from the business of routing messages to a
location where your UA can find them. Forcing the two to be linked
together in a certificate is a gross layering violation.
I never said that one's canonical, published e-mail address is the same
as the address of the location one's UA picks up messages. It is common
practice, especially in enterprises, for them to be different.
If S/MIME
forces the UA to use the email address in a cert, how could I send
an S/MIME message to my wife from the IETF terminal room?
The same way you send the message from anywhere. You sign with the
private key of a cert conatining your preferred published e-mail
address. You're already going to want the client configured to attach
your preferred e-mail address to the headers.
There is no security benefit to requiring delivery addresses in
certificates, since if the message gets misdelivered it can't be read
anyway. The worst that can happen if the user misconfigures the UA
is that the message won't get to it's intended recipient. Requiring
the CA to certify message routing information will just gum up the
works when the routing is not static.
The CA is not certifying message routing information, it is certifying
an identity which has RFC 822 syntax. It is up to the issuer of the RFC
822 identity to manage the routing, but that routing can be changed
without affecting any certifications of the identity.
* But requiring CAs to certify email delivery addresses for *all*
S/MIME users is unworkable if *any* users change addresses,
and certification provides *no* identity-linking benefit if the
email delivery infrastructure does not enforce name uniqueness.
All of this is true for DN's as well, and I've mentioned before that
DN's permanency and uniqueness properties are no better than those for
email identities.