[cabfpub] Ballot 193 - 825-day Certificate Lifetimes

Ryan Sleevi sleevi at google.com
Thu Mar 2 00:50:59 UTC 2017


On Wed, Mar 1, 2017 at 4:31 PM, Kirk Hall via Public <public at cabforum.org>
wrote:

> There were people at several CAs who worked on this draft, but here is my
> understanding of these provisions.
>
> New subsection (ii) came from Ballot 186, and was intended to deal with
> the question of whether a change in a validation method requires revetting
> of all applicants who are still within the vetting data validity period. –
> the answer is no.  (This question briefly came up with Ballot 169.)  If a
> future ballot changes a validation method and wants to mandate revetting of
> data that is still within the data validity period, the future ballot
> should specifically say that so no one is confused.
>
I would like to suggest that your subsection (ii) be an independent ballot.
As the Forum strives for consensus, members should seek to ensure the least
conflict, by ensuring harmony in the sections.

I appreciate your efforts to solve this issue, but this is a poor ballot to
attempt to do so, and naturally jeopardizes the success by increasing risk.

I want to highlight that Ballot 186 was restating and reaffirming what's
already written, and then further restricting it. The proposal here by
Entrust does the exact opposite - it weakens the current Baseline
Requirements and undermines security and trust in certificates.

Under the current Baseline Requirements, independent of any other Ballots,
a CA MAY use documents and data previously obtained, but MUST use this
information as part of the validation fulfillment of Section 3.2. This
naturally flows from the explicit and intentional lack of the exception
you're introducing. By introducing this, the proposal undermines the
security by allowing the use of known-insecure validation methods, thus
undermining the years of effort this Forum has spent with respect to Ballot
169/180/181/182.

While I appreciate the efforts made to provide clarity, the current text is
incompatible with this insecure and harmful proposal.


> On your second point, the following “new” BR language in Ballot 193 has
> part of EVGL 11.14.1(6) for EV cert domain validation for many years.  This
> new BR section is part of an effort to harmonize the BRs and EVGL so if a
> method is permitted in the EVGL, it’s also permitted in the BRs.
>
>
>
> “ BR 4.2.1 *** * If an Applicant has a currently valid Certificate issued
> by the CA, a CA MAY rely on its prior authentication and verification of
> the Applicant's right to use the specified Domain Name under Section
> 3.2.2.4, provided that the CA verifies that the WHOIS record still shows
> the same registrant as when the CA verified the specified Domain Name for
> the existing Certificate.*”
>

It's unclear whether you disagree with the substance of my analysis, and
are thus stating it was intentional to weaken the Baseline Requirements, or
if you're simply providing clarification for the intent, for which the
weakening of the Baseline Requirements was unintentional?

If this was unintentional, we can work to resolve this in a way that
achieves the intended resolve. However, if this was intentional, we will
continue to disagree, and thus will find it necessary to vote against this
ballot. I can only hope that, like Ballot 188, this was merely an
unintentional side-effect, and hopefully one we can resolve through
collaboration.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170301/e9d5ec42/attachment-0002.html>


More information about the Public mailing list