[Cscwg-public] Update to key protection (in 16.2 & 16.3)

[Ian McMillan]

Hi Folks!

I've drafted up the redline for the changes for an upcoming ballot on the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates<https://cabforum.org/wp-content/uploads/baseline_requirements_for_the_issuance_and_management_of_code_signing.v.2.0.pdf> on section 16.2 and 16.3 as it pertains to subscriber private key protection requirements (leaf-signing cert private keys). The goal is to collapse the requirements on non-EV and EV, and to include support for cloud-based key protection solution offered by GCP, AWS, and Azure. Please review and provide comments on the verbiage below and the redline changes in the document attached, and if you would be willing to endorse this change in the upcoming ballot, please let me know.

16.2 Signing Service Requirements
The Signing Service MUST ensure that a Subscriber's private key is generated, stored, and used in a secure environment that has controls to prevent theft or misuse.  A Signing Service MUST enforce multi-factor authentication to authorize Code Signing and obtain a representation from the Subscriber that they will securely store the tokens required for multi-factor access.  A system used to host a Signing Service MUST NOT be used for web browsing.  The Signing Service MUST run a regularly updated antivirus solution to scan the service for possible virus infection.  The Signing Service MUST comply with the Network Security Guidelines as a "Delegated Third Party".
For Code Signing Certificates, Signing Services shall protect private keys in a FIPS 140-2 level 2 (or equivalent) crypto module.  Techniques that may be used to satisfy this requirement include:

1.      Use of an HSM, verified by means of a manufacturer's certificate;
2.      A hardware crypto module provided by the CA;
3.      Contractual terms in the subscriber agreement requiring the Subscriber to protect the private key to a standard equivalent to FIPS 140-2 level 2 and with compliance being confirmed by means of an audit.
4.      Cryptographic algorithms, key sizes and certificate life-times for both authorities and Subscribers are governed by the NIST key management guidelines.
5.      A Cloud-based key protection solution with the following requirements enabled on the subscription, and a usage pattern as follows:
1.      A hardware crypto module with a unit design form factor certified as conforming to at least FIPS 140-2 Level 2, eIDAS Protection Profile: EN 419 221-5, or equivalent;
2.      Key creation, storage, and usage of private key must remain within the security boundaries of the cloud solutions hardware crypto module;
3.      Subscription must be configured to log access, operations, and configuration changes on the key. The configuration change log is available for audits.

16.3 Subscriber Private Key Protection
For 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 hardware crypto module with a unit design form factor certified as conforming to at least FIPS 140-2 Level 2, eIDAS Protection Profile: EN 419 221-5, or equivalent;

2.      A Cloud-based key protection solution with the following requirements enabled on the subscription, and a usage pattern as follows:
1.      A hardware crypto module with a unit design form factor certified as conforming to at least FIPS 140-2 Level 2, eIDAS Protection Profile: EN 419 221-5, or equivalent;
2.      Key creation, storage, and usage of private key must remain within the security boundaries of the cloud solutions hardware crypto module;
3.      Subscription must be configured to log all access, operations, and configuration changes on the key. The configuration change log is available for audits.

3.      A type of hardware storage token with a unit design form factor of SD Card or USB token certified as conformant with FIPS 140 Level 2 or eIDAS Protection Profile: EN 419 221-5). 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.

For Code Signing Certificates, CAs SHALL ensure that the Subscriber's private key is generated, stored and used in a crypto module that meets or exceeds the requirements of FIPS 140-2 level 2, eIDAS Protection Profile: EN 419 221-5, or equivalent. Acceptable methods of satisfying this requirement include (but are not limited to) the following:

1.      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;

2.      The Subscriber provides a suitable IT audit indicating that its operating environment achieves a level of security at least equivalent to that of FIPS 140-2 level 2, eIDAS Protection Profile: EN 419 221-5, or equivalent;

3.      The Subscriber provides a suitable report of the cloud key protection solution subscription configuration protecting the key in hardware crypto module with a unit design form factor certified as conforming to at least FIPS 140-2 Level 2, eIDAS Protection Profile, EN 419 221-5, or equivalent.


Thanks,
Ian McMillan
Microsoft


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20201030/08523583/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: redline-v1-keyprotection.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 129090 bytes
Desc: redline-v1-keyprotection.docx
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20201030/08523583/attachment-0001.docx>