As you know from the mailing list discussions last year I share your view. I lost the debate and, as an editor, I had to accept the decision of the group. If the mindset has changed in the meanwhile I am happy to update the document again.
Ciao Hannes Orie Steele <[email protected]> schrieb am Do., 1. Juni 2023, 00:44: > 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
