Re: [Iot-directorate] Iotdir early review of draft-ietf-anima-brski-prm-05

[Marco Tiloca <[e-mail]>]

Hello Steffen,

Your updates look good to me. Thanks for addressing my comments!

Best,
/Marco

On 2023-01-02 14:19, Fries, Steffen wrote:
> Hi Marco,
>
> Thank you for the early review, I made my comments to yours inline.
>
>> -----Original Message-----
>> From: Marco Tiloca via Datatracker<[e-mail]>
>> Sent: Donnerstag, 22. Dezember 2022 14:33
>> To:[e-mail]
>> Cc:[e-mail];[e-mail]
>> Subject: Iotdir early review of draft-ietf-anima-brski-prm-05
>>
>> Reviewer: Marco Tiloca
>> Review result: Ready with Nits
>>
>> [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?
> Yes you are right. We should consequently to the preceding paragraph also use MAY here. Will adapt this.
>
>> [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."
> Yes, taken.
>
>
>> [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?
> Yes, enhanced the sentence for clarity to:
> " A POI is also required for the certification request and therefore the certification request needs to be additionally bound to the existing credential of the pledge (IDevID)."
>
>> * "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?
> Yes, updated as suggested
>
>> * "... based on COSE [RFC9052]"
>>
>>     I think it is appropriate to cite also RFC 9053.
> Yes, certainly. Included in the text and as additional reference.
>
>
>> [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?
> Yes, it was intended to enhance the endpoints.
> Corrected accordingly to " enhances existing endpoints with new supported media types, e.g., for JWS voucher "
>
>
>> [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?
> Okay, after rereading the sentence, it may be misleading. The intention was to allow the registrar to realize with which registrar-agent the pledge was in contact.
> I will reformulate that sentence to make that clearer and also make the may normative. Updated bullet:
> " The registrar-agent MAY provide additional data to the pledge in the context of the voucher triggering request, that the pledge includes into the PVR. This allows the registrar to identify, with which registrar-agent the pledge was in contact."
>
>>     Isn't visibility a general issue between Registrar Agent and Domain
>>     Registrar, for which the specific Pledge does not play a role?
> Yes, as stated above, the intention was to allow the registrar to know, with which registrar agent the pledge was in contact.
>   
>> * "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".
> Good point. I moved that sentence to the first bullet in the 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".
> Agreed, changed to "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?
> Good catch! We had 404 as the registrar was expected to verify the received pledge information against authorization information available on the registrar.
> As the verification of the PVR involves more than just the serial number check I will add 403 similar as for the case in section 6.3.3
> The resulting text would be:
> "If the registrar is unable to validate the PVR it SHOULD respond with a HTTP 4xx/5xx error code to the registrar-agent.
>
> The following 4xx client error codes SHOULD be used:
> * 403 Forbidden: if the registrar detected that one or more security related parameters are not valid.
> * 404 Not Found status code if the pledge provided information could not be used with automated allowance, as described in section 5.3 of RFC8995.
> * 406 Not Acceptable: if the Content-Type indicated by the Accept header is unknown or unsupported.. "
>
>>     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.
> We referred here to RFC 8995 as we kept the handling.
>
>>     Further later on in Section 6.3.3, a failed validation of the wrapping
>>     signature is followed by a 403.
> Should be in line now with the change described above. Will change the text also to a list to make the reading alike.
> "The following 4xx client error codes SHOULD be used by the pledge:
> * 403 Forbidden: if the validation of the wrapping signature or another security check fails.
> * 415 Unsupported Media Type: if the Content-Type of the request is in an unknown or unsupported format.
> * 400 Bad Request: if the pledge detects errors in the encoding of the payload."
>
>   
>> [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."
> Yes, corrected as suggested.
>
>
>> [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."
> Yes, corrected as suggested.
>
>
>> [Section 10.1]
>>
>> * "... (the pledge may produce a voucher, and refuse to produce another
>> one)."
>>
>>     What is produced is actually a "voucher request", right?
> Yes, corrected to "voucher-request"
>
>
>> [Nits]
> All addressed, thank you.
>
>> * 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
>>

-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se