[cabfpub] Preballot - Revised Ballot 190

Ryan Sleevi sleevi at google.com
Fri May 19 14:32:36 UTC 2017


On Fri, May 19, 2017 at 9:04 AM, Gervase Markham <gerv at mozilla.org> wrote:

> Hi Ryan,
>
> On 19/05/17 13:12, Ryan Sleevi via Public wrote:
> > Luckily, this is an incorrect interpretation of what's required. It
> > would only affect those domains affected by those changed validation
> > methods,
>
> Indeed, but the point is, many CAs currently do not have records of
> which method was used, and so surely this would mean "all domains" for
> those CAs?
>

It may, in the context of "data and documents" reuse. It would not, in the
context of "previous domain validations" reuse.


> > only if they're changed in incompatible ways,
>
> Do you consider the current form of the 10 Blessed Methods to have
> "changed in incompatible ways" from the seven methods we had in the BR
> 1.3.x timeframe? I'd say they all probably have. So again, isn't this
> "all domains"?
>

No, not exclusively.


>
> > and only when an
> > applicant requests a certificate.
>
> Well yes, but if otherwise you could reuse the data as often as
> necessary for the normal reuse period, this is still a significant
> increase in work.
>

I don't think the data supports that - it's proportional to the request.
That is, as both Entrust and GlobalSign have highlighted, it's primarily
centered around the enterprise set of customers (those acting as enterprise
RAs or those OV/EV validated) moreso than it is all issuance. The
significance of this is relative to the issuance.

That said, I think it's worth stressing - we think it's a reasonable path
forward that if we allow the reuse of non-conforming validations (e.g.
granting benefits to incumbents at the cost to new CAs or those customers
transitioning CAs), then we should at least consider encouraging
appropriate signals for the CAs that opt to not use the insecure practices.
That at least strikes the right balance in providing public transparency
regarding the security practices, agility, and thoughtful design that many
members have participated in and practiced.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170519/9bf59968/attachment-0003.html>


More information about the Public mailing list