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://github.com/anima-wg/anima-brski-prm > > > # 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? > > > 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). > > > # 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. > > > ---------------------------------------------------------------- > > > 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. > > > # 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. > > > # 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 > > > # 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. > > > # 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. > > > 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. > > > # "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. > > > # 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 > > > > # 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. _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
