[cabfpub] Preballot - Revised Ballot 190

[Ryan Sleevi]

On Wed, May 17, 2017 at 1:29 PM, Doug Beattie <doug.beattie at globalsign.com>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170517/0703655c/attachment-0003.html>