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

Kent Watsen <> Tue, 27 August 2019 19:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B5DD120113 for <>; Tue, 27 Aug 2019 12:56:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 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] 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 e_sbBThOniFt for <>; Tue, 27 Aug 2019 12:56:52 -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 4E5381200FF for <>; Tue, 27 Aug 2019 12:56:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1566935810; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=A9gM/HTos58M3fsNPPE1TXR/fbcoIx6kBEkOP0O4HvY=; b=FgyqzdzMf+PnNldrWx2YhkW8nxg2UMjo3SUAHu98Sq21g2apPi+NTQ/ybpV0eC05 bWqCSgkek28HX1ps4onoqJWi/jlMCXSIq1/054WXjVW7bMJDpo5oL1C2VZH8Qdpjutz 5ifMvLaee+CqJxtkSBcv2Fg6JfjXGecng4Tn9IlI=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_702B542C-0F95-4BD2-8C26-3FAC591F9310"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 27 Aug 2019 19:56:50 +0000
In-Reply-To: <12738.1566933705@localhost>
To: Michael Richardson <>
References: <2693.1566923418@localhost> <> <12738.1566933705@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 19:56:54 -0000

> 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:

   type binary;

   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.