Thank you for sharing your opinions (both on list and off list) and for the good discussion! With -06 published, my understanding is that all outstanding issues raised during the WGLC have been addressed and given the positive feedback and the lack of negative feedback, the chairs will move this document further in the process.
If anyone is interested in shepherding this document, please let us know. Otherwise I will assign myself. Thank you, -- Ivaylo On Thu, Jul 6, 2023 at 1:50 PM AJITOMI Daisuke <[email protected]> wrote: > As for “enforcement power”, the registrations ensure that those parameters >> can be used in JWEs. But the registrations don’t prevent them from being >> used in other ways or for other claims to be used. > > > Thanks for the explanation. I understand. > > Best, > Daisuke > > 2023年7月6日(木) 10:10 Michael Jones <[email protected]>: > >> Thanks for pointing out that the JOSE header parameter usage location >> registrations at >> https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-header-parameters >> for “iss”, “sub”, and “aud” were only for JWE. I believe that was an >> oversight on our part. >> >> >> >> As for “enforcement power”, the registrations ensure that those >> parameters can be used in JWEs. But the registrations don’t prevent them >> from being used in other ways or for other claims to be used. >> >> >> >> Thanks again for your careful attention to this specification! >> >> >> >> -- Mike >> >> >> >> *From:* AJITOMI Daisuke <[email protected]> >> *Sent:* Friday, June 30, 2023 8:47 PM >> *To:* Michael Jones <[email protected]> >> *Cc:* Cose Chairs Wg <[email protected]>; cose <[email protected]>; Mike >> Prorock <[email protected]>; Ivaylo Petrov <[email protected]>; Tobias >> Looker <[email protected]>; Orie Steele >> <[email protected]> >> *Subject:* Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-in-headers >> >> >> >> Hi Mke, >> >> >> >> I'm sorry for the late reply. I did not have any time to check the COSE >> WG mailing list for the past few weeks... >> And thank you for incorporating my comment into the latest draft. >> >> Your explanation helped me understand your design policy and thank you >> again, but I would like to add one thing because my previous comment may >> have been insufficient and lead to misunderstanding. >> >> In JWT, any claim can be duplicated to a header parameter. This is >> described in https://www.rfc-editor.org/rfc/rfc7519.html#section-5.3. >> There was no restriction on use in structures without payloads, etc. It’s >> a design goal of CWT to be as parallel to JWT as possible. Therefore, I >> don’t think it makes sense to impose restrictions on CWTs that were not >> made in JWTs. >> >> >> >> RFC7519#section-5.3 describes only the JWE thing but, as you pointed out, >> this section does not have any restrictions regarding the structures that >> can have JWT claims. >> >> However, The IANA Registry for JOSE ( >> https://www.iana.org/assignments/jose/jose.xhtml) have a "Header >> Parameter Usage Location(s)" column and it seems to me that it limits the >> use of JWT claims to JW"E". >> >> I'm not sure of the importance (enforcement power?) of the "Header >> Parameter Usage Location(s)" column, but from the perspective of aligning >> the constraints of CWT with JWT as much as possible, I pointed this out. >> >> >> I understand your policy of not wanting to impose constraints on the >> locations where the CWT claims can be used, without limiting the use cases. >> Therefore, I leave the final decision on whether to focus on the Encrypt >> structures or not up to you. Whichever you choose, I support the latest >> version being published. >> >> Best regards, >> >> Daisuke >> >> >> >> 2023年6月30日(金) 12:52 Michael Jones <[email protected]>: >> >> >> https://www.ietf.org/archive/id/draft-ietf-cose-cwt-claims-in-headers-05.html >> moves the statement about verifying that claim values present in both the >> header and payload are identical from the Security Considerations to the >> body of the specification. I’ll note that -04 already said that “It is >> RECOMMENDED that the CWT claims header parameter is used only in a >> protected header” and that remains in -05. >> >> >> >> Thanks again for your review, Daisuke. >> >> >> >> -- Mike >> >> >> >> *From:* Michael Jones >> *Sent:* Monday, June 19, 2023 11:56 AM >> *To:* AJITOMI Daisuke <[email protected]>; Cose Chairs Wg < >> [email protected]>; cose <[email protected]> >> *Cc:* Mike Prorock <[email protected]>; Ivaylo Petrov <[email protected]>; >> Tobias Looker <[email protected]>; Orie Steele < >> [email protected]> >> *Subject:* RE: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-in-headers >> >> >> >> Thanks for the review, Daisuke! Responses are inline below in green. >> >> >> >> *From:* AJITOMI Daisuke <[email protected]> >> *Sent:* Tuesday, May 2, 2023 3:57 PM >> *To:* Cose Chairs Wg <[email protected]>; cose <[email protected]> >> *Cc:* Mike Prorock <[email protected]>; Michael Jones < >> [email protected]>; Ivaylo Petrov <[email protected]>; Tobias >> Looker <[email protected]>; Orie Steele < >> [email protected]> >> *Subject:* Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-in-headers >> >> >> >> Hi authors, >> >> I read the draft for the first time today. I think it's basically fine, >> but there are some points I'm concerned about, so I'd like to make some >> comments from an imprementor's perspective. >> >> 1) I think it would be better to limit the COSE structures that can have >> the CWT claims parameter. >> >> >> Specifically, I think the use of the CWT claims parameter should be >> limited only for COSE_{Encrypt0, Encrypt} and the COSE structures without >> payloads (COSE structures with detached contents). I'm not sure whether it >> should be MUST, SHOULD or RECOMMENDED though. In JOSE as well, I believe >> the JWT claims were only partially usable (only "iss", "sub", "aud") in JWE. >> >> In JWT, any claim can be duplicated to a header parameter. This is >> described in https://www.rfc-editor.org/rfc/rfc7519.html#section-5.3. >> There was no restriction on use in structures without payloads, etc. It’s >> a design goal of CWT to be as parallel to JWT as possible. Therefore, I >> don’t think it makes sense to impose restrictions on CWTs that were not >> made in JWTs. >> >> >> 2) Similarly, I believe that there is no need to enable the use of the >> CWT claims parameter in COSE_Recipient or COSE_Signature, as it doesn't >> seem meaningful. >> >> >> >> If my understanding is correct, it might be helpful to mention this >> somewhere in the document. >> >> Successful specifications are used in ways that the authors never >> envisioned, provided they are written to enable general applicability. For >> instance, I never imagined JWTs would be used to secure Caller-ID, but that >> very thing has happened in the STIR working group, in specs such as RFC >> 8224. The same is already true of CWTs. Therefore, I’m very reluctant to >> limit the applicability of the CWT claims-in-headers feature because, as a >> general-purpose feature, we are unlikely to be able to guess the productive >> ways that it will be used. >> >> >> 3) I think it would be better to limit the use of the CWT claims >> parameter only to the protected header. >> >> I believe there is no need to leave room for using it in the unprotected >> header, as it would increase security concerns. >> >> >> >> I’m fine suggesting that use in the protected headers is preferred in the >> Security Considerations. But as above, it seems unwise to impose arbitrary >> restrictions on the applicability of the feature. >> >> >> >> 4) I think the following sentence in Security Considerations might be >> better written in the main body of this specification. Is there any reason >> not to write it in Chapter 2? >> >> "In cases where CWT claims are both present in the payload and the >> header, an application receiving such a structure MUST verify that their >> values are identical, unless the application defines other specific >> processing rules for these claims." >> >> I’m fine with promoting this sentence to the main body of the >> specification. >> >> >> If there are any off-the-mark comments due to my lack of understanding of >> the context, I apologize in advance. >> >> Not at all. I appreciate you taking the time to review the specification >> and make concrete suggestions. The “understanding the context” point is >> right on. Some of my responses above essentially say that we don’t have a >> crystal ball to gaze into to know the contexts in which the CWT feature >> will be used in advance. >> >> >> Best regards, >> AJITOMI Daisuke >> >> >> >> Best wishes, >> >> -- Mike >> >> >> >> 2023年4月28日(金) 7:53 Orie Steele <[email protected]>: >> >> I support publication. >> >> >> >> On Thu, Apr 27, 2023, 5:20 PM Mike Prorock <[email protected]> wrote: >> >> I believe that this is ready to go as well. >> >> Mike Prorock >> mesur.io >> >> >> >> On Thu, Apr 27, 2023, 15:31 Michael Jones <[email protected]> >> wrote: >> >> I believe that this specification is ready for publication. >> >> >> >> -- Mike >> >> >> >> *From:* Ivaylo Petrov <[email protected]> >> *Sent:* Thursday, April 27, 2023 1:23 PM >> *To:* [email protected]; Tobias Looker < >> [email protected]>; cose <[email protected]> >> *Cc:* Cose Chairs Wg <[email protected]> >> *Subject:* 🔔 WGLC of draft-ietf-cose-cwt-claims-in-headers >> >> >> >> Dear all, >> >> This message starts the formal Working Group Last Call of the >> draft-ietf-cose-cwt-claims-in-headers [1]. >> >> The working group last call will run for **two weeks**, ending on May 12, >> 2022. >> >> Please review and send any comments or feedback to the working >> group. Even if your feedback is "this is ready", please let us know. >> >> Thank you, >> >> - Mike and Ivaylo >> >> COSE Chairs >> >> [1]: >> https://www.ietf.org/archive/id/draft-ietf-cose-cwt-claims-in-headers-04.html >> >> _______________________________________________ >> COSE mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/cose >> >> _______________________________________________ >> COSE mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/cose >> >> _______________________________________________ >> COSE mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/cose >> >>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
