[Cscwg-public] [External Sender] Re: [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection

Mon Apr 22 08:17:58 UTC 2024

All, 

Based on our discussion from last week, I’ve updated the proposed language. 

Please review the new commit, located at https://github.com/cabforum/code-signing/pull/34/commits/61d9426e9025d448a13eb56fa75b9651b2136548 <https://github.com/cabforum/code-signing/pull/34/commits/61d9426e9025d448a13eb56fa75b9651b2136548> and let me know if there are any further concerns blocking this ballot from moving forward. 

From: Cscwg-public <cscwg-public-bounces at cabforum.org> on behalf of Martijn Katerbarg via Cscwg-public <cscwg-public at cabforum.org>
Date: Tuesday, 16 April 2024 at 12:06
To: Adriano Santoni <adriano.santoni at staff.aruba.it>, cscwg-public at cabforum.org <cscwg-public at cabforum.org>, Christophe Bonjean <christophe.bonjean at globalsign.com>
Subject: Re: [Cscwg-public] [External Sender] Re: [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection 

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 Christophe, Adriano,

Thank you for the comments. 

I kind of think this may be a slight mismatch between what’s listed as the purpose of the ballot, vs the language included in the redline. However, I’m not sure I agree with your solution:

> I would recommend to scope this change to Private Keys generated after the effective date, instead of linking it to the issuing date of the Subordinate CA Certificate for those keys. 

> For example if a CA issues a new Subordinate CA Certificate after this date, with an existing Private Key, then the related Private Key would need to be moved to an offline state. I think the intention is only for new keys to follow this requirement. 

Am I understanding correctly that you’re proposing that if CAs issue a new SubCA after the effective date using a key already in existance, you want them to keep using that CA in an online state? 

If so, that kindof defeats the purpose of this ballot. CA’s may have loads of parked private keys in their online HSMs, meaning if we scope it to when a key was generated, they could keep issuing new SubCAs for timestamping for many years to come in an online state. 

Instead, I think we could restate the purpose of the ballot to make it a bit more clear if we feel that may help, as:
1. Require Private Keys associated with newly issued Timestamp Authority Subordinate CA to be stored in offline HSMs 
2. Add a requirement to remove Private Keys associated with Timestamp Certificates after a 18 months 
3. Add a requirement to reject SHA-1 timestamp requests 

Thoughts?

(If so, I wonder, since the redline doesn’t change, only the ballot description, does it need a new ballot version?)

Regards,

Martijn 

From: Cscwg-public <cscwg-public-bounces at cabforum.org> on behalf of Adriano Santoni via Cscwg-public <cscwg-public at cabforum.org>
Date: Tuesday, 16 April 2024 at 08:35
To: cscwg-public at cabforum.org <cscwg-public at cabforum.org>
Subject: Re: [Cscwg-public] [External Sender] Re: [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection 

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. 

I concur with Christophe. 
Adriano 

Il 12/04/2024 16:30, Christophe Bonjean via Cscwg-public ha scritto: 

Hi Martijn, 

Looking at the purpose of the ballot, the goal is to require newly issued [..] Private Keys to be stored in offline HSMs. 

The proposed change scopes this change to [keys related to] Root CA certificates and new Subordinate CA certificates 

I would recommend to scope this change to Private Keys generated after the effective date, instead of linking it to the issuing date of the Subordinate CA Certificate for those keys. 

For example if a CA issues a new Subordinate CA Certificate after this date, with an existing Private Key, then the related Private Key would need to be moved to an offline state. I think the intention is only for new keys to follow this requirement. 

Christophe 

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: Monday, April 8, 2024 9:32 AM
To: cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org>
Subject: [Cscwg-public] [Discussion Period Begins] CSC-24 (v2): Timestamping Private Key Protection 

Purpose of the Ballot 
This ballot updates the “Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates“ version 3.7 in order to clarify language regarding Timestamp Authority Private Key Protection. The main goals of this ballot are to: 

1. Require newly issued Timestamp Authority Subordinate CA Private Keys to be stored in offline HSMs 
2. Add a requirement to remove Private Keys associated with Timestamp Certificates after a 18 months 
3. Add a requirement to reject SHA-1 timestamp requests 
The following motion has been proposed by Martijn Katerbarg of Sectigo and endorsed by Bruce Morton of Entrust and Ian McMillan of Microsoft. 
MOTION BEGINS 
This ballot updates the “Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates” ("Code Signing Baseline Requirements") based on version 3.7. MODIFY the Code Signing Baseline Requirements as specified in the following redline: https://github.com/cabforum/code-signing/compare/d431d9104094f2b89f35ed4bf1d64b9a844e762b...84e8586846a0c836d5bccbe9ef74593358c5b421 <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fcode-signing%2Fcompare%2Fd431d9104094f2b89f35ed4bf1d64b9a844e762b...84e8586846a0c836d5bccbe9ef74593358c5b421&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Cd587b32400694fc851b208dc5dfcefcc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638488588150515702%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=kMkg3KUAWvdi8emTbzyKjj7CKIG1ksE5LfchqQ20E1I%3D&reserved=0> 
MOTION ENDS 
The procedure for this ballot is as follows: 
Discussion (7 days) 

* Start Time: 2024-04-08 09:00 UTC 
* End Time: Not before 2024-04-15 17:00 UTC 
Vote for approval (7 days) 

* Start Time: TBD 
* End Time: TBD 

_______________________________________________ Cscwg-public mailing list Cscwg-public at cabforum.org <mailto:Cscwg-public at cabforum.org> https://lists.cabforum.org/mailman/listinfo/cscwg-public <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fcscwg-public&data=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Cd587b32400694fc851b208dc5dfcefcc%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638488588150528464%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=zyDreoAmB9RNLRIEgzI94cWdL6Dw%2B3N2eGgSihUuCDc%3D&reserved=0> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20240422/1fab5d92/attachment-0001.html>
-------------- 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/20240422/1fab5d92/attachment-0001.bin>