6.1.1.1 CA Key Pair Generation

[lachellel]

Comparing the Federal Common Policy Framework, Section 6.1.1.1 to the BRD Section 6.1.1.1

BRD:

6.1.1.1 CA Key Pair Generation

For Root CA Key Pairs created after the Effective Date that are either (i) used as Root CA Key Pairs or (ii) Key Pairs generated for a subordinate CA that is not the operator of the Root CA or an Affiliate of the Root CA, the CA SHALL:

1. prepare and follow a Key Generation Script,
2. have a Qualified Auditor witness the Root CA Key Pair generation process or record a video of the entire Root 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.

For other CA Key Pairs created after the Effective Date that are for the operator of the Root CA or an Affiliate of the Root CA, the CA SHOULD:

1. prepare and follow a Key Generation Script and
2. have a Qualified Auditor witness the Root CA Key Pair generation process or record a video of the entire Root CA Key Pair generation process.

In all cases, the CA SHALL:

1. generate the keys in a physically secured environment as described in the CA's Certification Practice Statement;
2. generate the CA keys using personnel in Trusted Roles under the principles of multiple person control and split knowledge;
3. generate the CA keys 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 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.

[lachellel]

Common Policy Framework:

6.1.1.1 CA Key Pair Generation Cryptographic keying material used by CAs to sign certificates, CRLs or status information shall be generated in FIPS 140 validated cryptographic modules. For CAs that issue certificates under id-fpki-common-High, the module(s) shall meet or exceed FIPS 140 Level 3. For CAs that do not issue certificates under id-fpki-common-High, the module(s) shall meet or exceed FIPS 140 Level 2. Multiparty control is required for CA key pair generation, as specified in section 6.2.2. CA key pair generation must create a verifiable audit trail that the security requirements for procedures were followed. The documentation of the procedure must be detailed enough to show that appropriate role separation was used. An independent third party shall validate the execution of the key generation procedures either by witnessing the key generation or by examining the signed and documented record of the key generation

[lachellel]

Questions and thoughts:

• Maintain the BRD lexicon which is more detailed in writing style than Common

• ? FIPS 140 Level 2 and / or FIPS 140 Level 3

  • Which should be specified for which scenarios

[lachellel]

Referencing the BRD - key storage is FIPS 140-2 Level 3 or an appropriate Common Criteria (etc) EAL 4+.

https://github.com/uspki/policies/blob/master/certificate-policy.md#627-private-key-storage-on-cryptographic-module

[lachellel]

Additional reference:

• NIST: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf
• Section 2.2.3
• Ensure that Cryptographic modules for CAs, Key Recovery Servers, and OCSP responders are hardware modules validated as meeting FIPS 140-2 Level 3 or higher

[LarryFrank]

As written in BRD, it is loose enough to drive a truck through. E.G., "1.prepare and follow a Key Generation Script." Based on WHAT requirements? Similar to requiring that they have a CPS that says how they do something without specifying any requirements - worthless from a security.

and (if applicable) its Key Generation Script

When is it "not applicable" since both roots and issuing CAs require a script?

My understanding is that DoD uses level 3 modules - but current policy only requires 2 (DoD doesn't issue "Fed PKI HIGH")

[lachellel]

Keep:

FIPS 140-2 Level 3 obviously

Review Common Criteria EAL 4+ clause; keep in draft

[lachellel]

Add

• Multiparty control is required for CA key pair generation,
• The documentation of the procedure must be detailed enough to show that appropriate role separation was used.
• An independent third party shall validate the execution of the key generation procedures either by witnessing the key generation or by examining the signed and documented record of the key generation

[LarryFrank]

FIPS 140-2 Level 3 obviously

Agree.

Review Common Criteria EAL 4+ clause; keep in draft

Can be dropped - US no longer uses "EAL" - now only accepts CC evaluation against approved protection profiles. For a crypto module - FIPS 140 is the only choice for US government - so EAL is not applicable even if it was still used.

[LarryFrank]

•Multiparty control is required for CA key pair generation,

Pet peeve - this should be stated in Section 6.2.2 (multi party control) not here. But understand we will likely repeat requirements because CA/.B does...

[lachellel]

Multiparty control is required for CA key pair generation,

covered in this statement:

• 2. generate the CA keys using personnel in Trusted Roles under the principles of multiple person control and split knowledge;

An independent third party shall validate the execution of the key generation procedures either by witnessing the key generation or by examining the signed and documented record of the key generation

covered in this statement:

• 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

witness or video in BRD; current Common CP states - "witness or examining audit record" to align, need to not include the "or examining audit record"

[lachellel]

In draft pull request (can be changed - up for discussion!), removing the "SHOULD" statements from BRD and applying the SHALL to all CAs

[techliaison]

I don't think we need to distinguish Root vs Subrodinte/Intermediate CA - for this CP they all need to adhere to the same key generation/protection, so I suggest the following wording for 6.1.1.1:

In all cases, 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 used to ensure the integrity and confidentiality of the Key Pair.

The CA keys shall be:

1. Generated in a physically secured environment as described in the CA's Certification Practice Statement;
2. Using personnel in Trusted Roles using multiple person control and split knowledge, as specified in section 6.2.2 ;
3. Generated within cryptographic modules that meet or exceed FIPS 140 Level 3 validation;
4. CA key generation activities shall be logged; and
5. Effective controls shall be maintained to provide reasonable assurance that the Private Key was generated and protected in conformance with the procedures described in this Certificate Policy and the CA’s Certification Practice Statement and its Key Generation Script.

The documentation of the procedure must be detailed enough to show that appropriate role separation was used and the CA key pair generation must create a verifiable audit trail that the security requirements for procedures were followed.

[lachellel]

missed this one @techliaison - adding new commits and pull request