MRSP 3.0: Issue #275: CA Key Protection

[Ben Wilson]

All,

This email is to open discussion here on the m-d-s-p list regarding the resolution of GitHub Issue #275 (Emphasize period-of-time key lifecycle management in MRSP § 3.1.3). 

Part of the issue, as I see it, is to strengthen key protection requirements for all keys that are intended to serve as CA keys, including pre-generated CA keys that a CA operator might create. Sometimes cryptographic key pairs are generated but not yet used to issue a CA certificate (because, for example, the standards sometimes require auditor presence at "key generation" but not at certificate creation). An auditor's key generation report is likely useless if CA keys are subsequently unprotected. So, at least one goal is to create clarity with requirements that address the lifecycle management of these "parked" CA keys.

Here are some proposed edits to the Mozilla Root Store Policy (MRSP)

Proposed edits to the MRSP (lines 273 and 746)

Mainly this adds to MRSP § 3.1.3, "CA private keys that have been generated but not yet associated with a CA certificate ("parked keys") MUST be identified and included in auditor-provided annual key lifecycle management reports (or a corresponding section of the CA operator's annual audit reports). These reports must account for the controls and measures applied to ensure the integrity, confidentiality, and protection of these keys throughout their lifecycle, consistent with the audit criteria cited above".

The CA/B Forum's TLS Baseline Requirements has a similar issue (see e.g. https://github.com/cabforum/servercert/issues/417).

Proposed edits to the TLS BRs (CABF Server-Cert GitHub Repository)

Please provide any comments or suggestions you might have to resolve, or otherwise improve this proposed resolution of, Issue #275.

Thanks,

Ben

[Roman Fischer]

Dear Ben,

 

We're wondering about the last sentence of proposed MRSP line 273:

 

[…] Successive period-of-time audits and auditor-provided annual key lifecycle management reports MUST be contiguous (no gaps).

 

What are the consequences if there are gaps? Can the gaps be closed retrospectively or must the key be discarded?

 

Thanks
Roman

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYZ4bfgg05Wb7MOfKz0q5rjnvnruQoKtS0O_kCOv9GMtQ%40mail.gmail.com.

[Ben Wilson]

Thanks, Roman, for your questions.

With respect to CA key protection, gaps in audit reports raise a big concern, but possibly they could be considered on a case-by-case basis. It would depend on the circumstances and the justification provided by the CA operator.  But yes, if the gap were unjustified or part of a lapse in compliance or security, we would consider the key compromised and the key material and any certificates would not be trusted.

Here are some ideas for how a CA operator's case-specific request might be handled:

We would require an independent auditor's post-gap report confirming that key lifecycle management processes remained intact, supported by sufficient documentation and evidence from the CA operator demonstrating CA key security measures as well as compliance with relevant policies or requirements.

We would also want the CA operator to explain publicly:

• why the gap occurred (all internal and external factors leading to its failure to obtain contiguous, annual key-protection reports);
• what key protection controls were in place during the gap, which prevented key compromise and misuse;
• how the CA operator maintained compliance with all other relevant policies and requirements; and
• what the CA operator has done or will do in the future to prevent occurrence of similar incidents.

Thanks again,

Ben

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZR0P278MB017061E36B172D95F2B2DCCEFA3E2%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM.