2

Microsoft has recommended my organization to use different subordinate issuer CAs in order to issue certificates that will be used for different things. For example, they recommend to use a CA for issuing certificates that will be used to connect to the wifi and another CA por issuing certificates that will be used for applications to authenticate to webservices.

They say the reason is to reduce the risk of a CA malfunctioning to affect all the services.

What are the risks of using the same subordinate issuer CA to generate certificates that will be used for different things (ex: wifi authentication vs webservices authentication)?

Are there only availability reasons or also confidentiality reasons?

Eloy Roldán Paredes
  • 1,507
  • 12
  • 25
  • 1
    The biggest reason I could think of, is what if you use one CA for everything then that CA gets compromised? That would be a much bigger problem than if CAs with separate jobs were completely independent. – Jonathan Gray Dec 28 '15 at 15:48

2 Answers2

3

Using different intermediate CAs will allow you to differentiate end-entity certificates by their issuer. This makes it possible to create trust rules that will limit certificate usage based on their issuer.

Issuing all your certificates from the same iCA will make it easy to mistakenly allow one certificate to be used for something unintended.

That will, for instance, allow you to generate wifi authentication certificate from iCA1 and TLS client connection certificate (web services) from iCA2 and then to configure your wifi access point to trust any certificate issued by iCA1. This will prevent certificate you issue for your web services to be re-used for accessing your wifi network (and the reverse) without having to mess up with custom OIDs in certificates (which might not even be supported by the software making use of these certificates).

You could do the exact same thing with separate CAs except that this require more management effort.

Stephane
  • 18,557
  • 3
  • 61
  • 70
  • wifi certs are almost always customer generated client certs from an internal root and wouldn't come from an external CA so the question would still stand for externally facing CAs. My answer comes from internal communications from MSFT trying to cover themselves due to their overuse of certificates in their last two releases of product lines –  Dec 28 '15 at 21:42
2

There is a general principle that keys should be used for only one purpose. According to NIST's Key Usage guidelines (see section 5.2 on page 42),

In general, a single key should be used for only one purpose (e.g., encryption, authentication, key wrapping, random number generation, or digital signatures). There are several reasons for this:

  1. The use of the same key for two different cryptographic processes may weaken the security provided by one or both of the processes.
  2. Limiting the use of a key limits the damage that could be done if the key is compromised.
  3. Some uses of keys interfere with each other. For example, consider a key pair used for both key transport and digital signatures. In this case, the private key is used as both a private key-transport key to decrypt data-encryption keys and a private signature key to apply digital signatures. It may be necessary to retain the private key-transport key beyond the cryptoperiod of the corresponding public key-transport key in order to decrypt the data-encryption keys needed to access encrypted data. On the other hand, the private signature key shall be destroyed at the expiration of its cryptoperiod to prevent its compromise (see Section 5.3.6). In this example, the longevity requirements for the private key-transport key and the private digital-signature key contradict each other.

The same reasons that ordinary keys should have a single purpose also apply to a CA signing key or Subordinate CA (SCA) signing key.

I can't think of a specific vulnerability in certificates that reason #1 might create, but we've seen enough cryptographic vulnerabilities that have occurred whenever principles are violated, so I wouldn't completely discount it.

Regarding #2, you obviously want to limit the damage that could be done if a signing server is compromised. When you start running your own PKI, you realize how fragile the systems can be and how easy it can be to make subtle mistakes.

Reason #3 gets into system flexibility. For example, someone in property management may buy a pre-packaged security solution for building access control, and it may have its own requirements for SCA issuing certificates that don't match your current SCA certificate hierarchy. Rather than disrupting your other certificate issuing processes, you can isolate the change to just the impacted domain.

Of course, you can't just stack up subordinate CA certificates like building blocks. Every SCA link in the chain-of-trust means another certificate to be validated, and there are practical limits to how many certificates can be validated before the process becomes too burdensome on the clients. For that reason you'll see that Trusted Root CAs don't delegate to SCA certificates on their working servers, even if it would better segregate their infrastructure. But the trusted root CAs have a lot of experience in the field, and have designed their systems focused on the security of their architecture; we all trust them to do their jobs well. (The cynical reality is that whenever any root CA has made a mistake and been compromised in the past, the loss of trust means the company tends to go out of business quickly.)

John Deters
  • 33,650
  • 3
  • 57
  • 110