[Cscwg-public] [EXTERNAL] Re: Discussion: Proposed Ballot CSC-6: Update to Subscriber Private Key Protection Requirements
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Thu Nov 18 17:03:31 UTC 2021
On 18/11/2021 4:09 μ.μ., Bruce Morton wrote:
>
> Hi Dimitris,
>
> I don’t accept that IT audit will not be used. The reason is that the
> ballot will remove software keys from non-EV code signing
> certificates. This is a new requirement and will impact the majority
> of the certificates and the Subscribers. In addition, there was no
> requirement to check how Subscriber keys were generated or non-EV code
> signing certificates, another new requirement.
>
This is confusing. We had this language for EV Code Signing Certificates
and nobody was using it. How would it be used for non-ev code signing
certificates?
> I don’t think that a CA or Qualified Auditor can audit a bank of HSMs
> in production, HA and DR modes for all the keys which a software
> developer will need for the next undefined period of time. They can
> only look at the past. I understand that you can ship a token with
> more than one key, but the HSM might have thousands or millions of
> keys required for generation on-demand.
>
Ok, so you are thinking of a Subscriber that owns an HSM and gets an IT
audit that has an audit report that asserts that all Keys associated
with Code Signing Certificates are generated in an on-prem certified
HSM. Is this what this method is supposed to cover?
> Option 5 Cloud-based protection is NOT Option 7 Signing Service
> protection. Cloud-based protection will allow a Subscriber to use an
> HSM from AWS. Signing Service protection has many requirements in the
> CSBRs, which currently includes an audit report. I assume that a CA
> will provide a Signing Service or could be similar to a TSP providing
> QSCD key generation and signing.
>
> Option 5 states, “The Subscriber provides a suitable report from the
> cloud-based key protection solution subscription and resources
> configuration protecting the private key in a suitable hardware crypto
> module meeting the requirements specified in section 16.3.1.” This is
> essentially a subscription agreement and not an audit report.
>
This "subscription agreement" has absolutely no assurances about
anything. Any company could suggest they are a "cloud-based" provider
with no audits and no assurances but would have a "subscription
agreement". Would CAs accept that?
We can discuss more on the call today.
Dimitris.
> Thanks, Bruce.
>
> *From:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
> *Sent:* Thursday, November 18, 2021 1:58 AM
> *To:* Bruce Morton <Bruce.Morton at entrust.com>;
> cscwg-public at cabforum.org; Ian McMillan <ianmcm at microsoft.com>
> *Subject:* Re: [Cscwg-public] [EXTERNAL] Re: Discussion: Proposed
> Ballot CSC-6: Update to Subscriber Private Key Protection Requirements
>
> On 17/11/2021 8:56 μ.μ., Bruce Morton wrote:
>
> Hi Dimitris,
>
> Regarding this statement, “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?”
>
> The concern I have and has been raised on a call is if a customer
> has purchased a server HSM, which does not support key
> attestation, what is the CAs alternative to verify that the many
> keys have been generated on the HSM?
>
>
> This is covered under option 6.
>
> /" 6. The CA or a Qualified Auditor witnesses the key creation in a
> suitable hardware crypto module solution including a cloud-based key
> generation and protection solution. " /
>
>
> I do understand that this is a problematic option, but I do not
> see another option for the above use case. We might be better
> suited to provide more information on the IT audit. Here are some
> ideas:
>
> 1. Form audit letter included in the CSBRs
> 2. Signed by a verified identity, such as a Contract Signer
> 3. Audit letter Includes a warranty that all keys for code
> signing certificates requested will be generated on the HSM
> 4. Audit includes crypto device make, model, serial number and
> picture of serial number
> 5. Etc.
>
> I think we see that the current environment has limited USB tokens
> which support both 3072/4096-bit RSA and key attestation. We also
> see that many server HSMs do not support key attestation. It looks
> like the ecosystem needs to evolve a little longer before we can
> make our requirements perfect.
>
>
> As explained in previous discussions, there is no "IT audit" today
> that can remotely attest that an operating environment achieves the
> levels of security described in 16.3.1 (i.e. FIPS 140-2 level 2 or EAL
> 4+). I believe your use case is perfectly covered with the new option 6.
>
>
> Also, I don’t see that option 4 IT audit is any more problematic
> than option 5 a cloud provider subscription agreement.
>
>
> The "cloud-based key protection solution" (or a "signing service key
> protection solution") will include an audit report that describes that
> the solution actually uses HSMs certified according to 16.3.1. The CA
> will review this audit report, ensure that the solution is compliant
> with 16.3.1 and then allow the Subscriber to use that service.
> Actually, 5 is very similar to 7, which is why I am suggesting we
> merge the "cloud-based solution" and the "signing service".
>
> Dimitris.
>
>
> Bruce.
>
> *From:* Cscwg-public <cscwg-public-bounces at cabforum.org>
> <mailto:cscwg-public-bounces at cabforum.org> *On Behalf Of *Dimitris
> Zacharopoulos (HARICA) via Cscwg-public
> *Sent:* Wednesday, November 17, 2021 1:22 PM
> *To:* Ian McMillan <ianmcm at microsoft.com>
> <mailto:ianmcm at microsoft.com>; cscwg-public at cabforum.org
> *Subject:* Re: [Cscwg-public] [EXTERNAL] Re: Discussion: Proposed
> Ballot CSC-6: Update to Subscriber Private Key Protection Requirements
>
> 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:
>
> 1. Update option 1 to allow more keys to be shipped and keys
> generated *in* crypto-devices instead of outside and then imported
> 2. 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.
>
> /Any email and files/attachments transmitted with it are
> confidential and are intended solely for the use of the individual
> or entity to whom they are addressed. If this message has been
> sent to you in error, you must not copy, distribute or disclose of
> the information it contains. _Please notify Entrust immediately_
> and delete the message from your system./
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20211118/5db0b95d/attachment-0001.html>
More information about the Cscwg-public
mailing list