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

From: "M. Ranganathan" <[email-masked]>
Date: Sat, 21 Mar 2020 19:10:29 -0400

Hello,

Consider an integrated BRSKI-EST server. The pledge bootstraps and gets the
pinned domain certificate. Then the pledge queries EST for the ca-certs. Is
it correct to require that the pinned domain cert must be present in the
CACerts collection returned by the EST server when the pledge does a
cacerts query  (but can include additional certificates) ?

Thanks

Ranga

-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Mon, 23 Mar 2020 15:42:54 +0100

> On 22 Mar 2020, at 00:10, M. Ranganathan <[email-masked]> wrote:
> 
> Hello,
> 
> Consider an integrated BRSKI-EST server. The pledge bootstraps and gets the pinned domain certificate. Then the pledge queries EST for the ca-certs. Is it correct to require that the pinned domain cert must be present in the CACerts collection returned by the EST server when the pledge does a cacerts query  (but can include additional certificates) ? 

I don’t think so, because you may make that query from time to time if you are reregistering.  What do others think?

> 
> Thanks 
> 
> Ranga
> 
> -- 
> M. Ranganathan 
> 
> -- 
> Iot-onboarding mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iot-onboarding

---

From: Michael Richardson <[email-masked]>
Date: Mon, 23 Mar 2020 15:25:23 -0400

> cacerts query  (but can include additional certificates) ?

No, I don't think that the specific cert needs to be in the cacert set.

1) It makes sense that a trust anchor(s) returned ought to validate the pinned
   domain cert.  This is because a certificate renewal operation needs to connect to the
   EST server correctly.
   Obviously, in a very degenerate case, there is only the one owner
   certificate, and it is used for everything.
   section 3.3 of draft-richardson-anima-registrar-considerations suggests
   that, and I include the text at the bottom.

2) The pinned-domain cert is validated by the pledge using the voucher.
   It does not need to be validatable via the cacerts for BRSKI-EST to work,
   provided that the TLS connection is never broken.
   (If the TLS connection is broken, then the enrollment should restart.
   We considered many ways around this, but I think in the end, we decided
   not to do this.  HTTP/1.1+ persistent connections or die)

===

3.3.  Home Network

   Home networks and small offices that use residential class equipment
   are the most challenging situation.  The three-tier PKI architecture
   is not justified because the ability to keep the root CA offline has
   no operational value.

   The home network registrar should be initialized with a single key
   pair used as the certificate authority.

   Secret splitting is useful in order to save the generated key with a
   few neighbours.  It is recommended that the entire PKI system
   database (including CA private key) be encrypted with a symmetric key
   and the results made available regularly for download to a variety of
   devices.  The symmetric key is split among the neighbours.

   The most difficult part of the Home Network PKI and Registrar is
   where to locate it.  Generally it should be located on a device that
   is fully owned by the home user.  This is sometimes the Home Router,
   but in a lot of situations the Home Router is the ISP's CPE router.
   If the home has a Network Attached Storage (NAS) system, then running
   it there is probably better.

   A compromise for CPE devices owned by the ISP that can run containers
   is for the Registrar to be located on detachable storage that is
   inserted into the CPE.  The detachable storage is owned by the home
   owner, and can be removed from the CPE device if it is replaced.
   More experience will be necessary in order to determine if this is a
   workable solution.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Esko Dijk <[email-masked]>
Date: Tue, 24 Mar 2020 13:08:33 +0000

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

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? 

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 ?

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. 

Best regards
Esko

-----Original Message-----
From: Anima <[email-masked]> On Behalf Of Michael Richardson
Sent: Monday, March 23, 2020 20:25
To: M. Ranganathan <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Anima] [Iot-onboarding] EST CACerts and Pinned Domain Certificate

===

3.3.  Home Network

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Mar 2020 14:47:10 +0100

Hi Esko

> On 24 Mar 2020, at 14:08, Esko Dijk <[email-masked]> wrote:
> 
> Hello Michael,
> 

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

> 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 auth…

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
   response.

> 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 cer…

Why, indeed!

> This suggests that pinned-domain-cert is part of the complete set of current CA certificates. 

Right.

> 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 i…

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 indicate…

But see above.

Eliot

---

From: Esko Dijk <[email-masked]>
Date: Tue, 24 Mar 2020 14:33:33 +0000

Hi Eliot,

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

That requirement in 7030 doesn’t really help to answer the question in case that the EST server’s CA certificate is a subordinate CA of the root CA. Sure, the root CA (self-signed) must be included. But what if the pinned-domain-cert is a subordinate CA cert (Domain CA cert) which is not the root CA? Then it is not clear from 7030 text alone if that Domain CA cert should be included or not.  Having a subordinate CA cert seems to me a valid case also – i.e. the Registrar pins its own CA cert that is also used for its EST server as a CA that signs the operational certs. If a Pledge performs the EST CA Certificates Request, it will get e.g. the EST CA cert plus a self-signed root CA cert for the Domain. The EST CA cert is in this case the pinned-domain-cert, and it is a Domain CA cert, but not necessarily *the* Domain CA root cert.

Esko

From: Eliot Lear <[email-masked]>
Sent: Tuesday, March 24, 2020 14:47
To: Esko Dijk <[email-masked]>
Cc: Michael Richardson <[email-masked]>; M. Ranganathan <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Anima] [Iot-onboarding] EST CACerts and Pinned Domain Certificate

Hi Esko

On 24 Mar 2020, at 14:08, Esko Dijk <[email-masked]<mailto:[email-masked]>> wrote:

Hello Michael,

   response.

Why, indeed!

Right.

  if the EST CA is

But see above.

Eliot