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

Ben Wilson bwilson at mozilla.com
Fri Nov 13 11:37:32 MST 2020 

Responding on my own as an interested party and not on behalf of Mozilla:

Couldn't you say "FIPS 140-2 OR FIPS 140-3" for the indefinite future?  I
don't think it has to be only one or the other.

On Fri, Nov 13, 2020 at 6:46 AM Bruce Morton via Cscwg-public <
cscwg-public at cabforum.org> wrote:

> Regarding FIPS 140-3, I don't think that this should be referenced unless
> we have decided that we should not use FIPS 140-2 devices. Currently, we
> have deployed FIPS 140-2 tokens to Subscribers and we use FIPS 140-2
> devices for our CAs, OCSP responders, TSAs, etc. I don't think we need to
> reference FIPS 140-3 until we have a plan to phase out FIPs 140-2 devices.
>
> Bruce.
>
> -----Original Message-----
> From: Cscwg-public <cscwg-public-bounces at cabforum.org> On Behalf Of Tomas
> Gustavsson via Cscwg-public
> Sent: Friday, November 13, 2020 3:09 AM
> To: cscwg-public at cabforum.org
> Subject: [EXTERNAL]Re: [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,
>
> I have reached out to a security architect at a vendor of security
> hardware chips to get a better understanding on the certification side of
> things.
>
> The story gets foggier...at least for me.
>
> I have more questions than answers unfortunately. But it boils down to if
> the forum want to high a high level of assurance of private key protection,
> or muddier, opening options for weaker private key protection?
>
> The security architect I spoke with don't think we should use "or
> equivalent" as that is very non specific. How to judge this? In his opinion
> it open up doors to weak private key protection.
>
> I got a little better insight into chip silicon certifications.
>
> FIPS 140-2 or EN 419 221-5 are highly related to HSMs.
> BTW: from now on HSMs are evaluated against FIPS 140-3 I believe (since
> september 2020).
>
> Silicon produced for USB tokens and smart cards are evaluated against:
>
> TPM silicon is certified against:
> https://trustedcomputinggroup.org/resource/pc-client-tpm-certification/
>
> Then system vendors can lay FIPS certification on top of the silicon
> certification, adding their firmware.
>
> https://trustedcomputinggroup.org/resource/tcg-fips-140-2-guidance-for-tpm-2-0/
>
> A relevant requirement for TPMs module certification would be:
> "Protection Profile PC Client Specific TPM version 2.0"
>
> For smart cards or USB token chips it could be:
> "Security IC Platform Protection Profile version 1.0"
>
> To complicate things some old tokens like SafeNet was certified against:
> "Protection Profile -Secure Signature-Creation Device v1.05"
>
> Questions:
>
> 1. How strongly does the forum want to assure private key protection for
> code signing keys?
>
> 2. Question I guess if for WebTrust, is it reasonable to judge "or
> equivalent", or does it open up too many doors to weak key protection?
> For example is the CC evaluation of SafeNet eToken 5110 (a popular USB
> token) equivalent?
>
> https://cpl.thalesgroup.com/access-management/authenticators/pki-usb-authentication/etoken-5110-usb-token
>
> 3. Should we FIPS 140-3 directly? Evaluations on -3 has begun.
>
> 4. If the Forum want to specify USB tokens and TPMs more carefully, should
> those certification standards be called out?
>
> Regards,
> Tomas
>
> On 2020-11-02 20:43, Ian McMillan via Cscwg-public wrote:
> > Thanks Bruce!
> >
> >
> >
> > For #1, I am interested in better understanding what advantages level
> > 3 operations provides here. I do feel level 2 will continue to be the
> > best course of requirement as a Signing Service should have the
> > ability to execute on resiliency scenarios that would be negated by
> > level 3 operations (e.g. HSM vendor and SW diversity/resilience). I
> > also do not want to exclude Signing Services from leveraging
> > cloud-based key protection services which offer level 2 as a
> > base/premium SKU in all cases (not all have a level 3 option).
> >
> >
> >
> > On #2, I feel the timing is at least one year out from the June 1,
> > 2021 date that we attached to key lengths and hash algorithms. The 1
> > year from that date should provide most the opportunity to obtain a
> > code signing certificate within the new standards for key protection.
> > It may be best to state in the timing that any new certificates issued
> > post implementation date (say June 1, 2021) must meet the these key
> > protection standards, but private keys for existing valid certificates
> > have until June 1, 2022 to meet these requirements. Is this viable in
> > folks mind?
> >
> >
> >
> > Thanks,
> >
> > Ian
> >
> >
> >
> >
> >
> > *From:* Bruce Morton <Bruce.Morton at entrust.com>
> > *Sent:* Sunday, November 1, 2020 11:38 AM
> > *To:* Ian McMillan <ianmcm at microsoft.com>; cscwg-public at cabforum.org
> > *Subject:* [EXTERNAL] RE: 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcab
> > forum.org%2Fwp-content%2Fuploads%2Fbaseline_requirements_for_the_issua
> > nce_and_management_of_code_signing.v.2.0.pdf&data=04%7C01%7Cianmcm%40m
> > icrosoft.com%7C7f76fb8beccf4872e87508d87e9db601%7C72f988bf86f141af91ab
> > 2d7cd011db47%7C0%7C0%7C637398563618781485%7CUnknown%7CTWFpbGZsb3d8eyJW
> > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&
> > sdata=n20Tj9NtxJ%2BN0DYmwZABe04HUShfI70zAG%2BVlDSPyls%3D&reserved=0>
> > 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
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Cscwg-public mailing list
> > Cscwg-public at cabforum.org
> > https://lists.cabforum.org/mailman/listinfo/cscwg-public
> >
> _______________________________________________
> Cscwg-public mailing list
> Cscwg-public at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/cscwg-public
>
> _______________________________________________
> 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/20201113/cd77c8aa/attachment-0001.html>

More information about the Cscwg-public mailing list