Good morning, I approve these changes.
Thanks! Rebecca Rebecca Guthrie she/her Center for Cybersecurity Standards (CCSS) Cybersecurity Collaboration Center (CCC) National Security Agency (NSA) -----Original Message----- From: Karen Moore <kmo...@staff.rfc-editor.org> Sent: Tuesday, April 29, 2025 12:59 PM To: Alison Becker (GOV) <aebe...@uwe.nsa.gov>; Rebecca Guthrie (GOV) <rmgu...@uwe.nsa.gov>; Michael Jenkins (GOV) <mjje...@cyber.nsa.gov> Cc: r...@cert.org; rfc-edi...@rfc-editor.org; lamps-...@ietf.org; lamps-cha...@ietf.org; tim.holleb...@digicert.com; auth48archive@rfc-editor.org Subject: Re: [AD] [auth48] AUTH48: RFC-to-be 9763 <draft-ietf-lamps-cert-binding-for-multi-auth-06> for your review Hi Alison, We have noted your approval on the AUTH48 status page for this document (https://www.rfc-editor.org/auth48/rfc9763). We now await approvals from Roman and Rebecca. Best regards, RFC Editor/kc > On Apr 28, 2025, at 6:44 AM, aebe...@uwe.nsa.gov wrote: > > > Hello, > I approve the changes as well. > Alison > From: Karen Moore <kmo...@staff.rfc-editor.org> > Sent: Friday, April 25, 2025 1:18 PM > To: r...@cert.org <r...@cert.org>; Michael Jenkins (GOV) > <mjje...@cyber.nsa.gov>; Rebecca Guthrie (GOV) <rmgu...@uwe.nsa.gov>; Alison > Becker (GOV) <aebe...@uwe.nsa.gov> > 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>; > tim.holleb...@digicert.com <tim.holleb...@digicert.com>; > auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> > Subject: [AD] [auth48] AUTH48: RFC-to-be 9763 > <draft-ietf-lamps-cert-binding-for-multi-auth-06> for your review > > Hello Mike and *Roman, > > We have noted your approval on the AUTH48 status page for this document > (https://www.rfc-editor.org/auth48/rfc9763). > > We now await approvals from Alison and Rebecca. > > *Roman, we await your approval of the following: Sections 3.1, 3.2, 4.1, 4.2, > 5, and 6 and Appendix A, as well as changes to the terms (validation and > verification). Please see the changes here: > https://www.rfc-editor.org/authors/rfc9763-auth48diff.html. > > Best regards, > RFC Editor/kc > > --Files (please refresh)-- > The updated XML file is here: > https://www.rfc-editor.org/authors/rfc9763.xml > > The updated output files are here: > https://www.rfc-editor.org/authors/rfc9763.txt > https://www.rfc-editor.org/authors/rfc9763.pdf > https://www.rfc-editor.org/authors/rfc9763.html > > These diff files show all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9763-auth48diff.html > https://www.rfc-editor.org/authors/rfc9763-auth48rfcdiff.html (side by side) > > These diff files show all changes made to date: > https://www.rfc-editor.org/authors/rfc9763-diff.html > https://www.rfc-editor.org/authors/rfc9763-rfcdiff.html (side by side) > > > On Apr 25, 2025, at 10:41 AM, mjje...@cyber.nsa.gov wrote: > > > > Hi Karen, > > > > I approve the current version of RFC-to-be 9763. > > > > Mike Jenkins > > > > -----Original Message----- > > From: Karen Moore <kmo...@staff.rfc-editor.org> > > Sent: Wednesday, April 9, 2025 14:42 > > To: Michael Jenkins (GOV) <mjje...@cyber.nsa.gov>; Alison Becker (GOV) > > <aebe...@uwe.nsa.gov>; Rebecca Guthrie (GOV) <rmgu...@uwe.nsa.gov> > > Cc: r...@cert.org; rfc-edi...@rfc-editor.org; lamps-...@ietf.org; > > lamps-cha...@ietf.org; tim.holleb...@digicert.com; > > auth48archive@rfc-editor.org > > Subject: Re: [AD] [auth48] AUTH48: RFC-to-be 9763 > > <draft-ietf-lamps-cert-binding-for-multi-auth-06> for your review > > > > Hi Mike, > > > > We have made the requested changes to the sourcecode in Section 4.1 and > > Appendix A. Please review (especially the spacing) and let us know if any > > further changes are needed. > > > > Note that we await approval of the document from all authors. > > > > We also await Roman's approval of the following: Sections 3.1, 3.2, 4.1, > > 4.2, 5, and 6 and Appendix A, as well as changes to the terms (validation > > and verification). > > > > -Files- > > The updated XML file is here: > > https://www.rfc-editor.org/authors/rfc9763.xml > > > > The updated output files are here: > > https://www.rfc-editor.org/authors/rfc9763.txt > > https://www.rfc-editor.org/authors/rfc9763.pdf > > https://www.rfc-editor.org/authors/rfc9763.html > > > > These diff files show all changes made during AUTH48: > > https://www.rfc-editor.org/authors/rfc9763-auth48diff.html > > https://www.rfc-editor.org/authors/rfc9763-auth48rfcdiff.html (side by side) > > > > These diff files show all changes made to date: > > https://www.rfc-editor.org/authors/rfc9763-diff.html > > https://www.rfc-editor.org/authors/rfc9763-rfcdiff.html (side by side) > > > > Best regards, > > RFC Editor/kc > > > > > >> On Apr 8, 2025, at 6:03 AM, mjje...@cyber.nsa.gov wrote: > >> > >> Hi Karen, > >> > >> Russ kindly checked our ASN.1 module. Please make the following > >> changes (these are in sourcecode blocks, I've left off the bracketing > >> tags). Thank you! mj > >> > >> Section 4.1, "The RelatedCertificate Extension" > >> > >> OLD: > >> -- Object Identifier for certificate extension id-relatedCert OBJECT > >> IDENTIFIER ::= { 36 } > >> > >> -- X.509 Certificate extension > >> RelatedCertificate ::= SEQUENCE { > >> hashAlgorithm AlgorithmIdentifier, > >> hashValue OCTET STRING } > >> > >> NEW: > >> -- Object Identifier for certificate extension id-relatedCert OBJECT > >> IDENTIFIER ::= { 36 } > >> > >> -- X.509 Certificate extension > >> RelatedCertificate ::= SEQUENCE { > >> hashAlgorithm DigestAlgorithmIdentifier, > >> hashValue OCTET STRING } > >> > >> > >> > >> Appendix A. "ASN.1 Module" > >> > >> OLD: > >> RelatedCertificate { iso(1) identified-organization(3) dod(6) > >> internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) > >> id-mod-related-cert-2023(115)} > >> > >> DEFINITIONS IMPLICIT TAGS ::= > >> BEGIN > >> > >> IMPORTS > >> > >> ATTRIBUTE, EXTENSION > >> FROM PKIX-CommonTypes-2009 -- in RFC 5912 > >> { iso(1) identified-organization(3) dod(6) internet(1) > >> security(5) mechanisms(5) pkix(7) id-mod(0) > >> id-mod-pkixCommon-02(57) } > >> > >> IssuerAndSerialNumber > >> FROM CryptographicMessageSyntax-2010 -- in RFC 6268 > >> { iso(1) member-body(2) us(840) rsadsi(113549) > >> pkcs(1) pkcs-9(9) smime(16) modules(0) > >> id-mod-cms-2009(58) } > >> > >> BinaryTime > >> FROM BinarySigningTimeModule -- in RFC 6019 > >> { iso(1) member-body(2) us(840) rsadsi(113549) > >> pkcs(1) pkcs-9(9) smime(16) modules(0) > >> id-mod-binarySigningTime(27) } ; > >> > >> > >> -- Object identifier arcs > >> > >> id-pe OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > >> dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1 } > >> > >> id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) usa(840) > >> rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2) } > >> > >> > >> -- relatedCertificate Extension > >> > >> id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe 36 } > >> > >> RelatedCertificate ::= SEQUENCE { > >> hashAlgorithm AlgorithmIdentifier, > >> hashValue OCTET STRING } > >> > >> ext-relatedCertificate EXTENSION ::= { > >> SYNTAX RelatedCertificate > >> IDENTIFIED BY id-pe-relatedCert } > >> > >> > >> -- relatedCertRequest Attribute > >> > >> id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa 60 } > >> > >> RequesterCertificate ::= SEQUENCE { > >> certID IssuerAndSerialNumber, > >> requestTime BinaryTime, > >> locationInfo UniformResourceIdentifier, > >> signature BIT STRING } > >> > >> UniformResourceIdentifier ::= IA5String > >> > >> aa-relatedCertRequest ATTRIBUTE ::= { > >> TYPE RequesterCertificate > >> IDENTIFIED BY id-aa-relatedCertRequest } > >> > >> END > >> > >> NEW: > >> RelatedCertificate { iso(1) identified-organization(3) dod(6) > >> internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) > >> id-mod-related-cert-2023(115)} > >> > >> DEFINITIONS IMPLICIT TAGS ::= > >> BEGIN > >> > >> IMPORTS > >> > >> ATTRIBUTE, EXTENSION > >> FROM PKIX-CommonTypes-2009 -- in [RFC5912] > >> { iso(1) identified-organization(3) dod(6) internet(1) > >> security(5) mechanisms(5) pkix(7) id-mod(0) > >> id-mod-pkixCommon-02(57) } > >> > >> IssuerAndSerialNumber, DigestAlgorithmIdentifier > >> FROM CryptographicMessageSyntax-2010 -- in [RFC6268] > >> { iso(1) member-body(2) us(840) rsadsi(113549) > >> pkcs(1) pkcs-9(9) smime(16) modules(0) > >> id-mod-cms-2009(58) } > >> > >> BinaryTime > >> FROM BinarySigningTimeModule -- in [RFC6019] > >> { iso(1) member-body(2) us(840) rsadsi(113549) > >> pkcs(1) pkcs-9(9) smime(16) modules(0) > >> id-mod-binarySigningTime(27) } ; > >> > >> > >> -- Object identifier arcs > >> > >> id-pe OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) > >> dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1 } > >> > >> id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) usa(840) > >> rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 2 } > >> > >> > >> -- relatedCertificate Extension > >> > >> id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe 36 } > >> > >> RelatedCertificate ::= SEQUENCE { > >> hashAlgorithm DigestAlgorithmIdentifier, > >> hashValue OCTET STRING } > >> > >> ext-relatedCertificate EXTENSION ::= { > >> SYNTAX RelatedCertificate > >> IDENTIFIED BY id-pe-relatedCert } > >> > >> > >> -- relatedCertRequest Attribute > >> > >> id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa 60 } > >> > >> RequesterCertificate ::= SEQUENCE { > >> certID IssuerAndSerialNumber, > >> requestTime BinaryTime, > >> locationInfo UniformResourceIdentifiers, > >> signature BIT STRING } > >> > >> UniformResourceIdentifiers ::= SEQUENCE SIZE (1..MAX) OF URI > >> > >> URI ::= IA5String > >> > >> aa-relatedCertRequest ATTRIBUTE ::= { > >> TYPE RequesterCertificate > >> IDENTIFIED BY id-aa-relatedCertRequest } > >> > >> END > >> > >> -----Original Message----- > >> From: Karen Moore <kmo...@staff.rfc-editor.org> > >> Sent: Friday, April 4, 2025 15:58 > >> To: Michael Jenkins (GOV) <mjje...@cyber.nsa.gov>; Rebecca Guthrie > >> (GOV) <rmgu...@uwe.nsa.gov>; r...@cert.org; Alison Becker (GOV) > >> <aebe...@uwe.nsa.gov> > >> Cc: rfc-edi...@rfc-editor.org; lamps-...@ietf.org; > >> lamps-cha...@ietf.org; tim.holleb...@digicert.com; > >> auth48archive@rfc-editor.org > >> Subject: Re: [AD] [auth48] AUTH48: RFC-to-be 9763 > >> <draft-ietf-lamps-cert-binding-for-multi-auth-06> for your review > >> > >> Hi Mike, > >> > >> Thank you for confirming that the sourcecode types are correct and for > >> pointing out the sentence in Section 1.1 that needed a further update (we > >> caught this and removed the extraneous "and"; the change can be viewed > >> here: https://www.rfc-editor.org/authors/rfc9763-auth48diff.html). > >> > >> We now await further changes (if needed) and approval of the document from > >> each author. We also await approval from the AD for the non-editorial > >> changes in Sections 3.1, 3.2, 4.1, 4.2, 5, and 6 and Appendix A. > >> > >> Thanks! > >> RFC Editor/kc > >> > >>> On Apr 3, 2025, at 5:26 PM, mjje...@cyber.nsa.gov wrote: > >>> > >>> the update to sourcecode is correct (i.e. produces the correct output). > >>> the type for all sourcecode should be "asn.1". > >>> > >>> Thanks! > >>> > >>> Mike > >>> > >>> > >>> Get Outlook for iOS > >>> From: Karen Moore <kmo...@staff.rfc-editor.org> > >>> Sent: Thursday, April 3, 2025 5:19:00 PM > >>> To: Michael Jenkins (GOV) <mjje...@cyber.nsa.gov>; r...@cert.org > >>> <r...@cert.org>; Rebecca Guthrie (GOV) <rmgu...@uwe.nsa.gov>; Alison > >>> Becker (GOV) <aebe...@uwe.nsa.gov> > >>> 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>; tim.holleb...@digicert.com > >>> <tim.holleb...@digicert.com>; auth48archive@rfc-editor.org > >>> <auth48archive@rfc-editor.org> > >>> Subject: [AD] Re: [auth48] AUTH48: RFC-to-be 9763 > >>> <draft-ietf-lamps-cert-binding-for-multi-auth-06> for your review > >>> > >>> Dear Michael and *Roman (AD), > >>> > >>> Thank you for your reply and for providing the updated XML file. Our > >>> files have been updated accordingly. We have one clarification. > >>> > >>> 1) We don't believe a response was provided to the following question; > >>> please confirm if everything is correct or if any changes are needed. > >>> > >>>> <!-- [rfced] We updated artwork to sourcecode in Sections 3.1 and > >>>> 4.1 and in Appendix A. Please confirm that this is 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. > >>>> --> > >>> > >>> *Roman, please review the updates made to Sections 3.1, 3.2, 4.1, 4.2, 5, > >>> and 6 and Appendix A, as well as the changes to the terms throughout the > >>> text ('validation' for certificates and 'verification' for signatures), > >>> and let us know if you approve. The updates can be viewed in this file: > >>> https://www.rfc-editor.org/authors/rfc9763-auth48diff.html. > >>> > >>> Note: The authors have included detailed notes in the XML file if you > >>> would like to see the rationale for the changes (search on 'rmg' and > >>> 'mjj' to find the comments). > >>> > >>> -Files- > >>> The updated XML file is here: > >>> > >>> https://www/. > >>> rfc-editor.org%2Fauthors%2Frfc9763.xml&data=05%7C02%7Cmjjenki%40cyber. > >>> nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164f848a3e6eef > >>> f > >>> 33e136b%7C0%7C0%7C638793935537134083%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 > >>> e > >>> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl > >>> d > >>> UIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=ZqjhV8B071Hw6T0Ef2YaLzsNoC9Fl05k > >>> a > >>> TjNc5oNDK0%3D&reserved=0 > >>> > >>> The updated output files are here: > >>> > >>> https://www/. > >>> rfc-editor.org%2Fauthors%2Frfc9763.txt&data=05%7C02%7Cmjjenki%40cyber. > >>> nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164f848a3e6eef > >>> f > >>> 33e136b%7C0%7C0%7C638793935537146429%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 > >>> e > >>> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl > >>> d > >>> UIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=K%2FGnj7alnj%2FSva9oyGaLc8%2BI8N > >>> v > >>> vZJTBysw8TVAx%2FoY%3D&reserved=0 > >>> > >>> https://www/. > >>> rfc-editor.org%2Fauthors%2Frfc9763.pdf&data=05%7C02%7Cmjjenki%40cyber. > >>> nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164f848a3e6eef > >>> f > >>> 33e136b%7C0%7C0%7C638793935537158443%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 > >>> e > >>> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl > >>> d > >>> UIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Qs8MdMZhS520Ds5bHT15hsuLZxeI5jV6 > >>> p > >>> kmxEOael9Y%3D&reserved=0 > >>> > >>> https://www/. > >>> rfc-editor.org%2Fauthors%2Frfc9763.html&data=05%7C02%7Cmjjenki%40cybe > >>> r > >>> .nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164f848a3e6ee > >>> f > >>> f33e136b%7C0%7C0%7C638793935537170380%7CUnknown%7CTWFpbGZsb3d8eyJFbXB > >>> 0 > >>> eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI > >>> l > >>> dUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=HDM9U0Brl604w9MFGz75%2BNWcxhKy2 > >>> r > >>> oOldDf8bVp%2Biw%3D&reserved=0 > >>> > >>> These diff files show all changes made during AUTH48: > >>> > >>> https://www/. > >>> rfc-editor.org%2Fauthors%2Frfc9763-auth48diff.html&data=05%7C02%7Cmjj > >>> e > >>> nki%40cyber.nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc16 > >>> 4 > >>> f848a3e6eeff33e136b%7C0%7C0%7C638793935537182638%7CUnknown%7CTWFpbGZs > >>> b > >>> 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj > >>> o > >>> iTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=RPQuAUPjE%2FTphw37eV > >>> F > >>> DUP%2BCSTXp7doX0WWQ%2F7bbkZQ%3D&reserved=0 > >>> > >>> https://www/. > >>> rfc-editor.org%2Fauthors%2Frfc9763-auth48rfcdiff.html&data=05%7C02%7C > >>> m > >>> jjenki%40cyber.nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ff > >>> c > >>> 164f848a3e6eeff33e136b%7C0%7C0%7C638793935537194513%7CUnknown%7CTWFpb > >>> G > >>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > >>> O > >>> IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=JxfzkF40eMr1jJHRv > >>> 6 > >>> IIueDZ%2FhWbl1wCt3wBhr6WNlw%3D&reserved=0 (side by side) > >>> > >>> These diff files show all changes made to date: > >>> > >>> https://www/. > >>> rfc-editor.org%2Fauthors%2Frfc9763-diff.html&data=05%7C02%7Cmjjenki%4 > >>> 0 > >>> cyber.nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164f848a > >>> 3 > >>> e6eeff33e136b%7C0%7C0%7C638793935537206549%7CUnknown%7CTWFpbGZsb3d8ey > >>> J > >>> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp > >>> b > >>> CIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=4reKQGpfVScLb%2F8AzjN7AKdF > >>> L > >>> hnEHso7hTIQekzl%2Bzw%3D&reserved=0 > >>> > >>> https://www/. > >>> rfc-editor.org%2Fauthors%2Frfc9763-rfcdiff.html&data=05%7C02%7Cmjjenk > >>> i > >>> %40cyber.nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164f8 > >>> 4 > >>> 8a3e6eeff33e136b%7C0%7C0%7C638793935537218639%7CUnknown%7CTWFpbGZsb3d > >>> 8 > >>> eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT > >>> W > >>> FpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=1xRWX%2FzuMWKedp%2BXMWw > >>> W > >>> uXV2kTCQXPTLD%2Fx%2BuCNnSKY%3D&reserved=0 (side by side) > >>> > >>> Note that it may be necessary for you to refresh your browser to view the > >>> most recent version. Please review the document carefully to ensure > >>> satisfaction as we do not make changes once it has been published as an > >>> RFC. > >>> > >>> Please contact us with any further updates or with your approval of the > >>> document in its current form. We will await approvals from each author > >>> and the AD prior to moving forward in the publication process. > >>> > >>> For the AUTH48 status of this document, please see: > >>> > >>> https://www/. > >>> rfc-editor.org%2Fauth48%2Frfc9763&data=05%7C02%7Cmjjenki%40cyber.nsa. > >>> g > >>> ov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164f848a3e6eeff33e1 > >>> 3 > >>> 6b%7C0%7C0%7C638793935537230574%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc > >>> G > >>> kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo > >>> y > >>> fQ%3D%3D%7C60000%7C%7C%7C&sdata=icHIJjW%2B%2Bb2mpstpljZsgHJczcMhRgxLJ > >>> K > >>> 4dsWKhj3o%3D&reserved=0 > >>> > >>> Best regards, > >>> RFC Editor/kc > >>> > >>> > >>>> On Apr 3, 2025, at 12:09 PM, mjjenki--- via auth48archive > >>>> <auth48archive@rfc-editor.org> wrote: > >>>> > >>>> Please find attached the authors final edits to RFC-to-be 9763 as file > >>>> <rfc9763_bgj.xml>. > >>>> > >>>> Most RFC Editor suggested changes were made. For Q12, note that the term > >>>> "traditional" with reference to pre-PQC algorithms is a term-of-art; see > >>>> draft-ietf-pquip-pqt-hybrid-terminology. > >>>> > >>>> Nearly all edits were editorial. There are two substantial ones that we > >>>> want to bring to your attention (these are also fully described in situ): > >>>> > >>>> * In Section 4.1, "The RelatedCertificate Extension", a substantive > >>>> change was made that had been raised and resolved on the LAMPS (spasm) > >>>> mail-list after WGLC. The change agreed was not security-relevant and > >>>> was in fact a reversion to an earlier version of the same document. > >>>> > >>>> * Section 6, "CA Organization Considerations", has been extensively > >>>> edited for clarity. Significantly, we found it difficult to tell that > >>>> the first paragraph discussed to the CSR attribute and the second > >>>> paragraph discussed the certificate extension. We feel that the new text > >>>> is equivalent to the old text but much clearer. > >>>> > >>>> Please let us know if you have any questions regarding changes made. > >>>> > >>>> -----Original Message----- > >>>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > >>>> Sent: Friday, March 28, 2025 22:19 > >>>> To: Alison Becker (GOV) <aebe...@uwe.nsa.gov>; Rebecca Guthrie (GOV) > >>>> <rmgu...@uwe.nsa.gov>; Michael Jenkins (GOV) <mjje...@cyber.nsa.gov> > >>>> Cc: rfc-edi...@rfc-editor.org; lamps-...@ietf.org; > >>>> lamps-cha...@ietf.org; tim.holleb...@digicert.com; r...@cert.org; > >>>> auth48archive@rfc-editor.org > >>>> Subject: Re: AUTH48: RFC-to-be 9763 > >>>> <draft-ietf-lamps-cert-binding-for-multi-auth-06> 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] May we update the short title that spans the header of > >>>> the PDF file to more closely match the document title as shown below? > >>>> > >>>> Original: > >>>> Related Certificates > >>>> > >>>> Perhaps: > >>>> Related Certificates for Protocol Authentications > >>>> --> > >>>> > >>>> > >>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear > >>>> in the title) for use on https://ww/ > >>>> w.rfc-editor.org%2Fsearch&data=05%7C02%7Cmjjenki%40cyber.nsa.gov%7Cc > >>>> 679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164f848a3e6eeff33e136b%7 > >>>> C0%7C0%7C638793935537242582%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGki > >>>> OnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > >>>> fQ%3D%3D%7C60000%7C%7C%7C&sdata=ZtoLjDg6AL7h8mSZbqdB4eLKGpQWNIzcCbZq > >>>> 6LWrjGM%3D&reserved=0. --> > >>>> > >>>> > >>>> 3) <!--[rfced] Please clarify "different to" in the following sentence. > >>>> Is the intended meaning perhaps "different than"? > >>>> > >>>> Original: > >>>> If the request for (new) Cert B is to a CA organization different > >>>> to the CA organization that issued the certificate > >>>> (existing) Cert A referenced in the CSR... > >>>> > >>>> Perhaps: > >>>> If the request for (new) Cert B is to a CA organization that is > >>>> different than the CA organization that issued the certificate > >>>> (existing) Cert A referenced in the CSR... > >>>> --> > >>>> > >>>> > >>>> 4) <!-- [rfced] FYI: We have added a citation for the NIST SP mentioned > >>>> in this sentence, with a corresponding reference entry in the > >>>> informative reference section. > >>>> > >>>> Original: > >>>> If the related certificate is a key establishment certificate > >>>> (e.g., using RSA key transport or ECC key agreement), use the > >>>> private key to sign one time for POP (as detailed in NIST SP 800-57 > >>>> Part 1 Rev 5 Section > >>>> 8.1.5.1.1.2) > >>>> > >>>> Current: > >>>> If the related certificate is a key establishment certificate > >>>> (e.g., using RSA key transport or Elliptic Curve Cryptography (ECC) > >>>> key agreement), use the private key to sign one time for proof of > >>>> possession (POP) (as detailed in Section 8.1.5.1.1.2 of > >>>> [NIST-SP-800-57]). > >>>> --> > >>>> > >>>> > >>>> 5) <!--[rfced] Is "mechanism" intended to be singular (perhaps A) or > >>>> plural (perhaps B) in this sentence? And may we rephrase "have to be to > >>>> the satisfaction of the verifier" to "have to be satisfactory to the > >>>> verifier"? > >>>> > >>>> Original: > >>>> The means and strength of mechanism for authentication have to be > >>>> to the satisfaction of the verifier. > >>>> > >>>> Perhaps A: > >>>> The means and strength of an authentication mechanism have to be > >>>> to satisfactory to the verifier. > >>>> > >>>> Perhaps B: > >>>> The means and strength of mechanisms for authentication have to be > >>>> satisfactory to the verifier. > >>>> --> > >>>> > >>>> > >>>> 6) <!--[rfced] Can "and to assess that it got what it needed" be > >>>> rephrased for clarity? Please let us know if the suggested text is > >>>> agreeable or if you prefer otherwise. > >>>> > >>>> Original: > >>>> For more promiscuous online protocols, like TLS, the ability for > >>>> the verifier to express what is possible and what is preferred - > >>>> and to assess that it got what it needed - is important. > >>>> > >>>> Perhaps: > >>>> For more promiscuous online protocols, like TLS, the ability for > >>>> the verifier to express what is possible and what is preferred - > >>>> and to assess that its requirements were met - is important. > >>>> --> > >>>> > >>>> > >>>> 7) <!--[rfced] We updated "it may be advisable" to "it is advisable". If > >>>> that is incorrect, please let us know. > >>>> > >>>> Original: > >>>> CAs should be aware that retrieval of existing certificates may be > >>>> subject to observation; if this is a concern, it may be advisable to > >>>> use the dataURI option described in Section 3.1. > >>>> > >>>> Current: > >>>> CAs should be aware that retrieval of existing certificates may be > >>>> subject to observation; if this is a concern, it is advisable to > >>>> use the dataURI option described in Section 3.1. > >>>> --> > >>>> > >>>> > >>>> 8) <!--[rfced] We have included a clarification about the IANA text > >>>> below. In addition to responding to that question, please review all of > >>>> the IANA-related updates carefully and let us know if any further > >>>> updates are needed. > >>>> > >>>> a) FYI: For all three registrations, we replaced the OIDs enclosed in > >>>> <artwork> with entries that exactly match the IANA registries at > >>>> <https://www.iana.org/assignments/smi-numbers/>. > >>>> > >>>> One example > >>>> > >>>> Original: > >>>> > >>>> id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe TBD2 } > >>>> > >>>> Current: > >>>> > >>>> | Decimal | Description | References | > >>>> +=========+===================+============+ > >>>> | 36 | id-pe-relatedCert | RFC 9763 | > >>>> --> > >>>> > >>>> > >>>> 9) <!-- [rfced] We note that the "IssuerAndSerialNumber type" is > >>>> mentioned in [RFC5912] and [RFC6268, and the "BinaryTime type" is > >>>> mentioned in [RFC6019]. Considering that, may we update the following > >>>> sentence for clarity as shown below? > >>>> > >>>> Original: > >>>> It pulls definitions from modules defined in [RFC5912], and > >>>> [RFC6268], and [RFC6019] for the IssuerAndSerialNumber type, and > >>>> BinaryTime type, respectively. > >>>> > >>>> Perhaps: > >>>> It pulls definitions from modules defined in [RFC5912] and > >>>> [RFC6268] for the IssuerAndSerialNumber type and in [RFC6019] for > >>>> the BinaryTime type. > >>>> --> > >>>> > >>>> > >>>> 10) <!-- [rfced] We updated artwork to sourcecode in Sections 3.1 and > >>>> 4.1 and in Appendix A. Please confirm that this is 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. > >>>> --> > >>>> > >>>> > >>>> 11) <!-- [rfced] 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. > >>>> > >>>> Cryptographic Message Syntax (CMS) > >>>> Certificate Signing Request (CSR) > >>>> Elliptic Curve Cryptography (ECC) > >>>> extended key usage (EKU) > >>>> Internet Key Exchange Protocol Version 2 (IKEv2) key usage (KU) > >>>> proof of possession (POP) (per NIST-SP-800-57) post-quantum (PQ) > >>>> post-quantum cryptography (PQC) > >>>> --> > >>>> > >>>> > >>>> 12) <!-- [rfced] Please review the "Inclusive Language" portion of > >>>> the online Style Guide <https://w/ > >>>> ww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data= > >>>> 05%7C02%7Cmjjenki%40cyber.nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578 > >>>> %7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638793935537282506%7CU > >>>> nknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlA > >>>> iOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata > >>>> =6%2F62oLAy%2FABpdG4KhsZaUxReBxi0zUXAvPoXZEYubRo%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. > >>>> > >>>> For example, please consider whether "native" should be updated. > >>>> > >>>> In addition, please consider whether "traditional" should be updated for > >>>> clarity. > >>>> While the NIST website > >>>> <https://w/ > >>>> eb.archive.org%2Fweb%2F20250214092458%2Fhttps%3A%2F%2Fwww.nist.gov%2 > >>>> F&data=05%7C02%7Cmjjenki%40cyber.nsa.gov%7Cc679b7ae8a9f45e1c02b08dd7 > >>>> 3b2f578%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638793935537294 > >>>> 788%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > >>>> MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7 > >>>> C&sdata=6N6OP9IsjMuT2iLJ8O19OQhiqWFrmS%2FmxocPE7JC7W4%3D&reserved=0 > >>>> nist-research-library/nist-technical-series-publications-author-inst > >>>> ructions#table1> indicates that this term is potentially biased, it > >>>> is also ambiguous. > >>>> "Tradition" is a subjective term, as it is not the same for everyone. > >>>> --> > >>>> > >>>> > >>>> Thank you. > >>>> > >>>> RFC Editor/kc > >>>> > >>>> > >>>> > >>>> On Mar 28, 2025, at 7:16 PM, RFC Editor via auth48archive > >>>> <mailto:auth48archive@rfc-editor.org> wrote: > >>>> > >>>> *****IMPORTANT***** > >>>> > >>>> Updated 2025/03/28 > >>>> > >>>> RFC Author(s): > >>>> -------------- > >>>> > >>>> Instructions for Completing AUTH48 > >>>> > >>>> Your document has now entered AUTH48. Once it has been reviewed and > >>>> approved by you and all coauthors, it will be published as an RFC. > >>>> If an author is no longer available, there are several remedies > >>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). > >>>> > >>>> You and you coauthors are responsible for engaging other parties > >>>> (e.g., Contributors or Working Group) as necessary before providing > >>>> your approval. > >>>> > >>>> Planning your review > >>>> --------------------- > >>>> > >>>> Please review the following aspects of your document: > >>>> > >>>> * RFC Editor questions > >>>> > >>>> Please review and resolve any questions raised by the RFC Editor > >>>> that have been included in the XML file as comments marked as > >>>> follows: > >>>> > >>>> <!-- [rfced] ... --> > >>>> > >>>> These questions will also be sent in a subsequent email. > >>>> > >>>> * Changes submitted by coauthors > >>>> > >>>> Please ensure that you review any changes submitted by your > >>>> coauthors. We assume that if you do not speak up that you agree to > >>>> changes submitted by your coauthors. > >>>> > >>>> * Content > >>>> > >>>> Please review the full content of the document, as this cannot > >>>> change once the RFC is published. Please pay particular attention to: > >>>> - IANA considerations updates (if applicable) > >>>> - contact information > >>>> - references > >>>> > >>>> * Copyright notices and legends > >>>> > >>>> Please review the copyright notice and legends as defined in RFC > >>>> 5378 and the Trust Legal Provisions (TLP - > >>>> https://trustee.ietf.org/license-info). > >>>> > >>>> * Semantic markup > >>>> > >>>> Please review the markup in the XML file to ensure that elements of > >>>> content are correctly tagged. For example, ensure that <sourcecode> > >>>> and <artwork> are set correctly. See details at > >>>> <https://authors.ietf.org/rfcxml-vocabulary>. > >>>> > >>>> * Formatted output > >>>> > >>>> Please review the PDF, HTML, and TXT files to ensure that the > >>>> formatted output, as generated from the markup in the XML file, is > >>>> reasonable. Please note that the TXT will have formatting > >>>> limitations compared to the PDF and HTML. > >>>> > >>>> > >>>> Submitting changes > >>>> ------------------ > >>>> > >>>> To submit changes, please reply to this email using 'REPLY ALL' as > >>>> all the parties CCed on this message need to see your changes. The > >>>> parties > >>>> include: > >>>> > >>>> * your coauthors > >>>> > >>>> * mailto: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). > >>>> > >>>> * mailto: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://ma/ > >>>> ilarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxI > >>>> Ae6P8O4Zc&data=05%7C02%7Cmjjenki%40cyber.nsa.gov%7Cc679b7ae8a9f45e1c > >>>> 02b08dd73b2f578%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C6387939 > >>>> 35537343926%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw > >>>> LjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000 > >>>> %7C%7C%7C&sdata=WY3cdoRW6qaY3rGcC%2F6GA5dXB03a6c8SeYFtNg%2BVFcU%3D&r > >>>> eserved=0 > >>>> > >>>> * The archive itself: > >>>> > >>>> https://ma/ > >>>> ilarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7 > >>>> Cmjjenki%40cyber.nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a > >>>> 6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638793935537356098%7CUnknown%7C > >>>> TWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z > >>>> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=b8cqUHTt > >>>> 0Frk4xaNYjH6XU5UKTyKQVYQnlIUPK8tru0%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, > >>>> mailto: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://ww/ > >>>> w.rfc-editor.org%2Fauthors%2Frfc9763.xml&data=05%7C02%7Cmjjenki%40cy > >>>> ber.nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164f848a3 > >>>> e6eeff33e136b%7C0%7C0%7C638793935537368078%7CUnknown%7CTWFpbGZsb3d8e > >>>> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT > >>>> WFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=fycL7Uz8hXWRY%2BGMs56 > >>>> CsDmiETiLj%2FTLtPrEWksBQLM%3D&reserved=0 > >>>> > >>>> https://ww/ > >>>> w.rfc-editor.org%2Fauthors%2Frfc9763.html&data=05%7C02%7Cmjjenki%40c > >>>> yber.nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164f848a > >>>> 3e6eeff33e136b%7C0%7C0%7C638793935537381446%7CUnknown%7CTWFpbGZsb3d8 > >>>> eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > >>>> TWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=jUwX4WGtk0KzEQ%2FizR > >>>> dgL8PD26%2F3KGMIKU%2FC7vqpfiE%3D&reserved=0 > >>>> > >>>> https://ww/ > >>>> w.rfc-editor.org%2Fauthors%2Frfc9763.pdf&data=05%7C02%7Cmjjenki%40cy > >>>> ber.nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164f848a3 > >>>> e6eeff33e136b%7C0%7C0%7C638793935537393670%7CUnknown%7CTWFpbGZsb3d8e > >>>> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT > >>>> WFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=nGJnFAxmecrhzczSeO0MF > >>>> Vmy55KAxb3MxCwD5CjQRxY%3D&reserved=0 > >>>> > >>>> https://ww/ > >>>> w.rfc-editor.org%2Fauthors%2Frfc9763.txt&data=05%7C02%7Cmjjenki%40cy > >>>> ber.nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164f848a3 > >>>> e6eeff33e136b%7C0%7C0%7C638793935537406141%7CUnknown%7CTWFpbGZsb3d8e > >>>> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT > >>>> WFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=oKKagfnwYjq%2FPsCxExi > >>>> %2BjSBx%2BJeaLMLKdKdSCT9M7r0%3D&reserved=0 > >>>> > >>>> Diff file of the text: > >>>> > >>>> https://ww/ > >>>> w.rfc-editor.org%2Fauthors%2Frfc9763-diff.html&data=05%7C02%7Cmjjenk > >>>> i%40cyber.nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164 > >>>> f848a3e6eeff33e136b%7C0%7C0%7C638793935537423152%7CUnknown%7CTWFpbGZ > >>>> sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > >>>> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=%2F2iqlbDBcXPw5 > >>>> HCCvlnlvJsOh5B3dlAs6m0L5nC3Yw0%3D&reserved=0 > >>>> > >>>> https://ww/ > >>>> w.rfc-editor.org%2Fauthors%2Frfc9763-rfcdiff.html&data=05%7C02%7Cmjj > >>>> enki%40cyber.nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc > >>>> 164f848a3e6eeff33e136b%7C0%7C0%7C638793935537436064%7CUnknown%7CTWFp > >>>> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs > >>>> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=%2F%2FEnqDeP > >>>> YqolQ8lPyNjaULHnLEBA63Crhk%2BfdLAGEkg%3D&reserved=0 (side by side) > >>>> > >>>> Diff of the XML: > >>>> > >>>> https://ww/ > >>>> w.rfc-editor.org%2Fauthors%2Frfc9763-xmldiff1.html&data=05%7C02%7Cmj > >>>> jenki%40cyber.nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ff > >>>> c164f848a3e6eeff33e136b%7C0%7C0%7C638793935537449174%7CUnknown%7CTWF > >>>> pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI > >>>> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=AKG0MuvHMJb > >>>> mNFHWRQQTx8jghgpl3XQ82Cn8GgAWvlo%3D&reserved=0 > >>>> > >>>> > >>>> Tracking progress > >>>> ----------------- > >>>> > >>>> The details of the AUTH48 status of your document are here: > >>>> > >>>> https://ww/ > >>>> w.rfc-editor.org%2Fauth48%2Frfc9763&data=05%7C02%7Cmjjenki%40cyber.n > >>>> sa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164f848a3e6eef > >>>> f33e136b%7C0%7C0%7C638793935537461431%7CUnknown%7CTWFpbGZsb3d8eyJFbX > >>>> B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbC > >>>> IsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=51CScHAPI07gb%2BDdeahbraOt > >>>> cwrNJDSgBovwrRBWDIk%3D&reserved=0 > >>>> > >>>> Please let us know if you have any questions. > >>>> > >>>> Thank you for your cooperation, > >>>> > >>>> RFC Editor > >>>> > >>>> -------------------------------------- > >>>> RFC9763 (draft-ietf-lamps-cert-binding-for-multi-auth-06) > >>>> > >>>> Title : Related Certificates for Use in Multiple > >>>> Authentications within a Protocol > >>>> Author(s) : A. Becker, R. Guthrie, M. Jenkins > >>>> WG Chair(s) : Russ Housley, Tim Hollebeek > >>>> Area Director(s) : Deb Cooley, Paul Wouters > >>>> > >>>> > >>>> -- > >>>> auth48archive mailing list -- mailto:auth48archive@rfc-editor.org > >>>> To unsubscribe send an email to > >>>> mailto:auth48archive-le...@rfc-editor.org > >>>> > >>>> <rfc9763_bgj.xml>-- > >>>> auth48archive mailing list -- auth48archive@rfc-editor.org To > >>>> unsubscribe send an email to auth48archive-le...@rfc-editor.org > >>> > >> > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
