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

[John Mattsson <[e-mail]>]

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.

- 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