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

Wed Sep 13 09:11:14 UTC 2023

So while updating the charter really is something for the Forum level (ping @Dimitris Zacharopoulos (HARICA) <mailto:dzacharo at harica.gr>), I would be inclined to say that a first update draft could be floated in the CSWG mailing list for feedback. Any objections? 

I’ll start working on a draft update, and include changes to the voting structure language as well. 

Regards,

Martijn 

From: Dean Coclin <dean.coclin at digicert.com>
Date: Wednesday, 13 September 2023 at 10:14
To: Tim Hollebeek <tim.hollebeek at digicert.com>, cscwg-public at cabforum.org <cscwg-public at cabforum.org>, Martijn Katerbarg <martijn.katerbarg at sectigo.com>, Bruce Morton <bruce.morton at entrust.com>
Subject: RE: [Cscwg-public] Proposed Signing Service, High Risk and Timestamp Changes 

What “current timestamping BRs” are you referring to? 

As I said, timestamping strictly related to code signing should be in scope. 

Dean 

Dean Coclin 
Sr. Director Business Development 
M 1.781.789.8686 

From: Tim Hollebeek <tim.hollebeek at digicert.com> 
Sent: Tuesday, September 12, 2023 8:27 PM
To: Dean Coclin <dean.coclin at digicert.com>; cscwg-public at cabforum.org; Martijn Katerbarg <martijn.katerbarg at sectigo.com>; Bruce Morton <bruce.morton at entrust.com>
Subject: RE: [Cscwg-public] Proposed Signing Service, High Risk and Timestamp Changes 

This is just wrong, and Martijn was trying to say the opposite thing anyway: we should update the charter to explicitly state that timestamping is in scope. And I agree. 

The reason it can’t be true that timestamping is out of scope is because the current timestamping BRs have over 75+ references to timestamping! 

We’ve always considered timestamping to be in scope, because it’s an essential part of a secure code signing ecosystem. 

-Tim 

From: Cscwg-public <cscwg-public-bounces at cabforum.org <mailto:cscwg-public-bounces at cabforum.org>> On Behalf Of Dean Coclin via Cscwg-public
Sent: Tuesday, September 5, 2023 10:15 AM
To: Martijn Katerbarg <martijn.katerbarg at sectigo.com <mailto:martijn.katerbarg at sectigo.com>>; cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org>; Bruce Morton <bruce.morton at entrust.com <mailto:bruce.morton at entrust.com>>
Subject: Re: [Cscwg-public] Proposed Signing Service, High Risk and Timestamp Changes 

As has been pointed out many times, the charter of the CSCWG does not include timestamping. Hence anything related to that beyond Code Signing would require a change to the charter. 

Thanks for the point Martijn. 

Dean 

Dean Coclin 
Sr. Director Business Development 
M 1.781.789.8686 

From: Cscwg-public <cscwg-public-bounces at cabforum.org <mailto:cscwg-public-bounces at cabforum.org>> On Behalf Of Martijn Katerbarg via Cscwg-public
Sent: Tuesday, September 5, 2023 11:47 AM
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: Re: [Cscwg-public] Proposed Signing Service, High Risk and Timestamp Changes 

Hey Bruce, 

I’m inclined to say that even the removal of TSC Private Keys, is a new requirement. If we’re not explicitly saying that existing keys up until this point are excluded, then CA’s may need to remove a fair number of keys. If so, we may need to allow for a bit more time. 

That also brings me to another concern that popped up: 

We’re adding more restrictions around timestamp certificates. While these obviously are heavily used for code signing, they’re not used just for that purpose. 

With that in mind, I think at least in the next Forum level meeting, we should make all members aware of the proposed changes, since it will probably impact members that are not a member of the CSWG. Secondly, I’ve started to wonder if we need to get our charter updated to include the scope of timestamping certificates, and possibly allow members that do not issue code signing certificates but that still are a TSA. 

Regards,

Martijn 

From: Bruce Morton <Bruce.Morton at entrust.com <mailto:Bruce.Morton at entrust.com>>
Date: Thursday, 31 August 2023 at 17:30
To: Martijn Katerbarg <martijn.katerbarg at sectigo.com <mailto:martijn.katerbarg at sectigo.com>>, cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org> <cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org>>
Subject: RE: [Cscwg-public] Proposed Signing Service, High Risk and Timestamp Changes 

Hi Martijn, 

Thanks for the Github version! 

We should discuss which items need a future effective date. I assume the only issue is offline Subordinate CA. I would propose 15 September 2024. I don’t think there should be any impact to TSA certificates, since the private key can only be used for 15-months which is not changing. 

Bruce. 

From: Martijn Katerbarg <martijn.katerbarg at sectigo.com <mailto:martijn.katerbarg at sectigo.com>> 
Sent: Thursday, August 31, 2023 10:56 AM
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 

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 <Protected by Avanan: 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: 

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

     1. 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 <mailto:Bruce.Morton at entrust.com>> 
Sent: Wednesday, 16 August 2023 20:00
To: Martijn Katerbarg <martijn.katerbarg at sectigo.com <mailto:martijn.katerbarg at sectigo.com>>; cscwg-public at cabforum.org <mailto: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. 

1. Signing Service – based on the former proposal, plus updates based on the discussions 
2. 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. 
3. 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/20230913/2091d32f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 23699 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20230913/2091d32f/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 8254 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20230913/2091d32f/attachment-0001.bin>