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

Wed Sep 13 09:38:07 UTC 2023

Makes sense. The CWG has the first say in its own Charter.

Thanks,
Dimitris.

On 13/9/2023 12:11 μ.μ., Martijn Katerbarg wrote:
>
> 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> *On Behalf Of 
> *Dean Coclin via Cscwg-public
> *Sent:* Tuesday, September 5, 2023 10:15 AM
> *To:* Martijn Katerbarg <martijn.katerbarg at sectigo.com>; 
> cscwg-public at cabforum.org; Bruce Morton <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> *On Behalf Of 
> *Martijn Katerbarg via Cscwg-public
> *Sent:* Tuesday, September 5, 2023 11:47 AM
> *To:* Bruce Morton <bruce.morton at entrust.com>; 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>
> *Date: *Thursday, 31 August 2023 at 17:30
> *To: *Martijn Katerbarg <martijn.katerbarg at sectigo.com>, 
> cscwg-public at cabforum.org <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>
> *Sent:* Thursday, August 31, 2023 10:56 AM
> *To:* Bruce Morton <Bruce.Morton at entrust.com>; 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 
> <https://url.avanan.click/v2/___https:/github.com/cabforum/code-signing/compare/main...XolphinMartijn:code-signing:TSA_Changes?expand=1___.YXAzOmRpZ2ljZXJ0OmE6bzo0ZGY3NmNlYWMzMDA4N2ZkOWU0OWFjZmUwNzAxMWY3MTo2OjczZDc6N2JlZWYyZWRjNTU1ZTZmYmIxODIyMDZhNmU5NDY2YTY3ZTU2OTA2OWVhNDQ3YmNlNzVlZGQwY2U4MjdkYmJmMDpoOkY>
>
> 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>
> *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>
> *Sent:* Thursday, August 10, 2023 3:54 PM
> *To:* Bruce Morton <Bruce.Morton at entrust.com>; 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> *On Behalf Of 
> *Bruce Morton via Cscwg-public
> *Sent:* Friday, 21 July 2023 17:55
> *To:* 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/7d86ccef/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/7d86ccef/attachment-0001.jpg>