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

[Ryan Sleevi]

I think it's framing the question wrong.

Understandably, some CAs will object to anything that allows clients to
make more informed trust decisions. We've certainly seen this with
opposition to Certificate Transparency, in the past. At the same time,
we've seen four validation methods demonstrated as insecure. Two have been
removed from the Forum (but with a grace period, allowing CAs to continue
issue certificates despite knowing that information is not valid), while
two are still permitted but which are forbidden by software vendors. We've
also seen multiple CAs relying on cached domain validation information
beyond the permitted window. We've seen browsers take steps to deprecate
validation methods in advance of the Forum, in response to ongoing and
emerging security threats - such as disallowing the "Any Other Method" even
while the BRs permitted it.

We've seen multiple claims from members that "no certificate using Method X
has ever been misissued", but, to date, no data to support that statement
has been provided, nor is it quantifiable. Thus, relying parties have no
idea whether or not certain methods are demonstrably weaker, and the CAs
that practice those methods demonstrably less secure.

The distinction here is that the Baseline Requirements capture the minimum,
but that should not be conflated with what is sufficient. CAs routinely
make this argument to their customers, when they discuss the value of OV
and EV certificates, in that they posit that there is a greater value than
the common acceptable level. Equally, we see browser vendors disagreeing on
what the appropriate level of product security is for their customers, and
some requiring additional information - such as, for example, Certificate
Transparency information, or deprecating weak and insecure algorithms.
Because the BRs capture the minimum state, they will never and can never
capture stronger security requirements.

In this regard, enshrining this information allows for both relying parties
and CAs the ability to make discerning choices about the level of trust
introduced and afforded. Should we pretend that this information somehow
belongs elsewhere (likely because CAs wish to preserve using insecure
methods), then inevitably the next steps would be to see greater
fragmentation, in browsers requiring this information to be established
even if the BRs don't, should that be appropriate for their client security
- or potentially distrusting CAs that use validation methods they feel are
insecure.

I think it's misguided and mistaken to believe that this information is not
relevant or applicable for trust decisions, and while I know CAs are keen
to protect their interests in using methods that they may feel are 'secure
enough' (much like they did with SHA-1), the reality is that
trustworthiness is in the eye of the RP, not the CA.

On Fri, Aug 10, 2018 at 3:02 PM Tim Shirley <TShirley at trustwave.com> wrote:

> I’d agree that things necessary for connection establishment should
> ideally be in the certificate.  Putting aside for a second that the “level
> of assurance” is a subjective measure in the eye of the beholder and not
> what is actually proposed to be encoded in the certificate, I’m not sure
> what leads you to suggest that the domain validation method(s) used would
> “almost certainly” fall into that category.  Admittedly I wasn’t at the
> validation working group call last week, but the minutes there captured a
> sentiment that this information should not be used for making trust
> decisions.  Wouldn’t that thus make it unnecessary for connection
> establishment?
>
>
>
> *Tim Shirley    *
>
> Software Architect
>
> t: +1 412.395.2234
>
>
>
> *Trustwave* | SMART SECURITY ON DEMAND
>
> *www.trustwave.com <http://www.trustwave.com/>*
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180810/84d7798c/attachment-0001.html>