> On Sep 13, 2024, at 1:30 AM, John Mattsson
> <[email protected]> wrote:
>
> Hi,
>
> As an individual, I agree with Neil’s comments.
> https://mailarchive.ietf.org/arch/msg/jose/JSlZI6oeyYHXFkG2PgHbG4YzghA/
>
> I have also pointed out in a separate mail that the following sentence in not
> true:
>
> ”This is not a problem in practice, because RSA libraries accommodate keys of
> different sizes without having to use different code.”
>
> In addition to limitations on key length nlen, it is not uncommon that RSA
> implementations have limitations on the exponent e.
Could you provide more information here? I am only aware of a few
implementations (notably one included in Microsoft Windows) requiring it to be
a 32-bit value, not that they mandate 65537 or the like.
>
> I have a hard time seeing why RSA domain parameters (nlen, e) and ECC domain
> parameters (p, a, b, G, n, h) are treated completely differently.
JOSE and COSE already only allow named curves to be specified, so discussion of
custom curve definitions may be getting out of scope here.
Starting early with domain parameters being specified meant that RSA
implementations were expected to be able to operate over a range of parameters
for interoperability. There are also expectations that you can evaluate the RSA
parameters at runtime for appropriateness (such as e needing to be odd)
Starting early with pre-defined curves meant that a select set of curves were
often built into software, that was put into firmware, and sometimes even used
to design silicon. I do not know of a way to evaluate the properties/safety of
a custom curve at runtime.
<snip>
-DW
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
