Hi Roman (AD), This is a friendly reminder that all authors have approved this document, and we now await your approval of the following:
- Sections 3.1, 3.2, 4.1, 4.2, 5, and 6 - Appendix A - Updates to the terms (validation and verification) The changes can be viewed 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 11:17 AM, Karen Moore <kmo...@staff.rfc-editor.org> wrote: > > 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
