Re: [Iot-onboarding] what can pinned-domain-cert actually pin?

["Owen Friel (ofriel)" <[e-mail]>]

> -----Original Message-----
> From: Iot-onboarding <[e-mail]> On Behalf Of Michael
> Richardson
> Sent: 30 August 2019 21:38
> To: Owen Friel (ofriel) <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Iot-onboarding] what can pinned-domain-cert actually pin?
> 
> 
> Owen Friel (ofriel) <[e-mail]> wrote:
>     >> > Regardless, LE root rotation is not at issue here. The issue is what
>     >> > happens if an operator wants to move from GoDaddy to
>     >> > LetsEncrypt. Either (i) all existing vouchers are dead or (ii) we need
>     >> > multiple pinned-domain-cert entries. And maybe (i) is fine and if an
>     >> > operator wants to change root CA providers, then the operator sucks it
>     >> > up and reissues all nonceless vouchers.
>     >>
>     >> We could also consider pinning the public key of the Registrar.
>     >> This is how constrained-BRSKI works.  There are crypto-hygiene issues
> here,
>     >> but maybe it's better than putting more fragile logic into a device that
> might
>     >> remain on a shelf for many years.
> 
>     > Right. You could pin the raw public key and then the RA EE cert could
>     > rotate provided the key remained the same. Obviously any changes to the
>     > key (length, algorithm, etc.) invalidate vouchers.
> 
> Depending upon what kind of processing we could assume on the pledge (thus
> the tussle), one could imagine that if the key/algorithm/etc. became too weak,
> that one could use the key to sign another stronger certificate to be used going
> forward.
> 
> This doesn't make the key stronger suddenly, but unless the key is actually
> compromised, it allows the old nonceless vouchers to be used in the future.
> 
> My take is that this is a lot of code effort in the Pledge.
> If the Enterprise/Registrar would cause to be operated a long-lived private
> CA, then the problem goes away.   It doesn't have to be operated by the
> Enterprise itself; it could be operated by a service provider that they trust.  In
> effect, it's just a new form of MASA.
> 
> I think that this is really the right way to go: to allow chains of vouchers pinning
> keys, which can then be used to issue new vouchers (which could pin new keys).
> This solves the long-term problems you have mentioned, and removes the
> external dependancy upon a MASA.... by createing a new dependancy upon an
> internal MASA.

I am not convinced that allowing chains of vouchers pinning keys is simpler that allowing a voucher to have 2 or more pinned-domain-certs. In fact, I would the code in the pledge to support chains of vouchers pinning keys is probably more complex than the code to allow an array of pinned-domain-certs in the voucher. With any TLS library code I have ever messed with, you setup the trust store to include your set of 1 or more CAs, and the TLS stack takes care of everything once the trust store is setup. If you have a chain of vouchers pinning keys - then that's all application specific code.

> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-