On Wed, May 17, 2017 at 1:29 PM, Doug Beattie <[email protected]> wrote:
> Ryan, > > > > Is this a current summary of the options: > > 1) Set a date way out in the future for allowing certificates to be > issued using deprecated domain validation methods: > > a. Not secure, Browser reject > > b. CA like it > > 2) Set a date within the next 3-6 months for requiring only the 10 > methods for issuance of all certificates (previously collected data cannot > be used past this date if it was collected in accordance with any > depreciated methods): > > a. CAs reject, too much work to reverify all domains within this > short time period > > b. Browsers like it, assuming the date is not too far out. > This is what CAs previously adopted in Ballot 169. > 3) Specify which baseline methods were used within the certificate > and allow deprecated methods to be used for the next 825 days. What > timeline are we contemplating for this? > > a. This is a compromise option > > b. CAs can continue to use insecure data they collected within the > prior 825 days (or 39 months till March) > > c. Browsers can decide if they should trust the site or not. > > d. Depending on what action browsers take, CAs might be incented to > not use deprecated domain validation methods sooner than b). > Not quite. Note the reply to Erwann (and from the original thread). The proposal is simply "Specify what is the newest version that all information within the certificate conforms to" Independent of any discussions of deprecation, which aren't being discussed here, simply signaling what version a given certificate complies with is a huge step forward in providing reasonable assurances to the level of validation. This is not substantially different than proposals to use the standard CA/B Forum OIDs for determining DV/OV/IV in a reliable manner, or to handle any changes in future validation requirements. As we saw with the SHA-1 discussions, there are times when CAs feel they have a compelling business need to use an 'older' version of the Baseline Requirements for the validation and encoding of information, and this could offer a reasonable and reliable technical signal for that. It provides auditors useful tools in evaluating compliance. It provides ways for CAs to establish their security bonafides in the communities that examine corpuses of such certificates, such as Netcraft does. Overall, it seems like a strictly positive win. I'm unclear of your concerns though, and perhaps it'd be useful if you could try to explain them for me. 1) Are you concerned that specifying the technical format of an optional extension would create issues? If so, what are they? 2) Are you concerned that providing details about the compliance status of a certificate would create issues? If so, what are they? I'm happy to provide the text, but there wasn't much comment - and certainly, few objections - so I mistakenly thought it was being incorporated.
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
