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

[Eliot Lear <[e-mail]>]

> On 28 Aug 2019, at 11:08, Owen Friel (ofriel) <[e-mail]> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: Iot-onboarding <[e-mail] <mailto:[e-mail]>> On Behalf Of Kent
>> Watsen
>> Sent: 27 August 2019 19:43
>> To: Michael Richardson <[e-mail] <mailto:[e-mail]>>
>> Cc: [e-mail] <mailto:[e-mail]>
>> Subject: Re: [Iot-onboarding] what can pinned-domain-cert actually pin?
>> 
>> 
>> 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 <https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf>.


I don’t think it’s long enough.  A manufacturer at least needs the option to issue a voucher that doesn’t expire for a cert that doesn’t expire.  We just don’t know how long a device might sit in a drawer, nor whether the manufacturer would continue to exist or support a particular device.

One issue we might want to take into account: time may be quite a fluid concept as far as end device clocks are concerned.  That is- how does the client know whether a cert actually is expired?  Now I don’t think we can count on them NOT knowing, but it could also be the case that cert expiry in these cases should just be ignored in favor of the voucher expiry.

Eliot