[cabf_netsec] draft ballot proposal re: HSM firmware updates

[Josh Aas]

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:
> Josh,
> Do you want to go back to the drawing board and come back  with another ballot proposal?
> Thanks,
> Ben
>
>
> -----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?
>
> Regards,
> Fotis
>
>>
>>>> 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
> https://clicktime.symantec.com/a/1/vzX1xH7PMF5NlBMInFuMPnTQbH2vlQqIwxgk2puXdHM=?d=ki2iv9AYb5xB4EKjBjSSR-dskSKsYtc4k0UxHcE7W0t8cM6DGdT5osGiVaBC09lH5Tt3VwRcAv_2J2TNLPIJQxNQpQmfOL_NB5cjG5vG_sNydmV6xG-dud2-PZml25TRM0lutL0HpZX9d94vU6eQ1qo8OqQ8GvZ1zWTChfK-hjTw1yiKE0u75HvcacRaYXP5xK8iIGi5ECzxmb3dts2_hgXumQ-KtsTP1bVl36-4Npsx8S3sE9mYz0ImgGNESbROzNSKpJeFVE1GxbSAbgvvIPvgRRZB_kdzwxT6z0j0oIVL5-q2VbMH3L-4J8ZpZuVStqICG5SgtLeOz7kl09Oy_iR_xMFefKJIKeMMBsqpAKLz4wrI0EgqyVnmfXvawWj5hvHMJ2hzOLAkCHhVmv6_9cFHFTy6QC_XmckyP9i5diA%3D&u=http%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fnetsec



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