Hi If I understand the emails going back and forth on Friday correct, we agreed on the changes I proposed in my Email below including David's proposal on Section 5.2.1.
Hendrik >-----Ursprüngliche Nachricht----- >Von: Brockhaus, Hendrik (FT RPD CST SEA-DE) >Gesendet: Freitag, 11. Juli 2025 14:38 >An: Alanna Paloma <apal...@staff.rfc-editor.org>; John Gray ><john.g...@entrust.com>; von Oheimb, David (FT RPD CST SEA-DE) ><david.von.ohe...@siemens.com>; Mike Ounsworth ><mike.ounswo...@entrust.com> >Cc: debcool...@gmail.com; rfc-edi...@rfc-editor.org; lamps-...@ietf.org; lamps- >cha...@ietf.org; hous...@vigilsec.com; auth48archive@rfc-editor.org >Betreff: AW: [EXTERNAL] [AD] Re: AUTH48: RFC-to-be 9810 <draft-ietf-lamps- >rfc4210bis-18> for your review > >Alanna > >Thank you for providing this update. >I took a close look at the diff https://www.rfc-editor.org/authors/rfc9810- >auth48diff.html >I have the following final proposals if my coauthors agree. > >The abbreviation pvno is not introduced in Section 2 and I support that. It is >basically not an abbreviation but an ASN.1 filed name. To differentiate between >‘protocol version number’, a concrete pvno value, and the pvno field I propose >the >following changes: >Sections 5.2.2, 5.2.8.3, and 5.3.13 >OLD > Details on the usage of the pvno are described in > Section 7. >NEW > Details on the usage of the protocol version number > are described in Section 7. >Section 7 >OLD > Note: Using cmp2000 as the default pvno is done to avoid extra > message exchanges for version negotiation and to foster compatibility > with cmp2000 implementations. >NEW > Note: Using cmp2000 as the default pvno value is done to avoid extra > message exchanges for version negotiation and to foster compatibility > with cmp2000 implementations. >Section 7.1.1 >OLD > If, after sending a message with a pvno higher than cmp1999, a client > receives an ErrorMsgContent with a version of cmp1999, then it MUST > abort the current transaction. >NEW > If, after sending a message with a pvno value higher than cmp1999, a > client receives an ErrorMsgContent with a version of cmp1999, then it > MUST abort the current transaction. >Appendix C.1 >OLD > The pvno MUST be set as specified in Section 7). >NEW > The protocol version number MUST be set as specified in Section 7. > > >You changed from ‘end entity’ to ‘EE’. Below you find some remaining places >where >'end entity' could be replaced. >Section 3.1.3 >OLD > | | <--------------------- | End Entity | <------- >NEW > | | <--------------------- | EE | <-------------- >Section 4.2.2.2. >OLD > End entity RA/CA > ========== ============= >NEW > EE RA/CA > ========== ============= >Appendix C.4 >OLD > Step# End entity PKI >NEW > Step# EE PKI >Appendix D.5 >OLD > Step# End entity PKI >NEW > Step# EE PKI > > >Here are some minor fixes I would like to propose. >Section 3.1.3 >OLD > various environments (e.g., offline: file-based; online: mail, HTTP >NEW > various environments (e.g., offline: file-based; online: email, HTTP >Section 5.1.3.4, can you indent the four line by two characters. >OLD > Encapsulate(pk) -> (ct, ss) >... > Decapsulate(ct, sk) -> (ss) >... > KDF(ss, len, context)->(ssk) >... > KDF(ss, len, context)->(ssk) >NEW > Encapsulate(pk) -> (ct, ss) >... > Decapsulate(ct, sk) -> (ss) >... > KDF(ss, len, context)->(ssk) >... > KDF(ss, len, context)->(ssk) > >Section 5.2.1, I support David’s proposal. >OLD > The CertTemplate structure allows an EE or RA to > specify as many data fields as the structure wishes for the requested > certificate. The structure also allows an EE 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 [RFC5280]) but with all fields > optional/situational. [HB] Added David's final proposal. NEW The CertTemplate structure allows entities requesting a certificate to specify the data fields that they want to be included. Typically, they are required to provide at least the publicKey field. A CertTemplate structure is identical to a TBSCertificate structure (see [RFC 5280]) but with all fields optional/situational. >Section 6.6.1 >OLD > This is done by generating a symmetric key based on the > authorization code and using the symmetric key for generating > MACs) on all messages exchanged. >NEW > This is done by generating a symmetric key based on the > authorization code and using the symmetric key for generating > MACs on all messages exchanged. > > >Hendrik > >>-----Ursprüngliche Nachricht----- >>Von: Alanna Paloma <apal...@staff.rfc-editor.org> >>Gesendet: Donnerstag, 10. Juli 2025 23:16 >>An: John Gray <john.g...@entrust.com> >>Cc: debcool...@gmail.com; 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 Ounsworth >><mike.ounswo...@entrust.com>; rfc-edi...@rfc-editor.org; lamps-...@ietf.org; >>lamps-cha...@ietf.org; hous...@vigilsec.com; auth48archive@rfc-editor.org >>Betreff: Re: [EXTERNAL] [AD] Re: AUTH48: RFC-to-be 9810 <draft-ietf-lamps- >>rfc4210bis-18> for your review >> >>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%2Fauthors%2Frfc9810.txt&data=05%7C02%7Chendrik.brockhaus%40s >iem >>ens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4addab42 >e14 >>95d55a%7C1%7C0%7C638877790756055380%7CUnknown%7CTWFpbGZsb3d8e >yJF >>bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF >pbC >>IsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=S2NpSsG6z0LtBwRwXs% >2F >>MwU2VXQbzQ%2Fhs438l30O8JI8%3D&reserved=0 >>https://www.rfc-/ >>editor.org%2Fauthors%2Frfc9810.pdf&data=05%7C02%7Chendrik.brockhaus%40 >sie >>mens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4addab4 >2e1 >>495d55a%7C1%7C0%7C638877790756103392%7CUnknown%7CTWFpbGZsb3d8 >eyJ >>FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW >Fpb >>CIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=tfXaayc%2BlOp5z%2Bn2 >AX >>LuMcn26li3IZnCDVfX0nK5PWg%3D&reserved=0 >>https://www.rfc-/ >>editor.org%2Fauthors%2Frfc9810.html&data=05%7C02%7Chendrik.brockhaus%4 >0sie >>mens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4addab4 >2e1 >>495d55a%7C1%7C0%7C638877790756133357%7CUnknown%7CTWFpbGZsb3d8 >eyJ >>FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW >Fpb >>CIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=bRacv5RAs9W9Cazk%2 >Bu8 >>hvM4DdsI1ZhL804s4JbpR%2B3g%3D&reserved=0 >>https://www.rfc-/ >>editor.org%2Fauthors%2Frfc9810.xml&data=05%7C02%7Chendrik.brockhaus%40 >sie >>mens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4addab4 >2e1 >>495d55a%7C1%7C0%7C638877790756155919%7CUnknown%7CTWFpbGZsb3d8 >eyJ >>FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW >Fpb >>CIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=mDEdK020OnfOChAiqXa >jV9 >>oM5pjwdnAPgV88Ux0UahQ%3D&reserved=0 >> >>The relevant diff files are posted here: >>https://www.rfc-/ >>editor.org%2Fauthors%2Frfc9810- >>diff.html&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C0dd94ff63e >0a4 >>7ecdbed08ddbff70c69%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C >638 >>877790756177065%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd >WUsI >>lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D% >7C6 >>0000%7C%7C%7C&sdata=r4zABxR3wg4QUg%2BBw5mc65noqpmVbLigvlLZPsz >SN9 >>0%3D&reserved=0 (comprehensive diff) >>https://www.rfc-/ >>editor.org%2Fauthors%2Frfc9810- >>auth48diff.html&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C0dd9 >4ff6 >>3e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C >0%7 >>C638877790756196029%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn >Ryd >>WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D >%3D >>%7C60000%7C%7C%7C&sdata=bmYOiu0i%2BhqfU9ivPvSKO0ILKaj%2B30%2F >YT1 >>pRsDCWi6k%3D&reserved=0 (all AUTH48 changes) >>https://www.rfc-/ >>editor.org%2Fauthors%2Frfc9810- >>auth48rfcdiff.html&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C0d >d94 >>ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7 >C0 >>%7C638877790756214570%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki >On >>RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% >3D >>%3D%7C60000%7C%7C%7C&sdata=xh5weZO%2B0lZ0R6dfJOGdCykUbo4QLX4 >KM >>Wdow4hT5O0%3D&reserved=0 (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-editor@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 >>%2Fv3%2F__https%3A%2F%2Fwww.rfc- >>editor.org%2Fauthors%2Frfc9810.txt__%3B!!FJ- >>Y8qCqXTj2!bXrlG1IXABCRn7pLgU1MtD1k2kJ7iEbtFjY_XaaXiHbAsKIGwNDvltLJV >d5 >>osfPCr_dVa5HKOCVzagAeUhAZLN09tA%24&data=05%7C02%7Chendrik.brockha >us >>%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4 >add >>ab42e1495d55a%7C1%7C0%7C638877790756234085%7CUnknown%7CTWFpbG >Zsb >>3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >OIjoi >>TWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=8tkrq39EDsph4Hk >I13 >>nqPElKc2mtbPqsOwdnVXCi7Ko%3D&reserved=0 >>> >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc- >>editor.org%2Fauthors%2Frfc9810.pdf__%3B!!FJ- >>Y8qCqXTj2!bXrlG1IXABCRn7pLgU1MtD1k2kJ7iEbtFjY_XaaXiHbAsKIGwNDvltLJV >d5 >>osfPCr_dVa5HKOCVzagAeUhDbDiHL1Q%24&data=05%7C02%7Chendrik.brockh >aus >>%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4 >add >>ab42e1495d55a%7C1%7C0%7C638877790756253480%7CUnknown%7CTWFpbG >Zsb >>3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >OIjoi >>TWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=0EwYvqAYSe9xP >41D >>ozH%2Fg%2Boo4%2F8EYzSoLkV1%2BHY7AXA%3D&reserved=0 >>> >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc- >>editor.org%2Fauthors%2Frfc9810.html__%3B!!FJ- >>Y8qCqXTj2!bXrlG1IXABCRn7pLgU1MtD1k2kJ7iEbtFjY_XaaXiHbAsKIGwNDvltLJV >d5 >>osfPCr_dVa5HKOCVzagAeUhCj8eRoGQ%24&data=05%7C02%7Chendrik.brockh >aus >>%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4 >add >>ab42e1495d55a%7C1%7C0%7C638877790756272895%7CUnknown%7CTWFpbG >Zsb >>3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >OIjoi >>TWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=6TywVtqiTvLp%2 >Bcw >>8L4ERhOjDSgZj9ibItStpYblzIbc%3D&reserved=0 >>> >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc- >>editor.org%2Fauthors%2Frfc9810.xml__%3B!!FJ- >>Y8qCqXTj2!bXrlG1IXABCRn7pLgU1MtD1k2kJ7iEbtFjY_XaaXiHbAsKIGwNDvltLJV >d5 >>osfPCr_dVa5HKOCVzagAeUhC4AtGOwg%24&data=05%7C02%7Chendrik.brockh >aus >>%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4 >add >>ab42e1495d55a%7C1%7C0%7C638877790756292982%7CUnknown%7CTWFpbG >Zsb >>3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >OIjoi >>TWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=yeTNIHbN1p1Sb >mea >>eu1etDjm2j6sbQcrodTwQjbK52c%3D&reserved=0 >>> >>> The relevant diff files are posted here: >>> >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9810- >>diff.html__%3B!!FJ- >>Y8qCqXTj2!bXrlG1IXABCRn7pLgU1MtD1k2kJ7iEbtFjY_XaaXiHbAsKIGwNDvltLJV >d5 >>osfPCr_dVa5HKOCVzagAeUhAC4Nr_wg%24&data=05%7C02%7Chendrik.brockh >aus >>%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4 >add >>ab42e1495d55a%7C1%7C0%7C638877790756313124%7CUnknown%7CTWFpbG >Zsb >>3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >OIjoi >>TWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=wm0rPGtGPuYU0 >7V >>VA3%2BGRz3v8RadjW%2BAK0onMFlTWYU%3D&reserved=0 (comprehensive >diff) >>> >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9810- >>auth48diff.html__%3B!!FJ- >>Y8qCqXTj2!bXrlG1IXABCRn7pLgU1MtD1k2kJ7iEbtFjY_XaaXiHbAsKIGwNDvltLJV >d5 >>osfPCr_dVa5HKOCVzagAeUhCj0k_R2Q%24&data=05%7C02%7Chendrik.brockh >aus >>%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4 >add >>ab42e1495d55a%7C1%7C0%7C638877790756332804%7CUnknown%7CTWFpbG >Zsb >>3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >OIjoi >>TWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=WlL6iRoy1tabOux >Lo >>%2FDz5U6LEB2t%2BvbKXddlOXVTUqo%3D&reserved=0 (all AUTH48 changes) >>> >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9810- >>auth48rfcdiff.html__%3B!!FJ- >>Y8qCqXTj2!bXrlG1IXABCRn7pLgU1MtD1k2kJ7iEbtFjY_XaaXiHbAsKIGwNDvltLJV >d5 >>osfPCr_dVa5HKOCVzagAeUhB9PiDdIA%24&data=05%7C02%7Chendrik.brockha >us >>%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4 >add >>ab42e1495d55a%7C1%7C0%7C638877790756351714%7CUnknown%7CTWFpbG >Zsb >>3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >OIjoi >>TWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=xomqj7rC4x1Hns >T4U >>6YDkiF6%2BzZM%2BW4z8%2BM8A34ro68%3D&reserved=0 (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 >>%2Fv3%2F__https%3A%2F%2Fwww.rfc- >>editor.org%2Fauth48%2Frfc9810__%3B!!FJ- >>Y8qCqXTj2!bXrlG1IXABCRn7pLgU1MtD1k2kJ7iEbtFjY_XaaXiHbAsKIGwNDvltLJV >d5 >>osfPCr_dVa5HKOCVzagAeUhArr- >>tV2w%24&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C0dd94ff63 >e0a >>47ecdbed08ddbff70c69%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7 >C63 >>8877790756370839%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd >WU >>sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D >%7 >>C60000%7C%7C%7C&sdata=qTukJ%2BEhwJgcK4pXxjeHCfhn41%2Bhs%2F5%2 >Fa >>cnxg2mhKCc%3D&reserved=0 >>> >>> 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 >>%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9810-ad- >>diff.html__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3wB0AtxDw%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756391415%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=l4A5cNFoTHk9r >2m >>PoEKq4na9dcT5kiOZn1y4DkgZgAE%3D&reserved=0 >>> > >>> > >>> > 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 >>%2Fv3%2F__https%3A%2F%2Fwww.rfc- >>editor.org%2Fauthors%2Frfc9810.txt__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3wZYZ8gbQ%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756411618%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=UkiC6F6Ga7E >%2F >>RkeZDuaZzlvb20H6Xync875eQgQJjeU%3D&reserved=0 >>> > >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc- >>editor.org%2Fauthors%2Frfc9810.pdf__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3zN3_ROSg%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756430564%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=6%2BNMCniT5 >6eE >>ZdpsxL%2FT03nFP75I%2FSk%2F3mrqUD%2B5CNA%3D&reserved=0 >>> > >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc- >>editor.org%2Fauthors%2Frfc9810.html__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3wu0CLetQ%24&data=05%7C02%7Chendrik.broc >khau >>s%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd >4ad >>dab42e1495d55a%7C1%7C0%7C638877790756449870%7CUnknown%7CTWFpb >GZs >>b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOIj >>oiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=SDKBOUGQSrT >ZB >>1GQYEBQ6ECy5Kk94Jw18pjr5E%2FUxFo%3D&reserved=0 >>> > >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc- >>editor.org%2Fauthors%2Frfc9810.xml__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3wV9HfmPg%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756470523%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=fZT2fFPed4pYD >A4t >>t6%2F2gh5THEcmqybo6Do8eoiatcg%3D&reserved=0 >>> > >>> > The relevant diff files are posted here: >>> > >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9810- >>diff.html__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3zURljmmA%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756492436%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=rsWZA6lLMPX >WInl >>27z3XD%2BepWetVsi34dGCuH6EIRKw%3D&reserved=0(comprehensive diff) >>> > >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9810- >>auth48diff.html__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3zey24sgA%24&data=05%7C02%7Chendrik.brock >hau >>s%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd >4ad >>dab42e1495d55a%7C1%7C0%7C638877790756517929%7CUnknown%7CTWFpb >GZs >>b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOIj >>oiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=dKHGs57H7W% >2B >>TGihkddlMFCTdifKNd3nOUgXhlDbr4wQ%3D&reserved=0(all AUTH48 changes) >>> > >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9810- >>auth48rfcdiff.html__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3wGtPR5Tg%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756538868%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=fS2D0YKTHqj0 >F5a >>dyX52AlJhnhRrRca%2BxiwqhVVgAIU%3D&reserved=0(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 >>%2Fv3%2F__https%3A%2F%2Fwww.rfc- >>editor.org%2Fauth48%2Frfc9810__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3w- >>JXp6ug%24&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7C0dd94ff >63e >>0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0% >7C >>638877790756560428%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR >ydW >>UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 >D% >>7C60000%7C%7C%7C&sdata=uowyeBqz8pLkpgR36meVaXlEOJ6u7%2BglED7Q >FGl >>3vKc%3D&reserved=0 >>> > >>> > 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 >>%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9810- >>diff.html__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3zURljmmA%24I&data=05%7C02%7Chendrik.bro >ckha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756580202%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=aAZknvDtNsW5 >%2 >>F1379H%2FA0fYtTzGdy%2Byu3ACjKVal3gI%3D&reserved=0 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/ >.co >>m%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9810- >>diff.html__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3zURljmmA%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756600102%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=VpTpE7ZKI5U3 >CC >>OlAZC9x%2FeUso9HuLoCnPZSGr6aecw%3D&reserved=0>,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 >>%2Fv3%2F__https%3A%2F%2Fcacr.uwaterloo.ca%2Fhac%2Findex.html__%3B!! >FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3zKQld8tw%24which&data=05%7C02%7Chendrik. >broc >>khaus%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95 >794f >>d4addab42e1495d55a%7C1%7C0%7C638877790756619696%7CUnknown%7CT >WFp >>bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zM >iIsI >>kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=OjfYLQMk >9% >>2FvU4lv9MDoM%2BI0UlVaO6AiTII4sb2q8OY4%3D&reserved=0 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 >>%2Fv3%2F__https%3A%2F%2Fcacr.uwaterloo.ca%2Fhac%2F__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3zKZgFV8g%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756641536%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=X3V0Rq8NGrJ >WU1 >>Sai33kb6qJsrbTEHp6xWZfqVl3u84%3D&reserved=0 >>> >> >>> > >> >>> > >> 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 >>%2Fv3%2F__https%3A%2F%2Fwww.rfc- >>editor.org%2Frpc%2Fwiki%2Fdoku.php%3Fid%3Dsourcecode-types__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3wVRJoMWA%24&data=05%7C02%7Chendrik.bro >ckh >>aus%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd9579 >4fd4 >>addab42e1495d55a%7C1%7C0%7C638877790756662931%7CUnknown%7CTWF >pbG >>Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >IkF >>OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=chBQyNyqHI >Ge >>N34sjskQvqcfi90rgxSnYsz3RqlSVrg%3D&reserved=0. >>> >>> 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/ >.co >>m%2Fv3%2F__https%3A%2F%2Fwww.rfc- >>editor.org%2Fauthors%2Frfc9810.xml__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3wV9HfmPg%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756684507%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=g7vg1IByHrO% >2Fe >>Ewfi2MQVFcQ%2FfWv3yvf5AlO%2FHOEIkM%3D&reserved=0>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/. >co >>m%2Fv3%2F__https%3A%2F%2Fauthors.ietf.org%2Fen%2Frfcxml- >>vocabulary*aside__%3BIw!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3wFK99b7A%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756706198%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=tk6TvxZ%2F%2 >Be >>cuFz2Vb45NAzLVa4H3veH0u18MM2HHG70%3D&reserved=0). >>> >>> --> >>> > > >>> > > [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 >>%2Fv3%2F__https%3A%2F%2Fwww.rfc- >>editor.org%2Fstyleguide%2Fpart2%2F*inclusive_language__%3BIw!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3zRe_saTw%24&data=05%7C02%7Chendrik.broc >khau >>s%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd >4ad >>dab42e1495d55a%7C1%7C0%7C638877790756726961%7CUnknown%7CTWFpb >GZs >>b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOIj >>oiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=cprq7pdgr0wpqt >wYB >>Zbo7j%2F9CAHU3e25rx4WpKM7E0w%3D&reserved=0 >>> >>> 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/. >co >>m%2Fv3%2F__https%3A%2F%2Fwww.rfc-%2F__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3yQjuEqKQ%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756746788%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=4qt2VhqfZuEqq >zlN >>gpa%2B5xPlTyrb1T1B3TD9qqmNdIk%3D&reserved=0 >>> >>> >>editor.org%2Ffaq%2F&data=05%7C02%7Chendrik.brockhaus%40siemens.com% >7 >>> > >> >>Cd25dca9b7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4addab42e1495d55 >a >>> > >> >>%7C1%7C0%7C638860614551309675%7CUnknown%7CTWFpbGZsb3d8eyJFbX >B >>> > >> >>0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbC >I >>> > >> >>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 >>%2Fv3%2F__https%3A%2F%2Ftrustee.ietf.or%2F__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3wvMegLOA%24&data=05%7C02%7Chendrik.bro >ckha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756766839%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=GkZrJt6KfYh7T >kC >>Hk4htZFVNwhPw1Z1eSyTndOSdmv0%3D&reserved=0 >>> >>> g%2Flicense- >>> > >> >>info&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7Cd25dca9b7ada4 >b >>> > >> >>54eb7908ddb05804ed%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C >6 >>> > >> >>38860614551334722%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy >d >>> > >> >>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/ >.co >>m%2Fv3%2F__https%3A%2F%2Fauthors.ietf%2F__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3xnb53Egg%24&data=05%7C02%7Chendrik.brock >hau >>s%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794fd >4ad >>dab42e1495d55a%7C1%7C0%7C638877790756786038%7CUnknown%7CTWFpb >GZs >>b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOIj >>oiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=gYqJtxwcZuIew >OTjj >>c4yZKIgWP5dLmcH0sef4orHSKk%3D&reserved=0. >>> >>> org%2Frfcxml- >>> > >> >>vocabulary&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7Cd25dca9 >b >>> > >> >>7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7 >C >>> > >> >>0%7C638860614551358701%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG >ki >>> > >> >>OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf >Q >>> > >> >>%3D%3D%7C0%7C%7C%7C&sdata=4KEKvd%2F9HcDmuK1H9u9SLkiZFp7R0Pj >B >>> > >> 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 >>%2Fv3%2F__https%3A%2F%2Fmailarchive.i%2F__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3weKQu31Q%24&data=05%7C02%7Chendrik.bro >ckha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756805590%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=C6bCVPTfwHZ >dTe >>4tBwfH6laugUBSj%2B7dZ68GoAr22XA%3D&reserved=0 >>> >>> etf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh- >>> > >> >>4Q9l2USxIAe6P8O4Zc&data=05%7C02%7Chendrik.brockhaus%40siemens.com >% >>> > >> >>7Cd25dca9b7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4addab42e1495d5 >5 >>> > >> >>a%7C1%7C0%7C638860614551381593%7CUnknown%7CTWFpbGZsb3d8eyJFb >X >>> > >> >>B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb >C >>> > >> >>IsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=W3nbLk6%2B4%2FLyd5eikaD >m >>> > >> YcJ1rMZRpHFznRBvsQHXWNw%3D&reserved=0 >>> > >> >>> > >> * The archive itself: >>> > >> >>> > >> >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fmailarchive.i%2F__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3weKQu31Q%24&data=05%7C02%7Chendrik.bro >ckha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756826297%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=3MZRxzzFeThF >U% >>2B3Pux%2FoC1pc9qUjApkmp%2FPxWZnFI4c%3D&reserved=0 >>> >>> >>etf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Chendrik.br >o >>> > >> >>ckhaus%40siemens.com%7Cd25dca9b7ada4b54eb7908ddb05804ed%7C38ae3bc >d >>> > >> >>95794fd4addab42e1495d55a%7C1%7C0%7C638860614551407415%7CUnknown >% >>> > >> >>7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJ >X >>> > >> >>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 >>%2Fv3%2F__https%3A%2F%2Fwww.rfc-%2F__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3yQjuEqKQ%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756852137%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=WT0WR%2BBj >yW >>m0rjdvgITolLcYbUMUnVaEMpb97vybdHA%3D&reserved=0 >>> >>> >>editor.org%2Fauthors%2Frfc9810.xml&data=05%7C02%7Chendrik.brockhaus%40 >s >>> > >> >>iemens.com%7Cd25dca9b7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4ad >d >>> > >> >>ab42e1495d55a%7C1%7C0%7C638860614551432483%7CUnknown%7CTWFpbG >Z >>> > >> >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >F >>> > >> >>OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KaOYhlNHFMk5Z >A >>> > >> HZxzbiozmnixhggqPfINdxPE8UDGg%3D&reserved=0 >>> > >> >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc-%2F__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3yQjuEqKQ%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756876011%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=QOEZHFOyBg >m% >>2FgrMjMZBEGQtklsBnVNzguFCxpP0TcQU%3D&reserved=0 >>> >>> >>editor.org%2Fauthors%2Frfc9810.html&data=05%7C02%7Chendrik.brockhaus%4 >0 >>> > >> >>siemens.com%7Cd25dca9b7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4a >d >>> > >> >>dab42e1495d55a%7C1%7C0%7C638860614551448828%7CUnknown%7CTWFpb >G >>> > >> >>Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >Ik >>> > >> >>FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=IuWYtynoq8I%2 >B >>> > >> Pgv328Iol28iRrml8cUzulftnr7unMs%3D&reserved=0 >>> > >> >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc-%2F__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3yQjuEqKQ%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756896933%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=GfhlFJ8cVSoQ >HNV >>1qcANJ0u50MOX%2FsMWQnmPF8VSEjI%3D&reserved=0 >>> >>> >>editor.org%2Fauthors%2Frfc9810.pdf&data=05%7C02%7Chendrik.brockhaus%40 >si >>> > >> >>emens.com%7Cd25dca9b7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4add >a >>> > >> >>b42e1495d55a%7C1%7C0%7C638860614551465544%7CUnknown%7CTWFpbGZ >s >>> > >> >>b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >F >>> > >> >>OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DXx2eaB55FufB% >2 >>> > >> F5pdV6p5H2keVC6C5RWwQf9g2oVITc%3D&reserved=0 >>> > >> >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc-%2F__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3yQjuEqKQ%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756916571%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=u33SgegqbFXfq >zw >>2Wxu1N8oeHaYEMwD1%2BW0zNyI9Eqg%3D&reserved=0 >>> >>> >>editor.org%2Fauthors%2Frfc9810.txt&data=05%7C02%7Chendrik.brockhaus%40s >i >>> > >> >>emens.com%7Cd25dca9b7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4add >a >>> > >> >>b42e1495d55a%7C1%7C0%7C638860614551481529%7CUnknown%7CTWFpbGZ >s >>> > >> >>b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >F >>> > >> >>OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YwUasxMliK2BL1 >V >>> > >> GwRfgcM6X%2FMPLwE3SHwsAjUVFXBM%3D&reserved=0 >>> > >> >>> > >> Diff file of the text: >>> > >> >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc-%2F__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3yQjuEqKQ%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756935628%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=dRbQRf4OjI57 >mqO >>BXscPC0xQ7GGz5i4pWtW88NAjnRU%3D&reserved=0 >>> >>> editor.org%2Fauthors%2Frfc9810- >>> > >> >>diff.html&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7Cd25dca9b7 >a >>> > >> >>da4b54eb7908ddb05804ed%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0 >% >>> > >> >>7C638860614551496675%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO >n >>> > >> >>RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ% >3 >>> > >> >>D%3D%7C0%7C%7C%7C&sdata=UGE071%2B6EDvQWedVY3hAAOCo80bcXNd >g >>> > >> QNdRHJ1JvdQ%3D&reserved=0 >>> > >> >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc-%2F__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3yQjuEqKQ%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756955254%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=r%2Bl%2Bq92S >YG >>n8bHhhgcE0F6FYDdpWYFk2CDLinuZzW7Y%3D&reserved=0 >>> >>> editor.org%2Fauthors%2Frfc9810- >>> > >> >>rfcdiff.html&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7Cd25dca9 >b >>> > >> >>7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7 >C >>> > >> >>0%7C638860614551511934%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG >ki >>> > >> >>OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf >Q >>> > >> >>%3D%3D%7C0%7C%7C%7C&sdata=BRV2ZGaAlsjhLKTkmxoI%2Bc7IvBUtB7aC >n >>> > >> J5hdXbzg8g%3D&reserved=0 (side by side) >>> > >> >>> > >> Diff of the XML: >>> > >> >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc-%2F__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3yQjuEqKQ%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756974174%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=UJgHrH5d2Sq1 >h%2 >>B4ynVsIkEevbdQHMesOvNfQlo5Ojv4%3D&reserved=0 >>> >>> editor.org%2Fauthors%2Frfc9810- >>> > >> >>xmldiff1.html&data=05%7C02%7Chendrik.brockhaus%40siemens.com%7Cd25dc >a >>> > >> >>9b7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4addab42e1495d55a%7C1% >7 >>> > >> >>C0%7C638860614551532795%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc >G >>> > >> >>kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy >f >>> > >> >>Q%3D%3D%7C0%7C%7C%7C&sdata=nwoPdp3qSCaj8Eh8jLjWsBYnth60Qtt4Ad >P >>> > >> CxBx7wU8%3D&reserved=0 >>> > >> >>> > >> >>> > >> Tracking progress >>> > >> ----------------- >>> > >> >>> > >> The details of the AUTH48 status of your document are here: >>> > >> >>https://urldefense/. >com >>%2Fv3%2F__https%3A%2F%2Fwww.rfc-%2F__%3B!!FJ- >>Y8qCqXTj2!bvOdlRfDXkgzoTQQMtMPAi2fT_zvqn82oIkk6OeoH2K_FHhr0DchJVTl >NK >>OJbWpkQOaqJrwSG3xa0ndDx3yQjuEqKQ%24&data=05%7C02%7Chendrik.broc >kha >>us%40siemens.com%7C0dd94ff63e0a47ecdbed08ddbff70c69%7C38ae3bcd95794f >d4a >>ddab42e1495d55a%7C1%7C0%7C638877790756992674%7CUnknown%7CTWFp >bGZ >>sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >FOI >>joiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=nfl3d6MtzqIx86 >ckc >>u1uXFMace7V5f07TsIKwffy90w%3D&reserved=0 >>> >>> >>editor.org%2Fauth48%2Frfc9810&data=05%7C02%7Chendrik.brockhaus%40siem >e >>> > >> >>ns.com%7Cd25dca9b7ada4b54eb7908ddb05804ed%7C38ae3bcd95794fd4addab4 >2 >>> > >> >>e1495d55a%7C1%7C0%7C638860614551554676%7CUnknown%7CTWFpbGZsb3 >d >>> > >> >>8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj >oi >>> > >> >>TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZhCuyKv%2BPSRvvwt >y >>> > >> 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
