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

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Mon Feb 28 17:03:59 UTC 2022


Hi Ian,

There is no way to withdraw a ballot once the voting period starts. All 
members that voted "yes" may change their vote to "no" so that the 
ballot fails. A new subsequent ballot can be submitted with new number.


Thanks,
Dimitris.

On 28/2/2022 6:58 μ.μ., Ian McMillan via Cscwg-public wrote:
>
> Hi Doug,
>
> Thanks for sharing these questions and calling out some minor changes 
> we need to take to make this right.
>
> I am asking now that we WITHDRAW the CSC-6 ballot to address these 
> questions and revisions under a new ballot.
>
> For questions 1-4, I’ve addressed them by removing the term “hosted”, 
> removed the, “Subscriber Private Keys for Code Signing Certificates 
> SHALL be _protected_ per the following requirements” statement in 
> 16.3.2 to attach the effective date to the verification methods, and 
> sync’d the effective date in 16.3.1 to November 15, 2022. The 
> effective date of November 15, 2022 has also been reflected in the 
> 16.3.1 and 16.3.2 sections as it explicitly states the current methods 
> will be prohibited (which leads to the new requirements on November 
> 15, 2022).
>
> For question 5, yes that does satisfy the requirement,  the item 3 
> under 16.3.2 regarding CA prescribed crypto libraries and hardware 
> crypto modules is to address exactly your stated scenario.
>
> Please look for these changes in attached redline doc for what will 
> now be CSC-13. I’ll will start a new thread regarding CSC-13 and look 
> to restart the ballot process.
>
> Thanks,
>
> Ian
>
> *From:*Doug Beattie <doug.beattie at globalsign.com>
> *Sent:* Monday, February 28, 2022 10:46 AM
> *To:* Ian McMillan <ianmcm at microsoft.com>; cscwg-public at cabforum.org
> *Subject:* [EXTERNAL] RE: VOTING BEGINS: Ballot CSC-6: Update to 
> Subscriber Private Key Protection Requirements
>
> 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.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)
>
>
> _______________________________________________
> Cscwg-public mailing list
> Cscwg-public at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/cscwg-public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20220228/f95736f9/attachment-0001.html>


More information about the Cscwg-public mailing list