[cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time stamping

Thu Apr 29 14:52:25 UTC 2021

Maybe the use of Policy Identifiers is a good way to assert that your TSA
service complies with the CABF Code signing BRs, but that does not preclude
other uses?

From: Public <public-bounces at cabforum.org> On Behalf Of Rob Stradling via
Public
Sent: Thursday, April 29, 2021 10:36 AM
To: public at cabforum.org; Sebastian Schulz <sebastian.schulz at globalsign.com>
Subject: Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time
stamping

> I don't think the creation of another WG would be justified or useful

Practically, that may well be the case, but I think it's right to arrive at
that conclusion by going through this thought process rather than
circumventing it.

> I don't see an issue with the CS WG defining requirements for timestamping
as long as it's very clear that this is ONLY for timestamping used with
CodeSigning certificates so that is no violation of the scope of the WG.

Policing "ONLY for timestamping used with CodeSigning certificates" seems
like it would be hard.  A timestamping server has no idea whether it's being
asked to timestamp signed code or some other "datum" (to quote RFC3161).

Sectigo's publicly-trusted RFC3161 timestamping service (and the
timestamping certificates that it uses) is expected to be used in
conjunction with both Code Signing and Document Signing.

  _____  

From: Public <public-bounces at cabforum.org> on behalf of Sebastian Schulz via
Public <public at cabforum.org>
Sent: 29 April 2021 11:03
To: public at cabforum.org <public at cabforum.org>
Subject: Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time
stamping 

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 can't think of anything else except proprietary systems that use
timestamping in for example Supply Chain Management and rely on CA issued
timestamps due to the complexity of Enterprises building on-premise TSAs.

When it comes to Adobe, they also trust other, non-qualified timestamps:

"When a Time Stamping Authority is imposed or recommended to the signers by
the Member, it must follow state of the art security policies and provide
proper timestamps. The time-stamping practices and policies must be provided
to Adobe and Adobe reserve the right to not accept the Time Stamping
Authority." From AATL TR v2.0 EE3

I'm not generally opposed, but all in all I don't think the creation of
another WG would be justified or useful, other major use cases of
timestamping have their major stakeholders outside the CA/B Forum.  I don't
see an issue with the CS WG defining requirements for timestamping as long
as it's very clear that this is ONLY for timestamping used with CodeSigning
certificates so that is no violation of the scope of the WG. But I can see
how opinions differ. Maybe an item to discuss on the next F2F?

Best,

Seb

Sebastian Schulz
Product Manager Client Certificates

From: Public <public-bounces at cabforum.org> On Behalf Of Adriano Santoni via
Public
Sent: 29 April 2021 11:42
To: public at cabforum.org
Subject: Re: [cabfpub] [Cscwg-public] [EXTERNAL] Re: Code signing and Time
stamping

Well, considering that Adobe is not currently a CABF member, I see no
context wherein time stamping plays a role, other than code signing.

Adobe already trusts qualified time stamping providers (according to EU
regulations) based on the EU trust lists, in the context of Document
Signing, and I am not aware that they may want to also trust time stamps
based on different criteria.

In theory, time stamping could be used to extend the validity of an S/MIME
signature beyond the signing certificate's expiration, but there is no
S/MIME client supporting this, and no plans to support it in the future, so
this is just theory. After all, S/MIME signatures are not meant for the
long-term.

Is there any other context that I am overlooking?

Adriano

Il 29/04/2021 11:07, Rob Stradling via Public ha scritto:

Could it be argued, at least conceptually, that there should be a separate
CABForum working group dedicated entirely to Time Stamping?  After all, the
Code Signing ecosystem doesn't have a monopoly on Time Stamping.  For
example, Adobe software uses Time Stamping in the context of Document
Signing.  If Adobe wanted to collaborate with CABForum members on Time
Stamping certificate profiles, what (assuming Adobe had no interest in Code
Signing) would be the best venue for that?

(Please note: I'm not advocating any position here; I'm just thinking
aloud).

  _____  

From: Cscwg-public  <mailto:cscwg-public-bounces at cabforum.org>
<cscwg-public-bounces at cabforum.org> on behalf of Bruce Morton via
Cscwg-public  <mailto:cscwg-public at cabforum.org> <cscwg-public at cabforum.org>
Sent: 26 April 2021 14:18
To: Ben Wilson  <mailto:bwilson at mozilla.com> <bwilson at mozilla.com>;
cscwg-public at cabforum.org <mailto:cscwg-public at cabforum.org>
<mailto:cscwg-public at cabforum.org> <cscwg-public at cabforum.org>; Dean Coclin
<mailto:dean.coclin at digicert.com> <dean.coclin at digicert.com>; CA/Browser
Forum Public Discussion List  <mailto:public at cabforum.org>
<public at cabforum.org>
Subject: Re: [Cscwg-public] [EXTERNAL] Re: [cabfpub] Code signing and Time
stamping 

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.

To follow up, the CSCWG charter includes the following documents:

a. EV Code Signing Guidelines, v. 1.4 and subsequent versions

b. Version 1.0 Draft of November 19, 2015, Baseline Requirements for the
Issuance and Management of Publicly-Trusted Code Signing Certificates
(subject to the CSCWG making a written finding that the provenance of such
document is sufficiently covered by the Forum's IPR Policy)

The documents define requirements or reference: timestamp authority (TSA),
timestamps, timestamp implementation method, timestamp certificate,
timestamp signed objects, TSA logging, and timestamp key protection. The
documents also define the certificate profiles for timestamp root, timestamp
subordinate CA and timestamp authority. As such, the CSCWG has considered it
is in scope to manage these documents and the requirements associated to
allow timestamp signatures with code signed using certificates conforming to
the CSBRs.

The CSBRs also state, "CAs complying with these Requirements MAY also assert
the reserved policy OIDs in such Certificates." The reserved policy OIDs
reference those required for Non-EV and EV code signing certificates. The
CSBRs do not reference an OID for a timestamp certificate, since the OID has
not been reserved. It is also considered appropriate to use all applicable
reserved certificate policy OIDs as we consider deploying dedicated PKI
hierarchies to support code signing.

As such, the CSCWG plans to add the following reserved certificate policy
OID to the CSBRs, which may be included in a timestamp certificate, which
meets the requirements of the CSBRs:

{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140)
certificate-policies(1) code-signing-requirements(4) timestamping(2)}
(2.23.140.1.4.2)

Bruce.

From: Cscwg-public  <mailto:cscwg-public-bounces at cabforum.org>
<cscwg-public-bounces at cabforum.org> On Behalf Of Ben Wilson via Cscwg-public
Sent: Tuesday, April 20, 2021 12:09 PM
To: Dean Coclin  <mailto:dean.coclin at digicert.com>
<dean.coclin at digicert.com>; CA/Browser Forum Public Discussion List
<mailto:public at cabforum.org> <public at cabforum.org>
Cc: cscwg-public at cabforum.org
Subject: [EXTERNAL] Re: [Cscwg-public] [cabfpub] Code signing and Time
stamping

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the
content is safe.

  _____  

Just a few thoughts to move this conversation forward, and speaking as a
CSCWG interested party and not to advocate any position of Mozilla, I think
the answer depends on how strict or flexible the CABF wants to be as an
organization when it comes to interpreting the scope of a working group
charter.

It seems that the mention of time stamping in a code signing work product
would be allowed even under a strict interpretation.  While creating
standards for issuing and managing time stamping certificates would
certainly be out of scope with a flexible interpretation. 

The Scope in the Charter does not expressly include or exclude the
assignment of a time stamping OID for time stamping certificates.

https://cabforum.org/2019/03/26/code-signing-certificate-wg-charter/#1-Scope

Included in the scope is "Version 1.0 Draft of November 19, 2015, Baseline
Requirements for the Issuance and Management of Publicly-Trusted Code
Signing Certificates (subject to the CSCWG making a written finding that the
provenance of such document is sufficiently covered by the Forum's IPR
Policy)."  Time stamping was discussed in that draft, and I recall that the
CSCWG did make the required written finding of provenance.  Is the
assignment of a timestamping OID a logical outcome of the continued work on
that earlier document?

Ben

On Mon, Apr 19, 2021 at 2:31 PM Dean Coclin via Public <public at cabforum.org
<mailto:public at cabforum.org> > wrote:

A discussion on last week's CA/B call about code signing and time stamping
brought up a question as to whether the latter was in scope of the CSCWG
charter
(https://cabforum.org/2019/03/26/code-signing-certificate-wg-charter/). 

Bruce said there was no CP OID for time stamping and that the group wanted
to create one IAW with the CA/B Forum registry. Ryan was concerned that this
was outside the CSCWG charter as it was not specifically mentioned therein.
Dimitris commented that it was included in charter scope 1a which pulls in
the EV CS guidelines where time stamping is specified. Ryan did not seem
convinced and asked that the discussion continue on the list. 

The working group has not had a chance to discuss this since the Forum
meeting but plans to do so on the next call. 

I've included the CS Public list on this thread since the topic is of
interest to members/observers there. If a respondent does not have posting
rights, I can re-post for them.

Dean

_______________________________________________
Public mailing list
Public at cabforum.org <mailto:Public at cabforum.org> 
https://lists.cabforum.org/mailman/listinfo/public

_______________________________________________
Public mailing list
Public at cabforum.org <mailto:Public at cabforum.org> 
https://lists.cabforum.org/mailman/listinfo/public
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cab
forum.org%2Fmailman%2Flistinfo%2Fpublic&data=04%7C01%7C%7Ca7396462b9ad4cd10f
7208d90af6103c%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C6375528749499146
59%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
WwiLCJXVCI6Mn0%3D%7C2000&sdata=iGPrVmi56%2BLDj2lcVpxIx3198EfxV66PuQeujATQBAs
%3D&reserved=0> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20210429/50bb733f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 8424 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20210429/50bb733f/attachment-0001.p7s>