Paul,
I agree with you. But there also is a point in John's message that may be
worth noting in the S/MIME standard -- that is:
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". 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.
I don't agree with the point of needing interoperability of address books, but
John further states:
The security of such an address book is critical to the security of
S/MIME. The S/MIME protocol would then have to find a way to
appropriately secure the mandatory address book protocol, as well as
explicitly call out the security considerations of such address books.
It could be said that if a user agent utilizes such a mapping of addresses
to certificates, that the mapping should be appropriately protected by
the user agent, or display the mapping to the user prior to usage.
But this attack would only be successful once without a man-in-the-
middle attack, as the real recipient wouldn't be able to read the
message, which should cause someone to look into the problem.
Larry
----------
From: Paul Hoffman / IMC[SMTP:phoffman(_at_)imc(_dot_)org]
Sent: Monday, December 22, 1997 4:05 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Re: The address-in-certs issue
At 12:58 PM 12/22/97 -0800, John Gardiner Myers wrote:
Just like S/MIME needs a mandatory-to-implement cipher suite, it needs
some sort of mandatory identity syntax. Otherwise it is likely that
conforming implementations will fail to interoperate.
I'm not sure if I agree here (and I really mean "not sure"). When checking
the validity of a signature in S/MIME, the receiving agent looks at a
certificate from a mutually-trusted CA. I think that there is an assumption
that maybe we need to state more clearly in the document: If you trust the
CA, you also trust the CA's method(s) of identifying users. A CA might use
RFC822 addressess, might use DNs, or might use both (or others).
Putting it a different way, you must accept whatever your CA gives you for
an identifier when validating a signature. If you are an RFC822 kind of
program, you can still use a CA that uses other blobs for the identifiers.
However, you won't be able to do much with those blobs after validating a
signature other than storing them for future reference.
If you insist on being able to use the identifier for some additional
purpose (such as comparing it with the From: and Sender: headers), then you
must use a CA that uses the right kind of identifier. However, these
purposes are (as of the discussion of the last few weeks) not required by
S/MIME. We should do nothing to prevent them, and I think we should at
least discuss how some might do them, but I don't see a need to force
everyone to use a single identifier if any identifier will work as long as
you have a mutual agreement with your CA as to what the identifiers mean.
This isn't to say we can't make the RFC822 format a SHOULD for identifiers;
I think that would be exactly right given that much of what we do in S/MIME
is for Internet mail, and that format works just fine for that purpose.
However, elevating it to a MUST seems to stymie some potential uses of
S/MIME without adding value that isn't already added in the inherent trust
model between users and their CAs.
--Paul Hoffman, Director
--Internet Mail Consortium