Root Cert Protection and Signing Process for e.g. Intermediates or Cross-Signs of new Roots

Issuance Tech
1

kinda curious, how exactly are the Root certs handled, is that something the public is allowed to know?

while I assume that it is not QUITE as extreme as the DNSSec Root keys I would assume there is a similar idea, fully offline multiple people who have to be together to unlock different levels of access which are all needed to in the end get to however the root cert is protected right?

for reference, the DNSSec Process:
https://www.cloudflare.com/learning/dns/dnssec/root-signing-ceremony/

2

Something like that as far as I know indeed. So called "root signing ceremonies". Look it up, there's probably info about it out there related to the web PKI too.

1 Like
3

The legal requirements that all public certificate authorities have agreed on - Let's Encrypt included - are documented in the Baseline Requirements from the CA/Browser Forum. Some excerpts:

6.1.1.1 CA Key Pair Generation
the CA SHALL:

  1. prepare and follow a Key Generation Script,
  2. have a Qualified Auditor witness the CA Key Pair generation process or record a video of the
    entire CA Key Pair generation process, and
  3. have a Qualified Auditor issue a report opining that the CA followed its key ceremony during
    its Key and Certificate generation process and the controls used to ensure the integrity and
    confidentiality of the Key Pair.

In all cases, the CA SHALL:

  1. generate the CA Key Pair in a physically secured environment as described in the CA’s
    Certificate Policy and/or Certification Practice Statement;
  2. generate the CA Key Pair using personnel in Trusted Roles under the principles of multiple
    person control and split knowledge;
  3. generate the CA Key Pair within cryptographic modules meeting the applicable technical and
    business requirements as disclosed in the CA’s Certificate Policy and/or Certification Practice
    Statement;
  4. log its CA Key Pair generation activities; and
  5. maintain effective controls to provide reasonable assurance that the Private Key was
    generated and protected in conformance with the procedures described in its Certificate
    Policy and/or Certification Practice Statement and (if applicable) its Key Generation Script.

4.3.1.1 Manual authorization of certificate issuance for Root CAs
Certificate issuance by the Root CA SHALL require an individual authorized by the CA (i.e. the CA
system operator, system officer, or PKI administrator) to deliberately issue a direct command in
order for the Root CA to perform a certificate signing operation.

Effectively, this boils down to a) having auditors present when you do critical things, b) storing your key securely, c) having access controls (multi-person, security etc) in place. This involves putting them on a Hardware Security Module, and additionally you may want to keep them offline when they're not needed. Precise details are not usually public.

As stated in the BRs, a CA must describe their practices in their Certification Practice Statement. As such, you will find some further information there. Quoting from Let's Encrypts CPS:

5.2.2 Number of persons required per task
A number of tasks, such as key generation and entering areas physically containing operating ISRG PKI systems, require at least two people in Trusted Roles to be present.

6.7 Network security controls

ISRG implements reasonable network security safeguards and controls to prevent unauthorized access to CA systems and infrastructure. ISRG complies with the CA/Browser Forum's Network and Certificate System Security Requirements. Identified vulnerabilities are responded to within 96 hours of review, and remediated within a timeframe based on their risk profile: critical vulnerabilities within 96 hours, high-risk within one month, medium-risk within three months, and low-risk within six months.

ISRG's network is multi-tiered and utilizes the principle of defense in depth. Firewalls and other critical CA systems are configured based on a necessary-traffic-only allowlisting policy whenever possible.

ISRG Root CA Private Keys are stored offline in a secure manner.

3 Likes
4

I've seen a post about those in here, not that much details though, not sure if the procedures are different between making and signing new roots vs just handling intermediates and CRLs.

I have been very intrigued how insanely specific the DNSSec root process was even up to the level that the proces is fully public including video footage.