[cabfpub] Final Minutes of CA/B Forum Call April 15, 2021

[Dean Coclin via Public]

Here are the approved minutes of the subject call.

 

 

Attendees: Adrian Mueller (SwissSign), Ali Gholami (Telia), Ben Wilson
(Mozilla), Bruce Morton (Entrust), Chris Kemmerer (SSL.com), Clint Wilson
(Apple), Corey Bonnell (DigiCert), Curt Spann (Apple), David Kluge (Google),
Dean Coclin (Digicert), Dimitris Zacharopoulos (HARICA), Doug Beattie
(GlobalSign), Enrico Entschew (D-TRUST), Hazhar Ismail (MSC Trustgate),
Inaba Atsushi (GlobalSign), Inigo Barreira (Sectigo), Jeff Ward (CPA
Canada/WebTrust), Johnny Reading (GoDaddy), Jos Purvis (Cisco Systems),
Karina Sirota (Microsoft), Mads Henriksveen (Buypass AS), Michelle Coon
(OATI), Mike Reilly (Microsoft), Neil Dunbar (TrustCor Systems), Niko
Carpenter (SecureTrust), Patrick Nohe (GlobalSign), Paul van Brouwershaven
(Entrust), Pedro Fuentes (OISTE Foundation), Rebecca Kelley (Apple), Ryan
Sleevi (Google), Sebastian Schulz (GlobalSign), Stephen Davidson (Digicert),
Tadahiko Ito (SECOM Trust Systems), Tobias Josefowitz (Opera Software AS),
Wayne Thayer (Mozilla), Wendy Brown (US Federal PKI Management Authority)

 

1. Anti-Trust statement was read

2. The Agenda was reviewed

3. Minutes of the last call were approved. Still awaiting minutes from March
15th call. Karina said she would finish them.

4. Forum Infrastructure working group: Jos gave the update:

*   Discussions on what's left to do to update github. Now with the
passing of SC41, changes will be made to update the old infrastructure. 
*   Some changes were requested from validation subgroup on cert profile
updates (look and feel). A style guide is being worked for producing
documents including a markdown linter. 
*   A docker image method was also being worked. 
*   SMTP is being setup to forward updates from github to the various
lists. 
*   Issues section being added for submission of issues to CA/B Forum. 
*   The website is still being hosted on GoDaddy on WordPress. Working
on getting a clone setup for testing. 
*   Discussed archiving older content (old ballots, minutes, media
files) and staticly linking them to the website. 
*   Membership management-new spreadsheet being created. New CA/B Forum
level google account established which can own documents for CA/B Forum,
helpful for transition to new chairs. 

5. Code Signing working group update: Bruce gave the update:

*   Intel will become an Interested Party
*   CSCWG-8 has passed and in IPR review.
*   Cleanup ballot in progress on some open items
*   Discussions from F2F on dedicated roots
*   Current requirements for test sites points to SSL BRs which doesn't
make sense for code signing
*   Discussion on Common Criteria and HSM requirements for code
signing/timestamping
*   CP OIDs: There is no CP OID for a timestamping cert. Would like to
create one. Ryan asked if this is within the scope of the charter. Bruce
said that codesigning does issue timestamps and would like to connect to the
TS OID in order to comply to a CA/B Forum document. Ryan said he was
concerned if the WG is adopting something out of the scope of the charter
and suggested that someone propose to the forum the addition of this task,
if properly scoped. Dean said that the group would need to look at that.
Dimitris thought that this was added as part of 1a in the charter. This
states that the requirements for EV CS include timestamping and hence are
grandfathered. It's just a logical next step of something already updates.
Ryan suggested we continue on the list. There had been discussion in
Infrastructure WG to clean up our OID registry
(https://cabforum.org/object-registry/). Dean will put this on the agenda
for the CSWG. 

6. S/MIME working group update: Stephen gave the update:

*   Discussion on reusing the Audit section (8) from the TLS Baseline
Requirements. Question on acceptable audit criteria 8.4, govt audits: will
this option still be acceptable to root stores?
*   Discussion on reusing Net Sec requirements
*   Everything is in github repository for review. Looking for feedback
*   Algorithms from TLS BRs moved over to SMIME

7. Any other business: None

8. Next call: April 29th

Adjourned



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

[cabfpub] Using OV TLS server certificate as TLS client certificates only

[Stefan Santesson via Public]

Hi,

I would really appreciate this lists opinion on a matter being discussed
in the EU ongoing effort with establishing a Digital Green Certificate
(DGC) for Covid-19 vaccination and test results.

The time is very short as things must be in production in June.


The issue is:

The EU key exchange service (The DGC Gateway) will allow EU member
states to uppload their DGC signing certificates for sharing among EU
countries.

Each country uploading DGC signing certificates must then have a TLS
client certificate when connecting to the DGC Gateway.

So far so good.

However, today it was announced that this TLS client certificate MUST be
a Organization Validation (OV) certificate issued by a public CA
supported by current browsers.

Now, this is problematic, since the TLS client certificate is being used
by a backend application that is NOT acting as a TLS server. So in order
to get an OV certificate as TLS client certificate I simply need to either:

1) Make a copy of the private key installed in our web server and re-use
that key/certificate in my backend application as TLS client cert. Or:

2) Apply for a separate TLS Server certificate to be used as TLS client
certificate. However the backend application server will NOT act as a
TSL server and is not bound to any domain name (just an IP address for
outbound connections).


My guess is that both these alternatives must be some kind of violation
against CAB policy for TLS server certificates.

Am I right or wrong here?

This is quite urgent, If this is bad and we want to prevent this, I need
help with good arguments now.


Thanks a lot for reading and providing feedback!


/Stefan Santesson

___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Delivery test -- Please ignore

[Jos Purvis (jopurvis) via Public]

Second test

 

 

-- 
Jos Purvis (jopur...@cisco.com)
.:|:.:|:. cisco systems | Cryptographic Services
PGP: 0xFD802FEE07D19105 | Controls and Trust Verification

 

 

From: Public  on behalf of CA/B Forum Public List 

Reply-To: "Jos Purvis (jopurvis)" , CA/B Forum Public List 

Date: Thursday, 29 April, 2021 at 12:47
To: CA/B Forum Public List 
Subject: [cabfpub] Delivery test -- Please ignore

 

Testing delivery through SES.

 

 

-- 
Jos Purvis (jopur...@cisco.com)
.:|:.:|:. cisco systems | Cryptographic Services
PGP: 0xFD802FEE07D19105 | Controls and Trust Verification

 



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

[cabfpub] Delivery test -- Please ignore

[Jos Purvis (jopurvis) via Public]

Testing delivery through SES.

 

 

-- 
Jos Purvis (jopur...@cisco.com)
.:|:.:|:. cisco systems | Cryptographic Services
PGP: 0xFD802FEE07D19105 | Controls and Trust Verification

 



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

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

[Doug Beattie via Public]

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  On Behalf Of Rob Stradling via
Public
Sent: Thursday, April 29, 2021 10:36 AM
To: public@cabforum.org; Sebastian Schulz 
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  on behalf of Sebastian Schulz via
Public 
Sent: 29 April 2021 11:03
To: public@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  On Behalf Of Adriano Santoni via
Public
Sent: 29 April 2021 11:42
To: public@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  
 on behalf of Bruce Morton via
Cscwg-public   
Sent: 26 April 2021 14:18
To: Ben Wilson   ;
cscwg-pub...@cabforum.org 
 ; Dean Coclin
 ; CA/Browser
Forum Public Discussion List  

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

 

CAUTION: This email 

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

[Ryan Sleevi via Public]

On Thu, Apr 29, 2021 at 10:36 AM Rob Stradling via Public <
public@cabforum.org> wrote:

> > 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.
>

Indeed Rob, I think this gets to the heart of the concern.

If the CSC WG is expecting that CAs will stand up separate EVCS
Timestamping services, exclusively to be used for code signing (which
cannot be enforced by the TSA), from a separate hierarchy, then at least we
should be clear about that.

The fundamental issue here is that the references to timestamping appear to
be implementation/policy-specific to a particular implementor, rather than
generalized regarding code signing. I appreciate the challenge here (code
outliving the code signing certificate), and I can understand the rationale
for wanting to address it, but it fundamentally feels like an attempt to
scope an entirely unrelated service, which has no **defined** interaction,
and which fundamentally is a matter of Relying Party policy.

It seems the CSC WG should define how the CS *certificates* work, and the
broader question about how code signing is conveyed (e.g. PKCS#7/CMS, ZIP
files, bespoke vendor format - all of which are practically deployed
today), or how those *certificates* are authenticated after their useful
lifetime, is really a question for root program policies, in the absence of
industry norms. And there could be opportunity here for something. However,
if the CSC WG is determined to have this scoped within its charter, which
is still something highlighted previously as problematic, then it really is
and must simply be scoped to CS, and that's fundamentally saying a new,
separate trust hierarchy "should" be established.

We previously discussed, during the chartering of the S/MIME WG, exactly
this issue (the need for a separate WG), due to the attempts to conflate
S/MIME WG with document signing, since they both may choose to use legal
identities in addition to or in lieu of technical identities (like an email
address). This was the major blocker to getting the S/MIME charter
approved, but we managed to eventually do so by making it clear document
signing (and the related support services, including timestamping) are out
of scope of S/MIME.
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

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

[Rob Stradling via Public]

> 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  on behalf of Sebastian Schulz via 
Public 
Sent: 29 April 2021 11:03
To: public@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  On Behalf Of Adriano Santoni via 
Public
Sent: 29 April 2021 11:42
To: public@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 
 
on behalf of Bruce Morton via Cscwg-public 

Sent: 26 April 2021 14:18
To: Ben Wilson ; 
cscwg-pub...@cabforum.org 
; Dean Coclin 
; CA/Browser Forum 
Public Discussion List 
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 

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

[Sebastian Schulz via Public]

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  On Behalf Of Adriano Santoni via
Public
Sent: 29 April 2021 11:42
To: public@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  
 on behalf of Bruce Morton via
Cscwg-public   
Sent: 26 April 2021 14:18
To: Ben Wilson   ;
cscwg-pub...@cabforum.org 
 ; Dean Coclin
 ; CA/Browser
Forum Public Discussion List  

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 

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

[Adriano Santoni via Public]

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  on behalf of 
Bruce Morton via Cscwg-public 

*Sent:* 26 April 2021 14:18
*To:* Ben Wilson ; cscwg-pub...@cabforum.org 
; Dean Coclin ; 
CA/Browser Forum Public Discussion List 
*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  *On Behalf Of 
* Ben Wilson via Cscwg-public

*Sent:* Tuesday, April 20, 2021 12:09 PM
*To:* Dean Coclin ; CA/Browser Forum Public 
Discussion List 

*Cc:* cscwg-pub...@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.

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

[Rob Stradling via Public]

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  on behalf of Bruce 
Morton via Cscwg-public 
Sent: 26 April 2021 14:18
To: Ben Wilson ; cscwg-pub...@cabforum.org 
; Dean Coclin ; CA/Browser 
Forum Public Discussion List 
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  On Behalf Of Ben Wilson 
via Cscwg-public
Sent: Tuesday, April 20, 2021 12:09 PM
To: Dean Coclin ; CA/Browser Forum Public Discussion 
List 
Cc: cscwg-pub...@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