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.
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: js(_at_)acme(_dot_)com
Subject: Request for Proposal for the provision of Consulting Services
To: Security Consultants Mailing List <sec-consultants(_at_)security(_dot_)com>
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" js(_at_)acme(_dot_)com 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: povey(_at_)dstc(_dot_)edu(_dot_)au | 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/