Subject: Re: Problem for public CAs

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 14 Feb 2000 16:10:05 -0700

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, [email-masked] isn't very helpful either, but
better than [email-masked].

(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 [[email-masked]] 
           [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

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 14 Feb 2000 16:01:05 -0800

At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote:
>as secondary, and the certificate contents the primary information.

 From a security standpoint, this is right. From a UI standpoint, it might 
not be. Assume I have a different email address in my cert than in the 
From: header of a message I send you, that your S/MIME client has informed 
you of that, and you agreed. Now you want to reply to my message. You 
probably don't want to reply to the email address in my cert, but you 
might. There are essentially two From vales: the certificate one and the 
insecure-and-possibly-altered one.

>may be particularly relevant or informative.

Exactly right.

And, no, I'm not proposing a solution here.

--Paul Hoffman, Director
--Internet Mail Consortium