Hi Steffen, Thanks for the follow-up.
For my own convenience, I'm using https://tinyurl.com/brskp-prm-diff to track the changes you made so far. Please see inline. Cheers, Med > -----Message d'origine----- > De : Fries, Steffen <steffen.fr...@siemens.com> > Envoyé : mardi 8 avril 2025 18:57 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; > The IESG <i...@ietf.org> > Cc : draft-ietf-anima-brski-...@ietf.org; anima-cha...@ietf.org; > anima@ietf.org; i...@kovatsch.net; t...@cs.fau.de > Objet : RE: Mohamed Boucadair's Discuss on draft-ietf-anima-brski- > prm-18: (with DISCUSS and COMMENT) > > Hi Mohamed > > Thank you for the swift replay. > I made further changes inline and dropped the already addressed > and acknowledged parts for better readability. > > Best regards > Steffen > > > > > ------------------------------------------------------------ > > > > DISCUSS: > > > > ------------------------------------------------------------ > > > > # DISCUSS > > > > > > > > # Unconditional MUST > > > > > > > > CURRENT: > > > > The pledge MUST respond to all requests regardless of the > > > > Host header field provided by the client (i.e., ignore > it). > > > > > > > > I don't think that is safe. > > > > > > > > I'm afraid this needs some scoping; as there are other > legitimate > > > > conditions where the pledge doe snot have to reply. > > > [stf] Based on the existing discussion on this, we opened an > issue > > > on github to align on the solution The current proposal takes > your > > > suggestion into account: > > > OLD > > > The pledge MUST respond to all requests regardless of the Host > > > header field provided by the client (i.e., ignore it). > > > > > > NEW > > > In the absence of a security policy the pledge MUST respond to > all > > > requests regardless of the Host header field provided by the > client > > > (i.e., ignore it). A security policy may include a rate > limiting for > > > a requests to avoid susceptibility of the pledge to overload. > > > > > > Once aligned, we will include it in the draft > > > > [Med] ACK. > [stf] included in the latest version available on github: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > github.com%2Fanima-wg%2Fanima-brski- > prm&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd4e9e79794b548 > 0498b608dd76be77ac%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63 > 8797282642341814%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI > lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 > D%7C0%7C%7C%7C&sdata=r7WV295TJXFaNu5Mp4KCoBsTfHllgncYbWEXjjTwCOE%3 > D&reserved=0 > [Med] The change looks great. Consider this one closed. > > > > > # Compliance with HTTP BCP (RFC9205) > > > > > > > > CURRENT: > > > > If the pledge is unable to create the PVR, it SHOULD > respond with an > > > > HTTP error status code to the Registrar-Agent. The > following client > > > > error status codes SHOULD be used: > > > > > > > > The use of normative language is IMO not compliant with the > > > > guidance in RFC9205, about error handling. > > > [stf] I created a new issue for this: > > > From RFC 9205 I understood that we could use the HTTP status > codes > > > in this way. What would you suggest here? > > > > > > > [Med] A simple fix here is to remove the normative language. > Listing > > the appropriate codes is definitely right, but need to redefine > the > > error codes, just be affirmative. For example, an entity will > return 404 when there is no resources, etc. > [stf] Hm, after the discussion in the design team, we are not > quite sure about your concern. Is it the one.-to-one mapping > referenced in section 4.6 of RFC 9205 or the understanding we re- > define status codes? > [Med] I'm afraid that you are redefining those. We don't need new normative HTTP behavior here. I suggest we simply make this change (and similar) OLD: If the pledge is unable to create the PER, it SHOULD respond with an HTTP error status code to the Registrar-Agent. The following client error status codes MAY be used: * 400 Bad Request: if the pledge detects an error in the format of the request. ... NEW: If the pledge is unable to create the PER, it responds with an HTTP error status code to the Registrar-Agent. The following client error status codes can be used: * 400 Bad Request: if the pledge detects an error in the format of the request. .. > > > > There are several similar constructs in the document. > > > > > > > > # Cluster with 8366bis > > > > > > > > CURRENT: > > > > > > > > The JSON PVR Data MUST contain the following fields of > the "ietf- > > > > voucher-request" YANG module as defined in > > > > [I-D.ietf-anima-rfc8366bis]; > > > > > > > > I think this spec should be clustered with 8366bis. There > are > > > > several structure that used in this document and which > depends on what is defined in 8366bis. > > > > Changes to the bis will have implications on this one. > > > > > > > > With that in mind, I tend to suggest holding approval of > this > > > > specification till we finalize the bis spec. > > > [stf] As indicated by Michael, we already have a cluster for > RFC > > > 8366bis and further drafts related to BRSKI variants to take > care of > > > mutual influences. I opened an issue > > > > [Med] ACK. > [stf] Also discussed in design team meeting today. It is less > about changes in the draft but more to the processing. The > intention is that all other BRSKI variant documents currently > handled will go into MISSREF, as draft-ietf-jws-voucher waiting > for 8366bis. 8366bis collects considerations from the different > documents and is likely not to lead to addition of new information > in the respective drafts (at least that is the intention). > [Med] I would be more comfortable if I had more stability signs of 8366 ;-) That's said, I think that I have the discussion I wanted to have. I leave it to Mahesh to decide. > > > > > # Requires TLS1.3 > > > > > > > > CURRENT: > > > > As already stated in [RFC8995], the use of TLS 1.3 (or > newer) is > > > > encouraged. TLS 1.2 or newer is REQUIRED on the > Registrar-Agent > > > > side. TLS 1.3 (or newer) SHOULD be available on the > registrar, but > > > > TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be > available on the > > > > MASA, but TLS 1.2 MAY be used. > > > > > > > > Please update to take into to reflect draft-ietf-uta- > require-tls13. > > > [stf] I saw that there was already discussion on this issue. I > > > created a corresponding issue as We will discuss the use of > TLS 1.2 > > > and if there is a desire to also allow or existing pledges, > that may > > > have no option to only allow TLS 1.3, we would add a note as > > > suggested and explain the necessity. > > > > > > > [Med] ACK. I'm neutral on the outcome here, but I'd like we back > the > > design and include some reasoning if we don't follow the UTA > reco. Thanks. > [stf] BRSKI-PRM is an extension of existing BRSKI, which requires > TLS 1.2. We aligned with that and also included it in BRSKI-PRM. > TLS1.3 is currently widely used in browsers, but industry adoption > is not as fast. There are constraint devices using SDKs, which are > not updated fast. > We enhanced the part with following to state the consideration of > the uta draft.: > OLD > As already stated in {{!RFC8995}}, the use of TLS 1.3 (or newer) > is encouraged. > NEW > As already stated in {{!RFC8995}}, and required by {{I-D.ietf-uta- > require-tls13}}, the use of TLS 1.3 (or newer) is encouraged. > [Med] I suggest we pause on this one and reflect the outcome of the ongoing discussion. I would at least see in the text a brief mention of the SDK limitations you mentioned. BTW, what is currently supported by implementations such as open-brski? > > > > > ------------------------------------------------------------ > ---- > > > > COMMENT: > > > > ------------------------------------------------------------ > ---- > > > > > > > > # Consider having a reference figure early in the document > with > > > > the various entities. > > > [stf] We currently have the architecture overview figure in > section > > > 5 discussing the solution architecture. To avoid repeating > that > > > figure, would it be fine to essentially reference the figure > from > > > the introduction to guide the reader to the overview? > > > > > > > [Med] Moving that figure early in the document would be better, > IMO. > [stf] after discussion in the ANIMA design team, we felt that > including a reference to figure 1 and section 5 would be better as > figure 1 is part of the solution architecture section, which > covers different deployment options. Ripping it apart may lead to > confusion when reading the solution architecture section. > [Med] ACK > > > > > > # Resource vs. Endpoint > > > > > > > > CURRENT: > > > > endpoint: Term equivalent to resource in HTTP [RFC9110] > and CoAP > > > > [RFC7252]. Endpoints are accessible via Well-Known > URIs > > > > [RFC8615]. > > > > > > > > For the CoAP mention, this may be confusing as CoAP has also > the > > > concept of > > > > "Endpoint", which is not identical to resource. > > > [stf] Do you have a suggestion on how to address potential > confusion > > > here? We tried this already by providing references to both > RFCs, > > > but if there is a clearer way of describing it we could > include it. > > > > [Med] I would simply remove the mention of CoAP here. No need to > dive > > into subtleties of endpoint vs. resources for a protocol that is > not > > used as foundation for this work. > [stf] okay, removed as suggested to avoid confusion. > [Med] ACK > > > > # Mysterious > > > > > > > > CURRENT: Requirements Discussion and Mapping to Solution- > Elements > > > > > > > > What does Solution-Elements mean? > > > [stf] In the discussion we handled solution elements as "parts > of > > > the solution" like the introduction of the registrar-agent as > new > > > component or the reliance on self-contained objects, > enhancements of > > > assertion types in the voucher etc. If you have a proposal for > a > > > better name, we could change it. > > > > > > > [Med] Thanks for clarifying. I think I would > > s/Solution-Element/BRSKI-PRM Functional Entities or similar. > [stf] okay, good suggestion, finally changed from OLD Requirements > Discussion and Mapping to Solution-Elements NEW Requirements > Discussion and Mapping to BRSKI-PRM Functional Elements > > [Med] ACK > > > > # Outsource Key Infrastructure > > > > > > > > This is currently drawn within the customer domain. Can this > be > > > > outsourced/external to the customer domain? > > > [stf] The intention was to show the supporting infrastructure > on the > > > customer side without including the operational model. So the > PKI > > > may be customer operated or provided to the customer as > service. > > > > > > > [Med] Please consider clarifying this in the ops section. > Thanks. > [stf] Included the following statement in the ops section: > NEW > The key infrastructure as part of the customer domain discussed in > Section 5 may be operated locally by the operator of that domain > or may be provided as a third party service. > [Med] Looks good. Thanks. > > > > > # Group OPS considerations in one single section > > > > > > > > Consider moving the following to the OPS cons section: > > > > > > > > CURRENT: > > > > The benefits of BRSKI-PRM can be achieved even without > the > > > > operational complexity of stand-alone Registrar-Agents by > integrating > > > > the necessary functionality of the Registrar-Agent as a > module into > > > > the domain registrar as shown in Figure 3 so that it can > support the > > > > BRSKI-PRM communications to the pledge. > > > > > > [stf] Good idea! Included the following in the Ops Con > section: > > > NEW > > > As outlined in {{colo-regagt}} the functional support of > BRSKI-PRM > > > can also be achieved using a Registrar-Agent co-located with > the > > > Registrar instead of a stand-alone Registrar-Agent, which may > reduce > > > operational complexity. > > > > > > > > And > > > > > > > > CURRENT > > > > Overall, this may have > > > > operational implications when the registrar is part of a > scalable > > > > framework as described in Section 1.3.1 of > > > > [I-D.richardson-anima-registrar-considerations]. > > > [stf] The reference to [I-D.richardson-anima-registrar- > > > considerations] is already contained in the Ops Con. > > > So I would propose to move the sentence as suggested to the > Ops Con > > > section as following to keep the context: > > > NEW > > > Requirements to the utilized credentials authenticating and > artifact > > > signatures on the registrar as outlined in Section 6.3 may > have > > > operational implications when the registrar is part of a > scalable > > > framework as described in Section 1.3.1 of [I- > > > D.richardson-anima-registrar-considerations]. > > > > > > > [Med] This is an enhancement as we do have one reference section > to > > look at for these important matters. > > > > > > > # Configurable knobs > > > > > > > > CURRENT: > > > > In the absence of a more general discovery as defined in > > > > [I-D.ietf-anima-brski-discovery] the Registrar-Agent MUST > use > > > > > > > > Do we need to have a control parameter here to instruct the > > > behavior of the RA? > > > [stf] This is covered in the referenced draft. It allows to > discover > > > the functionality of the registrar with much more details > about > > > operational mode, encoding options, etc. > > > Would you suggest to provide a sentence that the discovery may > be a > > > configuration item of the Registrar-Agent. I had assumed this > is > > > already implicitly given through the existing formulation, but > > > explicit may be better. > > > > [Med] Adding that sentence would be may preference here as a > reader. > [stf] Added the following: > NEW > When supporting different options for discovery, as outlined in > {{I-D.ietf-anima-brski-discovery}}, a manufacturer may support > configuration of preferred options. > [Med] Thanks. > > > > The same applies for the following: > > > > > > > > CURRENT: > > > > A nonceless voucher MAY be accepted as in [RFC8995] if > > > allowed by the > > > > pledge implementation of the manufacturer. > > > [stf] As above, the suggestion is to include a sentence that > the > > > manufacturer may opt to have this as configuration item? > > > > > > > [Med] Yeah. Thanks. > [stf] Added the following: > NEW > A manufacturer may opt to provide the acceptance of nonceless > voucher as configurable item. > [Med] ACK > > > > > # "MUST ...unless" constructs should be "SHOULD ...unless" > > > > > > > > OLD: > > > > To enable interaction as responder with the Registrar- > Agent, pledges > > > > in responder mode MUST act as servers and MUST provide > the endpoints > > > > defined in Table 1 within the BRSKI-defined /.well- > known/brski/ URI > > > > path, except for the OPTIONAL endpoint "qps". The > endpoints are > > > > defined with short names to also accommodate for > resource-constrained > > > > devices. > > > > > > > > NEW: > > > > To enable interaction as responder with a Registrar- > Agent, pledges > > > > in responder mode MUST act as servers and SHOULD provide > the endpoints > > > > defined in Table 1 within the BRSKI-defined /.well- > known/brski/ URI > > > > path, except for the OPTIONAL endpoint "qps". The > endpoints are > > > > defined with short names to also accommodate for > resource-constrained > > > > devices. > > > [stf] Hm, for compliance with BRSKI-PRM we require the support > of > > > the two stated endpoints in Table 1 to ensure they can be > trigger. > > > > > > > [Med] The issue here is that MUST is an absolute required, while > this > > case we have an exception (unless..). FWIW, 2119 has the > following: > > > > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean > that the > > definition is an absolute requirement of the specification. > > > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that > there > > may exist valid reasons in particular circumstances to ignore > a > > particular item, but the full implications must be understood > and > > carefully weighed before choosing a different course. > > [Med] I see that you explored another path. I like that as well. There is one nit, though: delete an extra "provide the endpoints" OLD: To enable interaction as responder with a Registrar-Agent, pledges in responder mode MUST act as servers and MUST provide the endpoints provide the endpoints "tpvr", "tper", "svr", "scac", and "ser" defined in Table 1 within the BRSKI-defined /.well-known/brski/ URI path. The optional endpoint "qps" SHOULD be supported. NEW: To enable interaction as responder with a Registrar-Agent, pledges in responder mode MUST act as servers and MUST provide the endpoints "tpvr", "tper", "svr", "scac", and "ser" defined in Table 1 within the BRSKI-defined /.well-known/brski/ URI path. The optional endpoint "qps" SHOULD be supported. > > > > > # TTL > > > > > > > > CURRENT: > > > > Note that the pledge provisionally accepts the registrar > EE > > > > certificate contained in the tPVR until it receives the > voucher (see > > > > Section 5.4). > > > > > > > > Shouldn't that be TTLed as well for better security control? > > > [stf] Good point we need to discuss this to avoid a dead lock > of the > > > pledge. As the situation is different to the TLS connection in > BRSKI > > > we may add some further clarification. Created issue for > discussion > > > > [Med] ACK. > [stf] Proposal to include that the last received tPVR will be > taken if the pledge does not have the possibility to store more > that one provisionally accepted registrar EE certificate [Med] ACK > > > > > > > # Missing IANA action > > > > > > > > CURRENT: IANA has registered the following service names > > > > > > > > Please ad an action for IANA to update that entry. Thanks. > > > [stf] We've got the following information from IANA: > > > "The actions requested in this document will not be completed > until > > > the document has been approved for publication as an RFC. > > > This message is meant only to confirm the list of actions that > will > > > be performed." > > > Are there additional actions necessary? > > > > > > > [Med] No, just save a question from IANA in the future when they > well > > implement the actions. Add a sentence to say basically what I > had in my comment. Thanks. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
