A correction/clarification - basically, while you see both kty and alg together, if you have a well defined alg, you always know what kty is for that alg - so derivation is from alg alone
Mike Prorock CTO - mesur.io On Thu, Jul 20, 2023, 08:01 Michael Prorock <[email protected]> wrote: > Daisuke, > definitely 'combination of "alg" and key information.', especially as > things have started to evolve recently. However, I think the point that > Orie is trying to make (please correct me if I am wrong Orie) is that once > you have the 'kty' which lets you know what shape and family of keys you > are dealing with, then you should have everything you need from 'alg' and > nothing else. > > Mike Prorock > CTO, Founder > https://mesur.io/ > > > > On Thu, Jul 20, 2023 at 7:53 AM AJITOMI Daisuke <[email protected]> wrote: > >> Daisuke asserts “On the other hand, there are no examples like the >>> proposal from Hannes/Laurence, where the "alg" value includes information >>> about "crv" values and unrelated key operation information (e.g., KDF, >>> AEAD)”. There are actually many such examples. >> >> >> It mainly concerns the latter, which is ”unrelated key operation >> information". Anyway, while it is true that JOSE's ES* algs include the >> "crv" value implicitly, the COSE's ES* algs don't. The COSE's ES256 >> algorithm is not limited to P-256 and this crv value and the information >> about whether the key is compressed EC point or not ultimately requires >> referring to the key info. >> >> Therefore, in COSE, even ES256 has to be defined as follows: >> >> - -7 (ES256), where kty is 2 (with uncompressed points) and crv is 1 >> (P-256). >> >> It is evident that the mainstream approach is to negotiate using a >> combination of "alg" and key information. >> >> -- >> Daisuke >> >> >> 2023年7月20日(木) 9:55 Michael Jones <[email protected]>: >> >>> [chair hat off] >>> >>> >>> >>> The interoperability problem caused by polymorphic algorithm identifiers >>> is that the “alg” and “enc” values are no longer useful for algorithm >>> negotiation. >>> >>> >>> >>> In protocols such as OpenID Connect, OAuth 2.0, and WebAuthn/FIDO2, lists >>> of supported “alg” and “enc” values are published in metadata. For >>> instance, here’s an example from RFC 8414: >>> >>> "token_endpoint_auth_signing_alg_values_supported": >>> >>> ["RS256", "ES256"], >>> >>> >>> >>> The problem with polymorphic algorithm identifiers such as “EdDSA” is >>> that they don’t actually specify which algorithm is used. It could mean >>> either “Ed25519” or “Ed448”. You can’t advertise which you support and/or >>> which you want. >>> >>> >>> >>> This is a problem in practice for WebAuthn, since some COSE alg >>> identifiers are polymorphic and WebAuthn and FIDO2 use COSE algorithm >>> identifiers for negotiation. See that WebAuthn specified that EdDSA always >>> uses Ed25519 – making it non-polymorphic but precluding its use with >>> Ed448. Here’s the line doing so at >>> https://www.w3.org/TR/webauthn-2/#sctn-public-key-easy: >>> >>> - -8 (EdDSA), where crv >>> <https://tools.ietf.org/html/rfc8152#section-13.1.1> is 6 (Ed25519). >>> >>> >>> >>> Daisuke asserts “On the other hand, there are no examples like the >>> proposal from Hannes/Laurence, where the "alg" value includes information >>> about "crv" values and unrelated key operation information (e.g., KDF, >>> AEAD)”. There are actually many such examples. >>> >>> >>> >>> All the registered JOSE algorithms (for example “ES256”) fully >>> specified all parameters until “EdDSA” was registered. The COSE >>> algorithms from RFC 8812 fully specify all parameters, such as when >>> secp256k1 is used and when RSASSA is used. >>> >>> >>> >>> Likewise, if we had a single HPKE algorithm identifier, it couldn’t be >>> used to distinguish which HPKE algorithms are supported (and not all will >>> be by all implementations). This would cause the same problem for future >>> systems that, for instance, WebAuthn/FIDO2, OAuth 2.0, and OpenID Connect >>> already encounter when polymorphic algorithm identifiers are used. >>> >>> >>> >>> -- Mike >>> >>> >>> >>> *From:* AJITOMI Daisuke <[email protected]> >>> *Sent:* Wednesday, July 19, 2023 3:45 PM >>> *To:* Michael Jones <[email protected]>; Ilari Liusvaara < >>> [email protected]> >>> *Cc:* cose <[email protected]> >>> *Subject:* Re: [COSE] Draft IETF 117 COSE agenda >>> >>> >>> >>> > Speaking as an individual contributor, I fully support the first >>> > (fully specified) choice. Whereas the second possibility will cause >>> > endless interoperability problems. >>> >>> >>> I disagree. >>> >>> >>> +1 >>> >>> (Below, I comment from the standpoint that the design of alg values >>> should be consistent with COSE and JOSE.) >>> >>> I am convinced that the "fully specified" design, on the contrary, >>> includes more interoperability issues. >>> >>> Originally, in JOSE and COSE, the identification of the specific >>> cryptographic algorithm was done by combining the "alg" value ("ECDH-ES," >>> "EdDSA," etc.) with the information held by the key itself ({"kty": "EC", >>> "crv": "P-256", ...}, {"kty": "OKP", "crv": "Ed25519", ...}, etc.). >>> The current draft follows this approach. On the other hand, there are no >>> examples like the proposal from Hannes/Laurence, where the "alg" value >>> includes information about "crv" values and unrelated key operation >>> information (e.g., KDF, AEAD) to the original key's purpose. In JWK, the >>> "alg" value is merely an optional parameter, so packing excessive >>> information into the "alg" value will, in fact, lead to interoperability >>> issues. >>> >>> I have repeatedly written about the reasons why the current >>> specification is better than the "fully specified" design (*1, *2). >>> However, I would like to add one more point from a new perspective. >>> >>> I am very concerned that JWK, which is a "JSON representation of keys" >>> that could be used for a wide range of applications not limited to JOSE and >>> COSE, will no longer be available as a means of transmission and >>> negotiation of HPKE parameters. I think this is a very big loss. >>> >>> The following works with no problem with existing JWK implementations, >>> and it is also guaranteed to work in the JWK RFC: >>> >>> { >>> kty: "EC", >>> crv: "P-256", >>> // alg: "HPKE-v1-Base(-KEM)", // alg can be omitted as many >>> JWKs do >>> hkc: { kem: 0x0010, kdfs: [0x0001], aeads: [0x0001]}, // Unknown >>> parameters for the JWK implementation MUST be ignored on the JWK layer. >>> x: "-eZXC6nV-xgthy8zZMCN8pcYSeE2XfWWqckA2fsxHPc", >>> y: "BGU5soLgsu_y7GN2I3EPUXS9EZ7Sw0qif-V70JtInFI", >>> } >>> >>> On the other hand, the following does not work with many existing JWK >>> implementations. This is because existing JWK implementations often throw >>> errors for "alg" values not supported by the bundled JWS/JWE: >>> >>> { >>> kty: "EC", >>> crv: "P-256", >>> alg: " HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM", >>> // Must be specified to specify HPKE parameters if not assuming an >>> offline(implicit) agreement. >>> x: "-eZXC6nV-xgthy8zZMCN8pcYSeE2XfWWqckA2fsxHPc", >>> y: "BGU5soLgsu_y7GN2I3EPUXS9EZ7Sw0qif-V70JtInFI", >>> } >>> >>> I think this example clearly illustrates the harm of putting subsequent >>> algorithm information (KDF&AEAD), which is not originally relevant to the >>> key itsef, into a key that is originally only used in the KEM step. >>> >>> >>> In any case, I am tired of the situation where even after all these >>> repeated discussions, even the obvious design point, which is obvious if >>> you read the HPKE standard, that "encapsulated_key should be expressed as a >>> sequence of bytes," is being rehashed... >>> >>> I hope the chairs will make a wise decision. >>> >>> Best regards, >>> Daisuke >>> >>> P.S. >>> ... the design of COSE-HPKE was more difficult than I had thought, as it >>> required not only knowledge of both COSE and HPKE, but also knowledge of >>> JOSE (primarily JWK) in terms of alg value design, and related >>> considerations of consistency with the W3C Web Cryptography API and >>> existing implementations. So I do not intend to ask you (the mailing list >>> participants) to agree with my suggestion easily, but I'm very glad if you >>> could read (*1)(*2) without bias. >>> >>> (*1) >>> https://mailarchive.ietf.org/arch/msg/cose/KTpXbZ3UxUH8BuLT4OmhfaToYTk/ >>> (*2) >>> https://mailarchive.ietf.org/arch/msg/cose/cPqYqCagPbWPKwvQODjqn98U3F4/ >>> >>> 2023年7月20日(木) 2:37 lgl island-resort.com <[email protected]>: >>> >>> >>> >>> >>> >>> On Jul 19, 2023, at 9:52 AM, Michael Jones <[email protected]> >>> wrote: >>> >>> >>> >>> As a chair, I’d like clarity on what you mean by “the single algorithm >>> design”. Do you mean that each algorithm identifier fully specifies all >>> the cryptographic parameters being used? Or do you mean that a single >>> algorithm identifier is used for all the HPKE possibilities? >>> >>> >>> >>> The proposal that Hannes, Jeremy and a few others favor is roughly this. >>> (I picked these three just as an example, the decision we want is not >>> whether these three are the ones to register, it is that we will use one >>> algorithm ID to indicate the HPKE KEM, KDF and AEAD. >>> >>> >>> >>> *Alg ID HPKE-P-256 (equivalent to COSE -29 with NIST key)* >>> >>> KEM: 0x0010 DHKEM(P-256, HKDF-SHA-256) >>> >>> KDF: 0x0001 HKDF-SHA256 >>> >>> AEAD: 0x0001 AES-128-GCM >>> >>> >>> >>> *Alg ID HPKE-P-384 (equivalent to COSE -30 with NIST key)* >>> >>> KEM: 0x0011 DHKEM(P-384, HKDF-SHA-384) >>> >>> KDF: 0x0002 HKDF-SHA384 >>> >>> AEAD: 0x0002 AES-256-GCM >>> >>> >>> >>> *Alg ID HPKE-P-521 (equivalent to COSE -31 with NIST key)* >>> >>> KEM: 0x0012 DHKEM(P-521, HKDF-SHA-512) >>> >>> KDF: 0x0003 HKDF-SHA512 >>> >>> AEAD: 0x0002 AES-256-GCM >>> >>> >>> >>> The one that Ilari and Ajitomi-san favor is what we have now in >>> COSE-HPKE: >>> >>> >>> >>> When the alg value is set to 'HPKE-v1-BASE', the HPKE_sender_info >>> >>> structure MUST be present in the unprotected header parameter. >>> >>> >>> >>> The CDDL grammar describing the HPKE_sender_info structure is: >>> >>> >>> >>> HPKE_sender_info = [ >>> >>> kem_id : uint, ; kem identifier >>> >>> kdf_id : uint, ; kdf identifier >>> >>> aead_id : uint, ; aead identifier >>> >>> enc : bstr, ; encapsulated key >>> >>> ] >>> >>> >>> >>> >>> >>> >>> >>> Speaking as an individual contributor, I fully support the first (fully >>> specified) choice. Whereas the second possibility will cause endless >>> interoperability problems. >>> >>> >>> >>> We need your efforts primarily has a chair at this point. I think we’ve >>> had the discussion. >>> >>> >>> >>> LL >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> COSE mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/cose >>> >>> _______________________________________________ >> COSE mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/cose >> >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
