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 <[email protected]>: > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
