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

[Rick Andrews]

> > 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.

Agreed, and I even changed Application Software Provider to Root Store Manager in one sentence in 6.2: "The Root Store Manager should store the distinct certificate policy identifier associated with each root certificate, for example, as meta-data." Would you agree that that's the job of the Root Store Manager and not the Application Software Provider?
 
> >> 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.)

I re-read these carefully, and evaluated each section independently:

Section 9: I left it MUST: "User agents must not grant the EV treatment to certificates that do not validate successfully." I believe I can get consensus on this. If the chain does not validate successfully, the cert should not be trusted, period, and if the cert is not trusted, period, there's no rational argument for still showing EV treatment. If there's a browser that shows EV if the chain doesn't validate, I think we'd all like to know about it.

Section 10: I left it SHOULD: "User agents should not grant the EV treatment to certificates whose algorithms and keys do not conform to the EV requirements." I'm fine with keeping the onus on CAs to issue EV certs with the appropriate algorithms and keys.

Section 11: I left it SHOULD, because this talks about processing cert fields and not trusting the OU field.

Section 12, Policy Identifier: I changed both to MUST: "The certificate verification software must verify that the EV certificate contains a value in its certificate policies extension that matches the distinct certificate policy identifier associated with the issuing CSP root certificate. The user agent must grant the EV treatment only to certificates that contain the appropriate policy identifier." If there's a browser that shows the EV treatment even for certs whose policy OID doesn't match the root's EV OID, I think we'd all like to know about it.

Section 13: I left it MUST, but clarified the wording: "User agents must not grant the EV treatment to EV Certificates that are known to have been revoked." That seems reasonable to me: if the browser, via OCSP, CRL, CRL Set, Staple, blacklist, or any other mechanism *knows* that this cert is revoked, it must not show the EV treatment. You're right that this opens up the possibility that the browser learned the cert was revoked but its cache was cleared, and the next time it visited the site, it couldn't get any OCSP response and show EV, but I'm ok with that. I just want to set a bar. It's not perfect.

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

Actually, I think "confirm" is also correct (it's some strange verb tense in English that I've forgotten the name of) but Microsoft Word's grammar checker accepts both, so I changed it.

> 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).

I asked Ben Wilson, and he said:
"Browsers distribute software that includes the Root Certificate.  The
software they distribute comes with an End User License Agreement.  An
agreement between the CA and the Browser will often say, "2.  Grant of
License: Subject to the terms and conditions of this License, CA hereby
grants to Browser a non-exclusive, non-transferable license to copy and use
one or more of CA's Root Certificates for the purpose of (i) embedding such
CA Root Certificates in Browser's Products, and (ii) manufacturing,
distributing and sublicensing, through multiple layers of distribution, such
Products.  Browser may sublicense to its End Users the right to copy and use
the CA's Root Certificates, solely as such Root Certificates are embedded in
such Products, to (i) Browser's resellers and OEMs solely for the purpose of
licensing and distributing such Products and OEM Products, and (ii) to
Browser's end users solely for the purpose of using such Products.  

"Some Root Agreements include End Users as intended third party
beneficiaries.  For instance, an agreement might state, " 'Certificate
Beneficiaries' means, collectively, Subscribers, Subjects, ASVs and Relying
Parties who actually rely on such Certificate during the period when it is
Valid."  Then it will say, the CA shall ensure that every Subscriber enters
into a binding agreement that includes the following covenants and
warranties to all Certificate Beneficiaries, that the Subscriber (i)
provides complete and accurate information, (ii) protects its Private Key,
(iii) accepts the Certificate as an accurate representation of information,
(iv) will use the Certificate and Key Pair appropriately, and (v) will
promptly report any key compromise to the CA."

Let me know if you think that section should change.

> 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...

OK, I asked Ben Wilson and he started looking up legal documents to back this up. But what do you suggest? I think this sentence is an introduction to the following idea that "Achieving the intended level of assurance also requires proper behavior by the relying application.", and that's why we're publishing this document. I suppose we can remove the entire paragraph since it doesn't actually recommend anything. Is that what you suggest?

-Rick