>
> 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

Reply via email to