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

[Rick Andrews]

> > 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."
> 
> Sounds good, but note the ambiguity now inherent in the wording, as
> "validate" means "path validation according to RFC 5280" in the first
> sentence, and "validation according to the certificate verification
> software" in the second sentence. User agents might not be told about
> path mis-validation by the certificate verification software, and by
> this sentence must take the gospel from such libraries, for any kind of
> validation errors, not just path validation. (Or else validate by other
> means.)

How about if I change it to "The EV treatment must not be granted by user agents to certificates for which the agent knows of any failure in path validation."?

> > 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.
> 
> This gets complicated with a must. There is no technical reason for
> these OIDs, a CA might just as well just have an EV root, and
> categorically state that anything chaining to it is EV. This might be
> sufficient in a lot of cases, so I'd recommend a should here. Also note
> that an EV root is not required to be issued by a public CA, it could
> also be a home grown intranet root, automatically installed by
> sysadmin.

I'm reluctant to change this. I was not in the CABF at its founding, but AFAIK the group agreed that an EV cert would have to contain the OID corresponding to the OID associated with the root that it chained up to. I'd like to hear others' opinions on this. I believe there is value in requiring the OID in the end-entity cert. It allows the CA to issue non-EV certs from under the EV root, for example. Root store managers have expressed a desire to maintain fewer roots, not more, so I would expect that CAs that issue EV certs would also issue non-EV certs from the same root. And the OID is what differentiates them.

I'm not sure what home grown intranet EV roots have to do with this discussion?

> User agents might not check the certificate policy identifiers at all
> (leaving that entirely to the certificate verification software), so it
> might be impossible for user agents to live up to their part of the
> bargain here, so I'd recommend a should for the second part too,
> alternatively replacing user agents with certificate verification
> software and rewriting. (Similar issue as in section 9, using "must"
> for
> something the user agent doesn't know about.)

If you accept my argument above that CAs want to issue EV and non-EV from the same root, then in cases where user agents are separate from certificate verification software, someone has to check if the policy identifier is correct. If it's the certificate verification software that does that, it needs to return some flag to the user agent indicating whether the test passed or failed. I feel that if I make this a "should", everyone might just assume that the other guy is checking, and we may have a case where no one checks.

> > 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."
> 
> Sounds good. What about the second part, certificates "for which
> confirmation has never been obtained", this originally used the same
> verb?

I removed 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.
> 
> Hm, saying "Should [...] offer protections [which might be null]"
> sounds
> strange to me, and goes against the definition of should. They also
> seem
> to only apply to its relying parties, not all relying parties. I also
> expect such protections are not the same for all relying parties,
> browser vendors and end users would quite possibly receive different
> protections (e.g. emergency contacts).
> Maybe the following would be sufficient: "These agreements, and any
> protections offered by them to relying parties, should be
> non-discriminatory."

Since this is quasi-legal, I defer to Ben.

> >> 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?
> 
> Adding an "in order to" clause, stating that relying parties have been
> required to work "in order to" achieve some particular end result,
> would
> be one solution. E.g. "Historically, CSP's policies and practices
> varied, and had to be assessed by relying agents in order to be certain
> of their suitability for the intended usage."
> 
> Replacing "relying parties" with root store managers and application
> software providers, would be another solution.
> Removing the sentence would also work. Having some background
> information is good though, so I don't recommend removing the
> paragraph.

I'll defer to Ben on this one too.

-Rick