1

From what I see, many server and client RSA certificates in the real deployments have the "key usage" mask containing both digitalSignature and keyEncipherment.

Isn't this a bad (that is, potentially insecure) practice, given that there's a general guideline to use separate keys for different purposes?

As an example of protocol that appears to freely switch between this two, take TLS 1.2. If the key exchange method, that was negotiated between the client and the server, is ECDHE_RSA, then the digital signature capability of the certificate will be exploited during the handshake; if, on the contrary, the method is plain-RSA, then the key encipherment capability will be used. And these two specific instances are probably still widely used - assuming this after checking which methods have been deprecated by the most popular browser Chrome and which have not.

Max
  • 87
  • 5

1 Answers1

3

The guidance is more about keeping the certificates used for different operations seperate. Not keeping the certificates used for different ways of achieving the same operation seperate.

In the case of different TLS key exchange, the overall operation is still the same, i.e. Generating and exchanging a session key. While technically one method generates a key then sends it, with the other involves signatures they have the same overall lifecycle and consequence if the key linked to the certificate is disclosed.

The general guidance applies more to situations where the operation is different. E.g. With email signing there are two operations, encrypting the email (to prevent it being intercepted) and signing it (to prevent it being forged). As per this answer there are situations where you'd want to disclose the encryption key but not the signing key.

This doesn't apply to the different key exchange algorithms in TLS so the certificate usage is more of a technicality.

Of course if you then used the same certificate to sign something then that would be a terrible security practice.

EdC
  • 206
  • 1
  • 2