[jose] draft-ietf-jose-hpke-encrypt adoption call feedback and prototype

Orie Steele <orie@transmute.industries> Sat, 22 June 2024 17:32 UTC

Return-Path: <orie@transmute.industries>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 64119C14CE53 for <jose@ietfa.amsl.com>; Sat, 22 Jun 2024 10:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=transmute.industries
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VtTVbTySonAT for <jose@ietfa.amsl.com>; Sat, 22 Jun 2024 10:32:54 -0700 (PDT)
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 3EEDAC14F695 for <jose@ietf.org>; Sat, 22 Jun 2024 10:32:54 -0700 (PDT)
Received: by mail-pf1-x42e.google.com with SMTP id d2e1a72fcca58-7067272245aso159705b3a.1 for <jose@ietf.org>; Sat, 22 Jun 2024 10:32:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; t=1719077573; x=1719682373; darn=ietf.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=IZT0iXvbJPfUNIXskvGWGoiernUdTmDhfkQSmh7KlyU=; b=hNjzWPVdtIBLIyC1IXdW46ZMmiSwjuMTeaePr0FhoZImnI2Y9kz8HMonacDTsBJFNG LR0/dUhr7hEzoC418MMouaw8TycAqYQ4UntlYiJ44pwBGXzXSGwxXTnwvYv2vH8X6zpz dsL3HD0tPU4qvWP849/p3AMvlPvJBfiNdLElYiwiN/nSczYJ+n2FPge0zxi/bEWg4DvC 4LCa7QjOXmr18i+pr7XmI0MWqlyVXT53hQJfRUTLMGr5T9v4z9aQfpFrlgaVWO2O8dWa 710tNA8NkcTOJSSTz8UG9mHGFgJxtCp+6g2Um04XxqPgJAh/F9I0PiyTX/Fmwc0fDZCe 0tBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719077573; x=1719682373; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=IZT0iXvbJPfUNIXskvGWGoiernUdTmDhfkQSmh7KlyU=; b=pHcyhIFOshx6zeZyILWTPE/VGVPOYFfY6Urpn2hS67hEpcDUqGnjqgPaxcFwCttrKv V0jkcb9C8Qd7ORe45vH0s9i8vyyac+frrW8elCGcqUWhx0D7xHkRJlz9kDKpUqgkv6/Q 5DJWd54FuHXNNUvJQD+NdQPuwdKRMNjwtICo610pZWkpqF7imfhkM6grYm8FMdQ2y4NY gdheGQkUt+4P8Y6/ki4xRjih57x133OAXZIGR/oJ5e3ioY2w09myZ1b0rSpDvy3P+Ri4 E5RhgIOkIIt+3JmgO2H2NuzVgDNqDKTB2AiVHN0h60F5W47gMf+Nr06eU950K+JxjelA 1BNQ==
X-Gm-Message-State: AOJu0YwbJtdiakBcMobaEEcdsuKb3rYmtxCrE3oHCBjR8uLXybkUfwxC RFJ23DB0J799D82lF5ivDnr2xP9WrV4P5u55k9XZEVGIFaMayNl97wSLiSte3lB6WE/jGS/6xoR RlPwAeSCsWOQJQ6npADzEnkKan6fyyHT+Li37peFHlS4lBKVG818=
X-Google-Smtp-Source: AGHT+IGzagZ3/dte3lIquDVAWXC4zlXXlFGlfmfSe7Wu0alpHJJh5EW0tabxFSofbV6HsIUBfGjiKeA5Ml016IArMpM=
X-Received: by 2002:a05:6a20:6a25:b0:1b6:db6c:11ea with SMTP id adf61e73a8af0-1bcf7e7f821mr388643637.26.1719077572856; Sat, 22 Jun 2024 10:32:52 -0700 (PDT)
MIME-Version: 1.0
From: Orie Steele <orie@transmute.industries>
Date: Sat, 22 Jun 2024 12:32:42 -0500
Message-ID: <CAN8C-_KLwCjfj2_gOUM6jF_4jv8-w7UZC1hzDWpNSHP6OpQe6Q@mail.gmail.com>
To: JOSE WG <jose@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000126a60061b7df02a"
X-MailFrom: orie@transmute.industries
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: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Paul Bastian <paul.bastian@bdr.de>, draft-ietf-jose-hpke-encrypt@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [jose] draft-ietf-jose-hpke-encrypt adoption call feedback and prototype
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/Ea4cPSEOmBNQtjcnMG-sUPhCAnI>
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>


I've created yet another prototype HPKE implementation to consider feedback
we got from the adoption call.
I know folks are struggling to follow along with HPKE details, but I'm
going to address several points of feedback in this email to avoid creating
separate threads for each topic.
To make this bearable (bearer token joke), I have focused only on compact
JWEs for use as JWTs.

As you can see from:

In JWTs built from { alg: 'ECDH-ES+A128KW', enc: 'A128GCM' }
The ephemeral public key goes into the protected header, and the encrypted
content encryption key goes in to the JWE Encrypted Key.

In the prototype, JWTs are built from { alg:
'HPKE-Base-P256-SHA256-A128GCM', enc: 'A128GCM' }
The encapsulated key goes into the JWE Encrypted Key.
This is a change from the draft-ietf-jose-hpke-encrypt-00 where the "ek"
was placed in the protected header.
It eliminates double base64url encoding.
The enc value is set to `A128GCM`, this is a change from

There was confusion about some of the normative statements that are in JWE,
and how they apply to HPKE based JWTs.

I show how apu / apv can remain supported, however they are secured with
aad in my prototype instead of as part of the key agreement info.
This is inconsistent with their original purpose, but they are "mandatory
to process" when present, so I am not sure how we should be interpreting
them in the context of HPKE.
Please read: https://datatracker.ietf.org/doc/html/rfc9180#section-8.1
Based on my experience as a developer (not a cryptographer) implementations
should not be required to write extra code to process apu / apv.
Please read: https://datatracker.ietf.org/doc/html/rfc9180#section-5.1.1
We should provide an example like
But it should explicitly address the confusion that is present surrounding
mandatory processing of "apu" and "apv" when present.
My current recommendation would be to write something to the effect of:

When "apu" and "apv" are present in headers, they:
1. MUST NOT be used to construct explicit info per section 5.1.1 of RFC
2. will be secured as AAD, during Seal and Open AEAD operations (this is
true of all information in protected headers).

Another exciting topic has been AuthMode and PSK support.

draft-ietf-jose-hpke-encrypt-00 requests psk_id and auth_kid headers to
support this use case, but does not request algorithms.

I've now done a first attempt here:

The headers  "psk_id" and "auth_kid" should be optional, but I believe it
is important to distinguish "auth mode psk" from "base" mode:

- HPKE-Base-P256-SHA256-A128GCM
- HPKE-Auth-P256-SHA256-A128GCM
- HPKE-AuthPSK-P256-SHA256-A128GCM
- HPKE-PSK-P256-SHA256-A128GCM

This is sad, because it will result in registry bloat per mode.

We could consider making the "mode" a dependent parameter of the algorithm,
but then we lose the ability to distinguish keys which support auth mode
from those that do not.

This also goes against guidance in

The good news is that we do not need to register all combinations of mode,
kem, kdf, and aead that are implied by:

Now seems like a great time to talk about use cases for HPKE based JWTs, so
we know which algorithms are actually needed.

At IETF 119, this draft was presented:

As you can see, the latest editors copy includes some guidance on use of


If this document were to register algorithms there would be substantial
overlap with HPKE Encrypted JWT use cases.

I believe that draft-ietf-jose-hpke-encrypt based JWTs can support the use
case that draft-bastian-jose-alg-ecdh-mac is targeting.

When creating "tokens" or "credentials", the goal is to convey claims made
by an issuer about a subject, to a verifier.
JWT and CWT have claim names for these entities, such as: "iss", "sub",
Other claims can be added such as "iat", "exp", or "email", etc...

Such claims are secured in several different ways, for example:

1. The claims could be signed with the issuer private key, producing a
signed JWT.
2. The claims can be encrypted to the verifier's public key, producing an
encrypted JWT.
3. The claims can be retrieved over a secure channel, like HTTPS.

This draft shows how to assign media types for each case:


There is growing interest in credentials that are channel bound, and cannot
be stolen or sold while remaining verifiable to a high value issuer, for
example a government.

HPKE Encrypted JWTs with Auth Mode can support this use case, for protocols
that support JWT, and that already understand JWT claims that are protected
with digital signatures today.

I am hopeful that with feedback from stakeholders that have this use case,
we can ensure that HPKE JWTs support the algorithms that are necessary to
enable government credential use cases where digital signatures are
forbidden, or not recommended.

Please use know if you would like us to apply any of
these prototype implemented changes to the draft.




Chief Technology Officer