Hi Orie,
Thanks for your contribution. I am trying to understand your suggestion better. When it comes to the algorithm registry there are only two choices: * A la carte, or * Ciphersuites >From your text below I believe you are arguing for a ciphersuite as Apple uses >it. For the initial versions of the COSE-HPKE we used the ciphersuite approach and then we switched to the a la carte approach. Is it correct that you want to move back to the ciphersuite approach? Once this decision has been taken, there is the question about where to take the registered algorithm values from. Version -05 of the draft takes the values directly from the IANA HPKE registry. In an attempt to avoid creating conflicts with the COSE algorithm registry, they had to be used in the newly designed structure rather than in the “usual” COSE algorithm parameter. Ciao Hannes From: COSE <[email protected]> On Behalf Of Orie Steele Sent: Mittwoch, 31. Mai 2023 15:30 To: cose <[email protected]> Cc: Christopher Wood <[email protected]>; Carsten Bormann <[email protected]>; Henk Birkholz <[email protected]>; Laurence Lundblade <[email protected]>; AJITOMI Daisuke <[email protected]>; Ilari Liusvaara <[email protected]>; Hannes Tschofenig <[email protected]> Subject: [COSE] Updating the COSE alg registry for HPKE These comments are for: https://datatracker.ietf.org/doc/draft-ietf-cose-hpke/ Chris Wood and I had a chat about the HPKE registry: https://www.iana.org/assignments/hpke/hpke.xhtml and how it might interact with the COSE registry: https://www.iana.org/assignments/cose/cose.xhtml I shared: https://datatracker.ietf.org/doc/draft-ajitomi-cose-cose-key-jwk-hpke-kem/ And some of the threads discussing alignment to the conventions we have had previously for "alg" or creating the first registry entry for "alg"that is bound to a parameterization label, "hkc" in the draft above. We also discussed if multiplicity is really necessary, given that it leads to power set issues in unique parameter sets for hpke, for example: { "kty": "HPKE-KEM", "kid": "01", "alg": "HPKE-v1-Base", "hkc": { "kem": 0x020, "kdfs": [0x001, 0x002, 0x003], "aeads": [0x001, 0x002] }, "pub": "y3wJq3uXPHeoCO4FubvTc7VcBuqpvUrSvU6ZMbHDTCI", "priv": "vsJ1oX5NNi0IGdwGldiac75r-Utmq3Jq4LGv48Q_Qc4" } We discussed how DHKems already have `kty` values that are suitable, namely "EC" and "OKP" for dhkems, for example: { "kty": "EC", "crv": "P-256", "x": "mAzzRDFigiSNrNfcvj8oopFUyaUBfa53xEfMurYOMO0", "y": "LTyqRXOgAsC-VdwoHG0cymji27cG1KUq0g2RtamLWbY", // "alg": "ECDH-ES+A128KW" ---> HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM } I shared what Apple is doing: https://developer.apple.com/documentation/passkit/wallet/verifying_wallet_identity_requests#4036908 Where "HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM" is named "APPLE-HPKE-v1"... COSE developers probably would want some integer expression of this for consistency and compactness. Carsten, Henk and I had discussed if it would be possible to get a unique integer from the HPKE registry, so we can keep the conventions we have had to date, regarding alg. See table 18: https://datatracker.ietf.org/doc/html/rfc8152#section-12.4.1 And the section defining COSE Key: https://datatracker.ietf.org/doc/html/rfc8152#section-7.1 Ideally COSE implementers would only need to implement what is in the COSE registry, but we could update the registry such that each new entry aligned with what is already registered in HPKE registry, and where the label and the value are minimized. For example, see: https://datatracker.ietf.org/doc/html/rfc8152#appendix-C.3.3 Compared to: https://datatracker.ietf.org/doc/html/draft-ietf-cose-hpke-05#name-multiple-recipients-two-laye I invite Chris and Carsten to share their thoughts on HPKE and "alg" as expressed in COSE Keys and COSE encryption envelopes. Regards, OS -- ORIE STEELE Chief Technology Officer www.transmute.industries <http://www.transmute.industries> <https://transmute.industries/>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
