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

[Orie Steele <[e-mail]>]

Inline:


On Thu, Jun 29, 2023 at 3:09 PM Michael Jones <[e-mail]>
wrote:

> 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]> 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 <[e-mail]>
> *Sent:* Tuesday, June 20, 2023 9:51 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
>
>
>
> 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]>
> wrote:
>
> Thanks for the review, Daisuke!  Responses are inline below in green.
>
>
>
> *From:* AJITOMI Daisuke <[e-mail]>
> *Sent:* Tuesday, May 2, 2023 3:57 PM
> *To:* Cose Chairs Wg <[e-mail]>; cose <[e-mail]>
> *Cc:* Mike Prorock <[e-mail]>; Michael Jones <
> [e-mail]>; Ivaylo Petrov <[e-mail]>; Tobias
> Looker <[e-mail]>; Orie Steele <
> [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]>:
>
> I support publication.
>
>
>
> On Thu, Apr 27, 2023, 5:20 PM Mike Prorock <[e-mail]> wrote:
>
> I believe that this is ready to go as well.
>
> Mike Prorock
> mesur.io
>
>
>
> On Thu, Apr 27, 2023, 15:31 Michael Jones <[e-mail]>
> wrote:
>
> I believe that this specification is ready for publication.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Ivaylo Petrov <[e-mail]>
> *Sent:* Thursday, April 27, 2023 1:23 PM
> *To:* [e-mail]; Tobias Looker <
> [e-mail]>; cose <[e-mail]>
> *Cc:* Cose Chairs Wg <[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]
> https://www.ietf.org/mailman/listinfo/cose
>
> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose
>
> _______________________________________________
> COSE mailing list
> [e-mail]
> 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>