[jose] Re: HPKE and diminishing returns

Simo Sorce <simo@redhat.com> Tue, 18 June 2024 20:15 UTC

Return-Path: <simo@redhat.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 58423C1840E1 for <jose@ietfa.amsl.com>; Tue, 18 Jun 2024 13:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 (1024-bit key) header.d=redhat.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 zahgB3obVvjm for <jose@ietfa.amsl.com>; Tue, 18 Jun 2024 13:15:37 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 091A3C180B54 for <jose@ietf.org>; Tue, 18 Jun 2024 13:15:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1718741735; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9s/Qg9R2hs9RwmsTMRehgNh+XegkeGT8qFAhYBiwj+A=; b=UkaXJ9Fqy7Qb9otkbF+VyT2UqsQ/4Pu8lP1+V4ANRaihZOT5x9IDov0X/iHFDDgcOBHxke HSU0EoGjkt0jH+etkpOY+xL1l5GFpL/2dVz4omV6IzlE8SOzHjpAwKWvi7P5hzcBc3DFGl jcg+wX3sh+gbp8pplvcj8uSX8LATwdM=
Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-320-oufLBWANPHqE5RFdsO8UTg-1; Tue, 18 Jun 2024 16:15:34 -0400
X-MC-Unique: oufLBWANPHqE5RFdsO8UTg-1
Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-7955b3dd742so35240185a.1 for <jose@ietf.org>; Tue, 18 Jun 2024 13:15:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718741733; x=1719346533; h=mime-version:user-agent:content-transfer-encoding:organization :references:in-reply-to:date:cc:to:from:subject:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9s/Qg9R2hs9RwmsTMRehgNh+XegkeGT8qFAhYBiwj+A=; b=Kv4P8C5/1l/seWIvBR3Js4YaCVh40FkV/aw8aHSdmPEdGbL0lqx6kkegbulUv/nSix UkuutCItZnJqW3RxOr/0P3rrjz/bgt0JyQvNFLvvY/TyoTX9JTrsMI6mnb2Y3IZUmBNg Kn0wmG4hJ6FPOG2JgDeiVwQLixgWbXYiNHcLlWRxPsIb2xJs7ufWtwJpaTlpDnP5dRNu br7n3K2H4uA7TE6fbyvF3YFHPEn30CjRQu6+MF9itUD5CpkoUovh54UUYkxLow1AF2D9 DD3n2HKZaN07wytZKXr4wvBTcXvbI31Mw8up6vGeIqUiFsCk2+oZnw7PI2yt/VeIwU+t rJtw==
X-Forwarded-Encrypted: i=1; AJvYcCV+ItqU5CnZ69IxEPYPVTFNLtnby2jxQiLQB9haFfwrzufgl5GQQy2ZvTNmu61VBWAy/Stk7NUyMdFBjDq9
X-Gm-Message-State: AOJu0YwzZl9cK0ferLFNmwA8aK1fFUdKSzAOgZ2duseXFp4rVvBYxqbv TZ5g6hM07CwrIoqxU28gbGVmMsq3YAKzUgnr0EdWy2ZZkedG17/a/ozXAfw17TgaVzGx7hBVYdZ Qrgg3RONkjAm4khj4zGO6zBmkz2tuzVl7PyUI8RFFuQ==
X-Received: by 2002:a05:620a:4553:b0:797:a8cf:67de with SMTP id af79cd13be357-79ba76e35b9mr691629685a.19.1718741733502; Tue, 18 Jun 2024 13:15:33 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IF1BFOhhkBIOB67neEGTHyJFLVfhKv1lNW/2DVMy/0FtLfGo97KN4IjdtW/1l2loafxYs+K0Q==
X-Received: by 2002:a05:620a:4553:b0:797:a8cf:67de with SMTP id af79cd13be357-79ba76e35b9mr691626285a.19.1718741733075; Tue, 18 Jun 2024 13:15:33 -0700 (PDT)
Received: from m8.users.ipa.redhat.com ([2603:7000:9400:fe80::a75]) by smtp.gmail.com with ESMTPSA id af79cd13be357-798abc0ccb0sm549241585a.87.2024.06.18.13.15.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Jun 2024 13:15:32 -0700 (PDT)
Message-ID: <35678881c2acbde6e83e5c5a7850a859761bd9cd.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Michael Jones <michael_b_jones@hotmail.com>, Orie Steele <orie@transmute.industries>
Date: Tue, 18 Jun 2024 16:15:31 -0400
In-Reply-To: <PH0PR02MB74301382D6C0EBC34714D5EEB7CE2@PH0PR02MB7430.namprd02.prod.outlook.com>
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>
Organization: Red Hat
User-Agent: Evolution 3.52.2 (3.52.2-1.fc40)
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: ONLKTJPLGRWBSMOPTIUOBWENPY7DUMM2
X-Message-ID-Hash: ONLKTJPLGRWBSMOPTIUOBWENPY7DUMM2
X-MailFrom: simo@redhat.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: 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/JOrqgWzDtYgbJZsFLn5F3NZ5VbE>
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>

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