[cabfpub] Ballot 117 - EV Code Signing Guidelines Corrections

Ben Wilson ben at digicert.com
Mon Mar 24 09:20:09 MST 2014


Thanks, Rob.  The vote on Ballot 117 will likely pass unless a substantial
number of members change their vote within the next several hours to vote
against it.  I would not recommend that anyone do that.  Instead, I will add
this issue to the agenda for our next telephone call, and until then, we
should start a new thread on this topic.  Also, it would seem to me that the
Baseline Code Signing and EV Code Signing efforts present a lot of promising
opportunities to improve the security of software distributed on the
Internet.  Maybe the CS WG should discuss combining the two similar to what
has been done with the BRs and EVGs for SSL certificates?  I would like to
see more OS providers (both desktop and mobile) work with us, rather than
implement gated/walled gardens.  We've had many good ideas emerge from or
code-signing discussions, such as sandboxing applications before signing
them (e.g. https://www.team-cymru.com/Services/MalwareHawk/).  

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Rob Stradling
Sent: Monday, March 24, 2014 8:23 AM
To: Dean Coclin; ben at digicert.com; 'Moudrick M. Dadashov';
public at cabforum.org
Subject: Re: [cabfpub] Ballot 117 - EV Code Signing Guidelines Corrections

On 21/03/14 20:55, Dean Coclin wrote:
> I echo Ben and Inigo's comments,  except that I think Comodo is free 
> to express its opinion as is any other CA/B forum member at any time.
>
> My comments:
>
> > "EV Code Signing has been implemented by only a single vendor"
>
> Assuming you mean Microsoft, this is true, but there are only a 
> handful of platforms (Apple, Linux and maybe some mobile) so it's one 
> of only a small potential number.

Our concern is that there are zero open programs.

> > "only two CA participants in that vendor's program"
>
> CA's can choose to sell whatever they want. The fact that only 2 (your
> claim) have decided to so far is most likely a business decision.

If only this were true.

BTW, are you aware of any public source that disputes our figure of 2?

> Should the CA/B Forum also not support or discuss CT because only "a 
> single vendor" supports it and only a handful of companies want to
participate?

CT is not a CABForum work product.  The EV Code Signing Guidelines are.

> > "Comodo strongly supports the concept of EV Code Signing, and would 
> > very much like to see wider implementation and participation."
>
> Great, so how do you propose the CA/B Forum does this if we can't 
> implement and improve guidelines around that? How does that "restrain 
> competition"?

We don't think improving the EV Code Signing Guidelines will be enough to
cause EV Code Signing to thrive.

To truly become an open, industry standard, more CAs need to be permitted to
participate.

Closed programs are a fact of life, but they should not be a CABForum work
product.

> Dean
>
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] 
> On Behalf Of Ben Wilson
> Sent: Friday, March 21, 2014 3:09 PM
> To: 'Moudrick M. Dadashov'; 'Rob Stradling'; public at cabforum.org
> Subject: Re: [cabfpub] Ballot 117 - EV Code Signing Guidelines 
> Corrections
>
> Did Comodo object to / or vote against the EV Code Signing Guidelines 
> in the past?  If this is the first we've heard of this concern on code 
> signing, then my question is why should we hold up this vote, which 
> from my perspective has been presented as a very minor issue?  Why use 
> a hammer?  If this was merely a bow shot, then this issue needs to 
> take on its own independent form and be discussed as an entirely new 
> topic, and a new thread should be started.  If Comodo wants us to 
> examine our scope of action in greater depth, then I think it needs to 
> set forth its analysis separately in a detailed explanation.  Voting 
> started last Monday when the comment period ended, and my 
> understanding is that we generally try to refrain from presenting
arguments against when we are near the end of the voting period.
> That's my 2 cents.
>
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] 
> On Behalf Of Moudrick M. Dadashov
> Sent: Friday, March 21, 2014 12:39 PM
> To: Rob Stradling; ben at digicert.com; public at cabforum.org
> Subject: Re: [cabfpub] Ballot 117 - EV Code Signing Guidelines 
> Corrections
>
> Hi,
>
> I think Rob's comment raises potentially problematic practice.
>
> I'm not sure about the voting procedure, but I'd suggest we find some 
> ways to discuss these issues before the end of voting period.
>
> Is this possible?
>
> Thanks,
> M.D.
>
>
> On 3/21/2014 4:40 PM, Rob Stradling wrote:
>> Comodo votes "no".
>>
>> Comodo strongly supports the concept of EV Code Signing, and would 
>> very much like to see wider implementation and participation.
>> However, as far as we are aware, EV Code Signing has been implemented 
>> by only a single vendor with only two CA participants in that 
>> vendor's
> program.
>> Therefore, as Section 1.2 of the Bylaws of the CA/B Forum states that 
>> the purpose of the Forum is to meet and discuss matters of common 
>> interest, we do not believe the EV Code Signing Guidelines to be a 
>> matter of common interest for the Forum at this time.  Specifically, 
>> absent wider implementation and participation in the use of this 
>> standard, additional work now by the CA/B Forum on this topic will be 
>> in contravention of Section 1.2 of the Bylaws.
>>
>> Moreover, Section 1.3 of the Bylaws of the CA/B Forum states that 
>> Forum Members shall not use their participation in the Forum either 
>> to promote their own products and offerings or to restrict or impede 
>> the products and offerings of other Members.  Given the current level 
>> of implementation and participation in EV Code Signing, Comodo 
>> currently cannot vote in favour of Ballot 117, because agreements, 
>> understandings, or protocols reached in the context of standard 
>> setting efforts may violate antitrust laws if the effective result of 
>> such efforts is to restrain competition.
>>
>> On 10/03/14 16:24, Ben Wilson wrote:
>>> Ballot 117 - EV Code Signing Guidelines Corrections
>>>
>>> Jeremy Rowley of DigiCert made the following motion, and Iñigo 
>>> Barreira of Izenpe and Rick Andrews of Symantec endorsed it.
>>>
>>> There are two issues with the EV code signing guidelines that need
>>> correction:
>>>
>>> 1.  Section 9.2.2 of the EV code signing guidelines recommends that 
>>> CAs not include the SAN extension in an EV certificate.  However, 
>>> section
>>> 9.7 requires that an EV certificate include 
>>> subjectAltName:permanentIdentifier. Because the main concern is that 
>>> a CA might include a domain name in the SAN extension, we should 
>>> specify that this practice is not allowed and recognize that other 
>>> information may be present.
>>>
>>> 2.  Because the EV Code Signing Guidelines were originally based on 
>>> the EV Guidelines for SSL, Section 9.2.3 of the EV code signing 
>>> guidelines deprecates the CN field.  However, the CABF Code Signing 
>>> Working Group received a report that this field is still required by 
>>> code signing applications. We should still include the CN in code 
>>> signing certificates for the Subscriber’s legal name, even though 
>>> the field is deprecated for use in SSL/TLS certificates.
>>>
>>> ---Motion Begins---
>>>
>>> Effective immediately:
>>>
>>> a.            Replace section 9.2.2 with the following:
>>>
>>> “9.2.2    Subject Alternative Name Extension
>>>
>>> This field MUST be present and MUST contain the permanentIdentifier 
>>> specified in Section 9.7. This field MUST NOT contain a Domain Name 
>>> or IP Address.”
>>>
>>> b.            Amend section 9.2.3 as follows:
>>>
>>> “9.2.2    Subject Common Name Field
>>>
>>> Certificate field: subject:commonName (OID 2.5.4.3)
>>>
>>> Required/Optional: Required
>>>
>>> Contents: This field MUST contain the Subject’s legal name as 
>>> verified under Section 11.2.“
>>>
>>> ---Motion ends---
>>>
>>> Motion Ends
>>>
>>> The review period for this ballot shall commence at 2200 UTC on 
>>> Monday,
>>> 10 March 2014, and will close at 2200 UTC on Monday, 17 March 2014.
>>>
>>> Unless the motion is withdrawn during the review period, the voting 
>>> period will start immediately thereafter and will close at 2200 UTC 
>>> on Monday, 24 March 2014.
>>>
>>> Votes must be cast by posting an on-list reply to this thread.
>>>
>>> A vote in favor of the motion must indicate a clear 'yes' in the
> response.
>>>
>>> A vote against must indicate a clear 'no' in the response.
>>>
>>> A vote to abstain must indicate a clear 'abstain' in the response.
>>> Unclear responses will not be counted.
>>>
>>> The latest vote received from any representative of a voting member 
>>> before the close of the voting period will be counted.
>>>
>>> Voting members are listed here: https://cabforum.org/members/
>>>
>>> In order for the motion to be adopted, two thirds or more of the 
>>> votes cast by members in the CA category and more than one half of 
>>> the votes cast by members in the browser category must be in favor.
>>>
>>> Quorum is currently six (6) members– at least six members must 
>>> participate in the ballot, either by voting in favor, voting 
>>> against, or by abstaining for the vote to be valid.
>
>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690 Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by
replying to the e-mail containing this attachment. Replies to this email may
be monitored by COMODO for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no
liability can be accepted and the recipient is requested to use their own
virus checking software.
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5453 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20140324/52929d6b/attachment-0001.bin 


More information about the Public mailing list