[cabfpub] Ballot 117 - EV Code Signing Guidelines Corrections
Dean Coclin
Dean_Coclin at symantec.com
Fri Mar 21 20:55:14 UTC 2014
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.
"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.
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?
"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"?
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 Subscribers 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 Subjects 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6130 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20140321/f075b131/attachment-0001.p7s>
More information about the Public
mailing list