[Anima] Discussion on BRSKI/cBRSKI/BRSKI-PRM requirements on signing the PVR

[Esko Dijk <[e-mail]>]

Hi Steffen, Thomas, (WG),

Based on our discussion in the ANIMA design team I looked up the requirements for signing the PVR, and including the certificate chain in the PVR, for BRSKI/cBRSKI.
Just to compare. For BRSKI-PRM there may be other requirements because of the Registrar-Agent that sits in between.


RFC 8366 5.4 – for Vouchers only:

   The CMS structure SHOULD also contain all of the certificates leading
   up to and including the signer's trust anchor certificate known to
   the recipient.  The inclusion of the trust anchor is unusual in many
   applications, but third parties cannot accurately audit the
   transaction without it.

RFC 8995 5.2 – for the PVR, it basically copies the above requirement and requires signing by the Pledge’s IDevID credentials:

application/voucher-cms+json:
    [RFC8366] defines a "YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure", and the voucher-request described in Section 3 is created in the same way. The media type is the same as defined in [RFC8366]. This is also used for the pledge voucher-request. The pledge MUST sign the request using the credentials in Section 2.3.

Now the target recipient of the PVR is the MASA. (Again for PRM this may be different and include Registrar as well...? But not in BRSKI I think.)
So the requirement on the Pledge is it SHOULD include in the PVR all the certificates needed for the MASA to build the complete chain. And by design (same vendor) the Pledge should know what the deployed MASA will now about the vendor’s Pledges i.e. what trust anchors are stored in MASA. This would I think need to be at least the Pledge’s own IDevID EE certificate. If “trust anchor” is interpreted as a “CA”, it needs to be at least this IDevID EE certificate and the next-in-line CA certificate, which may be a sub-CA and not a root CA.
It’s not a MUST requirement.

Next: In cBRSKI, the PVR size is reduced by completely removing any signing certificates: only the signature itself is included!  This works because we have vendor’s serial-number to uniquely identify a Pledge to MASA. And if serial numbers would collide in some case, we explain how to use the “key ID” (kid) field to  identify the signer in those cases. And an optional way to include the complete cert chain, if really needed for something, by including it in the x5bag container element.

The MASA is this solution needs to store all the cert-chains for all the Pledges it supports – including their IDevID EE certificates -- an extra burden on MASA, compared with BRSKI, but one which helps us achieve the smaller size of PVR.
So cBRSKI changes the “SHOULD” requirement from 8995 to a SHOULD NOT in Section 9.2.2.

Also in cBRSKI, the Registrar obtains the IDevID of the Pledge from the DTLS handshake. Not from the PVR.
This seems allowed per BRSKI Section 9.3,

    A registrar accepts or declines a request to join the domain, based on the authenticated identity presented

It doesn’t say where the IDevID identity should come from – PVR or the (D)TLS handshake supplied certificates. Having only one source should be fine ... ?

Regards
Esko