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

Sigbjørn Vik sigbjorn at opera.com
Wed Oct 16 08:35:23 UTC 2013


New set of docs, new set of comments :)

"Relying party software" is still used in the foreword and the
definition of Application Software Provider, and I still don't know what
it means...

Nitpick: I think that the term "application software" is a superfluous
term to start out with, but according to the common definition (user
interacting software), verification libraries do not belong. Maybe call
it "EV applications" instead?

Whenever "Root store manager" is mentioned, "or Application Software
Provider" is also mentioned. Maybe update the definition to say what we
really mean instead. E.g. "In some cases the application software
supplier might perform some of the root store management, in which case
it is to be considered as a root store manager for those purposes."

"User Agent Software" doesn't make sense. "User agent" means specialized
software, so drop the last "Software" from all mentions.

I believe section 6 discusses root stores, not application software in
general. E.g. it does not apply to Opera.

Section 11, last sentence, should probably mention that it applies to
all application software, not just verification libraries.

Section 13, first paragraph. Verification libraries do not accept or
reject certificates, they only validate/verify.

Why is section 9 only a "should" on non-validating certificates, while
section 13 is a "must" on non-revocation checked certificates? Surely a
non-validating certificate is worse than one that hasn't been revocation
checked?

I still think section 15.1 is contradictory. Imo, the word
"incorporation" does not exist in the subset of English vocabulary
called "human readable", so the section is impossible to fulfill. I also
don't see how e.g. Opera can ensure that Microsoft's certificate viewer
adhere to this section. Alternate (hopefully non-controversial) text:
"Certificate viewers should provide text equivalents for any OIDs shown
to end users."


On 16-Oct-13 01:24, Rick Andrews wrote:
> Without restarting the ballot, I'd like to continue discussion. With Ben's help, I've incorporated changes in nearly every section to address Sigbjørn's comments. Please review the latest docs. They're also attached to the Ballot page on the wiki.
> 
> -Rick
> 
>> -----Original Message-----
>> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
>> On Behalf Of Rick Andrews
>> Sent: Tuesday, October 15, 2013 9:41 AM
>> To: public at cabforum.org
>> Subject: Re: [cabfpub] Ballot 89, Again (Publish Recommendations for
>> the Processing of EV SSL Certificates v.2)
>>
>> 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
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>>
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public


-- 
Sigbjørn Vik
Opera Software



More information about the Public mailing list