Inline:
On Thu, Jun 29, 2023 at 3:09 PM Michael Jones <[email protected]> wrote: > Thanks, Orie. Replies inline in green. > > > > *From:* Orie Steele <[email protected]> > *Sent:* Monday, June 26, 2023 11:03 AM > *To:* Michael Jones <[email protected]> > *Cc:* AJITOMI Daisuke <[email protected]>; Cose Chairs Wg < > [email protected]>; cose <[email protected]>; Mike Prorock < > [email protected]>; Ivaylo Petrov <[email protected]>; Tobias Looker > <[email protected]> > *Subject:* Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-in-headers > > > > Inline: > > > > On Mon, Jun 26, 2023 at 12:36 PM Michael Jones < > [email protected]> wrote: > > 1. Answering your first question, yes, the equivalent CWT header would be { > alg, kid, cwt-claims (TBD): { iss, cnf, exp, sub } }. > > > Awesome... One comment is that this could make "key discovery" slightly > more complicated, and also in general `iss` will NEVER be allowed as a top > level COSE Header, which will impact key discovery for SCITT, KT or other > systems that might have wished to mirror JWT 1:1... > > Concretely, a verifier / RP might need to pull `iss` from TBD, and then > find the corresponding `kid`. > > > > Yes, a verifier/RP could pull “iss” from the new claims-in-headers header > parameter and use it as part of its matching logic (some of which could > also utilize other header parameter values). > Yes, thank you! > > Or the verifier might choose to ignore `iss` completely, and just rely on > `kid`. > > > > > 2. Is it possible to promote "reserved claim names" across serializations? > > Applications could choose to do this if they have a reason to do so. This > proposed standard doesn’t say anything about JSON. It’s intentionally very > focused in its scope. > > > Interesting, see my comment below: > > > 3. Is it possible to secure "application/json" using CWTs that have this > new header parameter? > > Strictly speaking, CWTs always have a CBOR claims set as their body. > > > This is the same as saying you can't promote cross serialization, IMO.... > it also precludes calling certain "COSE Sign1" examples "CWTs"... > I can imagine that impacting how a lot of other documents might or might > not use `iss`, or `cnf`. > > It’s fine to secure a JSON payload with COSE_Sign or COSE_Sign1. Just > like it’s fine to secure a CBOR payload with JWS. Neither of those are > conforming JWTs or CWTs, nor do they need to be. > > > > But being positive about your points, going further, it’s fine for the > JSON payload secured with COSE to use registered JWT claims; it’s likewise > fine for the CBOR payload secured with JWS to use registered CWT claims. > There may be application reasons to do either or both, which is fine. > > > Agreed. > They could also choose to use this new header parameter to include some > CBOR claims in the headers. > > > > > We have several use cases related to this at SCITT, but we specifically > don't use CWT because of the ambiguity regarding content type. > > So SCITT wants to secure non-CBOR payloads with COSE_Sign? That’s fine > and I have no problem with that not being called a CWT. That said, if > SCITT is securing sets of CBOR claims with COSE_Sign, using CWT for that > would be appropriate. > > > > Again, applications could choose to mix COSE and JSON, but that would no > longer be a CWT. > > > Right, so the `content_type` header parameter should never be used with a > CWT, since it's assumed to always be CBOR. > > So for example you might never see a CWT header that looks like this: > > { alg, kid, content_type: application/spdx+json, cwt-claims (TBD): { iss, > cnf, exp, sub } } > > That’s a perfectly legal COSE_Sign header. > > > As a consequence CWT is not suitable for general purpose signatures over > arbitrary content types, > and COSE Sign1 with cwt-claims (TBD): { iss, cnf, exp, sub } }, could > still be a solution even though the payload is technically not a CWT. > > > > It’s COSE_Sign and JWS that are suitable for signatures over arbitrary > content types. If that’s what SCITT is doing, I’d describe it that way. > > > > Of course, if JWS is used to sign a JSON Claims set, the result is a JWT; > and if COSE_Sign is used to sign a CBOR Claims Set, the result is a CWT. > > > Yes, agreed. > I think that is confusing enough to add some explicit text, warning > against it or at least commenting on it. > > I’m not sure what specifically you find confusing about the current draft > or what you’d like us to warn or comment about. For instance, nothing > about securing JSON is in scope for CWT or this draft, but that’s not what > either of them are about. Warning about not being able to do something > that’s not in scope could more confuse than help people. But I may be > entirely missing your point. > > > > What specific warning text would you like to be inserted where into the > draft? (Or maybe you’re talking about your suggestions below.) > > > > Does that help? > > > Yes, I think you should clarify the following: > > 1. cwt-claims (TBD) MAY be present in the protected header, even when > `content_type` is present and the payload is NOT CBOR. > > > > We can say that. In particular, we can include a clear statement that the > CWT-claims-in-headers header parameter can be used for arbitrary COSE > objects, whether the payload being secured is a CBOR CWT Claims Set or > not. Is that the main point you’re trying to get at? > > > Yes exactly, the header parameter is useful even when the claimset is not CBOR. > 2. typ AFAIK it's not reserved at the top level, so there is no way to > subtype a CWT following the same best practices as the JWT BCP: > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-bcp-07#section-3.11 > > > > I agree that that’s a problem that should be fixed, but in a different > spec. If no one else is actively doing, it, I willing to write that spec > and present it at IETF next month. It will be very short. And it will > cite wanting to do the equivalent of JWT BCP explicit typing for CWTs as > one of the motivations. Of course, it would be generally useful, just like > the JWS “typ” parameter is. > > > Agreed as well, happy to help with that. > 2 seems related to 1 in that we are not really sure how to distinguish > "types" of CWT and "types" of CWT payload. > > > > Agreed > > > It seems fine to request a registration for `typ` in another document, but > if it would be possible to address it at the same time as clarifying > `content_type` that does seem desirable. > > Especially given we already have requests to register +cwt as a > structured suffix: > https://www.ietf.org/archive/id/draft-ietf-rats-eat-media-type-02.html#section-6.1 > > > > While this is off-topic for this draft, I’m curious, how’s the +cwt > registration progressing? Any estimate of when the registration might > occur? > > > Latest update I have seen on +cwt: https://mailarchive.ietf.org/arch/msg/media-types/WYpYmm8kOuATyx7vSbjmpp7Xa4k/ There is also +cose which is newer: https://mailarchive.ietf.org/arch/msg/media-types/RYZNRLiFA1ll9K8dS7kK_2GaNRg/ > Today, there would be no way to use this structured suffix, in a CWT > similar to how other structured suffixes are used for JWT: > > typ: application/secevent+jwt > typ: application/secevent+cwt > > This will likely cause wrinkles for anyone trying to upgrade from a BCP > following JWT based implementation to a CWT one that attempts to align with > the JWT BCP. > > Agreed. These are gaps we should address, as described above. > You answered all my questions, the only action I see remaining is what you offered here: *Include a clear statement that the CWT-claims-in-headers header parameter can be used for arbitrary COSE objects, whether the payload being secured is a CBOR CWT Claims Set or not.* I support adding such a sentence. > OS > > Thanks again, > > -- Mike > > > > -- Mike > > > > *From:* Orie Steele <[email protected]> > *Sent:* Tuesday, June 20, 2023 9:51 AM > *To:* Michael Jones <[email protected]> > *Cc:* AJITOMI Daisuke <[email protected]>; Cose Chairs Wg < > [email protected]>; cose <[email protected]>; Mike Prorock < > [email protected]>; Ivaylo Petrov <[email protected]>; Tobias Looker < > [email protected]> > *Subject:* Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-in-headers > > > > I want to confirm my understanding of this paragraph: > > > Directly including CWT claim values as COSE header parameter values > would not work, since there are conflicts between the numeric header > parameter assignments and the numeric CWT claim assignments. Instead, this > specification defines a single header parameter registered in the IANA > "COSE Header Parameters" registry that creates a location to store CWT > claims in a COSE header parameter. > > So for example, in a JWT header looks like this: > > { iss, kid, alg, cnf, iat, exp, sub } > > The equivalent CWT header would look like this: > > { alg, kid, cwt-claims (TBD): { iss, cnf, exp, sub } } > > This would impact key discovery for the issuer of the token, since they > would need to review both top level header parameters such as "alg" and > "kid' which are already registered. > > As well as CWT claims, such as "iss"... > > Another related question... is the value for the "claimset" of a CWT, to > be any content type? or MUST a CWT only secure CBOR content? > > For example, consider the hypothetical CWT: > > COSESign1 // Tag 18 [ > protected header: { alg, kid, content_type: application/json, cwt-claims: > { iss, sub, cnf, iat, exp, nbf } } > unprotected header: { counter signature } > claimset / payload: { iss, sub, cnf} (as JSON) > signature > ] > > In other words: > > Is it possible to promote "reserved claim names" across serializations? > > Is it possible to secure "application/json" using CWTs that have this new > header parameter? > > Regards, > > OS > > > > On Mon, Jun 19, 2023 at 1:55 PM Michael Jones <[email protected]> > wrote: > > 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 > > > > > -- > > > > > *ORIE STEELE *Chief Technology Officer > www.transmute.industries > > <https://transmute.industries/> > > > > > -- > > > > > *ORIE STEELE *Chief Technology Officer > www.transmute.industries > > <https://transmute.industries/> > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
