Re: The address-in-certs issue
1) This is not an interoperability issue. Every UA should be able to
present a string, and the UA does not need to interpret it.
2) Since its not an interoperability issue, why dictate the form of the
3) We MUST require the UA to present to the user whatever identifiers are
in the cert.
At 06:09 PM 12/22/97 -0800, John Gardiner Myers wrote:
David P. Kemp wrote:
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
on you, but use "O=netscape.com, CN=John Gardiner Myers" as an example
could use a cryptically-named compuserve email account *and* an
employer-provided email account, both with the same certificate.
Even simpler, I could have a certificate with both
12345,3924(_at_)compuserve(_dot_)com and "John Gardiner Myers"@netscape.com.
What's the advantage of putting it in DN syntax?
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.
This is one of the possible solutions to this interoperability issue.
Later in this message I will argue that the solution of mandating RFC822
names only is better for the Internet mail application, but can we first
get consensus on the basics:
JGM1) In order to interoperate, each application of S/MIME must specify
mandatory minimum idenitfier syntax requirements on CAs and receiving
UAs, such that every conforming cert has identifiers interperable
(subject to policy) by every conforming UA.
JGM2) The mandatory identifier syntax requirements of Internet mail
should be specified in a base S/MIME document.
JGM3) Applications other than Internet mail may profile S/MIME to change
these identifier syntax requirements as necessary.
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.
No interface I know of has the user typing in a public key. Some
software somewhere chooses
a public key based on some input it got from the user and some system
for mapping that input to a public key.
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 :-).
You have mixed up who is the attacker and who is the attackee. I am the
attacker. For purposes of this exercise, we postulate that I am able to
make modifications to Paul's address book and that I am able to subvert
the mail transport between Paul and you.
Paul needs to send you an important, private message. Paul is a busy
person. He's the co-founder of an industry consortium for Internet
mail. Having much familiarity with Internet mail, he uses the same,
simple, interface he has always used for informing his UA to whom the
mail is intended: he types "dkemp(_at_)missi(_dot_)ncsc(_dot_)mil" into the
To: field of
his compose window.
Since you have a perfectly conforming cert which fails to certify the
mapping of "dkemp(_at_)missi(_dot_)ncsc(_dot_)mil" to your public key, the UA
database mapping that either to a public key or to some other name which
has a certified mapping to a public key. Since I have subverted that
database, I get the UA to map that to "O=netscape.com, CN=John Gardiner
Myers", which has a certified mapping to my public key. Thus I cause
mail intended for you to be encrypted with my public key.
Since I have subverted the delivery system, I can intercept that message
and prevent it from being delivered to you. After decrypting and
reading the message, I can re-encrypt it with your real public key and
inject that into the delivery system destined for you.
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)?
That is because Paul, being a busy person, doesn't have the time to
parse the DN for every message he receives. Being an Internet mail kind
of person, he thinks in terms of RFC822 syntax. He uses a UA which
checks the header against the certification using the mapping in the
subverted address book and displays a simple icon stating "yup, this was
Suppose the UA always displays the DN that was certified. Now suppose
the attacker has the legal name "David P. Kemp". What is the likelihood
that Paul will notice that fields in the DN other than CN aren't what
they should be? Most Internet mail users can't distinguish a DN from
base64-encoded line noise.
And if Paul encrypts a message to my DN using my certified public key,
how would you be able to read it?
Paul doesn't encrypt a message to your DN. I trick his UA into using my
If you claim that Paul should always be picking a DN to use out of an
address book or directory and that his UA should display every single
component of the DN, then I would say you have given Paul's UA all the
simplicity and ease of use of X.400.
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.
The issue is the syntax of identities. An identity which is different
than the SMTP delivery information can still be in RFC822 syntax.
Do you believe that the above scenario and others like it should be
precluded by the S/MIME specification?
It is perfectly legitimate for a cert which contains the identities
"John Gardiner Myers"@netscape.com and/or jgm+(_at_)cmu(_dot_)edu to be used
mail delivered to anon3984(_at_)remailer(_dot_)fi(_dot_) I believe such is an
case, and retail UAs are likely to express this situation with a more
complex UI than they use for the case where the delivery address matches
an identifier in the cert.
It greatly complicates matters if the UA has to do something with
identities not in RFC822 syntax.