Yes, there has been a *lot* of discussion regarding this on the list already.
On Wed, May 31, 2023 at 2:02 PM Hannes Tschofenig <[email protected]> wrote: > 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? > Yes, I think "alg" should work the way it has previously worked, for both keys and envelopes. I don't think a new "alg" system should be invented in COSE-HPKE. > > > Once this decision has been taken, there is the question about where to > take the registered algorithm values from. > I suggest requesting registrations only for the algorithm suites that people want to use in COSE-HPKE, here: https://www.iana.org/assignments/cose/cose.xhtml This follows the conventions we have for ECDH alg's, which is what many people will be familiar with, and will potentially be upgrading from when considering COSE-HPKE. This will also result in simpler keys and envelopes. > 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. > > > Yes, I disagree with this design choice. It is more contentious and requires more work, because it has to define this "new way of handling alg with an external registry". This complexity is not coming from HPKE, it is coming from wanting to establish new conventions in COSE Keys and Envelopes that avoid registry updates related to new algorithms. If it is going to be attempted, it would be better done in a separate document, as an update to COSE. However, I would still object because as Chris said, it seems to go against the previous conventions, and current trends in security best practices. > 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 > > <https://transmute.industries/> > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
