This has been a fascinating discussion, in part because
of the multi-dimensional aspects to the problem.
Let me see if I can summarize some of the different points of
view:
The first issue raised was one of privacy, and in particular
the possibility of spam. This reminds me of two lessons
I learned so time ago, rather forcefully, with regard to this space.
Back in the PEM days, I was concentrating on the question
of how to ensure the legal sufficiency of a digital signature
to assure nonrepudiation, and I was suggesting that full
name, verified address, and perhaps social security number
or driver's license number be included in the certificate.
John Gilmore brought me up short by pointing out that
we were supposed to be talking about privacy ENHANCED
mail. Point taken -- some of this stuff needs to be optional.
Then a few years later, I was trying to solve the problem of
uniquely identifying someone in a directory, given the presumption
at the time that multiple directory service providers (e.g., telcos)
might exist and might have overlapping geopolitical boundaries.
The answer to this problem, it seemed to me, was to include
sufficient disambiguating information, such as street address,
assuming that there wouldn't be two people with the same name
in the same household. Sharon Boyen gave me another much
needed lesson in political correctness by pointing out that many
women, in particular, weren't about to list their residence address
in a public directory, and many wouldn't even list their given names,
preferring to be listed as "M. Smith". Point taken again. If necessary,
include meaningless qualifiers such as employeeID for uniqueness.
So these are legitimate issues, and I suppose that spam mail is
the virtual equivalent of stalking.
So I accept the position that says that an e-mail address should
not be required, either in the DN or the subjectAltName, although it may
be desirable.
This bears on the second issue, which I raised at the November
meeting, where I pointed out that it was all too easy to manipulate
the From address in an e-mail so that the addr-spec portion would match
the e-mail address in the certificate, and yet the user-friendly portion of
the name could be completely bogus and seriously misleading.
I now think that I agree with David Kemp -- this is primarily a man/machine
interface issue.
In other words, the conventional paradigm of presenting the From address
as the primary identification of the sender is WRONG in the case of a digitally
signed message, and especially so considering how easily it can be forged
or manipulated.
Instead, in the case of a signed message the From address should be viewed
as secondary, and the certificate contents the primary information. The
"contents": in this case should probably include the DN and the subjectAltName,
even if it takes an additional line of the GUI display.
Of course, we have to face the fact that NEITHER the DN nor the RFC822 address
may be particularly relevant or informative.
In the case of the DN, at least from the perspective of someone who works
for a directory company, the DN is probably going to be whatever it is
today, not withstanding the fact that directories today are primary set up
for the convenience of the system administrator, and secondly for the benefit
of users within the organization, and thirdly if at all for the benefit of users
outside of the organization. In my case, for example, my directory name
is bjueneman.nsrd.prv.novell (note the "backwards" presentation order), or
o=Novell, ou=prv, ou=nsrd, cn=bjueneman. Hardly very helpful to someone
on the outside, and certainly not what I would like, but unlikely to change
any time soon. Of course, bjueneman(_at_)novell(_dot_)com isn't very helpful
either, but
better than graybeard123(_at_)aol(_dot_)com(_dot_)
(Public CAs may not have this problem, as they would tend to put "meaningful"
names in a directory.)
So the ugly fact of the matter is that both DNs and RFC822 names are
really the result of legacy systems, and are unlikely to change or to be
very helpful. So neither is really satisfactory.
My preferred solution? Use an _additional_ subjectAltName to convey the
person's "real" name, suitably qualified if desired. And leave the directory
DN to the directory administrators, and the RFC822 name to e-mail
administrators. Render unto Caesar ....
Then in the message display, present the subjectAltName containing a
commonName format as primary (if present), the RFC822 address as
secondary (if present), and the DN as supplemental information (if present).
IN order to assure at least some semblance of uniqueness, either the
RFC822 name or the DN MUST be present, and the "real" commonName
SHOULD be present.
The banner portion of a signed message from me would then be properly
displayed as:
Signer: Robert R. (Bob) Jueneman [bjueneman(_at_)novell(_dot_)com]
[o=Novell, ou=prv, ou=nsrd, cn=bjueneman]
The From address, i.e., what the RFC822 From address itself was, would
not normally be displayed, except by viewing the message in RFC822 format.
I believe that the combination of these three different name forms will be
sufficient
to adequately disambiguate the sender of a message, and to prevent all sorts
of mischief and possible accidents.
If this is the display format, I don't care that much about what the name
matching
rules are, or even whether name matching is done at all. So far, name matching
seems to be causing more problems than it solves.
Comments?
Bob