<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>I actually considered scoping it to a particular EKU, and forcing code-signing certificates to only be for code signing. I might actually do that. I’m not a fan of the Swiss Army Knife certificates that are so common in the Web PKI (I remember one of my first reactions when looking inside a Web PKI certificate was “WTF is this client EKU doing in here?”). I’d like to hear what other code-signing CAs think about that.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The problem of who is a Certificate Consumer for code signing is also an interesting question I had. If Tim’s Homebrew Code Signature Verifier App has one user, am I a Certificate Consumer?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The only thing I can think of is having something vague like “produces widely used software that verifies code integrity and authorship by validating digital signatures created using certificates issued by Certificate Issuers” and have the Working Group police itself as far as what “widely used” means. We already have a similar issue with “Tim’s ‘Totally Not Chrome’ Fork Of Chrome With A Few Small Changes” giving Tim CABF voting rights as a browser, but somehow the world hasn’t ended. Yet.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It’s also a reason why I think “One Organization, One Vote” like most other standards bodies is probably a better voting model, instead of the two class model we have in the Server Certificate WG. But I’m interested in hearing what other code-signing CAs and companies that are interested in participating as “Certificate Consumers” think.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-Tim<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Ryan Sleevi [mailto:sleevi@google.com] <br><b>Sent:</b> Tuesday, April 24, 2018 11:14 AM<br><b>To:</b> Tim Hollebeek <tim.hollebeek@digicert.com>; CA/Browser Forum Public Discussion List <public@cabforum.org><br><b>Subject:</b> Re: [cabfpub] For Discussion: Code Signing Working Group Charter<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Tue, Apr 24, 2018 at 11:04 AM, Tim Hollebeek via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>A rough first draft, based on text I blatantly stole from the Server Certificate Working Group Charter:<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Code Signing Working Group Charter<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>SCOPE: The authorized scope of the Code Signing Working Group shall be as follows: <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>3. To develop requirements for time stamping certificates and time stamping servers intended to be used in conjunction with code signing certificates.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>4. To perform such other activities that are ancillary to the primary activities listed above. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Anticipated End Date: None. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Initial chairs and contacts: TBD [4]<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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: <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>(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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>(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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>(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). <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Summary of the work that the WG plans to accomplish: As specified in Scope section above. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Summary of major WG deliverables and guidelines: As specified in Scope section above. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Primary means of communication: listserv-based email, periodic calls, and face-to-face meetings. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>IPR Policy: The CA/Browser Forum Intellectual Rights Policy, v. 1.3 or later, SHALL apply to all Working Group activity.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>[1] Not a defined term in the Bylaws, so these are the Code Signing BRs, not the Server Certificate BRs.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>[2] These would be intended to initially be the EV Code Signing Requirements, from two years ago.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>[3] It is anticipated these would be kept in sync with the same requirements adopted by the Server Certificate WG, whenever possible.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>[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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>[5] Do we want to keep this structure or change it?<o:p></o:p></p></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><br>_______________________________________________<br>Public mailing list<br><a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br><a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></p></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></body></html>