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

[Esko Dijk <[e-mail]>]

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 <[e-mail]> On Behalf Of Esko Dijk
Sent: Wednesday, October 7, 2020 12:04
To: [e-mail]
Cc: [e-mail]; Michael Richardson <[e-mail]>
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: [e-mail]<mailto:[e-mail]>