Subject: Re: [TLS] Root certificates in server certificate chains

From: "Ryan Sleevi" <[email-masked]>
Date: Tue, 31 Aug 2010 22:25:19 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Marsh Ray
> Sent: Tuesday, August 31, 2010 9:57 PM
> To: Matt McCutchen
> Cc: [email-masked]; [email-masked]
> Subject: Re: [TLS] Root certificates in server certificate chains
>
<SNIP>
>
> >> But, in this case, why allow the server to include a root
> certificate
> >> in the certificate chain in the first place?
> >
> > Perhaps as a hint to clients that might decide they wish to add that
certificate as a trust anchor, possibly after further research?
>
> To make it easier for users to "Permanently store this exception"?  :-P

What about the edge case of a server requesting a client certificate from
a trusted list of CAs, for which the client does not have the trusted root
in their list. This would apply both to 'simple' authentication
(Root->Intermediate->EE) and to the more complex scenario of bridge CAs,
where the client may have Root A->Intermediate->EE, but the server has
Root B->Intermediate'->EE, where Intermediate' is the cross-certified
certificate.

If the client feeds in the list supplied by the server into the list of
certificates to consider when building/evaluating a path to one of the
specified trusted CAs (as NSS does implicitly, AFAICT, and which OpenSSL,
Secure Transport, and SChannel all support), then the end-user should be
able to successfully build a path that contains one of the server
requested CAs.

Of course, such an implementation puts the onus on the clients to do this,
and there are alternatives that you could configure at the server (eg: by
specifying a request for Intermediate/Intermediate', rather than Root B),
but it seems valid/useful use case.

It can also act as a hint to the client of how much of the chain they need
to send. Consider if the client had EE->Intermediate->Root A->Root
A'->Root B, and the server indicated trust for Root A. If the client sent
EE->Intermediate->Root A->Root A' in their response, some servers that
have limited/partial implementation of the RFC 3280 path building
algorithms may have trouble building/validating the client certificate, as
they may only check the final certificate in the chain/final certificate's
issuer against their list of trust anchors, ignoring the fact that Root A
occurred earlier. This was the case with OpenSSL for a time, and with NSS
prior to libpkix integration, though I believe support for this scenario
has been improved in subsequent versions in the case of the former, and
certainly in the case of the latter.

---

From: Marsh Ray <[email-masked]>
Date: Tue, 31 Aug 2010 22:58:06 -0500

On 08/31/2010 09:25 PM, Ryan Sleevi wrote:
> in their list.

I've tried to do that in some software and some client libraries really 
didn't want to cooperate. For this system we did everything we could, 
including opening paid support incidents with vendors, in order to avoid 
having to add our cert to the client's trusted roots because it 
represented an unnecessary expansion of scope and privilege for our 
little application-specific PKI scheme.

> This would apply both to 'simple' authentication

OK, so I'm an end user. I have a pop up dialog box with a yellow warning 
triangle. It has a bunch of words on it I don't understand. Or I thought 
I understood these words but they don't make any sense to me now. Words 
like: "credentials", "client", "server", "certificate", "authority", and 
"authentication".

It is clear though that I am being presented with a choice of great 
consequence. Probably if I make the wrong choice my computer will get 
infected again and I'll have to endure being spoken to condescendingly 
by my 14 year old nephew who's the family computer whiz. So:

"Do you wish to allow the use of your user certificate client 
authentication credentials for building a path that contains one of the 
certifying authorities requested by the server? Note: You will not be 
prompted again for this session unless make a clear cookie cache."
   * Click "OK" to spin the barrel and pull the trigger.
   * Click "Cancel" to definitely not succeed.

Which one should I choose? Why?

What does it mean when you suggest that I "successfully build a path 
that contains one of the server requested CAs"?

Oh I get it now. You're saying I should insert my card into the reader 
the bank gave me and enter my PIN when I see the bank's logo...

> certainly in the case of the latter.

If you're saying that this scheme is too complicated for mere mortal 
application developers (like me) to implement securely more than half 
the time, I think I'm convinced. The scary thing is that if I read your 
description enough times I start to feel like I understand it. But 
probably I don't.

This took how many years for OpenSSL and NSS to get right? Those guys 
are the full-time pros, what hope is there for the rest of us?

So sorry for the hang-ups in this email, I'm certainly not trying to 
give anybody static about it. I think your technical explanation is 
probably just fine.

But I just can't shake the feeling that there has got to be a better way 
out there somehow. Well, maybe not. Authentication and trust really are 
hard and deeply complicated problems.

- Marsh

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 01 Sep 2010 01:22:37 -0400

>    * Click "Cancel" to definitely not succeed.

That message just describes client-certificate authentication.

> that contains one of the server requested CAs"?

The server sends a CertificateRequest message for Root B, so the client
must send a chain from its certificate to Root B.  The only such chain
goes through the Intermediate' cross-certificate.  The client's local
database does not contain this certificate, so if path discovery only
uses the local database, the client will be unable to construct an
acceptable chain.  But if path discovery also uses the server's chain,
the client will construct the chain Client-Intermediate'-Root B, which
is acceptable to the server.  The client's chain is for the server's
consumption only, so there is no risk to the client in changing the way
it is constructed.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 01 Sep 2010 01:33:43 -0400

> but it seems valid/useful use case.

This isn't a use case for the server sending a root certificate.  I
would assume that the client's chain, like the server's chain, MAY omit
the root certificate.  Then, the client can take Intermediate' from the
server's chain and simply send Client-Intermediate', where the issuer of
Intermediate' is Root B, matching the CertificateRequest.  The client
does not need the actual Root B certificate.

> EE->Intermediate->Root A->Root A' in their response, [...]

The server's CertificateRequest will contain Root A's distinguished
name, and the client should use that as the indication of where to stop.
Again, there is no benefit to sending the actual certificate for Root A.

-- 
Matt