On Sun, Jun 04, 2023 at 06:32:21PM +0000, lgl island-resort.com wrote: > > Perhaps restating the obvious… > > If the ephemeral key is generated new for every message, then > PartyU/V are not really needed to ensure uniqueness of the key > output from the KEM (ECDH + HKDF). > > Another thing you could do is have the receiver compare the PartyU/V > values with what is expected. For example, if my name is Joseph and > I known from larger context that a message is from Jane, I then check > that PartyU/V are Joseph and Jane. But maybe not, because if I’m > forging encrypted messages, I can pick those to be what ever I want.
Yup, those should not be picked from the message itself. > Seems to me that PartyU/V should just default to strings like “sender” > and “receiver” for most use cases. There can be an override for use > cases that perhaps want more and/or don’t generate a new ephemeral > key for every message. The default values should be distinct from anything that can be set. > So far COSE-HPKE doesn’t say anything one way or another about info > being a user level parameter. My assumption, like Chris Woods, is > that SealBase and HPKE are internal to a COSE library and that it > wouldn’t be available in the public API. "Application profiles of this specification MAY populate the fields of the COSE_KDF_Context structure or MAY use a different structure as input to the "info" parameter. If no content for the "info" parameter is not supplied, it defaults to a zero-length byte string." (I don't think that is necressarily great.) > The ECDH in 9053 does require parts of COSE_KDF_Context to be input > from the public API. (PartyU/V and probably “other” and > “SuppPrivInfo”. > > I would like my COSE API to be the same for the 9053 ECDH > COSE_Recipients as it is for HPKE, so I don’t want to expose the > SealBase info parameter, but rather expose construction of > COSE_KDF_Context in the API. Note that one could use another context structure that has those fields, but lacks problematic things like keyDataLength and ultimately silly things like AlgorithmID and protected. > Enc_structure of type “Enc_Recipient” seems either derelict or > moribund to me. It is only discussed very briefly in 9052 section 5.3, > the title of this section is "How to Encrypt and Decrypt for AEAD > Algorithms”. The title implies the Enc_structure goes into the AAD > input of an AEAD. No COSE_Recipient type defined so far uses AEAD > or has an AAD input. > > RFC 9052 section 8 could have also been a place where a procedure > for use of Enc_structure of type “Enc_Recipient” could have be given > or a requirement set, but it is silent. I don’t know if this is > intentional or just because it wasn’t thought through. >From section 8.5.2., with emphasis added: "All of the _currently defined_ key wrap algorithms for COSE are AE algorithms." "_if_ the key wrap algorithm is an AE algorithm." So clearly there may be future key wrap algorithm that is not AE. And there is clear assumption that if it is not AE, it is AEAD. I did find some stuff that does not look thought through, from section 8.5.3, there is requirement to have empty protected. The only reason for this that makes sense to me is that there is assumption that all key transports are AE. Requirement like that does not make much sense if one has AEAD-capable key transport. > Jim’s code parallels this situation. It constructs a Enc_structure of > type “Enc_Recipient” and never uses it. Do not confuse not being able to trigger X with not having well-defined criteria when to trigger X. > What we do have in COSE_Recipients is the use of an HKDF which has an > "info” input. In multiple-recipient COSE-HPKE we also have an “info” > input that does pretty much the same thing. > > Single-recipient COSE-HPKE is an odd duck that doesn’t realy follow > along with COSE. Not saying it should not be done, just that we can’t > expect it to fit in or use it much in the argument one way or another. In fact, I would argue it is the multi-recipient COSE-HPKE that is the odd duck. There is no taxonomly of bulk ciphers. There is taxonomy of recipients. As recipient, HPKE would be closest of AEAD-capable key transport. Which is something RFC9052 seems to not consider. > Seems fine for multiple-recipient COSE-HPKE where the next algorithm > is the bulk content encryption algorithm. > > Seems like it would have to be no-alg / 0 for single recipient. There is well-defined algorithm the key material is for. It just that algorithm is always HPKE-v1-Base. Which is bit silly. > Agree with this assessment of 9052 vs 9053, but don’t think 9052 sets > a requirement on the use of Enc_structure of type “Enc_Recipient”. I read that it definitely would for AEAD key wrap. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
