Hi Orie, I'm looking forward to hearing Chris and Carsten's opinion, but I would like to briefly state my opinion in advance.
> 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"... I believe we should not conflate the choices made by a single company like Apple for their own service with the choices that COSE-HPKE needs to make, considering a wide range of use cases. I apologize for repeating the same discussion, but to put it simply, my proposal is easy to implement. There is no need to implement unnecessary ID conversion processes, and once implemented, there will be no need to change the implementation in the COSE library layer in the future. I believe this is also desirable from a security perspective. If you argue that creating RFCs for using new post-quantum KEMs in COSE is not a significant issue every time they emerge, I have nothing to say. However, personally, I believe such an approach is a waste of time. Best, AJITOMI Daisuke 2023年5月31日(水) 22:30 Orie Steele <[email protected]>: > 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> >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
