To: "David P. Kemp" <dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil>
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Problem for public CAs
Date: Thu, 10 Feb 2000 07:49:40 +1000
From: Dean Povey <povey(_at_)dstc(_dot_)qut(_dot_)edu(_dot_)au>
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.
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.
If the message from "js" is not S/MIME, you don't need a cert at all.
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.
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?
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".
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.
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.