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

[Sigbjørn Vik]

On 22-Nov-13 01:07, Rick Andrews wrote:

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

Sounds good.

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

As long as a "must" here is workable in practice, I have no objections.
My point is just that a "must" requires us to look into the issues I
mention above.

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

As they too are covered by the language, we must ensure that home grown
EV roots too follow the same OID practices. I believe they do already.

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

At the same time, requiring all parties to check might not be optimal
either. How about something like this: "User agents must ensure that
OIDs are checked as above.", where they are not actually required to
duplicate the check themselves.

-- 
Sigbjørn Vik
Opera Software