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

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