On Fri, Jul 14, 2023 at 12:04:30PM -0500, Orie Steele wrote: > Here is an example of how different versions of HPKE might choose to encode > `enc` with their favorite way to represent opaque bytes: > > https://gist.github.com/OR13/7d99f46c56e7f78082097452158125ef
This seems way more complicated than necressary. Just base64url-encode the stuff and stick it into string. Or in COSE, just stick it in bstr. > Coming from W3C where we see a lot of "new ways to represent opaque bytes > of a (un?) known type"... > > I would expect at a minimum: <snip list of different ways to represent "keys"> > I think all of these are valid interpresentation of HPKE, and might > have great use cases. > > None of them will be interoperable. I do not think any of those is a valid interpretation of HPKE. HPKE _defines_ enc as opaque octet string. If it is not transported exactly, HPKE will simply fail to decrypt anything. > I think: > > - JOSE should encode enc as a JWK, > - COSE should encode it as a COSE Key > > This will improve interoperability. And how that would work for KEM48? - Not supporting that KEM is not acceptable. - It has ciphertexts that are not keys. - Making some KEMs use eph and others use another parameter is not acceptable. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
