[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