Re: [saag] [lamps] subordinate vs intermediate certification authority

[Eliot Lear <[e-mail]>]

Ryan,

> 
> No one, anywhere, should ever pin to a CA that they don’t directly control, and even then, they still shouldn’t :)


> 
> Pinning is just a poor-man’s attempt at a server controlling the client’s trust anchors, and thus inevitably runs into issues, since client policy is inherently _client_ policy. Especially important is never pinning to a so-called “public” CA, precisely because their very existence is predicated on client policy that is intentionally not controlled/controllable by servers.

I think we’ve lost the point of the discussion.  In this case, the client starts with just one CA in its trusted root cache, and maybe not any.  These are small devices, and that one cert is a manufacturer CA.

When we are talking about pinning we are talking about an environment in which a public CA cert is somehow involved.  That “somehow” is very much up in the air. Another way of addressing this is with a domain constraint, but the problem with such a constraint is that the device needs to understand DNS, and it may or may not, in which case some sort of other method is needed to signal that a particular intermediate needs to be in the chain for validation.

The manufacturer is the only trusted element in this picture, as far as the device is concerned, but it IS trusted in this scenario to explicitly configure trust for the device.  Thus it is in a very good position to signal that a particular intermediate certificate must be present in the chain.  How to do that?

That’s the question of the hour, as I see it.  And how to do it such that it doesn’t completely cause various libraries to cough up blood?  BIGGER question.

Eliot