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

[Tim Shirley]

That is a disconnect then from what was discussed in the validation working group, unless I’m misunderstanding.  The minutes cited an example scenario where, upon determining that a domain validation method was insufficient, the domain is revalidated using a different method but the certificate itself is not replaced.  If a relying party was looking at this data in the certificate to make a trust decision, then that necessitates replacing the certificate for it to continue to be trusted.

I’m not trying to resist the transparency; I don’t think James or Tim are either.  I’d argue the metadata approach actually provides much greater transparency.  For example, the metadata approach might record, for a DNS-based validation, what DNS server was queried and when.  Now say there is a DNS hijacking discovered for a certain subnet / period of time.  You’re in a much better position to be able to determine which certificates are affected than you are when only the method is encoded into the certificate.  Given the discussion in the validation working group concluding that this shouldn’t be used for real-time decisions, this seemed an opportunity to be able to provide that greater transparency.

Tim Shirley
Software Architect
t: +1 412.395.2234

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>

Recognized by industry analysts as a leader in managed security services<https://www.trustwave.com/Company/About-Us/Accolades/>.


From: "sleevi at google.com" <sleevi at google.com>
Date: Friday, August 10, 2018 at 3:16 PM
To: Tim Shirley <TShirley at trustwave.com>
Cc: "validation at cabforum.org" <validation at cabforum.org>, Tim Hollebeek <tim.hollebeek at digicert.com>
Subject: Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies

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<mailto: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/7c0fe9f2/attachment-0001.html>