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`.
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`.
> 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.
> 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 } }
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.
I think that is confusing enough to add some explicit text, warning against
it or at least commenting on it.
>
>
> 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.
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
2 seems related to 1 in that we are not really sure how to distinguish
"types" of CWT and "types" of CWT payload.
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
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.
OS
>
> -- 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>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
