Paul Hoffman / IMC wrote:
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).
If a CA only uses DNs and the receiving UA is only able to present
RFC822 addresses in a way that is comprehensible to the receiving
end-user, then the CA and the UA have failed to interoperate. If both
conform to the S/MIME specification, then the S/MIME specification has
failed.
Having a user indicate to a UA that a given CA is trusted does not
magically give that UA the ability to present whatever identity syntaxes
that CA chooses to put in its certificaes. Different identity syntaxes
require different code.
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.
In such an appplication, a CA that does not use RFC822-syntax
identifiers is not appropriate, and the standard for such an application
needs to state that such CAs do not conform.
However, you won't be able to do much with those blobs after validating a
signature other than storing them for future reference.
Then what's the point of having a CA involved in the first place?
[...] 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.
Likewise, any cipher suite will work as long as you have a mutual
agreement between the sender and recipient as to which to use. Such an
approach does not lead to interoperability.
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.
Those uses can profile S/MIME to fit their needs. For example, a
commerce application could replace the RFC822 identity requirement with
a credit card identity for a purchase request. Such an application
doesn't have to interoperate with Internet mail--the only useful sender
CAs and recipient UA's are those which understand credit cards.