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

Tue Sep 5 14:15:12 UTC 2023

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
<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
<https://url.avanan.click/v2/___https:/github.com/cabforum/code-signing/comp
are/main...XolphinMartijn:code-signing:TSA_Changes?expand=1___.YXAzOmRpZ2ljZ
XJ0OmE6bzo0ZGY3NmNlYWMzMDA4N2ZkOWU0OWFjZmUwNzAxMWY3MTo2OjczZDc6N2JlZWYyZWRjN
TU1ZTZmYmIxODIyMDZhNmU5NDY2YTY3ZTU2OTA2OWVhNDQ3YmNlNzVlZGQwY2U4MjdkYmJmMDpoO
kY> 

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/20230905/4a2de0ac/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/20230905/4a2de0ac/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5197 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20230905/4a2de0ac/attachment-0001.p7s>