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

[Kent Watsen <[e-mail]>]

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. 

The "private CA roll-over" scenario you mention is side-stepped by enabling the Owner Certificate to itself be a partial chain (i.e., total-chain = partial-root-chain + partial-owner-cert-chain), hence the partial-root-chain part can be protected by some offline HSM while signing (e.g., annually) some middle-level CAs that are used to sign the actual Owner Cert EE cert.  

Separately in SZTP, there is the notion the device dynamically (during bootstrap) receiving the TA for a bootstrap server it it being redirected to.  In this case, the bootstrap servers are presenting a TLS-based service (specifically, HTTPS), and so EE certs MAY have a public root TA.  It was discussed at one point that the TA cert may expire and thus wouldn't it be better to enable the TA to be expressed as a 2-tuple [ <long-lived TA cert (MAY be a public CA)>, <name of some 'subject' matter in the TA-issued CA cert>].  But this became complicated and, instead, we opted for introducing alerts/alarms for when certificates are nearing expiration.

Part of what made it complicated is that one can imagine an organization obtaining a single top-level organization-wide commercial CA certificate that it uses for a variety of reasons, only one of which is to sign vouchers.  Thus, in such cases, the 2-tuple becomes a 3-tuple (and perhaps even an N-tuple), e.g.:  [ <long-lived TA cert (MAY be a public CA)>, <name of some 'subject' matter in the TA-issued CA cert>, <name of some 'subject' matter in the voucher-issuer's cert>].

Related, though not exactly, I regret that RFC 8366 states that the pinned-domain-cert value is a single X.509 cert, as opposed to a potential chain of certs.  One reason is so as to simplify support for path-validations, as not all libraries support partial-chain validation.

Kent


> On Aug 27, 2019, at 12:30 PM, Michael Richardson <[e-mail]> wrote:
> 
> 
> There has been some private conversation about what kinds of things an
> RFC8366 voucher can pin.  The discussion was about the utility of pinning an
> EE certificate that comes from LetsEncrypt (LE), or some commercial CA such as
> Verisign or Goddy, etc.
> 
> This was also in the context of a long-lived nonceless voucher.
> Pinning the CA of a 90-day LE EE voucher is meaningless without also
> including a DNS-ID.  My take on this is that this is a new kind of voucher,
> as it requires significantly more logic in the pledge to evaluate things.
> 
> It has come up that even with a private CA, that there is a problem if the
> private CA is pinned, and the CA rolls over.  In particular, even for
> vouchers with validities of more than a few days, if the private CA should
> roll over during that period, there is a problem.
> 
> RFC8649 seems to offer an additional way out for this.
> I doubt that CAs will let one include this extension, but if they did it
> might also help with the above problem.
> 
> 
> 
> From: [e-mail]
> Subject: RFC 8649 on Hash Of Root Key Certificate Extension
> Date: August 26, 2019 at 3:04:40 PM EDT
> To: [e-mail], [e-mail]
> Cc: [e-mail], [e-mail], [e-mail]
> Reply-To: [e-mail]
> 
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
>        RFC 8649
> 
>        Title:      Hash Of Root Key Certificate Extension 
>        Author:     R. Housley
>        Status:     Informational
>        Stream:     IETF
>        Date:       August 2019
>        Mailbox:    [e-mail]
>        Pages:      10
>        Characters: 22410
>        Updates/Obsoletes/SeeAlso:   None
> 
>        I-D Tag:    draft-ietf-lamps-hash-of-root-key-cert-extn-07.txt
> 
>        URL:        https://www.rfc-editor.org/info/rfc8649
> 
>        DOI:        10.17487/RFC8649
> 
> This document specifies the Hash Of Root Key certificate extension.
> This certificate extension is carried in the self-signed certificate
> for a trust anchor, which is often called a Root Certification
> Authority (CA) certificate.  This certificate extension unambiguously
> identifies the next public key that will be used at some point in the
> future as the next Root CA certificate, eventually replacing the
> current one.
> 
> This document is a product of the Limited Additional Mechanisms for PKIX and SMIME Working Group of the IETF.
> 
> 
> INFORMATIONAL: This memo provides information for the Internet community.
> It does not specify an Internet standard of any kind. Distribution of
> this memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>  https://www.ietf.org/mailman/listinfo/ietf-announce
>  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [e-mail].  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> 
> 
> 
> -- 
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> -- 
> Iot-onboarding mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iot-onboarding