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 < [email protected]> 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 > [email protected] > https://cabforum.org/mailman/listinfo/public > >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
