Those two changes look fine to me. Deb
On Thu, Jul 10, 2025 at 11:52 AM Alanna Paloma <[email protected]> wrote: > 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://www.rfc-editor.org/authors/rfc9810-ad-diff.html > > > 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://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) > > 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://www.rfc-editor.org/auth48/rfc9810 > > Thank you, > RFC Editor/ap > > > On Jul 9, 2025, at 3:33 AM, Brockhaus, Hendrik <hendrik.brockhaus= > [email protected]> 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://www.rfc-editor.org/authors/rfc9810-diff.html 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: [email protected] <[email protected]> > >> Gesendet: Samstag, 21. Juni 2025 02:10 > >> An: Brockhaus, Hendrik (FT RPD CST SEA-DE) > >> <[email protected]>; von Oheimb, David (FT RPD CST SEA-DE) > >> <[email protected]>; [email protected]; > >> [email protected] > >> Cc: [email protected]; [email protected]; > [email protected]; > >> [email protected]; [email protected]; > [email protected] > >> 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://www.rfc-editor.org/authors/rfc9810-diff.html>, 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://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. > >> --> > >> > > > > [HB] This is a great idea. I was not aware of this link. > > BTW, it is sufficient to use https://cacr.uwaterloo.ca/hac/ > > > >> > >> 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://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. > >> --> > > > > [HB] I reviewed <https://www.rfc-editor.org/authors/rfc9810.xml> 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://authors.ietf.org/en/rfcxml-vocabulary#aside). > >> --> > > > > [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://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. > >> --> > > > > [HB] I do not see any need for further changes. > > > >> > >> > >> Thank you. > >> > >> RFC Editor > >> > >> > >> On Jun 20, 2025, at 5:06 PM, [email protected] 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%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://trustee.ietf.or/ > >> 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://authors.ietf/. > >> 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 > >> > >> * [email protected] (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). > >> > >> * [email protected], which is a new archival mailing list > >> to preserve AUTH48 conversations; it is not an active discussion > >> list: > >> > >> * More info: > >> > >> https://mailarchive.i/ > >> 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://mailarchive.i/ > >> 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, > >> [email protected] 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%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://www.rfc-/ > >> 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://www.rfc-/ > >> 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://www.rfc-/ > >> 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://www.rfc-/ > >> 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://www.rfc-/ > >> 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://www.rfc-/ > >> 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://www.rfc-/ > >> 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 > > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
