On Wed, Aug 30, 2023 at 01:27:49AM +0000, Michael Jones wrote: > Orie Steele<https://twitter.com/OR13b> and I have written a new > specification creating algorithm identifiers for JOSE and COSE that > fully specify the cryptographic operations to be performed - > something we'd promised to do during our presentation to the JOSE > working > group<https://datatracker.ietf.org/meeting/117/materials/slides-117-jose-fully-specified-algorithms-for-jose-and-cose-00> > at IETF 117. The introduction to the specification (quoted below) > describes why this matters. > > The specification is available at: > * > https://www.ietf.org/archive/id/draft-jones-jose-fully-specified-algorithms-00.html Two small things that came up in quick read:
- Why ES25519/ES448 instead of Ed25519/Ed448? Or is having an alg and crv with the same name an issue for some implementations? I would associate ES25519/ES448 with certain other stuff... - Ed25519 and Ed448 are fully specified algorithms, so the description field could just be "Ed25519"/"Ed448". Then: "Discuss the treatment of EDCH-ES and its ephemeral keys." There is actually an related issue in JOSE and COSE. ECDH-ES (and ECDH-SS) when appiled to EC/EC2 keys is non-cofactor, which makes it unsuitable for curves with h > 1. X25519 and X448 have built-in workaround. Currently, there are no curves that trigger the problem. However, there are proposals to register curves that do. There are essentially two ways to address this: - Define copies of existing ECDH-ES/ECDH-SS codepoints that are limited to EC/EC2 and multiply by h at output. - Change the existing codepoints to multiply by h at output for EC/EC2. The issue with latter is if somebody is using ECDH-ES/ECDH-SS with some private EC crv that happens to have h > 1. That would create an incompatibility. -Ilari _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
