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
identity? 
3) We MUST require the UA to present to the user whatever identifiers are
in the cert.

Elliott Ginsburg


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
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.
> 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
> > > noninteroperable".
> > 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
> > > "dkemp(_at_)missi(_dot_)ncsc(_dot_)mil".
> > 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 
> > messages
> > 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 
> needs some
> 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
> signed."
>
> 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
> DN.
>
> 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 
> > > > gets
> > > > addressed and delivered to anon3984(_at_)remailer(_dot_)fi as long as it
eventually
> > > > 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 
> for
> mail delivered to anon3984(_at_)remailer(_dot_)fi(_dot_)  I believe such is an 
> uncommon
> 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.