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

[Ian McMillan]

Hi Corey,

Thank you for this great feedback, and I've incorporated your feedback in attach doc for #1 and #2 items in your comments. For #3, I've moved to aligning with 11.7, but I know in a future ballot we'll be looking to improve section and 11.7 (and thus 16.3.2(6)).

Tomas also provided feedback on the definition of the "Hardware Crypto Module" with feedback regarding the "dedicated" adjective to describe the crypto processor being non-inclusive of HSMs that leverage standard CPUs such as Intel SGX chips or MPCs. Tomas, is it sufficient to remove the "dedicated" adjective from that definition? I've updated the definition with that change as well.

Thanks,
Ian

From: Corey Bonnell <Corey.Bonnell at digicert.com>
Sent: Thursday, December 9, 2021 8:42 AM
To: Ian McMillan <ianmcm at microsoft.com>; cscwg-public at cabforum.org; Adriano Santoni <adriano.santoni at staff.aruba.it>; Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>; Bruce Morton <bruce.morton at entrust.com>
Subject: RE: [Cscwg-public] [EXTERNAL] Re: Discussion: Proposed Ballot CSC-6: Update to Subscriber Private Key Protection Requirements

Hi Ian,
Thank for you for circulating the latest copy of the draft ballot. Comments below.


  1.  As a general comment, it would be more consistent to use the Defined Terms of "Private Key" and "Key Pair" throughout.


  1.  "Acceptable methods of satisfying this requirement include the following" is unclear whether the list is exhaustive or is merely a list of illustrative examples. I believe the intent is that the list of methods is exhaustive, so I suggest changing this to "One of the following methods MUST be employed to satisfy this requirement:"


  1.  "6.          The CA or a Qualified Auditor witnesses the key creation in a suitable Hardware Crypto Module solution including a cloud-based key generation and protection solution;"



"Qualified Auditor" is a Defined Term that denotes an auditor with specific experience and ability to carry out WebTrust/ETSI audits. Do we need this level of specificity, especially when Section 11.7 prescribes "relying on a report provided by the Applicant that is signed by an auditor who is approved by the CA and who has IT and security training or is a CISA"? If we do not, perhaps it would be best to align on the language in Section 16.3.2 (6) with the auditor qualification requirement in Section 11.7.

Thanks,
Corey


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, December 7, 2021 5:24 PM
To: Adriano Santoni <adriano.santoni at staff.aruba.it<mailto:adriano.santoni at staff.aruba.it>>; cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>; Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr<mailto:dzacharo at harica.gr>>; Bruce Morton <bruce.morton at entrust.com<mailto:bruce.morton at entrust.com>>
Subject: Re: [Cscwg-public] [EXTERNAL] Re: Discussion: Proposed Ballot CSC-6: Update to Subscriber Private Key Protection Requirements

Hi Folks,

Coming out of our last call, I've made all the updates we discussed including producing a definition for the term "hardware crypto module" (see below).

Hardware Crypto Module: A tamper-resistant device with a dedicated cryptography processor used for the specific purpose of protecting the lifecycle of cryptographic keys (generating, managing, processing, and storing).

Please see the attached redline now with all the latest updates and provide feedback and willingness to endorse the ballot.

Thanks,
Ian

From: Cscwg-public <cscwg-public-bounces at cabforum.org<mailto:cscwg-public-bounces at cabforum.org>> On Behalf Of Adriano Santoni via Cscwg-public
Sent: Tuesday, November 23, 2021 8:34 AM
To: cscwg-public at cabforum.org<mailto:cscwg-public at cabforum.org>
Subject: Re: [Cscwg-public] [EXTERNAL] Re: Discussion: Proposed Ballot CSC-6: Update to Subscriber Private Key Protection Requirements


Hi all,

I find the language in "Baseline Requirements for the Issuance and Management of Code Signing.v2.6+CSC-6_redline_v2" rather confusing, about private key protection.

It seems to me that section 16.3.1, in the added parts, only allows three options for protecting the private key effective Sep 1, 2022:

1) hosted hardware crypto module (in short "HCM")
2) cloud-based key generation and protection solution (backed by an HCM)  (I am not clear what's the difference with #1)
3) signing service

But later on, section 16.3.2 seems to allow a wider range of options, including a suitable HCM shipped to the subscriber by the CA.

Am I reading wrong?

Also, I am not clear how option #3 in §16.3.2 works:

"3.    The Subscriber uses a CA prescribed CSP and a suitable hardware module combination for the key pair generation and storage;"

Anybody willing to explain?

Adriano
Il 23/11/2021 11:07, Dimitris Zacharopoulos (HARICA) via Cscwg-public ha scritto:

On 18/11/2021 7:03 μ.μ., Dimitris Zacharopoulos (HARICA) via Cscwg-public wrote:

Ok, so you are thinking of a Subscriber that owns an HSM and gets an IT audit that has an audit report that asserts that all Keys associated with Code Signing Certificates are generated in an on-prem certified HSM. Is this what this method is supposed to cover?

After our recent meeting, we agreed to tweak the language of 4. to cover this use case described by Bruce. I recommend changing

"4.    The Subscriber provides a suitable IT audit indicating that its operating environment achieves a level of security specified in section 16.3.1"

to

"4.    The Subscriber provides an internal or external IT audit indicating that it is only using a suitable hardware module as specified in section 16.3.1 to generate keys pairs to be associated with Code Signing Certificates"

I also noticed that we don't have consistency among all listed options. Some options just say " suitable hardware module", others point to 16.3.1 and others say both. We could discuss at our next call or someone could take a stab at it and try to use consistent language.


Thanks,
Dimitris.


_______________________________________________

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%7C8ce76500cce0434604b308d9ae85e4f6%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637732712463434560%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xxI42Sx5hRyvRih1OmIZ0jGoCRwPbLnCr4F0MByiLN4%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20211209/fe943dea/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: 157306 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/20211209/fe943dea/attachment-0001.docx>