[jose] Re: 2nd WGLC for draft-ietf-jose-fully-specified-algorithms (Fully Specified Algorithms)

[David Waite <[e-mail]>]

> On Sep 13, 2024, at 1:30 AM, John Mattsson <john.mattsson=[e-mail]> 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