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

[John Mattsson <[e-mail]>]

David Waite wrote:

>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.

Yes, here are some recent detailed examples I have come across:
- An RSA implementation from a big company that only supports e = 3. Large deployment.
- Several deployed RSA implementations from large companies that only support nlen <= 2048. In the past I have also come across nlen <= 1024, but hopefully these are not in use anymore.

But none of these were in COSE/JOSE.

Another related thing that is very common is that the same RSA key is used for several different algorithms. For new application this is not compliant with PKCS #1 (RFC 8017) unless your system is old. For security purposes fully-specified keys are likely much more important than fully specified algorithms.

Cheers,
John

From: David Waite <david=[e-mail]>
Date: Wednesday, 18 September 2024 at 01:17
To: John Mattsson <[e-mail]>
Cc: JOSE WG <[e-mail]>, [e-mail] <[e-mail]>, Neil Madden <[e-mail]>
Subject: Re: [jose] 2nd WGLC for draft-ietf-jose-fully-specified-algorithms (Fully Specified Algorithms)



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