Hi Esko > On 24 Mar 2020, at 14:08, Esko Dijk <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
