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

[Phillip Hallam-Baker <[e-mail]>]

On Mon, Feb 8, 2021 at 2:09 PM Ryan Sleevi <[e-mail]> wrote:

>
> On Mon, Feb 8, 2021 at 1:40 PM Eliot Lear <[e-mail]> wrote:
>
>> 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.
>>
>
> Yes, and I'm explicitly telling you this is fundamentally unsafe and
> unsound by design :)
>
> You cannot simply "reuse" existing PKIs, bound by existing / other policy
> agreements, and expect a stable interoperability with a different policy
> authority.
>

The problem is deeper than that.

The PKIs bind keys to names. Neither the naming scheme of the WebPKI nor
the naming scheme of DNS is a remotely appropriate fit for IoT.

The policy incompatibilities are a consequence of the naming mismatch.

The device PKIs I have been involved with that used PKIX, all used a
namespace that was separate from everything else. And fo course, once you
do that, if the names don't have to be human readable, a direct trust model
in which the name is a fingerprint of the public key works much better.