[Cscwg-public] [EXTERNAL] Re: Discussion: Proposed Ballot CSC-6: Update to Subscriber Private Key Protection Requirements

[Dimitris Zacharopoulos (HARICA)]

On 17/11/2021 7:01 μ.μ., Ian McMillan wrote:
>
> Hi Dmitris,
>
> This is not too painful. 😊
>
> Effective date set is September 1, 2022 as stated in section 16.3, but 
> 16.2 already has an effective date (June 1, 2021) for signing services 
> to use at least FIPS 140-2 level 2, or Common Criteria EAL 4+ for ALL 
> Code Signing Certificates per the table in section 1.3.  I’ll add the 
> effective date into the table in section 1.3 for the changes in 16.3 
> on all code signing certs . Please review the text I used in the 1.3 
> table, and suggest some better language if possible.
>
> When I read the,"conforming to *at least* FIPS 140-2 level 2, or 
> Common Criteria EAL 4+", it does apply to CC EAL 4+ as well.
>

Thanks for clarifying.

> In 16.2, I’ve corrected the typo (thanks!), but for cloud-based 
> solutions they will have their own terms for resources under a 
> subscription. I think the wording we’ll need to summarize to is for 
> each key generated and stored in the cloud-based subscription it must 
> be conforming to the requirements. With Azure and AKV, if I have a 
> subscription with a resource group and an AKV resource underneath, for 
> every key I generate, I’ll need to specify the vault protection level 
> (HSM) upon key creation. This means I could have a subscription with N 
> number of keys with various protection levels. AKV recommends users do 
> not group secrets into one vault, but it doesn’t stop users from 
> making this risk decision on their own (more keys in one vault, the 
> larger impact if compromised). GCP and AWS all have similar offerings 
> and concepts, but the common level of terminology is subscription. 
> I’ve updated the language to specifically target the subscription 
> configuration at the level that manages the private key.
>

I believe this is too prescriptive. I don't think we can describe these 
specific options in a public standards document. That's why the term 
"signing service" and "cloud-based provider" must be described in terms 
of functional expectations. Who knows what options will be available in 
2-5 years, or whether Microsoft, Amazon, Google and others will change 
their models and call these options something different than "subscription".

> In 16.3.1, I’ve updated….
>
>  1. To be the suggested text you provided, “Subscriber uses a hosted
>     hardware crypto module meeting the specified requirement;” I feel
>     this effectively closes the loophole you pointed out.
>
> On cloud-based vs signing service solutions (2 & 3), they are 
> distinctly different solutions in the market for subscribers today, so 
> I feel we need to expressly call them out differently.
>

I don't disagree with that statement, although we do need to discuss and 
document their differences and even describe their functions in a clear 
and unambiguous way. The term "cloud" is overloaded and has been used in 
this industry to mean very different things  depending on the context.

> For section 16.3.2, I am good with the suggested change to #2 with a 
> small ordering tweak being, “The Subscriber counter-signs certificate 
> requests that can be verified by using a manufacturer’s certificate 
> indicating that the key was generated in a non-exportable way using a 
> suitable hardware module;”
>
> With #1, I’d prefer keeping the same way it is today.  I’m interested 
> how folks view section 10.2.4 playing a part here as well (and with 
> signing services).
>

To help with the comparison, let me repeat the text here:

/"1.    The CA ships a suitable hardware crypto module, with a 
preinstalled key pair" could be changed to://
////
//"1.    The CA ships a suitable hardware crypto module, with one or 
more pre-generated key pairs that the CA has generated using those 
crypto modules"/

The current wording is limiting the key-pairs to just *one key-pair* 
(singular) when the CA can ship more than one key-pairs (for future 
use). I also wanted to avoid the case where CAs generate keys outside of 
these hardware modules (via software because it's faster) and then 
import them into crypto-modules and ship them to Subscribers.

I see that you probably missed my comment for removing option 4. (a 
suitable IT audit, etc). Are there any objections to removing that 
problematic option?


> On #8, My goal wasn’t to set a deadline for new methods to be 
> introduced, but to require any innovations to be well documented by 
> the CAs and brought to the Forum’s working group for inclusion. That 
> said, I see the loophole this creates in that a CA could include a new 
> method in their CP/CPS docs and bring it to the WG in the accordance 
> with this requirement. But the WG could deem the method not acceptable 
> and there is no requirement that states the CA must not use that now 
> rejected method. The downside is we really do not want to maintain a 
> rejected method list, so I am with you on the suggested change you 
> provided with the date being September 1, 2022. I would like to keep 
> the dates all aligned to reduce confusion.
>

I believe this was discussed during our last call and the plan was for a 
roadmap that would ultimately remove this "any other method" option. 
Until that time, CAs would need to disclose their "any other methods" to 
the CABF until a certain date (Sep 1, 2022 seems fine with me), so the 
WG can evaluate the security of that method and either include or reject 
it. I think we're in total agreement here :)

> The attached updated redline draft has all these changes.
>

Let me know how you feel about the other changes. To summarize:

In section 16.3.2:

  * Update option 1 to allow more keys to be shipped and keys generated
    *in* crypto-devices instead of outside and then imported
  * Removal of option 4

We will probably need some more analysis comparing "signing service" vs 
"cloud provider" to get a better feeling of the functional differences 
and adjust accordingly.


Thanks,

Dimitris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20211117/28f98fc7/attachment.html>