[cabfpub] For Discussion: Code Signing Working Group Charter

[Ryan Sleevi]

Given that the id-kp-codeSigning EKU is a context-dependent, and given that
only one software vendor has ever participated in such a WG, does it make
sense to either scope the activities of the WG to a defined product subset
- or to a defined EKU? Alternatively, should there be a minimum amount of
distinct and interoperable Certificate Consumers before undertaking such
the work? This is far more relevant to code signing than any other of the
recognized key usages - by definition, code-signing is specific to the
platform(s) that execute that code, and these platforms are fundamentally
incompatible.

On Tue, Apr 24, 2018 at 11:04 AM, Tim Hollebeek via Public <
public at cabforum.org> wrote:

>
>
> 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?
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20180424/d70b5465/attachment.html>