On Mon, Feb 12, 2024 at 11:09:37PM +0200, Ilari Liusvaara wrote:
> On Mon, Feb 12, 2024 at 12:41:52PM -0600, Orie Steele wrote:
> > See https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5990bis/
> >
> > Do we expect to see RSA Kem support in JOSE and COSE without the use of
> > HPKE?
> >
> > If so, how do we identify RSA keys for use with KEMS? How do we transport
> > KEM CT ?
>
> I would imagine keys specify which KEM those keys use.
>
> And then there would be KEM algorithms analogous to ECDH-ES ones (there
> are a few details about ECDH-ES algorithms that need tweaking for
> things to work with KEMs).
>
> IIRC, only three differences are needed:
>
> - KEM shared secret goes where ECDH result used to go.
> - Where one sticks the KEM ciphertext.
> - Some trivial encaps/decaps process stuff.
>
> Things like KDFs can just be reused as-is.
Attempting to spec things out to check this:
JOSE:
-----
algorithms KEM, KEM+A128KW, KEM+A192KW and KEM+A256KW work like ECDH-ES,
ECDH-ES+A128KW, ECDH-ES+A192KW and ECDH-ES+A256KW respectively with the
following differences:
In the sender end, the shared secret Z is established by encapsulating
to public key. This also yields ciphertext, which is base64url-encoded
and placed to "kct" parameter ("epk" parameter is not used).
In the receiver end, the shared secret Z is established by decapsulating
the (base64url-encoded) ciphertext in the "kct" parameter.
Key derivation uses Concat KDF with inputs as specified in RFC 7518
section 4.6.2.
The key MUST be for some KEM. The KEM algorithm is assumed to have both
shared secret and ciphertext be octet strings.
For security, the KEM used MUST be IND-CCA secure (with exception of
failures caused by malleability).
KEM is Direct Key Agreement and others are Key Agreement with Key
Wrapping.
COSE:
-----
algorithms KEM+HKDF-256, KEM+HKDF-512, KEM+A128KW, KEM+A192KW and
KEM+A256KW work like ECDH-ES+HKDF-256, ECDH-ES+HKDF-512,
ECDH-ES+A128KW, ECDH-ES+A192KW and ECDH-ES+A256KW respectively with
the following differences:
In the sender end, the secret input to the KDF is the shared secret
established by by encapsulating to public key. This also yields
ciphertext, which is placed in the -4 header parameter (the -1 header
parameter is not used).
In receiver end, the secret input to the KDF is the shared secret
established by decapsulating the ciphertext in the -4 header parameter.
Key Derivation uses the KDF defined in RFC 9053 section 5.1, with the
context structure defined in RFC 9053 section 5.2.
The key MUST be for some KEM. The KEM algorithm is assumed to have both
shared secret and ciphertext be byte strings.
For security, the KEM used MUST be IND-CCA secure (with exception of
failures caused by malleability).
KEM+HKDF-256 and KEM+HKDF-512 are Direct Key Agreement and others are
Key Agreement with Key Wrap.
... Seems to hold up pretty well.
No reason to care about malleability, that gets immediately ruined
anyway. However, IND-CCA failures not from malleability tend to be
something nasty that one very much has to care about.
-Ilari
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
