Re: [COSE] [jose] Call for Adoption: draft-ajitomi-cose-cose-key-jwk-hpke-kem

[AJITOMI Daisuke <[e-mail]>]

> This is not true, I showed a counter example using your library.

I'm not confident that I fully understand what you're saying, but I cannot
agree with you.
The HPKE_Sender_Info structure cannot be replaced with COSE_Key/JWK
representations for KEM.
They are completely different things.
Are you claiming that the representation of HPKE_Sender_Info in JOSE should
also be defined in the COSE-HPKE spec?
That is almost equivalent to "adding HPKE to JWE".

> 2. register "alg" values that map to "hkc", like Apple does, and as I
have shown on https://hpke.dev

I believe that comparing the specification of Apple's Wallet app with
COSE-HPKE is inappropriate. The former is simply the specification of an
app from a single company, and adopting a ciphersuite approach is a
reasonable choice for this kind of particular use case.

On the other hand, COSE-HPKE should be a generic specification that does
not assume any specific use case or application. Since HPKE is designed to
be cryptoagility-oriented, it is natural to follow that design philosophy
in COSE-HPKE as well. If someone wants to adopt a ciphersuite-based
approach, they can do so on higher-level applications that utilize
COSE-HPKE.

> Laurence seems neutral so far

... at least, the definitions of the "alg" value  (HPKE-v1-{Base, Auth,
PSK, AuthPSK}) included in the COSE-HPKE specification and my draft were
proposed by Laurence (I like this idea), so I believe that Laurence
supports the current COSE-HPKE. Also, the definitions of the "alg" value
are also an important part of my draft. Therefore, with Laurence's consent,
we have added him as a co-author in the latest draft. Of course, I don't
think Laurence fully agrees with my current draft.

Best,
AJITOMI Daisuke

2023年4月17日(月) 22:11 Orie Steele <[e-mail]>:

> Inline:
>
> On Mon, Apr 17, 2023 at 7:25 AM AJITOMI Daisuke <[e-mail]> wrote:
>
>> https://datatracker.ietf.org/doc/html/rfc8812
>>
>>
>>> ^ this RFC defined JWK and COSE key for secp256k1, and it registered an
>>> algorithm for use in JWS Headers.
>>
>>
>>> I am suggesting COSE HPKE do the same thing, we don't need to do
>>> anything with JOSE other than define reasonable algorithms in COSE, and
>>> ensure that you can signal their use in JWK & COSE Key, consistently, just
>>> like the above RFC does.
>>
>>
>> Well, is your argument that the "Use of HPKE with COSE'' should be
>> extended to "Use of HPKE with COSE and JOSE"?
>>
>> I believe that Hannes' scoping of the COSE-HPKE specification, which
>> focuses on the structure including the encapsulated key called
>> HPKE_Sender_Info and how to represent it in the COSE container, was very
>> reasonable from the beginning. It is focused on the minimal specification
>> necessary to use HPKE on COSE, and the representation of the recipient
>> public key for KEM is excluded from the scope. As I wrote in b) above, this
>> is because the key representation is not essential for COSE-HPKE and can be
>> left to the application layer.
>>
>> Now, if we extend this specification to "Use of HPKE with COSE and JOSE,"
>> we will also need to decide how to represent HPKE_Sender_Info on JOSE. This
>> is completely different from RFC8812, which only registers parameters with
>> the IANA registry. We need to define what we have been doing with COSE-HPKE
>> within the constraints specific to JOSE. Ilari says this is very difficult,
>> but to be honest, I don't understand the extent of the difficulty. However,
>> at least, it is certain that this is not a matter that can be settled with
>> just registering parameters with the IANA registry.
>>
>
> This is not true, I showed a counter example using your library.
>
> There may be difficulty in "adding HPKE to JWE", but it is not
> difficult to make a JWK / COSE Key that supports HPKE regardless of if you
> are using a COSE HPKE library or a regular one, like hpke-js.
>
> I am not saying the COSE WG needs to do more than define keys consistently
> and define how "alg" relates to them when it is in "cose headers".
>
> There are 2 options on the table:
>
> 1. parameterize "alg" with  "hkc" and relate it to "sender_info"... which
> is * revolutionary *.
> 2. register "alg" values that map to "hkc", like Apple does, and as I have
> shown on https://hpke.dev
>
> We are currently doing 1, and if I am in the minority on this point, I
> expect 1 to proceed... I still think the key side should be handled in the
> same document if 1 is taken, and hence another draft is a mistake.
>
> I think 1 is a mistake, and I see Ilari, and Daisuke advocating for it,
> Laurence seems neutral so far, but has noted we should try to follow
> conventions that COSE has set, let's assume for the sake of argument that
> Laurence is pro option 1 and anti option 2.
>
> At best option 1 has 3 people supporting it and option 2 has 1 person
> supporting it.
>
> Since option 1 is pretty revolutionary, I think the bar for accepting it
> should be a bit higher than that.
>
> OS
>
>
>
>
>
>>
>> I feel that this contradicts your opinion that JOSE should not delay
>> COSE-HPKE.
>>
>> Best,
>> AJITOMI Daisuke
>>
>>
>> 2023年4月17日(月) 8:43 Orie Steele <[e-mail]>:
>>
>>>
>>> Inline:
>>>
>>> On Sun, Apr 16, 2023 at 4:33 PM AJITOMI Daisuke <[e-mail]>
>>> wrote:
>>>
>>>> Yes, I believe the JWK and COSE Key Representations for HPKE should be
>>>>> defined together.
>>>>
>>>>
>>>>  So, could I understand that you agree to the adoption of this draft
>>>> into the WG document? Or do you think there are things that need to be done
>>>> before adoption?
>>>>
>>>
>>> Yes, the thing that needs to be done is address the use of "alg", in
>>> headers, and keys, consistently.
>>>
>>> In my opinion, this work needs to be done in the COSE HPKE draft, and
>>> when it is done, there will not be a need for a second draft focusing only
>>> on keys.
>>>
>>> https://datatracker.ietf.org/doc/html/rfc8812
>>>
>>> ^ this RFC defined JWK and COSE key for secp256k1, and it registered an
>>> algorithm for use in JWS Headers.
>>>
>>> I am suggesting COSE HPKE do the same thing, we don't need to do
>>> anything with JOSE other than define reasonable algorithms in COSE, and
>>> ensure that you can signal their use in JWK & COSE Key, consistently, just
>>> like the above RFC does.
>>>
>>> I don't support adoption of "draft-ajitomi-cose-cose-key-jwk-hpke-kem".
>>>
>>> I support including its contents in the already adopted
>>> "draft-ietf-cose-hpke".
>>>
>>>
>>>>
>>>> 2023年4月17日(月) 5:24 Orie Steele <[e-mail]>:
>>>>
>>>>> Inline:
>>>>>
>>>>> On Sun, Apr 16, 2023 at 3:10 PM AJITOMI Daisuke <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> Hi Orie,
>>>>>>
>>>>>> > 8812 defined an "alg" and key representations for JWK and COSE Key
>>>>>> in one document.
>>>>>>
>>>>>> At least, I want to define both key representations and alg values in
>>>>>> the same draft if possible as I mentioned in the previous mail as follows:
>>>>>>
>>>>>> > > If this draft is adopted as a working group document, I was
>>>>>> thinking of proposing to move the definition of alg values from the
>>>>>> COSE-HPKE spec to this draft.
>>>>>>
>>>>>> And I don't think defining alg values other than HPKE-v1-Base
>>>>>> beforehand is as bad an idea as Ilari suggests.
>>>>>>
>>>>>> The mode-dependent processing in HPKE is all confined to the KEM step
>>>>>> and all HPKE modes are clearly defined within the HPKE spec (RFC9180), and
>>>>>> it is evident that this does not affect the key representation for KEM and
>>>>>> the "hkc" structure.
>>>>>>
>>>>>> I thought you believed that JWK and COSE_Key for HPKE should be
>>>>>> defined simultaneously (in the same draft), or am I mistaken?
>>>>>> If you think JWK and COSE_Key should be defined together, separating
>>>>>> the key representation draft from the COSE-HPKE might not be a bad idea.
>>>>>>
>>>>>>
>>>>> Yes, I believe the JWK and COSE Key Representations for HPKE should be
>>>>> defined together.
>>>>>
>>>>> I would have started with this part, since HPKE assumes the sender has
>>>>> the recipient's key, and that they have agreed to mutually supported
>>>>> algorithms.
>>>>>
>>>>> Holding a restricted key is a natural way to capture this assumption,
>>>>> although it is not the only way to achieve it.
>>>>>
>>>>>
>>>>>> Best,
>>>>>> AJITOMI Daisuke
>>>>>>
>>>>>> 2023年4月16日(日) 23:09 Orie Steele <[e-mail]>:
>>>>>>
>>>>>>>
>>>>>>> Inline:
>>>>>>>
>>>>>>> On Sun, Apr 16, 2023 at 7:06 AM AJITOMI Daisuke <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Orie,
>>>>>>>>
>>>>>>>> Sorry for the late reply. I think I will be able to respond more
>>>>>>>> quickly starting from this week...
>>>>>>>> Thank you for the feedback on my draft.
>>>>>>>>
>>>>>>>> I think there are several topics mixed in this thread, but first,
>>>>>>>> I'd like to comment on whether this draft should be merged into the
>>>>>>>> existing COSE-HPKE spec.
>>>>>>>>
>>>>>>>>
>>>>>>> Agreed, Laurence has summarized them well.
>>>>>>>
>>>>>>> 1. "alg" in Headers
>>>>>>> 2. "alg" & "kty" in COSE Key and JWK
>>>>>>> 3. Negotiation of "alg"
>>>>>>>
>>>>>>> The reasons why I proposed this draft as an independent
>>>>>>>> specification separate from COSE-HPKE are as follows:
>>>>>>>>
>>>>>>>> a) I wanted to define not only COSE_Key but also JWK representation
>>>>>>>> together for HPKE. This is the biggest reason.
>>>>>>>>
>>>>>>>
>>>>>>> 8812 defined an "alg" and key representations for JWK and COSE Key
>>>>>>> in one document.
>>>>>>>
>>>>>>> - https://www.rfc-editor.org/rfc/rfc8812
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> b) Key representation is essentially independent of the COSE
>>>>>>>> message format and can be used for various applications unrelated to COSE
>>>>>>>> or JOSE.  As I mentioned in the slides for IETF116, I thought it would be
>>>>>>>> beneficial for applications using HPKE for end-to-end encryption over HTTP
>>>>>>>> if the HPKE recipient's public key could be published at the
>>>>>>>> .well-known/jwks endpoint. COSE_Key representation may also be useful for
>>>>>>>> CoAP-based end-to-end encryption apps in the same way.
>>>>>>>>
>>>>>>>>
>>>>>>> Yes,  I agree that representing keys in JSON and CBOR is valuable to
>>>>>>> many use cases outside of COSE and JOSE.
>>>>>>>
>>>>>>> c) I wanted to consolidate the definitions of all expected alg
>>>>>>>> values (HPKE-v1-{Base, Auth, PSK, AuthPSK}) into one document. Although I
>>>>>>>> had agreed with the opinion that the COSE-HPKE should focus only on the
>>>>>>>> Base mode, I thought it would be better to have all alg values for HPKE
>>>>>>>> modes consolidated into one document. If this draft is adopted as a working
>>>>>>>> group document, I was thinking of proposing to move the definition of alg
>>>>>>>> values from the COSE-HPKE spec to this draft.
>>>>>>>>
>>>>>>>> Regarding (a), for example, the key representation for secp256k1
>>>>>>>> has both JWK and COSE_Key formats defined (RFC8812), and the recent
>>>>>>>> post-quantum key representation proposed by Mike Prorock also has both JWK
>>>>>>>> and COSE_Key formats defined.
>>>>>>>>
>>>>>>>
>>>>>>> Yes, I generated the current JWK / JWS test vectors for those
>>>>>>> drafts, the first thing I did, was the key format... the second thing I did
>>>>>>> was the envelope format for the signatures:
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/mesur-io/post-quantum-signatures/blob/main/test-vectors/suites/dilithium-pqcrypto/jwk.js
>>>>>>>
>>>>>>> https://github.com/mesur-io/post-quantum-signatures/blob/main/test-vectors/suites/dilithium-pqcrypto/jws.js
>>>>>>>
>>>>>>> When I implemented the signature interface, it took a JWK private
>>>>>>> key, not a "raw dilithium 3 private key"... the thought process there was
>>>>>>> that it should reject a key that had been restricted to a different
>>>>>>> algorithm...
>>>>>>>
>>>>>>> Meaning you can always ask for ES256K from a key restricted to
>>>>>>> EdDSA... but that should error, before an expensive / sensitive operation
>>>>>>> is attempted.
>>>>>>>
>>>>>>> Same thing on the verify side:
>>>>>>> The verify interface takes a public key in JWK format, not a "raw
>>>>>>> dilithium 3 public key".
>>>>>>> You can try to verify ES256K with a key restricted to EdDSA... that
>>>>>>> should also error, before an expensive / sensitive operation is attempted.
>>>>>>>
>>>>>>> It is natural to ask for an operation from a key that is restricted
>>>>>>> to a single algorithm, this won't always be the case, since "alg" is
>>>>>>> optional, but it should be well supported for developers who want to build
>>>>>>> safer APIs.
>>>>>>>
>>>>>>> If we follow recent conventions, it would be better to define both
>>>>>>>> COSE_Key and JWK representations together, don't you think? As I also
>>>>>>>> mentioned in the slides for IETF116, in the EUDCC (EU Digital COVID
>>>>>>>> Certificate) where COSE has been adopted, the public keys for signature
>>>>>>>> verification were distributed in JWK format. JWK format is also useful for
>>>>>>>> COSE.
>>>>>>>>
>>>>>>>>
>>>>>>> Yes, I agree they should be done together, see RFC 8812.
>>>>>>>
>>>>>>> I disagree that they should be done separate from "alg", here is a
>>>>>>> short list of RFCs that define both "alg" and "kty" / "crv" together:
>>>>>>>
>>>>>>> - https://www.rfc-editor.org/rfc/rfc8812
>>>>>>> - https://www.rfc-editor.org/rfc/rfc8037
>>>>>>> - https://www.rfc-editor.org/rfc/rfc8152.html
>>>>>>>
>>>>>>>
>>>>>>>> If it is concluded that JWK should not be defined together, and
>>>>>>>> that the definition of key representation should be limited to the HPKE
>>>>>>>> Base mode, and that other HPKE modes should not be defined at this point,
>>>>>>>> then it may indeed be better to merge this draft into the COSE-HPKE spec.
>>>>>>>> On the other hand, if there is room for discussion on these issues, I think
>>>>>>>> it would be appropriate to consider it as an independent draft currently.
>>>>>>>> We can merge it into the COSE-HPKE spec at any time. What do you think?
>>>>>>>>
>>>>>>>>
>>>>>>> I think you should continue working on it as an I-D, find
>>>>>>> co-authors, implement library support for it, confirm your representations
>>>>>>> align with previous libraries, and conventions their uses will assume, and
>>>>>>> continue to press COSE HPKE to integrate reasonable key representation into
>>>>>>> the same document that discussed "senders" and "recipients" and assumed
>>>>>>> "they have already obtained each other's keys" : )
>>>>>>>
>>>>>>> I recommend reviewing the experience provided here:
>>>>>>>
>>>>>>> -
>>>>>>> https://github.com/panva/jose/blob/a505724d72705b8bfab8026af45678b2a5534bf4/docs/classes/jwe_general_encrypt.GeneralEncrypt.md
>>>>>>> - https://github.com/potatosalad/erlang-jose
>>>>>>> - https://docs.authlib.org/en/latest/jose/jwe.html
>>>>>>> - https://github.com/cisco/cjose/blob/master/src/jwe.c
>>>>>>> - https://github.com/digitalbazaar/minimal-cipher
>>>>>>>
>>>>>>> You might also look at previous related drafts:
>>>>>>>
>>>>>>> -
>>>>>>> https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu-04
>>>>>>>
>>>>>>>
>>>>>>>> Best,
>>>>>>>> AJITOMI Daisuke
>>>>>>>>
>>>>>>>> 2023年4月16日(日) 14:12 Ilari Liusvaara <[e-mail]>:
>>>>>>>>
>>>>>>>>> On Sat, Apr 15, 2023 at 10:33:37AM -0500, Orie Steele wrote:
>>>>>>>>> > Thank you for this wonderful breakdown!
>>>>>>>>> >
>>>>>>>>> > On Fri, Apr 14, 2023 at 4:00 PM Laurence Lundblade <
>>>>>>>>> [e-mail]>
>>>>>>>>> > wrote:
>>>>>>>>> >
>>>>>>>>> > When we say "public key" in a CRFG document, I think it is
>>>>>>>>> reasonable to
>>>>>>>>> > assume no specific representation (JWK, COSE Key, PGP, etc...)
>>>>>>>>> >
>>>>>>>>> > As a side note, HPKE requires more than just having a recipient
>>>>>>>>> public key,
>>>>>>>>> > it also requires knowledge of the recipient supported
>>>>>>>>> algorithms... (this
>>>>>>>>> > is extremely obvious per the security considerations).
>>>>>>>>> > It is natural to assume this will be solved differently in COSE,
>>>>>>>>> PGP,
>>>>>>>>> > etc...
>>>>>>>>> > Maybe it is in the key representation, maybe it is via
>>>>>>>>> negotiation, as you
>>>>>>>>> > mentioned earlier...
>>>>>>>>> >
>>>>>>>>> > But it has to actually be solved for, or the sender is just
>>>>>>>>> guessing that
>>>>>>>>> > the recipient will be able to process their messages.
>>>>>>>>>
>>>>>>>>> Well, in store-and-forward system like COSE or JOSE, there are
>>>>>>>>> really
>>>>>>>>> only two ways:
>>>>>>>>>
>>>>>>>>> - negotiation.
>>>>>>>>> - assume based on application.
>>>>>>>>>
>>>>>>>>> And when it comes to COSE and JOSE, there are no usable negotation
>>>>>>>>> capabilties, so it is the latter: assuming based on application.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> > When we say "public key" in a COSE WG document,
>>>>>>>>> > folks will want to be sure if we are talking about the "abstract
>>>>>>>>> concept of
>>>>>>>>> > a public key"
>>>>>>>>> > or a concrete serialization conforming to normative requirements
>>>>>>>>> (JWK
>>>>>>>>> > Public Key or COSE Public Key).
>>>>>>>>> >
>>>>>>>>> > Holding a JWK or COSE "public key" with an algorithm, 🔥 has
>>>>>>>>> historically
>>>>>>>>> > meant 🔥 holding a recipient's encryption preferences.
>>>>>>>>>
>>>>>>>>> No, this is not correct. And this has been the case since the first
>>>>>>>>> RFCs for both.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> > There is no precedent for COSE Key or JWK containing
>>>>>>>>> "preferences for
>>>>>>>>> > parameterization" in addition to a "restriction of key use".
>>>>>>>>>
>>>>>>>>> However, there is precedent for parametrization. For both COSE and
>>>>>>>>> JOSE, since the first RFCs.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> > You can imagine COSE HPKE asking IANA to update the COSE
>>>>>>>>> registry to
>>>>>>>>> > communicate that "hkc" is bound to a specific value of "alg",
>>>>>>>>> similar to
>>>>>>>>> > how -27 is bound to "kty".
>>>>>>>>> > (! 🔥 kty and alg confusion intensifies... )
>>>>>>>>>
>>>>>>>>> There is no precedent for key parameter being bound to "alg". Being
>>>>>>>>> bound to "kty" yes (that is the difference between the two kinds of
>>>>>>>>> key parameters in COSE). And in JOSE, analogous split exists, even
>>>>>>>>> if
>>>>>>>>> it is not explicit in registeries.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> > ... I prefer to imagine requesting registration of a few good
>>>>>>>>> choices for
>>>>>>>>> > HPKE COSE (to start), and not importing every option under the
>>>>>>>>> sun by
>>>>>>>>> > default from the CFRG established registries here:
>>>>>>>>> >
>>>>>>>>> > How many other preferences would we need to register? Only the
>>>>>>>>> ones people
>>>>>>>>> > actually want to use, and *they* need to do *some* work to
>>>>>>>>> justify why this
>>>>>>>>> > is a good idea...
>>>>>>>>>
>>>>>>>>> With a few plausible extensions to HPKE, over 70.
>>>>>>>>>
>>>>>>>>> As for how many there currently would be, either 12 or *none at
>>>>>>>>> all*,
>>>>>>>>> depending on how exactly one defines things.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> > we don't just hand out a blank check, and leave COSE
>>>>>>>>> implementers on the
>>>>>>>>> > hook for an ever expanding bill of CFRG registered algorithms.
>>>>>>>>>
>>>>>>>>> Currently, it is not COSE-HPKE that is on the hook for HPKE
>>>>>>>>> algorithms,
>>>>>>>>> it is HPKE itself. Just modified my test code to make the following
>>>>>>>>> work (with COSE-HPKE code having absolutely no idea what is going
>>>>>>>>> on):
>>>>>>>>>
>>>>>>>>> $ target/debug/cose-hpke-keygen /tmp/mystery-key.key TYPE21
>>>>>>>>> $ echo "The crow flies at midnight" >/tmp/message
>>>>>>>>> $ target/debug/cose-hpke-encrypt --algorithm=TYPE2 /tmp/message
>>>>>>>>> /tmp/mystery-key.key.pub
>>>>>>>>> $ target/debug/cose-hpke-decrypt /tmp/message.chpke
>>>>>>>>> /tmp/mystery-key.key.priv
>>>>>>>>> $ cat /tmp/message.chpke.decrypted
>>>>>>>>> The crow flies at midnight
>>>>>>>>> $
>>>>>>>>>
>>>>>>>>> In contrast, registering explicit algs would make COSE
>>>>>>>>> implementers to
>>>>>>>>> be on hook for the bill.
>>>>>>>>>
>>>>>>>>> And for JWK, explicit algs is non-starter.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> > HPKE is not actually usable in COSE without some work from this
>>>>>>>>> working
>>>>>>>>> > group,
>>>>>>>>> > we should not defer our responsibility to the (first ever, IIRC)
>>>>>>>>> CFRG
>>>>>>>>> > established registry,
>>>>>>>>> > it is not going to feel good for developers, if we try to start
>>>>>>>>> a 5 guy
>>>>>>>>> > revolution while the world is trying to upgrade to post quantum
>>>>>>>>> encryption.
>>>>>>>>>
>>>>>>>>> HPKE and its implementation has to update anyway for post-quantum.
>>>>>>>>>
>>>>>>>>> But does COSE-HPKE and its implementation *also* have to update for
>>>>>>>>> post-quantum?
>>>>>>>>>
>>>>>>>>> With updated HPKE implementation, in the example above, replacing
>>>>>>>>> "TYPE21" with "TYPE30" would have enabled Post-Quantum.
>>>>>>>>>
>>>>>>>>> TODO: Make the code dynamically link against HPKE library.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> > > Up until COSE_HPKE, 1) and 2) are a single integer
>>>>>>>>> ciphersuite. Probably
>>>>>>>>> > > anyone doing 3) up to until COSE_HPKE would also use the
>>>>>>>>> single integer too.
>>>>>>>>> > >
>>>>>>>>> >
>>>>>>>>> > Agreed.
>>>>>>>>>
>>>>>>>>> I don't agree. Even ignoring keys, no single integer ciphersuite
>>>>>>>>> ever
>>>>>>>>> existed in COSE.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> > > draft-ietf-cose-hpke has addressed 1) with the new
>>>>>>>>> HPKE_sender_info header
>>>>>>>>> > > parameter. Now the algorithm used is a special ciphersuite
>>>>>>>>> identifier that
>>>>>>>>> > > indicates further details in an additional parameter.
>>>>>>>>> > >
>>>>>>>>> > Agreed, there are "proposals for revolution", which I am all
>>>>>>>>> for, if they
>>>>>>>>> > are coming from enough reviewers / implementers.
>>>>>>>>> > I am happy to withdraw my objection if overwhelmed by counter
>>>>>>>>> arguments, I
>>>>>>>>> > don't find the current arguments from Ilari compelling, but I
>>>>>>>>> appreciate
>>>>>>>>> > his consistent engagement.
>>>>>>>>>
>>>>>>>>> If performing asymmetric encryption with COSE or JOSE, there is
>>>>>>>>> already
>>>>>>>>> further details in additional parameter.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> > > - In COSE_HPKE we’re requiring algorithm identification be
>>>>>>>>> made up of a
>>>>>>>>> > > special ciphersuite and a triple. This will/should apply in
>>>>>>>>> all contexts
>>>>>>>>> > > where COSE algorithm IDs are used.  Maybe we should try to
>>>>>>>>> unify the
>>>>>>>>> > > definition of this in draft-ietf-cose-hpke
>>>>>>>>> > > and draft-ajitomi-cose-cose-key-jwk-hpke-kem?
>>>>>>>>> > >
>>>>>>>>> > I don't think we need another document.
>>>>>>>>> >
>>>>>>>>> > I think we should bend the knee to convention in COSE HPKE, even
>>>>>>>>> over the
>>>>>>>>> > objections of Ilari and Daisuke... (assuming they persist in
>>>>>>>>> advocating for
>>>>>>>>> > parameterization of alg).
>>>>>>>>> >
>>>>>>>>> > UNLESS, we have clear consensus on proceeding with a revolution,
>>>>>>>>> for that I
>>>>>>>>> > would want to see a lot more engagement :)
>>>>>>>>>
>>>>>>>>> Well, speaking for myself, I will continue advocating
>>>>>>>>> parametrization.
>>>>>>>>>
>>>>>>>>> Engagement seems to be very limited for COSE-HPKE.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> > > My opinions on 3) are:
>>>>>>>>> > > - The use cases are too widely varying for anyone to define an
>>>>>>>>> actual
>>>>>>>>> > > protocol
>>>>>>>>> > > - draft-ajitomi-cose-cose-key-jwk-hpke-kem can only work for a
>>>>>>>>> small
>>>>>>>>> > > fraction of negotiation use cases — those that use COSE_Key
>>>>>>>>> for negotiation
>>>>>>>>> > > - We might generalize the HPKE COSE algorithm identifier
>>>>>>>>> definition so the
>>>>>>>>> > > same thing can be used for 1), 2) and 3).  That is probably
>>>>>>>>> splitting HPKE_sender_info
>>>>>>>>> > > into two, one structure that is the algorithm ID and one is
>>>>>>>>> the enc info.
>>>>>>>>> > > We still wouldn’t define actual protocol for 3) but we would
>>>>>>>>> have a clear
>>>>>>>>> > > common method for COSE HPKE algorithm identification that
>>>>>>>>> anyone could use
>>>>>>>>> > > for their use-case specific negotiation protocol.
>>>>>>>>> > >
>>>>>>>>> > I agree with you on 3.
>>>>>>>>>
>>>>>>>>> I do not see how that would work.
>>>>>>>>>
>>>>>>>>> And I think that negotiation mechanism that would work for
>>>>>>>>> majority of
>>>>>>>>> use cases would be straightforward extension of the key draft. No
>>>>>>>>> splitting needed.
>>>>>>>>>
>>>>>>>>> The question is, given that we have not needed negotiation
>>>>>>>>> mechanism in
>>>>>>>>> the past, why do we need one now?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -Ilari
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> COSE mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/cose
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *ORIE STEELE*
>>>>>>> Chief Technical Officer
>>>>>>> www.transmute.industries
>>>>>>>
>>>>>>> <https://www.transmute.industries>
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> *ORIE STEELE*
>>>>> Chief Technical Officer
>>>>> www.transmute.industries
>>>>>
>>>>> <https://www.transmute.industries>
>>>>>
>>>>
>>>
>>> --
>>> *ORIE STEELE*
>>> Chief Technical Officer
>>> www.transmute.industries
>>>
>>> <https://www.transmute.industries>
>>>
>>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>