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

[AJITOMI Daisuke <[e-mail]>]

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

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