[Cscwg-public] [EXTERNAL] Re: Discussion: Proposed Ballot CSC-6: Update to Subscriber Private Key Protection Requirements

[Ian McMillan]

Hi Dmitris,

This is not too painful. 😊

Effective date set is September 1, 2022 as stated in section 16.3, but 16.2 already has an effective date (June 1, 2021) for signing services to use at least FIPS 140-2 level 2, or Common Criteria EAL 4+ for ALL Code Signing Certificates per the table in section 1.3.  I’ll add the effective date into the table in section 1.3 for the changes in 16.3 on all code signing certs . Please review the text I used in the 1.3 table, and suggest some better language if possible.

When I read the,"conforming to at least FIPS 140-2 level 2, or Common Criteria EAL 4+", it does apply to CC EAL 4+ as well.

In 16.2, I’ve corrected the typo (thanks!), but for cloud-based solutions they will have their own terms for resources under a subscription. I think the wording we’ll need to summarize to is for each key generated and stored in the cloud-based subscription it must be conforming to the requirements. With Azure and AKV, if I have a subscription with a resource group and an AKV resource underneath, for every key I generate, I’ll need to specify the vault protection level (HSM) upon key creation. This means I could have a subscription with N number of keys with various protection levels. AKV recommends users do not group secrets into one vault, but it doesn’t stop users from making this risk decision on their own (more keys in one vault, the larger impact if compromised). GCP and AWS all have similar offerings and concepts, but the common level of terminology is subscription. I’ve updated the language to specifically target the subscription configuration at the level that manages the private key.

In 16.3.1, I’ve updated….


  1.  To be the suggested text you provided, “Subscriber uses a hosted hardware crypto module meeting the specified requirement;” I feel this effectively closes the loophole you pointed out.

On cloud-based vs signing service solutions (2 & 3), they are distinctly different solutions in the market for subscribers today, so I feel we need to expressly call them out differently.

For section 16.3.2, I am good with the suggested change to #2 with a small ordering tweak being, “The Subscriber counter-signs certificate requests that can be verified by using a manufacturer’s certificate indicating that the key was generated in a non-exportable way using a suitable hardware module;”

With #1, I’d prefer keeping the same way it is today.  I’m interested how folks view section 10.2.4 playing a part here as well (and with signing services).

On #8, My goal wasn’t to set a deadline for new methods to be introduced, but to require any innovations to be well documented by the CAs and brought to the Forum’s working group for inclusion. That said, I see the loophole this creates in that a CA could include a new method in their CP/CPS docs and bring it to the WG in the accordance with this requirement. But the WG could deem the method not acceptable and there is no requirement that states the CA must not use that now rejected method. The downside is we really do not want to maintain a rejected method list, so I am with you on the suggested change you provided with the date being September 1, 2022. I would like to keep the dates all aligned to reduce confusion.

The attached updated redline draft has all these changes.

Thanks,
Ian

From: Cscwg-public <cscwg-public-bounces at cabforum.org> On Behalf Of Dimitris Zacharopoulos (HARICA) via Cscwg-public
Sent: Thursday, November 11, 2021 1:42 PM
To: cscwg-public at cabforum.org
Subject: [EXTERNAL] Re: [Cscwg-public] Discussion: Proposed Ballot CSC-6: Update to Subscriber Private Key Protection Requirements

Hello Ian,

I noticed that you have not set an effective date for all these changes. It would be best if the ballot itself contained updates to the table in section 1.3. With that said, section 16.2 probably needs an effective date because it requires signing services to use at least FIPS 140-2 level 2, or Common Criteria EAL 4+ for ALL Code Signing Certificates (it used to apply only for EV CS Certificates).

When you say "conforming to at least FIPS 140-2 level 2, or Common Criteria EAL 4+", does the "at least" apply only for the first part (FIPS 140-2 level 2) or does it also extend to the second part (Common Criteria EAL 4+)? I'm not 100% sure how it is used in the English language and since it is possible to have non-native English speakers interpreting these requirements (CAs and auditors), I thought it's best to ask for clarifications.

While still on section 16.2, I believe the introduction of the term "cloud-based" (please correct the typo), "subscription and usage pattern" needs to be defined and/or clarified. Similarly for the "cloud solution" in 2a. We may need some assistance from providers offering cloud key management services to reach good language for this. We can certainly try ourselves and see what happens :-)

In 16.3.1, under the new numbered item 1.,

" 1.    Subscriber hosts a hardware crypto module meeting the specified requirement;  "

does not mean that the key will be protected in that hardware crypto module. As written, a subscriber could just present that they own a compliant device and would meet the requirement without the need for them to actually use it.

Following similar language as 2. and 3., I would recommend changing this to:

"1.    Subscriber uses a hosted hardware crypto module meeting the specified requirements;"

I have some concerns about 2. which are related to the definition/clarifications described above for "cloud-based" key management solutions. In my opinion these are not any different from "signing services", which are entities that manage keys on behalf of the Subscribers. Having two similar terms for similar things is a bit confusing.

Section 16.3 should be more about Private Key generation, use and protection. The "verification" part sounds a bit strange for me. 16.3.2 is more about the subscriber key generation part, and assurances that the key generation is done properly according to the specified requirements.

Finally, some small recommendations for 16.3.2.

"1.    The CA ships a suitable hardware crypto module, with a preinstalled key pair" could be changed to:

"1.    The CA ships a suitable hardware crypto module, with one or more pre-generated key pairs that the CA has generated using those crypto modules"

"2.    The Subscriber counter-signs certificate requests that can be verified by using a manufacturer’s certificate indicating that the key is managed in a suitable hardware module; " to

"2.    The Subscriber counter-signs certificate requests that can be verified by using a manufacturer’s certificate indicating that the key was generated in a suitable hardware module in a non-exportable way;"

I thought we agreed to remove option 4. (a suitable IT audit indicating a FIPS 140-2 level 2 or equivalent) because we didn't hear auditors or CAs using that option and it is very ambiguous and risky. I would love to see this go and I believe September 2022 is a reasonable timeframe to deprecate this practice.

For 6., the "cloud-based" again sounds confusing to me because they are effectively "signing services". They generate and protect the subscriber keys on their behalf.

"8.    Any other method the CA uses satisfy this requirement SHALL be specified in the CPS and must be proposed to the CA/Browser Forum for inclusion into these requirements within a 6-month period." to

"8.    Any other method the CA uses to satisfy this requirement. The CA SHALL specify and describe in detail those other methods in its Certificate Policy or Certification Practice Statement, and SHALL propose those methods to the CA/Browser Forum Code Signing Working Group for inclusion into these requirements until April 1, 2022, using the questions at cabforum.org<mailto:questions at cabforum.org> mailing list. After that date, the Code Signing Working Group will discuss the removal of this "any other method" and allow only CA/Browser Forum approved methods."

I hope that was not too painful for you to read :-)


Dimitris.
On 11/11/2021 3:36 μ.μ., Ian McMillan via Cscwg-public wrote:
Hi Folks,

After a brief side conversation with Bruce, I’ve made some further edits to the redline draft to include the CA prescribed CSP and suitable hardware crypto module scenario raised in the last call.

Please review the attached redline now and let me know if you have any feedback and if you are willing to endorse this ballot.

Thanks,
Ian

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, November 9, 2021 8:35 AM
To: Bruce Morton <Bruce.Morton at entrust.com><mailto:Bruce.Morton at entrust.com>; cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>
Subject: [EXTERNAL] Re: [Cscwg-public] Discussion: Proposed Ballot CSC-6: Update to Subscriber Private Key Protection Requirements

Thanks Bruce!

Really appreciate the help with the new redline draft. I’ve added the effective date of September 1, 2022 for this change to private key protection requirements. That seems reasonable and better than placing a date closer to major events in the calendar year (e.g. end of year holiday season).

The other thing that isn’t sitting well with me is the Signing Service requirements section 16.2, so I added the cloud-based key protection to the list of techniques that MAY be used for protecting the private keys of subscribers in a Signing Service. I know this section will have considerable overhauling in the very near future, so I only would like to add this minor update.

For everyone, please see that new attached redline now. Also please let me know if you are willing to endorse the ballot.

Thanks,
Ian

From: Bruce Morton <Bruce.Morton at entrust.com<mailto:Bruce.Morton at entrust.com>>
Sent: Thursday, November 4, 2021 3:00 PM
To: Bruce Morton <Bruce.Morton at entrust.com<mailto:Bruce.Morton at entrust.com>>; cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>; Ian McMillan <ianmcm at microsoft.com<mailto:ianmcm at microsoft.com>>
Subject: [EXTERNAL] RE: Discussion: Proposed Ballot CSC-6: Update to Subscriber Private Key Protection Requirements

Hi Ian,

Great meeting. Looks like we are making progress now. It will be nice to get this behind us.

Since the change will impact the CAs, we need the ballot to have an effectivity date. As such, we need to keep the current requirements as is with no change. We will also add in the new requirements and have them be effective on a future date. It is understood that the CAs may implement the requirement before that date.

Attached is a draft with the idea. I used the latest version of the CSBRs and captured most of the changes.

It would be great, if the CAs could provide some feedback on an effective date.

Thanks, Bruce.

From: Cscwg-public <cscwg-public-bounces at cabforum.org<mailto:cscwg-public-bounces at cabforum.org>> On Behalf Of Bruce Morton via Cscwg-public
Sent: Wednesday, November 3, 2021 1:21 PM
To: Ian McMillan <ianmcm at microsoft.com<mailto:ianmcm at microsoft.com>>; cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>
Subject: [EXTERNAL] Re: [Cscwg-public] Discussion: Proposed 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.
________________________________
Hi Ian,

Thanks for the proposal. Please find your document with some edits. I wanted to state that the subscriber could use a Signing Service to protect the private key. In addition I tried to reduce the number of “FIPS 140-2 Level 2 or Common Criteria EAL 4+” call outs as I am sure they will not remain consistent.

Looking forward to the discussion tomorrow.

Thanks again, Bruce.

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: Wednesday, November 3, 2021 10:58 AM
To: cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>
Subject: [EXTERNAL] [Cscwg-public] Discussion: Proposed 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.
________________________________
Hi Folks,

I’ve found the time to write up the subscriber private key protection update under a proposed Ballot CSC-6. Please review the attached redline doc and provide feedback. Also, please let me know if you are willing to endorse this ballot.

cscwg:csc_6_-_update_to_subscriber_private_key_protection_requirements [CAB Forum Wiki]<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwiki.cabforum.org%2Fcscwg%2Fcsc_6_-_update_to_subscriber_private_key_protection_requirements__%3B!!FJ-Y8qCqXTj2!JFXFBvuicNpp5JGeK1TvRJ-6eotM5fhSRjTUe2CUTty2HljPYkdltIcLdAbGX374fBk%24&data=04%7C01%7Cianmcm%40microsoft.com%7C3fcb6f7b002144eeacc308d9a542fec9%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637722529511561524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BkDEwbd%2Bs7MsAgwFPN2iXZMsuMGnmZibz%2FepayRh%2FyY%3D&reserved=0>
Ballot CSC-6: Update to Subscriber Private Key Protection Requirements
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.5. The following motion has been proposed by Ian McMillan of Microsoft, and endorsed by <Name + Org> and <Name + Org>.

— MOTION BEGINS — This ballot updates the “Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates“ version 2.5 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 stimpulation 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: TBD End Time: TBD
Vote for approval (7 days) Start Time: TBD End Time: TBD

Thanks,
Ian
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.



_______________________________________________

Cscwg-public mailing list

Cscwg-public at cabforum.org<mailto:Cscwg-public at cabforum.org>

https://lists.cabforum.org/mailman/listinfo/cscwg-public<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fcscwg-public&data=04%7C01%7Cianmcm%40microsoft.com%7C3fcb6f7b002144eeacc308d9a542fec9%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637722529511571474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=DNmJWVKCcMY0ybs4pFnIulBPzQPahXngcddzJ%2FQSy2k%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20211117/5c10b1e9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Baseline Requirements for the Issuance and Management of Code Signing.v2.6+CSC-6_redline_v2.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 152956 bytes
Desc: Baseline Requirements for the Issuance and Management of Code Signing.v2.6+CSC-6_redline_v2.docx
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20211117/5c10b1e9/attachment-0001.docx>