Hi Eliot, You mention:
> 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. 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 <l...@cisco.com> Sent: Tuesday, March 24, 2020 14:47 To: Esko Dijk <esko.d...@iotconsultancy.nl> Cc: Michael Richardson <mcr+i...@sandelman.ca>; M. Ranganathan <mra...@gmail.com>; iot-onboard...@ietf.org; anima@ietf.org Subject: Re: [Anima] [Iot-onboarding] EST CACerts and Pinned Domain Certificate Hi Esko On 24 Mar 2020, at 14:08, Esko Dijk <esko.d...@iotconsultancy.nl<mailto:esko.d...@iotconsultancy.nl>> 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 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 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. Right. 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. Eliot
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
