[Anima] BRSKI: clarification needed on how MASA may check consistency of proximity-registrar-cert

[Esko Dijk <[e-mail]>]

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: [e-mail]<mailto:[e-mail]>