Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-in-headers
Orie Steele <orie@transmute.industries> Mon, 26 June 2023 18:03 UTC
Return-Path: <orie@transmute.industries>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2B6C15154D for <cose@ietfa.amsl.com>; Mon, 26 Jun 2023 11:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.084
X-Spam-Level:
X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=transmute.industries
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGPI7ADtLE_l for <cose@ietfa.amsl.com>; Mon, 26 Jun 2023 11:03:15 -0700 (PDT)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC116C14CE51 for <cose@ietf.org>; Mon, 26 Jun 2023 11:03:14 -0700 (PDT)
Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-51cff235226so4933949a12.0 for <cose@ietf.org>; Mon, 26 Jun 2023 11:03:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; t=1687802593; x=1690394593; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DucBE16dVBslcjts+T8grMnyLJl7224rwH8W7JUYDBc=; b=oOcQfSnr/nQW4NYkn381pe1ngWGXAupJvibXjdOGuJQylNqYlXyI2o/LtJDYeiDPYn bxsZEQVDO51/Sx8WbvhyfDFAOnQbTKDpkT8wAGpEzu0Iha+mG3zO/KVFumqntyXALJjF Fbq9aHxb6U2kAsJ7Vu9YXJyl3YRi/iOMGMjMNQZJt9xf/H+OcHi7YLbp3eImh1GM+H/r rlCamBSY0wotZf5vmc7iX0whv0kS+M5IBx6OEgQp3AgLfjGNB7xpzdvswDfF2uawUArW bV1fbs64WNsvdzHaw+sNMxtvimPVqZeocSGn1GjNFZa3R4xMe3pNpZ6WhILew/lA02b+ 8Uug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687802593; x=1690394593; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DucBE16dVBslcjts+T8grMnyLJl7224rwH8W7JUYDBc=; b=ZPFOP6CdGwXIpI6gM3aD6G0TnZWh+Xr6HXWp5YOPJfjaQ2ZEJ5VWB2UYUym4pwDS+6 rvQ+eEtBwkSz+kxde5jsY1qWb+h7r4e9D78/CrzmIwXKXeQnbKr6knXtfqTZ1tgke21b rDA5EhMCOzJ0NXUp+7yCqYcNQCiD21YVETnfSQKFQ+rOIBvfMB5X3EPVbfhnHrU6QoE/ NvCHX5lPscXIkFo7HGvUUPo18QPIzEeyAApvQ52suWtMhYoj93XJjJn2tOnfp5rJMVfU Xk7v5Y3fq2UbsWJ7K+AKWiCUBZwFbXj/sVokzqQZGV/y+6wohoxkabH1bSA+DX5IyjnX SSiw==
X-Gm-Message-State: AC+VfDyaxJnSzkfo9ImEJw5h2pulIFoaqdKHSVFTTXFCT0wVi37C1oRI dUzfvW/j3hG7Fv7CEOz26dpRIde1S/ULk1NjyJqU8w==
X-Google-Smtp-Source: ACHHUZ4yPL/1JruaVqaPulO16X1JTbcm/eyT4Wd/Vip3/lXjTMAQACJowrQWo2JTiZkuyp7ZRGWxnGZoQ1/puqRC0cA=
X-Received: by 2002:a05:6402:2683:b0:51a:4c1e:c94a with SMTP id w3-20020a056402268300b0051a4c1ec94amr23953649edd.2.1687802592895; Mon, 26 Jun 2023 11:03:12 -0700 (PDT)
MIME-Version: 1.0
References: <CAJFkdRw075tYGVT1mghOwzwKFRahBRz0q2rrhjPO2ATziofxPg@mail.gmail.com> <MW4PR02MB7428D03014EC6251E5B90935B76A9@MW4PR02MB7428.namprd02.prod.outlook.com> <CAGJKSNToC+waFM-wigAf2k3KP-L-48U9X_jhWejbTVFgeoouNQ@mail.gmail.com> <CAN8C-_LGdDd=prtytMo5Qe21g+ZWgD3bdiMjrxJg=_vtsZ96Bg@mail.gmail.com> <CAFWvErXXGOY-79zsg34z0t3nsmSJgwnby1ECoKNHb3S7Z4B0Rw@mail.gmail.com> <MW4PR02MB74280F6390B849A12313F775B75FA@MW4PR02MB7428.namprd02.prod.outlook.com> <CAN8C-_KG6BFnxpJr5rH0-6i5aeZJnMUi5mCy=gLh8hLiJP1Bfg@mail.gmail.com> <MW4PR02MB7428358E1AE80E43882F9FAEB726A@MW4PR02MB7428.namprd02.prod.outlook.com>
In-Reply-To: <MW4PR02MB7428358E1AE80E43882F9FAEB726A@MW4PR02MB7428.namprd02.prod.outlook.com>
From: Orie Steele <orie@transmute.industries>
Date: Mon, 26 Jun 2023 13:03:02 -0500
Message-ID: <CAN8C-_KJ2Oahz6OAYiwmxZw9_YjaKGSABqidmeQbR7fbLTuJiw@mail.gmail.com>
To: Michael Jones <michael_b_jones@hotmail.com>
Cc: AJITOMI Daisuke <ajitomi@gmail.com>, Cose Chairs Wg <cose-chairs@ietf.org>, cose <cose@ietf.org>, Mike Prorock <mprorock@mesur.io>, Ivaylo Petrov <ivaylo@ackl.io>, Tobias Looker <tobias.looker@mattr.global>
Content-Type: multipart/alternative; boundary="00000000000000353e05ff0c2a5d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/0soC6zDEK9IYkLFukGwJs72Rr-I>
Subject: Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-in-headers
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Jun 2023 18:03:19 -0000
Inline: On Mon, Jun 26, 2023 at 12:36 PM Michael Jones <michael_b_jones@hotmail.com> 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 <orie@transmute.industries> > *Sent:* Tuesday, June 20, 2023 9:51 AM > *To:* Michael Jones <michael_b_jones@hotmail.com> > *Cc:* AJITOMI Daisuke <ajitomi@gmail.com>; Cose Chairs Wg < > cose-chairs@ietf.org>; cose <cose@ietf.org>; Mike Prorock < > mprorock@mesur.io>; Ivaylo Petrov <ivaylo@ackl.io>; Tobias Looker > <tobias.looker@mattr.global> > *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 <michael_b_jones@hotmail.com> > wrote: > > Thanks for the review, Daisuke! Responses are inline below in green. > > > > *From:* AJITOMI Daisuke <ajitomi@gmail.com> > *Sent:* Tuesday, May 2, 2023 3:57 PM > *To:* Cose Chairs Wg <cose-chairs@ietf.org>; cose <cose@ietf.org> > *Cc:* Mike Prorock <mprorock@mesur.io>; Michael Jones < > michael_b_jones@hotmail.com>; Ivaylo Petrov <ivaylo@ackl.io>; Tobias > Looker <tobias.looker@mattr.global>; Orie Steele < > orie@transmute.industries> > *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 <orie@transmute.industries>: > > I support publication. > > > > On Thu, Apr 27, 2023, 5:20 PM Mike Prorock <mprorock@mesur.io> wrote: > > I believe that this is ready to go as well. > > Mike Prorock > mesur.io > > > > On Thu, Apr 27, 2023, 15:31 Michael Jones <michael_b_jones@hotmail.com> > wrote: > > I believe that this specification is ready for publication. > > > > -- Mike > > > > *From:* Ivaylo Petrov <ivaylo@ackl.io> > *Sent:* Thursday, April 27, 2023 1:23 PM > *To:* michael_b_jones@hotmail.com; Tobias Looker < > tobias.looker@mattr.global>; cose <cose@ietf.org> > *Cc:* Cose Chairs Wg <cose-chairs@ietf.org> > *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 > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > COSE@ietf.org > 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] 🔔 WGLC of draft-ietf-cose-cwt-claims-in-he… Ivaylo Petrov
- Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-i… Michael Jones
- Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-i… Mike Prorock
- Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-i… Orie Steele
- Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-i… AJITOMI Daisuke
- Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-i… Michael Jones
- Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-i… Orie Steele
- Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-i… Michael Jones
- Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-i… Orie Steele
- Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-i… Michael Jones
- Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-i… Orie Steele
- Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-i… Michael Jones
- Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-i… Michael Jones
- Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-i… AJITOMI Daisuke
- Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-i… Michael Jones
- Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-i… AJITOMI Daisuke
- Re: [COSE] 🔔 WGLC of draft-ietf-cose-cwt-claims-i… Ivaylo Petrov