Hi David, Thank you for your replies. We have updated as requested. Please note that we have some follow-up notes/questions.
) To have a 1:1 matchup with the acronym and expansion of “BRSKI-AE” and to reflect how it is expanded elsewhere in the document we have further updated your suggested title. Please review. > Update: > NEW: > BRSKI with Alternative Enrollment Protocols (BRSKI-AE) Current: BRSKI with Alternative Enrollment (BRSKI-AE) Protocol ) FYI - We have also added “CMS” to the list in Section 2 as it appears in the expansion of “CMC”. Please let us know of any objections. Current: CMS: Cryptographic Message Syntax ) For consistency, should field names appear within <tt> or without <tt>? > OLD: > the <tt>caPubs</tt> field > NEW: > the '<tt>caPubs</tt>' field > > OLD: > the acp-node-name field > NEW: > the 'acp-node-name' field ) To make the following update in Figure 1, please provide us with updated SVG that includes this change. (We have made this update in the ascii-art, which appears in the txt file). >> b.) We note the following expanded forms of "PKI" are used after the >> abbreviation is introduced. May we update these instances below to the >> abbreviation? >> >> Public-Key Infrastructure >> public-key infrastructure > Figure 1: > OLD: > Public-Key Infrastructure > > NEW: > > Public-Key Infrastructure (PKI) ) After we have received the final approvals from each author, we will ask IANA to update their registry accordingly. > 6. > > We are ok with your change > from "Lightweight CMP Profile (LCMPP, [RFC9483])" > to "Lightweight CMP Profile (LCMPP) [RFC9483]" > because it improves consistency with the style used in sections 1 and 5.1. > Yet please just note that this change incurs a minor textual discrepancy with > the Description entry at > https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=brski-reg-cmp > which uses "Lightweight CMP Profile (LCMPP, [RFC9483])". ... The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9733.xml https://www.rfc-editor.org/authors/rfc9733.txt https://www.rfc-editor.org/authors/rfc9733.html https://www.rfc-editor.org/authors/rfc9733.pdf The relevant diff files have been posted here: https://www.rfc-editor.org/authors/rfc9733-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9733-auth48diff.html (AUTH48 changes) Please review the document carefully and contact us with any further updates you may have. Note that we do not make changes once a document is published as an RFC. We will await approvals from each party listed on the AUTH48 status page below prior to moving this document forward in the publication process. For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9733 Thank you, RFC Editor/ap > On Feb 19, 2025, at 5:22 AM, David von Oheimb > <David.von.Oheimb=40siemens....@dmarc.ietf.org> wrote: > > P.S Oops, I was notified of a copy&paste error in my below email in the > response to question 1 > (which should have been updated in consistency with what we wrote further > down in our requested list changes on section 2). > > > Please use as the new document title (to match the style of the title of the > BRSKI-PRM draft): > > BRSKI with Alternative Enrollment Protocols (BRSKI-AE) > > David > > > On 19.02.25 13:10, David von Oheimb wrote: >> Dear RFC editors, >> thank you for your work on polishing the document and your list of good >> questions. >> Our apologies for taking longer than expected to respond - >> after I prepared a draft response on which we had to align among us authors, >> I was on sick leave for a couple of days. >> >> We enclose below our aligned responses to the given list of questions. >> We authors agree on most changes. For a small part of them we see good >> reason to return to the original text or we suggest further enhancement, all >> of which we also list below. >> Please let us know if anything remains to be clarified. >> Best regards, >> David von Oheimb and co-authors >> >> >> On 11.02.25 00:05, rfc-edi...@rfc-editor.org wrote: >>> Authors, >>> >>> While reviewing this document during AUTH48, please resolve (as necessary) >>> the following questions, which are also in the XML file. >>> >>> 1) <!--[rfced] Please note that the title of the document has been updated >>> as >>> follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC >>> Style Guide"). Please review and confirm that this is how you would like >>> "BRSKI-AE" to be expanded both in the title and throughout the rest of >>> this document. >>> >>> Original: >>> BRSKI-AE: Alternative Enrollment Protocols in BRSKI >>> >>> Current: >>> BRSKI-AE: Bootstrapping Remote Secure Key Infrastructure with Alternative >>> Enrollment >>> --> >> OLD: >> >> BRSKI-AE: Bootstrapping Remote Secure Key Infrastructure with Alternative >> Enrollment >> NEW: >> >> BRSKI-AE: Bootstrapping Remote Secure Key Infrastructure with Alternative >> Enrollment Protocols > Update: > NEW: > BRSKI with Alternative Enrollment Protocols (BRSKI-AE) >>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in >>> the title) for use on >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fsearch&data=05%7C02%7Cdavid.von.oheimb%40siemens.com%7C8b2ed9f5423e4b68146208dd4a277bb1%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638748258750743998%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EJbTDEgl5v5lmCcVRB9BKxq5OQ4QDXmSkdMDS%2BtO1SE%3D&reserved=0. >>> --> >> >> BRSKI, IoT, zero-touch onboarding, alternative enrollment protocols, CMP, >> self-contained signed objects, end-to-end proof of origin, auditable source >> authentication >> >> >>> 3) <!-- [rfced] We have updated the text below to improve readability. >>> Please >>> review to ensure these changes do not alter your intended meaning. >>> >>> Original: >>> It uses them to authenticate itself to the >>> Manufacturer Authorized Signing Authority (MASA, [RFC8995]), and >>> to the registrar, which is the access point of the target domain, >>> and to possibly further components of the domain where it will be >>> operated. >>> >>> Current: >>> It uses them to authenticate itself to the >>> Manufacturer Authorized Signing Authority (MASA) [RFC8995] and the >>> registrar (which is the access point of the target domain) and to >>> possibly further components of the domain where it will be >>> operated. >>> --> >> Pretty good. >> Just may add commas to separate the clauses more clearly, if you agree this >> would help: >> >> OLD: >> >> [RFC8995] and the registrar (which is the access point of the target domain) >> and to >> NEW (optional, or keep OLD): >> [RFC8995], to the registrar (which is the access point of the target >> domain), and to >> >> >> >>> 4) <!-- [rfced] Please review the following questions and changes regarding >>> the >>> terminology list in Section 2: >>> >>> a.) FYI - We have updated some list items to have a 1:1 relationship between >>> abbreviation and expansion. Please carefully review these changes and let us >>> know of any objections. >> Please add NEW: >> local RA: same as LRA. >> >>> b.) As this list contains a mixture of definitions and abbreviations, may we >>> separate these items into two separate lists for readability? >> Yes. >> >>> c.) We note that several abbreviations appear in this document that are not >>> included in the terminology list in Section 2 (see some examples >>> below). Please review and let us know if these or any other terms should be >>> added. >>> >>> (Note that we have already added a list item for Certification Authority >>> (CA) >>> as this abbreviation appears in other definitions in this list.) >>> >>> Key Encapsulation Mechanism (KEM) >>> Certificate Request Message Format (CRMF) >>> Simple Certificate Enrolment Protocol (SCEP) >>> Certificate Management over CMS (CMC) >>> Autonomic Control Plane (ACP) >>> --> >> Please add NEW: >> >> Certificate Request Message Format (CRMF) >> Simple Certificate Enrolment Protocol (SCEP) >> Certificate Management over CMS (CMC) >> >> (The other two abbreviations are just used very locally, so no need to add >> them.) >> >>> 5) <!-- [rfced] May we clarify the content in the parenthetical text below? >>> >>> Original: >>> Binding a certificate signing request (CSR) to an existing >>> authenticated credential (the BRSKI context, the IDevID certificate) >>> enables proof of origin... >>> >>> Perhaps: >>> Binding a Certificate Signing Request (CSR) to an existing >>> authenticated credential (such as the BRSKI context or the IDevID >>> certificate) >>> enables proof of origin... >>> --> >>> >> OLD: >> (such as the BRSKI context or the IDevID certificate) >> NEW: >> (which in the BRSKI context is the IDevID certificate) >> >>> 6) <!-- [rfced] FYI - For ease of the reader, we have broken up the >>> following >>> sentences below into two. Please let us know any objections. >>> >>> Original: >>> What the registrar needs to do is to authenticate and pre-authorize the >>> pledge and to indicate this to the (second) RA by signing the forwarded >>> certification request with its private key and a related certificate >>> that has the id-kp- cmcRA extended key usage attribute. >>> ... >>> It will recognize whether the protocol >>> it uses and the specific request it wants to perform are understood >>> and supported by the domain registrar by sending the request to the >>> respective endpoint according to the above addressing scheme and then >>> evaluating the HTTP status code of the response. >>> >>> Current: >>> What the registrar needs to do is authenticate and pre-authorize the >>> pledge and indicate this to the (second) RA. This is done by signing the >>> forwarded certification request with its private key and a related >>> certificate >>> that has the id-kp-cmcRA extended key usage attribute. >>> ... >>> It will recognize whether the protocol >>> it uses and the specific request it wants to perform are understood >>> and supported by the domain registrar. This is done by sending the >>> request to the respective endpoint according to the above addressing >>> scheme and then evaluating the HTTP status code of the response. >>> --> >>> >> Fine. >> >>> 7) <!--[rfced] To avoid the awkward hyphenation of "PKCS #10-formatted >>> CSRs", >>> may we update the text as follows? >>> >>> Original: >>> [RFC7030], Section 2.5 sketches wrapping PKCS #10-formatted CSRs >>> with a Full PKI Request message sent to the "/fullcmc" endpoint. >>> >>> Perhaps: >>> [RFC7030], Section 2.5 sketches wrapping CSRs formatted per PKCS #10 >>> with a Full PKI Request message sent to the "/fullcmc" endpoint. >>> --> >> Fine. >> >>> 8) <!-- [rfced] We note the use of "FullCMCRequest" in the following >>> sentence; >>> however, RFC 7030 uses the term "Full CMC Request". May we update this >>> instance for consistency with RFC 7030? >>> >>> Original: >>> The proof of identity can be provided as part of a FullCMCRequest, based on >>> CMS [RFC5652] and signed with an existing IDevID secret. >>> >>> Perhaps: >>> The proof of identity can be provided as part of a Full CMC Request based on >>> CMS [RFC5652] and signed with an existing IDevID secret. >>> --> >> Fine. >> >>> 9) <!-- [rfced] In the sentence below, may we update "follows" for clarity? >>> >>> Original: >>> Note: From the definition of the interaction with the MASA in >>> [RFC8995], Section 5 follows that it may be synchronous (using >>> voucher request with nonces) or asynchronous (using nonceless >>> voucher requests). >>> >>> Perhaps: >>> Note: From the definition of the interaction with the MASA in >>> Section 5 of [RFC8995], it may be synchronous (using >>> voucher requests with nonces) or asynchronous (using nonceless >>> voucher requests). >>> --> >> >> We are note sure, maybe it would be more clear to write as follows; please >> choose as you prefer: >> >> >> OLD: >> From the definition of the interaction with the MASA in Section 5 of >> [RFC8995], >> NEW (optional, or keep OLD): >> The definition of the interaction with the MASA in Section 5 of [RFC8995] >> implies that >> >> >>> 10) <!-- [rfced] How may we clarify what "as not already done" and "it" >>> refer to >>> in the text below? >>> >>> Original: >>> * RA: performs centralized certificate management functions as a >>> public-key infrastructure for the domain operator. As far as not >>> already done by the domain registrar, it performs the final >>> validation and authorization of certification requests. >>> >>> Perhaps: >>> * RA: This performs centralized certificate management functions as a >>> public-key infrastructure for the domain operator. As far as what is >>> not already done by the domain registrar, the RA performs the final >>> validation and authorization of certification requests. >>> --> >> OLD: >> As far as what is not already done by the domain registrar >> NEW: >> Insofar these functions are not already done by the domain registrar, >> (or >> NEW': >> >> In case these functions are not entirely performed by the domain registrar, >> ) >> >>> 11) <!-- [rfced] Throughout this document, we note that RFCs 8895 and 9483 >>> are >>> often referred to with shortened titles or nicknames such as "BRSKI" and >>> "LCMPP", respectively. >>> >>> For clarity, because these names also represent protocols, we plan to update >>> these document nicknames to just their RFC number (in order to help the >>> reader >>> distinguish between the RFC itself and the protocol). Please see some >>> examples >>> below and let us know any objections. >>> >>> Originals: >>> In this document, references to CMP follow the Lightweight CMP >>> Profile (LCMPP) [RFC9483] rather than [RFC4210] and [RFC9480], as the >>> subset of CMP defined in LCMPP sufficiently meets the required >>> functionality. >>> >>> * MASA: functionality as described in BRSKI [RFC8995]. The voucher >>> exchange with the MASA via the domain registrar is performed as >>> described in BRSKI. >>> >>> * Ownership tracker: This is as defined in BRSKI. >>> >>> Perhaps: >>> In this document, references to CMP follow [RFC9483] rather than >>> [RFC4210] and [RFC9480], as the subset of CMP defined in [RFC9483] >>> sufficiently meets the required functionality. >>> >>> * MASA: This has the functionality as described in [RFC8995]. >>> The voucher exchange with the MASA via the domain registrar is >>> performed as described in [RFC8995]. >>> >>> * Ownership Tracker: This is as defined in [RFC8995]. >>> --> >> OK for BRSKI -> [RFC8995]. We use LCMPP not as the name of a protocol - it >> is the name of the profile defined in [RFC9483]. Therefore, please keep >> "Lightweight CMP Profile (LCMPP)" and "LCMPP". Yet for the only case where >> we actually mean the respective protocol, so in the abbreviation list in >> section 2 within the item for "BRSKI-AE" please change (also for >> simplicit)y: OLD: Lightweight CMP (see LCMPP) NEW: >> CMP >> >>> 12) <!-- [rfced] In Section 4.1, should "Discovery phase" and >>> "Identification phase" >>> be updated to "Discover phase" and "Identity phase", respectively, to better >>> match the figure from Section 2.1 of RFC 8995? >>> >>> Original: >>> Based on the diagram in BRSKI [RFC8995], Section 2.1 and the >>> architectural changes, the original protocol flow is divided into >>> several phases showing commonalities and differences to the original >>> approach as follows. >>> >>> * Discovery phase: mostly as in BRSKI step (1). For details see >>> Section 4.2.1. >>> >>> * Identification phase: same as in BRSKI step (2). >>> >>> Perhaps: >>> Based on the diagram in [RFC8995], Section 2.1 and the >>> architectural changes, the original protocol flow is divided into >>> several phases showing commonalities and differences to the original >>> approach as follows. >>> >>> * Discover phase: This is mostly as in step (1) of [RFC8995]. For >>> details see Section 4.2.1. >>> >>> * Identity phase: This is the same as in step (2) of [RFC8995]. >>> --> >>> >> >> We consider the suggested change problematic because, e.g., >> "Discover phase" it could be misread as "this discovers a phase". >> Moreover, BRSKI section 2.1 does not use "phase" in the figure nor in the >> labels of the list elements. >> So for consistency with that, please remove form your suggestion the "phase" >> part: >> OLD: >> Discovery phase: This >> NEW: >> Discover: This >> >> OLD: >> >> Identity phase: This >> NEW: >> Identify: This >> >> >> (and in the sequel): >> OLD: >> Voucher exchange phase: This >> NEW: >> >> Voucher exchange: This >> >> >>> 13) <!--[rfced] To improve the readability of the following sentence, may >>> we update >>> it as follows? >>> >>> Original: >>> For transporting the certificate enrollment request and response >>> messages, the (D)TLS channel established between pledge and >>> registrar is REQUIRED to use. >>> >>> Perhaps: >>> It is REQUIRED to use the (D)TLS channel established between the >>> pledge and registrar to transport the certificate enrollment request >>> and response messages. >>> --> >> Fine. >> >>> 14) <!-- [rfced] Should "options applicable" be updated to "applicable >>> options" >>> in the text below? >>> >>> Original: >>> Section 5 discusses selected suitable enrollment protocols and options >>> applicable. >>> >>> Perhaps: >>> Section 5 discusses selected suitable enrollment protocols and applicable >>> options. >>> --> >> Yes. >> >>> 15) <!-- [rfced] As this sentence begins Section 4.2.4, may we clarify what >>> "This" refers to? >>> >>> Additionally, may we make a similar update in Appendix A.5? >>> >>> Original: >>> 4.2.4. Pledge - Registrar - RA/CA Certificate Enrollment >>> >>> This replaces the EST integration for PKI bootstrapping described in >>> [RFC8995], Section 5.9 (while [RFC8995], Section 5.9.4 remains as the >>> final phase, see below). >>> ... >>> A.5. Infrastructure Isolation Policy >>> >>> This refers to any case in which network infrastructure is normally >>> isolated from the Internet as a matter of policy, most likely for >>> security reasons. >>> >>> Perhaps: >>> 4.2.4. Pledge - Registrar - RA/CA Certificate Enrollment >>> >>> RA/CA certificate enrollment replaces the EST integration for PKI >>> bootstrapping described in Section 5.9 of [RFC8995] (while Section 5.9.4 >>> of [RFC8995] remains as the final phase; see below). >>> ... >>> A.5. Infrastructure Isolation Policy >>> >>> The infrastructure isolation policy refers to any case in which... >>> --> >> 4.2.4 >> OLD: >> RA/CA certificate enrollment replaces >> NEW: >> The specification in this section replaces >> >> A.5 >> OLD: >> The infrastructure isolation policy refers >> NEW: >> The approach described in this section refers >> >>> 16) <!-- [rfced] To improve readability, may we update the list below as >>> follows? >>> >>> Original: >>> They include the application scenario, the capabilities of the registrar >>> and of the local RA possibly co-located with the registrar, the enrollment >>> protocol being used, and the specific contents of the request. >>> >>> Perhaps: >>> They include the application scenario, the capabilities of the registrar, >>> the capabilities of the local RA possibly co-located with the registrar, >>> the enrollment protocol being used, and the specific contents of the >>> request. >>> --> >> Fine. >> >> >>> 17) <!--[rfced] Should the following artwork element be reformatted as >>> a bulleted list, per text from the preceding paragraph? >>> >>> Original: >>> The following list of endpoints provides an illustrative example of a >>> domain registrar supporting several options for EST as well as for >>> CMP to be used in BRSKI-AE. >>> ... >>> /.well-known/brski/voucherrequest >>> /.well-known/brski/voucher_status >>> /.well-known/brski/enrollstatus >>> /.well-known/est/cacerts >>> /.well-known/est/csrattrs >>> /.well-known/est/fullcmc >>> /.well-known/cmp/getcacerts >>> /.well-known/cmp/getcertreqtemplate >>> /.well-known/cmp/initialization >>> /.well-known/cmp/pkcs10 >>> --> >> As you prefer. >> >> >>> 18) <!-- [rfced] Formatting and XML: >>> >>> a.) There are several author comments present in the XML. Please >>> review and confirm that none of these comments still need to be >>> addressed. Note that the comments will be deleted prior to >>> publication. >> Yes, fine to delete them. >> >>> b.) Please review whether any of the notes in this document >>> should be in the <aside> element. It is defined as "a container for >>> content that is semantically less important or tangential to the >>> content that surrounds it" >>> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Fen%2Frfcxml-vocabulary%23aside&data=05%7C02%7Cdavid.von.oheimb%40siemens.com%7C8b2ed9f5423e4b68146208dd4a277bb1%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638748258750770590%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wm5TdcsPKK0A9hd%2Blj0dqpwNlmxRzChOgHWOz0SDeEc%3D&reserved=0). >>> >> Please use <aside> for the following note paragraphs: >> Note: From the definition of the interaction with the MASA in >> [RFC8995], Section 5 follows that it may be synchronous (using >> voucher requests with nonces) or asynchronous (using nonceless >> voucher requests). >> >> Note: The message exchanges marked OPTIONAL in Figure 2 below >> cover all those supported by the use of EST in BRSKI. The last >> OPTIONAL one, namely certificate confirmation, is not supported by >> EST but by CMP and other enrollment protocols. >> >> Note that the optional certificate confirmation by the pledge to the >> PKI described above is independent of the mandatory enrollment status >> telemetry done between the pledge and the registrar in the final >> phase of BRSKI-AE, which is described next. >> Note that independent of the certificate confirmation within CMP, >> enrollment status telemetry with the registrar at the BRSKI level >> will be performed as described in [RFC8995], Section 5.9.4. >> Note: We chose the suffix "cmp" here rather than some other >> abbreviation like "lcmpp" mainly because this document defines the >> normative CMP instantiation of BRSKI-AE, which implies adherence to >> LCMPP is necessary and sufficient. >> Note: If EST was used, the registrar could give implicit consent on a >> certification request by forwarding the request to a PKI entity using >> a connection authenticated with a certificate containing an id-kp- >> cmcRA extension. >> >>> c.) We note the following different uses regarding this document's use of >>> <tt> >>> styling and quotation marks. In the HTML and PDF outputs, the text enclosed >>> in >>> <tt> is output in fixed-width font. In the txt output, there are no changes >>> to >>> the font. Please review carefully and let us know if any updates should be >>> made >>> for consistency: >>> >>> the <tt>caPubs</tt> field >>> the acp-node-name field (no quotes or <tt> styling) >>> >>> <tt>"brski-reg-cmp"</tt> >>> brski-reg-cmp (no quotes or <tt> styling) >>> >>> <tt>"brski-registrar"</tt> >>> <tt>"/.well-known/est/simpleenroll"</tt> >>> <tt>"/.well-known/<enrollment-protocol>/<request>"</tt> >>> <tt>"/fullcmc"</tt> endpoint >>> <tt>"/simpleenroll"</tt> endpoint >>> >>> '<tt>est</tt>' >>> '<tt>cmp</tt>' >>> >>> <tt><enrollment-protocol></tt> >>> <tt><request></tt> >>> The label <tt>[OPTIONAL forwarding]</tt> >>> >>> 'renewal' option >>> "tls-unique" value >>> the tls-unique value (no quotes) >>> --> >> Good point. >> >> OLD: >> the <tt>caPubs</tt> field >> NEW: >> the '<tt>caPubs</tt>' field >> >> OLD: >> the acp-node-name field >> NEW: >> the 'acp-node-name' field >> >> (several times:) >> OLD: >> >> <tt><enrollment-protocol></tt> >> >> NEW: >> >> "<tt><enrollment-protocol></tt>" >> >> >> (several times:) >> OLD: >> >> <tt><request></tt> >> >> NEW: >> >> "<tt><request></tt>" >> >> OLD: >> >> The label <tt>[OPTIONAL forwarding]</tt> >> >> NEW: >> >> The label '<tt>[OPTIONAL forwarding]</tt>' >> >> OLD: >> >> the tls-unique value >> >> NEW: >> >> the "tls-unique" value >> >> >> >>> 19) <!-- [rfced] Abbreviations: >>> >>> a.) FYI - We have updated the expansion of LDevID throughout the document >>> as follows. Please review and let us know of any objections. >>> >>> Original: >>> Locally significant Device IDentifier (LDevID) >>> >>> Current: >>> Local Device Identifier (LDevID) >> Please revert this change, as the official name does include "Locally >> significant" and the "IDentifier" is meant to point out that the first two >> letters are part of the abbreviation. >>> >>> b.) We note the following expanded forms of "PKI" are used after the >>> abbreviation is introduced. May we update these instances below to the >>> abbreviation? >>> >>> Public-Key Infrastructure >>> public-key infrastructure >> Figure 1: >> OLD: >> Public-Key Infrastructure >> >> NEW: >> >> Public-Key Infrastructure (PKI) >> >> 4.1 >> OLD: >> a public-key infrastructure >> NEW: >> >> a PKI >> >>> c.) May we update instances of "local RA" to the abbreviation "LRA"? >> Please keep "local RA", which contrasts better with "full RA". >> >> >>> d.) FYI - We have added expansions for abbreviations upon first use >>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >>> expansion in the document carefully to ensure correctness. >>> >>> Autonomic Control Plane (ACP) >>> Certificate Management over CMS (CMC) >>> Cryptographic Message Syntax (CMS) >>> Constrained Application Protocol (CoAP) >>> Simple Certificate Enrollment Protocol (SCEP) >>> --> >> Fine. >> >>> 20) <!-- [rfced] Please review the following changes and questions we have >>> regarding the References section: >>> >>> a.) [UNISIG-Subset-137] >>> >>> The provided URL returns the message: "The requested page could not be >>> found." >>> We found the following URL from the European Union Agency for Railways (ERA) >>> website, which matches the specification described in this reference, but it >>> is a more up-to-date version from May 2023. Would you like to use this >>> version >>> and URL instead? >>> >>> https://www.era.europa.eu/sites/default/files/filesystem/ertms/ccs_tsi_annex_a_-_mandatory_specifications/set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_-_subset-137_v100.pdf >>> >>> Current: >>> [UNISIG-Subset-137] >>> UNISIG, "ERTMS/ETCS On-line Key Management FFFIS", Subset- >>> 137, Version 1.0.0, December 2015, >>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.era.europa.eu%2Fsites%2Fdefault%2Ffiles%2Ffilesystem%2F&data=05%7C02%7Cdavid.von.oheimb%40siemens.com%7C8b2ed9f5423e4b68146208dd4a277bb1%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638748258750796912%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=V2BE7Q2KDktZ2wte4twO82qT1%2BEdsCMAAHB3o9iI4eo%3D&reserved=0 >>> ertms/ccs_tsi_annex_a_-_mandatory_specifications/ >>> set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_- >>> _subset-137_v100.pdf>. >>> >>> >> >> Sigh, the original link was ugly and prone to break, and meanwhile it did. >> Please use instead this link: >> >> NEW: >> >> https://www.era.europa.eu/system/files/2023-01/sos3_index083_-_subset-137_v100.pdf >> >> >>> b.) [BRSKI-AE-OVERVIEW] >>> >>> FYI - We have removed the text below from the <annotation> element in this >>> reference. If you would like to include this note, we recommend placing it >>> in >>> the document where this reference is cited (rather than in the references >>> section). >>> >>> "Graphics on slide 4 of the status update on the BRSKI-AE draft 04 at IETF >>> 116." >> Then please re-add the description of what was actually meant, namely only >> slide 4, >> as we indicated above for section 4.2: >> >> NEW: >> >> can be found in the graphics on slide 4 of [BRSKI-AE-overview]. >> >>> c.) [IEC-62351-9] >>> >>> Would you like to update to the newest version of this reference? The cited >>> version of this reference has been withdrawn. In addition, this version of >>> the >>> document references the SCEP Internet-Draft rather than RFC 8894 (SCEP). RFC >>> 8894 is cited in the 2023 version. >>> >>> Current: >>> [IEC-62351-9] >>> International Electrotechnical Commission, "Power systems >>> management and associated information exchange - Data and >>> communications security - Part 9: Cyber security key >>> management for power system equipment", IEC 62351-9:2017, >>> May 2017, >>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwebstore.iec.ch%2Fen%2Fpublication%2F30287&data=05%7C02%7Cdavid.von.oheimb%40siemens.com%7C8b2ed9f5423e4b68146208dd4a277bb1%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638748258750814239%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YRkxthgRluLnytsP%2FRzjbOUh8%2BpiWU%2BK4VtuDL3ep%2BI%3D&reserved=0>. >>> >>> --> >> Yes, please update to the latest version, >> apparently available at https://webstore.iec.ch/en/publication/66864 >> >> >>> 21) <!-- [rfced] Please review the "Inclusive Language" portion of the >>> online >>> Style Guide >>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C02%7Cdavid.von.oheimb%40siemens.com%7C8b2ed9f5423e4b68146208dd4a277bb1%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638748258750829249%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=AtbDW2tr3of02EvP%2BeqM3FAsnPVVcaLiPSmGn%2Bm2uQg%3D&reserved=0> >>> and let us know if any changes are needed. Updates of this nature typically >>> result in more precise language, which is helpful for readers. >>> >>> Note that our script did not flag any words in particular, but this should >>> still be reviewed as a best practice. --> >> We did not notice any problematic words. >> As non-native speakers, we anyway believe that your script would know better >> than us. >> >> Mostly independently of the questions answered above, here is a list of >> changes requested by the authors >> relative to the update you provided at >> https://www.rfc-editor.org/authors/rfc9733-rfcdiff.html : >> >> Global >> >> (since OVERVIEW and DISCOVERY would wrongly look like abbreviations:) >> OLD: >> BRSKI-AE-OVERVIEW >> NEW: >> BRSKI-AE-overview >> >> Global >> OLD: >> BRSKI-DISCOVERY >> NEW. >> >> BRSKI-discovery >> >> 1. >> OLD: >> Initial Device Identifier (IDevID) >> NEW: >> Initial Device IDentifier (IDevID) >> >> 1. >> OLD: >> voucher exchange [RFC8366] >> NEW: >> voucher [RFC8366] exchange >> >> 2. >> OLD: >> >> BRSKI-AE: BRSKI with Alternative Enrollment. >> NEW: >> >> BRSKI with Alternative Enrollment Protocols (BRSKI-AE) >> >> 2. >> OLD: >> IDevID: Initial Device Identifier >> NEW: >> IDevID: Initial Device IDentifier >> >> 2. >> OLD: >> LDevID: Local Device Identifier >> NEW. >> LDevID: Locally Significant Device IDentifier >> >> 4.2. >> OLD: >> >> can be found at [BRSKI-AE-OVERVIEW]. >> >> NEW: >> can be found in the graphics on slide 4 of [BRSKI-AE-overview]. >> >> >> 6. >> >> We are ok with your change >> from "Lightweight CMP Profile (LCMPP, [RFC9483])" >> to "Lightweight CMP Profile (LCMPP) [RFC9483]" >> because it improves consistency with the style used in sections 1 and 5.1. >> Yet please just note that this change incurs a minor textual discrepancy >> with the Description entry at >> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=brski-reg-cmp >> which uses "Lightweight CMP Profile (LCMPP, [RFC9483])". >> >> >> A.1 >> OLD: >> These communicate within the railroad car but also exchange information >> between railroad cars, >> forming a train with track-side equipment and/or possibly with backend >> systems. >> NEW: >> >> These communicate within the railroad car but also exchange information with >> other railroad cars >> of the same train and with track-side equipment and/or possibly with backend >> systems. >> >> On 11.02.25 00:04, rfc-edi...@rfc-editor.org wrote: >>> *****IMPORTANT***** >>> >>> Updated 2025/02/10 >>> >>> RFC Author(s): >>> -------------- >>> >>> Instructions for Completing AUTH48 >>> >>> Your document has now entered AUTH48. Once it has been reviewed and >>> approved by you and all coauthors, it will be published as an RFC. >>> If an author is no longer available, there are several remedies >>> available as listed in the FAQ >>> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F&data=05%7C02%7Cdavid.von.oheimb%40siemens.com%7Cea014175a6ca4c3be31e08dd4a275747%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638748255324668215%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MYF2Uh3MZzP0YQ4uBdOvQopBYEbNyawmAtic64hGbts%3D&reserved=0). >>> >>> You and you coauthors are responsible for engaging other parties >>> (e.g., Contributors or Working Group) as necessary before providing >>> your approval. >>> >>> Planning your review >>> --------------------- >>> >>> Please review the following aspects of your document: >>> >>> * RFC Editor questions >>> >>> Please review and resolve any questions raised by the RFC Editor >>> that have been included in the XML file as comments marked as >>> follows: >>> >>> <!-- [rfced] ... --> >>> >>> These questions will also be sent in a subsequent email. >>> >>> * Changes submitted by coauthors >>> >>> Please ensure that you review any changes submitted by your >>> coauthors. We assume that if you do not speak up that you >>> agree to changes submitted by your coauthors. >>> >>> * Content >>> >>> Please review the full content of the document, as this cannot >>> change once the RFC is published. Please pay particular attention to: >>> - IANA considerations updates (if applicable) >>> - contact information >>> - references >>> >>> * Copyright notices and legends >>> >>> Please review the copyright notice and legends as defined in >>> RFC 5378 and the Trust Legal Provisions >>> (TLP – >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-info&data=05%7C02%7Cdavid.von.oheimb%40siemens.com%7Cea014175a6ca4c3be31e08dd4a275747%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638748255324703061%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Df5qr2RIP%2B4moyKaG2BrR9tj4IxBhqreHDHjyRJ3yKk%3D&reserved=0). >>> >>> * Semantic markup >>> >>> Please review the markup in the XML file to ensure that elements of >>> content are correctly tagged. For example, ensure that <sourcecode> >>> and <artwork> are set correctly. See details at >>> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary&data=05%7C02%7Cdavid.von.oheimb%40siemens.com%7Cea014175a6ca4c3be31e08dd4a275747%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638748255324716591%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=36s0zf6m8NqTHiLqUwuVFrpQQm5viV1hz%2BpA38id4QQ%3D&reserved=0>. >>> >>> * Formatted output >>> >>> Please review the PDF, HTML, and TXT files to ensure that the >>> formatted output, as generated from the markup in the XML file, is >>> reasonable. Please note that the TXT will have formatting >>> limitations compared to the PDF and HTML. >>> >>> >>> Submitting changes >>> ------------------ >>> >>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>> the parties CCed on this message need to see your changes. The parties >>> include: >>> >>> * your coauthors >>> >>> * rfc-edi...@rfc-editor.org (the RPC team) >>> >>> * other document participants, depending on the stream (e.g., >>> IETF Stream participants are your working group chairs, the >>> responsible ADs, and the document shepherd). >>> >>> * auth48archive@rfc-editor.org, which is a new archival mailing list >>> to preserve AUTH48 conversations; it is not an active discussion >>> list: >>> >>> * More info: >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Cdavid.von.oheimb%40siemens.com%7Cea014175a6ca4c3be31e08dd4a275747%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638748255324728647%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=d6rS%2BU6h2rHbloogUsEOqyB5YOa0aoqLQY47JYeTIAY%3D&reserved=0 >>> >>> * The archive itself: >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cdavid.von.oheimb%40siemens.com%7Cea014175a6ca4c3be31e08dd4a275747%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638748255324740424%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=pSCT2oyoEB%2BMUgTXZxoYfJ15BYGNZj3wsgM0HNLRoCA%3D&reserved=0 >>> >>> * Note: If only absolutely necessary, you may temporarily opt out >>> of the archiving of messages (e.g., to discuss a sensitive matter). >>> If needed, please add a note at the top of the message that you >>> have dropped the address. When the discussion is concluded, >>> auth48archive@rfc-editor.org will be re-added to the CC list and >>> its addition will be noted at the top of the message. >>> >>> You may submit your changes in one of two ways: >>> >>> An update to the provided XML file >>> — OR — >>> An explicit list of changes in this format >>> >>> Section # (or indicate Global) >>> >>> OLD: >>> old text >>> >>> NEW: >>> new text >>> >>> You do not need to reply with both an updated XML file and an explicit >>> list of changes, as either form is sufficient. >>> >>> We will ask a stream manager to review and approve any changes that seem >>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>> and technical changes. Information about stream managers can be found in >>> the FAQ. Editorial changes do not require approval from a stream manager. >>> >>> >>> Approving for publication >>> -------------------------- >>> >>> To approve your RFC for publication, please reply to this email stating >>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>> as all the parties CCed on this message need to see your approval. >>> >>> >>> Files >>> ----- >>> >>> The files are available here: >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9733.xml&data=05%7C02%7Cdavid.von.oheimb%40siemens.com%7Cea014175a6ca4c3be31e08dd4a275747%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638748255324751603%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OGl%2BMNBHUSDRqKe7%2B2VtAPnu4DImI6REdEpHQR7sCNA%3D&reserved=0 >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9733.html&data=05%7C02%7Cdavid.von.oheimb%40siemens.com%7Cea014175a6ca4c3be31e08dd4a275747%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638748255324762818%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tBNCtkRblZFZ3Qgel2yQll1TSRXsco4ldpUixq%2BvC4s%3D&reserved=0 >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9733.pdf&data=05%7C02%7Cdavid.von.oheimb%40siemens.com%7Cea014175a6ca4c3be31e08dd4a275747%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638748255324773897%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bZ5qwfrYKnHp6KClo%2FKCPBuIg2xa56ah%2BB40KAFlSuE%3D&reserved=0 >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9733.txt&data=05%7C02%7Cdavid.von.oheimb%40siemens.com%7Cea014175a6ca4c3be31e08dd4a275747%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638748255324784498%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Hu6uUgZ%2FuBYxbfSDtiQH5cEwpg9sOt0c%2BbTyvZ0i1yw%3D&reserved=0 >>> >>> Diff file of the text: >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9733-diff.html&data=05%7C02%7Cdavid.von.oheimb%40siemens.com%7Cea014175a6ca4c3be31e08dd4a275747%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638748255324799207%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4dBIzu%2B%2BNS7Zf47rI241UPPz3jUXpnwJ5lONenTX5lM%3D&reserved=0 >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9733-rfcdiff.html&data=05%7C02%7Cdavid.von.oheimb%40siemens.com%7Cea014175a6ca4c3be31e08dd4a275747%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638748255324813972%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=15GBUkIMTHBTDS%2FXjotl3oNgaErHkOp6VigZi4TCc9M%3D&reserved=0 >>> (side by side) >>> >>> Diff of the XML: >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9733-xmldiff1.html&data=05%7C02%7Cdavid.von.oheimb%40siemens.com%7Cea014175a6ca4c3be31e08dd4a275747%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638748255324825944%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=PDd9L%2F8Icm4W3JOaWJhXUYQRZ%2B4GJgBWQrH8HbSft9w%3D&reserved=0 >>> >>> >>> Tracking progress >>> ----------------- >>> >>> The details of the AUTH48 status of your document are here: >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9733&data=05%7C02%7Cdavid.von.oheimb%40siemens.com%7Cea014175a6ca4c3be31e08dd4a275747%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638748255324841432%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lK67Z2cEPJtbQn4Jh7TIlQYheZNpv3R5ZhQ4fT8Qs9Y%3D&reserved=0 >>> >>> Please let us know if you have any questions. >>> >>> Thank you for your cooperation, >>> >>> RFC Editor >>> >>> -------------------------------------- >>> RFC9733 (draft-ietf-anima-brski-ae-13) >>> >>> Title : BRSKI-AE: Alternative Enrollment Protocols in BRSKI >>> Author(s) : D. von Oheimb, S. Fries, H. Brockhaus >>> WG Chair(s) : Toerless Eckert, Sheng Jiang >>> >>> Area Director(s) : Warren Kumari, Mahesh Jethanandani >>> >>> >>> -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
