[jose] Re: HPKE and diminishing returns

Brian Campbell <bcampbell@pingidentity.com> Wed, 19 June 2024 19:43 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB3EC1CAF51 for <jose@ietfa.amsl.com>; Wed, 19 Jun 2024 12:43:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-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=pingidentity.com
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 WZivN8iz7JGo for <jose@ietfa.amsl.com>; Wed, 19 Jun 2024 12:43:30 -0700 (PDT)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 1919EC1840DE for <jose@ietf.org>; Wed, 19 Jun 2024 12:43:30 -0700 (PDT)
Received: by mail-il1-x132.google.com with SMTP id e9e14a558f8ab-376211b3a4fso2827935ab.1 for <jose@ietf.org>; Wed, 19 Jun 2024 12:43:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; t=1718826209; x=1719431009; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uWem+Vd3hy77Cp6MpLMu+UV1d/afT04tzQ8y7TMfCsQ=; b=DpUTUHOKi2tbdIh4iW0ohuosWJJS2/EFEUsjsgsxwBBT1Pqmmfdmh+lYjyrzulu1Rx +p5tZrvQ96ZMlOenPpU5RXMIBHbgGKLs2IE5Ib5wyXMDO+8Vu3UnUymLUOvsgEu9mPED yi+2utn90g5XPJL+yDIlevy96+nCK5M1w7c97M8cJ9vXm8t68CBHz/ZA77pxMjIsLbD5 LrkyGaPvJwdB4opGhBcsF9PLHyo5GkCvmI2LQGM9VpDAl2M4RAbcR8dS2ne1hbnCw/G0 QCSIjrVW/S9OE3KZOn6f34BGwEJ11KqsShtN0nQJdL+bkQ9lznbtK9LaOuMu5h5kdD8g Xmow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718826209; x=1719431009; 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=uWem+Vd3hy77Cp6MpLMu+UV1d/afT04tzQ8y7TMfCsQ=; b=e0nDvV+9SSvHIsO10rpdZTIflnFbK83vIkGFTvg+HmravUOu0ZCM4rSVpCWp2yfnSM vMSMcACoTkptxETaHuTos7jPZypkjkjYNSojOc2h6aOfLWG5sQbtapUZKojfeSH8M6mm 7JclpmyL/bZnYAjuL3FECh/+dS6ck3oAV2LUfug7X32oHlZKReQU0RL5MOjVBOyvwgYf dZm0/9A5iwo5nnDMUgRkzCYTo5isKxLYhdi2Ka3P8tOpzXnVa8rh31wvJ2RnI2Z1tQI6 +eCnnQUJ259Hy6s2TPCD9UffSnvBIoIa5hmAjYQDntUlR37buNbGMAPoZywfMyjAV++7 tGSA==
X-Forwarded-Encrypted: i=1; AJvYcCVo+4YSbmotqC8MIHIpuuZmOghmRKVnF0tDIhJ3fPYl3WecN0ixz/xYtvBUH83Xqj9vvXyDhsfO8rUD+6kZ
X-Gm-Message-State: AOJu0Yw8ZpL0TknIIP5wJ915wBSP2moNpZ818UKhqc1tlQFNRNWj8s+X vMGZ+qRavezHOE4axbUJOgBp2VoxlOO1PoGGsT2kJEmj5Ocx/vcY9ponrddLuEyMDuKSvkknGHy x3Nk+fRPDmw/6Wp6yjnHh49t1UpX5lStDv087YbO/mqHakPJi0T0exqluBZ40u8SxOYYit82WIH waMFAbagV5
X-Google-Smtp-Source: AGHT+IFRGaPeBv3phFi14gig+4hrS42MI9bZS8lPETg6Rb88PbOfiQY47lS73j2Go95zOIACeBaLu0IZ6xG25IqVSmA=
X-Received: by 2002:a05:6e02:1086:b0:376:d20:1470 with SMTP id e9e14a558f8ab-3760d201500mr28631265ab.12.1718826208815; Wed, 19 Jun 2024 12:43:28 -0700 (PDT)
MIME-Version: 1.0
References: <762F63AC-D5B7-4C07-AE44-29BDA6F1077C@gmail.com> <CA+k3eCRez+M4NAH=OqPfciHV4geAXiSn7AnrmUqdFwNVrXt6XA@mail.gmail.com> <Zm2NfyM_XcQZBswu@LK-Perkele-VII2.locald> <CAN8C-_+i4aEFvAFENmyJTzK-b2u_14hpBDeOGi1Nx6cCMyKxDA@mail.gmail.com> <Zm3LJWxGdL6GcB5m@LK-Perkele-VII2.locald> <CAN8C-_+iiX7XkzNeL+zR5ZLkq=6zmiC0qU5PdotOe6uFFVBZVg@mail.gmail.com> <85065444d9d70370b5628e5fdafdaa586a008271.camel@redhat.com> <CAN8C-_KS4WPiSH7rG0-nXNO5KQQ48CW-bLdieoLR9sUuf68oGg@mail.gmail.com> <78b8dc94a051d9799cef2c1a24bccae73b40de14.camel@redhat.com> <PH0PR02MB74301382D6C0EBC34714D5EEB7CE2@PH0PR02MB7430.namprd02.prod.outlook.com> <35678881c2acbde6e83e5c5a7850a859761bd9cd.camel@redhat.com>
In-Reply-To: <35678881c2acbde6e83e5c5a7850a859761bd9cd.camel@redhat.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 19 Jun 2024 13:43:02 -0600
Message-ID: <CA+k3eCQLOpq2XDEdH66sbY51uGiThtaWCD1DafL3Po3+i_U26g@mail.gmail.com>
To: Simo Sorce <simo@redhat.com>
Content-Type: multipart/alternative; boundary="0000000000009b9014061b43693f"
Message-ID-Hash: ZJRH53KEDKS3KGAMINCJNADJY3VUPZKY
X-Message-ID-Hash: ZJRH53KEDKS3KGAMINCJNADJY3VUPZKY
X-MailFrom: bcampbell@pingidentity.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-jose.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Michael Jones <michael_b_jones@hotmail.com>, Orie Steele <orie@transmute.industries>, Ilari Liusvaara <ilariliusvaara@welho.com>, JOSE WG <jose@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [jose] Re: HPKE and diminishing returns
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/4aapxiRD7TKXyy0V_jGrWy_dMfU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Owner: <mailto:jose-owner@ietf.org>
List-Post: <mailto:jose@ietf.org>
List-Subscribe: <mailto:jose-join@ietf.org>
List-Unsubscribe: <mailto:jose-leave@ietf.org>

To be clear, empty components are not the concern (or my concern anyway).
The inappropriate, nonconforming, problematic, etc. use of existing RFC
defined constructs is my concern.

I believe Neil's concern is more meta and questioning whether this line of
work should even be pursued. Which I certainly empathize with but seems
overcome by events at this point
https://mailarchive.ietf.org/arch/msg/jose/rmKgDcPre_QqFWzoBQ3MmkrXw4c/


On Tue, Jun 18, 2024 at 2:15 PM Simo Sorce <simo@redhat.com> wrote:

> On Tue, 2024-06-18 at 19:48 +0000, Michael Jones wrote:
> > Thanks Simo, for sharing your perspective as an implementer. FYI, empty
> components already occur for some JWE algorithms in some places. That's
> fine.
>
> Indeed it is, which is why I did not understand why in the previous
> discussion this was brought up as a possible supporting reason to
> advocate for a change in compact serialization representation.
>
> I just wanted to make it clear that it is indeed fine if the IV or the
> encrypted key parts or even headers are absent, implementations should
> be able to easily handle that, more easily than alternative
> implementations or requiring introspection of headers before you decide
> what kind of token you are likely handling.
>
> Simo.
>
> > -- Mike
> >
> > ________________________________
> > From: Simo Sorce <simo@redhat.com>
> > Sent: Tuesday, June 18, 2024 12:42:58 PM
> > To: Orie Steele <orie@transmute.industries>
> > Cc: Ilari Liusvaara <ilariliusvaara@welho.com>; JOSE WG <jose@ietf.org>
> > Subject: [jose] Re: HPKE and diminishing returns
> >
> > On Tue, 2024-06-18 at 13:00 -0500, Orie Steele wrote:
> > > Hey Simo,
> > >
> > > I was responding to Brian's comments, since he proposed changing the
> > > structure of a compact JWE for HPKE's "integrated encryption mode",
> which
> > > is the mode that is not required to interoperate with JSON serialized
> JWE
> > > that supports ECDH-ES+A128KW & RSA, etc...
> > >
> > > It sounds like you are supportive of producing a "compact JWE" for HPKE
> > > integrated encryption, and to not produce a different structure.
> > >
> > > That's consistent with the current draft text, although we have been
> > > debating the following points:
> > >
> > > - do we put the ek in a protected header or where the encrypted key
> would
> > > go.
> > > - which values do we choose for "alg" and "enc" when using HPKE
> integrated
> > > encryption.
> > >
> > > I don't see the need to create a new structure, which is why the
> current
> > > draft fits HPKE into JSON and compact serialized JWEs.
> > >
> > > Neil and Brian do not seem to agree that HPKE is compatible with
> compact
> > > JWE.
> > >
> > > Other commenters seem to believe it is compatible, and are debating the
> > > details of "how".
> > >
> > > In terms of changes needed for support HPKE based JWEs:
> > >
> > > + encrypted_key -> kem ct / encapsulated key (and where to put it)
> > > - iv (internalized by HPKE, no longer needed)
> > >
> > > alg: ECDH-ES+A128KW -> alg: HPKE-Base-P256-SHA256-A128GCM
> > > enc: A128GCM -> enc: A128GCM / dir / maybe something else depending on
> > > resolution of the "integrated encryption mode" discussion.
> > >
> > > Recall Section 3.1 of RFC7516:
> > >
> > >    In the JWE Compact Serialization, a JWE is represented as the
> > >    concatenation:
> > >
> > >       BASE64URL(UTF8(JWE Protected Header)) || '.' ||
> > >       BASE64URL(JWE Encrypted Key) || '.' ||
> > >       BASE64URL(JWE Initialization Vector) || '.' ||
> > >       BASE64URL(JWE Ciphertext) || '.' ||
> > >       BASE64URL(JWE Authentication Tag)
> > >
> > > We want to be able to make HPKE JWTs that are compact JWEs.
> > > We want to be able to make HPKE JWEs that are compatible with other
> > > recipient structures that use ECDH and RSA.
> > >
> > > The current draft addresses both of these needs, but we are debating
> the
> > > details of "how" it solves them.
> > >
> > > I don't find this confusing, but I've implemented a few variations of
> this
> > > in both JOSE and COSE at this point, and have been waiting for the
> working
> > > groups (JOSE and COSE) to adopt or decide what the final parameters
> should
> > > be, and where they need to go.
> > >
> > > Hopefully this is helpful, the purpose of adopting and documenting a
> single
> > > approach to HPKE in JOSE is to make it clear that a new structure is
> or is
> > > not needed for HPKE and its 2 modes of use.
> > >
> > > I don't believe a new structure is needed, I can live with an empty iv,
> > > maybe an empty encrypted key and 4 periods.
> > >
> > > I can also live with whatever value needs to be set for enc, when a
> fully
> > > specified HPKE algorithm is present in alg.
> > >
> > > Regards,
> > >
> > > OS
> > >
> >
> > I think I agree with you on most points, as an implementer it is more
> > valuable to me to treat HPKE as just another kind of JWE than to have
> > to build a whole new type of token just for HPKE ... and to be another
> > kind of JWE it needs to look like a JWE even if some of the components
> > are "empty": EWRQ...WEQW.QWEQW is just fine if need be as a compact
> > representation.
> >
> > I also don't see why HPKE can't be transmitted via compact
> > serialization, of course there will be limitations (single recipient),
> > but that is already the case with compact serializations with both JWS
> > and JWE ...
> >
> > I would also be ok to have:
> > alg: HPKE-Base-P256-SHA256
> > enc: A128GCM
> >
> > on the above I am not concerned about people composing arbitrary stuff,
> > because the spec can make it clear that only certain combinations are
> > allowed, and all others will just return errors from well behaving
> > implementations. (Bad implementations will accept composed identifiers
> > for alg: as well, it is not a game you can win).
> >
> > but equally
> >
> > alg: HPKE-Base-P256-SHA256-A128GCM
> > enc: hpke-foo vs enc: hpke-bar
> > if it makes sense to expose multiple modes at this level via an enc
> > attribute.
> >
> >
> > HTH,
> > Simo.
> >
> > >
> > >
> > > On Tue, Jun 18, 2024 at 12:09 PM Simo Sorce <simo@redhat.com> wrote:
> > >
> > > > On Sat, 2024-06-15 at 13:12 -0500, Orie Steele wrote:
> > > > > On Sat, Jun 15, 2024, 12:11 PM Ilari Liusvaara <
> ilariliusvaara@welho.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > On Sat, Jun 15, 2024 at 09:02:24AM -0500, Orie Steele wrote:
> > > > > > > Brian wrote:
> > > > > > >
> > > > > > > >  Perhaps it'd be less awkward to do something like JWHPKE
> that
> > > > defines
> > > > > > > independent JOSE style JSON and compact serializations
> specifically
> > > > for
> > > > > > > HPKE and is unencumbered by constructs and constraints of
> RFC7516?
> > > > > > >
> > > > > > > This is an interesting idea.
> > > > > > >
> > > > > > > MIMI also seems to be considering something like this, where
> MLS (see
> > > > > > >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fmls%2Fmls.xhtml%23mls-ciphersuites&data=05%7C02%7C%7Ce1b84dbf48db42a0218e08dc8fcee813%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638543366022131536%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=nYZ8M4vzCyaE82zd2nEO%2BDh3PnOUUNsBV5rMQOgVi5s%3D&reserved=0
> <https://www.iana.org/assignments/mls/mls.xhtml#mls-ciphersuites> )
> > > > and
> > > > > > CBOR
> > > > > > > are used together, instead of COSE or mixed in with COSE
> algorithms,
> > > > here
> > > > > > > is the draft:
> > > > > > >
> > > > > > >
> > > > > >
> > > >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-mimi-content-04%23section-4.4&data=05%7C02%7C%7Ce1b84dbf48db42a0218e08dc8fcee813%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638543366022145933%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=DzDZvUF%2F03ItYGwjd2G%2FA%2BHbXV1Fuvr3Yv1mtRMUyhw%3D&reserved=0
> <
> https://datatracker.ietf.org/doc/html/draft-ietf-mimi-content-04#section-4.4
> >
> > > > > > >
> > > > > > > I assumed we had already moved beyond "normal JWE" some time
> ago,
> > > > given
> > > > > > the
> > > > > > > structure of a compact HPKE JWT (from the unadopted draft)
> looks like
> > > > > > this:
> > > > > > >
> > > > > > >
> > > > > >
> > > >
> eyJhbGciOiJIUEtFLUJhc2UtUDI1Ni1TSEEyNTYtQUVTMTI4R0NNIiwiZXBrIjp7Imt0eSI6IkVLIiwiZWsiOiJCTFE0cHBMMFdlendzWjAyYTRtTFlkLVY1NUh2a0trT1hZVFN6NXJ3aWh6Z1BKbFY5M2Z3c2NfRzhLdTNfeHJKdUtST1FaT05HMzUxcmtKNnZ5Z0xDVk0ifX0...cwLUcH4GFHBZqq0Q-u3yHl-3Nb6eUpLg2w-WZyv1PfYi4pdgLyp_Mmw9atlp7NqujqIFgRhZpAvIRgOBlWPSfjGgi5qsUyU0lcY0DdICCPRMdPnA0JGtFI9iP11JbQLldSg-1Fo.
> > > > > > >
> > > > > > > ( notice the gaps for things we don't need from
> > > > > > >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7516%23section-3.1&data=05%7C02%7C%7Ce1b84dbf48db42a0218e08dc8fcee813%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638543366022158664%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=cViazBEEU%2BdkvdqeoYl74qrAzyEZpJssrunmRSYfW3U%3D&reserved=0
> <https://datatracker.ietf.org/doc/html/rfc7516#section-3.1> )
> > > > > > >
> > > > > > > Decoded protected header (after updates to align with COSE):
> > > > > > >
> > > > > > > {
> > > > > > >   "alg": "HPKE-Base-P256-SHA256-A128GCM",
> > > > > > >   "ek":
> > > > > > >
> > > > > >
> > > >
> "BLQ4ppL0WezwsZ02a4mLYd-V55HvkKkOXYTSz5rwihzgPJlV93fwsc_G8Ku3_xrJuKROQZONG351rkJ6vygLCVM"
> > > > > > > }
> > > > > >
> > > > > > Easier to do something like:
> > > > > >
> > > > > >
> > > > > >
> > > >
> eyJhbGciOiJIUEtFLUJhc2UtUDI1Ni1TSEEyNTYtQUVTMTI4R0NNIiwiZW5jIjoiZGlyIn0.BLQ4ppL0WezwsZ02a4mLYd-V55HvkKkOXYTSz5rwihzgPJlV93fwsc_G8Ku3_xrJuKROQZONG351rkJ6vygLCVM..cwLUcH4GFHBZqq0Q-u3yHl-3Nb6eUpLg2w-WZyv1PfYi4pdgLyp_Mmw9atlp7NqujqIFgRhZpAvIRgOBlWPSfjGgi5qsUyU0lcY0DdICCPRMdPnA0JGtFI9iP11JbQLldSg-1Fo.
> > > > > >
> > > > > > Which has decoded header:
> > > > > >
> > > > > > {
> > > > > >   "alg": "HPKE-Base-P256-SHA256-A128GCM",
> > > > > >   "enc":"dir"
> > > > > > }
> > > > > >
> > > > > >
> > > > > > There is no reason to align the two modes, because
> implementations are
> > > > > > separate anyway.
> > > > > >
> > > > > > (Also noticed that this avoids double base64-url).
> > > > > >
> > > > >
> > > > > This is an improvement.
> > > > >
> > > > >
> > > > > >
> > > > > > > As Tiru points out, the purpose of the draft is to enable
> protocols
> > > > (that
> > > > > > > rely on JWT or JSON serialization) to upgrade to PQ or hybrid
> > > > encryption.
> > > > > >
> > > > > > This can also be done with indirect HPKE (it is even compatible
> with
> > > > > > compact serialization), which avoids all problems with JWE
> > > > > > compatibility.
> > > > > >
> > > > > > Or it could be done with native KEM support (I estimate adding
> that to
> > > > > > JOSE would take about half page of spec).
> > > > > >
> > > > > >
> > > > > > > A JWT is a JWS or a *compact* JWE today, so we have focused on
> making
> > > > > > "HPKE
> > > > > > > JWEs".
> > > > > > >
> > > > > > > The fact that an "HPKE JWE" looks similar to a compact JWE
> using
> > > > > > > alg:ECDH-ES, enc: A128GCM, but is different, seems to be
> causing a
> > > > lot of
> > > > > > > confusion.
> > > > > >
> > > > > > What I think is confusing is that it looks like JWE, but it is
> not JWE.
> > > > > >
> > > > > > And also that bulk encryption should be one operation, and
> ECDH-ES is
> > > > > > inherently different operation.
> > > > > >
> > > > > >
> > > > > > > I had similar confusion with SD-JWT, until I did an
> implementation,
> > > > and
> > > > > > > then I realized that SD-JWT is like a JWT, but with a ~ on the
> end,
> > > > and
> > > > > > > some new rules for processing parameters in the payload.
> > > > > >
> > > > > > Based on brief look at SD-JWT spec, to me it looks like the
> "JWT" part
> > > > > > is an actual signed JWT, and not just something that looks like
> JWT.
> > > > > >
> > > > > >
> > > > > > > HPKE JWTs are like normal JWEs, but with some missing
> parameters
> > > > (because
> > > > > > > HPKE internalizes them) and with some rules for processing new
> > > > parameters
> > > > > > > (ek will be the only new parameter, assuming we can use alg
> and enc).
> > > > > >
> > > > > > JWE explictly allows any combination of Encrypted Key,
> Initialization
> > > > > > Vector and Authentication Tag to be missing.
> > > > > >
> > > > > > - If using Direct Encryption or Direct Key Agreement, Encrypted
> key is
> > > > > >   missing.
> > > > > > - If "enc" does not have IV nor nonce, Initialization Vector is
> > > > missing.
> > > > > > - If "enc" combines ciphertext and tag, Authentication Tag is
> missing.
> > > > > >
> > > > > >
> > > > > > > I think this makes HPKE JWTs easier to understand than many
> other
> > > > > > formats I
> > > > > > > have reviewed.
> > > > > > >
> > > > > > > Consider the compact example above, we could make a new kind of
> > > > compact
> > > > > > > JWE, like compact JWE2.
> > > > > > >
> > > > > > > That allows for this:
> > > > > > >
> > > > > > > <encoded protected header>.<cipher text>
> > > > > > >
> > > > > > > Or we could add support for unprotected headers in compact
> JWE2s:
> > > > > > >
> > > > > > > <encoded protected header>.<encoded unprotected
> header>.<cipher text>
> > > > > > >
> > > > > > > Then we could define a JWT as being a JWS, compact JWE,
> (compact
> > > > SD-JWT?)
> > > > > > > or a compact JWE2.
> > > > > >
> > > > > > JWS uses three components, so it might not be good idea, as it
> could be
> > > > > > confused with JWS.
> > > > > >
> > > > > > And if using Encrypted Key, the full format has only a few bytes
> of
> > > > > > overhead.
> > > > > >
> > > > >
> > > > > Could use a different separator, to avoid confusion with JWS.
> > > > > Although I think counting "." Or "~" and guessing is worse than
> decoding
> > > > a
> > > > > header and checking typ.
> > > > >
> > > > > I think it's ok to have 3 components, separated by a "." Where the
> first
> > > > is
> > > > > a protected header with optional alg and typ.
> > > > >
> > > > > If we're not stuck with JWE rules, we can make alg optional just
> like it
> > > > is
> > > > > in COSE.
> > > > >
> > > >
> > > > If you want to leave one optional you just leave it out and have 2
> > > > consecutive .. it is fine, there is no need to invent new stuff.
> > > >
> > > > Parsing headers w/o knowing whether it is a JWE or a JWS is
> inefficient
> > > > and error prone, as you will then have to re-parse the input again
> with
> > > > the proper code later.
> > > >
> > > > Using the number of dots has nothing sketchy for it, it is no
> different
> > > > the looking at the first few bytes of a file to guess the type via a
> > > > magic number.
> > > >
> > > > Full validation later will throw an error if it was a malformed
> token,
> > > > but this is exactly why you should not confuse software by sending
> > > > obviously "incorrect" tokens by changing the number of dots.
> > > > >
> > > >
> > > >
> > > > > > > AFAIK, a JWT can never be JSON serialized, which is why SD-JWT
> has
> > > > > > sections
> > > > > > > like this that clarify how to verify a JSON serialized SD-JWT:
> > > > > > >
> > > > > > >
> > > > > >
> > > >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-oauth-selective-disclosure-jwt-09%23name-verification-of-the-jws-jso&data=05%7C02%7C%7Ce1b84dbf48db42a0218e08dc8fcee813%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638543366022170314%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=nGg%2B1LSWAzpyo91DREKL5eyQ7SILbn7T7RA7Yf5Vcy0%3D&reserved=0
> <
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-09#name-verification-of-the-jws-jso
> >
> > > > > > >
> > > > > > > I bring up SD-JWT, because that draft seems to have taken the
> > > > approach
> > > > > > > Brian has suggested.
> > > > > >
> > > > > > To me, it looks like SD-JWT took compact JWS, and added more
> components
> > > > > > with a different separator.
> > > > > >
> > > > >
> > > > > That's what it is, it's also a different media type.
> > > > >
> > > > > Even if it had the same number of components and separators as JWS
> and
> > > > JWE,
> > > > > it would still be a different media type.
> > > > >
> > > > >
> > > > > >
> > > > > > > If we are successful and produce an HPKE alg that can be used
> in JSON
> > > > > > > Serialized JWE Encryptions, we can start adding a recipient
> that
> > > > supports
> > > > > > > ML-KEM, next to other recipients that support RSA or ECDH.
> > > > > >
> > > > > > I think there are only a few details that need to be figured
> out, most
> > > > > > of those minor.
> > > > > >
> > > > > >
> > > > > > > If COSE WG is also successful, keys restricted for
> > > > > > > HPKE-Base-P256-SHA256-A128GCM in JOSE will also be useful in
> COSE.
> > > > > >
> > > > > > And COSE stuff is just about complete.
> > > > > >
> > > > > >
> > > > > > > Of course it will take rough consensus in both groups to
> ensure we
> > > > don't
> > > > > > > end up with confusing algorithms that are partially specified
> in
> > > > > > different
> > > > > > > ways.
> > > > > >
> > > > > > Or trying to "align" things, but only managing to make things
> more
> > > > > > complex rather than simpler.
> > > > > >
> > > > >
> > > > > Sometimes it's simpler to make a new structure, sounds like we are
> > > > heading
> > > > > for a new compact serialization that can be used for encrypted
> JWTs, but
> > > > > that is not a JWE.
> > > >
> > > > Why? It is unclear why you would need that.
> > > > >
> > > >
> > > > > > > Luckily we appear to have a good amount of overlap, and both
> groups
> > > > have
> > > > > > > now discussed the essentials for adding HPKE to JOSE and COSE.
> > > > > > >
> > > > > > > I will summarize those essentials here once more, with the
> hope that
> > > > > > > providing clarity addresses the topic of "diminishing returns":
> > > > > > >
> > > > > > > KEM Info -
> > > > > > >
> > > > > >
> > > >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9180%23name-auxiliary-authenticated-app&data=05%7C02%7C%7Ce1b84dbf48db42a0218e08dc8fcee813%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638543366022178138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zDsciX084RNfqkfLzRamMOiTqIseN%2FRocFEMxOr7Q%2F8%3D&reserved=0
> <
> https://datatracker.ietf.org/doc/html/rfc9180#name-auxiliary-authenticated-app
> >
> > > > > >
> > > > > > HPKE spec has some rather annyoing limitations around KEM info.
> Actual
> > > > > > HPKE implementations may or may not actually have those
> limitations.
> > > > > >
> > > > > >
> > > > > > > Additional Authenticated Data -
> > > > > > >
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9180%23section-9.4&data=05%7C02%7C%7Ce1b84dbf48db42a0218e08dc8fcee813%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638543366022183583%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1mZd0jpGauka5v3wL8nebBT16IA6Pn1LS%2FACHYQkpPE%3D&reserved=0
> <https://datatracker.ietf.org/doc/html/rfc9180#section-9.4>
> > > > > > > Protected Headers - alg, enc, ek, psk_id
> > > > > > >
> > > > > > > 2 Layer (Indirect / JSON Serialization, etc...)
> > > > > > > HPKE-Base-P256-SHA256-A128GCM upgrades { alg: ECDH-ES+A128KW }
> ... {
> > > > enc:
> > > > > > > A128GCM }
> > > > > > > 1 Layer (A new kind of "direct encryption"... "does not exist
> in
> > > > JWE")
> > > > > > > HPKE-Base-P256-SHA256-A128GCM upgrades { alg: ECDH-ES, enc:
> A128GCM }
> > > > > >
> > > > > > Careful here: "Direct Encryption" is existing term in JWE, and
> it means
> > > > > > something different. Hence me using "Integrated Encryption" as
> the mode
> > > > > > name in the past ("direct encryption operation" was used as
> algorithm
> > > > > > operation name).
> > > > > >
> > > > >
> > > > > Right and if we are saying it's not a JWE, we should not reuse any
> JWE
> > > > > terminology... And we are not limited by normative statements
> about the
> > > > > construction of JWE.
> > > >
> > > > Are you planning to build a completely new competing standard ... for
> > > > an algorithm ?
> > > >
> > > > > But we are saying that JSON serialization with HPKE used to
> encrypt a
> > > > > content encryption key is JWE... Which seems to also be confusing
> people.
> > > >
> > > > You can encrypt what you want with a JWE, including keys, I fail to
> see
> > > > why this would be confusing.
> > > >
> > > > Simo.
> > > >
> > > > --
> > > > Simo Sorce
> > > > Distinguished Engineer
> > > > RHEL Crypto Team
> > > > Red Hat, Inc
> > > >
> > > >
> > >
> >
> > --
> > Simo Sorce
> > Distinguished Engineer
> > RHEL Crypto Team
> > Red Hat, Inc
> >
> > _______________________________________________
> > jose mailing list -- jose@ietf.org
> > To unsubscribe send an email to jose-leave@ietf.org
>
> --
> Simo Sorce
> Distinguished Engineer
> RHEL Crypto Team
> Red Hat, Inc
>
> _______________________________________________
> jose mailing list -- jose@ietf.org
> To unsubscribe send an email to jose-leave@ietf.org
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._