Much of the work at this stage is going to come under the heading 'standards describe the things that don't matter'.
The exact serialization, I really don't care about at all, but we all have to agree to use the same thing. On Wed, Sep 4, 2024 at 3:00 PM Ilari Liusvaara <[email protected]> wrote: > On Wed, Sep 04, 2024 at 12:59:57PM -0400, Phillip Hallam-Baker wrote: > > Has anyone considered how to encode the recipient info for ML-KEM? > > Yes. > > > > RFC 7518 specifies a different key blob 'JWE Encrypted Key' per algorithm > > and ML-KEM doesn't look like either RSA or DH and its variations. > > Actually, it does look like how DH is used in COSE/JOSE. > > > > RSA has key recovery, DH uses an ephemeral key and fills the epk slot. > > ML-KEM does not create an ephemeral, it looks more like RSA except that > it > > doesn't provide key recovery. > > > > And that means that if there are multiple recipient blobs on a message, > we > > need to extend the definition because we are going to need to encrypt the > > content under the content-shared secret and then wrap that in the shared > > secret from ML-KEM. Which means we are going to need two slots for data, > a > > wrapped key slot and an ML-KEM ciphertext slot. > > Using epk slot would lead to some annoying complications, because that > one needs full key strucure, but one only has a byte string. > > Both COSE and JOSE specify slot to stuff the wrapped key to. > > For stuffing the ML-KEM ciphertext, for COSE, the easiest would be to > reuse the -4 slot from COSE-HPKE. For JOSE, one might have to define > a new parameter. > > > > (Because the content has to be encrypted under the same key for each > > recipient...) > > > > So I am thinking of something like this: > > > > "recipients":[{ > > "kid":"MBUX-V4NE-VRJS-6NT7-6QKR-DE2W-QQBG", > > "ct": "OYT5iH4doxVrj90NRowmffE20OOPLl....RGqaCav6b-Xw4", > > "wmk":"N3KQ0jcCztbOMSOwcvy_UdGNsLL-PMtd9_ZMuWqT4GzEIXj33a > > HlKQ"} > > > > Comments? > > That looks very much off... I would think it would be something like: > > "recipients":[ > { > "header":{ > "alg":"KEM+AES256KW", > "kid":"2011-04-29", > "ek":"geokgoekgosok...oegksgogoesgkosekg" > }, > > "encrypted_key:"D90J_pteUjm-jcoIRrWdgkQuyuzbS584BndndQhPhPvlJbgYWy7qh2qW4qCSmSpW" > } > ] > > The "ek" is the ML-KEM ciphertext, "encrypted_key" is the wrapped key. > > The algorithm has class Key Agreement with Key Wrapping. > > > > > -Ilari > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
