From: John Gardiner Myers <jgmyers(_at_)netscape(_dot_)com>
extension is "12345,3924(_at_)compuserve(_dot_)com" also more simple and
than a DN?
Yes. The user clearly knows that it is the identity "12345,3924" issued
by "compuserve.com". To know more, they would have to know about the
identity-issuing policies "compuserve.com". (And possibly the
delegation policies of ".com".)
The DN representation of this information would be something like:
C=US, O=CompuServe Inc., CN=12345,3924
give or take a few characters.
The point is not that a compuserve user could get a certificate with that
DN, it is that a person having a certificate with a real name (sorry to pick
on you, but use "O=netscape.com, CN=John Gardiner Myers" as an example again)
could use a cryptically-named compuserve email account *and* an
employer-provided email account, both with the same certificate.
If the standard permits eithe syntax, some CA's only use DN syntax, and
some UAs only use RFC822 syntax, then you have "conforming but
If the standard requires that a DN, an RFC822 name, or both be present
in a certificate, and requires that UAs to support DN and RFC822 forms,
then conformance implies interoperability.
Please explain why there is any security issue involved.
If an attacker can subvert the UA's mapping, they can cause the UA to
choose the wrong public key. Suppose I am able to add a mapping into
Paul Hoffman's UA equating "O=netscape.com, CN=John Gardiner Myers" to
The UA does not choose a public key, the user chooses the public key
based on the name bound to that key in a certificate.
If Paul encrypts a message to "O=netscape.com, CN=John Gardiner Myers"
and his address book causes the message to be sent to
dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil, then I get (unreadable) copies of
intended for you, and you don't get copies unless I'm kind enough to
forward them to you :-). That's denial of service. It is impossible
for a security protocol to prevent DoS - the best that can be done is
to avoid having security exacerbate problems that exist in non-secure
versions. Since your run-of-the-mill non-secure MUA has an address
book that could be configured to send mail for "John Gardiner Myers" to
dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil, the S/MIME DoS situation is no worse.
I can now make Paul believe that things I
signed came from you, and I can decrypt any mail from him to you that I
am able to snoop off the wire.
Say what? If Paul receives a message signed by your key which is bound
in a cert to your DN, why would he believe it came from me (regardless
of any tampered SMTP header or any misconfiguration of his address book)?
And if Paul encrypts a message to my DN using my certified public key,
how would you be able to read it?
Address book misconfiguration/tampering might cause your mail to be
delivered to me, or my mail to be delivered to you. And sniffing could
result in mail showing up in lots of places not intended by the sender.
But without my private key you can't read my mail, regardless of how
you managed to get a copy of it.
If I want to send mail to the person I know as
"O=netscape.com, CN=John Gardiner Myers", or the person I know as
"jgm+(_at_)cmu(_dot_)edu", then what difference does it make if the mail
addressed and delivered to anon3984(_at_)remailer(_dot_)fi as long as it
winds up in a location where the person holding the private key
corresponding to the certified identity can read it?
This is not the issue.
The difference between the identity in a certificate and SMTP delivery
information is precisely the issue.
Do you believe that the above scenario and others like it should be
precluded by the S/MIME specification?