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

Sigbjørn Vik sigbjorn at opera.com
Mon Nov 18 12:53:48 UTC 2013


On 16-Nov-13 03:03, Rick Andrews wrote:

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

Agreed, sounds good.

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

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

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.

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

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

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

You are right, subjunctive may be used here. Also note the original
missing "r".

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

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

-- 
Sigbjørn Vik
Opera Software



More information about the Public mailing list