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

[Rick Andrews]

I should have addressed this in my previous email.

You're right, "must" requires more work than a "should", and many months ago I changed this doc title from "Guidelines" to "Recommendations". I realize that can lead to confusion. What does it mean if we say we "recommend" that you "must" do something?

If I change everything to "should"s, it would be much more likely to pass, but I'm concerned that it will barely raise the security bar, if it raises it at all. At this point, the only "must"s in the doc are points for which I feel a) no user agent violates today, and b) would be dangerous for a user agent to ignore. For example, if the user agent has up-to-date knowledge that a cert has been revoked but still decides to show the EV treatment.

-Rick

> -----Original Message-----
> From: Sigbjørn Vik [mailto:sigbjorn at opera.com]
> Sent: Monday, November 18, 2013 9:58 AM
> To: Rick Andrews; ben at digicert.com; public at cabforum.org
> Subject: Re: [cabfpub] Ballot 89 Again (Publish Recommendations for the
> Processing of EV SSL Certificates v.2)
> 
> On 18-Nov-13 13:53, Sigbjørn Vik wrote:
> > On 16-Nov-13 03:03, Rick Andrews wrote:
> >
> >> 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 was told that my intention didn't shine through here :) I am not
> opposed to a "must" (in any of the issues), it is just that using a
> "must" requires significant more work than a "should", including
> checking if there are any existing use cases which would be
> invalidated.
> While a stricter spec is better, it is also harder to get approved, and
> takes more time to get right, and from my understanding that this spec
> is already controversial and overdue, this might not be the most
> important point to work on. If you know that nobody would oppose such a
> "must" (Opera won't), then feel free to include it. Another possibility
> is to explicitly bring up such changes later, after the main body of
> the
> spec has been agreed upon.
> 
> --
> Sigbjørn Vik
> Opera Software