Subject: [Anima] a better Introduction for anima-constrained-voucher

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Sep 2021 20:42:31 -0400

Hi, I'm trying to make the Introduction better, as you suggested.
I'm not sure how to reduce the amount of "other reading" that is required to
understand where this protocol starts.    This is what I have so far,
rewritten slighty.

I would appreciate guidance and suggestions on how much background
(repetition or 8995 and 8366) should be done, and how much "go read that"
needs to be made.

1.  Introduction

   Secure enrollment of new nodes into constrained networks with
   constrained nodes presents unique challenges.  As explained in
   [RFC7228], the networks are challenged and the nodes are constrained
   by energy, memory space, and code size.

   The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol
   described in [RFC8995] provides a solution for secure zero-touch
   (automated) bootstrap of new (unconfigured) devices.  In it, new
   devices, such as IoT devices, are called "pledges", and equipped with
   a factory-installed Initial Device Identifier (IDevID) (see
   [ieee802-1AR]), they are enrolled into a network.

   The BRSKI solution described in [RFC8995] was designed to be modular,
   and this document describes a version scaled to the constraints of
   IoT deployments.

   Therefore, this document defines a constrained version of the voucher
   artifact (described in [RFC8366]), along with a constrained version
   of BRSKI.  This constrained-BRSKI protocol makes use of the
   constrained CoAP-based version of EST (EST-coaps from
   [I-D.ietf-ace-coap-est]) rather than the EST over HTTPS [RFC7030].

   In BRSKI, the the [RFC8366] voucher is by default serialized to JSON
   with a signature in CMS [RFC5652].  This document defines a new
   voucher serialization to CBOR [RFC8949] with a signature in COSE
   [I-D.ietf-cose-rfc8152bis-struct].

   This COSE-signed CBOR-encoded voucher is transported using secured
   CoAP and HTTPS.

   The CoAP connection (between Pledge and Registrar) is to be protected
   by either OSCORE+EDHOC or DTLS (CoAPS).  The HTTP connection (between
   Registrar and MASA) is to be protected using TLS (HTTPS).

   This document specifies a constrained voucher-request artifact based
   on Section 3 of [RFC8995], and voucher(-request) transport over CoAP
   based on Section 3 of [RFC8995] and on [I-D.ietf-ace-coap-est].

   The CBOR definitions for the constrained voucher format are defined
   using the mechanism described in [I-D.ietf-core-yang-cbor] using the
   SID mechanism explained in [I-D.ietf-core-sid].  As the tooling to
   convert YANG documents into a list of SID keys is still in its
   infancy, the table of SID values presented here MUST be considered
   normative rather than the output of the pyang tool.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide