Subject: RE: trust domains

From: Alberti Antoine <[email-masked]>
Date: Mon, 11 Aug 2003 10:50:00 +0200

There was such an issue in TLS, solved, from the server point of view, by
sending a list of trusted authorities when requesting a client
authentication. However, this list was so ennoying to use for both sides
that it is now almost always empty, indicating "Send me whatever you want,
we'll see then".
I agree that a work could be done on this topic, but it should done
carefully to avoid this conclusion.
Regards.

-----Message d'origine-----
De : [email-masked]
[mailto:[email-masked]]De la part de Julien Pierre
Envoye : samedi 9 aout 2003 04:43
A : [email-masked]
Objet : trust domains

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 ?

---

From: [email-masked] (Julien Pierre)
Date: Wed, 13 Aug 2003 16:16:47 -0700

Alberti,

 > carefully to avoid this conclusion.

I'm aware of the change that was made recently to TLS to allow an empty 
list of trusted certificates to be sent by the SSL server.  I don't 
personally like this change at all and considered very useful in SSL 
client authentication.

This provision means that to login to such servers, I'm now presented 
with a list of 12 certificates to choose from, with absolutely no hint 
about which one is correct, instead of having the right one 
automatically chosen by the application, or at least a list of valid 
ones if there are several matches. This is what I call shooting oneself 
in the foot. Some server administrators are probably too lazy to install 
the valid trusted roots. My opinion is that they probably shouldn't be 
running PKI servers. Eventually after the client auth login, the code in 
the SSL server is going to have to check if the client certificate is 
valid anyway, and that operation will require the trusted root to be 
installed. If the check does not involve a particular issuing root, 
there are many spoof attacks I can think of against such SSL servers ...

-- 
I am the dog in dogfood