[cabfpub] For Discussion: Code Signing Working Group Charter

Thu May 3 11:36:51 MST 2018

Bruce, that's something I thought about as well.  Maybe have them be
combined for now, but split out timestamping if/when we have a document
signing WG?

I could go either way.  I just think a Time-stamp WG would be a lot of
effort and not very busy.  Maybe two documents as you said at the end is a
good strategy.

S/MIME is actually the next WG on my list once we get this charter sorted
out, but if someone else wants to circulate a draft document signing
charter, feel free.

As Virginia has repeatedly pointed out, it would be nice to have the
charters for the WGs we want sorted out so we can hit the ground running in
two months.

-Tim

From: Bruce Morton [mailto:Bruce.Morton at entrustdatacard.com] 
Sent: Thursday, May 3, 2018 2:21 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>; CA/Browser Forum Public
Discussion List <public at cabforum.org>
Subject: RE: For Discussion: Code Signing Working Group Charter

Hi Tim,

Although we combined Code Signing and Time-stamping certificates into the
Minimum Requirements for Code Signing document, I'm thinking that they
should not be combined in the Code Signing Working Group. First there may be
IP scope issues similar to when we wanted to combine both SSL and Code
Signing. Also Time-stamping certificates are used for other applications
such as Document Signing (e.g., AATL certificates) or a Time-stamping
certificate may be issued for another application.

Would it be better to create a Time-stamping Working Group? We could create
a Time-stamp guideline based on the information already documented in the
Minimum Requirements for Code Signing. The Code Signing document could refer
to the Time-stamp document, but it will also make the Time-stamp document
available for other uses.

An alternative would be that the Code Signing working group creates the
Time-stamp document. Then it could be picked up later by a new working group
to manage. This alternative does not address IP scope issues.

Thanks, Bruce.

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Tim Hollebeek
via Public
Sent: April 24, 2018 11:04 AM
To: CA/Browser Forum Public Discussion List <public at cabforum.org
<mailto:public at cabforum.org> >
Subject: [EXTERNAL][cabfpub] For Discussion: Code Signing Working Group
Charter

A rough first draft, based on text I blatantly stole from the Server
Certificate Working Group Charter:

Code Signing Working Group Charter

Upon approval of the CAB Forum by ballot, the Code Signing Working Group
("Working Group") is created to perform the activities as specified in this
Charter, subject to the terms and conditions of the CA/Browser Forum Bylaws
and Intellectual Property Rights (IPR) Policy, as such documents may change
from time to time. The definitions found in the Forum's Bylaws shall apply
to capitalized terms in this Charter. 

SCOPE: The authorized scope of the Code Signing Working Group shall be as
follows: 

1. To specify Code Signing Baseline Requirements [1], Extended Validation
Guidelines [2], Network and Certificate System Security Requirements [3],
and other acceptable practices for the issuance and management of code
signing certificates used to sign executables, libraries, and apps. 

2. To update such requirements and guidelines from time to time, in order to
address both existing and emerging threats, including responsibility for the
maintenance of and future amendments to the current Code Signing Baseline
Requirements, Extended Validation Requirements, and Network and Certificate
System Security Requirements. 

3. To develop requirements for time stamping certificates and time stamping
servers intended to be used in conjunction with code signing certificates.

4. To perform such other activities that are ancillary to the primary
activities listed above. 

OUT OF SCOPE: The Code Signing Working Group will not address certificates
intended to be used primarily for client or server authentication, S/MIME,
VoIP, IM, or Web services. The Code Signing Working Group will not address
the issuance, or management of certificates by enterprises that operate
their own Public Key Infrastructure for internal purposes only, and for
which the Root Certificate is not distributed by any Application Software
Supplier. 

Anticipated End Date: None. 

Initial chairs and contacts: TBD [4]

Members eligible to participate: The Working Group shall consist of two
classes of voting members [5], the Certificate Issuers and the Certificate
Consumers. The CA Class shall consist of eligible Certificate Issuers and
Root Certificate Issuers meeting the following criteria: 

(1) Certificate Issuer: The member organization operates a certification
authority that has a current and successful WebTrust for CAs audit, or ETSI
TS 102042, ETSI 101456, or ETSI EN 319 411-1 audit report prepared by a
properly-qualified auditor, and that actively issues code-signing
certificates, such certificates being treated as valid when verified by
software from a Certificate Consumer Member. Applicants that are not
actively issuing certificates but otherwise meet membership criteria 7 may
be granted Associate Member status under Bylaw Sec. 3.1 for a period of time
to be designated by the Forum. 

(2) Root Certificate Issuer: The member organization operates a
certification authority that has a current and successful WebTrust for CAs,
or ETSI TS 102042, ETSI TS 101456, ETSI EN 319 411-1 audit report prepared
by a properly-qualified auditor, and that actively issues code-signing
certificates to subordinate CAs that, in turn, actively issue code-signing
certificates, such certificates being treated as valid when verified by
software from a Certificate Consumer Member. Applicants that are not
actively issuing certificates but otherwise meet membership criteria may be
granted Associate Member status under Bylaw Sec. 3.1 for a period of time to
be designated by the Forum. 

(3) A Certificate Consumer can participate in this Working Group if it
produces a software product intended for use by the general public that can
validate and execute signed code. The Working Group shall include Interested
Parties and Associate Members as defined in the Bylaws. Voting structure
[5]: In order for a ballot to be adopted by the Working Group, two-thirds or
more of the votes cast by the Certificate Issuers must be in favor of the
ballot and more than 50% of the votes cast by the Certificate Consumers must
be in favor of the ballot. At least one member of each class must vote in
favor of a ballot for it to be adopted. Quorum is the average number of
Member organizations (cumulative, regardless of Class) that have
participated in the previous three Code Signing Working Group Meetings or
Teleconferences (not counting subcommittee meetings thereof). If three
meetings have not yet occurred, quorum is ten (10). 

Summary of the work that the WG plans to accomplish: As specified in Scope
section above. 

Summary of major WG deliverables and guidelines: As specified in Scope
section above. 

Primary means of communication: listserv-based email, periodic calls, and
face-to-face meetings. 

IPR Policy: The CA/Browser Forum Intellectual Rights Policy, v. 1.3 or
later, SHALL apply to all Working Group activity.

[1] Not a defined term in the Bylaws, so these are the Code Signing BRs, not
the Server Certificate BRs.

[2] These would be intended to initially be the EV Code Signing
Requirements, from two years ago.

[3] It is anticipated these would be kept in sync with the same requirements
adopted by the Server Certificate WG, whenever possible.

[4] I'd actually like this to be the first topic for the WG to discuss,
though I could be convinced we should pick one in advance.

[5] Do we want to keep this structure or change it?

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