In BRSKI and the constrained version described in draft-ietf-6tisch-dtsecurity-zerotouch-join, the voucher is signed by the MASA using a key that has been pre-installed into the pledge by the manufacturer. The pledge can validate the voucher because the MASA knows (by constructin) which keys the pledge knows about.
The Registrar (JRC) that mediates the operation, and which is vouched
for by the voucher using the pinned-domain-cert. The Registrar does not
*NEED* to validate the voucher, implementations might want to do this
because it's useful to know whether the voucher validates as part of
the audit-trail.
In the CMS case, there isn't any great constraint on the signed CMS
structure, and one can easily include any needed public keys for the MASA
as part of the unprotected SignedData.certificates.
When the signature mechanism is COSE however in the constrained-voucher
situation. In such a situation, the RFC8152 provides four buckets:
<https://tools.ietf.org/html/rfc8152#section-4.2>
protected
unprotected
payload
signature
We are using the CBOR SID mechanism to provide a keys for the mapping of the
YANG voucher model into the protected bucket. It's unclear to me if we
should be including "alg" into that bucket as well.
The question that arises is how (and if!!) to convey the MASA's public key to
the Registrar. Secondary to this is in what format(s).
Options are:
1) use the COSE(8152, section 3.1) kid parameter.
2) actually say we are using CWT, and make use of the claims in
RFC8392, and the x5c is listed in some other document I can't find right
now.
3) use our own SID value(s) for some set of Raw-Public-Key or PKIX format key
which would be placed in the unprotected bucket.
The Registrar would be encouraged to *remove* those keys from the
unprotected bucket to reduce space.
4) provide an entirely new BRSKI-MASA API call by which the Registrar can
retrieve the right set of public keys to validate the voucher with.
5) use the existing /voucherrequest, but define the result (when an
application/cbor+cose voucher request is presented) to be a multipart
result, with the second piece being the public key "bag".
6) like (5), but instead of MIME multipart, return a CBOR array with
the voucher as the first item, and the extra keys as additional entries.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
