Ned, perhaps we should slow down the volley's. I'm having real trouble in
following your logic. and as I said in my previous message, maybe we should
postpone further debate on this issue until the new draft is available.
However, I will respond to your statements, for upon review I find that you may
have misunderstood my point. Maybe my message was too short? :-)
In order to be concrete, let me propose a certificate that looks something
like
the following:
Certificate=signature{
SubjectDN=rfc822{"Robert R. Jueneman" <Jueneman(_at_)gte(_dot_)com>},
serial=1;
IssuerDN=rfc822{"Robert R. Jueneman" <Jueneman(_at_)gte(_dot_)com>, serial=0;
other necessary junk}
You think this is simple enough, and from the
perspective of someone that deals with this stuff all the time it probably
looks OK. But just isn't that simple.
Let me illustrate this by pointing out a very specific problem in your
supposedly simple example. You've included a personal name field in the
address, and doing so for this purpose is in fact incorrect. Personal names
are
not useful as part of a distinguished name.
I am bemused. You say, "You've included a personal name field in the
address, and doing so for this purpose is in fact incorrect. Personal names are
not useful as part of a distinguished name." What on earth makes you think so?
Remember, what we are doing is binding a claimed identity, presumably of a
person, to a public key. What could possible be more natural than to include
that user's name, as a useful and informative addition to a sometimes arcane
and uninformative e-mail mailbox name? For that matter, if someone want to
include a comment, e.g., Earl "What is it about 'Shall not be infringed' that
you don't understand?" Weaver
<RKBA(_at_)redoubt(_dot_)godscountry(_dot_)idaho(_dot_)us> in an email
name, that very comment may provide a lot of potentially relevant information
about that individual, eithe pro or con depending on the recipient's own
feelings.
They are completely under the user's very casual control, and may in fact
change on every single message a user sends. (I routinely receive mail from
people who do this, and in fact we have a gadget on our system here that
generates random email personal names.)
How droll!
But what we are talking about is the content of the CERTIFICATE, which is
generated and signed once and only once, and distributed by some form of a
trusted distribution (or repetitively over time) to the (potential) recipients.
Did you somehow imagine that I was going to make up a new one for every message
that is sent?
I care not a whit whether the name in the certificate matches the From or Reply
To address in the message, or in fact whether the message is sent via e-mail at
all. All that I was trying to do was to provide a globally unique DN for
inclusion in the certificate, and the use of a unique mailbox name plus a
user's name is certainly sufficient for that purpose.
There are also lots of cases where personal name fields end up getting lost,
removed, or even amended. This is fine since they are inherently write-only
and
only serve to communicate limited information to recipients. They are entirely
untrustworthy and as such any inclusion of them in a distinguished name should
be completely forbidden.
It finally dawns on me that you may be talking about my suggestion that an
on-line certificate generator respond to e-mail messages, and provide a limited
amount of assurance by matching the SMTP-protocol provided e-mail name against
the user's claimed information. Obviously, in this case, the e-mail responder
has no way of verifying the personal name information, or anything contained in
the comment field. All it can do is validate the e-mail name itself, so I could
claim to be "Newt Gingrich" <Jueneman(_at_)valhalla(_dot_)gte(_dot_)com>, or,
if the validation
was limited to simply return the completed certificate,
"Newt Gingrich" <Jueneman(_at_)gte(_dot_)com>. Of course, if my name were Nick
Garagiola,
and our email names were two initials and two numbers, "Newt Gingrich"
<ng01(_at_)gte(_dot_)com> would look rather more plausible -- I'll grant you
that.
However, I was originally talking about a simple self-signed certificate that I
fill out and sign myself. I don't care what the out-of-band trusted
distribution mechanism is -- you and I could meet in the park at midnight and I
slip you a disk, or I could email it to you and have you read me the public key
or a digest thereof for my confirmation or vice versa. the point is that you
know who I am and (re-)validate the claimed identity yourself. If you aren't
comfortable with the name field in my e-mail rsponder generated certificae, you
could do the same thing. I might lie, in this case, but you don't really care
very much or you would have insisted on a higher degree of assurance.
After all, I was comparing that mechanism to your use of a bare key, received
somehow from someone, and with the binding between your identity and that key
known only to me and my trusted cache, unless I issue a certificate containing
you public key and your identity and I sign it, in which case I just became a
CA. How is this any worse? I claim that it is likely to be slightly (but only
slightly) better, or a tie.
Even in the e-mail responder case, I could argue that I don't really care what
your name is per se. I've never met you in person, so I can't confirm that you
are in fact named Ned. Maybe Ned Freed is an anagram of the Transylvanian
nickname for Rumplestiltskin -- I don't know or really care. I can't really be
sure that you work for a company called Innosoft (or Innovative Software, or In
Nose Often, or whatever), either -- in fact I had assumed that Jeff worked for
Netcomm, and that was merely his network service provider.
The only thing that really matters is that when I write to someone who claims
to be Ned, you or someone very much like you answers, and there is a sufficient
amount of consistancy in the replies that I can be reasonably sure that it is
the same person each time. The same thing might happen if I wrote to President
Clinton and he had a carefully trained staff of ghost writers that respond for
him, maybe even a different one every time. This becomes a philosophical
questions -- if I can't tell the difference, then does it matter?
As such, personal name information, along with any RFC822 comments (which are
used for all sorts of things besides communicating names) should not be
included in this field. Doing so will practically guarantee interoperability
problems.
I don't understand the issue of interoperability.
There's also the issue of source routes and percent hacks. I'd be in favor of
dropping the former and would say you have to keep the latter, but this
is also something that would need to be dealt with.
One way of looking at it might be to say that the "identity" being claimed is
simply a destination mailbox, and source routes, percent hacks, and X.400
gateway horrible examples a la Peter Williams are all fair game if they
identify the mailbox uniquely. The fact that there may be other, simpler ways
of identifying that mailbox (and by implication it's owner) may not matter.
I think the fact that you of all people would make this mistake illustrates
the
problems with this approach far more eloguently than anything else I could
say.
I don't know whether I should feel flattered or not. "Praising with faint
damns?" :-)
There are many other problems with the currently defined attributes for RFC822
addresses. For one thing, the ones I'm familiar with are only useful as
information returned by the directory -- they are not capable of being used as
part of a distinguished name. Specifically, they typically allow a list of
addresses rather than a single, canonical address. (This is a matter of
implementation practice rather than what any of the specifications say, I'm
afraid. In particular RFC1274 is silent on whether or not you can put more
than
one email address in an RFC822Mailbox attribute. But you'll find that this is
what happens in practice.)
The attribute specified in v3 merely requires that the e-mail address be in
IA5. What RFC822 itsefl would call the syntax of a valid name, and what the
rfc822 attribute might reasonably call the semantics of that attribute, are
something else. But if an invalid address is specified, the certificate won't
be returned properly. No harm, no foul. I'll agree that including multiple
e-mail addresses in one attribute might result in some weird effects, but that
is something the e-mail certificate responder might enforce as part of its
policy.
The bottom line is that current thinking about this stuff equates RFC822
addresses more with attributes like "GIF image of person's dog" than with
something that's intended to be used as some kind of identifier.
Another, more insidious problem is that the people who defined some of these
attributes obviously didn't know much about RFC822 email. The syntax rules are
appalling, and inconsistent with RFC822. This is not acceptable.
The final, crushing blow comes from the fact that there's no single
standardized attribute to use for this. The one we normally use is what's
defined in RFC1274 (which I note is long past the date by which it should have
been revised). In order for certificates to be at all inobtrusive there has to
be a single, universally standardized attribute for this purpose with
specific,
standardized content. I don't believe this is the case at present, and until
it
is the bar is about 1000 meters up, in my opinion.
Well, not to try to switch horses in mid stream, but I was merely trying to
respond to a request that Steve Crocker and Jim Galvin had made more than a
year ago -- to use email addresses rather than those pesky traditional DNs
becasue there were so much simply, and could be extracted easily from the To or
CC addresses. Now that you have brought up some of these subtleties, I will be
even more interested to read the new drafts to see how you have handled these
issues in the name form and key selector portions.
Bob
The third worst reason to realize that you are in the wrong tattoo shop:
"There's two O's in Bob, aren't there?"
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
FAX: 1-617-466-2603
Voice: 1-617-466-2820