[cabfpub] Require commonName in Root and Intermediate Certificates ballot draft (2)

[Ryan Sleevi]

On Thu, Apr 20, 2017 at 11:57 AM, Gervase Markham <gerv at mozilla.org> wrote:

> On 20/04/17 16:42, Ryan Sleevi wrote:
> > So requirements about data gathering apply both when it is gathered and
> > reused. Requirements about data reuse apply when it is reused. And so on.
>
> Hmm. I see your point. On the other hand, if we adopt this method, we
> run into the problem I mentioned on the call - people will resist any
> improvements to data gathering, because it automatically invalidates all
> existing data.
>

No, it just means you need to explicitly address it in ballots if it's
intentional. But to be clear, people resist any improvements to everything
as is, so it's not strictly worse than the status quo we have today, where
the only things that see uniform consensus are things which relax
requirements, rather than tighten.

Provide clear and unambiguous guidelines about what is acceptable or not,
so that there's no interpretative license, much like there's no debate
about whether "sent" and "submitted" and "distributed" are equivalent or
not.


> For other activities, like issuance, the activity stands alone and my
> originally-specified rules apply.
>

I think your suggested rules perhaps bring more ambiguity than clarity.

Is it reasonable to suggest the simple position, which is what Jeremy was
seeking clarification on: That at the time of a certificate's issuance, it
must be done so in a manner compliant with the "latest published version"
(as specified in Section 2.2 of the BRs that all CAs attest to).

If the latest published version says that "Until July 1, 2017, a CA may
rely on a previously obtained domain validation, provided that validation
was obtained in a manner consistent with the latest published version of
the Baseline Requirements at the time of validation, and that the
validation occurred within the time specified in Section 4.2.1" (OK,
obviously, wordsmithing can be improved).

This makes it clear and unambiguous the scope and intent. That's merely one
approach to doing it.

Another approach - one in which Ballot 189 successfully passed on, is to
state "For all certificates issued after (Date X), the domain authorization
must have been performance in accordance with these sections, and data and
documents obtained and validated in accordance with these sections."

Either of these are objectively better than the interpretation you've
offered, because they fully resolve any ambiguity by making it explicit,
within the documents themselves, as to what methods will be used to
validate a given certificate at a given date.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170420/057ff177/attachment.html>