Subject: Re: Problem for public CAs

From: "David P. Kemp" <[email-masked]>
Date: Wed, 9 Feb 2000 12:14:19 -0500 (EST)

Russ,

Please describe a security vulnerability that is caused by lack of
email address in subjectAltName.

* In the case of authentication:
I sign my own messages with (one of) my own certs.  The subject name of
my cert is displayed to the recipient when the message signature is
validated.  What vulnerability is introduced if a message signed by
"C=US ... CN=David Kemp" comes from any email address, or mail list
address, in the world?  The "from" and "reply-to" fields are both
irrelevant to the authentication.

* In the case of confidentiality:
I want to send a message to "C=CA ... CN=Joe Smith".  I look up Joe's
email address in my address book, which might be correct or incorrect.
If Joe receives the message using whatever email address I have for him,
he can read the message.  If my address book is incorrect and Fred
receives the message, he can't read it because he doesn't have Joe's
private key.

It seems to me that if there are security vulnerabilities, they are
the result of a flawed HMI, not a flawed certificate profile.  If
the HMI does not associate the subjectName with the message to which
it is cryptographically bound, you will have vulnerabilities.

Dave

> Date: Wed, 09 Feb 2000 11:27:35 -0500
> To: "Graham Laws" <[email-masked]>
> From: Russ Housley <[email-masked]>
> Subject: Re: Problem for public CAs
> Cc: "'SMIME IETF'" <[email-masked]>

> Graham:
> 
> Certificates usually contain a subject name and a public key.  However, 
> this information is not adequate for a mail user agent to determine which 
> certificate goes with a particular e-mail address.  That is why the S/MIME 
> RFCs require the inclusion of the e-mail address in the subjectAltName.
> 
> Several people have tried to build S/MIME capabilities that support 
> certificates without e-mail address in the subjectAltName.  The results are 
> security vulnerabilities!  The address book must be used to associate the 
> certificate and the e-mail address.  Users are not very good at associating 
> the correct certificate with the correct address book entry (that is, the 
> correct e-mail address).  This mismatch has impacts on both authentication 
> and confidentiality.
> 
> Russ

---

From: Dean Povey <[email-masked]>
Date: Thu, 10 Feb 2000 07:49:40 +1000

>receives the message, he can't read it because he doesn't have Joe's

Sure, this is fine if you know the person you are communicating with by
email personally, and aware of all the context that is implicit in their
email address and hence the right DN to pick.  But what if I get the
following:

From: [email-masked]
Subject: Request for Proposal for the provision of Consulting Services
To: Security Consultants Mailing List <[email-masked]>

Which of the following DN's is the correct one?

C=AU, OU=Accounting, O=ACME, CN=John Smith
C=AU, OU=Accounting, O=ACME, CN=Jane Siegfried
C=AU, OU=Hacking, O=ACME, CN=John Smith
C=US, OU=Accounting, O=ACME, CN=John Smith
C=ZA, OU=Consulting, O=ACME Rival Security Consultants, CN=John Smith

etc. etc.

So all I have to do to forge an email that looks like it comes from a 
valid address is to come up with DN that looks plausible.  The problem 
with relying on global names in general is that they don't include the 
associated context (often referred to by the SPKI community as the "which 
John Smith" problem).  The reason you make them stick the email address in 
the cert is that this is absolutely bound to the message, wheras there is no 
guarantee that the DN and email map to the same entity.  The cert can then 
make the mapping between email and DN explicit hence linking the DN to the 
message.

Sure, the person who "owns" [email-masked] can later point out that the DN
used in the certificate is not them, but it is a bit late after you have
just replied to them and sent a message encrypted with the hacker's public
key. 

The answer to the privacy problem for public certificates is simple.  
Don't publish your certificate if you are worried about it.  Go to a CA 
whose certificate policy is not to publish in a public directory and give 
out your certificate to those you trust.

-- 
Dean Povey,         | e-m: [email-masked]     | JCSI: Java Crypto Toolkit 
Research Scientist  | ph:  +61 7 3864 5120       |  security.dstc.edu.au/ 
Security Unit, DSTC | fax: +61 7 3864 1282       | Oscar - C++ PKI Toolkit:
Brisbane, Australia | www: security.dstc.edu.au/ |  oscar.dstc.qut.edu.au/