Re: [saag] Public key parameters in the signature algorithm —that is the question

[Martin Thomson <[e-mail]>]

On Mon, Jul 19, 2021, at 08:28, Benjamin Kaduk wrote:
> > - TLS 1.3 is inconsistent. ECDSA, EdDSA, sm2sig_sm3, and gost include the curve, but eccsi_sha256, iso_ibs1, iso_ibs2, and iso_chinese_ibs. RSA does not include the key length.
> 
> We didn't ask the experts to enforce anything about parameters in
> SignatureSchemes.  Do you think we should?  (The ongoing 8446bis would be
> an okay place to add such guidance, I think.)

So I do think that this is good guidance to give, but we'll need an exception for RSA.

That is, a signature scheme should define a singular use of an algorithm that includes all parameters of that algorithm.  This works for most of what has been defined in RFC 8446, except RSA.  It could work for RSA, but RSA is sufficiently weird that attempting to define RSA 2048 and RSA 3072 and whatever other numbers as discrete schemes would not be backward compatible.  Also deciding on which numbers to privilege seems like it would be difficult.  Incidentally, RSA 2049 should not be a problem, but I can confirm that it is a real problem in some software (I'd have to go back and check which to be sure, I think it was OpenSSL, but it might have been NSS).

As far as the non-recommended options go, informing registrants of this decision might lead them to either reject the advice or ask for a new codepoint, but I don't think it matters.