Update: a Github issue is now opened on this topic, see https://github.com/anima-wg/anima-bootstrap/issues/146
I was working on new text for the consistency check of Section 5.5.5, to be able to use different identities for the TLS server (southbound, towards the Pledge(s)) and for the signing of Voucher Requests. I hit upon one issue which is the following text in 5.5.2: "A MASA MAY have a local policy that it only pins the End-Entity certificate." This is the RA certificate that Registrar had used to sign the Voucher Request. If the MASA happens to use the above ‘MAY’ policy, then the Pledge will receive a Voucher with a pinned domain certificate that it cannot use… See the Github issue for more details. So as long as this above rule is in the BRSKI spec, a Registrar is unable to use different identities for its southbound TLS server and for signing of Voucher Requests. Any further opinions on this? Esko PS for reference here was the new proposed text, which unfortunately doesn’t fix everything yet: --OLD The consistency check described above is checking that the 'proximity- registrar-cert' SPKI fingerprint exists within the registrar voucher- request CMS signature's certificate chain. This is substantially the same as the pin validation described in in [RFC7469] section 2.6, paragraph three. --NEW The consistency check described above is checking that at least one of the following two conditions holds: 1) the 'proximity-registrar-cert' SPKI fingerprint exists within the registrar voucher- request CMS signature's certificate chain. This is substantially the same as the pin validation described in in [RFC7469] section 2.6, paragraph three. 2) the 'proximity-registrar-cert' was signed by one of the CA certificates in the registrar voucher-request CMS signature's certificate chain. In other words, a valid chain can be built from the 'proximity-registrar-cert' to the root CA of the CMS signature's chain. From: Anima <[email protected]> On Behalf Of Esko Dijk Sent: Wednesday, October 7, 2020 12:04 To: [email protected] Cc: [email protected]; Michael Richardson <[email protected]> Subject: [Anima] BRSKI: clarification needed on how MASA may check consistency of proximity-registrar-cert Hello all, The following question came up during implementation of BRSKI: when the MASA verifies the prior-signed-voucher-request and its included ‘proximity-registrar-cert’ per Section 5.5.5, does the ‘proximity-registrar-cert’ necessarily need to be included in the Registrar’s CMS signature cert chain? Because for cases where a Registrar uses different identities (keypairs) for TLS-server and for Voucher-Request signing, the CMS signature cert chain will typically not include the TLS-server cert and hence the ‘proximity-registrar-cert’ will not appear directly in the CMS signature cert chain. Instead the MASA can verify that the ‘proximity-registrar-cert’ is directly *signed* by one of the CA(s) present in the CMS signature cert chain; thus it can be trusted. Example: Domain CA (root) | Subordinate CA | \ Registrar RA Registrar RA cert 1 cert 2 (TLS server) (signing) The RA cert 1 is used for the TLS server. The RA cert 2 is used for signing the Voucher-Request to MASA. The RA cert 1 is seen by the Pledge and present in the ‘proximity-registrar-cert’ field. MASA sees the following chain in the CMS signature: Domain CA (root) | Subordinate CA | Registrar RA cert 2 My interpretation of current BRSKI Section 5.5.5 is that the verification / consistency-check at MASA will now fail. However, another opinion in my team is that it can succeed because MASA can verify that RA cert 1 is signed by ‘Subordinate CA’ and hence can be trusted. On the other hand, RA cert 1 and RA cert 2 are different entities logically so then the “proximity” assertion of BRSKI would be weakened. Any opinions on this? For interoperability, it needs to be clear for the Registrar how the MASA will perform, if this verification is enabled, the verification of Section 5.5.5. This impacts with what identity it can sign Voucher-Requests. Best regards Esko Dijk IoTconsultancy.nl | Email/Teams: [email protected]<mailto:[email protected]>
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
