Skip to main content

Early Review of draft-ietf-anima-brski-prm-05
review-ietf-anima-brski-prm-05-iotdir-early-tiloca-2022-12-22-00

Request Review of draft-ietf-anima-brski-prm-05
Requested revision 05 (document currently at 12)
Type Early Review
Team Internet of Things Directorate (iotdir)
Deadline 2022-12-24
Requested 2022-11-15
Requested by Toerless Eckert
Authors Steffen Fries , Thomas Werner , Eliot Lear , Michael Richardson
I-D last updated 2022-12-22
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
This document is getting close to WGLC, and we would appreciate early review of the three above listed directorates (security, IoT and YANG doctors) as the in our opinion most important ones.

The YANG doctor review is particularily important, because we would want to use this document as the spearhead for resolving our issue of augmenting rfc8366 YANG, and so far, the discussions we have on netmod/anima with YANG experts have not lead to a working suggestion. This problem applies to multiple ANIMA drafts intending to augment rfc8366 YANG, and if the solution is that we first need to fix up the rfc8366 YANG, e.g.: via rfc8366bis or a differently fixed version of its YANG module, then this would become a new dependency for all those doc. The authors of this draft suggested that Jan Lindblad has been helpful on these type of issues in the past already, and he might be more familiar with them than other YANG doctors.

Thank you so much
    Toerless on behalf of ANIMA (chairs).
Assignment Reviewer Marco Tiloca
State Completed
Request Early review on draft-ietf-anima-brski-prm by Internet of Things Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/iot-directorate/jk_dIUnQb60f-TIeSceywHXNvjs
Reviewed revision 05 (document currently at 12)
Result Ready w/nits
Completed 2022-12-22
review-ietf-anima-brski-prm-05-iotdir-early-tiloca-2022-12-22-00
Hi,

I have reviewed draft-ietf-anima-brski-prm as part of the IoT directorate
document reviews. Please see my comments below. I hope it helps!

Best,
/Marco

[Section 3.1]

* "Once a pledge with such combined functionality has been bootstrapped, it may
act as client for enrollment or re-enrollment of further certificates needed,
e.g., using the enrollment protocol of choice."

   Considering the normative words used in the previous paragraph for a pledge
   with combined functionalities, I would have expected the use of "MAY" here
   about a pledge-initiated enrollment. Is the use of the non-normative "may"
   intentional?

[Section 3.2]

* "The mechanism described in this document presume the availability of the
pledge to communicate with the registrar-agent."

   The last sentence in the paragraph says that "the registrar-agent is
   similarly presumed to be unavailable for certain periods of time".
   Consistently, the first sentence quoted above can already suggest that
   point, instead of focusing on the pledge only. E.g., it can say:

   "The mechanism described in this document presumes the availability of the
   pledge and the registrar-agent to communicate with one another."

[Section 4]

* "A POI is also required for the certification request and therefore needs to
be additionally bound to the existing credential of the pledge (IDevID)."

   The subject of "needs" is the certification request, right?

* "This binding supports the authorization decision for the certification
request may be provided directly with the certification request."

   I am not sure how to parse this sentence. It think you mean "... for the
   certification request and may be provided ...". Correct?

* "... based on COSE [RFC9052]"

   I think it is appropriate to cite also RFC 9053.

[Section 5.1]

* "enhances existing with new supported media types, e.g., for JWS voucher"

   What is existing and enhanced? Data exchanges and messages, or instead
   endpoints again?

[Section 5.1]

* "The registrar-agent may provide additional data to the pledge in the context
of the voucher triggering request, to make itself visible to the domain
registrar."

   Could you elaborate on this, perhaps through an example? How does this help
   the registrar-agent to make itself visible to the domain registrar?

   Isn't visibility a general issue between Registrar Agent and Domain
   Registrar, for which the specific Pledge does not play a role?

* "The registrar-agent may be implemented as an integrated functionality of a
commissioning tool or be co-located with the registrar itself."

   This feels like something quite important to say already in Section 1
   "Introduction".

[Section 6.2]

* "Registrar-agent: possesses ... In addition, it may possess the IDevID CA
certificate of the pledge vendor/manufacturer to verify the pledge certificate
in the received request messages."

   Consistently with what is said later on about the MASA, I think that the
   sentence above should also better use the normative "MAY".

[Section 6.2.2]

* "If the validation fails the registrar SHOULD respond with HTTP 404 Not Found
status code to the registrar-agent."

   Why 404? The registrar has been processing the request from the
   registrar-agent, so the targeted resource indeed exists at the registrar.

   Wouldn't 403 be more appropriate?

   Later on, the last paragraph of Section 6.2.3 more generally considers a 4xx
   status code in case of (agent-signed-data) validation failure.

   Further later on in Section 6.3.3, a failed validation of the wrapping
   signature is followed by a 403.

[Section 6.3.5]

* "Once the registrar-agent has collected the information, it can connect to
the registrar-agent to provide the status responses to the registrar."

   I guess you mean: "Once it has collected the information, the
   registrar-agent can connect to the registrar to provide it with the status
   responses."

[Section 6.4.2]

* "The pledge-status responses are cumulative in the sense that connect-success
implies enroll-success implies voucher-success."

   I guess you mean: "The pledge-status responses are cumulative in the sense
   that connect-success implies enroll-success, which in turn implies
   voucher-success."

[Section 10.1]

* "... (the pledge may produce a voucher, and refuse to produce another one)."

   What is produced is actually a "voucher request", right?

[Nits]

* Abstract
- s/situations, in which/situations in which

* Section 1:
- s/In this scenarios it/In this scenario, it
- s/i this document/in this document
- s/on application layer/addressed on the application layer
- s/IDevID do not/IDevIDs do not

* Section 2:
- s/be a temporary/be temporary
- s/PER send to the CA/PER sent to the CA

* Section 3.1:
- s/pledges, which can/pledges which can
- s/as describe in/as described in

* Section 3.2:
- s/document presume the/document presumes the

* Section 4:
- s/are than provided/are then provided
- s/certificate a that/a certificate that
- s/a signature using/a signature computed using

* Section 5:
- s/constraint environments it may provided/constrained environments it may be
provided

* Section 5.1:
- s/endpoints were additional/endpoints where additional
- s/or cases where/or in cases where

* Section 6.1:
- s/beacons The registrar-agent/beacons. The registrar-agent

* Section 6.1.2:
- s/or it's not/or if the request is not
- s/synchronized the time/synchronized time

* Section 6.2:
- s/possesses it's own/possesses its own
- s/it's own registrar EE/its own registrar EE
- s/possesses it's own vendor/possesses its own vendor

* Section 6.2.3:
- s/of pledge The/of pledge. The

* Section 6.2.5:
- s/point 8. The/point 8). The
- s/contain registrar EE/contain the registrar EE

* Section 6.3:
- The first paragraph has an in-line bullet list that was probably intended to
stand out on its own following a line break after "the pledge:".

* Section 6.3.1:
- s/example if given/example is given

* Section 7.1.1:
- s/the registrar-proximity-certificate, and/registrar-proximity-certificate,
and

* Section 7.1.2:
- s/form the pledge/from the pledge

* Section 9
- s/a "oppressive/an "oppressive
- s/could be easily be/could easily be
- s/insert on-path/insert an on-path

* Section 10.3
- s/an registrar-agent/a registrar-agent

* Section 10.4
- s/this if his/this if its