Hey Ilari! Thanks for the speedy review : )
Inline: On Wed, Aug 30, 2023 at 2:10 AM Ilari Liusvaara <[email protected]> wrote: > 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? > > IIRC there are examples of using the same label for multiple registry entries, especially in COSE: kty: WalnutDSA, alg: WalnutDSA kty: HSS-LMS, alg: HSS-LMS - https://www.iana.org/assignments/cose/cose.xhtml Personally, I don't think this is a good thing to do. AFAIK, there are no JOSE cases where this happens. 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". > > I agree that they are fully specified. I still think it's better to not name the curve and the algorithm with the same value, but perhaps the pattern from COSE registries is "good" / worth continuing ? > > > 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. > This sounds like your recommendation, can you elaborate a bit more on what this might look like? > - 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 > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
