Designing a PKI environment

Question

For our company I was given the task to design a durable, structured PKI environment for mainly client authentication purposes.

We need a Root CA with a couple of Intermediate CAs, like this:

• Enterprise Root CA
  • Purpose 1 CA
  • Purpose 2 CA
  • Customer CA
    • Customer 1 CA
    • Customer 2 CA

Can anyone explain some best practices for these questions in a modern (~2016) environment?

• Should I use RSA or EC certificates? Do all certificates need to be of the same type to sign intermediates?
• What are the preferred key lengths for these certificates?
• Is there a schema to use for serial numbers?
• What are the typical expiry dates for Root CAs and Intermediate CAs? I don't think they should expire at the same date, preventing a future headache?
• What if a, for example, Customer CA expires? Do I need to re-sign all underlying certificates?
• How does Customer 1 create a keypair that can be signed by our Customer 1 CA so it can be used for client authentication? What exactly is needed for a CSR?

Thanks.

Answer 1

You have a lot of questions combined into one here, and I won't attempt to answer all of them.

Regarding serial number schemes, I am aware of an installation that originally said "we have two signing machines, let's add a prefix of 100000 to the numbers generated by the second machine. Turns out that it didn't take as long as they planned to consume a hundred thousand serial numbers, and their scheme collapsed. Serial numbers can be quite long. I'd recommend using a hash of the public key as the serial number, or at least a significant fraction of it (it needs to be large enough to statistically assure yourself that you will avoid collisions, taking into account the birthday paradox.) They only need to be unique, not sequential.

Root CAs are often set for 10 or 20 years of life; they are trotted out only to sign Subordinate CA signing certificates, and are kept physically locked in a safe the rest of the time. SCAs are set to expire more frequently, as they're installed in on-line systems and are in constant use, exposing them to more risk. But each signing certificate needs to expire after the lifetime of the longest certificate they issue. If you try cutting them too close, you will run into problems when they all expire at the same time. In a related caution, you want to make sure your subordinate CA certs don't all expire at the same time.

I'm unsure why you show "customer certificates" signing other "customer certificates". A certificate that can be used for signing has a tremendous amount of authority, and you typically would not risk delegating that to a third party. If you have that kind of relationship, it would be more common to offer a signing service to your clients who need certificates.

It's also time to think about CRLs and/or OCSP responders. You also need to consider tracking your certificates. You can issue them all day long, but I assure you most of your clients will forget to request new ones until the day the old ones expire. If you keep a list of issued certificates in a database, along with the requester's email addresses, your security team will be able to send out warning notices a month before the certificates expire.

Finally, there are enterprise certificate management products in the marketplace that can manage all of these requirements for you. While this is not a forum for making specific product recommendations, I suggest at least searching the market to see what's available. They will likely provide answers to other questions you didn't know you should ask.