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

[AJITOMI Daisuke <[e-mail]>]

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

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