[cabf_netsec] draft ballot proposal re: HSM firmware updates
josh at letsencrypt.org
Thu Nov 16 21:08:43 MST 2017
Yeah, I'm going to work on another draft but I'm traveling next week
so it probably won't be ready until the week of the 27th.
On Thu, Nov 16, 2017 at 11:16 AM, Ben Wilson <ben.wilson at digicert.com> wrote:
> 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
>>>> 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
> 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
Internet Security Research Group
Let's Encrypt: A Free, Automated, and Open CA
More information about the Netsec