[cabfpub] Preballot - Revised Ballot 190

[Ryan Sleevi]

On Wed, May 17, 2017 at 2:23 PM, Gervase Markham <gerv at mozilla.org> wrote:

> On 17/05/17 18:04, Ryan Sleevi via Public wrote:
> > I totally appreciate that sentiment, but you realize one area of the
> > concern and issues has been the proposal - made by Kirk, Gerv, and
> > Jeremy - to allow the reuse of insecurely-validated domain names.
>
> This is why I am proposing this. Not because I like it, but because CAs
> have not kept records of which method was used, any per-method variance
> would require them to redo all validations. (And I'm not up for
> requiring every CA to redo every validation, either, and it wouldn't
> pass even if I was.) So we sigh, grandfather everything in one last
> time, and make it a requirement that CAs record the method used so that
> in future, we can do method-specific rules.
>
> What's the alternative proposal, given that many or most CAs can't do
> per-method rules right now?
>

The proposed extension would be simply that the CAs which haven't
maintained those records can still signal a BR version 1.4.2 (or 1.4.1 or
equivalent). As they gather/complete such records, they can signal a BR
version 1.4.x.

As those who have maintained records revalidate, they can signal 1.4.x. If
they reuse information, and it wasn't to 1.4.x, they can signal 1.4.2

So the capability remains. The signalling is optional until some phase in,
with the intent that in the future, it can make such grandfathering
technically reliable, which can open up greater flexibility for CAs and the
ecosystem in assessing the risk of accepting such certificates. Modulo
things which undermine the underlying cryptographic signature (e.g. the
choice of algorithm and keys), this allows us greater flexibility to
discuss how best to grandfather other aspects, whether about the
certificate themselves or the issuance systems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170517/74cada73/attachment-0003.html>