Subject: [Anima] I-D Action: draft-ietf-anima-constrained-voucher-15.txt

From: [email-masked]
Date: Tue, 07 Dec 2021 16:09:11 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF.

        Title           : Constrained Bootstrapping Remote Secure Key Infrastructure (BRSKI)
        Authors         : Michael Richardson
                          Peter van der Stok
                          Panos Kampanakis
                          Esko Dijk
	Filename        : draft-ietf-anima-constrained-voucher-15.txt
	Pages           : 74
	Date            : 2021-12-07

Abstract:
   This document defines the Constrained Bootstrapping Remote Secure Key
   Infrastructure (Constrained BRSKI) protocol, which provides a
   solution for secure zero-touch bootstrapping of resource-constrained
   (IoT) devices into the network of a domain owner.  This protocol is
   designed for constrained networks, which may have limited data
   throughput or may experience frequent packet loss.  Constrained BRSKI
   is a variant of the BRSKI protocol, which uses an artifact signed by
   the device manufacturer called the "voucher" which enables a new
   device and the owner's network to mutually authenticate.  While the
   BRSKI voucher is typically encoded in JSON, Constrained BRSKI defines
   a compact CBOR-encoded voucher.  The BRSKI voucher is extended with
   new data types that allow for smaller voucher sizes.  The Enrollment
   over Secure Transport (EST) protocol, used in BRSKI, is replaced with
   EST-over-CoAPS; and HTTPS used in BRSKI is replaced with CoAPS.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-anima-constrained-voucher-15.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-constrained-voucher-15

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Michael Richardson <[email-masked]>
Date: Thu, 09 Dec 2021 13:47:20 -0500

> https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-constrained-voucher-15

This version is the result of a lot of work and pull requests.
Here is my attempt to capture a high-level view.... the diff is worth
reading.  A list of pull requests that went into this document is at:
  https://github.com/anima-wg/constrained-voucher/pulls?q=is%3Apr+created%3A%3E2021-08-01

We mostly think we are done.  We'd appreciate some additional review of the document.
We think that WGLC in January might be appropriate.
We expect to do additional online interop testing.

We have cancelled the Thursday "morning" design team meetings until Jan, but
likely we'll continue to edit and merge some pull requests.  Your review
would help.  We have dealt with all review comments that we have received.

1) rewrote abstract
   new abstract proposal https://github.com/anima-wg/constrained-voucher/pull/198

2) We added Appendix D about different kinds of pledges that we think can be
   created. They differ in host many network round trips are required, and
   how much code (mostly PKIX code) is required.

   We also are considering a section: https://github.com/anima-wg/constrained-voucher/pull/202
   that goes more into the no-PKIX operational consideration, but we have not
   yet decided to include it.
   It seems that we could make this a new document if the WG preferred.
   I think as a group, the authors are undecided.

3) We have a section 14.2, which was about IDevID security, and we think that
   actually there isn't anything to say, and we'll remove this section.

4) Many editorial fixes, many updates to make the IANA sections correct.

5) Clarified that constrained vouchers can be sent over HTTPS.
   (Also that non-constrained-vouchers could travel over CoAP, but we
   think that is a stupid thing to do)

6) section added on consequences of no certificate operations #202

7) one reviewer challenged our claims about code size reduction.
   We have agreed and decided to remove that claim from the text where it was
   really about network transmission savings.

8) we have added some text about discovery and applicability in different
   deployment scenarios (section 10)

9) add text explaining when to look for new trust anchor CA via /crts #186

10) clarify that the Registrar certificate can be self-signed #181

11) clarification of RFC4210 Root CA key change, close #163 issue-for-wg

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