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

[Sigbjørn Vik]

On 11-Nov-13 23:50, Rick Andrews wrote:

>> "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...
> 
> I added a definition to Section 4. I copied the definition from the BRs; that should be good enough.

Should be good.

>> 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?
> 
> I left this as is, because the BRs and EV Guidelines also use the term. Why create another term?

Consistency is good.

>> 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."
> 
> Before I change this, I ask for clarification: Google and now Opera don't manage their own root stores (except for Chrome on Android), but I think they are among the intended audience for this document. Do you agree? Do you think Opera or Google would assert that they're not root store managers?

Opera is part of the intended audience for this document. Opera is also
no longer a root store manager. We create "root store relying party
software" though :P

>> I believe section 6 discusses root stores, not application software in
>> general. E.g. it does not apply to Opera.
> 
> Wait a minute - I'm pretty sure that Chrome keeps its own list of EV-capable roots, over and above what the platform might have. And I would expect that Opera would work the same way. The way I understood it, Chrome could decide to untrust a root for EV (for example) even though the underlying platform trusted it for EV. If that's true for Chrome and Opera, then doesn't Section 6 apply? Shouldn't Chrome and Opera examine audit reports and maintain the EV OIDs for each EV root?

Opera has no intention of having to deal with CA audits in the future :)
We get root stores and EV lists from elsewhere. While we have the
capability to override these, we don't plan to do so, except in special
circumstances. There are also plenty of other browsers which do not
operate as root stores, to whom this section should not apply.

>> 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."	
> 
> I guess Chrome and Opera are special cases in that they don't include their own certificate viewer functionality. I changed it to "Certificate Viewers should provide text equivalents for any OIDs shown to end users. For example, these EV-specific OIDs used in Subject Distinguished Name fields should be displayed as follows (translated accordingly):"

Change the second "should" to a "may", and I have no objections. My
issue was not with the use of "human readable", I strongly believe all
end user UI should be human readable, my issue is with mandating
non-human readable strings in UIs, as this stops software from improving
and creating more understandable user experiences.

Other edits seem good.

-- 
Sigbjørn Vik
Opera Software