Re: [TLS] Root certificates in server certificate chains

[Marsh Ray <[e-mail]>]

On 08/31/2010 09:25 PM, Ryan Sleevi wrote:
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Marsh Ray
>>
>> 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.

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

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

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

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