On Jul 25, 2023, at 6:02 AM, Ilari Liusvaara <[email protected]<mailto:[email protected]>> wrote:
On Tue, Jul 18, 2023 at 05:33:09PM +0000, Michael Jones wrote: 14:25-14:40 Summary of contentious issues in HPKE (15 minutes) - Orie Steele Skipping the first question (because it is more complicated), here are my thoughts on the rest: - Should “enc” be opaque in COSE / JOSE? I think yes, for the following reasons: * "enc" enters cryptographic calculations. This guarantees interoperability with raw bstr form. And any transformation done by sender has to be undone by the receiver. * "enc" for arbitrary KEM can not be encoded as COSE_Key / JWK. There already exists usable KEM where this fails. * Even future DHKEMs can fail to be encodeable as COSE_Key / JWK. * Switching between two header parameters depending on if the enc can be encoed as COSE_Key / JWK or not increases complexity a lot. * Compressed keys would save space, but the CP-x stuff from draft-harkins-cfrg-dnhpke-02draft-harkins-cfrg-dnhpke-02 is smaller still with no drawbacks. There was some confusion as to to status of KEM48 (X25519+Kyber). Best to treat it like it was from published Experimental RFC. It is certainly intended to be fully interoperable and stable. My argument for opaque enc is very different. It is not about future algorithms, HPKE module APIs or ease of implementation. It is about following the specification. I think HTTPS is a parallel here. The HTTPS specification didn’t rearrange internals of TLS messages. I believe what we are doing in COSE-HPKE is defining protocol messages for the specification in 6.1 def Seal<MODE>(pkR, info, aad, pt, ...): /* implementation detailes elided */ return enc, ct def Open<MODE>(enc, skR, info, aad, ct, ...): /* implementation detailes elided */ return ctx.Open(aad, ct) Particularly “enc” and “ct” are the output messages on the sender side to be transmitted in a COSE_Encrypt message to the receiver. Python is the specification formalism here kind of like ABNF or CDDL, but unlike ABNF or CDDL, Python is serving three purposes: 1) Specify the top level messages. This is usually done with ABNF, CDDL or such 2) Specify how to construct the messages. This is typically done in prose so as to not bias to one implementation or another. 3) An actual running implementation. This rarely in an IETF specification. For integration of HPKE into COSE only 1) is relevant. If you do look inside the RFC 9180 Python, you will find a complete and clear specification of how to encode “enc”. It says enc = SerializePublicKey(pkE) The section 7.1.1 clearly defines what SerializePublicKey()does. There’s no wiggle room or underspecification. It doesn’t say that HPKE users may choose alternate serialization formats or such. From a formal specification view, it seems wrong to reach in to essentially parts of RFC 9180 and discard them. To go on a bit more… - COSE-HPKE will have to say that RFC 9180 section 7.1.1 is replaced by a COSE-Key, rather than just defining a simple header param to carry “enc” - I don’t see any implementation benefits here - - COSE_Key is a more complex structure than the “enc” parameter that will increase code size and complexity - - COSE_Key has redundant info that has to be cross-checked (key type, curve) - - HPKE libraries will take care of everything for binary “enc” and be simple to integrate LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
