[cabfpub] Ballot 89, Again (Publish Recommendations for the Processing of EV SSL Certificates v.2)

Rick Andrews Rick_Andrews at symantec.com
Tue Oct 15 09:41:16 MST 2013


In light of Sigbjørn's comments made during the comment period, I'm withdrawing the ballot until I can address his points.

-Rick

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Sigbjørn Vik
> Sent: Thursday, October 10, 2013 3:23 AM
> To: public at cabforum.org
> Subject: Re: [cabfpub] Ballot 89, Again (Publish Recommendations for
> the Processing of EV SSL Certificates v.2)
> 
> A few notes:
> According to the definition of Application Software Supplier, Opera is
> not one, as we no longer incorporate root certificates, but rather make
> use of those already available on the OS. In e.g. section 6.1
> Application Software Suppliers are treated as root store providers, and
> in section 15.1 as user agents. Opera is not both, so something needs
> to
> change somewhere.
> 
> I believe that relying application means a certificate verification
> application (a definition would be good), but the definition of
> Application Software Supplier indicates that browsers are relying
> applications. On OSes where the embedded root store verifies
> certificates, the browser will not perform such a check. Section 12 and
> 13 need to be clear about what types of applications they apply to.
> 
> Section 13 does not explain what it means to not be "trusted" - does
> that mean non-EV, or not secure?
> 
> Section 15.1 makes no sense to me as a browser developer. We would not
> put legalese in UI intended for end users, e.g. "Inc." or
> "Incorporation", and the section would be blatantly ignored. It is not
> clear what applications this section refers to though, root stores,
> browsers, payment terminals, ...?
> 
> The document talks about root stores, certificate verification
> applications and user agents interchangeably, while those might be
> three
> separate applications, by separate companies. For any one such
> supplier,
> one has to read through the entire document to find out what applies. A
> cleanup both in the use of terms, and clearly specifying which sections
> apply to which providers would help.
> 
> In most other standards organizations, a specifications document like
> this, which puts requirements on applications, is routinely (sometimes
> mandated) accompanied by a testsuite where application developers can
> verify their compliance. A testsuite for the requirements would be
> good.
> 
> 
> 
> 
> 
> On 07.10.2013 21:27, Rick Andrews wrote:
> > A while back, I volunteered to update the Guidance for the Processing
> of
> > EV certificates (version 1, dated 2009).  The group decided several
> > weeks ago to remove version 1.0 from the website, even if a newer
> > version never replaces it.
> > Based on comments received, numerous edits were made to both the
> > guideline document and the ballot. During this process the browsers
> have
> > appeared reluctant to move forward with any EV processing guidelines.
> > Nevertheless, as the final step in this process, I have made one
> final
> > edit to the document, incorporating more edits from Ben and one from
> > Moudrick made at the Face-to-Face meeting in Ankara, and I have
> renamed
> > the document from "guidelines" to "recommendations" and made
> conforming
> > edits throughout.  I have also renamed the motion from "Adopt
> Guidelines
> > ." to "Publish Recommendations for the Processing of EV SSL
> > Certificates." Hopefully by converting this entire issue from "adopt
> > guidelines" to "publish recommendations", the approval of this ballot
> > will appear less obligatory on browsers and their opposition to
> > publishing this version 2.0 on the CAB Forum website will fade.
> > You can view changes from version 1 in the attached documents. They
> are
> > also posted on the wiki page
> > at_https://www.cabforum.org/wiki/89%20-
> %20Publish%20Recommendations%20for%20the%20Processing%20of%20EV%20SSL%2
> 0Certificates%20v.2_
> > Therefore, I am proposing that Ballot 89 go forward as follows, if
> Ben
> > and Kirk acknowledge their continued endorsement of this ballot, as
> amended:
> > Ballot 89 - Publish Recommendations for the Processing of EV SSL
> > Certificates v.2
> > Rick Andrews (Symantec) made the following motion, endorsed by Ben
> > Wilson from Digicert and Kirk Hall from Trend Micro:
> > --- Motion begins ---
> > A "YES" vote on the ballot means that the member votes to post the
> > "Recommendations for the processing of EV SSL certificates" document
> to
> > the CAB Forum public web site.
> > A "NO" vote on the ballot means that the member votes not to post the
> > "Recommendations for the processing of EV SSL certificates" document
> to
> > the CAB Forum public web site.
> > ... Motion ends ...
> > The ballot review period comes into effect immediately upon posting
> > today (Monday, 7 October 2013) and will close at 2200 UTC on Monday,
> 14
> > October 2013.  Unless the ballot is withdrawn or modified during the
> > review period, the voting period will start immediately thereafter
> and
> > will close at 2200 UTC on Monday, 21 October 2013.  If the ballot is
> > modified for reasons other than to correct minor typographical
> errors,
> > then the ballot will be deemed to have been withdrawn.
> > Votes must be cast by posting an on-list reply to this thread.
> > A vote in favor of the ballot must indicate a clear 'yes' in the
> response.
> > A vote against the ballot 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: _http://www.cabforum.org/forum.html_
> > 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. Also,
> quorum
> > is currently set at 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.
> > -Rick
> >
> >
> > _______________________________________________
> > Public mailing list
> > Public at cabforum.org
> > https://cabforum.org/mailman/listinfo/public
> >
> 
> 
> --
> Sigbjørn Vik
> Opera Software
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public


More information about the Public mailing list