[jose] Re: draft-ietf-jose-hpke-encrypt-01

[Orie Steele <[e-mail]>]

### Key Encryption Example

{
*        "protected": "eyJlbmMiOiJBMTI4R0NNIn0", // { "enc": "A128GCM" }*
        "iv": "xFOVHqPoufKESHE0",
        "ciphertext":
"jrQO6jW9iuxDHl46SWDQW3nmedYU09I1xssRZlOYWYE2HbAXmXDwgAc5hLGVTQxizhLaC0YaNh4im2GJ9_h7",
        "tag": "1zAmVzvbaZiAU_olStTzdg",
        "aad": "cGF1bCBhdHJlaWRlcw",
        "recipients": [
          {
            "encrypted_key": "_jOYzDrItWbL9Vv035qEnJTip0vvhmC_",
            "header": {
              "kid":
"urn:ietf:params:oauth:jwk-thumbprint:sha-256:8ty4B2GslLjOxJdGjd9YdybvX15eFroyQHio1YimpZk",
              *"alg": "ECDH-ES+A128KW", // works today*
              "epk": {
                "kty": "EC",
                "crv": "P-256",
                "x": "JkxQ8Sry4ZHd45Qea4vt3MxIuliC-ZT08YFEJrRr5VU",
                "y": "TIbmUelobO3iwCj1x6RWG7Wk28XDHBH-U5lLZH6n7P8"
              }
            }
          },
          {
            *"encrypted_key":
"GcLTSQO7NabyItEqeh2EQB2Uh8KrV79-FGFSVQ-fG-E", // encrypted with *
*HPKE-P256-SHA256-A128GCM*
            "header": {

*              "alg": "HPKE-P256-SHA256-A128GCM", // hopefully works in the
future, maybe the name will change?              "enc": "A128GCM", //
probably not needed, maybe remove?*
              "kid":
"urn:ietf:params:oauth:jwk-thumbprint:sha-256:8Tp_DUMUqBo1nsGLwEtk-Y0Lway4dzQRpgUR4ZzyXpQ",
              "psk_id": "our-pre-shared-key-id",
              "auth_kid":
"urn:ietf:params:oauth:jwk-thumbprint:sha-256:8Tp_DUMUqBo1nsGLwEtk-Y0Lway4dzQRpgUR4ZzyXpQ",
              "ek":
"BA80h3xLNmrwWMi1ME--hniqwBcQplt5lwM_r02vXewA1_igignkUnm0qb6mIjaw1c8qs78ZyC3wV_1fpumQP-c"
            }
          }
        ]
}

### Integrated Encryption Example

{
        "protected": "eyJhbGci...tjaWq-PqOZoatF2hrJoho",
        "ciphertext": "nLg0PgTlkWAk9Z77rJvpJYnRAL9QRI0A4GgsFkZUcRgUaVOt",
        "aad": "8J-PtOKAjeKYoO-4jyBiZXdhcmUgdGhlIGFhZCE"
}

Decoded protected header:

{

*  "alg": "HPKE-P256-SHA256-A128GCM",  "enc": "A128GCM", // previously
"dir", ... something needs to stay here for integrated encryption?*
  "kid":
"urn:ietf:params:oauth:jwk-thumbprint:sha-256:S6AXfdU_6Yfzvu0KDDJb0sFuwnIWPk6LMTErYhPb32s",
  "psk_id": "our-pre-shared-key-id",
  "auth_kid":
"urn:ietf:params:oauth:jwk-thumbprint:sha-256:S6AXfdU_6Yfzvu0KDDJb0sFuwnIWPk6LMTErYhPb32s"
}

As you can see, the problem is that currently HPKE "alg" names do not
distinguish between "direct encryption like things" and "key agreement with
key wrapping like things"... for both cases we see:

"alg": "HPKE-P256-SHA256-A128GCM", // currently use for both
"enc": "A128GCM", // optional / invalid for key encryption?... mandatory
for integrated encryption...

We need a way to tell from the header, if the mode is "integrated
encryption" or "key encryption"... either from looking only at the alg, or
looking at the alg and enc.

Folks familiar with direct encryption and key agreement with key wrapping
would probably expect to see:

"alg": "HPKE-P256-SHA256+A128KW" // for key encryption

and ...

"alg": "HPKE-P256-SHA256",  // for "integrated encryption"
"enc": "A128GCM",

I'm hoping that "HPKE-P256-SHA256-A128GCM" is ok for both cases, and the
presence of "enc" is sufficient to distinguish them... but if folks
disagree, feel free to propose something that makes this clearer.

Regards,

OS

On Mon, Jul 8, 2024 at 12:05 PM Les Hazlewood <[e-mail]> wrote:

> Apologies, I misread the compact form in the version 01 draft - it does
> indeed included the cek ciphertext, but not the iv or aad tag.  But my
> comments/questions about mandatory `alg` and `enc` values are still valid I
> believe.
>
> On Mon, Jul 8, 2024 at 9:58 AM Les Hazlewood <[e-mail]> wrote:
>
>> Thanks Orie,
>>
>> As a long-time implementer and maintainer of a widely used JOSE library,
>> I'm have some concerns that I hope could be addressed.  Admittedly, most of
>> my questions are relevant to single recipient and compact (JWT) forms.
>>
>> I don't think for JWE there should ever be an omitted `alg` header
>> parameter: its omission and/or 'none' value can and has caused security
>> problems in the past for parsers and this feels like opening a can of worms
>> again.  Further, it adds cyclomatic complexity (conditionals) for
>> validation assertions that, I hope, shouldn't ever be necessary.
>> Non-absent deterministic values are so much nicer and reduce potential
>> problems.
>>
>> The way `alg` has always worked (conceptually at least) IMO from a
>> library implementor point of view is it means "the algorithm used to obtain
>> the AEAD content encryption key and its potentially associated ciphertext".
>>  `enc` is "the algorithm used to AEAD encrypt the payload".  That is,
>> (pseudocode):
>>
>> enc_alg = enc_registry.find( header['enc'] )
>> key_alg = alg_registry.find( header['alg'] )
>> kek = keystore.find( header['kid'] )
>> cek, cek_ciphertext = key_alg((kek, encAlg, header)
>>
>> For JWE:
>>
>> - No `alg` inherently means "there isn't a way to obtain an cek/cdk".
>> - No `enc` means "the payload is not encrypted", so both must always be
>> present for JWE.
>> - No JWE ciphertext token in the compact JWE string means 'there is no
>> encrypted key ciphertext', when clearly there is (encapsulation).
>>
>> I could be missing something (and happy to be educated accordingly), but
>> I would really like to see the HPKE work maintain these existing constructs
>> - changing them to introduce additional complexity is not an intuitive, nor
>> safe, idea IMO.
>>
>> Respectfully,
>>
>> Les Hazlewood
>> JJWT author/maintainer
>>
>> On Sun, Jul 7, 2024 at 3:17 PM Orie Steele <[e-mail]>
>> wrote:
>>
>>> Hello,
>>>
>>> I have done my best to apply all the feedback gathered from the adoption
>>> call, and I want to draw your attention to the latest draft, and its
>>> primary remaining obstacles for discussion at ietf 120.
>>>
>>> In my haste, I may have destroyed something essential. Apologies to my
>>> co-authors, feel free to roast me at the mic line.
>>>
>>> Be advised the github repo for the working group adopted draft is
>>> currently here, PRs are welcome:
>>>
>>> https://github.com/OR13/draft-ietf-jose-hpke-encrypt
>>>
>>> As you can see from the document history -01 addresses several points of
>>> feedback, and uses the terminology and guidance regarding algorithm names
>>> provided by Ilari and others.
>>>
>>> Major changes in this version:
>>>
>>> - JWK is no longer used for encapsulated keys, but "encrypted_key" JWE
>>> member and "ek" header parameter are.
>>> - HPKE mode (base / auth / psk / psk_auth) is no longer included in
>>> algorithm registrations.
>>> - HPKE Setup info and aad are addressed in a single location for both
>>> integrated and key encryption with hpke.
>>> - "dir" approach has been replaced with "enc": <some registered aead>.
>>> - "jwe aad" examples have been added.
>>> - "psk_id" and "auth_kid" examples have been added.
>>>
>>> I've implemented version -01, and the examples are produced from my
>>> prototype.
>>>
>>> Risk areas, and things which we would like to resolve ASAP.
>>>
>>> ### Fully specified HPKE algorithms
>>>
>>> It would be nice to have confidence that the algorithm names will not
>>> change.
>>>
>>> For example where we currently see:
>>>
>>> ```
>>> "alg": "HPKE-P256-SHA256-A128GCM",
>>> "enc": "A128GCM",
>>> ```
>>>
>>> We might see:
>>>
>>> ```
>>> "alg": "HPKE-P256-SHA256",
>>> "enc": "A128GCM",
>>> ```
>>>
>>> Or whatever the working group decides counts as a "fully specified HPKE
>>> algorithm".
>>>
>>> ```
>>> "alg": "HPKE-P256-SHA256+A128KW", ?
>>> ```
>>>
>>> ### HPKE AAD vs JWE AAD
>>>
>>> I think the current approach is better than computing some custom KDF
>>> info from apu / apv... But is setting the following as HPKE AAD enough?
>>>
>>> hpke-info = empty
>>> hpke-aad = encode-protected-header . aad (when JWE aad is available)
>>>
>>> Where encoded protected header is either the protected header for
>>> hpke jwe integrated encryption, or the protected header used in content
>>> encryption, for which the content encryption key is being encrypted?
>>>
>>> ### Lossy conversions
>>>
>>> It's possible to express things in JSON Serialization that can't be
>>> expressed in Compact serialization.
>>> I tried to make this explicit, but we could decide to simply forbid
>>> conversions from JSON to Compact that lose information, or that would move
>>> things around "ek" to "encrypted_key".
>>>
>>>
>>> Thanks for all the feedback during the adoption call.
>>>
>>> Regards,
>>>
>>> OS
>>>
>>> --
>>>
>>>
>>> ORIE STEELE
>>> Chief Technology Officer
>>> www.transmute.industries
>>>
>>> <https://transmute.industries>
>>> _______________________________________________
>>> jose mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>