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

Reply via email to