[Cscwg-public] VOTING BEGINS: Ballot CSC-6: Update to Subscriber Private Key Protection Requirements
Bruce.Morton at entrust.com
Mon Feb 28 16:51:59 UTC 2022
Entrust also votes NO to ballot CSC-6.
From: Cscwg-public <cscwg-public-bounces at cabforum.org> On Behalf Of Doug Beattie via Cscwg-public
Sent: Monday, February 28, 2022 10:46 AM
To: Ian McMillan <ianmcm at microsoft.com>; cscwg-public at cabforum.org
Subject: [EXTERNAL] Re: [Cscwg-public] VOTING BEGINS: Ballot CSC-6: Update to Subscriber Private Key Protection Requirements
WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
GlobalSign Votes No on Ballot CSC-6.
As we looked at the ballot in more detail, we have a couple of questions which we should have asked during the review period which we think are important to address prior to voting yes.
What is meant by: Subscriber uses a hosted Hardware Crypto Module meeting the specified requirement;
The word hosted makes this sound like a hosted service. Does this include the use of a token? If so, then we should make a defined term for “Hosted Hardware Crypto Module” that explains what this is, or perhaps delete “hosted” from this requirement if that meant the intent.
Section 16.3.2, Subscriber Private Key Verification has this statement:
Effective November, 15, 2022, Subscriber Private Keys for Code Signing Certificates SHALL be protected per the following requirements. ….
Since this is specifying private key protection, shouldn’t this be in section 16.3.1, Subscriber Private Key Protection, or maybe just that statement needs to be removed or updated?
Section 16.3.1 Subscriber Private Key Protection says the following:
For Non-EV Code Signing Certificates, the CA MUST obtain a representation from the Subscriber that the Subscriber will use one of the following options to generate and protect their Code Signing Certificate Private Keys:
1. A Trusted Platform Module (TPM) that generates and secures a Key Pair and that can document the Subscriber’s Private Key protection through a TPM key attestation.
2. A suitable Hardware Crypto Module with a unit design form factor certified as conforming to at least FIPS 140-2 Level 2, Common Criteria EAL 4+, or equivalent.
3. Another type of hardware storage token with a unit design form factor of SD Card or USB token (not necessarily certified as conformant with FIPS 140-2 Level 2 or Common Criteria EAL 4+). The Subscriber MUST also warrant that it will keep the token physically separate from the device that hosts the code signing function until a signing session is begun.
Then a bit later it says:
Effective September, 1, 2022, Subscriber Private Keys for Code Signing Certificates SHALL be protected per the following requirements.
The CA MUST obtain a representation from the Subscriber that the Subscriber will use one of the following options to generate and protect their Code Signing Certificate Private Keys in a Hardware Crypto Module with a unit design form factor certified as conforming to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+:
Does this mean that the first 3 methods are prohibited? If so, then we should explicitly state that “these methods must not be used starting September 1, 2022.” In the heading para for those 3 methods.
Same as question 3 but in section 16.3.2: Are the first 3 methods prohibited as of 15 November 2022? If so, then we should explicitly state that they are prohibited as of that date.
Need clarification on section 16.3.2, item 3
* The Subscriber uses a CA prescribed crypto library and a suitable Hardware Crypto Module combination for the Key Pair generation and storage;
If a CA limits the list of available CSPs available to the Subscriber to those that are only suitable for approved tokens, does that satisfy this requirement?
From: Cscwg-public <cscwg-public-bounces at cabforum.org<mailto:cscwg-public-bounces at cabforum.org>> On Behalf Of Ian McMillan via Cscwg-public
Sent: Tuesday, February 22, 2022 10:30 AM
To: cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>
Subject: [Cscwg-public] VOTING BEGINS: Ballot CSC-6: Update to Subscriber Private Key Protection Requirements
Ballot CSC-6: Update to Subscriber Private Key Protection Requirements<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.cabforum.org%2Fcscwg%2Fcsc_6_-_update_to_subscriber_private_key_protection_requirements&data=04%7C01%7Cianmcm%40microsoft.com%7Cdba94eb81c164facf1b508d9f019a88d%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637804815989127861%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=chOc9LY58DjZreBftXXETeYfez6xuBrSzqZxifDxvcQ%3D&reserved=0>
Purpose of this ballot: Update the subscriber private key protection requirements in the Baseline Requirement for the Issuance and Management of Publicly-Trusted Code Signing Certificates v2.7. The following motion has been proposed by Ian McMillan of Microsoft, and endorsed by Tim Hollebeek of DigiCert and Bruce Morton of Entrust.
- MOTION BEGINS -
This ballot updates the “Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates“ version 2.7 according to the attached redline which includes:
1. Update section 16.3 “Subscriber Private Key Protection” to “Subscriber Private Key Protection and Verification”
2. Update section 16.3 “Subscriber Private Key Protection” to include sub-sections “16.3.1 Subscriber Private Key Protection” and “16.3.2 Subscriber Private Key Verification”
3. Update section 16.3 under new sub-section 16.3.1 to remove allowance of TPM key generation and software protected private key protection, and remove private key protection requirement differences between EV and non-EV Code Signing Certificates
4. Update section 16.3 under new sub-section 16.3.1 to include the allowance of key generation and protection using a cloud-based key protection solution providing key generation and protection in a hardware crypto module that conforms to at least FIPS 140-2 Level 2 or Common Criteria EAL 4+
5. Update section 16.3 under new sub-section 16.3.2 to include verification for Code Signing Certificates' private key generation and storage in a crypto module that meets or exceeds the requirements of FIPS 140-2 level 2 or Common Criteria EAL 4+ by the CAs. Include additional acceptable methods for verification including cloud-based key generation and protection solutions and a stipulation for CAs to satisfy this verification requirement with additional means specified in their CPS. Any additional means specified by a CA in their CPS, must be proposed to the CA/Browser Forum for inclusion into the acceptable methods for section 16.3.2 within 6 months of inclusion in their CPS.
- MOTION ENDS -
The procedure for approval of this ballot is as follows:
Discussion (7 days)
Start Time: 2022-02-14, 19:30 Eastern Time (US)
End Time: not before 2022-02-21, 19:30 Eastern Time (US)
Vote for approval (7 days)
Start Time: 2022-02-22,10:30 Eastern Time (US)
End Time: 2022-03-01,10:30 Eastern Time (US)
Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cscwg-public