(Below, some of them overlap with Ilari's comments.) Just because it's optional, does not mean that when it's present it should > be ambiguous, or invite negotiation. > I concede that there are examples of this in both JOSE and COSE... I don't > think we need to create more of them.
Sorry, emphasizing that the alg value is optional might not have been a good idea. I'm not saying that having alg as an optional field in JWK is a problem (in fact, I quite like it being optional). What I'm trying to say is that, in the end, the alg value alone cannot be used to achieve a specific cryptographic algorithm agreement or decision between two parties. According to RFC9053 Section 8 (COSE Capabilities), the agreement of parameters between two parties is only done through a combination of alg value and key information. It's just another optional field.... You could make them equivalent by > calling stringify on it, and using that for alg. I don't consider it just another optional field. First, the alg value is already an existing parameter with a defined purpose in the RFC, and it should not include information unrelated to direct key usage, such as KDF or AEAD, nor duplicate information about key properties (like crv) other than kty. RFC 9053 Section 8 also includes the following statement: "... the items that are specific to a key (for example, a curve) should not be included in the algorithm capabilities." While it doesn't explicitly say not to include crv information in the alg value, the author's intention to avoid duplication between the key properties and the alg value can be inferred. Second, the alg value is closely associated with JOSE/COSE, and I believe it could be inconvenient when using JWK as a distribution format for pkR in HPKE without utilizing JOSE/COSE. Finally, another difference is that we have a choice to make "hkc" mandatory by defining a new kty (HPKE-KEM, etc.). I'm sure its possible... But is it a good idea? I think it's a good idea. One reason is that IoT devices are likely to implement only one specific HPKE cipher suite. For instance, a certain IoT device may have AES acceleration on its chip and therefore only implement DHKEM(P-256, HKDF-SHA256)/HKDF-SHA256/AES-128-GCM. However, not all chips or IoT devices have AES acceleration. For example, it is not enabled in RPi4. In such cases, if it's a software implementation, they might choose ChaCha20, which is significantly faster and time attack free, and implement only DHKEM(P-256, HKDF-SHA256)/HKDF-SHA256/ChaCha20-Poly1305. When considering an IoT service that covers various IoT products, it would be convenient to accommodate both types of devices with a single KEM key, right? I don't think we should exclude such use cases. Which vendors have said they really want to advertise capabilities this > way, by exposing a full list of HPKE parameters they support? > Do the folks who implemented HPKE for TLS do this today? > What evidence from implementations supports standardizing this kind of > parameterization? At least ECH (TLS) and OHTTP (HTTP) are doing the same thing. Isn't the fact that various implementations already exist the answer? Even if people show up saying it is being done outside COSE... That's not > necessarily a reason to do the same thing in COSE. Unfortunately, both ECH and OHTTP are defined as dedicated protocols, making it difficult to reuse them. They use binary formats, which adds to the challenge. I believe that if we can achieve the same functionality with a JWKS endpoint, not only JOSE/COSE but also various web applications would be able to easily use HPKE. Reducing the parameterization burden to use it, is one of the few things we > can do to improve the experience for developers. If you want to do that, I believe this can be achieved at a higher layer (such as something like CWT) above COSE-HPKE. For example, let's assume we create something called " Awesome Unlinkable Encrypted Token" (AUET) that uses COSE-HPKE. In this case, we can define AUET version 1 to only use the following two HPKE ciphersuites (one is also fine, of course): - "v1n" (NIST Curve): DHKEM(P-256, HKDF-SHA256)/HKDF-SHA256/AES-128-GCM - "v1s" (Secure Curve): DHKEM(X25519, HKDF-SHA256)/HKDF-SHA256/AES-128-GCM We don't need to worry about the string definitions of "alg". -- Daisuke 2023年7月21日(金) 7:44 Orie Steele <[email protected]>: > > > On Thu, Jul 20, 2023, 5:01 PM AJITOMI Daisuke <[email protected]> wrote: > >> It's *extremely* unfortunate naming choices, because that's not how JOSE >>> works: >> >> >> ...Regarding the KEM/key agreement thing about which we are talking, *that's >> how JOSE works*. >> >> In JOSE, the primary "alg" value for key agreement is "ECDH-ES". >> Not only "crv" but also "kty" cannot be determined by the "ECDH-ES". >> > > This is true... Partially... You still see crv and kty in epk. ( Which is > similar to how you see x and y in enc, for dh kems )... You can't do ecdh > cross curves... Afaik. > > Are we sure we haven't learned how to do this better since JOSE was > standardized? > > >> In the first place, "alg" is just an optional value in JWK/COSE_Key and >> cannot be relied upon. There are plenty of examples of JWKS endpoints >> without "alg" values. >> >> For example, Azure-AD JWKS endpoints like this... >> https://login.microsoftonline.com/common/discovery/keys >> >> Example JWKs in MDN web docs don't use "alg" ... >> >> https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/importKey#json_web_key_import >> > > Yes, alg is optional in both COSE Key and JWK. > > It's not optional in JWS headers, or JWE headers. > > It is optional in COSE Encrypt, and there are good reasons for it to > remain optional everywhere... The most obvious is that a protocol might > only support 1 configuration, an example of this is Apple's wallet protocol. > > Just because it's optional, does not mean that when it's present it should > be ambiguous, or invite negotiation. > > I concede that there are examples of this in both JOSE and COSE... I don't > think we need to create more of them. > > >> > And this is "better" than iterating one list of "advertised algorithms" >> in the sense that it is "more compact" and "safer" ? >> >> I think the "hkc" approach is better. >> - Since it does not rely on "alg", it will work with many existing >> implementations and it can be used not only JOSE/COSE but also many other >> applications. >> > > It's just another optional field.... You could make them equivalent by > calling stringify on it, and using that for alg. > > - If the recipient(server) wants to support multiple KDF/AEADs for one KEM >> algorithm, the "alg" approach should provide multiple KEM keys. >> - etc... >> > > I'm sure its possible... But is it a good idea? > > Which vendors have said they really want to advertise capabilities this > way, by exposing a full list of HPKE parameters they support? > > Do the folks who implemented HPKE for TLS do this today? > > What evidence from implementations supports standardizing this kind of > parameterization? > > Even if people show up saying it is being done outside COSE... That's not > necessarily a reason to do the same thing in COSE. > > We didn't invent the wheel (HPKE) but we can improve it. > > Reducing the parameterization burden to use it, is one of the few things > we can do to improve the experience for developers. > > And it doesn't impact what HPKE can do. > > It impacts what you need to know to use HPKE. > > > >> -- >> Daisuke >> >> 2023年7月21日(金) 1:53 Orie Steele <[email protected]>: >> >>> Inline: >>> >>> On Thu, Jul 20, 2023 at 10:42 AM AJITOMI Daisuke <[email protected]> >>> wrote: >>> >>>> 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.). >>>> >>> >>> https://datatracker.ietf.org/doc/html/rfc9053#section-8.3 >>> >>> I think you are correct. >>> >>> It's *extremely* unfortunate naming choices, because that's not how >>> JOSE works: >>> >>> https://datatracker.ietf.org/doc/html/rfc7518#section-3.1 >>> >>> It's also probably not a "good idea" to use "sha256 with P-521" >>> (mismatch in hash and curve strength) >>> ... Why does COSE encourage this kind of thing, I can't answer that... >>> >>> It leads to devices needing to support a kitchen sink, or only certain >>> protocols, ... it impacts agility. >>> >>> It seems that COSE created even more flexibility than JOSE, and >>> encouraged protocols to lock things down... >>> in other words, it punted responsibility, in a way that JOSE did not. >>> >>> >>>> >>>> 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. >>>> >>> >>> Seems you are required to use key information to use COSE... >>> But not in JOSE... I'm sorta shocked by how bad that is... >>> COSE "alg" values are NEVER enough information. >>> >>> Just for clarity... a receiver needs to advertise a list like this [ >>> kty, crv, alg, hkc ]. >>> >>> And then the sender needs to iterate that list to find a match they >>> support, in order to send. >>> >>> And this is "better" than iterating one list of "advertised algorithms" >>> in the sense that it is "more compact" and "safer" ? >>> >>> >>>> ... 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. >>>> >>> >>> I agree with this. >>> >>> >>>> -- >>>> 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> >>>>> >>>> >>> >>> -- >>> >>> >>> ORIE STEELE >>> Chief Technology Officer >>> www.transmute.industries >>> >>> <https://transmute.industries> >>> >>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
