<snip>
If the message you received from "js" is an S/MIME message, only one
cert will validate the signature or decrypt the body, so you know
which DN is correct.
Yes, but you still don't know if that was the correct DN for the email
address. You have to guess that the DN "matches" the email address,
unless you have some other information.
How does the person who owns js(_at_)acme(_dot_)com get involved in the first
place?
If a hacker sends you an S/MIME message with the hacker's cert,
you can reply to it "securely" (with a message the hacker can decode).
What motivation is there for the hacker to cause the reply to be
delivered to "js(_at_)acme(_dot_)com" where, presumably, the hacker can't get
it and the "real" js can't decrypt it?
Because the hacker can get you to reveal some information that you might
reveal to js but not to the hacker. I can think of scenarios where this
might happen, for example you come to trust someone on a mailing list, but
you only associate them with their email address and common name. The
hacker learns this and uses this to socially engineer you via email to
send him/her some information. You figure, okay well it's encrypted so
I'm safe, and the DN kind of looks okay, so I'll send it.
You bootstrap an electronic identity by what you say. If I send out
signed S/MIME messages all of which can be verified by the same cert,
it doesn't matter whether some of them come from a home rfc822 address
and others come from a work rfc822 address. If I want them linked to
the same persona I'll use the same cert. It also doesn't matter
whether the DN is a name with physical significance or a 'nym. All that
matters is that the messages come from the possessor of one private key.
If you have a collection of S/MIME messages with two different certs,
with similar or even identical DNs:
C=AU, OU=Accounting, O=ACME, CN=John Smith (issuer A, public key X)
C=AU, OU=Accounting, O=ACME, CN=John Smith (issuer B, public key Y)
you will have enough context to label one address book entry "John Smith"
and the other one "John the flaming idiot".
Sure, that is nice in theory, but if there is nothing meaningful in the
Certificate to associate with the possessor of the private key then what
have you gained? All you know is: a) The person who sent you email message
has a private key; and b) That some third party has verified that the
person that sent you the email possesses the private key. The email
address could be forged and the DN might be meaningless. Now what you are
saying is that you associate this DN locally with your address book,
mapping the meaningless DN back to a name/context you understand. Therefore
you have verified by some out-of-band mechanism that you can associate the
public key with a person/entity you know about (via the indirect route of
associating them with the meaninglyess DN). So in effect you have negated
the need for a third-party certificate in the first place as you have
already obtained all the information you needed OOB. Therefore this negates
the need to publish the certificate in a public repository, and hence the
reason for leaving it out in the first place.
Your argument seems to predicated on the basis that I know the people
personally with whom I communicate via email. More often than not I am
communicating with people via email whom I have never met, and who I know
very little about. I sometimes come to trust these people through the
email that they send, i.e. I find the things they say knowlegeable or
insightful. Therefore I build a certain degree of trust on the basis of
this past experience, but I only associate that with their email address
and name, not with their DN. My point is that it is not possible to
unambiguously associate a DN with an email address, so you can't make this
leap without both being in a cert. Therefore I am not going to send some
one some secure data on the basis of just a DN if I have nothing to
associate it with.
Now you could argue that there are some cases where you don't need to
verify this binding if you have the context required to get the DN anyway,
so therefore it should not be mandated. But this is a relying party
decision, not the decision of the person who signs the email. I think you
limit the ability of the relying party to make decisions about their email
if you don't associate the From address with the signature.
Every email address must have a From: address, and I think it is reasonable
that this email address in a secure message should always be securely
verifiable, so that you can accurately bind an S/MIME message with its
point of origin.
If you are using free CAs which hand out certs to anyone, an rfc822
address is just clutter which shortens the lifetime of the cert. It
doesn't make the two Johns any more unique than they were without it.
Saying "John could receive email at this address at the time this cert
was issued" links the cert to a non-secure pre-S/MIME rfc822 persona,
but the reliability of that link is questionable, particularly if
anything more than net reputation is at stake.
This is a valid point. One my misgivings with X.509 is that they chose not
to separate attribute and key management (SPKI is much better about this).
While S/MIME has support for attribute certs that could be used to
associate email addresses with keys in identity certs (useful as these will
have different life-cycles), I don't think that the application support is
wide enough yet that this is really a valid alternative to putting the
email address in the certificate.
If you are relying on CAs to provide a real PK Infrastructure (by ensuring
that keyholders are tied to something with Identity significance such
as a DUNS number or an employment record), then rfc822 addresses are
obviously irrelevant.
Well actually what I think you are really after is associate a key holder
with something (i.e. a privilege, identity or attribute). But the point
is about rfc822 addresses is that this is something you just about always
need to verify.
Cheers.
--
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/