Early Review of draft-ietf-anima-brski-prm-10
review-ietf-anima-brski-prm-10-secdir-early-kaufman-2023-11-08-00
| Request | Review of | draft-ietf-anima-brski-prm-09 |
|---|---|---|
| Requested revision | 09 (document currently at 12) | |
| Type | Early Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2023-08-12 | |
| Requested | 2023-08-01 | |
| Requested by | Toerless Eckert | |
| Authors | Steffen Fries , Thomas Werner , Eliot Lear , Michael Richardson | |
| I-D last updated | 2023-11-08 | |
| Completed reviews |
Secdir Early review of -10
by Charlie Kaufman
(diff)
Secdir Early review of -05 by Charlie Kaufman (diff) Yangdoctors Early review of -05 by Martin Björklund (diff) Iotdir Early review of -05 by Marco Tiloca (diff) |
|
| Comments |
Please assign to Charlie Kaufman, who did the early review of -05: The authors confirm that all issues raised in that -05 review where closed, and as chairs we would like to see the early review upgraded to a green ready state in acknowledgment and to help fasten further AD/IETF/IESG review. |
|
| Assignment | Reviewer | Charlie Kaufman |
| State | Completed | |
| Request | Early review on draft-ietf-anima-brski-prm by Security Area Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/secdir/XbQ8pxxJB0mH5yj-H_DJmgRh9_M | |
| Reviewed revision | 10 (document currently at 12) | |
| Result | Has nits | |
| Completed | 2023-11-08 |
review-ietf-anima-brski-prm-10-secdir-early-kaufman-2023-11-08-00
Reviewer: Charlie Kaufman Review result: Ready with Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This Standards Track ID extends a family of protocols for limited function devices to obtain certificates from their surrounding environment with the assistance of an on-line manufacturer's authority that can authenticate information as coming from their device. It extends the BRSKI (RFC8995) protocol to deal with devices that prefer to accept incoming initialization requests rather than initiating outbound requests. It does this be defining a new node called a "registrar-agent" that acts as a client to both the to-be-registered "pledge" and the domain registrar. The protocol is more elaborate that I would have thought necessary and offered a confusing array of options to deal with a variety of environments, but I could find no problems with it. I found one sentence that I think has some typos, but I can't be sure. In section 3.2, it says: "The mechanism described in this document presumes the availability of the pledge and the registrar-agent to communicate with another." I suspect what was meant was: "The mechanism described in this document presumes the ability of the pledge and the registrar-agent to communicate with one another."