> > The point here is... If I tell you -7 (ES256), you know 2 (kty EC2) and 1 > (crv P-256)
... No. In COSE, ES256 can be used not only with P-256 but also with other curves (P-521, etc.). Constrained devices won't ship support for both 6 and 7... so advertising > -8 is therefore ambiguous / not helpful (by itself) ... Now consider advertising "HPKE-Base"... How does this help you know how > to talk to a firmware or relying party? ES256 is also ambiguous... let's use key information. ... why would we go out of our way to add extra information to this > process, when we are supposed to be trying to design for a compact / > constrained environment? ... The current draft(or "hkc" approach) does not prohibit implementing only a specific combination of KEM/KDF/AEAD for constrained environments, and it is also possible not to put HPKE algorithm information in COSE_Key/JWK as an implicit agreement between a sender and a recipient. -- Daisuke 2023年7月20日(木) 23:27 Orie Steele <[email protected]>: > Granted, JOSE & COSE kinda broke this with EdDSA... > > > 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). > > The point here is... If I tell you -7 (ES256), you know 2 (kty EC2) and 1 > (crv P-256) > > If I tell you -8 (EdDSA) .... You know 1 (kty OKP), but *you don't > know if I meant 6 (crv Ed25519) or 7 (crv Ed448)* > > Constrained devices won't ship support for both 6 and 7... so advertising > -8 is therefore ambiguous / not helpful (by itself) > > ... Now consider advertising "HPKE-Base"... How does this help you know > how to talk to a firmware or relying party? > > ... why would we go out of our way to add extra information to this > process, when we are supposed to be trying to design for a compact / > constrained environment? > > OS > > > > On Thu, Jul 20, 2023 at 9:11 AM Michael Prorock <[email protected]> wrote: > >> 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 >> > > > -- > > > ORIE STEELE > Chief Technology Officer > www.transmute.industries > > <https://transmute.industries> >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
