Hi John, We have updated the files to include both expansions of “LRA”.
The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9810.txt https://www.rfc-editor.org/authors/rfc9810.pdf https://www.rfc-editor.org/authors/rfc9810.html https://www.rfc-editor.org/authors/rfc9810.xml The relevant diff files are posted here: https://www.rfc-editor.org/authors/rfc9810-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9810-auth48diff.html (all AUTH48 changes) https://www.rfc-editor.org/authors/rfc9810-auth48rfcdiff.html (AUTH48 changes side by side) Thank you, RFC Editor/ap > On Jul 10, 2025, at 12:17 PM, John Gray <john.g...@entrust.com> wrote: > > Thanks Alanna, > > Given its sparse usage in the document, expanding it in both places makes > sense to me. > > Thanks, > > John Gray > > > > From: Alanna Paloma <apal...@staff.rfc-editor.org> > Sent: Thursday, July 10, 2025 3:05 PM > To: John Gray <john.g...@entrust.com> > Cc: debcool...@gmail.com <debcool...@gmail.com>; Brockhaus, Hendrik > <hendrik.brockhaus=40siemens....@dmarc.ietf.org>; von Oheimb, David > <david.von.ohe...@siemens.com>; Mike Ounsworth <mike.ounswo...@entrust.com>; > rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>; lamps-...@ietf.org > <lamps-...@ietf.org>; lamps-cha...@ietf.org <lamps-cha...@ietf.org>; > hous...@vigilsec.com<hous...@vigilsec.com>; auth48archive@rfc-editor.org > <auth48archive@rfc-editor.org> > Subject: Re: [EXTERNAL] [AD] Re: AUTH48: RFC-to-be 9810 > <draft-ietf-lamps-rfc4210bis-18> for your review > > WARNING: This email originated outside of Entrust. > DO NOT CLICK links or attachments unless you trust the sender and know the > content is safe. > Hi John, > > Thank you for your reply. > > > I'm okay with the suggested updated text (I agree it is much clearer), > > however there is a typo in it 🙂 > > > > It should be "when it is" instead of "when t is" > > The CertTemplate structure allows an end entity or RA to specify as many > > data fields as the structure wishes for the requested certificate. The > > structure also allows an end entity or RA to include any other necessary > > data, > > such as the publicKey field, when it is required for the certificate. A > > CertTemplate structure is identical to a TBSCertificate structure (see [RFC > > 5280]) > > but with all fields optional/situational. > > Thanks for spotting this! We have updated the text accordingly. > > > For the LRA line, I am fine with your suggestion. If the document use you > > show is the first usage, should it include the full name with the acronym > > in brackets? I thought that was the convention used in the rest of the > > document (or am I mistaken)? > > The first occurrence of “LRA” is expanded in "Terminology and Abbreviations” > (Section 2), so we have not expanded it in the sentence in Section 5.2.8.3.3. > Please let us know if you would like it expanded in both places. > > Current: > LRA: Local Registration Authority > … > This protocol is obviously much longer than the exchange given in > Section 5.2.8.3.2 above but allows an LRA to be involved and has the > property that the certificate itself is not actually created until > the POP is complete. > > --- > The files have been posted here (please refresh): > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810.txt__;!!FJ-Y8qCqXTj2!bXrlG1IXABCRn7pLgU1MtD1k2kJ7iEbtFjY_XaaXiHbAsKIGwNDvltLJVd5osfPCr_dVa5HKOCVzagAeUhAZLN09tA$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810.pdf__;!!FJ-Y8qCqXTj2!bXrlG1IXABCRn7pLgU1MtD1k2kJ7iEbtFjY_XaaXiHbAsKIGwNDvltLJVd5osfPCr_dVa5HKOCVzagAeUhDbDiHL1Q$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810.html__;!!FJ-Y8qCqXTj2!bXrlG1IXABCRn7pLgU1MtD1k2kJ7iEbtFjY_XaaXiHbAsKIGwNDvltLJVd5osfPCr_dVa5HKOCVzagAeUhCj8eRoGQ$ > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810.xml__;!!FJ-Y8qCqXTj2!bXrlG1IXABCRn7pLgU1MtD1k2kJ7iEbtFjY_XaaXiHbAsKIGwNDvltLJVd5osfPCr_dVa5HKOCVzagAeUhC4AtGOwg$ > > The relevant diff files are posted here: > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810-diff.html__;!!FJ-Y8qCqXTj2!bXrlG1IXABCRn7pLgU1MtD1k2kJ7iEbtFjY_XaaXiHbAsKIGwNDvltLJVd5osfPCr_dVa5HKOCVzagAeUhAC4Nr_wg$ > (comprehensive diff) > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810-auth48diff.html__;!!FJ-Y8qCqXTj2!bXrlG1IXABCRn7pLgU1MtD1k2kJ7iEbtFjY_XaaXiHbAsKIGwNDvltLJVd5osfPCr_dVa5HKOCVzagAeUhCj0k_R2Q$ > (all AUTH48 changes) > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810-auth48rfcdiff.html__;!!FJ-Y8qCqXTj2!bXrlG1IXABCRn7pLgU1MtD1k2kJ7iEbtFjY_XaaXiHbAsKIGwNDvltLJVd5osfPCr_dVa5HKOCVzagAeUhB9PiDdIA$ > (AUTH48 changes side by side) > > We will await any further changes you may have and approvals from each author > and Deb (AD) prior to moving forward in the publication process. > > Please see the AUTH48 status page for this document here: > https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9810__;!!FJ-Y8qCqXTj2!bXrlG1IXABCRn7pLgU1MtD1k2kJ7iEbtFjY_XaaXiHbAsKIGwNDvltLJVd5osfPCr_dVa5HKOCVzagAeUhArr-tV2w$ > > Thank you, > RFC Editor/ap > > > On Jul 10, 2025, at 9:20 AM, John Gray <john.g...@entrust.com> wrote: > > > > Thanks for the comments: > > > > These are my comments, I hope my fellow RFC authors agree as well: > > > > > > I'm okay with the suggested updated text (I agree it is much clearer), > > however there is a typo in it 🙂 > > > > It should be "when it is" instead of "when t is" > > The CertTemplate structure allows an end entity or RA to specify as many > > data fields as the structure wishes for the requested certificate. The > > structure also allows an end entity or RA to include any other necessary > > data, > > such as the publicKey field, when it is required for the certificate. A > > CertTemplate structure is identical to a TBSCertificate structure (see [RFC > > 5280]) > > but with all fields optional/situational. > > For the LRA line, I am fine with your suggestion. If the document use you > > show is the first usage, should it include the full name with the acronym > > in brackets? I thought that was the convention used in the rest of the > > document (or am I mistaken)? > > > > Perhaps: > > This protocol is obviously much longer than the exchange given in > > Section 5.2.8.3.2 above, but allows a local Registration Authority (LRA) to > > > > be involved and has the property that the certificate itself is not > > actually created until the proof-of-possession is complete. > > > > > > Thanks, > > > > John Gray > > > > From: Alanna Paloma <apal...@staff.rfc-editor.org> > > Sent: Thursday, July 10, 2025 11:52 AM > > To: debcool...@gmail.com <debcool...@gmail.com>; Brockhaus, Hendrik > > <hendrik.brockhaus=40siemens....@dmarc.ietf.org>; von Oheimb, David > > <david.von.ohe...@siemens.com>; Mike Ounsworth > > <mike.ounswo...@entrust.com>; John Gray <john.g...@entrust.com> > > Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>; > > lamps-...@ietf.org <lamps-...@ietf.org>; lamps-cha...@ietf.org > > <lamps-cha...@ietf.org>; hous...@vigilsec.com<hous...@vigilsec.com>; > > auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> > > Subject: [EXTERNAL] [AD] Re: AUTH48: RFC-to-be 9810 > > <draft-ietf-lamps-rfc4210bis-18> for your review > > > > WARNING: This email originated outside of Entrust. > > DO NOT CLICK links or attachments unless you trust the sender and know the > > content is safe. > > Hi Authors and Deb*, > > > > *Deb - As the AD, please review and approve of the following: > > - Appendix C.4: removal of BCP14 key word (“OPTIONALLY” to “optionally”) > > - Appendix F: added sentence at the end of the first paragraph > > > > See this diff file for the changes: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810-ad-diff.html__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3wB0AtxDw$ > > > > > > Authors - Thank you for your reply. We have updated the files accordingly. > > Please note that we have some follow-up questions: > > > > > Please Update Section 5.2.1 based on feedback from Quynh Dang. > > > OLD > > > The CertTemplate structure allows an end entity or > > > RA to specify as much as it wishes about the certificate it requires. > > > CertTemplate is identical to a Certificate, but with all fields > > > optional. > > > NEW > > > The CertTemplate structure allows an end entity or RA to specify many > > > data fields it wishes the certificate it requests to include and to > > > include any data it is required to provide such as the publicKey field > > > when it is required for the certificate. CertTemplate is identical to a > > > TBSCertificate structure (see [RFC 5280]) but with all fields > > > optional/situational. > > > > ) We are having trouble parsing the new suggested text. It is unclear what > > each of the four instances of “it” refer to. May we update the sentence as > > follows? > > > > Perhaps: > > The CertTemplate structure allows an end entity or RA to specify as many > > data fields as the structure wishes for the requested certificate. The > > structure also allows an end entity or RA to include any other necessary > > data, > > such as the publicKey field, when t is required for the certificate. A > > CertTemplate structure is identical to a TBSCertificate structure (see > > [RFC 5280]) > > but with all fields optional/situational. > > > > > > >> a) Both the expansion and the acronym for the following terms are used > > >> throughout > > >> the document. Would you like to update to using the expansion upon first > > >> usage and > > >> the acronym for the rest of the document? > > >> > > >> Local Registration Authority (LRA) > > > > > [HB] Yes, please do. > > > As the acronym LRA is not used in the document, please remove this line. > > > > > > ) We note that "local Registration Authority” was used in Section > > 5.2.8.3.3. We have updated this to “LRA” and left the term in the > > "Terminology and Abbreviations” section. Please let us know if further > > updates are needed. > > > > Original: > > This protocol is obviously much longer than the exchange given in > > Section 5.2.8.3.2 above, but allows a local Registration Authority to > > be involved and has the property that the certificate itself is not > > actually created until the proof-of-possession is complete. > > > > Current: > > This protocol is obviously much longer than the exchange given in > > Section 5.2.8.3.2 above but allows an LRA to be involved and has the > > property that the certificate itself is not actually created until > > the POP is complete. > > > > --- > > The files have been posted here (please refresh): > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810.txt__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3wZYZ8gbQ$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810.pdf__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3zN3_ROSg$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810.html__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3wu0CLetQ$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810.xml__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3wV9HfmPg$ > > > > The relevant diff files are posted here: > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810-diff.html__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3zURljmmA$(comprehensive > > diff) > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810-auth48diff.html__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3zey24sgA$(all > > AUTH48 changes) > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810-auth48rfcdiff.html__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3wGtPR5Tg$(AUTH48 > > changes side by side) > > > > Please review the document carefully as documents do not change once > > published as RFCs. > > > > We will await any further changes you may have and approvals from each > > author and *Deb prior to moving forward in the publication process. > > > > Please see the AUTH48 status page for this document here: > > https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9810__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3w-JXp6ug$ > > > > Thank you, > > RFC Editor/ap > > > > > On Jul 9, 2025, at 3:33 AM, Brockhaus, Hendrik > > > <hendrik.brockhaus=40siemens....@dmarc.ietf.org> wrote: > > > > > > Hello > > > > > > Many thanks for your review and for all valuable changes. > > > I aligned the responses to your AUTH48 questions with the co-authors, and > > > we propose the following final changes (see inline below). > > > Locking at > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810-diff.html__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3zURljmmA$I > > > have the following additional proposals: > > > > > > Section 4.2.1.1 > > > OLD > > > zero touch methods > > > NEW > > > zero-touch methods > > > > > > Please Update Section 5.2.1 based on feedback from Quynh Dang. > > > OLD > > > The CertTemplate structure allows an end entity or > > > RA to specify as much as it wishes about the certificate it requires. > > > CertTemplate is identical to a Certificate, but with all fields > > > optional. > > > NEW > > > The CertTemplate structure allows an end entity or RA to specify many > > > data fields it wishes the certificate it requests to include and to > > > include any data it is required to provide such as the publicKey field > > > when it is required for the certificate. CertTemplate is identical to a > > > TBSCertificate structure (see [RFC 5280]) but with all fields > > > optional/situational. > > > > > > In Section 5.3.4 you updated (pvno) to (pvnos) to indicate the plural. > > > (pvno) refers to the PKIHeader field and this field name has no plural. > > > To circumvent confusion, better delete (pvno) in this place. > > > OLD > > > Note: To indicate support for EnvelopedData, the pvno cmp2021 has > > > been introduced. Details on the usage of different protocol version > > > numbers (pvno) are described in Section 7. > > > NEW > > > Note: To indicate support for EnvelopedData, the pvno cmp2021 has > > > been introduced. Details on the usage of different protocol version > > > numbers are described in Section 7. > > > > > > > > > Hendrik > > > > > >> -----Ursprüngliche Nachricht----- > > >> Von: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > > >> Gesendet: Samstag, 21. Juni 2025 02:10 > > >> An: Brockhaus, Hendrik (FT RPD CST SEA-DE) > > >> <hendrik.brockh...@siemens.com>; von Oheimb, David (FT RPD CST SEA-DE) > > >> <david.von.ohe...@siemens.com>; mike.ounswo...@entrust.com; > > >> john.g...@entrust.com > > >> Cc: rfc-edi...@rfc-editor.org; lamps-...@ietf.org; lamps-cha...@ietf.org; > > >> hous...@vigilsec.com; debcool...@gmail.com; auth48archive@rfc-editor.org > > >> Betreff: AUTH48: RFC-to-be 9810 <draft-ietf-lamps-rfc4210bis-18> for > > >> your review > > >> > > >> Authors, > > >> > > >> While reviewing this document during AUTH48, please resolve (as > > >> necessary) the > > >> following questions, which are also in the XML file. > > >> > > >> 1) <!-- [rfced] To keep the abstract succinct, we suggest moving some of > > >> its content > > >> to the Introduction. Perhaps the third paragraph could be worked into > > >> the > > >> Introduction? > > >> > > >> As noted in > > >> Section 4.3 of RFC 7322: > > >> Every RFC must have an Abstract that provides a concise and > > >> comprehensive overview of the purpose and contents of the entire > > >> document, to give a technically knowledgeable reader a general > > >> overview of the function of the document.... > > >> A satisfactory Abstract can often be > > >> constructed in part from material within the Introduction section, > > >> but an effective Abstract may be shorter, less detailed, and perhaps > > >> broader in scope than the Introduction. > > >> > > >> Please review and let us know how/if the text may be updated. > > >> --> > > > > > > [HB] Please remove the third paragraph of the Abstract and update Section > > > 1.3 as follows: > > > > > > OLD: > > > This document obsoletes [RFC4210] and [RFC9480]. It includes the > > > changes specified by Section 2 and Appendix A.2 of [RFC9480] as > > > described in Section 1.2. Additionally, this document updates the > > > content of [RFC4210] in the following areas: > > > > > > NEW: > > > This document obsoletes [RFC4210] and [RFC9480]. > > > > > > Backward compatibility with CMP version 2 is maintained > > > wherever possible. Updates to CMP version 2 improve crypto > > > agility, extend the polling mechanism, add new general message > > > types, and add extended key usages (EKUs) to identify special CMP > > > server authorizations. CMP version 3 is introduced for changes to > > > the ASN.1 syntax, which support EnvelopedData, certConf with hashAlg, > > > POPOPrivKey with agreeMAC, and RootCaKeyUpdateContent in ckuann > > > messages. > > > > > > The updates made in this document include the > > > changes specified by Section 2 and Appendix A.2 of [RFC9480] as > > > described in Section 1.2. Additionally, this document updates the > > > content of [RFC4210] in the following areas: > > > > > >> > > >> > > >> 2) <!--[rfced] It is unclear to us how "that has a signature > > >> algorithm..." > > >> fits into the sentence below. Please review and let us know it may be > > >> updated for > > >> clarity. > > >> > > >> Original: > > >> * Offer an optional hashAlg field in CertStatus supporting cases > > >> that a certificate needs to be confirmed that has a signature > > >> algorithm that does not indicate a specific hash algorithm to use > > >> for computing the certHash. > > >> > > >> > > >> Perhaps: > > >> * Offer an optional hashAlg field in CertStatus supporting cases > > >> where a certificate that has a signature algorithm but doesn't > > >> specify a hash algorithm to compute the certHash needs to be > > >> confirmed. > > >> --> > > > > > > [HB] NEW > > > * Offer an optional hashAlg field in CertStatus supporting cases > > > when a certificate needs to be confirmed, but the certificate > > > was signed using a signature algorithm that does not indicate a > > > specific hash algorithm to use for computing the certHash. > > > > > >> > > >> > > >> 3) <!-- [rfced] FYI, we have updated the citations in the sentence below > > >> as follows. > > >> [RFC9480] does not have an Appendix C.2, but it does have an Appendix > > >> A.2. Please > > >> review and confirm that these updates retain the intended meaning. > > >> > > >> Original: > > >> This document obsoletes [RFC4210] and [RFC9480]. It includes the > > >> changes specified by Section 2 and Appendix C.2 of [RFC9480] as > > >> described in Section 1.2. > > >> > > >> Current: > > >> This document obsoletes [RFC4210] and [RFC9480]. It includes the > > >> changes specified by Section 2 and Appendix A.2 of [RFC9480] as > > >> described in Section 1.2. > > >> --> > > >> > > > > > > [HB] Thank you for spotting this. You are right, we wanted to refer to > > > RFC 9480 Appendix A.2. This change is also included in my proposal to 1) > > > above. > > > > > >> > > >> 4) <!-- [rfced] For clarity, we recommend adding citations for ISO/IEC > > >> 9594-8/ITU-T > > >> X.509". May we add a citation to the existing reference to [X509.2019]? > > >> > > >> Original: > > >> 1. PKI management must conform to the ISO/IEC 9594-8/ITU-T X.509 > > >> standards. > > >> --> > > > > > > [HB] Yes, please add the reference. > > > OLD > > > 1. PKI management must conform to the ISO/IEC 9594-8/ITU-T X.509 > > > standards. > > > > > > NEW > > > 1. PKI management must conform to the ISO/IEC 9594-8/ITU-T X.509 > > > standards, in particular [X509.2019]. > > > > > >> > > >> > > >> 5) <!--[rfced] It is unclear what "off-line file-based" refers to in the > > >> sentence below. > > >> Does it refer to "transport mechanisms"? > > >> > > >> Original: > > >> PKI management protocols must be usable over a variety of > > >> "transport" mechanisms, specifically including mail, Hypertext > > >> Transfer Protocol (HTTP), Message Queuing Telemetry Transport > > >> (MQTT), Constrained Application Protocol (CoAP), and off-line > > >> file-based. > > >> > > >> Perhaps: > > >> PKI management protocols must be usable over a variety of > > >> "transport" mechanisms, specifically including mail, Hypertext > > >> Transfer Protocol (HTTP), Message Queuing Telemetry Transport > > >> (MQTT), Constrained Application Protocol (CoAP), and off-line > > >> file-based transport mechanisms. > > >> --> > > > > > > [HB] Yes off-line file-based is one of the transport mechanisms listed. > > > NEW > > > 8. PKI management protocols must be usable over a variety of > > > "transport" mechanisms, specifically including email, Hypertext > > > Transfer Protocol (HTTP), Message Queuing Telemetry Transport > > > (MQTT), Constrained Application Protocol (CoAP), and various > > > off-line and non-networked file transfer methods. > > >> > > >> > > >> 6) <!--[rfced] For the nested lists in Section 3.1.3, we have updated > > >> the numbering to > > >> letters and converted "Notes" to a hanging list to help with > > >> readability. Please review > > >> and let us know of any objections. > > >> > > >> Original: > > >> 1. CA establishment: When establishing a new CA, certain steps are > > >> required (e.g., production of initial CRLs, export of CA public > > >> key). > > >> ... > > >> 1. initial registration/certification: This is the process > > >> whereby an end entity first makes itself known to a CA or RA, > > >> prior to the CA issuing a certificate or certificates for > > >> that end entity. > > >> ... > > >> 1. Note 1. The above definition of "cross-certificate" > > >> aligns with the defined term "CA-certificate" in X.509. > > >> > > >> Current: > > >> 1. CA establishment: When establishing a new CA, certain steps are > > >> required (e.g., production of initial CRLs, export of CA public > > >> key). > > >> ... > > >> a. initial registration/certification: This is the process > > >> whereby an end entity first makes itself known to a CA or RA, > > >> prior to the CA issuing a certificate or certificates for > > >> that end entity. > > >> ... > > >> Note 1. The above definition of "cross-certificate" > > >> aligns with the defined term "CA-certificate" in X.509. > > >> --> > > > > > > [HB] I like this layout. > > > > > >> > > >> > > >> 7) <!--[rfced] May we update the phrasing of "Rail Automation adopted > > >> CMP" > > >> to improve readability? > > >> > > >> Original: > > >> Also industry standards like [ETSI-3GPP.33.310] for > > >> mobile networks and [UNISIG.Subset-137] for Rail Automation adopted > > >> CMP and have specified a set of mandatory schemes for their use case. > > >> > > >> > > >> Perhaps: > > >> Also industry standards, like [ETSI-3GPP.33.310] for > > >> mobile networks and [UNISIG.Subset-137] for CMP that has adopted rail > > >> automation, have specified a set of mandatory schemes for their use > > >> cases. > > >> --> > > > > > > [HB] I am uncertain if your proposal still has the same meaning. > > > Both standards adopt CMP for certificate management. [ETSI-3GPP.33.310] > > > is a standard for mobile network infrastructures. [UNISIG.Subset-137] is > > > a standard for rail automation. > > > Would this read better? > > > NEW > > > Industry standards such as [ETSI-3GPP.33.310] for mobile networks and > > > [UNISIG.Subset-137] for railroad automation have adopted CMP and > > > defined a series of mandatory schemes for their use cases. > > > > > >> > > >> > > >> 8) <!--[rfced] We have removed the following from the figure in Section > > >> 4.2.2.2 because it is repetitive with the text introducing the figure. > > >> However, please review, as it seems like some of the blank space can > > >> also be > > >> removed from the SVG. > > >> > > >> Original: > > >> In terms of message flow, the basic authenticated scheme is as > > >> follows: > > >> --> > > > > > > [HB] I do not see any change in > > > <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810-diff.html__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3zURljmmA$>,but > > > everything looks good. > > > > > >> > > >> > > >> 9) <!--[rfced] As "CMP" is expanded as "Certificate Management > > >> Protocol", may we > > >> update this text to avoid repetition? > > >> > > >> Original: > > >> As the functionality of a > > >> CA and RA is not specific to any certificate management protocol > > >> (such as CMC or CMP), these EKUs are reused by CMP. > > >> > > >> Perhaps: > > >> As the functionality of a > > >> CA and RA is not specific to any CMP (such as CMC), these EKUs are > > >> reused by > > >> CMP. > > >> --> > > > > > > [HB] Here the term "certificate management protocol" does not > > > specifically refer to CMP but refers to any protocol managing > > > certificates. > > > Does this rephrasing improve readability? > > > NEW > > > As the functionality of a > > > CA and RA is not specific to any protocol used for managing > > > certificates (such as CMC or CMP), these EKUs are reused by CMP. > > > > > >> > > >> > > >> 10) <!--[rfced] Should "PKIconf" be updated to "pkiconf", "pkiConf", or > > >> "PKIConf" to > > >> reflect usage elsewhere in the document? > > >> > > >> Original: > > >> In response to an ip, cp, kup, krp, or ccp message, an EE will > > >> send a certConf for all issued certificates and expect a PKIconf > > >> for each certConf. > > >> --> > > > > > > [HB] Thank you for bringing this up. We also spotted this issue, but did > > > not start resolving it. But we can do this now. > > > The field name in the ASN.1 syntax of the PKIBody is "pkiconf". Therfore, > > > we should consistently use "pkiconf" or "pkiconf message" consistently. > > > Next to your examples, we should also update "PKIConfirm" accordingly. > > > Overall, there are 29 occurrences of "pkiconf" to be aligned. > > > > > > Section 5.3.16 > > > OLD > > > Upon receiving a PKIConfirm for a > > > certificate response, the recipient MAY treat it as a certConf with > > > all certificates being accepted. > > > > > > NEW > > > Upon receiving a pkiconf for a > > > certificate response, the recipient MAY treat it as a certConf with > > > all certificates being accepted. > > > > > > Section 5.3.21 > > > OLD > > > If the client sends this request, the server MUST respond with a > > > PKIConfirm response, or another ErrorMsg if any part of the header is > > > not valid. > > > NEW > > > If the client sends this request, the server MUST respond with a > > > pkiconf response or another error message if any part of the header is > > > not valid. > > > > > > Section 5.3.22 > > > OLD > > > 1 In response to an ip, cp, kup, krp, or ccp message, an EE will > > > send a certConf for all issued certificates and expect a PKIconf > > > for each certConf. > > > NEW > > > 1. In response to an ip, cp, kup, krp, or ccp message, an EE will > > > send a certConf for all issued certificates and expect a pkiconf > > > for each certConf. > > > > > > OLD > > > 23 <-- pkiConf <-- > > > NEW > > > 23 <-- pkiconf <-- > > > > > > OLD > > > 34 <-- pkiConf <-- > > > NEW > > > 34 <-- pkiconf <-- > > > > > > Section 6.6.1 > > > OLD > > > Upon receipt of the certConf message, the responder CA validates > > > the message and the MAC and sends back an acknowledgement using > > > the PKIConfirm message. > > > NEW > > > Upon receipt of the certConf message, the responder CA validates > > > the message and the MAC and sends back an acknowledgement using > > > the pkiconf message. > > > > > > Appendix C.1 > > > OLD > > > 9. All PKI message exchanges in Appendix C.4 to C.6 require a > > > certConf message to be sent by the initiating entity and a > > > PKIConfirm to be sent by the responding entity. The PKIConfirm > > > is not included in some of the profiles given since its body is > > > NULL and its header contents are clear from the context. > > > NEW > > > 9. All PKI message exchanges in Appendices C.4 to C.6 require a > > > certConf message to be sent by the initiating entity and a > > > pkiconf message to be sent by the responding entity. The pkiconf > > > is not included in some of the profiles given since its body is > > > NULL and its header contents are clear from the context. > > > > > > Appendix C.4 > > > OLD > > > The CA sends > > > a PKIConfirm back, closing the transaction. All messages are > > > authenticated. > > > NEW > > > The CA sends > > > a pkiconf message back, closing the transaction. All messages are > > > authenticated. > > > > > > OLD > > > 10 format PKIConf > > > 11 <-- PKIConf <-- > > > 12 handle PKIConf > > > NEW > > > 10 format pkiconf > > > 11 <-- pkiconf <-- > > > 12 handle pkiconf > > > > > > OLD > > > Confirmation -- PKIConf > > > NEW > > > Confirmation -- pkiconf > > > > > > OLD > > > body PKIConf > > > NEW > > > body pkiconf > > > > > > Appendices C.5 and C.6 > > > OLD > > > The CA replies with a PKIConfirm, to close the transaction. > > > NEW > > > The CA replies with a pkiconf message to close the transaction. > > > > > > OLD > > > * protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY > > > also be supported) in request, response, certConfirm, and > > > PKIConfirm messages; > > > NEW > > > * protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY > > > also be supported) in request, response, certConf, and > > > pkiconf messages; > > > > > > Appendix D.4 > > > OLD > > > CA-1 replies > > > with a PKIConfirm to close the transaction. > > > NEW > > > CA-1 replies > > > with a pkiconf message to close the transaction. > > > > > > Appendix F > > > OLD > > > -- identifies the transaction, i.e., this will be the same in > > > -- corresponding request, response, certConf, and PKIConf > > > -- messages > > > NEW > > > -- identifies the transaction, i.e., this will be the same in > > > -- corresponding request, response, certConf, and pkiconf > > > -- messages > > > > > >> > > >> > > >> 11) <!--[rfced] In the sentence below, does "are typically > > >> insufficient..." > > >> refer to "passwords" or "entropy"? > > >> > > >> Original: > > >> If user-generated passwords are used as > > >> shared secret information, their entropy cannot be measured and are > > >> typically insufficient for protected delivery of centrally generated > > >> keys or trust anchors. > > >> > > >> Perhaps A (refers to "passwords"): > > >> If user-generated passwords are used as > > >> shared secret information, their entropy cannot be measured and the > > >> passwords are typically insufficient for protected delivery of centrally > > >> generated keys or trust anchors. > > >> > > >> Perhaps B (refers to "entropy"): > > >> If user-generated passwords are used as > > >> shared secret information, their entropy cannot be measured and is > > >> typically insufficient for protected delivery of centrally generated > > >> keys or trust anchors. > > >> --> > > >> > > > > > > [HB] What do you think of this proposal? > > > NEW > > > If user-generated passwords are used as shared secret information, > > > their entropy cannot be measured. Passwords generated from user > > > generated entropy are typically insufficient for protected delivery of > > > centrally generated keys or trust anchors. > > > > > >> > > >> 12) <!-- [rfced] We are unable to verify these registrations with > > >> Entrust. > > >> Please ensure the descriptions and values are correct. In addition, > > >> please consider > > >> whether it is appropriate for this text to appear in the IANA > > >> Considerations section, as > > >> it seemingly does not provide any information for IANA and does not > > >> require any IANA > > >> actions. > > >> > > >> Original: > > >> The new OID 1.2.840.113533.7.66.16 was registered by Entrust for id- > > >> KemBasedMac in the arch 1.2.840.113533.7.66. Entrust registered also > > >> the OIDs for id-PasswordBasedMac and id-DHBasedMac there. > > >> --> > > > > > > [HB] These OIDs are registered to the Entrust arc by WG consensus in > > > order to keep it consistent with previous registrations. Entrust is an > > > author of this draft and the authors confirm that Entrust's internal > > > (non-public) registry has noted this. > > > We added this information to the IANA section as it is about OID > > > registration. As IANA was fine with this section, I tend to leave the > > > sentence as it is or just re-phrase it for clarity as follows. > > > OLD > > > The new OID 1.2.840.113533.7.66.16 was registered by Entrust for id- > > > KemBasedMac in the arch 1.2.840.113533.7.66. Entrust registered also > > > the OIDs for id-PasswordBasedMac and id-DHBasedMac there. > > > NEW > > > Note that the new OID 1.2.840.113533.7.66.16 was registered by Entrust, > > > and not by IANA, for id-KemBasedMac in the arch 1.2.840.113533.7.66. > > > This was done to match the previous registrations for id- > > > PasswordBasedMac and id-DHBasedMac, which are also on the Entrust > > > private > > > arc. > > > > > >> > > >> > > >> 13) <!-- [rfced] Would you like the references to be alphabetized or > > >> left in their current > > >> order? > > >> --> > > >> > > > > > > [HB] Yes please alphabetize them. > > > > > >> > > >> 14) <!-- [rfced] Please review. We found the following URL: > > >> https://urldefense.com/v3/__https://cacr.uwaterloo.ca/hac/index.html__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3zKQld8tw$which > > >> is provided by authors of this handbook and > > >> includes open-access PDF files of this reference. Would you like to add > > >> this URL to > > >> the reference? > > >> > > >> [MvOV97] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook > > >> of Applied Cryptography", CRC Press ISBN 0-8493-8523-7, > > >> 1996. > > >> --> > > >> > > > > > > [HB] This is a great idea. I was not aware of this link. > > > BTW, it is sufficient to use > > > https://urldefense.com/v3/__https://cacr.uwaterloo.ca/hac/__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3zKZgFV8g$ > >> > > >> > > >> 15) <!--[rfced] The following text in Appendices C.3, D.3, and D.6 are > > >> not complete > > >> sentences. Please review and let us know how these may be made into > > >> complete > > >> sentences. > > >> > > >> Original: > > >> POP fields for use (in signature field of pop field of > > >> ProofOfPossession structure) when proving possession of a private > > >> signing key that corresponds to a public verification key for which a > > >> certificate has been requested. > > >> ... > > >> Profile of how a certificate structure may be "self-signed". > > >> ... > > >> Creation of a single cross-certificate (i.e., not two at once). > > >> > > >> Perhaps: > > >> The table below describes the POP fields for use (in signature field of > > >> pop field of ProofOfPossession structure) when proving possession of a > > >> private signing key that corresponds to a public verification key for > > >> which a certificate has been requested. > > >> ... > > >> The table below is a profile of how a certificate structure may be > > >> "self-signed". > > >> ... > > >> This section describes the creation of a single cross-certificate (i.e., > > >> not two at once). > > >> --> > > > > > > [HB] Thank you for these proposals. I like them. > > > > > >> > > >> > > >> 16) <!--[rfced] As "OPTIONALLY" is not a key word in BCP14, may we > > >> update this > > >> sentence to rephrase to use the key word "OPTIONAL"? > > >> > > >> Original: > > >> This transaction established the shared secret, the referenceNumber and > > >> OPTIONALLY the distinguished name used for both sender and subject > > >> name in the certificate template. > > >> > > >> Perhaps: > > >> This transaction established the shared secret, the referenceNumber, and > > >> an OPTIONAL distinguished name used for both the sender and subject > > >> name in the certificate template. > > >> --> > > > > > > [HB] You are right. This is not a key word. Let's use lower case letters. > > > NEW > > > This transaction established the shared secret, the referenceNumber, and > > > optionally the distinguished name used for both sender and subject > > > name in the certificate template. > > > > > >> > > >> > > >> 17) <!--[rfced] May we update the numbered listed in Appendix C.6 to be > > >> a bulleted > > >> list? This would reflect the bulleted list in Appendix C.5. > > >> > > >> Appendix C.5: > > >> * sender name SHOULD be present > > >> > > >> * protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY > > >> also be supported) in request, response, certConfirm, and > > >> PKIConfirm messages; > > >> ... > > >> > > >> Appendix C.6: > > >> 1. sender name SHOULD be present > > >> > > >> 2. protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY > > >> also be supported) in request, response, certConfirm, and > > >> PKIConfirm messages; > > >> ... > > >> --> > > > > > > [HB] Yes please do that. > > > > > >> > > >> > > >> 18) <!--[rfced] As the text preceding these figures and the titles of > > >> the figures are very > > >> similar, may we remove the preceding text to avoid redundancy? > > >> > > >> Original: > > >> Message Flow when the PKI entity has a KEM key pair and certificate: > > >> ... > > >> Figure 3: Message Flow when PKI entity has a KEM key pair > > >> > > >> > > >> Message Flow when the PKI entity knows that the PKI management entity > > >> uses a KEM key pair and has the authentic public key: > > >> ... > > >> Figure 4: Message Flow when the PKI entity knows that the PKI > > >> management entity uses a KEM key pair and has the authentic > > >> public key > > >> > > >> > > >> Message Flow when the PKI entity does not know that the PKI > > >> management entity uses a KEM key pair: > > >> ... > > >> Figure 5: Message Flow when the PKI entity does not know that the PKI > > >> management entity uses a KEM key pair > > >> --> > > > > > > [HB] Please go ahead, while using in the first case not "KEM key pair" > > > alone but "KEM key pair and certificate". > > > > > >> > > >> > > >> 19) <!--[rfced] We note that the following references have citations > > >> only in the ASN.1 > > >> module in Appendix F. In order to have a 1:1 matchup between the > > >> references section > > >> and the text, please review the text and let us know where a citation > > >> for each of the > > >> following may be included. > > >> > > >> Alternatively, a sentence can be added before the module stating that it > > >> refers to the > > >> following (and then list the citations). > > >> > > >> [RFC3629] > > >> [RFC6268] > > >> --> > > > > > > [HB] Pleas update Appendix F as follows: > > > OLD > > > The module contains those changes to the > > > normative ASN.1 module from Appendix F of [RFC4210] that were > > > specified in [RFC9480], as well as changes made in this document. > > > NEW > > > The module contains those changes to the > > > normative ASN.1 module from Appendix F of [RFC4210] that were > > > specified in [RFC9480], as well as changes made in this document. > > > This module makes reference to ASN.1 structures defined in [RFC6268], > > > as well as the UTF-8 encoding defined in [RFC3629]. > > > > > > > > >> > > >> > > >> 20) <!-- [rfced] Please review each artwork element and let us know if > > >> any should be > > >> marked as sourcecode (or another element) instead. > > >> > > >> We updated some artwork to sourcecode throughout the document. Please > > >> confirm > > >> that these are correct. > > >> > > >> In addition, please consider whether the "type" attribute of any > > >> sourcecode element > > >> should be set and/or has been set correctly. > > >> > > >> The current list of preferred values for "type" is available at > > > https://urldefense.com/v3/__https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3wVRJoMWA$. > >>> If the current list does not contain an applicable type, feel free to > >>> suggest additions for > > >> consideration. Note that it is also acceptable to leave the "type" > > >> attribute not set. > > >> --> > > > > > > [HB] I reviewed > > > <https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810.xml__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3wV9HfmPg$>and > > > propose the following changes. > > > > > > Section 5.1.3.4 after Figure 2; do not use sourcecode, please use plain > > > text. > > > Encapsulate(pk) -> (ct, ss) > > > ... > > > Decapsulate(ct, sk) -> (ss) > > > ... > > > KDF(ss, len, context)->(ssk) > > > ... > > > KDF(ss, len, context)->(ssk) > > > > > > Section 5.3.19.1 > > > Set the sourcecode element in this and all subsections of 5.3.19 to asn.1. > > > > > >> > > >> > > >> 21) <!-- [rfced] 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://urldefense.com/v3/__https://authors.ietf.org/en/rfcxml-vocabulary*aside__;Iw!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3wFK99b7A$). > >>> --> > > > > > > [HB] I do not see any note that must be tagged <aside>. > > > > > >> > > >> > > >> 22) <!--[rfced] Acronyms > > >> > > >> a) Both the expansion and the acronym for the following terms are used > > >> throughout > > >> the document. Would you like to update to using the expansion upon first > > >> usage and > > >> the acronym for the rest of the document? > > >> > > >> Certification Authority (CA) > > >> Certificate Management Protocol (CMP) > > >> Certificate Transparency (CT) > > >> Diffie-Hellman (DH) > > >> Distinguished Name (DN) > > >> End Entity (EE) > > >> extended key usage (EKU) > > >> Key Encapsulation Mechansim (KEM) > > >> Key Generation Authority (KGA) > > >> Local Registration Authority (LRA) > > >> Message Authentication Code (MAC) > > >> one-way function (OWF) > > >> Public Key Infrastructure (PKI) > > >> Proof-of-Possession (POP) > > >> Personal Security Environment (PSE) > > >> protocol version number (pvno) > > >> Registration Authority (RA) > > >> Trusted Execution Environment (TEE) > > >> > > >> b) FYI - We have added expansions for the following abbreviations per > > >> Section 3.6 of > > >> RFC 7322 ("RFC Style Guide"). Please review each expansion in the > > >> document > > >> carefully to ensure correctness. > > >> > > >> Initial Device Identifier (IDevID) > > >> Internet Key Exchange Protocol (IKE) > > >> Internet of Things (IoT) > > >> Lightweight Directory Access Protocol (LDAP) Organizational Unit (OU) > > >> --> > > > > > > [HB] Yes, please do. > > > As the acronym LRA is not used in the document, please remove this line. > > > > > >> > > >> > > >> 23) <!--[rfced] Terminology > > >> > > >> a) May we update the following terms to the form on the right for > > >> consistency? > > >> > > >> certification authority > Certification Authority registration > > >> authority > Registration > > >> Authority boot-strapping > bootstrapping key encapsulation mechanism > > > >> Key > > >> Encapsulation Mechanism off-line > offline on-line > online > > >> > > >> b) We note that the following terms are used inconsistently throughout > > >> the document. > > >> Please review and let us know if/how these terms may be made consistent. > > >> > > >> Protocol Encryption Key vs. protocl encryption key > > >> X.509v1 vs. X.509 v1 > > >> X.509v3 vs. X.509 v3 > > >> X.509v3 certificate vs. X.509v3 Certificate > > >> cross-cert* vs. cross cert* > > >> --> > > >> > > > > > > [HB] > > > a) Yes, please do. > > > > > > b) Please use the following: > > > protocol encryption key > > > X.509v1 > > > X.509v3 > > > X.509v3 certificate > > > cross-cert * (Please do not change the ASN.1 module.) > > > > > >> > > >> 24) <!-- [rfced] Please review the "Inclusive Language" portion of the > > >> online Style > > >> Guide > > >> https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3zRe_saTw$ > >>> 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. > > >> --> > > > > > > [HB] I do not see any need for further changes. > > > > > >> > > >> > > >> Thank you. > > >> > > >> RFC Editor > > >> > > >> > > >> On Jun 20, 2025, at 5:06 PM, rfc-edi...@rfc-editor.org wrote: > > >> > > >> *****IMPORTANT***** > > >> > > >> Updated 2025/06/20 > > >> > > >> 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://urldefense.com/v3/__https://www.rfc-/__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3yQjuEqKQ$ > >>> editor.org%2Ffaq%2F&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7 > > >> Cd25dca9b7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4addab42e1495d55a > > >> %7C1%7C0%7C638860614551309675%7CUnknown%7CTWFpbGZsb3d8eyJFbXB > > >> 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCI > > >> sIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=v%2FfFjv9cJJYNu9WUenH6OO > > >> %2BeHs9mPSs5TxzaRl%2FGOcQ%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://urldefense.com/v3/__https://trustee.ietf.or/__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3wvMegLOA$ > >>> g%2Flicense- > > >> info&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7Cd25dca9b7ada4b > > >> 54eb7908ddb05804ed%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6 > > >> 38860614551334722%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > > >> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D% > > >> 3D%7C0%7C%7C%7C&sdata=ypZMrC2pHXFDv4035ptPDCE5OQgiOeyNaAmjRT > > >> HWnhQ%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://urldefense.com/v3/__https://authors.ietf/__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3xnb53Egg$. > >>> org%2Frfcxml- > > >> vocabulary&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7Cd25dca9b > > >> 7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C > > >> 0%7C638860614551358701%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > > >> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ > > >> %3D%3D%7C0%7C%7C%7C&sdata=4KEKvd%2F9HcDmuK1H9u9SLkiZFp7R0PjB > > >> yXlrFebQ8B0%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://urldefense.com/v3/__https://mailarchive.i/__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3weKQu31Q$ > >>> etf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- > > >> 4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Chendrik.brockhaus%40siemens.com% > > >> 7Cd25dca9b7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4addab42e1495d55 > > >> a%7C1%7C0%7C638860614551381593%7CUnknown%7CTWFpbGZsb3d8eyJFbX > > >> B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbC > > >> IsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=W3nbLk6%2B4%2FLyd5eikaDm > > >> YcJ1rMZRpHFznRBvsQHXWNw%3D&reserved=0 > > >> > > >> * The archive itself: > > >> > > >> https://urldefense.com/v3/__https://mailarchive.i/__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3weKQu31Q$ > >>> etf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Chendrik.bro > > >> ckhaus%40siemens.com%7Cd25dca9b7ada4b54eb7908ddb05804ed%7C38ae3bcd > > >> 95794fd4addab42e1495d55a%7C1%7C0%7C638860614551407415%7CUnknown% > > >> 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX > > >> aW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cTD% > > >> 2FoCScXBBa%2B9G3QXMobdaAYaxyChjhkxXLApUmlrg%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://urldefense.com/v3/__https://www.rfc-/__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3yQjuEqKQ$ > >>> editor.org%2Fauthors%2Frfc9810.xml&data=05%7C02%7Chendrik.brockhaus%40s > > >> iemens.com%7Cd25dca9b7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4add > > >> ab42e1495d55a%7C1%7C0%7C638860614551432483%7CUnknown%7CTWFpbGZ > > >> sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > > >> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KaOYhlNHFMk5ZA > > >> HZxzbiozmnixhggqPfINdxPE8UDGg%3D&reserved=0 > > >> > > >> https://urldefense.com/v3/__https://www.rfc-/__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3yQjuEqKQ$ > >>> editor.org%2Fauthors%2Frfc9810.html&data=05%7C02%7Chendrik.brockhaus%40 > > >> siemens.com%7Cd25dca9b7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4ad > > >> dab42e1495d55a%7C1%7C0%7C638860614551448828%7CUnknown%7CTWFpbG > > >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk > > >> FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IuWYtynoq8I%2B > > >> Pgv328Iol28iRrml8cUzulftnr7unMs%3D&reserved=0 > > >> > > >> https://urldefense.com/v3/__https://www.rfc-/__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3yQjuEqKQ$ > >>> editor.org%2Fauthors%2Frfc9810.pdf&data=05%7C02%7Chendrik.brockhaus%40si > > >> emens.com%7Cd25dca9b7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4adda > > >> b42e1495d55a%7C1%7C0%7C638860614551465544%7CUnknown%7CTWFpbGZs > > >> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > > >> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DXx2eaB55FufB%2 > > >> F5pdV6p5H2keVC6C5RWwQf9g2oVITc%3D&reserved=0 > > >> > > >> https://urldefense.com/v3/__https://www.rfc-/__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3yQjuEqKQ$ > >>> editor.org%2Fauthors%2Frfc9810.txt&data=05%7C02%7Chendrik.brockhaus%40si > > >> emens.com%7Cd25dca9b7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4adda > > >> b42e1495d55a%7C1%7C0%7C638860614551481529%7CUnknown%7CTWFpbGZs > > >> b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > > >> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YwUasxMliK2BL1V > > >> GwRfgcM6X%2FMPLwE3SHwsAjUVFXBM%3D&reserved=0 > > >> > > >> Diff file of the text: > > >> > > >> https://urldefense.com/v3/__https://www.rfc-/__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3yQjuEqKQ$ > >>> editor.org%2Fauthors%2Frfc9810- > > >> diff.html&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7Cd25dca9b7a > > >> da4b54eb7908ddb05804ed%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0% > > >> 7C638860614551496675%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > > >> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 > > >> D%3D%7C0%7C%7C%7C&sdata=UGE071%2B6EDvQWedVY3hAAOCo80bcXNdg > > >> QNdRHJ1JvdQ%3D&reserved=0 > > >> > > >> https://urldefense.com/v3/__https://www.rfc-/__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3yQjuEqKQ$ > >>> editor.org%2Fauthors%2Frfc9810- > > >> rfcdiff.html&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7Cd25dca9b > > >> 7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C > > >> 0%7C638860614551511934%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > > >> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ > > >> %3D%3D%7C0%7C%7C%7C&sdata=BRV2ZGaAlsjhLKTkmxoI%2Bc7IvBUtB7aCn > > >> J5hdXbzg8g%3D&reserved=0 (side by side) > > >> > > >> Diff of the XML: > > >> > > >> https://urldefense.com/v3/__https://www.rfc-/__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3yQjuEqKQ$ > >>> editor.org%2Fauthors%2Frfc9810- > > >> xmldiff1.html&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7Cd25dca > > >> 9b7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7 > > >> C0%7C638860614551532795%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG > > >> kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf > > >> Q%3D%3D%7C0%7C%7C%7C&sdata=nwoPdp3qSCaj8Eh8jLjWsBYnth60Qtt4AdP > > >> CxBx7wU8%3D&reserved=0 > > >> > > >> > > >> Tracking progress > > >> ----------------- > > >> > > >> The details of the AUTH48 status of your document are here: > > >> > > >> https://urldefense.com/v3/__https://www.rfc-/__;!!FJ-Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTlNKOJbWpkQOaqJrwSG3xa0ndDx3yQjuEqKQ$ > >>> editor.org%2Fauth48%2Frfc9810&data=05%7C02%7Chendrik.brockhaus%40sieme > > >> ns.com%7Cd25dca9b7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4addab42 > > >> e1495d55a%7C1%7C0%7C638860614551554676%7CUnknown%7CTWFpbGZsb3d > > >> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > > >> TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZhCuyKv%2BPSRvvwty > > >> Rq0URqdUIkO%2FIoSLxuSNYchsOeo%3D&reserved=0 > > >> > > >> Please let us know if you have any questions. > > >> > > >> Thank you for your cooperation, > > >> > > >> RFC Editor > > >> > > >> -------------------------------------- > > >> RFC 9810 (draft-ietf-lamps-rfc4210bis-18) > > >> > > >> Title : Internet X.509 Public Key Infrastructure -- > > >> Certificate Management > > >> Protocol (CMP) > > >> Author(s) : H. Brockhaus, D. von Oheimb, M. Ounsworth, J. Gray > > >> WG Chair(s) : Russ Housley, Tim Hollebeek > > >> Area Director(s) : Deb Cooley, Paul Wouters > > > > > > > > Any email and files/attachments transmitted with it are intended solely for > > the use of the individual or entity to whom they are addressed. If this > > message has been sent to you in error, you must not copy, distribute or > > disclose of the information it contains. Please notify Entrust immediately > > and delete the message from your system. > > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org