1
$\begingroup$

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.

| improve this question | |
$\endgroup$
  • 1
    $\begingroup$ For a while in 2015 Chrome did warn for plain-RSA keyexchange and also non-AEAD 'bulk' ciphers, calling them 'obsolete cryptography'; security.SX has several Qs about it. $\endgroup$ – dave_thompson_085 Sep 2 '17 at 1:32
3
$\begingroup$

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.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Thanks, it's an interesting angle of view. But, technically, RSA encryption and RSA signing are two different operations - so why is it safe to use both for TLS 1.2 and why it's unsafe to re-use them in some other protocol? Is it because there exists some formal proof for the TLS usage of the key? As I'm not familiar with a generic proof for PKCS#1 v1.5-style encryption and signing (unlike, for instance, PSS, which seems to be proven by Haber and Pinkas). $\endgroup$ – Max Sep 4 '17 at 15:40
  • $\begingroup$ @Max there is no technical weakening of the encryption by also using the same key for signing (or the other way around). The reason for the advice to use different keys for signing and encryption is more about reducing the risk / mitigating the impact of the key being disclosed. There's more detail on that in the answer I linked. So the reasons the technicality doesn't matter here is that disclosure of the key has the same real world impact. $\endgroup$ – EdC Sep 5 '17 at 1:52
  • $\begingroup$ Could you clarify which constraints is your statement about "no technical weakening" based upon? My understanding was that it's not true in general, and depends a lot on the specific schemes being used. For instance, in [1] they give an example of how two, individually secure, encryption and signing schemes become completely broken when used simultaneously. [1] Paterson, Schuldt, Stam, Thomson "On the Joint Security of Encryption and Signature, Revisited" $\endgroup$ – Max Sep 5 '17 at 11:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.