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

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 18 Jul 2021 15:28:49 -0700

Hi John,

On Wed, Jun 23, 2021 at 08:35:24PM +0000, John Mattsson wrote:
> Hi,
> 
> There has been a lot of discussions in various groups recently on whether to have public key parameters also in the signature algorithm or not. There are significant differences between IETF protocols like PKIX, JOSE, COSE, TLS 1.2, TLS 1.3, and IKEv2. Many of the protocols are also internally inconsistent. The inconsistency has led to a lot of confusion for developers and people writing specifications.
> 
> Looking at IETF protocols with signature algorithm registers:
> 
> - PKIX/X.509 is consistent. There is no duplication of parameters between the public key algorithm and the signature algorithms.
> 
> - TLS 1.2 is consistent. None of the signature algorithms include public key parameters.
> 
> - COSE is inconsistent. COSE largely following PKIX. The exception is the signature algorithm ES256K that includes the public key parameter secp256k1.
> 
> - JOSE is inconsistent. JOSE is mostly doing the opposite as COSE and includes many public key parameters in the signature algorithms. Exceptions are EdDSA that do not include the curve, and the RSA algorithms that do not include the key size.
> 
> - IKEv2 is inconsistent. IKEv2 started its own registry where the ECDSA signature algorithms is bound to a curve, but the RSA signature algorithm does not include the key size. IKEv2 have since specified a way to use PKIX/X.509 registries where signature algorithms do not include any public key parameters.
> 
> - 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.)

-Ben

> - draft-ietf-httpbis-message-signatures is inconsistent. ECDSA includes curve, but RSA does not include key length and JOSE EdDSA does not include curve.
> 
> I have seen at least the following arguments to include public key parameters in the signature algorithm:
> 1. An implementation should know based on the signature algorithm that is support calculating the signature.
> 2. The security level should follow from the signature algorithm
> 3. Avoid using the same public key with two different algorithms
> 
> My observations and thoughts:
> - I think consistency is the most important property here.
> - The protocols except PKIX, COSE, and TLS 1.2 seems to try to achieve 1. but fail as they are not consistent.
> - None of the protocols above seem to strive for 2.
> - Adding public key parameters to the signature algorithm does not seem to achieve 3. A way to achieve 3. would e.g., be to add signature algorithm OIDs to the Extended Key Usage and only use algorithms specified there.
> 
> Cheers,
> John
> 

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 19 Jul 2021 09:01:45 +1000

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