-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE
kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh
HbGVud29vZA==,03
MIC-Info: RSA-MD5,RSA,bv1ts2rP4DRGRxXUQzs979d3ZaU5OrTkjxAXtJmiYAJ
rrutIuNQc6+6BzrqkZ6upeig7qKg63C+AU3Mg3fytrx8VE91MD3+2fHYwoxUaYED
z943S8Y7CNuuuY01cfUcq
Bob,
Rhys and I may have different points of view; this response is mine,
and I presume Rhys will speak for himself.
With all due respect to the effort you have put into
trying to map e-mail names to DNs, I still think you are
trying too hard to solve the wrong problem.
Let me begin with part of the Introduction to the I-D:
However, it will be quite some time before the X.500 naming
authorities and directory servers are wide-spread enough on the
Internet to make the process of a user obtaining a DN fairly
painless....
I actually don't think has been a big problem. My concern is that
we use email addresses in mail systems, and there's no automated way
to relate email addresses to public keys.
===========================================================================
I also don't believe that there is a serious problem of not being
able to map between DNs and e-mail addresses. In fact, I think those
two issues should be kept separate, just as X.400 addresses are
independent of the DN. I may very well want to use my certificate at
work, at home, and on the road, and my e-mail mailbox may vary
accordingly. In particular, why should it make any difference
whether I use my office PC (wotan%gte.com -- an ugly artifact of our
firewall system), or whether I log on to my Unix mail server as
rrj0(_at_)bunny(_dot_)gte(_dot_)com, or whether I send and receive mail using
Compuserve or AOL, there is no reason why my certificate should
change.
Well, there's an inherent tension between associating public keys with
email addresses versus keeping them separate. I agree that you may
need multiple email addresses, and this can cause a problem. But at
worst, this simply means that some users will continue to have to
build manual associations between your email address(es) and your
public key.
Let's consider how we send and receive certificates, and for what
purpose.
If I receive a signed message, I will want to validate it using the
originator's certificate. Eventually, it would be nice to have a way
of caching or looking up these certificates, just to cut back on the
bandwidth, but for the moment it is perfectly feasible and in fact
the encouraged practice for the originator to include his entire
chain of certificates within each message. So we really don't have a
practical problem with certificates on incoming messages.
Well, we've been through this cycle. At first, we included
certificates only when requested or when we thought the recipient
might need them. This was awkward, and some of us switched to sending
them all the time. This bloated the messages and made them ugly. One
can argue that the user agents should be fixed to ignore certificates,
but that ignores the reality of the situation. It also doesn't help
that the certificates come before the text of the message.
It would be better, I believe, if there were a way to fetch the
certificates. I think it was a mistake not to define a certificate
server as part of the protocol. I suppose X.500 directories were
supposed to be ubiquitous by this time, but they're not. I think a
widely used PEM implementation has to include mechanisms for providing
certificates on demand.
In the case of encrypted messages, we have two cases -- one where
the message is a reply to another message that is at least signed,
and one where a new message thread is initiated. In the case of a
reply, the certificates are already in front of our nose, so to
speak, so using them to encrypt the reply should be no great
problem.
Yup, this actually works ok, except for the rather substantial detail
of causing the incoming certificates to be stored and of specifying
that you want to use these for encryption. To be clearer about this,
suppose you send me a signed message, and I want to send an encrypted
reply. Here's what happens with our present implementation.
When I receive your message, which we're assuming contains your entire
certificate chain, I have the option to ask that these be stored. At
the same time, I'm queried as to whether I want to associate any
aliases with your certificate. Note that there are two decisions I
have to make, one of which has trust implications.
Having succeeeded at that, I'm now in a position to send you an
encrypted reply. If I've carefully associated your email address with
your certificate, the rest is automatic.
In practice, I discovered that I sometimes had to interrupt the
message composition process during a reply in order to reprocess the
recently received message and get the right association for the email
address.
Yes, we might fix some of this with a better user interface. For
example, we could jigger the reply function so it extracts the
certificate from the message being replied to, but this is not
entirely troublefree. Since there is no required relationship between
the certificates in a message and the sender's email address, I would
still have to be queried as to whether I meant to use that certificate
to reply to you.
The real issue seems to be how to file incoming certificates so that
the user can later retrieve them, and how to coordinate the
certificate with the e-mail address for encrypted mail.
Yup. That's the issue. And the corresponding issue of accessing the
certificates once they're filed.
Steve Crocker has argued that he believes that the e-mail name is
all-important, but I think that this may be a point of view that
reflects the experience of relatively long-time Internet users who
either work for small companies or got in early and can still use
short, almost "vanity-plate" mailbox names.
Sure, (assuming that people can remember how to spell Jueneman,)
Jueneman(_at_)gte(_dot_)com or Crocker(_at_)tis(_dot_)com, or
Kent(_at_)bbn(_dot_)com is short and
easy to remember. But Christian Huitema
<Christian(_dot_)Huitema(_at_)sophia(_dot_)inria(_dot_)fr> and Mr Rhys
Weatherley
<rhys(_at_)fitmail(_dot_)fit(_dot_)qut(_dot_)edu(_dot_)au> and Frank Sudia
<p00561(_at_)psilink(_dot_)com>
simply strain my brain. I called Rhys "Weatherby", which is the name
of a fine brand of rifles and shotguns, and Lord knows how many
times I have mangled Anish Bhimani <anish(_at_)ctt(_dot_)bellcore(_dot_)com>.
Wish we
all had names like Kent(_at_)bbn(_dot_)com!
Yes, there's no question that email names are not completely
descriptive. Email names may have to change over time, and/or there
may have to be a way to associate more descriptive information with
email addresses, but that's a long term email problem, not a PEM
problem. Or, to put it another way, I don't think PEM has enough
leverage to fix this fairly large email problem.
Maybe it's Alzheimers (what was I saying?), but I have to look up
such names, and I don't look them up by their e-mail name. Instead,
my pretty brain-dead mailer allows me to store names like "Huitema,
Christian" <Christian(_dot_)Huitema(_at_)sophia(_dot_)inria(_dot_)fr> and
that is they way
I look up even people who work for me -- by last name (because we
tend to assign mailbox names based on initials, and then allow users
to set up aliases if they wish.)
If we had a deployed infrastructure of mail systems which provided
easy to use mechanisms for related descriptive names to email
addresses, then we'd be in better shape. But we don't.
My FAX mailer is organized the same way. Neither is as smart as my
Wizard, which allows me to search for any portion of the string (in
case I can remember "Christian" or even "Christ" easier than
Huitema. and neither are as friendly as Quicken, which attempts to
guess what I am going to type based on the first several characters.
But I can live with thes limitations, and I suspect that most users
could. I have almost 300 entries in my Wizard's Rolodex, and I don't
send mail to nearly that many people.
Note that I am NOT arguing that instead of thinking of me as
Jueneman(_at_)GTE(_dot_)COM, that Steve should be thinking of me as C=US,
O=GTE
Laboratories Incorporated, CN=Robert R. Jueneman. He is correct,
little if any of the software available is organized like that, and
perhaps none should be. Instead, he should probably think of me as
just "Bob", with further qualifiaction depending on how many Bobs
are in his list of correspondents; or alternately as "Jueneman,"
with the same proviso.
Getting back to your scenario of replying to an incoming message, if
there were a way to associating public keys with email addresses, then
I could simply reply to your address and choose to encrypt it. I
often look up an old message and reply to it instead of filing away
the address and having to make up a private alias. Making up local
aliases is hazardous anyway. You might be the most obvious bob in my
life this week, but some other Bob will get my attention some other time.
Once the user has made a stab at the name, his mailer/PEM/Directory
user agent ought to finish the job, and present both the proposed
e-mail address and certificate for his review and confirmation.
Depending on the use that is intended, a different e-mail address or
different certificate might be selected.
This would be nice, and it would indeed help. However, it also forces
an interactive process. PGP benefits from being able to run in batch
mode.
In a previous message, Steve Crocker said
I've come to believe this point is fundamental. Various of us have
spent time and energy facilitating the use of PEM by designing
makeshift techniques for splicing PEM into the mail systems. The
"state of the art" is this. When a new certificate arrives, my system
either proposes the likely EN to DN correspondence or asks me for the
EN side of the correspondence. This requires manual operation each
user's part, is subject to error, and has no traceability. From a
security analysis point of view, this is not a great design. It also
fails on human factors and scalability grounds.
I don't have any objection to introducing distinguished names which
are descriptive if they're an adjunct to ENs, but I think it's
essential that we reorient PEM to use ENs as the base.
While I respect his judgment and opinion, I disagree with him on this. If his
system requires him to file a certificate under a user's e-mail address
instead of a nickname or other more friendly index, I think that is his
systems's fault, and he ought to go get another one. Even if he likes using
e-mail names as an index to certificates, his system ought to be able to use
the From: or Reply-To: address as the e-mail address under which to file it.
Marshall Rose made a very good point in one of his tutorials on
X.500. He said something to the effect that "user friendliness"
should be a property of the Directory User Agent, and not
necessarily of the Distinguished Names themselves.
I have no problem with this principle.
The local UA should have the responsibility for turning
user-friendly nicknames into DNs, and then looking up e-mail
addresses and certificates.
Where do the user-friendly nicknames come from, and what provides the
correspondence between DNs and email addresses?
I think the natural conclusion of this line is that every user has to
build up a private directory and maintain it himself. I don't think
this scales at all. As things stand now, once I know your email
address, I can send you mail. I think you're saying that if I want to
send you encrypted mail, I have to know your email address, I have to
separately obtain your certificate, and I also have to manually build
an entry into my private directory in order to associate your
certificate with whatever handle I will use to retrieve your
certificate. Good user interfaces will make this easier, but I think
it's fundamentally harder than it needs to be.
X.500 is not required for this purpose, and the correspondence
between the DN in the X.509 certificate and the DN of the user's
entry need not be particularly strong.
With regard to the security analyst's point of view, I would hope
that the user is examining the entire contents of the X.509
certificate before deciding whether to spill his guts in an
encrypted message which is sent to the wrong person. If you are
basing such decisions on the user's mailbox name, you have a pretty
shaky assumption. I can't evaluate the human factors aspect of his
argument, for I don't know how the information is being presented.
But we had a decent interface for such functions up and running
several years ago.
I don't buy the scalability argument at all. Most users only
correspond with a few dozen users at most, so almost any means of
storing those certificates will work. Now if you want to find
someone's certificate in the Manhattan phone book because you want
to send an encrypted order for take-out-Chinese and you have never
order from that particular store before, that is a different
problem. But I don't believe that is what is holding PEM back from a
wider success.
Actually, I would like encryption protection as a norm. It doesn't
make any sense for public discourse like pem-dev, but for ordinary
direct messages, I'd like to invoke encryption automatically.
Having said all this, I don't mean to imply that having the ability
to put an e-mail name in a certificate would be of no value. Of
course it would, as would lots of other non-DN attributes. But so
far I am not convinced that changing PEM and the various certificate
generation programs would be worthwhile at this time.
Other non-DN attributes aren't equivalent. The email address address
is special because it's part of the infrastructure.
If you can convince the IETF to sponsor a revision to X.509, as I
tried to without success within the last month, more power to you.
The same goes for adding ANY new attribute, whether domainComponent,
rfc822Mailbox, or whatever -- the DUAs and PEM programs won't
support them.
It may have been premature to attempt to depend on X.500 technology
and the associated standards process to the extent we have. If this
were a format defined within the IETF, we'd be able to transform our
implementation experience into the necessary changes in no time at all.
For the short term, pragmatic solution, therefore, if you want to
have some additional level of assurance regarding the binding of the
user's mailbox to his name and to his public key, I would suggest
that you not worry so much about making it machine parseable, but
simply include it as a human recognizable string within the common
name.
With this scheme, the DN in my X.509 certificate would read
C=US,O=GTE Laboratories Incorporated,
CN="Jueneman, Robert R."<Jueneman(_at_)GTE(_dot_)COM>
Frank Sudia's DN might be
C=US, S=New York, O=Bankers Trust Co.,
CN="Sudia, Frank" <p00561(_at_)psilink(_dot_)com>
and Rhys Weatherly's DN might be
C=AU,
stateOrProvince=Queensland, [Is Queensland a state, province,
territory, or what?}
l=Brisbane,
O=Queensland University of Technology,
OU=Gardens Point Campus, [optional]
CN="Weatherley, Rhys" <rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au>
Or, if Queensland University of Technology doesn't want to sponsor
or register Rhys, he could use a quasi-residential address:
C=AU,
l=Brisbane,
streetAddress="c/o School of Computing Science,
Gardens Point Campus,
Queensland University of Technology
2 George Street
GPO Box 2434"
postalcode="4001",
commonName=" ""Weatherley, Rhys""
<rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au> "
(Note that the c/o (care of) does not imply that he works for or has
any authority within the School of Computing Science. A monkey in a
cage could be addressed this way, without any expectation of
liability on the part of the institution if the monkey signed
something.)
I don't have any problem with this proposal as long as we also agree
that this syntax necessarily stands for the email address. There may
also be a problem with the character sets, but if there's a way to
cram the email address into the CN component, that's also an
acceptable approach. There are pros and cons to parsing out the
domain name. Rhys has presented a competent proposal which parses out
the domain name. I'm comfortable with it, although there are some
complexities which need to be discussed. It also fits in with
forthcoming work to be done on tightening up the doamin name system.
However, the alternative of simply including the email address in the
CN component or something similar.
Assuming he sends a certificate containing that DN to a low-assurance PCA
operated by TIS, RSA, COST, or anyone else, and that they certify him as a
residential person, he is up and running. If and when he wants to enjoy the
presumed benefits of something closer to an open-EDI architecture and have
his signed statements viewed with the same authority as a personal check,
he will probably have to join up under a higher assurance PCA, or find some
more than usually trusting individual to "cash" his electronic check.
Sorry this was so long winded, but I really think that we would be
going down the wrong track for the wrong reasons if we adopted the
use of e-mail names INSTEAD of the more traditional civil authority
DNs for use within PEM certificates, (except for Persona
certificates, where it doesn't matter). If we can incorporate them
in ADDITION to the "normal" DNs, that would be great.
In addition is ok with me. And it's also ok with me if not all
certificates fit into this model, but I think there has to be enough
support for this to make it easy to access certificates by email address.
Both Rhys' proposal and your "add it to the CN" proposal are in addition.
Comments, rejoinders, or miscellaneous flames? (BTW, I hope it was
obvious that I was not attacking either Rhys or Steve personnaly.
They've done some excellent work, and I respect that. I just
disagree with their proposed direction.)
Thanks.
Steve
-----END PRIVACY-ENHANCED MESSAGE-----