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: 28 August 2019 17:37
> To: [e-mail]
> Subject: Re: [Iot-onboarding] what can pinned-domain-cert actually pin?
> 
> 
> Kent wrote:
>     >> In SZTP, pinned-domain-cert is the long-lived TA to a potentially short-
> lived
>     >> "Owner Certificate".  In theory, the root of the pinned-domain-cert PKI
> could
>     >> be a public CA but, in practice (because public CAs don't issue long-lived
>     >> certs), it means that a private PKI needs to be used.  Due to the nature
> of
>     >> these PKIs NOT being used to secure TLS-based services, the need for
>     >> a public root TA isn't there, so no big deal.
> 
>     > What do you mean by long-lived? Public CAs can issue EE certs with
>     > expiration times up to 825 days as per
>     > https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-
> 1.6.5.pdf.. When
>     > thinking about pinned nonceless vouchers for thing onboarding, that's
>     > still pretty long. If pinning the EE cert, then the voucher is valid
>     > until the EE cert expires (assuming of course that the non-bootstrapped
>     > thing has an accurate trusted view of time). If the public CA root is
>     > pinned, then that 825 day limit doesn't matter as the public CA root
>     > will be long lived. E.g. Lets Encrypt ISRG Root X1 root expires in
>     > 2035, but if pinning that then we have the DNS-ID issue.
> 
> 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.

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

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.

> 3) By Long Lived, I mean 10 to 30 years.
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
>