[cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies

Ryan Sleevi sleevi at google.com
Tue Aug 14 11:32:56 MST 2018


On Tue, Aug 14, 2018 at 1:47 PM Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> More than happy to clarify since I can understand how this would be
> confusing.
>
>
>
> The message you reference is discussing operations on the main path of
> validating certificates.  That’s an extremely common operation that must be
> robust to all sorts of silliness or the entire world goes south very
> quickly.  It should also be noted that Wayne’s proposal was for disclosure
> only and to be able to more effectively determine appropriate remediations,
> and therefore there actually isn’t any need at all to parse this
> information as part of certificate validation.  Is the Chrome team planning
> to selectively distrust certificates based on validation method?
>

This was already addressed in
https://cabforum.org/pipermail/validation/2018-August/001021.html


> Viewing certificate details is a very, very rare operation for most
> people.  It still has to be secure and robust in the face of unexpected
> inputs, but that’s very different from requiring that they actually be
> displayed in an easily understood form.  As I stated in London, I would
> love if all certificate viewers were well maintained and wonderful, but I
> can understand that everybody has limited resources, and I’m sympathetic if
> really pretty display of the latest and greatest certificate changes
> doesn’t make it to the top of the backlog.
>

Unfortunately, your response leaves it difficult to impossible to predict
what your views on a given matter are, as they remain seemingly
inconsistent. The argument in favor of adding an obscure syntax is that
browsers can update rapidly, and yet the argument against using a more
natural syntax is that it takes too long for browsers to update. It sounds
like the view is now that browsers will not prioritize the display of this
certificate information, not that they cannot update to display it. Of
course, this position seems to be at odds and inconsistent with the views
you previously expressed in
https://cabforum.org/pipermail/validation/2018-August/001010.html

I can't tell what your priorities or principles are, but I cannot help but
feel that you're either agreeing with everyone or constantly changing your
views. I wish I had a better understanding of your priorities and concerns,
so that we can better arrive at a mutually beneficial solution. Since the
beginning - which itself has been expressed since the discussions of Ballot
190 - I've stated plainly that the value of this information is most
meaningful to relying parties in automated ways, given that the Baseline
Requirements permit, and historically have permitted, methods that are
below the acceptable security threshold of multiple members. If CAs are
opposed to raising the bar as the industry, then it's incumbent that the
appropriate controls be made available. If the Forum cannot make those
controls, then we can continue the path that multiple browsers have already
taken, which is unilaterally imposing controls to restrict or prohibit
certain practices that other vendors may deem acceptable, but that they
deem insufficient security.

This is, of course, the nature of the industry - evolving to react to new
information and new threats - and it's inherent in the Forum, or in any
body of competitors with an Antitrust Policy in place, that we cannot nor
should not expect or require coordinated moves in order to respond to those
threats. That doesn't serve users.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180814/7b2c3865/attachment-0001.html>


More information about the Validation mailing list