[Cscwg-public] Proposed Signing Service, High Risk and Timestamp Changes

Thu Aug 31 14:56:01 UTC 2023

As discussed on the last call, I’ve moved the language into GitHub, which can be reviewed at https://github.com/cabforum/code-signing/compare/main...XolphinMartijn:code-signing:TSA_Changes?expand=1

In this, I’ve also added text on logging key removal and how to handle key recovery scenarios

It occurs to me that we’re missing two details on this item:

*	What kind of effective date are we looking to attach to this
*	What will apply to SubCAs and Timestamp Certificates that have already been issued. 

*	If we want the same logic to be applied, do we want to maybe give additional time for existing setups?

Thoughts?

Regards,

Martijn

From: Bruce Morton <Bruce.Morton at entrust.com> 
Sent: Wednesday, 16 August 2023 20:00
To: Martijn Katerbarg <martijn.katerbarg at sectigo.com>; cscwg-public at cabforum.org
Subject: RE: [Cscwg-public] Proposed Signing Service, High Risk and Timestamp Changes

Agreed with the change proposal.

Thanks, Bruce.

From: Martijn Katerbarg <martijn.katerbarg at sectigo.com <mailto:martijn.katerbarg at sectigo.com> > 
Sent: Thursday, August 10, 2023 3:54 PM
To: Bruce Morton <Bruce.Morton at entrust.com <mailto:Bruce.Morton at entrust.com> >; cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> 
Subject: [EXTERNAL] RE: [Cscwg-public] Proposed Signing Service, High Risk and Timestamp Changes

Thanks Bruce,

I’m going through the TSA changes, and one thing caught my eye:

Section 6.2.7.2 now reads:

A Timestamp Authority MUST protect its Private Key in offline Hardware Crypto Module conforming 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 and Certificate System Security Requirements.

The definition of “Timestamp Authority” (TSA) reads:

A service operated by the CA or a delegated third party for its own code signing certificate users that timestamps data using a certificate chained to a public root, thereby asserting that the data (or the data from which the data were derived via a secure hashing algorithm) existed at the specified time.

It seems to me that this change would imply that a TSA needs to keep all their private keys in offline HCMs, including private keys associated with timestamp certificates. I presume this language is intended to only apply to the private key associated with the TSA Root CA (and even the Subordinate CAs, as far as I understood during todays call) , but not to the private key associated with the Timestamp Certificate itself. 

Might I suggest updating this language to:

A Timestamp Authority MUST protect Private Keys associated with its Root CA and Subordinate CA certificates in offline Hardware Crypto Module conforming 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 and Certificate System Security Requirements.

Regards,

Martijn

From: Cscwg-public <cscwg-public-bounces at cabforum.org <mailto:cscwg-public-bounces at cabforum.org> > On Behalf Of Bruce Morton via Cscwg-public
Sent: Friday, 21 July 2023 17:55
To: cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> 
Subject: [Cscwg-public] Proposed Signing Service, High Risk and Timestamp Changes

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.

Based on the discussions we had at the June F2F, I have taken the opportunity to propose markups to derive Signing Service, High Risk and Timestamping ballots.

The base text is from the CSC-19 version of the CSBRs. There may be some conflicting markups or markups.

*	Signing Service – based on the former proposal, plus updates based on the discussions
*	High Risk – Removal of high risk and takeover attack, plus removed Subscriber key generation methods prior to 1 June 2023 and the text about delivering a software based private key. Also propose removing the “any other method” text.
*	Timestamping – Maintain allowing 15 month private key usage period and 135 month validity period, but requiring private keys to be destroyed within 18 months if the timestamp certificate was valid for more than 15 months. Stating that the HSM supporting the Time-stamp CA must be offline. Stating that the TSA must reject SHA-1 signed timestamp requests

Hoping this will help to clean up this text which we have been discussing for a period of time. These items are on the agenda for next week's meeting.

Thanks, Bruce.

Any email and files/attachments transmitted with it 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/20230831/57a9aad1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6807 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20230831/57a9aad1/attachment-0001.p7s>