On Wed, May 17, 2017 at 4:46 PM, Doug Beattie <[email protected]> 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. >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
