Hi Rifaat, Apologies for the delay to follow-up as I was out of office.
I checked diff 18/16 right now. Thanks for addressing main comments. Cheers, Med De : Rifaat Shekh-Yusef <[email protected]> Envoyé : vendredi 22 août 2025 15:46 À : BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Objet : Re: Mohamed Boucadair's No Objection on draft-ietf-anima-brski-cloud-16: (with COMMENT) Hi Med, Thanks for your detailed review and comments. We believe that we have addressed your comments and suggestions in the new version of the draft: https://datatracker.ietf.org/doc/draft-ietf-anima-brski-cloud/ Please, take a look and let us know if you have any further comments. Regards, Rifaat On Wed, Jul 30, 2025 at 9:40 AM Mohamed Boucadair via Datatracker <[email protected]<mailto:[email protected]>> wrote: Mohamed Boucadair has entered the following ballot position for draft-ietf-anima-brski-cloud-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-brski-cloud/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi Owen, Rifaat, and Michael, Thank you for the effort put into this specification. Also, thanks to Tim Wicinski for the DNSDIR review and to the authors for engaging and proposing changes. # Overall The document is well-written with a clear applicability scope. The description is repetitive in some places (e.g., all the details about “SIP phones” is repeated several times, redundant text in 1.2.1, etc.); some less words would be appropriate to help readers better focus on the core specification. Please find below more detailed comments. Major comments are marked with (*). # Operationalizing the solution (*) The approach requires some coordination and provisioning that involve several entities. The document includes some useful discussion but those are really scattered in the document. I suggest to group these matters under a new “Operational Considerations” section. That section can include, e.g., required out of band configuration, discovery consideration, scalability discussion, service stability requirements and migration considerations, current Sections 5 and 7 as subsections. # Inappropriate use of normative language (*) Several uses of the normative language in the document are not justified. Also, many of those are redundant with other statements in the document. For example: (1) Introduction This work is in support of [BRSKI], Section 2.7, which describes how a Pledge MAY contact a well-known URI of a Cloud Registrar if a local ^^ Registrar cannot be discovered or if the Pledge's target use cases do not include a local Registrar. … This document updates [BRSKI] by clarifying operations that are left out of scope in [BRSKI]. Two modes of operation are specified in this document. The Cloud Registrar MAY redirect the Pledge to the^ ^^^^ owner's Registrar, or the Cloud Registrar MAY issue a voucher to the ^^^ Pledge that includes the domain of the owner's Enrollment over Secure Transport [RFC7030] (EST) server. (2) Section 2 It is also possible that the Cloud Registrar MAY redirect the Pledge ^^^^ to another Cloud Registrar operated by a VAR, with that VAR's Cloud Registrar then redirecting the Pledge to the Owner Registrar. This scenario is discussed further in Sections Section 7.2 and 8.3. (3) Section 3.1.1 BRSKI defines how a Pledge MAY contact a well-known URI of a Cloud I suggest s/MAY/may at least in these excerpts and similar ones. # Internal inconsistency (*) CURRENT: … and MUST NOT send the CSR Attributes request to the Cloud Registrar, because the Cloud Registrar does not have authority to issue a certificate for the customer domain. (The Cloud Registrar is not a full EST server) If a Pledge sends a CSR Attributes request to the Cloud Registrar, then the Cloud Registrar MUST reply with 404 response code. There is a conflict between the first MUST NOT and “if … sends”. # Compliancy with BCP 56 (*) There are several statements in the document that are not consistent with this reco: Applications using HTTP MUST NOT re-specify the semantics of HTTP status codes, even if it is only by copying their definition. It is NOT RECOMMENDED they require specific reason phrases to be used; the reason phrase has no function in HTTP, is not guaranteed to be preserved by implementations, and is not carried at all in the HTTP/2 [HTTP/2] message format. Examples of such statements are Registrar, then the Cloud Registrar MUST reply with 404 response code. Or The Cloud Registrar MUST determine Pledge ownership. Prior to ownership determination, the Registrar checks the request for correctness and if it is unwilling or unable to handle the request, it MUST return a suitable 4xx or 5xx error response to the Pledge as Or If the request is correct and the Registrar is able to handle it, but unable to determine ownership at that time, then it MUST return a 401 and similar statements in the document. Please check and revise accordingly. Typically, s/MUST return/returns # Deviation vs. RFC8366bis (*) The document says: (Section 2.3) [RFC8366bis] contains the two needed voucher extensions: "est-domain" and "additional-configuration" which are needed when a client is redirected to a local EST server. (Section 3.2.3) The voucher MAY include the new "additional-configuration" field. .. The exact Pledge and Registrar behavior for handling and specifying the "additional-configuration" field is outside the scope of this document. ## However, there is no “additional-configuration” in draft-ietf-anima-rfc8366bis. Do we meant “additional-configuration-url”? If so, please update accordingly ## BTW, s/extensions/parameters as “extensions” have a special meaning in YANG. # Need for a concrete recommendation (*) CURRENT: In order to avoid permanent bootstrap cycles, the Pledge MUST NOT revisit a prior location. How this is actually implemented? How the behavior is controlled? Should previous attempts be cached, time-outed? If so, what is the depth of cached failures? # Incomplete behavior (*) Section 3.1.1 has the following CURRENT: The Pledge SHOULD be provided with the entire URI of the Cloud Registrar, including the protocol and path components, which are typically "https://"; and "/.well-known/brski", respectively. But, what is supposed to do if incomplete URI is provided? # Please find below some additional minor comments ## Expand BRSKI in the title. ## Abstract ### Help the device CURRENT: Bootstrapping Remote Secure Key Infrastructures (BRSKI) defines how to onboard a device securely into an operator-maintained infrastructure. It assumes that there is local network infrastructure for the device to discover and help the device. I don’t parse what is meant by “help the device”. ## New device CURRENT: This document defines how to contact a well-known Cloud Registrar, and two ways in which the new device may be redirected towards the operator-maintained infrastructure. The concept of “new” is not clear at this stage. Do we consider a device new when it contacts the registrar for the first time or do we also consider cases where a device first connect to a given network? ## Introduction ### Nits OLD: Bootstrapping Remote Secure Key Infrastructures [BRSKI] BRSKI ^^^^^^ specifies automated and secure provisioning of nodes (which are ^^^^^^^^^^ called Pledges) with cryptographic keying material (trust anchors and NEW: Bootstrapping Remote Secure Key Infrastructures [BRSKI] (BRSKI) specifies automated and secure provisioning of nodes (called Pledges) with cryptographic keying material (trust anchors and ### Phone, a bit outdates and does not reflect actual uses I suggest to use User Agent (UA), rather than “phone” in this part (and similar ones) OLD: This kind of non-network onboarding is sometimes called "Application Onboarding", as the purpose is typically to deploy a credential that will be used by the device in its intended use. For instance, a SIP [RFC3261] phone might have a client certificate to be used with a SIP proxy. NEW: This kind of non-network onboarding is sometimes called "Application Onboarding", as the purpose is typically to deploy a credential that will be used by the device in its intended use. For instance, a SIP [RFC3261] user agent (UA) might have a client certificate to be used with a SIP proxy. ## Terminology The document says: This document uses the terms Pledge, Registrar, MASA, and Voucher from [BRSKI] and [RFC8366bis]. But provides a copy/past of some other entries (e.g., Manufacturer). Any reason that entry is copy/pasted here rather than listing it similar to other BRSKI terms? ## Applicability This text is lost in the “target Use Cases”. I suggest to move this to a dedicated subsection or to the introduction. CURRENT: A network with an operator that is able to provision these options would also be able to use BRSKI without changes. Such a network has no need for the mechanisms described in this document! ## Typical, really? CURRENT: A typical example is a VoIP phone manufacturer provides telephones to a local system integration company (a VAR). This may be “typical” in the past, but I don’t think this is “typical” nowadays. ## Missing LDevID reference CURRENT: When the employee plugs in the device and turns it on, the device will be provisioned with a LDevID and configuration that connections the phone with the Enterprises' VoIP PBX. Consider adding a pointer to 802.1AR? ## “cloud” in Section 1.2.2 OLD: The voucher issued by the cloud includes domain information for the owner's EST service that the Pledge should use for certificate enrollment. NEW: The voucher issued by the Cloud Registrar includes domain information for the owner's EST service that the Pledge should use for certificate enrollment. ## Architecture ### Cloud Registrars The text seems to assume that there is one single Cloud Registrar instance, while this shouldn’t. I suggest to make this change (and also through the doc): OLD: In both use cases, the Pledge connects to the Cloud Registrar during bootstrap. NEW: In both use cases, the Pledge connects to a Cloud Registrar during bootstrap. ### Additional information CURRENT: When returning a voucher, additional bootstrapping information is embedded in the voucher. Can we cite examples of additional information? Absent such example, not sure that sentence adds value. ### IP address and reachability CURRENT: prior to connecting to the Cloud Registrar. The Pledge must have an IP address so that it is able to make DNS queries, and be able to send requests to the Cloud Registrar. The first “must” does not guarantee that DNS queries can be successfully placed. For example, a device can only have a link local address, but that does not help communicating more than one hop further. ### Internal setup CURRENT: For many telephony applications, this is typically going to be a wired connection. For wireless use cases, existing Wi-Fi onboarding mechanisms such as [WPS] can be used. Do we really need to have this? ## Section 3.3.1 s/will a follow/will follow ## Section 4.2 * s/In step 3, the the Cloud Registrar/In step 3, the Cloud Registrar * s/ authenticate/authenticate ## Section 7.1: nit OLD: When the Pledge attempts to connect to any Cloud Registrar, an incorrect connection will be detected because the Pledge will be unable to verify the TLS connection to its Cloud Registrar via DNS-ID check Section 6.3 of [RFC9525]. NEW: When the Pledge attempts to connect to any Cloud Registrar, an incorrect connection will be detected because the Pledge will be unable to verify the TLS connection to its Cloud Registrar via DNS-ID check (Section 6.3 of [RFC9525]). Cheers, Med ____________________________________________________________________________________________________________ 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 -- [email protected] To unsubscribe send an email to [email protected]
