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

[Eliot Lear <[e-mail]>]

This is worth some discussion tomorrow.  Should I add it to the agenda?

Eliot

> On 27 Aug 2019, at 21:56, Kent Watsen <[e-mail]> wrote:
> 
> 
> 
>> 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
> 
> --
> Iot-onboarding mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iot-onboarding