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://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://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://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).
> 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.
> 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://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.
> 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.
> 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://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://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).
-Ilari
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
