Hi Paul and *Authors, Thank you for your quick reply. We have noted your approval on the AUTH48 status page (https://www.rfc-editor.org/auth48/rfc9679).
*Authors, please confirm if any final checks need to be performed prior to publication per this comment: > The sourcecode type should be set to cbor-diag. We should validate these > source code blocks once more at the very end, using CBOR.me or similar. Note that we will ask IANA to update their registry per the recent update; we will inform you when complete. Best regards, RFC Editor/kc > On Dec 5, 2024, at 9:54 AM, Paul Wouters <paul.wout...@aiven.io> wrote: > > I approve, > > Thanks everyone for working this out and catching it before the RFC went out. > > Paul > > On Thu, Dec 5, 2024 at 12:45 PM Karen Moore <kmo...@amsl.com> wrote: > Hi Mike and *Paul (AD), > > Thanks for providing the updated XML file. The changes are now reflected in > our files. Hannes and Orie, we will assume your assent to these changes > unless we hear otherwise. > > *Paul, please review the following changes and let us know if you approve (we > updated item 3 and added item 4; see Mike’s explanation for the new changes > in the thread below). The updates can also be viewed here: > https://www.rfc-editor.org/authors/rfc9679-auth48diff.html. > > 1) Section 5.1 > > OLD: > The COSE Key Thumbprint is a digest of the essential parameters required > to represent the key as a COSE Key, rather than any additional data that > might accompany the key. > > NEW: > The COSE Key Thumbprint is a digest of the ordered essential > parameters needed to represent a COSE Key, with all other > parameters excluded. > > ... > 2) Section 5.3 > > OLD: > Any party in possession of a key that is represented as a COSE Key can > use the COSE Key Thumbprint. > > NEW: > The only prerequisites are that the COSE_Key representation > of the key be defined and the party creating the COSE Key Thumbprint > be in possession of the necessary key material. > > … > 3) Addition of Section 5.5 > > NEW: > 5.5 Relationship to JSON Web Key Thumbprints > > The ckt of a COSE Key, as described in Section 7 of [RFC9052], and > the jkt of a JSON Web Key, as described in Section 4 of [RFC7517], > are different even when the underlying cryptographic key material is > the same. > > This document does not register a JWT confirmation method [RFC7800] > for using "ckt" as a confirmation method for a JWT or a CWT > confirmation method [RFC8747] for using "jkt" as a confirmation > method for a CWT. > > ... > 4) Section 5.6 - please review the file for the changes to this section. > > … > 5) Section 8 > > OLD: > Confirmation Method Name: ckt > Confirmation Method Description: COSE Key SHA-256 Thumbprint > JWT Confirmation Method Name: jkt > > NEW: > Confirmation Method Name: ckt > Confirmation Method Description: COSE Key SHA-256 Thumbprint > JWT Confirmation Method Name: (none) > > > —FILES (please refresh)— > > The updated XML file is here: > https://www.rfc-editor.org/authors/rfc9679.xml > > The updated output files are here: > https://www.rfc-editor.org/authors/rfc9679.txt > https://www.rfc-editor.org/authors/rfc9679.pdf > https://www.rfc-editor.org/authors/rfc9679.html > > This diff file shows all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9679-auth48diff.html > > These diff files show only changes made during the last edit round: > https://www.rfc-editor.org/authors/rfc9679-lastdiff.html > https://www.rfc-editor.org/authors/rfc9679-lastrfcdiff.html > > This diff file shows all changes made to date: > https://www.rfc-editor.org/authors/rfc9679-diff.html > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9679 > > Thank you, > RFC Editor/kc > > > > On Dec 4, 2024, at 3:08 PM, Michael Jones <michael_b_jo...@hotmail.com> > > wrote: > > > > Folks, I hate to do this, but in reviewing the newly added section, I > > realized that it was incorrectly using the term "claim". In both RFC 7800 > > and RFC 8747, "cnf" is a claim, whereas the JWT and CWT confirmation > > members are referred to as "members" - not "claims". Then I realized there > > other places in the draft this the term "claim" was incorrectly used. > > > > The attached updated source file makes the needed corrections. For easier > > reviewing, a diff from the RFC Editor's source also follows. > > > > RFC Editor, please apply these edits and send out a new draft for review. > > > > Thanks, > > -- Mike (writing as a COSE chair) > > > > diff rfc9679.xml rfc9679_mbj.xml > > 46c46 > > < <date year="2024" month="October"/> > > --- > >> <date year="2024" month="December"/> > > 284,285c284,288 > > < This document does not register a JWT claim for using ckt as a > > confirmation > > < method for a JWT or a CWT claim for using jkt as a confirmation method > > for a CWT. > > --- > >> This document does not register > >> a JWT confirmation method <xref target="RFC7800"/> > >> for using "ckt" as a confirmation method for a JWT > >> or a CWT confirmation method <xref target="RFC8747"/> > >> for using "jkt" as a confirmation method for a CWT. > > 293,294c296,297 > > < <t>The proof-of-possession key is identified using the "ckt" > > claim, > > < the COSE Key Thumbprint claim. This claim contains the value of > > --- > >> <t>The proof-of-possession key is identified using the "ckt" member > >> of > >> the CWT confirmation claim "cnf". This member contains the value of > > 299c302 > > < claim. In this approach, the issuer of a CWT declares that the > > --- > >> member. In this approach, the issuer of a CWT declares that the > > 302c305 > > < of the key by including a "ckt" claim in the CWT.</t> > > --- > >> of the key by including a "ckt" CWT confirmation method member in the > >> CWT.</t> > > 304c307 > > < <t>The following example demonstrates the use of the "ckt" claim > > --- > >> <t>The following example demonstrates the use of the "ckt" member > > 319,320c322,323 > > < <t><xref target="IANA"/> registers the "ckt" claim and the > > confirmation method. > > < The "ckt" claim is expected to be used in the "cnf" claim.</t> > > --- > >> <t><xref target="IANA"/> registers the "ckt" CWT confirmation > >> method member. > >> The "ckt" member is used in the "cnf" claim.</t> > > 510a514 > >> <xi:include > >> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7800.xml%22/> > > > > On Dec 4, 2024, at 12:12 PM, Karen Moore <kmo...@amsl.com> wrote: > > > > Hi Orie and *Paul (AD), > > > > We have updated the text with your additional suggested edits; the changes > > are now reflected in our files (links below). We now await approvals from > > Hannes and Paul. > > > > *Paul, please review the following changes and let us know if you approve. > > The updates can also be viewed here: > > https://www.rfc-editor.org/authors/rfc9679-auth48diff.html. > > > > 1) Section 5.1 > > > > OLD: > > The COSE Key Thumbprint is a digest of the essential parameters required > > to represent the key as a COSE Key, rather than any additional data that > > might accompany the key. > > > > NEW: > > The COSE Key Thumbprint is a digest of the ordered essential > > parameters needed to represent a COSE Key, with all other > > parameters excluded. > > > > ... > > 2) Section 5.3 > > > > OLD: > > Any party in possession of a key that is represented as a COSE Key can > > use the COSE Key Thumbprint. > > > > NEW: > > The only prerequisites are that the COSE_Key representation > > of the key be defined and the party creating the COSE Key Thumbprint > > be in possession of the necessary key material. > > > > … > > 3) Addition of Section 5.5 > > > > NEW: > > 5.5 Relationship to JSON Web Key Thumbprints > > > > The ckt of a COSE Key, as described in Section 7 of [RFC9052], and the > > jkt of a JSON Web Key, > > as described in Section 4 of RFC 7517, are different even when the > > underlying cryptographic > > key material is the same. > > > > This document does not register a JWT claim for using ckt as a > > confirmation > > method for a JWT or a CWT claim for using jkt as a confirmation method > > for a CWT. > > > > … > > 4) Section 8 > > > > OLD: > > Confirmation Method Name: ckt > > Confirmation Method Description: COSE Key SHA-256 Thumbprint > > JWT Confirmation Method Name: jkt > > > > NEW: > > Confirmation Method Name: ckt > > Confirmation Method Description: COSE Key SHA-256 Thumbprint > > JWT Confirmation Method Name: (none) > > > > > > —FILES (please refresh)— > > > > The updated XML file is here: > > https://www.rfc-editor.org/authors/rfc9679.xml > > > > The updated output files are here: > > https://www.rfc-editor.org/authors/rfc9679.txt > > https://www.rfc-editor.org/authors/rfc9679.pdf > > https://www.rfc-editor.org/authors/rfc9679.html > > > > This diff file shows all changes made during AUTH48: > > https://www.rfc-editor.org/authors/rfc9679-auth48diff.html > > > > These diff files show only changes made during the last edit round: > > https://www.rfc-editor.org/authors/rfc9679-lastdiff.html > > https://www.rfc-editor.org/authors/rfc9679-lastrfcdiff.html > > > > This diff file shows all changes made to date: > > https://www.rfc-editor.org/authors/rfc9679-diff.html > > > > For the AUTH48 status of this document, please see: > > https://www.rfc-editor.org/auth48/rfc9679 > > > > Thank you, > > RFC Editor/kc > > > > > >> On Dec 4, 2024, at 7:26 AM, Orie Steele <orie@transmute.industries> wrote: > >> > >> Thank you! > >> > >> "cose key" should be "COSE Key", > >> > >> We could add "COSE Key as described in Section 7 of RFC9052" and "JSON Web > >> Key, as described in Section 4 of RFC7517" > >> > >> If the citations are helpful... This is a style nit. > >> > >> I approve of the changes. > >> > >> On Tue, Dec 3, 2024 at 3:48 PM Karen Moore <kmo...@amsl.com> wrote: > >> Authors, > >> > >> Thank you for the discussion and suggested changes. Our files now reflect > >> the updates below (see > >> <https://www.rfc-editor.org/authors/rfc9679-lastrfcdiff.html> for a > >> snapshot of the changes). Please review and let us know if these changes > >> are agreeable or if any further updates are needed. We will then ask the > >> AD to approve them. > >> > >> 1) Section 5.3 > >> > >> OLD: > >> Any party in possession of a key that is represented as a COSE Key can > >> use the COSE Key Thumbprint. > >> > >> NEW: > >> The only prerequisites are that the COSE_Key representation > >> of the key be defined and the party creating the COSE Key Thumbprint > >> be in possession of the necessary key material. > >> > >> ... > >> 2) Addition of New Section. Note that we made “json web key” uppercase for > >> consistency. > >> > >> NEW: > >> 5.5 Relationship to JSON Web Key Thumbprints > >> > >> The ckt of a cose key and jkt of a JSON Web Key are different, even when > >> underlying cryptographic key material is the same. > >> > >> This document does not register a JWT claim for using ckt as a > >> confirmation > >> method for a JWT or a CWT claim for using jkt as a confirmation method > >> for a CWT. > >> > >> ... > >> 3) Section 8 > >> > >> OLD: > >> Confirmation Method Name: ckt > >> Confirmation Method Description: COSE Key SHA-256 Thumbprint > >> JWT Confirmation Method Name: jkt > >> > >> NEW: > >> Confirmation Method Name: ckt > >> Confirmation Method Description: COSE Key SHA-256 Thumbprint > >> JWT Confirmation Method Name: (none) > >> > >> > >> —FILES (please refresh)— > >> > >> The updated XML file is here: > >> https://www.rfc-editor.org/authors/rfc9679.xml > >> > >> The updated output files are here: > >> https://www.rfc-editor.org/authors/rfc9679.txt > >> https://www.rfc-editor.org/authors/rfc9679.pdf > >> https://www.rfc-editor.org/authors/rfc9679.html > >> > >> This diff file shows all changes made during AUTH48: > >> https://www.rfc-editor.org/authors/rfc9679-auth48diff.html > >> > >> These diff files show only changes made during the last edit round: > >> https://www.rfc-editor.org/authors/rfc9679-lastdiff.html > >> https://www.rfc-editor.org/authors/rfc9679-lastrfcdiff.html > >> > >> This diff file shows all changes made to date: > >> https://www.rfc-editor.org/authors/rfc9679-diff.html > >> > >> For the AUTH48 status of this document, please see: > >> https://www.rfc-editor.org/auth48/rfc9679 > >> > >> Thank you, > >> RFC Editor/kc > >> > >>> On Dec 3, 2024, at 7:55 AM, Hannes Tschofenig > >>> <hannes.tschofe...@gmail.com> wrote: > >>> > >>> Thanks for the insightful comment, Orie. I agree with your proposed edits > >>> for the IANA consideration section and the extra text before the section > >>> on relationship to certificate thumbprints. > >>> > >>> I am also fine with the additional text Mike proposed. > >>> > >>> It is indeed too late to add new functionality at this point in time. > >>> > >>> Ciao > >>> Hannes > >>> > >>> > >>> On Tue, Dec 3, 2024 at 3:13 AM Michael Jones > >>> <michael_b_jo...@hotmail.com> wrote: > >>> I support adding the section that Orie proposed. > >>> > >>> > >>> > >>> However in reviewing related text, I unfortunately found a problem. > >>> Reading > >>> https://datatracker.ietf.org/doc/html/draft-ietf-cose-key-thumbprint-06#section-5.3, > >>> it differs from https://www.rfc-editor.org/rfc/rfc7638#section-3.5 in a > >>> counterproductive and overly restrictive way. Please change: > >>> > >>> > >>> > >>> Any party in possession of a key that is represented as a COSE Key can > >>> > >>> use the COSE Key Thumbprint. > >>> > >>> > >>> > >>> to: > >>> > >>> > >>> > >>> The only prerequisites are that the COSE_Key representation > >>> > >>> of the key be defined and the party creating the COSE Key Thumbprint > >>> > >>> be in possession of the necessary key material. > >>> > >>> > >>> > >>> That way it will be more actionable and will parallel the corresponding > >>> RFC 7638 text. > >>> > >>> > >>> > >>> Thanks all, > >>> > >>> -- Mike > >>> > >>> > >>> > >>> From: Orie Steele <orie@transmute.industries> > >>> Sent: Monday, December 2, 2024 5:55 PM > >>> To: Michael Jones <michael_b_jo...@hotmail.com> > >>> Cc: Hannes Tschofenig <hannes.tschofe...@gmail.com>; Hannes Tschofenig > >>> <hannes.tschofe...@gmx.net>; RFC Editor <rfc-edi...@rfc-editor.org>; > >>> Isobe Kohei <isobeko...@gmail.com>; cose-...@ietf.org; Cose Chairs Wg > >>> <cose-cha...@ietf.org>; Paul Wouters <paul.wout...@aiven.io>; > >>> auth48archive <auth48archive@rfc-editor.org> > >>> Subject: Re: AUTH48: RFC-to-be 9679 <draft-ietf-cose-key-thumbprint-06> > >>> for your review > >>> > >>> > >>> > >>> Let's add a section to the document, before the section on relationship > >>> to certificate thumbprints. > >>> > >>> > >>> > >>> 5.5 Relationship to JSON Web Key Thumbprints > >>> > >>> > >>> > >>> The ckt of a cose key, and jkt of a json web key are different, even when > >>> underlying cryptographic key material is the same. > >>> > >>> > >>> > >>> This document does not register a JWT claim for using ckt as a > >>> confirmation method for a JWT, or a CWT claim for using jkt as a > >>> confirmation method for a CWT. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Mon, Dec 2, 2024, 6:26 PM Orie Steele <orie@transmute.industries> > >>> wrote: > >>> > >>> I agree, let's just stick with the simple (none) solution. > >>> > >>> > >>> > >>> Hannes can you approve or suggest changes to the clarifying text that > >>> makes it clear this is not an oversight? > >>> > >>> > >>> > >>> Mike, do you object to that clarifying text assuming we take you change > >>> to the IANA considerations section? > >>> > >>> > >>> > >>> OS > >>> > >>> > >>> > >>> On Mon, Dec 2, 2024, 5:56 PM Michael Jones <michael_b_jo...@hotmail.com> > >>> wrote: > >>> > >>> I’m either fine with Orie’s proposed change to the registration wording > >>> or the following one: > >>> > >>> > >>> > >>> From: > >>> > >>> Confirmation Method Name: ckt > >>> Confirmation Method Description: COSE Key SHA-256 Thumbprint > >>> JWT Confirmation Method Name: jkt > >>> > >>> To: > >>> > >>> Confirmation Method Name: ckt > >>> Confirmation Method Description: COSE Key SHA-256 Thumbprint > >>> JWT Confirmation Method Name: (none) > >>> > >>> For the record, I’m not OK trying to add a ckt JWT “cnf” method as an > >>> AUTH48 action (despite me appreciating Orie’s discussion of the > >>> possibility). > >>> > >>> > >>> > >>> Cheers, > >>> > >>> -- Mike > >>> > >>> > >>> > >>> From: Orie Steele <orie@transmute.industries> > >>> Sent: Monday, December 2, 2024 2:55 PM > >>> To: Hannes Tschofenig <hannes.tschofe...@gmail.com> > >>> Cc: Hannes Tschofenig <hannes.tschofe...@gmx.net>; RFC Editor > >>> <rfc-edi...@rfc-editor.org>; Isobe Kohei <isobeko...@gmail.com>; > >>> cose-...@ietf.org; Cose Chairs Wg <cose-cha...@ietf.org>; Michael Jones > >>> <michael_b_jo...@hotmail.com>; Paul Wouters <paul.wout...@aiven.io>; > >>> auth48archive@rfc-editor.org > >>> Subject: Re: AUTH48: RFC-to-be 9679 <draft-ietf-cose-key-thumbprint-06> > >>> for your review > >>> > >>> > >>> > >>> This is indeed a bug, for extra assurance that it is a problem: > >>> > >>> How would you use a ckt to verify a JWT that was using "cnf"? > >>> > >>> Here is a more complete fix for the bug: > >>> > >>> https://datatracker.ietf.org/doc/html/draft-ietf-cose-key-thumbprint-06#section-5.3 > >>> > >>> Note that the ckt of a cose key, and jkt of a json web key are different, > >>> even when underlying cryptographic key material is the same. > >>> > >>> ckt is a binary string and jkt is always a base64url string encoded as > >>> described in section 6.1 of RFC9449. > >>> To use a ckt claim inside a JWT, the ckt claim value MUST be base64url > >>> encoded. > >>> The example provided in section 6.1 of RFC9449 is modified to distinguish > >>> confirmation with a CKT instead of JKT: > >>> { > >>> "sub":"some...@example.com", > >>> "iss":"https://server.example.com";, > >>> "nbf":1562262611, > >>> "exp":1562266216, > >>> "cnf": { > >>> "ckt":"SWvYr63zB-WwjGSwQhv53AFSijRKQ72oj63RZp2iU-w" > >>> } > >>> } > >>> > >>> I used the same base64url encoded thumbprint the draft already used for > >>> extra clarity. > >>> > >>> ckt would also need to be added here: > >>> https://www.iana.org/assignments/jwt/jwt.xhtml#confirmation-methods > >>> > >>> This kind of change might need to be taken to the relevant lists for > >>> review... and maybe another WGLC. > >>> > >>> ... we could leave the "ckt" in JWT cnf registration to another document, > >>> but I think at a minimum we need something added to section 5.3 to the > >>> effect of: > >>> > >>> Note that the ckt of a cose key, and jkt of a json web key are different, > >>> even when underlying cryptographic key material is the same. > >>> ckt is a binary string and jkt is always a base64url string encoded as > >>> described in section 6.1 of RFC9449. > >>> > >>> ^ If we are comfortable with this change alone, we still have a problem > >>> with the registration template: > >>> https://www.rfc-editor.org/rfc/rfc8747.html#name-registration-template > >>> > >>> """ > >>> CWT claims should normally have a corresponding JWT claim. If a > >>> corresponding JWT claim would not make sense, the designated experts can > >>> choose to accept registrations for which the JWT Claim Name is listed as > >>> "N/A". > >>> """ > >>> > >>> The logical JWT claim is "ckt"... not "jkt"... so N/A... does not make > >>> sense... and leaving it blank also does not make sense. > >>> > >>> There is also the x5t claim which sets the precedent that ckt is for cose > >>> key, jkt is for json web key, and x5t is for x.509 certs. > >>> > >>> I propose: > >>> > >>> From: > >>> > >>> Confirmation Method Name: ckt > >>> Confirmation Method Description: COSE Key SHA-256 Thumbprint > >>> JWT Confirmation Method Name: jkt > >>> > >>> To: > >>> > >>> Confirmation Method Name: ckt > >>> Confirmation Method Description: COSE Key SHA-256 Thumbprint > >>> JWT Confirmation Method Name: Not assigned by RFCXXXX ( not to be > >>> confused with x5t or jkt ) > >>> > >>> > >>> OS > >>> > >>> > >>> > >>> On Mon, Dec 2, 2024 at 4:14 PM Hannes Tschofenig > >>> <hannes.tschofe...@gmail.com> wrote: > >>> > >>> Thanks for the work on the draft and sorry for the slow response. > >>> > >>> > >>> > >>> I read through the draft carefully today and in general the edits look > >>> good but I noticed a possible bug. > >>> > >>> > >>> > >>> In the IANA consideration section we say that the ckt confirmation method > >>> maps to the jkt JWT configuration method. I double-checked RFC 9449, > >>> which defines the jkt, and it defines the computation as follows: > >>> > >>> " > >>> The value of the jkt member MUST be the base64url encoding > >>> > >>> of the JWK SHA-256 Thumbprint. > >>> " > >>> > >>> In draft-ietf-cose-key-thumbprint-06 we define the ckt thumbprint as the > >>> hash of the deterministic encoding of the COSE_Key structure. > >>> > >>> > >>> > >>> So, the question to me is whether we can even map the ckt to the jkt > >>> since the underlying structure that is hashed is different: JWK vs. > >>> COSE_Key structure. > >>> > >>> > >>> > >>> For that reason I believe it would be more correct to change the IANA > >>> consideration section by omitting the JWT Confirmation Method Name. > >>> > >>> Here is the proposed change: > >>> > >>> From: > >>> > >>> Confirmation Method Name: ckt > >>> Confirmation Method Description: COSE Key SHA-256 Thumbprint > >>> JWT Confirmation Method Name: jkt > >>> > >>> > >>> To: > >>> > >>> Confirmation Method Name: ckt > >>> Confirmation Method Description: COSE Key SHA-256 Thumbprint > >>> JWT Confirmation Method Name: > >>> > >>> > >>> Do you agree with me? > >>> > >>> > >>> > >>> Sorry for noticing this issue only now. > >>> > >>> > >>> > >>> Ciao > >>> > >>> Hannes > >>> > >>> > >>> > >>> Betreff: > >>> > >>> AUTH48: RFC-to-be 9679 <draft-ietf-cose-key-thumbprint-06> for your review > >>> > >>> Datum: > >>> > >>> Mon, 21 Oct 2024 14:30:59 -0700 (PDT) > >>> > >>> Von: > >>> > >>> rfc-edi...@rfc-editor.org > >>> > >>> An: > >>> > >>> isobeko...@gmail.com, hannes.tschofe...@gmx.net, orie@transmute.industries > >>> > >>> Kopie (CC): > >>> > >>> rfc-edi...@rfc-editor.org, cose-...@ietf.org, cose-cha...@ietf.org, > >>> michael_b_jo...@hotmail.com, paul.wout...@aiven.io, > >>> auth48archive@rfc-editor.org > >>> > >>> > >>> > >>> *****IMPORTANT***** > >>> > >>> Updated 2024/10/21 > >>> > >>> 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 > >>> * rfc-edi...@rfc-editor.org (the RPC team) > >>> > >>> * other document participants, depending on the stream (e.g., IETF Stream > >>> participants are your working group chairs, the responsible ADs, and the > >>> document shepherd). > >>> * auth48archive@rfc-editor.org, which is a new archival mailing list to > >>> preserve AUTH48 conversations; it is not an active discussion list: > >>> * More info: > >>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > >>> * The archive itself: > >>> https://mailarchive.ietf.org/arch/browse/auth48archive/ > >>> > >>> * Note: If only absolutely necessary, you may temporarily opt out of the > >>> archiving of messages (e.g., to discuss a sensitive matter). > >>> If needed, please add a note at the top of the message that you have > >>> dropped the address. When the discussion is concluded, > >>> auth48archive@rfc-editor.org will be re-added to the CC list and its > >>> addition will be noted at the top of the message. > >>> You may submit your changes in one of two ways: > >>> > >>> An update to the provided XML file > >>> — OR — > >>> An explicit list of changes in this format > >>> > >>> Section # (or indicate Global) > >>> > >>> OLD: > >>> old text > >>> > >>> NEW: > >>> new text > >>> > >>> You do not need to reply with both an updated XML file and an explicit > >>> list of changes, as either form is sufficient. > >>> > >>> We will ask a stream manager to review and approve any changes that seem > >>> beyond editorial in nature, e.g., addition of new text, deletion of text, > >>> and technical changes. Information about stream managers can be found in > >>> the FAQ. Editorial changes do not require approval from a stream manager. > >>> > >>> > >>> Approving for publication > >>> -------------------------- > >>> > >>> To approve your RFC for publication, please reply to this email stating > >>> that you approve this RFC for publication. Please use ‘REPLY ALL’, > >>> as all the parties CCed on this message need to see your approval. > >>> > >>> > >>> Files ----- > >>> > >>> The files are available here: > >>> https://www.rfc-editor.org/authors/rfc9679.xml > >>> https://www.rfc-editor.org/authors/rfc9679.html > >>> https://www.rfc-editor.org/authors/rfc9679.pdf > >>> https://www.rfc-editor.org/authors/rfc9679.txt > >>> > >>> Diff file of the text: > >>> https://www.rfc-editor.org/authors/rfc9679-diff.html > >>> https://www.rfc-editor.org/authors/rfc9679-rfcdiff.html (side by side) > >>> > >>> Diff of the XML: https://www.rfc-editor.org/authors/rfc9679-xmldiff1.html > >>> > >>> > >>> Tracking progress > >>> ----------------- > >>> > >>> The details of the AUTH48 status of your document are here: > >>> https://www.rfc-editor.org/auth48/rfc9679 > >>> > >>> Please let us know if you have any questions. > >>> Thank you for your cooperation, > >>> > >>> RFC Editor > >>> > >>> -------------------------------------- > >>> RFC9679 (draft-ietf-cose-key-thumbprint-06) > >>> > >>> Title : CBOR Object Signing and Encryption (COSE) Key Thumbprint > >>> Author(s) : K. Isobe, H. Tschofenig, O. Steele > >>> WG Chair(s) : Matthew A. Miller, Ivaylo Petrov, Michael B. Jones > >>> > >>> Area Director(s) : Deb Cooley, Paul Wouters > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> > >>> > >>> ORIE STEELE > >>> Chief Technology Officer > >>> www.transmute.industries > >>> > >> > >> > >> > >> -- > >> > >> ORIE STEELE > >> Chief Technology Officer > >> www.transmute.industries > >> > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
