Dear IANA, Please make the following update to the “CWT Confirmation Methods” registry at <https://www.iana.org/assignments/cwt> to match the edited document at <https://www.rfc-editor.org/authors/rfc9679-diff.html>.
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) Thanks in advance! RFC Editor/kc > Begin forwarded message: > > From: Karen Moore <kmo...@amsl.com> > Subject: Re: [AD] AUTH48: RFC-to-be 9679 <draft-ietf-cose-key-thumbprint-06> > for your review > Date: December 5, 2024 at 10:25:03 AM PST > To: Paul Wouters <paul.wout...@aiven.io>, Hannes Tschofenig > <hannes.tschofe...@gmx.net>, Orie Steele <orie@transmute.industries>, Isobe > Kohei <isobeko...@gmail.com>, Hannes Tschofenig <hannes.tschofe...@gmail.com> > Cc: Michael Jones <michael_b_jo...@hotmail.com>, RFC Editor > <rfc-edi...@rfc-editor.org>, "cose-...@ietf.org" <cose-...@ietf.org>, Cose > Chairs Wg <cose-cha...@ietf.org>, auth48archive <auth48archive@rfc-editor.org> > > 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
