On Tue, Nov 07, 2023 at 02:01:33PM +0100, Rohan Mahy wrote: > > I'll also observe that the interest in the CP NIST curves is currently > unproven and that these COSE ciphersuites could be easily added later.
One issue is that the CP256-AES128 one could warrant one-byte ID, and those require standards action, which is a bit annoying. However, if one requires reference to compact curves, that would likely cause long delays, as the progress on that draft seems very slow (it specifies some other stuff that turns out HPKE folks really do not like). However, compact curve KEMs are stable. The definitions will not change. > I would like to include the X25519/Kyber768 KEM with AES and ChaChaPoly, > but these could also be included later. There is substantial interest in > using a hybrid KEM to prevent harvest-now/decrypt-later attacks. However, a > desire to publish this spec sooner would be a perfectly reasonable > justification to leave these ciphersuite out. If one requires references, then those ciphersuites can not be included. That draft will _never_ be published as an RFC (it has already accomplished its mission). This would get especially annoying with defining the key format. However, the KEM is stable. The registration is permanent and will forever mean what it means now. The EKs are so large that optimizing for alg size is pointless. So it could be handled the same way as HPKE X25519Kyber stuff was: Publish a draft, work it to stable state, get codepoints and abandon it. Another point is that with there being as many ciphersuites as there is, including mode might not be a good idea if non-base modes are to be supported, as it will lead to explosion in number of ciphersuites. HPKE will not decrypt message unless sender and recipient agree on the mode used. For base/PSK distinction, the easiest way would be to have a header parameter containing the PSK id (HPKE validates it, so it can be either unprotected or protected). If that parameter is present, it is PSK, otherwise not. For base/auth distinction, the easiest way is for application to specify the auth key if it is using the auth/authPSK mode. However, this must only apply to layer0. The last requirement on layer0 is because using auth/authPSK with two-layer structure is _insecure_. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
