Hi Authors, We do not believe we have heard from you regarding this document's readiness for publication. Please review our previous messages describing the AUTH48 process and containing any document-specific questions we may have had.
We will wait to hear from you before continuing with the publication process. The AUTH48 status page for this document is located here: https://www.rfc-editor.org/auth48/rfc9733 Thank you, RFC Editor/ap > On Feb 10, 2025, at 3:05 PM, 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 > --> > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. --> > > > 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. > --> > > > 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. > > b.) As this list contains a mixture of definitions and abbreviations, may we > separate these items into two separate lists for readability? > > 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) > --> > > > 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... > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 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). > --> > > > 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. > --> > > > 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]. > --> > > > 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]. > --> > > > 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. > --> > > > 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. > --> > > > 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... > --> > > > 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. > --> > > > 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 > --> > > > 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. > > > 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://authors.ietf.org/en/rfcxml-vocabulary#aside). > > > 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) > --> > > > 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) > > > 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 > > > c.) May we update instances of "local RA" to the abbreviation "LRA"? > > > 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) > --> > > > 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/system/files/2023-09/index083_-_SUBSET-137_v400.pdf> > > Current: > [UNISIG-Subset-137] > UNISIG, "ERTMS/ETCS On-line Key Management FFFIS", Subset- > 137, Version 1.0.0, December 2015, > <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>. > > > 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." > > > 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://webstore.iec.ch/en/publication/30287>. > > --> > > > 21) <!-- [rfced] Please review the "Inclusive Language" portion of the online > Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > 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. --> > > > Thank you. > > RFC Editor/kf/ap > > > On Feb 10, 2025, at 3:04 PM, 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://www.rfc-editor.org/faq/). > > 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://trustee.ietf.org/license-info). > > * 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://authors.ietf.org/rfcxml-vocabulary>. > > * 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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * 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://www.rfc-editor.org/authors/rfc9733.xml > https://www.rfc-editor.org/authors/rfc9733.html > https://www.rfc-editor.org/authors/rfc9733.pdf > https://www.rfc-editor.org/authors/rfc9733.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9733-diff.html > https://www.rfc-editor.org/authors/rfc9733-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9733-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9733 > > 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
