Hi Authors, This is another friendly reminder that we await your word regarding this document's readiness for publication. Please see our previous messages describing the AUTH48 process and containing our document-specific questions.
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 27, 2025, at 9:02 AM, Mike Ounsworth <mike.ounswo...@entrust.com> > wrote: > > Sorry, yes. It’s been a busy week and I normally do my IETF work on weekends. > I’ll give a proper response to this before Monday, I promise. > --- > Mike Ounsworth > From: Alanna Paloma <apal...@staff.rfc-editor.org> > Sent: Friday, June 27, 2025 10:57 AM > To: Brockhaus, Hendrik <hendrik.brockh...@siemens.com>; 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; lamps-...@ietf.org; lamps-cha...@ietf.org; > Russ Housley <hous...@vigilsec.com>; Deb Cooley <debcool...@gmail.com>; > auth48archive <auth48archive@rfc-editor.org> > Subject: [EXTERNAL] Re: AUTH48: RFC-to-be 9810 > <draft-ietf-lamps-rfc4210bis-18> for your review > 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 willGreetings, > > 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://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9810__;!!FJ-Y8qCqXTj2!YgYHaVCny7IrpV5_ImlWgyxHPWHaGrB4wfKErGTON5dS2YFX76uOb9dFjBXWlyQAuJ2FmWkA1wdswvSLvIvmTt5YrwGq8A$ > > 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://urldefense.com/v3/__https://cacr.uwaterloo.ca/hac/index.html__;!!FJ-Y8qCqXTj2!YgYHaVCny7IrpV5_ImlWgyxHPWHaGrB4wfKErGTON5dS2YFX76uOb9dFjBXWlyQAuJ2FmWkA1wdswvSLvIvmTt7LddLIBw$ > > 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://urldefense.com/v3/__https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types__;!!FJ-Y8qCqXTj2!YgYHaVCny7IrpV5_ImlWgyxHPWHaGrB4wfKErGTON5dS2YFX76uOb9dFjBXWlyQAuJ2FmWkA1wdswvSLvIvmTt701q0dRA$>. > > 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://urldefense.com/v3/__https://authors.ietf.org/en/rfcxml-vocabulary*aside__;Iw!!FJ-Y8qCqXTj2!YgYHaVCny7IrpV5_ImlWgyxHPWHaGrB4wfKErGTON5dS2YFX76uOb9dFjBXWlyQAuJ2FmWkA1wdswvSLvIvmTt5_Q1jgZQ$). > > --> > > > > > > 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://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!FJ-Y8qCqXTj2!YgYHaVCny7IrpV5_ImlWgyxHPWHaGrB4wfKErGTON5dS2YFX76uOb9dFjBXWlyQAuJ2FmWkA1wdswvSLvIvmTt74G6GJFg$> > > 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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!FJ-Y8qCqXTj2!YgYHaVCny7IrpV5_ImlWgyxHPWHaGrB4wfKErGTON5dS2YFX76uOb9dFjBXWlyQAuJ2FmWkA1wdswvSLvIvmTt4Z36Slcw$). > > > > 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.org/license-info__;!!FJ-Y8qCqXTj2!YgYHaVCny7IrpV5_ImlWgyxHPWHaGrB4wfKErGTON5dS2YFX76uOb9dFjBXWlyQAuJ2FmWkA1wdswvSLvIvmTt4z8EOJWg$). > > > > * 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.org/rfcxml-vocabulary__;!!FJ-Y8qCqXTj2!YgYHaVCny7IrpV5_ImlWgyxHPWHaGrB4wfKErGTON5dS2YFX76uOb9dFjBXWlyQAuJ2FmWkA1wdswvSLvIvmTt537dv_3g$>. > > > > * 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.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!FJ-Y8qCqXTj2!YgYHaVCny7IrpV5_ImlWgyxHPWHaGrB4wfKErGTON5dS2YFX76uOb9dFjBXWlyQAuJ2FmWkA1wdswvSLvIvmTt4WZcR4QA$ > > > > * The archive itself: > > > > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!FJ-Y8qCqXTj2!YgYHaVCny7IrpV5_ImlWgyxHPWHaGrB4wfKErGTON5dS2YFX76uOb9dFjBXWlyQAuJ2FmWkA1wdswvSLvIvmTt4AXB6B-w$ > > > > * 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-editor.org/authors/rfc9810.xml__;!!FJ-Y8qCqXTj2!YgYHaVCny7IrpV5_ImlWgyxHPWHaGrB4wfKErGTON5dS2YFX76uOb9dFjBXWlyQAuJ2FmWkA1wdswvSLvIvmTt56I9pXAA$ > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810.html__;!!FJ-Y8qCqXTj2!YgYHaVCny7IrpV5_ImlWgyxHPWHaGrB4wfKErGTON5dS2YFX76uOb9dFjBXWlyQAuJ2FmWkA1wdswvSLvIvmTt4F9wsmDA$ > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810.pdf__;!!FJ-Y8qCqXTj2!YgYHaVCny7IrpV5_ImlWgyxHPWHaGrB4wfKErGTON5dS2YFX76uOb9dFjBXWlyQAuJ2FmWkA1wdswvSLvIvmTt6TRwlVog$ > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810.txt__;!!FJ-Y8qCqXTj2!YgYHaVCny7IrpV5_ImlWgyxHPWHaGrB4wfKErGTON5dS2YFX76uOb9dFjBXWlyQAuJ2FmWkA1wdswvSLvIvmTt7sUxacRw$ > > > > Diff file of the text: > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810-diff.html__;!!FJ-Y8qCqXTj2!YgYHaVCny7IrpV5_ImlWgyxHPWHaGrB4wfKErGTON5dS2YFX76uOb9dFjBXWlyQAuJ2FmWkA1wdswvSLvIvmTt5eeAb4Ww$ > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810-rfcdiff.html__;!!FJ-Y8qCqXTj2!YgYHaVCny7IrpV5_ImlWgyxHPWHaGrB4wfKErGTON5dS2YFX76uOb9dFjBXWlyQAuJ2FmWkA1wdswvSLvIvmTt5jpMbh5g$ > > (side by side) > > > > Diff of the XML: > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9810-xmldiff1.html__;!!FJ-Y8qCqXTj2!YgYHaVCny7IrpV5_ImlWgyxHPWHaGrB4wfKErGTON5dS2YFX76uOb9dFjBXWlyQAuJ2FmWkA1wdswvSLvIvmTt7LOTrphA$ > > > > > > Tracking progress > > ----------------- > > > > The details of the AUTH48 status of your document are here: > > > > https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9810__;!!FJ-Y8qCqXTj2!YgYHaVCny7IrpV5_ImlWgyxHPWHaGrB4wfKErGTON5dS2YFX76uOb9dFjBXWlyQAuJ2FmWkA1wdswvSLvIvmTt5YrwGq8A$ > > > > 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
