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

Inigo Barreira Inigo.Barreira at sectigo.com
Fri Dec 17 11:03:13 UTC 2021

Hi Ian,

I don´t know if it´s too late but I´d also like you to have in mind these
2 ETSI standards that may help or at least align some of the information
proposed for this ballot. These are:

ETSI TS 119 432 v1.2.1 - Protocols for remote digital signature creation

ETSI TS 119 431-1 v1.2.1 - TSPs operating a remote QSCD/SCDev

I think the latter is more appropriate for what we are discussion because
the “protocols” document is a more technical implementation, pretty much
ETSI style with the use of AdES formats and not within scope of these BRs,
but just in case.

I´m willing to help/clarify you (or any other), as the voluntary editor for
this ballot, some of the content and concepts in case you think is worthy.

I´ve attached the documents for convenience.


De: Cscwg-public <cscwg-public-bounces at cabforum.org> En nombre de Ian
McMillan via Cscwg-public
Enviado el: martes, 7 de diciembre de 2021 23:24
Para: Adriano Santoni <adriano.santoni at staff.aruba.it>;
cscwg-public at cabforum.org; Dimitris Zacharopoulos (HARICA) <dzacharo at harica.
gr>; Bruce Morton <Bruce.Morton at entrust.com>
Asunto: Re: [Cscwg-public] [EXTERNAL] Re: Discussion: Proposed Ballot CSC-6:
Update to Subscriber Private Key Protection Requirements

CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.

Hi Folks,

Coming out of our last call, I’ve made all the updates we discussed
including producing a definition for the term “hardware crypto module”
(see below).

Hardware Crypto Module: A tamper-resistant device with a dedicated
cryptography processor used for the specific purpose of protecting the
lifecycle of cryptographic keys (generating, managing, processing, and

Please see the attached redline now with all the latest updates and provide
feedback and willingness to endorse the ballot.



From: Cscwg-public <cscwg-public-bounces at cabforum.org
<mailto:cscwg-public-bounces at cabforum.org> > On Behalf Of Adriano Santoni
via Cscwg-public
Sent: Tuesday, November 23, 2021 8:34 AM
To: cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org>
Subject: Re: [Cscwg-public] [EXTERNAL] Re: Discussion: Proposed Ballot
CSC-6: Update to Subscriber Private Key Protection Requirements

Hi all,

I find the language in "Baseline Requirements for the Issuance and
Management of Code Signing.v2.6+CSC-6_redline_v2" rather confusing, about
private key protection.

It seems to me that section 16.3.1, in the added parts, only allows three
options for protecting the private key effective Sep 1, 2022:

1) hosted hardware crypto module (in short "HCM")
2) cloud-based key generation and protection solution (backed by an HCM)  (I
am not clear what's the difference with #1)
3) signing service

But later on, section 16.3.2 seems to allow a wider range of options,
including a suitable HCM shipped to the subscriber by the CA.

Am I reading wrong?

Also, I am not clear how option #3 in §16.3.2 works:

"3.    The Subscriber uses a CA prescribed CSP and a suitable hardware
module combination for the key pair generation and storage;"

Anybody willing to explain?


Il 23/11/2021 11:07, Dimitris Zacharopoulos (HARICA) via Cscwg-public ha

On 18/11/2021 7:03 μ.μ., Dimitris Zacharopoulos (HARICA) via Cscwg-public

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?

After our recent meeting, we agreed to tweak the language of 4. to cover
this use case described by Bruce. I recommend changing

"4.    The Subscriber provides a suitable IT audit indicating that its
operating environment achieves a level of security specified in section


"4.    The Subscriber provides an internal or external IT audit indicating
that it is only using a suitable hardware module as specified in section 16.
3.1 to generate keys pairs to be associated with Code Signing Certificates"

I also noticed that we don't have consistency among all listed options. Some
options just say " suitable hardware module", others point to 16.3.1 and
others say both. We could discuss at our next call or someone could take a
stab at it and try to use consistent language.


Cscwg-public mailing list
Cscwg-public at cabforum.org <mailto:Cscwg-public at cabforum.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20211217/20e9e27b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ts_11943101v010201p.pdf
Type: application/pdf
Size: 574621 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20211217/20e9e27b/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ts_119432v010201p.pdf
Type: application/pdf
Size: 822730 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20211217/20e9e27b/attachment-0003.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6853 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20211217/20e9e27b/attachment-0001.p7s>

More information about the Cscwg-public mailing list