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: 29 August 2019 19:49
> 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:
>     >> 1) LetsEncrypt does not issue 825 day certificates. (That's 2 1/4 years).
> 
>     > I never said LE issued 825 day certs. CA/Brower forum allows public CAs
>     > to issue 825 day certs. LE is currently at 90.
> 
> I know you didn't :-)
> The 90 day limit by LE is a significiant operational challenge.
> An 825 day limit is significantly less so, however my understanding is that the
> pressure is on to lower that limit significantly; to use ACME to (re-)issue
> certificates significantly more often, particilarly in light of the STAR work.

That  is correct, the CA/Browser forum is already discussing that: https://cabforum.org/2019/08/08/2019-07-25-minutes-of-the-server-certificate-working-group/#5-Validation-Subcommittee-Updatenbsp

" Another topic they discussed was the Certificate lifetime which Ryan introduced at the F2F in Thessaloniki. He is close to creating a draft ballot to reduce lifetime to roughly 1 year or roughly 13 months. "

But it is contentious:  https://cabforum.org/2019/08/26/2019-08-08-minutes-of-the-server-certificate-working-group/#5-Validation-Subcommittee-Updatenbsp

" Dean said that DigiCert is actively gathering feedback from large enterprise customers with multi-year certificates and no automation. "


> 
>     >> 2) I'm not worried about the LE key rolling, because the RFC8649 will
> likely
>     >> be used.
> 
>     > I wouldn’t necessarily say so. Have any CA providers, whether public
>     > CAs or private CA implementations (e.g. Microsoft ADCS) committed to
>     > supporting this? I'm not aware of a single one that has. Plus, RFC8649
>     > requires that the existing root CA includes the hash of the next root
>     > CA keys, meaning that when the existing LE root expires in 2035, then
>     > the next root CA could include the RFC8649 hash, and then the next root
>     > after that can be seamlessly rotated to. In like 2045. I hope to be
>     > long retired by then.
> 
> They haven't announced anything, but I think that it they will, and I think that
> it provides a very nice way to deal with private CA keys rolling over.
> 
>     > 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.

> 
> This is my only real objection to pinning an DNS-ID: the cost of the full PKI
> validation that it requires the Pledge to have (in a bug-free way for a period
> of decades), and that the rules for validation of chains won't change during
> that period of time.
> 
> This is core of the tussle.

Yep.

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