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’m assuming CAs can issue without this extension and those would be treated like certificates based on outdated validation methods. Do you have a timetable and plan for how Google would use this data to degrade the UI or block access? Gerv: Same question for you, what would you do this this data? From: Ryan Sleevi [mailto:sle...@google.com] Sent: Wednesday, May 17, 2017 2:34 PM To: Gervase Markham <g...@mozilla.org> Cc: CA/Browser Forum Public Discussion List <public@cabforum.org>; Doug Beattie <doug.beat...@globalsign.com> Subject: Re: [cabfpub] Preballot - Revised Ballot 190 On Wed, May 17, 2017 at 2:23 PM, Gervase Markham <g...@mozilla.org<mailto:g...@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.
_______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public
