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

[Tim Hollebeek]

Ok, so the speculation about my motivations are completely ridiculous and I’m not going to address them.  Suffice it to say neither of your speculations is even remotely close to correct.

 

I will say, thinking about it more, I think BIT STRING is optimizing for the wrong case.  I think large numbers of validation methods in a particular certificate will be vanishingly rare, so I think in the long term, just a sequence of integers is probably both easier to use, and more compact, since the number of elements will be strongly peaked at one.

 

-Tim

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Tuesday, August 14, 2018 2:33 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: Wayne Thayer <wthayer at mozilla.com>; Doug Beattie <doug.beattie at globalsign.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies

 

 

On Tue, Aug 14, 2018 at 1:47 PM Tim Hollebeek <tim.hollebeek at digicert.com <mailto: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/e69ac7b3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180814/e69ac7b3/attachment-0001.p7s>