ietf-smime
[Top] [All Lists]

Re: The address-in-certs issue

1998-01-06 13:57:19
David P. Kemp wrote:

From: John Gardiner Myers <jgmyers(_at_)netscape(_dot_)com>
Date: Fri, 19 Dec 1997 14:50:07 -0800

David P. Kemp wrote:
Reasons include 1) the more information that goes into a cert, the shorter
the expected lifetime,

Then take out other information.  RFC822 identities are what are used in
Internet Mail, and if you're securing Internet Mail objects, those are
the identities you need to certify.

  --- and ---

From: John Gardiner Myers <jgmyers(_at_)netscape(_dot_)com>
Date: Mon, 22 Dec 1997 18:09:51 -0800

Even simpler, I could have a certificate with both
12345,3924(_at_)compuserve(_dot_)com and "John Gardiner Myers"@netscape.com.

Is it too much to ask that your arguments at least be self-consistent?
You can't simultaneously take extra information out of and put extra
information into a certificate.

I don't see any inconsistency.  In the second quote, I transformed an
example that you posed that had two pieces of information into an
example that had two pieces of information.  No extra information was
put into the certificate, I merely changed the syntax of one piece of
information.

If we agree that relatively long-lived stable identities are a goal,
and that accommodating environments where mail can reach a given user
by multiple and occasionally or frequently changing addresses is also
a goal, then we can't reach both goals by putting all the delivery
addresses into a cert.

Then don't put all the delivery addresses into the cert.

You seem to have an assumption that DN-syntax identifiers are inherently
more "stable" than all RFC822-syntax identifiers.  This is not the
case.  Some RFC822-syntax identifiers are temporary.  Some are not. 
Some RFC822-syntax addresses are more stable than some DN-syntax
identifiers.

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.

Paul is a busy person, so he types "kemp" into his compose window.  His
MUA has a database of certificates, each of which has a subject name
bound to a public key.  The list of subjects matching "kemp" pops up,
and Paul clicks on the correct one.  If there is only one match, the
MUA displays the full name and either asks for confirmation if Paul has
previously checked the "always ask" option, or proceeds if the option is
unchecked.

The attacker happens to have a legal name of "David P. Kemp".  In
addition to associating the attacker's identity with the
dkemp(_at_)missi(_dot_)ncsc(_dot_)mil entry in Paul's address book, he also 
removes your
certificate from the MUA's database.  When the MUA finds only one match,
the MUA displays the full name and asks for confirmation.  Paul seeing a
common name matching yours checks "ok".  The message is encrypted with
the attacker's public key.

Proponents of DN's seem to have an inexplicable fascination with using
common names for identifiers.  This besides the fact that common names
fail two requirements of identifiers: common names are neither unique
nor unchanging.

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.
  [...]
Most Internet mail users can't distinguish a DN from base64-encoded
line noise.

That is a remarkably insulting statement - I'm glad you said it about
Paul and not me :-).  I give even computer-using mothers-in-law* credit
for being able to recognize "O=imc.org, CN=Paul Hoffman" as easily as
they would "Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org>".

I don't see why you consider it insulting.  Heck, I don't even have time
to do the mental gear-switching needed to parse two different syntaxes
for every message I read.

You must have a remarkably technically inclined mother-in-law.  Never
mind the fact that you give her an atypically simplistic DN.

And I give credit to MUA designers to be able to present "Paul Hoffman"
to the user given either form as input, and allow the curious to
explicitly seek further details.

If the UA only presents "Paul Hoffman", tossing the information needed
to distinguish that particular "Paul Hoffman" from other things with a
legal name of "Paul Hoffman", then there is a security problem--some
other "Paul Hoffman" could masquerade as phoffman(_at_)imc(_dot_)org(_dot_)


<Prev in Thread] Current Thread [Next in Thread>