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
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
