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

Kent Watsen <> Tue, 27 August 2019 18:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F43912088E for <>; Tue, 27 Aug 2019 11:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1AXHD_3MLo6d for <>; Tue, 27 Aug 2019 11:42:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31222120876 for <>; Tue, 27 Aug 2019 11:42:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1566931376; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=6P1S5m24kdeudGazxKyXQe9gH5dQRSgP8vUG7ip67Gg=; b=a4CboWpD9ijm9Nd4hMn+NgnrUWNN2uN6TW7HcI37JLB006RHoZ9f7u05wnqoEmYW In88X+aBpHUXmsTCNTYR/M1TXCilCk2Qk5zwtWTqAezkIpHhFGfkPzkKQXljqwGxNgl 7yNR/S8EaGcFJ6LafbmNnoMzzAyXMdF/aNDtWezg=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_90AD47FF-37F6-4CB2-9D0E-D0B316CA2750"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 27 Aug 2019 18:42:56 +0000
In-Reply-To: <2693.1566923418@localhost>
To: Michael Richardson <>
References: <2693.1566923418@localhost>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.08.27-
Archived-At: <>
Subject: Re: [Iot-onboarding] what can pinned-domain-cert actually pin?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IoT onboarding mechanisms <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Aug 2019 18:43:03 -0000

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.


> On Aug 27, 2019, at 12:30 PM, Michael Richardson <> 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:
> Subject: RFC 8649 on Hash Of Root Key Certificate Extension
> Date: August 26, 2019 at 3:04:40 PM EDT
> To:,
> Cc:,,
> Reply-To:
> 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:
>        Pages:      10
>        Characters: 22410
>        Updates/Obsoletes/SeeAlso:   None
>        I-D Tag:    draft-ietf-lamps-hash-of-root-key-cert-extn-07.txt
>        URL:
>        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
> For searching the RFC series, see
> For downloading RFCs, see
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to  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
> -- 
> Michael Richardson <>ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> -- 
> Iot-onboarding mailing list