Greetings, We do not believe we have heard from you regarding this document's readiness for publication. Please review our previous messages describing the AUTH48 process and containing any document-specific questions we may have had.
We will wait to hear from you before continuing with the publication process. The AUTH48 status page for this document is located here: https://www.rfc-editor.org/auth48/rfc9810 Thank you, RFC Editor/ap > On Jun 20, 2025, at 5:10 PM, rfc-edi...@rfc-editor.org wrote: > > Authors, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the XML file. > > 1) <!-- [rfced] 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. > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 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: > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 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. > --> > > > 13) <!-- [rfced] Would you like the references to be alphabetized or left > in their current order? > --> > > > 14) <!-- [rfced] Please review. We found the following URL: > https://cacr.uwaterloo.ca/hac/index.html 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. > --> > > > 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). > --> > > > 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. > --> > > > 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; > ... > --> > > > 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 > --> > > > 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] > --> > > > 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://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. > 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. > --> > > > 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://authors.ietf.org/en/rfcxml-vocabulary#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) > --> > > > 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* > --> > > > 24) <!-- [rfced] Please review the "Inclusive Language" portion of the > online Style Guide > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this nature > typically result in more precise language, which is helpful for readers. > > Note that our script did not flag any words in particular, but this should > still be reviewed as a best practice. > --> > > > Thank you. > > RFC Editor > > > 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://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing > your approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP – https://trustee.ietf.org/license-info). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * rfc-edi...@rfc-editor.org (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * auth48archive@rfc-editor.org, which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > auth48archive@rfc-editor.org will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, > and technical changes. Information about stream managers can be found in > the FAQ. Editorial changes do not require approval from a stream manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, > as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9810.xml > https://www.rfc-editor.org/authors/rfc9810.html > https://www.rfc-editor.org/authors/rfc9810.pdf > https://www.rfc-editor.org/authors/rfc9810.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9810-diff.html > https://www.rfc-editor.org/authors/rfc9810-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9810-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9810 > > 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 > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
