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
