At 03:52 PM 12/22/97 -0800, John Gardiner Myers wrote:
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.
True, but I assert that that failure is due to the presentation problem,
not to the protocol. All UAs need to be able to present signature
verification information to the "user" (human or otherwise) in a useful
fashion. For instance, I think it's perfectly reasonable for a receiving
agent to say "it was signed properly, as verified by FooCA, with a
signature of BlobboCorp." without making any linkage between BlobboCorp and
the sender, or BlobboCorp and a return address. If the name BlobboCorp
doesn't mean anything to you, that tells you something about what you
should believe about the signature.
As long as you trust your CA to give a unique ID to BlobboCorp, that's all
that matters as far as interoperability goes. And that belief doesn't (as
far as I can tell) rely on the format of the identifier.
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.
It does if the spec says it does.
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?
To assure you of the identity of the signer. "BlobboCorp" and
"xyzzy(_at_)blobbo(_dot_)com" are both identifiers that you might get back.
Looking at it a different way, if "xyzzy(_at_)blobbo(_dot_)com" does not have
to be a
deliverable address (which I agree it doesn't), what does it tell you that
"BlobboCorp" or "c=zw, o=BlobboCorp" doesn't? If you can't do anything with
the RFC822 address, then it is as opaque as any of the other identifiers.
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.
Completely right, but a bad analogy. If there is no meaning associated with
the RFC822 address you want to insist on (that is, it doesn't mean anything
as a useful recipient address), it's just a format that happens to have
some syntactical limitations to it. Any format would work there. I'm happy
to pick an ASN.1 string type and say "it must be one of these" in that
case, and make sure that type is as general as possible.
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.
Stated another way, you want the "default" profile to be Internet mail, and
other applications have to deviate from the default. I'd definitely be
behind that *only if* the indentifier MUST be a valid, usable Internet mail
address associated with the signer, therefore having some value other than
its uniqueness. However, we've seen many reasons why that is too
restrictive, and why it's not useful (header spoofing), so I'd say forcing
other applications to create separate profiles for just this one value is
not useful.
--Paul Hoffman, Director
--Internet Mail Consortium