Re: [Iot-onboarding] [Anima] EST CACerts and Pinned Domain Certificate

Eliot Lear <> Tue, 24 March 2020 13:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AF703A0A86; Tue, 24 Mar 2020 06:47:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 9yBX0a_6DawM; Tue, 24 Mar 2020 06:47:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 896EB3A0A4A; Tue, 24 Mar 2020 06:47:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=31840; q=dns/txt; s=iport; t=1585057634; x=1586267234; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=qhtXt4AYToVg/1jKjdnzOphWqyrbRa2eNSWoL23EkM0=; b=dRBQTc9T0EsXrErl+VxsYjEm1B+l15HhNnjzoo3Ns+s8j2fuPM3DafoQ T4qh5JTmlit7irKeArKEJHrvXvvJwH9SVChV1Ym7cIRAZ1WIkIikvIKke ypUR7sBtpwCN+CqbgvJunF53MWo6Dka3WShMDwiYPbHt+edbQ9lRfs2AL 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYBQANDnpe/xbLJq1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBJYEEgUABIBIqhBiJAodxJZtHCgEBAQwBAS8EAQGERAKCSzg?= =?us-ascii?q?TAgMBAQsBAQUBAQECAQUEbYVihWMBAQEBAgEjBFIFCwsYIAEJAgJXBhODJoJ?= =?us-ascii?q?dIKxsdX8zhUuEf4E4hSCHKYIAgREnDBSCHy4+hCIRgykygiwEoQ6PRoJGgla?= =?us-ascii?q?KXIlWHZteiyOcLYM0AgQGBQIVgWkigVgzGggbFTsqAYJBPhIYDZxmQAMwjQc?= =?us-ascii?q?CJgeCFAEB?=
X-IronPort-AV: E=Sophos; i="5.72,300,1580774400"; d="scan'208,217"; a="24711304"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Mar 2020 13:47:11 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id 02ODlAhm025504 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Mar 2020 13:47:11 GMT
From: Eliot Lear <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C23CBC0D-0807-488F-8AE9-E44D1D56754C"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
Date: Tue, 24 Mar 2020 14:47:10 +0100
In-Reply-To: <AM5P190MB0275693D588858FA230BE113FDF10@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM>
Cc: Michael Richardson <>, "M. Ranganathan" <>, "" <>, "" <>
To: Esko Dijk <>
References: <> <30498.1584991523@localhost> <AM5P190MB0275693D588858FA230BE113FDF10@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Iot-onboarding] [Anima] EST CACerts and Pinned Domain Certificate
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, 24 Mar 2020 13:47:33 -0000

Hi Esko

> On 24 Mar 2020, at 14:08, Esko Dijk <> wrote:
> Hello Michael,
> Looking at text in 5.6.2 of BRSKI:
>   The 'pinned-domain-cert' is not a
>   complete distribution of the [RFC7030] section 4.1.3 CA Certificate
>   Response, which is an additional justification for the recommendation
>   to proceed with EST key management operations.  Once a full CA
>   Certificate Response is obtained it is more authoritative for the
>   domain than the limited 'pinned-domain-cert' response.
> Which basically says that the Domain CA cert (that is present as 'pinned-domain-cert') is a sort of partial response to the CA Certificates Response of EST.

The primary purpose of the pinned-domain-cert is to validate the previously established TLS connection.  

> So, the Domain CA cert must be included in the full CA Certificate Response.
> Suppose the full response does not contain Domain CA cert. If the Pledge receives the full response and - as stated in above text - replaces the limited response (with Domain CA) with the more authoritative full response (without Domain CA cert) then it would have to discard its Domain CA cert! That's not wanted in this case. So from this I would conclude that Domain CA cert needs to be in the (full) CA Certificates Response of EST.

But this to me seems like a misconfiguration, because RFC 7030 states in Section 4.1.3:

   The EST server MUST include the current root CA certificate in the

> Another angle to consider is the following: by design, the pinned-domain-cert is in BRSKI a Domain CA cert (i.e. it must be a CA). Why would any CA certificate not be included in the list of CA certificates, that is given by the CA Certificates Response? 

Why, indeed!

> Third, in Section 5.9.1.:
>   The pledge SHOULD request the full EST Distribution of CA Certificates message.  See RFC7030, section 4.1.
>   This ensures that the pledge has the complete set of current CA
>   certificates beyond the pinned-domain-cert
> This suggests that pinned-domain-cert is part of the complete set of current CA certificates. 


> RFC 7030 is not fully clear to me regarding our question - there are requirements on what should be included in the message; let's assume that the EST server certificate is a subordinate CA; then the RFC states in 4.1.3:
>   if the EST CA is
>   a subordinate CA, then all the appropriate subordinate CA
>   certificates necessary to build a chain to the root EST CA are
>   included in the response.
> It is unclear if the EST CA's own certificate must be included or not in order to build the chain. In other words if the chain is X (subordinate CA) -> Y (subordinate CA) -> Z (root CA) then does it include only Y / Z or all of X / Y / Z ?

I agree that there is some ambiguity here, but because this amounts to a privileged operation on the device, and we are not using X to validate the current connection during the EST part of the transaction, it is safe to include it.  It’s all a matter of what happens next.  Now you have X in your store, chained to Y and Z, both also in your store.  TLS and DTLS should not blow up because the intermediate certificate is present in the store, even if it is presented in the HELLO.  The question is what happens if X and Y are not present in a normal HELLO.  TLS 1.3 says that’s ok.  But I’m not convinced that’s a good idea.

> Still, overall it would be strange to exclude Domain CA, as it is part of the full set of CA certificates, and because the "full response" would replace the single pinned Domain CA cert as indicated in BRSKI. 

But see above.