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

[Ilari Liusvaara <[e-mail]>]

On Sun, Apr 16, 2023 at 09:09:13AM -0500, Orie Steele wrote:
> Inline:
> 
> On Sun, Apr 16, 2023 at 7:06 AM AJITOMI Daisuke <[e-mail]> wrote:
> 
> 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.

However, in this case, there are no "alg" values for JOSE.

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

It should error even if key is not restricted, because the algorithm
requested (ECDSA SHA-256) is incompatible with the key (Ed25519?).

Then there is the case where ES256 is requested with ES256K key. The
requested cryptographic operation makes perfect sense (ES256 and ES256K
are the same cryptographic operation!), but spec says it is not allowed.


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

Again, it should error even without restriction because algorithm
requested is incompatible with the key.

But then there is the ES256 with ES256K key. Specification says it
should error, but the cryptographic operation makes perfect sense.


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

Back when I did some sketching on writing COSE/JOSE library, symmetric
keys having no indication what algorithm those are for was quite nasty
rat's nest. The asymmetric stuff was much more pleasant, even with stuff
like dual-purpose ECDH/ECDSA keys.


> 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

However, none of those faced a case where JWK was defined for something
not usable in JOSE.


> > 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 don't think the key representation has to make any sense outside
COSE-HPKE (but practically it will do so), so only libraries
implementing COSE-HPKE are relevant.

And having written COSE-HPKE implementation, the key representation
and negotiation stuff definitely should not be intermingled. The
parts of code that deal with the two are very different.

Right now that library operates with pure key representation (with
hacky encoding), it does not do negotiation at all.


> 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

Is anything there relevant? All those look to be JWE stuff.
COSE-HPKE works quite differently from any existing JWE stuff.

 
> You might also look at previous related drafts:
> 
> - https://datatracker.ietf.org/doc/html/draft-madden-jose-ecdh-1pu-04

That does not look like it hits the truly nasty cases.




-Ilari