Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-in-headers

[Michael Jones <[e-mail]>]

Thanks, Orie.  Replies inline in green.

From: Orie Steele <[e-mail]>
Sent: Monday, June 26, 2023 11:03 AM
To: Michael Jones <[e-mail]>
Cc: AJITOMI Daisuke <[e-mail]>; Cose Chairs Wg <[e-mail]>; cose <[e-mail]>; Mike Prorock <[e-mail]>; Ivaylo Petrov <[e-mail]>; Tobias Looker <[e-mail]>
Subject: Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-in-headers

Inline:

On Mon, Jun 26, 2023 at 12:36 PM Michael Jones <[e-mail]<mailto:[e-mail]>> 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).

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.

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.

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?

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.

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?

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.

OS
                                                       Thanks again,
                                                       -- Mike

                                                       -- Mike

From: Orie Steele <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, June 20, 2023 9:51 AM
To: Michael Jones <[e-mail]<mailto:[e-mail]>>
Cc: AJITOMI Daisuke <[e-mail]<mailto:[e-mail]>>; Cose Chairs Wg <[e-mail]<mailto:[e-mail]>>; cose <[e-mail]<mailto:[e-mail]>>; Mike Prorock <[e-mail]<mailto:[e-mail]>>; Ivaylo Petrov <[e-mail]<mailto:[e-mail]>>; Tobias Looker <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> wrote:
Thanks for the review, Daisuke!  Responses are inline below in green.

From: AJITOMI Daisuke <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, May 2, 2023 3:57 PM
To: Cose Chairs Wg <[e-mail]<mailto:[e-mail]>>; cose <[e-mail]<mailto:[e-mail]>>
Cc: Mike Prorock <[e-mail]<mailto:[e-mail]>>; Michael Jones <[e-mail]<mailto:[e-mail]>>; Ivaylo Petrov <[e-mail]<mailto:[e-mail]>>; Tobias Looker <[e-mail]<mailto:[e-mail]>>; Orie Steele <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>>:
I support publication.

On Thu, Apr 27, 2023, 5:20 PM Mike Prorock <[e-mail]<mailto:[e-mail]>> wrote:
I believe that this is ready to go as well.
Mike Prorock
mesur.io<http://mesur.io/>

On Thu, Apr 27, 2023, 15:31 Michael Jones <[e-mail]<mailto:[e-mail]>> wrote:
I believe that this specification is ready for publication.

                                                       -- Mike

From: Ivaylo Petrov <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, April 27, 2023 1:23 PM
To: [e-mail]<mailto:[e-mail]>; Tobias Looker <[e-mail]<mailto:[e-mail]>>; cose <[e-mail]<mailto:[e-mail]>>
Cc: Cose Chairs Wg <[e-mail]<mailto:[e-mail]>>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/cose


--



ORIE STEELE
Chief Technology Officer
www.transmute.industries<http://www.transmute.industries/>

[https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries/>


--



ORIE STEELE
Chief Technology Officer
www.transmute.industries<http://www.transmute.industries/>

[https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries/>