Technical Summary
This document defines a strategy to securely assign a candidate
device (Pledge) to an Owner using an artifact signed, directly or
indirectly, by the Pledge's manufacturer. This artifact is known as
a "Voucher".
This document defines an artifact format as a YANG-defined JSON or
CBOR document that has been signed using a variety of cryptographic
systems.
The Voucher Artifact is normally generated by the Pledge's
manufacturer (i.e., the Manufacturer Authorized Signing Authority
(MASA)).
This document obsoletes RFC8366: it includes a number of desired
extensions into the YANG module. The Voucher Request YANG module
defined in RFC8995 is also updated and now included in this document,
as well as other YANG extensions needed for variants of RFC8995.
Working Group Summary
Was there anything in the WG process that is worth noting?
For example, was there controversy about particular points
or were there decisions where the consensus was
particularly rough?
From Shepherd's report:
No.
Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type, or other Expert Review,
what was its course (briefly)? In the case of a Media Type
Review, on what date was the request posted?
From Shepherd's report:
There are several pre-existing implementations of BRKSI (RFC8995) that are using
the JSON encoding of the rfc8366 voucher according to the rfc7951 yang/json
mapping rules. These where validated to interoperate and that rfc8366bis still
provides backward-compatible definitions of those BRSKI vouchers.
There are two implementations of the subset of rfc8366bis required for cBRSKI
(sandelman, iot-consultancy).
There are two implementations for the subset of rfc8366bis required for BRSKI-PRM
(Siemens).
We think we have a significant number of implementers overall. The document
describes a superset of features of several different BRSKI variations. This list is likely
not complete.
We currently have no RFC embedded implementation reporting, but one is planned
to be included in the cBRSKI drafts (still in IETF processing).
Personnel
The Document Shepherd for this document is Sheng Jiang. The Responsible
Area Director is Mahesh Jethanandani.
IANA Note
(Insert IANA Note here or remove section)