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

[Sigbjørn Vik]

On 13-Nov-13 01:53, Rick Andrews wrote:
> Thanks, Sigbjørn. I accepted your suggestion about Root Store Manager and added this definition:
> "Root Store Manager - An entity that manages a Root Store. In some cases, an 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."
> 
> Then I removed "or Application Software Provider" wherever it appeared after "Root Store manager".

Section 6.1 should now be updated to talk about Root Store managers, not
Application Software Providers.


>> 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?
>
> Good point. I changed Section 9 to a "must". If the chain doesn't
> validate, I don't see any reason why a user agent should still show
> the EV treatment.

Hm, rereading the document, I think it was section 13 which was out of
sync with the rest, section 10, 11 and 12 still use "should", just as 9 did.
Using "should" would be easier for acceptance, if you use "must", you
will have to be more careful with the definitions. Section 13 is
difficult with "must not grant EV treatment to revoked certificates".
There will always be a time lapse between revocation and when user
agents become aware of this, so the "must" is too strong, and to support
it the definition needs to be changed to from "certificates that have
been revoked" to "certificates that are known to have been revoked".
Such a must also implies that it is impossible to "unrevoke" a
certificate, if the OCSP responder has a hiccup, all affected
certificates will have to be replaced afterwards, not certain what is
the state of this today.
A statement of "known to have been revoked" also has implications for
browser cache, after clearing it, the certificate would no longer be
untrusted. Not certain if I see a way around that, as privacy concerns
dictate that the revocation information be deletable. (Same issue with
using "should", but then it is explicitly left to the due diligence of
the browser vendor.)


Section 15, typo: "Root Store Manage confirm" should be "Root Store
manager confirms".


Nitpick now that I know what relying party means:

Section 7.2: I am not sure I understand what protections agreements
between root stores and CAs offer all end users (including end users not
using that root store or CA).

The following sentence in section 16 makes no sense:
"Historically, relying parties have been required to assess the
suitability of a CSP's policies and practices for the intended usage."
As an end user relying on sites being secure, I have not once looked up
the CSP's policies, far less been required to do so by anyone...


-- 
Sigbjørn Vik
Opera Software