Hi Rebecca, Thank you for your reply. We have noted your approval on the AUTH48 status page for this document (https://www.rfc-editor.org/auth48/rfc9763).
We now await approval from Roman (AD) for the changes that are beyond editorial. Best regards, RFC Editor/kc > On Apr 30, 2025, at 8:59 AM, Rebecca Guthrie <[email protected]> wrote: > > 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 <[email protected]> > Sent: Tuesday, April 29, 2025 12:59 PM > To: Alison Becker (GOV) <[email protected]>; Rebecca Guthrie (GOV) > <[email protected]>; Michael Jenkins (GOV) <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected] > 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, [email protected] wrote: >> >> >> Hello, >> I approve the changes as well. >> Alison >> From: Karen Moore <[email protected]> >> Sent: Friday, April 25, 2025 1:18 PM >> To: [email protected] <[email protected]>; Michael Jenkins (GOV) >> <[email protected]>; Rebecca Guthrie (GOV) <[email protected]>; Alison >> Becker (GOV) <[email protected]> >> Cc: [email protected] <[email protected]>; >> [email protected] <[email protected]>; [email protected] >> <[email protected]>; [email protected] >> <[email protected]>; [email protected] >> <[email protected]> >> 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, [email protected] wrote: >>> >>> Hi Karen, >>> >>> I approve the current version of RFC-to-be 9763. >>> >>> Mike Jenkins >>> >>> -----Original Message----- >>> From: Karen Moore <[email protected]> >>> Sent: Wednesday, April 9, 2025 14:42 >>> To: Michael Jenkins (GOV) <[email protected]>; Alison Becker (GOV) >>> <[email protected]>; Rebecca Guthrie (GOV) <[email protected]> >>> Cc: [email protected]; [email protected]; [email protected]; >>> [email protected]; [email protected]; >>> [email protected] >>> 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, [email protected] 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 <[email protected]> >>>> Sent: Friday, April 4, 2025 15:58 >>>> To: Michael Jenkins (GOV) <[email protected]>; Rebecca Guthrie >>>> (GOV) <[email protected]>; [email protected]; Alison Becker (GOV) >>>> <[email protected]> >>>> Cc: [email protected]; [email protected]; >>>> [email protected]; [email protected]; >>>> [email protected] >>>> 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, [email protected] 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 <[email protected]> >>>>> Sent: Thursday, April 3, 2025 5:19:00 PM >>>>> To: Michael Jenkins (GOV) <[email protected]>; [email protected] >>>>> <[email protected]>; Rebecca Guthrie (GOV) <[email protected]>; Alison >>>>> Becker (GOV) <[email protected]> >>>>> Cc: [email protected] <[email protected]>; >>>>> [email protected] <[email protected]>; [email protected] >>>>> <[email protected]>; [email protected] >>>>> <[email protected]>; [email protected] >>>>> <[email protected]> >>>>> 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 >>>>>> <[email protected]> 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: [email protected] <[email protected]> >>>>>> Sent: Friday, March 28, 2025 22:19 >>>>>> To: Alison Becker (GOV) <[email protected]>; Rebecca Guthrie (GOV) >>>>>> <[email protected]>; Michael Jenkins (GOV) <[email protected]> >>>>>> Cc: [email protected]; [email protected]; >>>>>> [email protected]; [email protected]; [email protected]; >>>>>> [email protected] >>>>>> 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:[email protected]> 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:[email protected] (the RPC team) >>>>>> >>>>>> * other document participants, depending on the stream (e.g., >>>>>> IETF Stream participants are your working group chairs, the >>>>>> responsible ADs, and the document shepherd). >>>>>> >>>>>> * mailto:[email protected], 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:[email protected] will be re-added to the CC list >>>>>> and >>>>>> its addition will be noted at the top of the message. >>>>>> >>>>>> You may submit your changes in one of two ways: >>>>>> >>>>>> An update to the provided XML file >>>>>> - OR - >>>>>> An explicit list of changes in this format >>>>>> >>>>>> Section # (or indicate Global) >>>>>> >>>>>> OLD: >>>>>> old text >>>>>> >>>>>> NEW: >>>>>> new text >>>>>> >>>>>> You do not need to reply with both an updated XML file and an >>>>>> explicit list of changes, as either form is sufficient. >>>>>> >>>>>> We will ask a stream manager to review and approve any changes that >>>>>> seem beyond editorial in nature, e.g., addition of new text, >>>>>> deletion of text, and technical changes. Information about stream >>>>>> managers can be found in the FAQ. Editorial changes do not require >>>>>> approval from a stream manager. >>>>>> >>>>>> >>>>>> Approving for publication >>>>>> -------------------------- >>>>>> >>>>>> To approve your RFC for publication, please reply to this email >>>>>> stating that you approve this RFC for publication. Please use >>>>>> 'REPLY ALL', as all the parties CCed on this message need to see your >>>>>> approval. >>>>>> >>>>>> >>>>>> Files >>>>>> ----- >>>>>> >>>>>> The files are available here: >>>>>> >>>>>> https://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:[email protected] >>>>>> To unsubscribe send an email to >>>>>> mailto:[email protected] >>>>>> >>>>>> <rfc9763_bgj.xml>-- >>>>>> auth48archive mailing list -- [email protected] To >>>>>> unsubscribe send an email to [email protected] >>>>> >>>> >>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
