Re: [jose] [COSE] Consensus on cryptographic agility in modern COSE & JOSE

[AJITOMI Daisuke <[e-mail]>]

Hi Orie,

Thank you for raising the issue.

Taking Ilari's post into account, I would like to take some time to
reconsider my proposal and your raised issue.

Best,
AJITOMI Daisuke

2023年3月26日(日) 18:49 Ilari Liusvaara <[e-mail]>:

> On Sun, Mar 26, 2023 at 07:33:10AM +0900, Orie Steele wrote:
>
> > Should post quantum keys use "the old way" or "the new way" or
> > "both / it depends" ?
>
> It depends.
>
> This may sound very anticlimatic, but key types need to be designed
> around needs of algorithms, such as:
>
> a) How are the keys used in COSE / JOSE? Are there multiple uses unified
>    by some larger family, or only a single use?
> b) Is there only a single alg that makes sense with each individual key,
>    or are there multiple?
> c) Are there no parameters, a small set of possible parameter sets, or
>    more complex parametrization? Is there already registry for possible
>    parameters?
> d) What are the components of private/secret/public key and what are the
>    types of those components?
> e) What hints would be useful (extra info to improve interop, but not
>    absolutely required for things to work)?
>
>
> Designing key types without knowing how the keys are actually used in
> COSE / JOSE is fraught with danger. It is very easy to make a subtle
> mistake that ruins the design, but isn't discovered until it is too
> late.
>
>
> Let's analyze a number of different things around those axis:
>
> 1) RSA:
>
> a) There are multiple different uses, unified around RSA.
> b) Multiple.
> c) There are no parameters.
> d) There are 2 or 7 positive integer components in private key
>    (depending on if CRT speedup is used or not) and 2 positive integer
>    components in public key. All the components are potentially large
>    numbers.
> e) There are no hints.
>
> The RSA key type in COSE / JOSE is designed along these lines.
>
>
> 2) Short-Weierstrass ECC:
>
> a) There are multiple different uses, unified around ECC.
> b) Multiple.
> c) There is more compicated parametrization, but only a small set
>    of parameters in common use. No existing registry.
> d) There is one positive integer component in private key, and 2
>    nonnegative integer components in public key.
> e) There are no hints.
>
> The EC/EC2 key type in COSE / JOSE is designed along these lines.
>
>
> 3) HSS-LMS:
>
> a) There is single use, as signature.
> b) Single.
> c) There is small set of possible parameters. There is already a
>    registry.
> d) Private keys are not representable. Public keys are one byte string
>    component.
> e) There are no hints.
>
> The HSS-LMS key type in COSE is designed along these lines.
>
>
> 4) X25519/X448:
>
> a) There is single use, as DH function.
> b) Multiple.
> c) There are no parameters,
> d) Private and public keys are both one byte string component.
> e) There are no hints.
>
> The OKP kty in COSE / JOSE is designed for this type of thing
> (b through e)
>
>
> 5) EdDSA:
>
> a) There is single use, as signature.
> b) Single.
> c) There is small set of parameters. There is no existing registry.
> d) Private and public keys are both one byte string component.
> e) There are no hints.
>
> COSE / JOSE also throw these to OKP, but the design could have been
> very different.
>
>
> 6) Kyber:
>
> a) There is single use, as KEM.
> b) Multiple.
> c) There is small set of parameters. There is no existing registry.
> d) Private and public keys are both one byte string component.
> e) There are no hints.
>
> This is still a great match to what OKP was designed for. However, in
> COSE this is likely unnecressary, as PQ HPKE should appear soon. In
> JOSE, likely needed, because combining JOSE and HPKE turns out to be
> Hard (while the Kyber in JOSE seems straightforward extension of
> ECDH-ES).
>
>
> 7) Dilithium, Falcon and Sphincs+:
>
> a) There is single use, as signature.
> b) Single.
> c) There is small set of parameters. There is no existing registry.
> d) Private and public keys are both one byte string component.
> e) There are no hints.
>
> The answers to questions are identical to EdDSA! The very different
> design mentioned in EdDSA is actually what is employed by the COSE /
> JOSE PQ signature drafts (split to three ktys with horrible naming).
>
>
> 8) HPKE:
>
> a) There is single use, as asymmetric encryption.
> b) Single in COSE, the JOSE case seems Too Hard.
> c) More complex parametrization: A single integer, picked from existing
>    registry. In some cases, reprurposing other keys is possible.
> d) Private and public keys are both one byte string component.
> e) Supported KDF and AEAD. In case of converted keys, supported KEM.
>
> In case of converted keys, this adds common key parameters for the
> hints. In case of dedicated keys, this would argue for design like:
>
> kty: HPKE
> kem: uint
> priv: bstr (private keys only)
> pub: bstr
>
> Plus common key parameters for KDF / AEAD hints.
>
>
> As for the HPKE JOSE case being too hard, I have come to conclusion that
> I don't have any idea on how to integrate HPKE into JOSE in any sort of
> even remotely clean manner. Thus, I have given up working on it, at
> least until somebody comes up with a breakthrough.
>
>
>
> Commenting on the keys from various drafts:
>
> - PQ signatures work:
>
>   The kty naming is horrible, but otherwise looks good. There is a
>   decision on if to have one or three kty's.
>
>
> - Kyber:
>
>   OKP can't be used that way. However, if "lat" was replaced by "crv"
>   (looks odd, but works as intended), it would look good.
>
>
> - HPKE:
>
>   The JOSE case is fraught with danger because it is not clear how HPKE
>   would be used in JOSE, and if that would need to be reflected in the
>   key format.
>
>   The COSE case is clear. The current draft has issue where it
>   mishandles KEM in both dedicated and converted key cases:
>
>   * In dedicated key case, KEM is key subtype, and should not be grouped
>     together with hints (KDF/AEAD).
>   * In converted key case, KEM is also a hint, like KDF and AEAD. It can
>     have mulitple values.
>
>
>
>
>
> -Ilari
>
> _______________________________________________
> COSE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cose
>