At 08:01 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?
OK, I misworded my answer. Instead of saying "True", I should have said
"False". The UA and CA can interoperate even if the UA can't present RFC822
addresses in a way that is comprehensible to the receiving end-user. It's
the UA and the end user that are not interoperating. That's out of scope.
The format of the identifier controls how the UA has to
present it, and it controls how humans are able to interpret it.
Yes to the former, no to the latter. Humans interpret it as we damn well
please. Saying one kind of opaque string is more understandable than
another, particularly when you are guaranteed that an intelligent piece of
software will be displaying it, is silly.
If you can't do anything with the identity, what's the point in having
it assured?
You have already said you can't do anything reliable with
"cjones1832(_at_)blobbo(_dot_)com". It may not be a recipient for a future
message, so
putting it in an address book is wrong. Comparing it to unauthenticated
information that came with the signed message is unsafe so should not be
done. What else were you planning on doing with it?
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.
Ah, I see where we are differing here. You are assuming that some
infrastructure will exist to aid users in getting further knowledge. You
hadn't said this before. Such an infrastructure could give further
knowledge about identifier policies for names in any format.
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.
...if the domain even exists. You're making lots of hidden assumptions
here, given that you already said that the identifier didn't have to be a
deliverable address. You are now saying that the right hand side (RHS) of
the identifier must be an existing domain name, not just a syntactically
correct one. I think you're also saying that it can somehow possibly
respond to queries about LHS names at that domain. This is a far cry from
what you said before.
Your repsonses leads to a lot of thorny questions.
- Does the RHS need to exist? If the RHS doesn't need to exist, the user
can't apply any external knowledge.
- If the RHS needs to exist, how does a disconnected user validate this? If
he can't validate it, what should he do with the signature?
- Does a domain named in the RHS have to be part of some policy-emitting
infrastructure? If not, what "external knowlege" does the user get from
knowing only that the RHS exists?
- If a domain named in the RHS has to be part of some policy-emitting
infrastructure, who at the domain named in the RHS controls the policy
emitter? Using what protocol? I admit I haven't followed all the other
security work as closely as I would like, but I've never heard of any such
protocol or the semantics associated with it.
- If the site in the RHS doesn't emit a policy, what should a user do with
a signature that has that RHS?
As you can see, I'm skeptical of all of this. I think a better protocol is
to say "UAs that trust a CA to validate signatures also must trust whatever
identifier the CA gives it". Anything else, including side-validation and
policy finding, is way outside the scope of the document.
Telling the user "you might recognize the format of the identifier and you
can make lots of possibly-wrong guesses based on that format" is OK, but I
wouldn't force it on every S/MIME implementation. I'd say that instead, we
could use RFC822 addresses as a SHOULD, and make it real clear in the spec
exactly what semantics they *don't* convey.
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?
My position is that the "restrictions" on identifier syntaxes can be
something as general as "a UTF-8 string". UAs and CAs can interoperate with
this. UAs can display this to their human users. Making the humans
"understand" it is difficult, but as you can see from above, it is also
difficult for supposedly "simple" formats as well.
--Paul Hoffman, Director
--Internet Mail Consortium