-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Julien
Pierre
Sent: Friday, August 08, 2003 7:43 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: trust domains
Assuming that you have already obtained my public encryption
certificate, for example by reading this message, there is no way for
you to be certain what type of certificate I will trust if
you send me
e-mail, in particular what CAs I trust.
Yup.
If you have multiple certificates from different CAs, which
one is the
most appropriate to use when writing me writing signed and encrypted
e-mail ?
This seems to be a question of certificate policies and mapping those to
the content being protected. That is, if the message being signed is
just casual communication, use one certificate, and if it's a purchase
order, use another one. Right now, I think that most clients pretty
much allow the user to pick. Further, I think that a lot of folks just
have one, so you'd better like it.
One theoretical answer to the problem would be for you to sign your
message with all the certificates you have, including multiple
signatures, in the hope I would trust one. Today our mail
clients only
support a single signature, so that wouldn't work. But even
if they did
tomorrow, the software trust policy might be to not trust the message
unless all its signatures are valid, so having one good
signature and n
bad signatures wouldn't help. You might send your message n
times, each
signed with a different certificate, but I would probably get annoyed.
Well, I'm not sure that the semantic of multiple SignerInfos is that "if
you verify them, you must verify all of them, and if you don't like any
of them, freak out". I think it's more along the lines of "these are
all equivalent, so go ahead and choose which one you like and run with
it".
What I'm getting at is that there is a need to make the user's trust
domain information available, so that senders get a hint of
the proper
certificate to use.
This might be interesting to discuss. You could make a capabilities
extension where you could identify your roots (off the top of my head,
I'd say using a hash of the certificate would work) and go from there.
One concern is bloat -- I have over 100 roots on my machine configured
with Outlook 2002 and IE6 that are all marked as suitable roots for
"Secure email" (in the "secure email" trust domain, using your terms).
Sending this stack of hashes with every signed message might make the
world a worse place to address this issue.
This is similar to what happens in the SSL protocol when an
SSL server
requests client authentication. The SSL server provides a list of
trusted CA certificates. The SSL client is then free to choose one to
use if he has one that chains to a CA the server accepts. Of
course the
problem was easier to solve for SSL, since it is an online
protocol, and
S/MIME is not.
I think the principle is the same, though. In the case of S/MIME, it's
"sign with all of your certs". One problem is that you're going to
potentially cart around a large number of certs -- each of your
individual certs as well as the intermediate certs that go with them.
And I'm not sure that there's enough experience with clients handling
multiple signers to tell you what would happen if you used that feature.
My question is : is there any work going within the IETF to
solve this
problem for the S/MIME protocol ? And how have you been solving this
problem today ?
From what I can tell, today we solve the problem by having clients
include every root key under the sun, and most certificates of
significant public value are issued under those roots. Certificates
that aren't issued under those roots are most likely corporate CA
certificates, and typically folks just have to hunt around to find the
right corporate root to install in order to verify the signatures.
Peter Hesse and Sharon Boeyen have recently illustrated this problem on
the PKIX list -- not directly, but by sending signed messages for which
people don't have the root keys.
Blake