[cabfpub] Preballot - Revised Ballot 190

Ryan Sleevi sleevi at google.com
Wed May 17 22:53:36 UTC 2017


On Wed, May 17, 2017 at 4:46 PM, Doug Beattie <doug.beattie at globalsign.com>
wrote:

> Rolling out a new extension and tying the value to the vetting level isn’t
> trivial to implement in some of the products, unfortunately.  DV is easy
> because we verify the domain upon issuance, so those have all been
> compliant with the 10 methods as of March.  The issue is with the managed
> PKI (similar to Entrust I believe).  Knowing the method and the validation
> version for some of the older domains is “hard”, but given sufficient time
> to comply (or sufficient time before browsers penalize certs with no value
> or old values), we can do it.
>
>
>
> What is the proposed timetable in the ballot for having this extension
> implemented?
>

I was thinking SHOULD effective immediately (since we know SHOULDs are
useless as policy), but a MUST with something larger - perhaps even as late
as a year out.


>   I’m assuming CAs can issue without this extension and those would be
> treated like certificates based on outdated validation methods.
>

Exactly :) There's a large LARGE corpus of certificates (e.g. everything
out there) that wouldn't have this extension for at least (phase in time +
validity time). So if we phased in within a year, it'd still be effectively
four years before this would be reliable. But that's all the more reason to
specify it _now_, particularly when it's most meaningful/impactful.


> Do you have a timetable and plan for how Google would use this data to
> degrade the UI or block access?
>

I think you're reading into something that I didn't say. I think it's
important to simply be able to measure and assess - much like the
conversations related to Enterprise RAs.

If there was a misissuance, for example, imagine how useful it would be to
be able to programatically identify which are the 'affected' certs - and
which were issued with more modern ways.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170517/db267dc4/attachment-0003.html>


More information about the Public mailing list