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

Tim Hollebeek tim.hollebeek at digicert.com
Wed Nov 4 15:42:40 MST 2020


We're looking at this as well, and should have some feedback soon.

 

-Tim

 

From: Cscwg-public <cscwg-public-bounces at cabforum.org> On Behalf Of Bruce
Morton via Cscwg-public
Sent: Sunday, November 1, 2020 2:38 PM
To: Ian McMillan <ianmcm at microsoft.com>; cscwg-public at cabforum.org
Subject: Re: [Cscwg-public] Update to key protection (in 16.2 & 16.3)

 

Hi Ian,

 

I will have our team review.

 

I have a couple of items:

1.	Signing Service requires FIPS 140-2 level 2. Should this be updated
to FIPS 140-2 level 3, as this device will not be operated by the Subscriber
and may have many multiple Subscriber private keys? Level 3 might be better
for a third party to protect a multi-tenant HSM.
2.	If this ballot passes, when would it need to be implemented. I think
that there may be many impacted to CAs and Subscribers. It would be good to
have many months to a year to implement.

 

 

Thanks, 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: Friday, October 30, 2020 6:11 PM
To: cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> 
Subject: [EXTERNAL][Cscwg-public] Update to key protection (in 16.2 & 16.3)

 

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 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_issua
nce_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/20201104/bde1683d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20201104/bde1683d/attachment-0001.p7s>


More information about the Cscwg-public mailing list