Subject: RE: (Practical) S/MIME certificate chain handling

From: [email-masked] (Peter Gutmann)
Date: Tue, 1 Jul 2003 21:08:42 +1200

"Blake Ramsdell" <[email-masked]> writes:

>I agree, and that's why they send all the certificates along with messages to
>this date.  By "they", I mean S/MIME-enabled versions of Netscape, Outlook
>Express, Outlook, and the S/MIME plugin for Eudora that I wrote.

Just as another data point, a small portion of my certificate zoo consists of
cert chains from S/MIME sigs, and every one of them is a full chain (or at
least some sort of chain), rather than a single cert.  I don't track where
they originally came from, but they cover (at least) Outlook (many versions),
Netscape, and a few S/MIME gateways that auto-sign everything passing through
them (most of the stuff I've seen in general mail in fact would be auto-
signed, either by a gateway or because the sender turned it on and forgot
about it).  I do have some single-cert chains, but they're from oddball
applications like EDI messaging (the certs have EDI altnames and whatnot)
which aren't representative of general usage.

Peter.

---

From: "Julien Stern" <[email-masked]>
Date: Fri, 4 Jul 2003 18:07:12 +0200

On Mon, Jun 30, 2003 at 03:40:01PM -0700, Blake Ramsdell wrote:
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Julien Stern
> > Sent: Monday, June 30, 2003 3:35 AM
> > To: Blake Ramsdell; [email-masked]; [email-masked]
> > Subject: Re: (Practical) S/MIME certificate chain handling
> > 
> > > I believe that most clients transmit the certificate chain (not
> > > including the root) today.
> > 
> > To the best of my knowledge, Outlook does not, and it has 
> > quite a large
> > market share ... (Although, I'd be happy to know how to make 
> > it do so if
> > there is a way ;) ).
> 
> Outlook 2002 sends all the certificates in the chain (I just verified
> this).  When Jim Schaad wrote the code way back in something like
> Outlook 97, I'm fairly certain that it sent all the certificates also.
> This could very well be a case of misconfiguration of some sort, and I'd
> be happy to work through it with you offline.  The early S/MIME
> implementations all understood the utility of this, and included the
> certificates for exactly the reasons that you cite.

We did a bit of research, and it seems that, for Outlook, if
intermediate certificates are stored in the local machine stores, they
are indeed sent. However, if these certificates are stored in the user
stores (the ones in the user profile) they are not sent, despite the
fact the chain is correctly reconstructed. This behavior is different
from the one in Outlook Express.

> [many things regarding automatic verification snipped]

Regarding the rest of this thread, thanks to all for your enlightening
replies. I guess I'll take the pragmatic approach and attempt to focus
on the settings that actually work ;) And hopefully, at some point, I
will have the insurance that, given the extensions in my chain of cert,
and the available servers, _any_ S/MIME compliant receiver will indeed
be able to verify everything automatically, including revocation...

--
Julien

---

From: Darrell Dykstra <[email-masked]>
Date: Fri, 4 Jul 2003 12:53:07 -0400

> market share ... (Although, I'd be happy to know how to make 

I believe an end user can configure to some degree, which certificates are
sent in a signed message.  To access the UI in Outlook 2002, go to
Tools/Options/Security/Settings...  There should be a check box for "Send
these certificates with signed messages".  I have not verified as to what
exactly this checkbox controls (I am in a strict 1 level hierarchy so I
can't verify if sub-CA's are included without some prep work).  I would
think that, despite its naming, Outlook 2002 will always send the signer's
certs, and depending on the state of the checkbox, the chain from the
signer's certs to a trusted root.

Can anybody confirm or deny my theory (do you have a more complex hierarchy
to test with)?

Thanks,
Darrell

---

From: [email-masked]
Date: Tue, 15 Jul 2003 14:26:44 +0000

Jim,

apologies for the delay. I've been on vacation and have just salvaged
your email from the 800 or so spams that were waiting for me :-) I also
got over enthusiastic about my mail box management and succeeded in
deleting the original of this. The headers are munged because I recovered
this text from the IETF archive!

Jim Schaad wrote:

> I hope there is a great deal more to this than what you are stating for
> a Best Practice recommendation.

Indeed. I did say it was 'a' recommendation without alluding to the
others, some of which concern the management of the root CA certificate
store.

> 1.  Acceptance of root certificates by end-users is a real problem.
> They tend to say yes without any good reason to do so.  This means that
> it is easy to stick "bad" root certificates on a persons machine

I agree completely. At the organisation level, however, the management
of the Root CA store is a administrative policy issue rather than a
technical one. The inclusion of the trust chain with outgoing emails
facilitates the distribution of trust in the continued absence of a
global recovery mechanism. It does not preclude correct and secure usage
of such paths, in-line with policy, at the recipient device.

> If you are really working in a single structure, then this information
> should be automatically distributed to people's machines and not send
> from the sender.

By a single structure do you mean a single organisation or a single
trust tree ? Policy should certainly be managed centrally although I'm
unconvinced that many organisations really understand the future,
legal implications of permitting their end-users to grow their own Root
CA stores. As you imply, we are not yet anywhere near widespread, correct
usage. In the main this is due to the fact that Digital Certificates are
still being used in many areas merely as technology enablers rather than
the trust mechanisms that they are designed to be. As such, acceptance of
trust (and thus liability) by end users is too easy and uncontrolled and
simply allows the software to work rather than trust be maintained.

Chris

Royal Mail is a trading name of Royal Mail Group plc. Registered in England and
Wales.
Registered number 4138203. Registered office at 148 Old Street, LONDON EC1V 9HQ