Subject: trust domains

From: [email-masked] (Julien Pierre)
Date: Fri, 8 Aug 2003 19:43:03 -0700

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: "Blake Ramsdell" <[email-masked]>
Date: Fri, 8 Aug 2003 20:44:36 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Julien Pierre
> Sent: Friday, August 08, 2003 7:43 PM
> To: [email-masked]
> Subject: trust domains
> 

Yup.

> most appropriate to use when writing me writing signed and encrypted 

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.

> 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".

> domain information available, so that senders get a hint of 

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.

> problem was easier to solve for SSL, since it is an online 

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.

> problem for the S/MIME protocol ? And how have you been solving this 

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

---

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

Blake,

 > have one, so you'd better like it.

It is indeed a question of policy, and the example you point out is a 
good one. Similarly, for internal communications within a company, I 
shouldn't use my freemail Thawte cert. The internal SSL web servers 
which require client auth don't accept that certs.
Yet mail client accept it just fine.

The specific application I'm interested in is e-mail spam filtering 
based on certificates. You could choose to trust some free CAs (such as 
Thawte) if you like to receive anonymous email, otherwise restrict to a 
set of CAs with a more stringent policy (eg. those that require you to 
pay for the certificate).

As far as the number of certificates, I think most folks have zero 
today, not one. Some will have one, issued by their employer (corporate, 
or government/military typically). Then there are hobbyists or security 
professionals like us who may have dozens of certificates. Nowhere does 
Joe User fit today, because PKI is not widely deployed. Most questions 
I'm asking are in the context of a very large-scale PKI deployment 
happening. The problems may not be so obvious unless you get to that point.

 > all equivalent, so go ahead and choose which one you like and run with

Where would that be specified ? I would think this would be completely 
up to the application. If I chose to sign mail with both my personal 
cert and corporate cert, I know I wouldn't treat each signature in the 
same way. Eg. if I am an employee, I might not care about the personal 
cert's signature failing, but care about the corporate cert signature.

 > world a worse place to address this issue.

I think it would be a very bad thing to embed all the root certificates 
in each S/MIME signature. The signatures are already quite big enough as 
they are. I know the number of trusted roots can be quite high - it is 
also high in Netscape products.

What I'm getting to is more along the lines of :
1) defining a standard ASN.1 structure to define the user's trusted 
roots policy WRT email. That structure will most likely be too large to 
embed in signatures.

2) there may be a set of rules that goes along with the roots. Just 
having roots trusted may not be right. Eg. my colleagues shouldn't trust 
email signed with my Thawte cert with [email-masked] in it, it 
should be signed with the Netscape CA ... This one I really haven't 
given much thought to.

3) Some mechanism for transporting that trust structure. I would suggest 
LDAP, but that requires a standard mechanism to get to it, just like we 
need a standard means for disseminating certificates

 > I think the principle is the same, though.

It's very similar, with the possible exceptions of the rules (see above).

 > In the case of S/MIME, it's

Definitely not today - multiple signatures is something that would need 
to be added to most S/MIME software and would hamper deployment.

 > include every root key under the sun,

It's worse than that, some SSL intermediate certs are also included with 
some software (IE) ... Many SSL servers are misconfigured and don't send 
their intermediate certs.

 > and most certificates of

This is a case where the trust domain could be useful. Eg. the mailing 
list alias could have a defined trust domain, and their software would 
know not to use that private cert when posting to the list.

-- 
I am the dog in dogfood