1
$\begingroup$

I suppose that I have this scenario:

  • Root CA
  • Intermediate CA

Practice 1:

  • The Root CA generates her own $PK_r$ and $PB_r$ key, and after it makes her certificate $Cert_r$.
  • The Intermediate CA generates her own $PK_i$ and $PB_i$ key, and after it generates a Certificate Signed Request (CSR), and send it to the Root CA to obtain a Certificate $Cert_i$.

Practice 2:

  • The Root CA generates her own $PK_r$ and $PB_r$ key, and after it makes her certificate $Cert_r$.
  • The Intermediate CA makes a request of a certificate $Cert_i$ to the Root CA, and this last creates a key pair ($PK_r$ and $PB_r$ key) and send to Intermediate CA the certificate requested. In a second moment, the Root CA send (i.e. with an email) the key pair to Intermediate CA.

I'm using xca to test and understand what is the best practice.

$\endgroup$

1 Answer 1

3
$\begingroup$

Practice 1 is superior without a doubt.

First and foremost the obvious problem:
With practice 2 you need a channel to transport a piece of data confidential and authenticated which is strictly harder than just transport information (the CSR) authenticated for practice 1.

Now there are a couple of other reasons why in practice the first practice is used:

  • In actual CAs, the private keys are stored inside of HSMs. If you were to transport a key from the root CA HSM to the Intermediate CA HSM these two would have to be linked in some form / initialized the same way which is unneccessary procedure and unneccessary risk, after all if someone manages to convince the root-HSM to give you a wrapped key of the root key, now the attacker can use this key on the fortified root-HSM or he could use it on the less-fortified intermediate-HSM. Note though that actual CAs most likely do operate multiple HSMs that can unwrap the root keys, but they are all off-line, in-vaults and highly fortified as opposed to the intermediate HSMs which sometimes even operate fully automatically with an internet-facing API / service.
  • At other times the intermediate CA may not be operated by the same company as the root CA. In these situations I highly doubt that the client (the intermediate CA) would want to trust the root CA's security measures on key generation and wrapping and secure transport methods given that they might as well just generate a key on their own and use a CSR.
  • It introduces unneccesary protocols. Consider how end-users get their certificates: They generate a key themselves, send a CSR and get a certificate. No sane CA would ever propose to generate the keypair for the client and have them download it. The same applies to this CA-CA communication: The protocol to issue certificates works just fine, so why make it harder?
$\endgroup$
1
  • $\begingroup$ Simply and great answer ! $\endgroup$
    – CipherX
    Commented Mar 25, 2017 at 18:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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