[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 

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


> 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