The convention established by RFC8152 and updated in RFC9052 says the following about the "alg" header parameter:
alg: This parameter is used to restrict the algorithm that is used with the key. If this parameter is present in the key structure, the application MUST verify that this algorithm matches the algorithm for which the key is being used. If the algorithms do not match, then this key object MUST NOT be used to perform the cryptographic operation. Note that the same key can be in a different key structure with a different or no algorithm specified; however, this is considered to be a poor security practice. My interpretation of this is that "alg" fully specifies the algorithm that is to be used for the object. For HPKE, the algorithm consists of the mode and ciphersuite parameters (KEM, KDF, and AEAD). On that basis, Orie's suggestion to use a single identifier or label that maps to an HPKE mode and ciphersuite seems best. It also matches the very high level abstraction that alg seems to target, being a very generic identifier for a "security thing." Beyond matters of consistency and abstraction alignment, I'll note that splitting up algorithm "negotiation" across parameters runs counter to the trend I've seen in higher-level security protocols lately, which is roughly "versions define ciphersuite/algorithm parameters." This lets implementations check precisely one thing, a version, label, or, in this case, the "alg" parameter, and determine how to process the rest. It does not introduce additional processing complexity. (I understand that the alternative proposal with the "hkc" parameters may not seem overly difficult, but it does effectively break from the mold of '"alg" fully defines the algorithm'.) As a final note, the contents of the registry do matter. I consider HPKE to be a fairly low-level primitive, whereas I (perhaps naively) view COSE as a higher-level application protocol. We have the expertise to be opinionated about what goes into that registry for applications to use, and we should exercise that opinion to provide folks with a very limited set of options, ideally target precisely one. The "HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM" label seems like a perfectly fine candidate for that. I hope this helps. Best, Chris > On May 31, 2023, at 11:09 AM, AJITOMI Daisuke <[email protected]> wrote: > > 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 > _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
