Yes, I think this is the right direction. LL
To go into more detail — while I don’t think this design is fully in the spirit of COSE, I think it is a reasonable and workable compromise. COSE_Encrypt0 wasn’t really intended for a key distribution mechanism like HPKE. It was just intended for a pre-shared CEK. From 9052: COSE messages are built using the concept of layers to separate different types of cryptographic concepts. As an example of how this works, consider the COSE_Encrypt message (Section 5.1 <https://www.rfc-editor.org/rfc/rfc9052.html#EnvelopedData>). This message type is broken into two layers: the content layer and the recipient layer. The content layer contains the encrypted plaintext and information about the encrypted message. The recipient layer contains the encrypted content encryption key (CEK) and information about how it is encrypted, for each recipient. A single-layer version of the encryption message COSE_Encrypt0 (Section 5.2 <https://www.rfc-editor.org/rfc/rfc9052.html#EnvelopedData0>) is provided for cases where the CEK is preshared. <https://www.rfc-editor.org/rfc/rfc9052.html#section-2-4> Also in implementation so far COSE lends it self to a neat object-oriented design. I think Jim maybe have been pursuing this intentionally from looking at his code. Having HPKE plug into Encrypt0 results in a special case in the code. (But since the same set of AEAD algs is used in the content encryption in HPKE as it is for COSE things like key wrap, the HPKE code can be broken up (don’t use the SealBase API) so the call to AEAD is common). HPKE as a COSE_Recipient doesn’t create a special case. The COSE key distribution schemes like ECDH-ES+HKDF-256 faced the same fan out that HPKE did. They chose the ciphersuite approach. I don’t think the large potential fan out automatically meant the design couldn’t use a cipher suite. I think they did it because they wanted to limit the decisions the user needed to make. It is definitely less object code to decode one single integer than the array of parameters we have defined here.I think it might be good to publish a small sensible set of profiles of COSE-HPKE. I think if we’d tried to do the above exactly in the spirit of COSE, we’d have ended up with a design for which you couldn’t use the published python HPKE APIs directly and the COSE-HPKE document would be more complicated and harder to understand, so I think this is a good compromise. When COSE-HPKE goes into t_cose, I doubt there will be one integration point call to Seal<MODE>(pkR, info, aad, pt, …). Rather the sub-parts of HPKE will be called individually at several different places. This will be to have common object code with non-HPKE COSE and to be able to have fewer copies of the potentially large plaintext/ciphertext in memory. This all seems possible with this design. > On Feb 27, 2023, at 10:57 AM, Hannes Tschofenig <[email protected]> > wrote: > > Hi all, > > > I have just submitted version -03 of the COSE-HPKE draft capturing the > feedback on the mailing list from the last 6 months: > > https://datatracker.ietf.org/doc/html/draft-ietf-cose-hpke > > > Please let me know if you think that this version is heading into the > right direction. > > > Ciao > > Hannes > > > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
