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?
Because personal names are not part of a person's identity. They are nothing
but comments that people are able to insert into a subset of addressing fields.
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?
Again, the problem is that it is NOT part of the person's identity. Everyone is
entitled to call everyone else (including themselves) by a different name, and
change their choices any time they want.
I can put any personal name I think is appropriate on your address. In fact
some applications depend on the ability to do this.
And if you put this information into a field that is intended to identify
someone, even if it worked (which it won't) people are guaranteed to be
confused by its inclusion. This is not acceptable.
If you want to provide personal name information, it should be done in a
separate field, e.g. PreferredPersonalName, that is NOT normally part of the
distinguished name, and most certainly not part of the email address.
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.
Not really. You cannot depend on these fields showing up in the recipient's
mailbox, which tends to limit their utility in modern messaging systems rather
dramatically.
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?
No, what were are talking about is an identification field, which is used both
in certificates and to locate certificates. There is no problem with this stuff
being in certificates, but once you make it part of the distinguished name that
you use to find things in some kind of directory (X.500, local database,
whatever) there is guaranteed to be trouble.
Please don't try to tell me this isn't so. We already have fairly serious
operational problems with this issue in the X.500 world on a regular
basis.
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.
Well, since I care about building workable systems I DO care about this. And
frankly I think you are missing any number of crucial issues by ignoring these
matters.
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.
This is part of what I'm talking about. But only a tiny part. The general
problem I'm concerned with here is how you set up and deploy the infrastructure
necessary to support certificates, even self-signed certificates.
There are all sorts of serious issues in doing this. For example, how does a
system set up the correspondence between its users and the certificate
database? You can do this in any number of ways, of course, but when you're
talking about certificates that ONLY contain an email address for
identification purposes you have to use it. And I assert that in this situation
there is going to be MAJOR trouble if you let personal names creep into these
fields.
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.
In other words, you choose to ignore all of the hard parts of the problem, the
part that make simplistic and poorly defined schemes unworkable. And it is
undeniably true that once you ignore all the hard parts of the problem it gets
a lot easier!
The bottom line is that while PEM can cheerfully ignore distinguished name
issues and treat them for all intents and purposes as opaque objects, the same
cannot be said for a system that implements PEM in any useful way.
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.
It is significantly better, in that you haven't put a bunch of possibly
indistinguishable junk around the bare key that could possibly eliminate you
ability to block it.
Put another way, suppose the field for the public key allowed an arbitrary
introductory string that anyone could change any time they felt like it, and
also allowed for the possibly of more than one key in the field with no
well-defined delimiter between them. How would you feel about this identifier?
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.
Again you are focusing on the trivially easy part of the problem. Of course
this is a non-issue when you're talking about something you received from
outside your management domain! Implementatiosn have to provide you with the
ability to bind whatever sort of trust you want to certificates you receive.
This is easy to do and it is well understood. I'm not talking about this aspect
of the problem and I never have been.
What I'm talking about is how you set up and maintain a real infrastructure
within your management domain. This is much more difficult, and it is where
all the problems are.
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.
Well, the problem here is that you don't know what "defines the mailbox
uniquely". All you know is what is *supposed* to define the mailbox uniquely,
and that is the local-part(_at_)domain part of an RFC822 address. The personal
name,
comments, and source route are all supposed to be unnecessary to provide this
unique binding, per RFC822 and RFC1123.
Now, in the real world it so happens that this isn't necessarily true. In
particular, there are plenty of cases where source routes are needed despite
what the specifications say. And believe it or not, personal name information
(or the free form name X.400 equivalent) are sometimes used for message
*routing*. (I know that this makes no sense since these fields are only present
in the header, not the envelope, but nevertheless there are systems that do
this in both the X.400 and Internet messaging worlds.)
However, I have no problem with saying that these are broken and we're not
going to cater to them. In fact that's exactly what I do say.
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.
On the contrary, this doesn't wash when the president of the company tries to
do something only to find that his or her personal name field has changed and
broken things.
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.
No, this should be part of the *definition* of the field. This is a matter for
standardization, not policy. Interoperability is one of the main reasons we
standardize things.
There are also issues of policy here, but I haven't mentioned them yet. And
they can be very sticky. For example, the majority of large commercial sites
these days have deployed or are deploying systems that canonicalize email
addresses. For example, instead of being
ned(_at_)am(_dot_)sigurd(_dot_)innosoft(_dot_)com I would
appear as ned(_dot_)freed(_at_)innosoft(_dot_)com(_dot_) This is done for
security and consistency
reasons (security in the sense that revealing actual hosts people use invites
both traffic analysis and reveals internal network topology, consistency in the
sense that when someone changes positions their address should not be
affected).
It seems clear that the canonical address is what you want in the certificate.
(Note that since you'll be sending certs out use of internal addresses could
compromise security in the same way that header addresses do.) However, this is
not always easy to achieve, since in many cases personal systems don't know
what their canonical address is! They only know their local address -- the
canonical form is generated by some server somewhere else. And there presently
isn't any standard protocol that can be used to retrieve this information.
Note that the policy issues apply to the email id form as well. However, I
doubt that we will address them given the general reluctance of this working
group to ever deal with policy matters, which I feel has been responsible for
lowering the quality of service we're trying to provide a heck of a lot more
than non-cert-based systems do.
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.
There's no problem as long as you know what you're doing and specify what is
right and what is wrong and are able to document it. We do understand these
issues, but we're unable to deal with them in the cert end of things (both
because it is out of scope and we're getting close to policy and we don't do
that). We can at least deal with them partially at the id form level, in that
we can specify syntax.
Ned