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

[Orie Steele <[e-mail]>]

Inline:

On Mon, Apr 17, 2023 at 10:06 AM AJITOMI Daisuke <[e-mail]> wrote:

> > 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.
>
>
Apple's use of "alg" is directly equivalent to your proposed key
representations, just simpler:

{
  "kty": "EC",
  "crv": "P-256",
  "alg": "APPLE-HPKE-v1",
  "x": "uxSHB-R9o3r74-58WDcxSva-eJxFaMUvJkgMFYSfjjU",
  "y": "54JP36nHh3B14RiJqBNH71ZbSmou5WUwTUGOWgfHqEs"
}

vs

{
       "kty": "EC",
       "crv": "P-256",
       "alg": "HPKE-v1-Base",
       "hkc": {
           "kem": 0x010,
           "kdfs": [0x001],
           "aeads": [0x001]
       },
       "x": "-eZXC6nV-xgthy8zZMCN8pcYSeE2XfWWqckA2fsxHPc",
       "y": "BGU5soLgsu_y7GN2I3EPUXS9EZ7Sw0qif-V70JtInFI"
   }


> On the other hand, COSE-HPKE should be a generic specification that does
> not assume any specific use case or application.
>

Should it assume that keys are represented in none-JOSE / none-COSE
formats? I think so... should it omit examples for JOSE and COSE? I think
not.


> Since HPKE is designed to be cryptoagility-oriented, it is natural to
> follow that design philosophy in COSE-HPKE as well.
>

No! : )

It is not natural to forward cryptographic algorithm
parameterization agility from a CRFG work item, to envelope formats and
application developers.

What works well for cryptographers, does not always work well for
"traditional application developers", or developers used to working with
JOSE and COSE.

RSA expressions are often cited when this comes up... because normal
developers don't understand why they need all these values:

https://www.rfc-editor.org/rfc/rfc7518.html#section-6.3

^ this is what HPKE is proposing to bring back... Parameters for
HPKE keys... instead of parameters for RSA Keys.


> If someone wants to adopt a ciphersuite-based approach, they can do so on
> higher-level applications that utilize COSE-HPKE.
>
>
This really is the primary point of contention.

Perhaps we should ask CFRG to do 2 new RFCs for ECDSA and ECDH so we can
add:

Why use alg: ES256, when you can use this instead:

{
       "kty": "ECDSA",
       "crv": "P-256",
       "alg": "ECDSA-v1-Base",
       "ekc": {
           "crv": 0x010, // new registry for curve identifiers
           "digest": [0x001], // new registry hash before sign
       },
       "x": "-eZXC6nV-xgthy8zZMCN8pcYSeE2XfWWqckA2fsxHPc",
       "y": "BGU5soLgsu_y7GN2I3EPUXS9EZ7Sw0qif-V70JtInFI"
 }

Why use alg: ECDH-ES+A128KW, when you can use this instead:

{
       "kty": "ECDH",
       "crv": "P-256",
       "alg": "ECDH-v1-Base",
        "hkc": {
           "crv": 0x010,
           "kdfs": [0x001], // matching to ECDH-ES+A128KW,...
https://www.rfc-editor.org/rfc/rfc7518#section-4.6.2
           "aeads": [0x001] // matching specific values fo "enc" /
"AES128GCM" for example. ...
https://www.rfc-editor.org/rfc/rfc7518#section-4.7
       },
       "x": "-eZXC6nV-xgthy8zZMCN8pcYSeE2XfWWqckA2fsxHPc",
       "y": "BGU5soLgsu_y7GN2I3EPUXS9EZ7Sw0qif-V70JtInFI"
 }

Then COSE and JOSE registries can defer all future algorithm code points to
the CFRG established registries, like we are currently proposing for HPKE.

If we leave COSE HPKE the way it currently is, I expect we will have to
keep explaining why kty: RSA, EC, OKP, and HPKE all look so different, and
why there was a brief window, where parameterization seemed to be unpopular.

It seems like answering this question with "because we learned from
mistakes made in RSA, fixed them with EC and OKP, and this is how it has
always been, and it's considered a best practice" is easier than:

 "because we wanted HPKE to be structured very differently from previous
COSE / JOSE standards (except for RSA)".

> 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.
>
>
As I said before, I am happy to be overruled on this point.

I understand the 2 approaches, I think following the current JOSE / COSE
conventions and registering an "alg" per suite proposal is better, and I
can cite industry adoption to support my point.

If it's just me objecting I assume the chairs will eventually tell me to
let it go, and I will be happy to do so.


> 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>
>>
>

-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>