[cabf_netsec] draft ballot proposal re: HSM firmware updates

Ben Wilson 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?

-----Original Message-----
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 
>>> 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.

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
SSL Corp
e: fotisl at ssl.com
w: https://clicktime.symantec.com/a/1/ZqITkuiDIkSAwuPRkZLyTrB40AciFTYO4_STaWGl5_4=?d=ki2iv9AYb5xB4EKjBjSSR-dskSKsYtc4k0UxHcE7W0t8cM6DGdT5osGiVaBC09lH5Tt3VwRcAv_2J2TNLPIJQxNQpQmfOL_NB5cjG5vG_sNydmV6xG-dud2-PZml25TRM0lutL0HpZX9d94vU6eQ1qo8OqQ8GvZ1zWTChfK-hjTw1yiKE0u75HvcacRaYXP5xK8iIGi5ECzxmb3dts2_hgXumQ-KtsTP1bVl36-4Npsx8S3sE9mYz0ImgGNESbROzNSKpJeFVE1GxbSAbgvvIPvgRRZB_kdzwxT6z0j0oIVL5-q2VbMH3L-4J8ZpZuVStqICG5SgtLeOz7kl09Oy_iR_xMFefKJIKeMMBsqpAKLz4wrI0EgqyVnmfXvawWj5hvHMJ2hzOLAkCHhVmv6_9cFHFTy6QC_XmckyP9i5diA%3D&u=https%3A%2F%2Fwww.ssl.com
Netsec mailing list
Netsec at cabforum.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4934 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/netsec/attachments/20171116/a397375f/attachment.p7s>

More information about the Netsec mailing list