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

[AJITOMI Daisuke <[e-mail]>]

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.

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