Thanks this is helpful and very timely feedback. I will be pushing an updated draft with some adjustments in the coming days.
Mike Prorock mesur.io On Wed, Jul 6, 2022, 04:04 Anders Rundgren <[email protected]> wrote: > I agree. New crypto systems should follow the standard for "kty": > https://datatracker.ietf.org/doc/html/rfc7517#section-4.1 > > The "kty" (key type) parameter identifies the cryptographic algorithm > family used with the key, such as "RSA" or "EC" > > Putting different PQ crypto systems under the same moniker would be a > mistake regardless of the system's maturity. > Distinct names permit dynamic registration of cryptographic providers > which is used by platforms like Java. > > The exact naming I leave to the committee to figure out :) > > Cheers, > Anders > > > On 2022-07-06 9:19, Ilari Liusvaara wrote: > > On Tue, Jul 05, 2022 at 02:45:00PM -0500, Orie Steele wrote: > >> Hello, > >> > >> We've been working on JOSE/COSE representations for post quantum > >> cryptography here: > >> > >> > https://mesur-io.github.io/post-quantum-signatures/draft-prorock-cose-post-quantum-signatures.html > >> https://github.com/mesur-io/post-quantum-signatures > >> > >> Given the recent announcement: > >> > >> Announcement: The End of the 3rd Round - the First PQC Algorithms to > >> be Standardized > >> - > https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/G0DoD7lkGPk?pli=1 > >> > >> We'd like to share our progress, gather feedback and discuss next > >> steps. > > > > Some feedback: > > > > > > - I really do not like the PQK kty. It might be desirable to define a > > new keyshape that is explicitly single-algorithm by using alg for > > algorithm selection, with octet string private/public keys. However, > > I really do not think PQK is good name for that. > > > > Additionally, PQK makes no sense as some sort of grouping of > > algorithms, as post-quantum is very diverse bunch, especially with > > signatures (I think there are like 4-5 very different types). And > > post-quantum is not only signatures. > > > > - The "pset" parameter makes no sense to me. Dilithium 2, 3 and 5 are > > not compatible at all, even if implementations may internally share > > code. Same for Falcon and SPHINCS+ variants. This incompatiblity makes > > all these "variants" to actually be different algorithms. > > > > This is not like ECC, where ECDSA is compatible between different hash > > functions (and the same for ECDH). If one wants a precedent for this > > type of incompatiblity, there is EdDSA (Ed25519 and Ed448). > > > > - There are serious security concerns about Dilthium and Falcon at this > > point (there are no concerns about SPHINCS+). There is wide consensus > > that the way to counter these concerns is to hybridize with > > "classical" algorithm. > > > > And given that post-quantum stuff seems to really like SHAKE, one > > would want a classical signature that uses SHAKE. Unfortunately, > > SHAKE in ECDSA is cursed (nasty interop trap), and the only other > > signature algorithm that uses SHAKE is Ed448, which would not be great > > for pairing with the low variants. > > > > - Even if the algorithms to be standardized are published, there are no > > guarantees that the final standards will be compatible with the latest > > versions of the algorithm specifications. > > > > - I think at this point, given that CRQCs are not imminent, it makes > > more sense to focus on encryption first, as it is much more urgent > > problem. For signatures, it suffices to complete transition by the > > time CRQCs appear. For encryption, anything less than several decades > > before causes severe problems. And that time is substantially longer > > than the ~10 years last signature transition (SHA-1 to SHA-2) took. > > > > For encryption, it might be worth to take the risk of producing > > incompatible transitional algorithm. Any implementation of both the > > transitional and final algorithms is likely to be able to share very > > substantial chunks of the code. For signatures, that is much less > > clear. > > > > > > > > -Ilari > > > > _______________________________________________ > > COSE mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
