Following up on this: On Tue, Jul 25, 2023 at 2:07 PM lgl island-resort.com <[email protected]> wrote:
> > > On Jul 25, 2023, at 6:02 AM, Ilari Liusvaara <[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) > This depends on how it might be used. Yes, it's possible to pull apart DHKem output into a kty: EC / crv P256 setup... but it's also possible to just treat enc a regular bytes: { "kid": "...opaque-dhkem-output", "alg": "...", // probably not a thing, but just for argument's sake. "kty": "oct", "k": "04 + x + y ...." } vs { "kty": "EC", "crv": "P-256", "x": "mpWfwr7bhFcmmDDQkpc5KGua-PaI7tbakIpZc4rKy38", "y": "uqdK_tLp8_7Xt3uH3zhjv5JwPygp-lPGRNdhBSwAkSg", "use": "enc", // probably not a thing, but just for argument's sake. "key_ops": [ "deriveBits" ], // probably not a thing, but just for argument's sake. "alg": "..." // probably not a thing, but just for argument's sake. } - - HPKE libraries will take care of everything for binary “enc” and be > simple to integrate > > Given the encap / decap APIs that each registered kem needs to define I agree that avoiding doing surgery on enc is preferred, but I still question if it's worth communicating enc in a structured wrapper like a Map or a COSE Key, or if it's better to just forward it as is. Are there any channel binding considerations related to encap / decap? OS > LL > > > > > > > > > > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
