Paul Hoffman / IMC wrote:
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.
Huh? If the CA and receiving UA fail to interoperate, at least one of
the following has occurred:
A) The CA is non-conforming
B) The UA is non-conforming
C) Something in the path between the CA and UA is broken.
D) The S/MIME standard is broken.
For purposes of my statement above, we can rule out (C). Which of the
remaining is it?
All UAs need to be able to present signature
verification information to the "user" (human or otherwise) in a useful
"All" he says. In the domain of retail Internet UA's, "useful fashion"
includes "in a simple enough form for anyone off the street to be able
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."
You've lost most of the Internet mail user base right there. Think:
Secure Mail for Dummies.
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.
On the contrary: the format of the identifier controls how the UA has to
present it, and it controls how humans are able to interpret it.
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.
This was a source of amusement for the UI programmer in the next cube.
Let's try an exercise: you are an S/MIME UA implementation. Your user
indicates that the "John Gardiner Myers CA" is trusted. You receive a
message that was signed using a key certified by the "John Gardiner
Myers CA". In the cert, there is one identity, which has the "John
Gardiner Myers Special Sauce" syntax. The value of that identity is the
base64 decoding of:
Present that identity to the user in a form they will be able to
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.
If you can't do anything with the identity, what's the point in having
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?
It tells a UA how to present the identity in a form an Internet mail
user can reasonably be expected to comprehend.
It tells a user that the identity is something at "blobbo.com", and that
the user can apply some external knowledge concerning the identifier
policies of "blobbo.com" to get further knowledge of the identity.
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.
You are incorrectly equating "it doesn't mean anything as a useful
recipient address" with "it doesn't mean anything".
An RFC822 name means exactly what the entity that controls the domain
part wants it to mean, no more, no less. The domain can choose to make
the name usable as a delivery address or it could not.
This is the case with any identity syntax: the meaning of an identity is
entirely up to the issuer of that identity. More information than that
can only be obtained through a series of bilateral agreements.
So I contend that an RFC822-syntax identifier has the meaning that it
identifies whatever the owner of the domain in the right hand part calls
the left hand part. Receiving UA's can use this knowledge of the
identifier syntax and semantics to appropriately display and process the
identification in an interoperable fashion. The analogy holds.
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.
Again, generality is the antithesis of interoperability. In practice,
identifiers do need hierarchy in their namespaces.
Stated another way, you want the "default" profile to be Internet mail, and
other applications have to deviate from the default.
Other applications have to deviate from the default only if the default
profile does not suit their needs.
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
Please give a technical justification for this requirement on
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
Which reasons are these? Please call them out so that I can
individually address them.
Is it your position that other applications do not need to have
restrictions on identifier syntaxes? If not, what exactly is your
position on mandatory minimum identifier syntaxes?