CSC-16: Improved signing services requirements #12

CBonnell · 2022-08-19T15:18:35Z

No description provided.

dzacharo

Great work Corey, thanks for the proposed changes.

docs/CSBR.md

dzacharo · 2022-08-25T09:47:47Z

docs/CSBR.md

@@ -857,22 +859,20 @@ Private Keys corresponding to CA Keys MUST be stored in accordance with BR Secti

 #### 6.2.7.2 Private key storage for Timestamp Authorities

-A Timestamp Authority MUST protect its signing key using a process that is at least to FIPS 140-2 Level 3, Common Criteria EAL 4+ (ALC\_FLR.2), or higher. The CA MUST protect its signing operations in accordance with the CA/Browser Forum's Network Security Guidelines.
+A Timestamp Authority MUST protect its signing key using a process that is at least to FIPS 140-2 Level 3, Common Criteria EAL 4+ (ALC\_FLR.2), or higher. The Timestamp Authority MUST protect its signing operations in accordance with the CA/Browser Forum's Network Security Guidelines.


The reference to the NetSec Guidelines seems redundant as it is explicitly required under section 6.7. Perhaps we can update 6.7 to explicitly require adherence to the NetSec Guidelines for CAs issuing Code Signing Certificates, Signing Services Managing Private Keys on behalf of Subscribers and Time-stamping Authorities.

I think the issue is the NetSec document scope states "These Network and Certificate System Security Requirements (Requirements) apply to all publicly trusted Certification Authorities (CAs) ..." It does not call out Timestamp Authority or Signing Service. I think if we leave this in place, then those entities will better understand the requirement.

If we explicitly state in 6.7 that Timestamp Authorities must also be audited against NetSec, then we should be fine because they take precedence.

So maybe we only need to reference NetSec in 6.7 for requirement and 8.4 subsection for audit.

This still needs to be figured out but I think we're close.

dzacharo · 2022-08-25T09:54:24Z

docs/CSBR.md

@@ -961,6 +958,8 @@ Cryptographic algorithms, key sizes and certificate life-times for both authorit

 ## 6.7 Network security controls

+The CA/Browser Forum’s Network and Certificate System Security Requirements are incorporated by reference as if fully set forth herein.
+


The NetSec Guidelines refer to "Root CA Systems" being air-gapped or offline. Should we update the text here to state that the requirements for "Root CA Systems" apply equally to Time-stamping CAs (Issuing CAs, Subordinate CAs)?

In case this comes as a surprise to some CAs, we could introduce an effective date 9-12 months away but only if we hear a CA with a real problem complying to this new requirement.

I think we should address the air-gap requirement for a Time-stamping CA in the time-stamp ballot, which we plan to do to address other time-stamping requirements as well.

dzacharo · 2022-08-25T09:58:44Z

docs/CSBR.md

@@ -1373,20 +1372,42 @@ As specified in BR Section 8.2.

 ## 8.4 Topics covered by assessment



It's very useful to clearly list the three different functions (CA, Signing Services, Time-stamping). I was wondering if we should add a sentence that allows for a combined assessment report for all functions, if they are provided by a single Legal Entity. I wouldn't want Certificate Consumers requesting 3 separate assessment reports from each CA that perform all three functions.

If a combined assessment report is not understood, then yes I agree we should add a sentence to allow this.

XolphinMartijn · 2022-08-25T19:30:54Z

docs/CSBR.md


-1.  Use of an HSM, verified by means of a manufacturer's certificate;
+1.  Use of an HSM, verified by means of the FIPS or Common Criteria certificate; or


Is this correct?
The way I read the old language, this is meant as key attestation. However the new language doesn't, and I'm not sure providing a FIPS certification document proofs that a HSM was used for key generation itself

I did not understand key attestation, but understood certification, so a certificate would show certification.

I agree with @XolphinMartijn a FIPs certification proves you have a FIPs HSM but doesn't ensure the key was generated there. Is the desire to change the language from Manufacturers certificate because there is a lack of standard methods to request that from the HSM? That has been my experience.

Right this change effectively removes the previous requirement, as FIPS is always required.

dzacharo · 2022-11-15T07:34:49Z

docs/CSBR.md

+The Timestamp Authority MUST undergo a conformity assessment audit for compliance with these Requirements performed in accordance with one of the following schemes:
+
+1.  “WebTrust for CAs v2.0 or newer” AND “WebTrust for Certification Authorities – Code Signing Baseline Requirements v2.0 or newer” AND “WebTrust for CAs SSL Baseline with Network Security v2.3 or newer” only as it applies to Network Security Requirements; or 
+2.  ETSI EN 319 411-1, which includes normative references to ETSI EN 319 401 (the latest version of the referenced ETSI documents should be applied).


This should be

2. ETSI EN 319 421, which includes normative references to ETSI EN 319 401 and ETSI EN 319 411-1 (the latest version of the referenced ETSI documents should be applied).

ianjmcm · 2022-11-17T17:02:10Z

docs/CSBR.md


-For Code Signing Certificates, Signing Services shall protect Private Keys in a Hardware Crypto Module conforming to at least FIPS 140-2 level 2 or Common Criteria EAL 4+.
+For Code Signing Certificates, Signing Services SHALL protect Private Keys in a Hardware Crypto Module conforming to at least FIPS 140-2 level 3 or Common Criteria EAL 4+.


Can we add a by xx date for signing services to meet this requirement change? I'd suggest a date no earlier than June 1, 2023.

Agree, an effective date could be used; however, we might not have an issue with so few Signing Services being implemented to date. Perhaps we can get feedback on one of the calls.

Need to agree on an effective date.

DigiCert doesn't need an effective date, so we can either choose something harmless, or leave it out entirely.

dzacharo · 2022-11-28T06:33:05Z

docs/CSBR.md

@@ -166,7 +171,7 @@ Capitalized Terms are as defined in the Baseline Requirements or the EV SSL Guid

 **Signature**: An encrypted electronic data file which is attached to or logically associated with other electronic data and which (i) identifies and is uniquely linked to the signatory of the electronic data, (ii) is created using means that the signatory can maintain under its sole control, and (iii) is linked in a way so as to make any subsequent changes that have been made to the electronic data detectable.

-**Signing Service**: An organization that signs Code on behalf of a Subscriber using a Private Key associated with a Code Signing Certificate.
+**Signing Service**: An organization that signs Code on behalf of a Subscriber using a Private Key associated with the Subscriber's Code Signing Certificate.


I believe we have already described the use case where the user may only be sending a "hash-to-be-signed" and not the entire Code, so we might need to take that into consideration. We should also highlight that this is a "remote" service.

Here is my proposal:

Signing Service: An organization that remotely signs Code or data associated with Code, on behalf of a Subscriber using a Private Key associated with the Subscriber's Code Signing Certificate.

Is is not always a hash? Either the Signing Service creates the hash or receives a hash. Or do I have that wrong?

The definition of "Code" is :

Code: A contiguous set of bits that has been or can be digitally signed with a Private Key that corresponds to a Code Signing Certificate.

So, a Signing Service either receives the Code and signs it (by creating the hash, etc, etc) or receives a hash from the Subscriber and signs that hash.

I don't think changes are needed here. It has been historically understood that creating an intermediate hash, and then signing the hash, is how signing works.

Unless we're going to start adding requirements about inspecting the code to be signed (which is actually a legitimate conversation topic), this detail doesn't matter. If a signing service receives a hash and signs it, it has "signed Code", despite never having seen it. In a model where the signature simply exists to associate an identity with the Code at the signer's request, without any inspection of the Code, this works just fine. And, for better or worse, that's the current signing model in this ecosystem.

dzacharo · 2022-11-28T06:37:08Z

docs/CSBR.md

@@ -792,7 +793,7 @@ The CA SHALL reject a certificate request if the requested Public Key does not m

 ### 6.1.2 Private key delivery to subscriber

-If the CA or any Delegated Third Party is generating the Private Key on behalf of the Subscriber where the Private Keys will be transported to the Subscriber outside of the Signing Service's secure infrastructure, then the entity generating the Private Key MUST either transport the Private Key in hardware with an activation method that is equivalent to 128 bits of encryption or encrypt the Private Key with at least 128 bits of encryption strength. Allowed methods include using a 128-bit AES key to wrap the private key or storing the key in a PKCS 12 file encrypted with a randomly generated password of more than 16 characters containing uppercase letters, lowercase letters, numbers, and symbols for transport.
+If the CA or any Delegated Third Party is generating the Private Key on behalf of the Subscriber where the Private Keys will be transported to the Subscriber outside of the CA's or Delegated Third Party's secure infrastructure, then the entity generating the Private Key MUST either transport the Private Key in hardware with an activation method that is equivalent to 128 bits of encryption or encrypt the Private Key with at least 128 bits of encryption strength. Allowed methods include using a 128-bit AES key to wrap the Private Key or storing the Private Key in a PKCS 12 file encrypted with a randomly generated password of more than 16 characters containing uppercase letters, lowercase letters, numbers, and symbols for transport.


Why do we explicitly call out a "Delegated Third Party" in this section? Which scenario are we trying to allow?

I think we are just adding "Delegated Third Party" to be complete to describe the "secure infrastructure."

We are replacing "Signing Service" with "Delegated Third Party" which is a bit strange and I would like to discuss a bit more to understand the possible scenarios we want to support.

Following-up on the meeting of 2022-12-01, add a new sentence:

"If a Signing Service is generating a Private Key on behalf of the Subscriber, that Private Key SHALL NOT be transported to the Subscriber".

Sending subscriber keys as PKCS#12 files seems very sketchy. Doesn't that bypass the whole subscriber private key protection requirements? How does the CA verify that the subscriber is using an HSM when the CA simply sent a P12 file? Requre and audit that the key was imported in an HSM and then the P12 file was wiped?
Today signing keys are laying around on P12 files, isn't that what we want to get away from?
PKCS#12 is not a well defined protection btw, different encryption algorithms can be used, including single DES, RC2, etc.

I think the purpose of this section was to transport keys generated in software. Perhaps we should only allow this section until 1 June 2023, when the private key protection ballot is in place. We could add the text which Dimitris provided. We could also state something to the effect that a CA can transport private keys to the Subscriber in a Hardware Crypto Module, where the activation data is provided out of band. This would line up with 6.2.7.4.2 item 1.

dzacharo · 2022-11-28T06:41:01Z

docs/CSBR.md

@@ -848,7 +849,7 @@ Private Keys corresponding to Root Certificates MUST NOT be used to sign Certifi

 ### 6.2.6 Private key transfer into or from a cryptographic module

-For Certificates transported outside of a Signing Service's secure infrastructure, the CA or Signing Service MUST require, by contract, each Subscriber to generate their own Private Key and protect the Private Key in accordance with [Section 6.2.7.4](#6274-subscriber-private-key-protection-and-verification).
+The CA or Timestamp Authority SHALL NOT transfer Private Keys from a cryptographic module to a Subscriber.


I'm not sure why this is necessary. It is strange to read that we disallow a CA or Timestamp Authority Private Key to be transferred to a Subscriber... I think the idea is to restrict ANY transfer of those types of keys outside a cryptographic module.

Recommended change:

The CA or Timestamp Authority SHALL NOT transfer Private Keys from a cryptographic module to a destination that does not meet the requirements of Section 6.2.7.4.

First, this looks like a typo so "The CA and Timestamp Authority" should be "The Timestamp and Signing Service" SHAL NOT ... The original requirement stated requirements for both the CA and the Signing Service, so the proposal was to be consistent. Perhaps we should state "Subscriber Private Keys".

dzacharo · 2022-11-28T06:47:06Z

docs/CSBR.md


 #### 6.2.7.3 Private key storage for Signing Services

-The Signing Service MUST ensure that a Subscriber's Private Key is generated, stored, and used in a secure environment that has controls to prevent theft or misuse. A Signing Service MUST enforce multi-factor authentication to access and authorize Code Signing and obtain a representation from the Subscriber that they will securely store the tokens required for multi-factor access. A system used to host a Signing Service MUST NOT be used for web browsing. The Signing Service MUST run a regularly updated antivirus solution to scan the service for possible virus infection. The Signing Service MUST comply with the Network Security Guidelines as a "Delegated Third Party".
+The Signing Service MUST ensure that a Subscriber's Private Key is generated, stored, and used in a secure environment that has controls to prevent theft or misuse. A Signing Service MUST enforce multi-factor authentication or secure server-to-server authentication to access and authorize the signing of Application Code. The Signing Service MUST comply with the Network Security Guidelines.


How is "secure server-to-server authentication" defined? We should either provide some illustrative examples so that those implementing and auditing this requirement have some approximation of what we mean by "secure", or remove the word "secure".

Also, "Application Code" is not defined. Suggest removing the word "Application".

We repeat that the Signing Service MUST comply with NetSec. See my previous comment about possibly updating section 6.7 so we don't have to repeat this requirement multiple times in the CSBRs.

I added in "secure server-to-server authentication" to support automated signing, which might be the largest use case. I also have not had anyone state what term or methods we should use for machine-to-machine authentication. However, I believe that CAs have already implemented this type of process for automated certificate issuance. I would prefer we make a statement which gives an alternative to "multi-factor".

We probably need more details from CAs that have implemented this type of process so the replacement language is equally secure (or more secure) than the previous one. The way this proposal is written, without any description or controls for the server-to-server authentication, may weaken the process. I mean, on one hand we require multi-factor authentication and on the other (server-to-server) it could be just a plain password which never expires.

I agree, we need more details on minimum requirements for secure server to server authentication. Let me ask our security team what we can recommend here.

dzacharo · 2022-11-28T06:49:23Z

docs/CSBR.md


-For Code Signing Certificates, Signing Services shall protect Private Keys in a Hardware Crypto Module conforming to at least FIPS 140-2 level 2 or Common Criteria EAL 4+.
+For Code Signing Certificates, Signing Services SHALL protect Private Keys in a Hardware Crypto Module conforming to at least FIPS 140-2 level 3 or Common Criteria EAL 4+.


For Code Signing Certificates, Signing Services SHALL protect Subscriber Private Keys....

docs/CSBR.md

Ivanyy5

docs/CSBR.md

timfromdigicert · 2023-02-28T16:05:28Z

docs/CSBR.md

@@ -91,6 +93,10 @@ If a Delegated Third Party fulfills any of the CA's obligations under [Section 4

 ### 1.3.5 Other participants

+Signing Services MAY support generation of Subscriber Key Pair and maintain security of the Subscriber Private Key.


Should we leave this just to avoid people making unwarranted assumptions that removing it means it's prohibited?

timfromdigicert · 2023-02-28T16:08:56Z

docs/CSBR.md

@@ -166,7 +171,7 @@ Capitalized Terms are as defined in the Baseline Requirements or the EV SSL Guid

 **Signature**: An encrypted electronic data file which is attached to or logically associated with other electronic data and which (i) identifies and is uniquely linked to the signatory of the electronic data, (ii) is created using means that the signatory can maintain under its sole control, and (iii) is linked in a way so as to make any subsequent changes that have been made to the electronic data detectable.

-**Signing Service**: An organization that signs Code on behalf of a Subscriber using a Private Key associated with a Code Signing Certificate.
+**Signing Service**: An organization that signs Code on behalf of a Subscriber using a Private Key associated with the Subscriber's Code Signing Certificate.


I don't think changes are needed here. It has been historically understood that creating an intermediate hash, and then signing the hash, is how signing works.

Unless we're going to start adding requirements about inspecting the code to be signed (which is actually a legitimate conversation topic), this detail doesn't matter. If a signing service receives a hash and signs it, it has "signed Code", despite never having seen it. In a model where the signature simply exists to associate an identity with the Code at the signer's request, without any inspection of the Code, this works just fine. And, for better or worse, that's the current signing model in this ecosystem.

timfromdigicert · 2023-02-28T16:10:35Z

docs/CSBR.md

@@ -401,13 +403,13 @@ For EV Code Signing Certificates, use of documents, data, and previous validatio

 CAs MUST not issue new or replacement Code Signing Certificates to an entity that the CA determined intentionally signed Suspect Code. The CA MUST keep meta-data about the reason for revoking a Code Signing Certificate as proof that the Code Signing Certificate was not revoked because the Applicant was intentionally signing Suspect Code.

-CAs MAY issue new or replacement Code Signing Certificates to an entity who is the victim of a documented Takeover Attack, resulting in either a loss of control of their code-signing service or loss of the Private Key associated with their Code Signing Certificate.
+CAs MAY issue new or replacement Code Signing Certificates to an entity who is the victim of a documented Takeover Attack, resulting in a loss of control of the Private Key associated with their Code Signing Certificate.


Since the ballot now likely won't be effective until after the HSM deadline, perhaps we go ahead and remove the Takeover Attack verbiage as previously agreed? As we discussed, that language was only there as a compensating control because we were unable to mandate HSM usage at the time the language was written, c. 2015.

timfromdigicert · 2023-02-28T16:12:13Z

docs/CSBR.md

@@ -857,22 +859,20 @@ Private Keys corresponding to CA Keys MUST be stored in accordance with BR Secti

 #### 6.2.7.2 Private key storage for Timestamp Authorities

-A Timestamp Authority MUST protect its signing key using a process that is at least to FIPS 140-2 Level 3, Common Criteria EAL 4+ (ALC\_FLR.2), or higher. The CA MUST protect its signing operations in accordance with the CA/Browser Forum's Network Security Guidelines.
+A Timestamp Authority MUST protect its signing key using a process that is at least to FIPS 140-2 Level 3, Common Criteria EAL 4+ (ALC\_FLR.2), or higher. The Timestamp Authority MUST protect its signing operations in accordance with the CA/Browser Forum's Network Security Guidelines.


This still needs to be figured out but I think we're close.

timfromdigicert · 2023-02-28T16:13:10Z

docs/CSBR.md


 #### 6.2.7.3 Private key storage for Signing Services

-The Signing Service MUST ensure that a Subscriber's Private Key is generated, stored, and used in a secure environment that has controls to prevent theft or misuse. A Signing Service MUST enforce multi-factor authentication to access and authorize Code Signing and obtain a representation from the Subscriber that they will securely store the tokens required for multi-factor access. A system used to host a Signing Service MUST NOT be used for web browsing. The Signing Service MUST run a regularly updated antivirus solution to scan the service for possible virus infection. The Signing Service MUST comply with the Network Security Guidelines as a "Delegated Third Party".
+The Signing Service MUST ensure that a Subscriber's Private Key is generated, stored, and used in a secure environment that has controls to prevent theft or misuse. A Signing Service MUST enforce multi-factor authentication or secure server-to-server authentication to access and authorize the signing of Application Code. The Signing Service MUST comply with the Network Security Guidelines.


I agree, we need more details on minimum requirements for secure server to server authentication. Let me ask our security team what we can recommend here.

timfromdigicert · 2023-02-28T16:13:56Z

docs/CSBR.md


-For Code Signing Certificates, Signing Services shall protect Private Keys in a Hardware Crypto Module conforming to at least FIPS 140-2 level 2 or Common Criteria EAL 4+.
+For Code Signing Certificates, Signing Services SHALL protect Private Keys in a Hardware Crypto Module conforming to at least FIPS 140-2 level 3 or Common Criteria EAL 4+.


DigiCert doesn't need an effective date, so we can either choose something harmless, or leave it out entirely.

…import)

…uirements

This reverts commit cca62c4.

CBonnell added 4 commits July 14, 2022 13:37

Fix typos

4af5f82

Prepare final copy assuming IPR review is clean

a39d3e0

Import of Word doc changes to Git

0ea86c9

Clarify that SSs are not DTPs in 8.1

3c24482

CBonnell force-pushed the improved-signing-services-requirements branch from 280b3de to 3c24482 Compare August 19, 2022 19:18

dzacharo reviewed Aug 25, 2022

View reviewed changes

XolphinMartijn reviewed Aug 25, 2022

View reviewed changes

dzacharo reviewed Nov 15, 2022

View reviewed changes

ianjmcm reviewed Nov 17, 2022

View reviewed changes

dzacharo reviewed Nov 28, 2022

View reviewed changes

alexanderregnier approved these changes Dec 17, 2022

View reviewed changes

Ivanyy5 approved these changes Dec 20, 2022

View reviewed changes

Update may to MAY

de62287

timfromdigicert reviewed Feb 28, 2023

View reviewed changes

DeanJC approved these changes Jul 31, 2023

View reviewed changes

CBonnell added 15 commits September 5, 2023 16:58

Merge branch 'main' into improved-signing-services-requirements

7f904ab

Integrate latest language from Bruce

49f51ab

"signing key" -> "Private Key" in 6.2.7.2

2efec60

MAY -> MUST for Signing Service Subscriber keypair gen (disallow key …

701d195

…import)

Restore EV guidelines version reference

877ba55

Capitalize "MUST NOT" (cabforum#19)

cca62c4

Assign ballot number, fix ballot name

50b40d4

Merge branch 'restore-evg-version' into improved-signing-services-req…

45ce24b

…uirements

Add "effective date" for Signing Service audit, tweak definition

b8dffbb

Fix 6.2.7.4.2 header

de7bced

Revert "Capitalize "MUST NOT" (cabforum#19)"

cf15a64

This reverts commit cca62c4.

Revert "Restore EV guidelines version reference" inclusion

1c0e711

Keep version number and revision history ambiguous to let Chair update

0d5ebf4

Merge branch 'main' into improved-signing-services-requirements

c23c205

Merge main

1a134a7

		@@ -961,6 +958,8 @@ Cryptographic algorithms, key sizes and certificate life-times for both authorit

		## 6.7 Network security controls

		The CA/Browser Forum’s Network and Certificate System Security Requirements are incorporated by reference as if fully set forth herein.

		@@ -1373,20 +1372,42 @@ As specified in BR Section 8.2.

		## 8.4 Topics covered by assessment


		1. Use of an HSM, verified by means of a manufacturer's certificate;
		1. Use of an HSM, verified by means of the FIPS or Common Criteria certificate; or

		@@ -91,6 +93,10 @@ If a Delegated Third Party fulfills any of the CA's obligations under [Section 4

		### 1.3.5 Other participants

		Signing Services MAY support generation of Subscriber Key Pair and maintain security of the Subscriber Private Key.

CSC-16: Improved signing services requirements #12

Are you sure you want to change the base?

CSC-16: Improved signing services requirements #12

Conversation

CBonnell commented Aug 19, 2022

dzacharo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dzacharo Dec 1, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dzacharo Dec 1, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Ivanyy5 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dzacharo Dec 1, 2022 •

edited

dzacharo Dec 1, 2022 •

edited