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
