[cabf_netsec] draft ballot proposal re: HSM firmware updates
ben.wilson at digicert.com
Thu Nov 16 10:16:28 MST 2017
Do you want to go back to the drawing board and come back with another ballot proposal?
From: Netsec [mailto:netsec-bounces at cabforum.org] On Behalf Of Fotis Loukos via Netsec
Sent: Tuesday, November 14, 2017 3:11 AM
To: Josh Aas <josh at letsencrypt.org>
Cc: CA/Browser Forum Network Security WG List <netsec at cabforum.org>
Subject: Re: [cabf_netsec] draft ballot proposal re: HSM firmware updates
On 14/11/2017 06:32 πμ, Josh Aas wrote:
> 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
>>> Cryptographic Module Validation Requirements: FIPS 140 level 3 or an
>>> appropriate Common Criteria Protection Profile or Security Target,
>>> 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.
I would totally agree with you, if CAs and browsers were the only target audience of the BRs :) This was just a recommendation, for me it's pretty clear the way it is.
>>> 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.
According to FIPS 140-2, there are eleven different areas of validation.
If you check the certificate of any cryptographic module, you will see that there is a different level in every area. How do you define 'Physical device (excluding firmware)'? Is the example of EMI/EMC included in the 'physical device (excluding firmware)'? If you have an HSM which conforms to level 3 in physical security (as defined in FIPS
140-2) and to level 2 in EMI/EMC, are you allowed to use it? That's why I argue that it's best to use FIPS 140-2 areas, somebody can just get the certificate and check the areas that interest him.
> Also, I don't know what FIPS 140-2 has to do with anything, did you
> mean FIPS 140-3?
I am talking about FIPS publication 140-2 by NIST, the latest version in the 140 publication series. As far as I know FIPS 140-3 was a big fail, so NIST is going to issue FIPS 140-4. Are you confusing the version of the publication with the level of security?
>>> 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.
Fotis Loukos, PhD
Director of Security Architecture
e: fotisl at ssl.com
Netsec mailing list
Netsec at cabforum.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4934 bytes
Desc: not available
More information about the Netsec