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

[Kent Watsen <[e-mail]>]

> i.e. adding a layer of indirection solves the problem in the classic way.

Yep  ;)


> When certificates, or when vouchers?

In this example, I meant certificates, but the same principle can apply to vouchers.  We only didn't discuss it because voucher-expiration was out-of-scope to SZTP, other than devices needing to ensure the voucher isn't expired, assuming a validity period is specified at all.


> These organization-wide commerical CA certificates seem impossible to obtain
> today.  At least, I haven't found a CA willing to sell that anymore, and I
> would love to be told I'm wrong.

Figures.  Oh well, they'll be out of business soon enough...


> A revision could change it from single item to an array of items.

Right, the simplest backward-compatible change would be:

OLD:
   type binary;

NEW:
   type union {
      type binary;
      type ct:trust-anchor-cert-cms;
   }


> That would be relatively easy to figure out in code, but I'm not entirely
> sure I understand the use case.  Are these independant anchors, or are the
> intended to be related.

It's just as I was saying before, to support cases where the pinned-domain-cert isn't a root CA, and the verifying software doesn't support partial-chain validation, hence external mechanisms have to supply the remainder of the chain.


Kent