[cabf_netsec] draft ballot proposal re: HSM firmware updates

[Josh Aas]

NetSec Folks,

I've been putting together a ballot intended to resolve a conflict
between the Baseline Requirements and the Network Security
Requirements while introducing clear guidance on what firmware may run
on HSMs.

My draft ballot email is below my signature. The introduction contains
more background on the problem.

While I believe the NetSec requirements are essentially correct (you
should update if you need to do so to address a vulnerability), and
the BRs need to be fixed, it was recommended to me that I run this by
the NetSec group for feedback.

Thanks,

-- 
Josh Aas
Executive Director
Internet Security Research Group
Let's Encrypt: A Free, Automated, and Open CA


Ballot ??? - Cryptographic Module Validation Clarification

This ballot is intended to resolve a conflict between the Baseline
Requirements and the Network Security Requirements while introducing
clear guidance on what firmware may run on HSMs. The following motion
has been proposed by Josh Aas of ISRG / Let’s Encrypt and endorsed by
??? of ??? and ??? of ???.

Currently, the Baseline Requirements state the following in Section
6.2.7 Private Key Storage on Cryptographic Module:

“The CA SHALL protect its Private Key in a system or device that has
been validated as meeting at least FIPS 140 level 3 or an appropriate
Common Criteria Protection Profile or Security Target, EAL 4 (or
higher), which includes requirements to protect the Private Key and
other assets against known threats.”

This states that HSMs must be running FIPS 140 level 3 or an
appropriate Common Criteria Protection Profile or Security Target, EAL
4 (or higher) certified firmware. For the remainder of this
explanation I will simply say FIPS when I mean “FIPS 140 level 3 or an
appropriate Common Criteria Protection Profile or Security Target, EAL
4 (or higher) certified firmware.”

However, the Network Security Requirements state the following in
Section 1 Letter l:

“Apply recommended security patches to Certificate Systems within six
(6) months of the security patch’s availability, unless the CA
documents that the security patch would introduce additional
vulnerabilities or instabilities that outweigh the benefits of
applying the security patch.”

The concept that vulnerabilities must be addressed is expanded upon in
Network Security Requirements Section 4 Letter f.

It is possible for vulnerabilities to be discovered in FIPS certified
HSM firmware. When that happens, updated firmware is often made
available by HSM vendors. However, due to the extreme time and expense
required for FIPS certification, such updates are often not FIPS
certified. This puts CAs in a position where they have to decide
whether to run FIPS certified firmware per the Baseline Requirements
or address vulnerabilities in critical systems in a timely manner per
the Network Security Requirements (and common sense). It also puts CAs
in a position where they are non-compliant with one requirement or the
other no matter what they do.

-- MOTION BEGINS --
In the Baseline Requirements, ADD the following definition to Section 1.6.1:

Cryptographic Module Validation Requirements: FIPS 140 level 3 or an
appropriate Common Criteria Protection Profile or Security Target, EAL
4 (or higher)

In the Baseline Requirements, REPLACE the entire text of Section 6.2.7
with the following:

The CA SHALL protect its Private Key in a system or device meeting the
Cryptographic Module Validation Requirements, or a device that meets
all of the following criteria:

1) The physical device (excluding firmware) meets the Cryptographic
Module Validation Requirements.
2) There is firmware available for the device that meets the
Cryptographic Module Validation Requirements.
3) There is at least one known vulnerability, which the CA feels the
need to address, in the latest firmware for the device.
4) The device is running with updated firmware which does not meet the
Cryptographic Module Validation Requirements but addresses the
aforementioned vulnerability.
5) The CA documents the vulnerability, the assessed risks, and the
decision to update firmware to a version that doesn't meet the
Cryptographic Module Validation Requirements.

The decision to patch a Cryptographic Module in such a way that it
meets the above listed requirements but no longer meets Cryptographic
Module Validation Requirements shall be at the discretion of the CA,
taking into account the CA’s threat model and relevant mitigations.

Cryptographic Modules SHALL be configured to run in a relevant
compliance mode at all times (e.g. "FIPS mode") if such a mode is
available, whether or not the current firmware version itself has been
validated to meet Cryptographic Module Validation Requirements.
-- MOTION ENDS --