Hi Roman (AD), This is a friendly reminder that we await your approval of Sections 3.1, 3.2, 4.1, 4.2, 5, and 6 as well as Appendix A and changes to the terms (validation and verification). The updates can be viewed here: https://www.rfc-editor.org/authors/rfc9763-auth48diff.html.
Best regards, RFC Editor/kc > On Apr 9, 2025, at 11:41 AM, Karen Moore <kmo...@staff.rfc-editor.org> wrote: > > 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%7Cd61e9a6ffc164f848a3e6eeff >>> 33e136b%7C0%7C0%7C638793935537134083%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e >>> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld >>> UIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=ZqjhV8B071Hw6T0Ef2YaLzsNoC9Fl05ka >>> 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%7Cd61e9a6ffc164f848a3e6eeff >>> 33e136b%7C0%7C0%7C638793935537146429%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e >>> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld >>> UIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=K%2FGnj7alnj%2FSva9oyGaLc8%2BI8Nv >>> vZJTBysw8TVAx%2FoY%3D&reserved=0 >>> >>> https://www/. >>> rfc-editor.org%2Fauthors%2Frfc9763.pdf&data=05%7C02%7Cmjjenki%40cyber. >>> nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164f848a3e6eeff >>> 33e136b%7C0%7C0%7C638793935537158443%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e >>> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld >>> UIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Qs8MdMZhS520Ds5bHT15hsuLZxeI5jV6p >>> kmxEOael9Y%3D&reserved=0 >>> >>> https://www/. >>> rfc-editor.org%2Fauthors%2Frfc9763.html&data=05%7C02%7Cmjjenki%40cyber >>> .nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164f848a3e6eef >>> f33e136b%7C0%7C0%7C638793935537170380%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 >>> eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl >>> dUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=HDM9U0Brl604w9MFGz75%2BNWcxhKy2r >>> 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%7Cmjje >>> nki%40cyber.nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164 >>> f848a3e6eeff33e136b%7C0%7C0%7C638793935537182638%7CUnknown%7CTWFpbGZsb >>> 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo >>> iTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=RPQuAUPjE%2FTphw37eVF >>> DUP%2BCSTXp7doX0WWQ%2F7bbkZQ%3D&reserved=0 >>> >>> https://www/. >>> rfc-editor.org%2Fauthors%2Frfc9763-auth48rfcdiff.html&data=05%7C02%7Cm >>> jjenki%40cyber.nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc >>> 164f848a3e6eeff33e136b%7C0%7C0%7C638793935537194513%7CUnknown%7CTWFpbG >>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO >>> IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=JxfzkF40eMr1jJHRv6 >>> 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%40 >>> cyber.nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164f848a3 >>> e6eeff33e136b%7C0%7C0%7C638793935537206549%7CUnknown%7CTWFpbGZsb3d8eyJ >>> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb >>> CIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=4reKQGpfVScLb%2F8AzjN7AKdFL >>> hnEHso7hTIQekzl%2Bzw%3D&reserved=0 >>> >>> https://www/. >>> rfc-editor.org%2Fauthors%2Frfc9763-rfcdiff.html&data=05%7C02%7Cmjjenki >>> %40cyber.nsa.gov%7Cc679b7ae8a9f45e1c02b08dd73b2f578%7Cd61e9a6ffc164f84 >>> 8a3e6eeff33e136b%7C0%7C0%7C638793935537218639%7CUnknown%7CTWFpbGZsb3d8 >>> eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW >>> FpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=1xRWX%2FzuMWKedp%2BXMWwW >>> 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%7Cd61e9a6ffc164f848a3e6eeff33e13 >>> 6b%7C0%7C0%7C638793935537230574%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG >>> kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy >>> fQ%3D%3D%7C60000%7C%7C%7C&sdata=icHIJjW%2B%2Bb2mpstpljZsgHJczcMhRgxLJK >>> 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
