[cabf_netsec] draft ballot proposal re: HSM firmware updates

[Josh Aas]

Thanks for the feedback. Responses inline.

On Fri, Nov 10, 2017 at 2:45 AM, Fotis Loukos <fotisl at ssl.com> wrote:
> On 09/11/2017 06:09 μμ, Josh Aas via Netsec wrote:

>> 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)
>
> I think that the name is a little bit misleading, since NIST already has
> the Cryptographic Module Validation Program whose requirements are the
> whole FIPS 140-2. Someone who will just read the text without getting to
> the definitions may think that any FIPS 140-2 validated HSM can be used,
> no matter what level.

This doesn't seem very misleading. They're different phrases made up
of standard words. If someone is making decisions like buying HSMs
based on a casual reading of the BRs they're going to have a lot of
problems besides what HSMs they end up with.

>> 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.
>
> You could use FIPS 140-2 language here and also add EMI/EMC. I think
> that "The system or device meets the Cryptographic Module Validation
> Requirements in the areas of physical security and electromagnetic
> interference/electromagnetic compatibility" is better. And I do not
> think that you have to exclude the firmware since it is not included in
> these two areas per FIPS 140-2.

Your language would probably work but I think my original language is
more clear. Seems easiest to say that you should have a FIPS 140-3
physical device (firmware aside, since we're talking about loading
non-validated firmware) in order to make sure all bases are covered.
Also, I don't know what FIPS 140-2 has to do with anything, did you
mean FIPS 140-3?

>> 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.
>
> Should this be "in the latest firmware for the device that meets the
> Cryptographic Module Validation Requirements" ? Otherwise I don't think
> that you will be able to use this as is, since once the vulnerability
> becomes known the HSM vendor creates an updated firmware (which is the
> latest firmware) that patches it. I don't think that any vendor would
> have a known vulnerability at his latest firmware.

You're right, good catch. I've fixed it in my draft.

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