Hi,
Here is another problem with S/MIME deployment that I'd like to inquire
about.
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.
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 ?
Nowadays, in Netscape applications (and in the new AOL communicator),
each user can make a decision of which CAs he trusts for signing each
type of certificate (SSL server, SSL client, email signing, email
encryption ...). I call this set of CAs and the trust properties a
user's "trust domain".
Unlike an email certificate which is typically included in an S/MIME
message's digital signature, my trust domain is not exposed to you.
The only clue that you have when writing to me is that I probably trust
the same Thawte freemail CA that issued my own public encryption
certificate. However, if I had signed this message with my corporate
certificate (and if my smartcard was working right now:)), you would not
be able to get a certificate from the same CA, unless you were employed
by the same company.
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.
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 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.
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 ?
smime.p7s
Description: S/MIME Cryptographic Signature