ietf-smime
[Top] [All Lists]

Re: The address-in-certs issue

1997-12-22 13:59:03
The key issue here is interoperability.  If it is possible to have a set
of components, each of which individually conform to the standard, yet
the comonents do not interoperate, then the standard has failed.  In a
security context, interoperate means "works when the security policy
permits, does not work when the security policy prohibits".

When protocols allow too much flexibility in what kinds of widgits
implementors can use to fill some critical slot, this sort of
"conforming but noninteroperable" problem can occur.  The solution is
for the standard to pick a small number of widgits (preferably one) to
make mandatory.  Examples of such widgits are cipher suites and identity
syntaxes.

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.



David P. Kemp wrote:
From: John Gardiner Myers <jgmyers(_at_)netscape(_dot_)com>

In order for S/MIME agents to interoperate, receiving UA's need to be
able to present an identity of the signer to the user in a manner that
is simple and comprehensible.  This is not going to work if UA's have to
deal with presenting two entirely different syntaxes for identities,
especially if one of them is as complex as the DN syntax.'

This is irrelevant to the question at hand, but why do you feel that
"O=netscape.com, CN=John Gardiner Myers" is complex and incomprehensible,
whereas "jgmyers(_at_)netscape(_dot_)com" is simple and comprehensible?

Your strawman DN is simpler than DNs are in practice.  Also, that DN can
be trivially represented in RFC822 syntax: "John Gardiner
Myers"@netscape.com.  Representing it that way makes the UA's task of
presenting the identity far simpler.  Users know what "@" means, users
do not know what "O=", and "CN=" is.
 
And by
extension is "12345,3924(_at_)compuserve(_dot_)com" also more simple and 
comprehensible
than a DN?

Yes.  The user clearly knows that it is the identity "12345,3924" issued
by "compuserve.com".  To know more, they would have to know about the
identity-issuing policies "compuserve.com".  (And possibly the
delegation policies of ".com".)

The DN representation of this information would be something like:

C=US, O=CompuServe Inc., CN=12345,3924

give or take a few characters.

The reason this is irrelevant is that there is no reason to either
require or prohibit users from choosing their preferred form of identity.
If some users want identities in RFC822 syntax, that's fine.  If other
users want identities in DN syntax (to enable the same cert to be used
for S/MIME and non-S/MIME purposes, for example), then that's fine too.

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".

You continue to ignore the distinction between an identity and a mailbox.

That's because any distinction is irrelevant.  Every mailbox is an
identity, and any identity can be represented in RFC822 syntax.  It is
not necessary that something represented in RFC822 syntax be
deliverable.

People normally would want one (or just a few) identities.  But some users
change mailboxes often, or have multiple contemporaneous mailboxes, or use
mail mechanisms that have no meaningful identity at all (IETF terminal
room - "sun19(_at_)ietf(_dot_)newbridge(_dot_)com" for example).

The identity "sun19(_at_)ietf(_dot_)newbridge(_dot_)com" is a useful one, it's 
just not
necessarily useful in the context of Internet mail.  That identity would
be useful in a cert used to access licensed software from a file
server.  That identity is unlikely to be useful in a cert used for
Internet mail, as it is unlikely to be useful in the From: header of an
RFC822 message.

A mailbox is NOT an identity - and as long as you keep using the same word
to refer to two different functions, you will continue to be confused
about the difference between them.

On the contrary, every mailbox is an identity.  That identity may or may
not be useful for a given application.

What is more
likely is that UA's are going to have to add a subsystem to map
DN-syntax identites to RFC822 identities and UAs are going to be far
less likely to get the security issues of this mapping right than the
far fewer and better equipped CAs.

Please explain why there is any security issue involved.

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.

Suppose this attack is carried out by someone else named "David P.
Kemp".

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.
 
To be redundantly didactic, the first two are *identities*, either of
which (the choice is a matter of personal preference) can be used in a
cert.  The third is a *mailbox* which does not belong in a cert at all.

The third is an identity, and it is useful to have it in a cert.

S/MIME user agents will maintain an address book mapping identities
to addresses.

If the interoperability of S/MIME depends on the existence of such an
address book, then S/MIME needs to mandate its presence.  If S/MIME
wishes to mandate its presence, then interoperation of different S/MIME
implementation run by a given user will require them to share this
address book data.  Thus, S/MIME would need to specify a mandatory
address book protocol.

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.

S/MIME user agents might also have a configurable option
to allow checking that the identity and the mailbox are the same and
warning if they are not, for people who choose to use their mailbox as
their identity.  But there is no reason for S/MIME to mandate that:
 1) certs contain mailbox addresses,
 2) certs have identities in RFC822 format, or that
 3) there be any mandatory checking between identities and mailbox
    addresses.

It is necessary for there to be some sort of mandatory identity syntax,
otherwise conforming CAs and UAs can fail to interoperate.  For the vast
majority of implementors, RFC822 syntax is the simplest to implement. 
It is also the most appropriate for use in Internet mail.  

The simplest interface for a UA to present is for when the identity in
the From: header matches an identity in the cert.  I can see that for
senders to get these to match with today's technology can be difficult,
so I do not feel as strongly about the matching issue as I feel about
the need for the cert to contain at least one RFC822 syntax identity.


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