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