[Cscwg-public] VOTING BEGINS: Ballot CSC-6: Update to Subscriber Private Key Protection Requirements

Mon Feb 28 15:45:40 UTC 2022

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.

Question 1:

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.

Question 2:

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?

Question 3:

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.

Question 4:

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.

Question 5:

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> On Behalf Of Ian
McMillan via Cscwg-public
Sent: Tuesday, February 22, 2022 10:30 AM
To: 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.cabf
orum.org%2Fcscwg%2Fcsc_6_-_update_to_subscriber_private_key_protection_requi
rements&data=04%7C01%7Cianmcm%40microsoft.com%7Cdba94eb81c164facf1b508d9f019
a88d%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637804815989127861%7CUnkno
wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
6Mn0%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)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20220228/d52726ab/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 8404 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20220228/d52726ab/attachment-0001.p7s>