[cabf_validation] Validation methods used for Wildcards/ADNs

Wed Feb 3 17:27:11 UTC 2021

Hi Ryan,

> First, while this was discussed in the context of our Herndon meeting in early 2018 (specifically, March 2018), you may recall that Google has raised this in the past before then (e.g. in the discussions of StartCom/WoSign validation practices, which were reiterating concerns Google raised to the management list even older than that regarding such validation)

I don’t recall any messages from Root Programs on prohibiting “ADN != FQDN” HTTP-based validation surrounding the StartCom/WoSign incidents [1], as none of the WoSign incidents arose from such allowance. Those incidents arose from failing to prohibit a ADN subdomain from validating a parent FQDN, or allowing validation against HTTP servers running on non-privileged ports, etc. Given this, it would be useful if you could clarify your previous statement that “we've become aware of some CAs having poorly evaluated the security risks in this space” so that everyone has a full understanding of the motivation underlying that statement and how we can address the security concern.

Thanks,

Corey

[1] https://wiki.mozilla.org/CA:WoSign_Issues#Issue_N:_Additional_Domain_Errors_.28June_2015.29

From: Ryan Sleevi <sleevi at google.com> 
Sent: Tuesday, February 2, 2021 3:31 PM
To: Corey Bonnell <Corey.Bonnell at digicert.com>
Cc: CABforum3 <validation at cabforum.org>
Subject: Re: [cabf_validation] Validation methods used for Wildcards/ADNs

On Tue, Feb 2, 2021 at 3:14 PM Corey Bonnell <Corey.Bonnell at digicert.com <mailto:Corey.Bonnell at digicert.com> > wrote:

Hi Ryan,

This WG discussed the allowance for HTTP-based domain validation to be performed at the ADN in late 2018 as a potential item to address as part of SC25. Given that the group decided to not modify this allowance in SC25, I’m wondering what the motivation is for this change now, especially considering that you mentioned “we've become aware of some CAs having poorly evaluated the security risks in this space”. Is this referring to a new threat that has been identified, or something else?

Hi Corey,

There are several things you've gotten wrong in your message, to varying degrees, and I think this might explain the disconnect.

First, while this was discussed in the context of our Herndon meeting in early 2018 (specifically, March 2018), you may recall that Google has raised this in the past before then (e.g. in the discussions of StartCom/WoSign validation practices, which were reiterating concerns Google raised to the management list even older than that regarding such validation)

Second, following that summit in Herndon, VA, the validation WG began to work to address multiple issues that were highlighted, by dividing that work into chunks to ensure productive discussion and collaboration. For example, this work continued through SC2, SC7, SC13, SC14, SC15, SC18, SC19, SC25, and SC33. This work is a continuation of our ongoing progress being made, both on the issues known before our summit and identified during.

Third, the choice to not include this within SC25 was not because this was and is not an important change, but in recognition of the differing challenges with respect to how methods are sunset, and wanting to continue to make meaningful progress.

Although our Herndon meeting serves as a useful anchor point, it's worth noting the discussion of validation security well existed before that attempt to formalize and track all of the issues - e.g. ballots such as Ballot 218 were themselves part of the overall discussion of validation security that began well prior to Ballot 169/181/190.

So the motivation is the same as it has always been, for over half a decade: to ensure users are secure. While the CA/B Forum has made good progress in the past three years, and we've made important progress on thorny issues the validation WG has identified (e.g. the ongoing work on certificate profiles, ballots such as SC12, SC16, and SC30), we cannot let progress detract from the need to address these issues.

Importantly, given that this is one of the longest-standing issues the Forum has been aware of, and because we explicitly designed ballots in order to help minimize risk (specifically, the proviso in Ballot 169 to record the validation method used).

Hopefully, this provides a useful refresher for the past activity in the Forum, how this has been subject to years of discussion, and the importance in continuing to make progress in closing a very clear and obvious security gap.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210203/6856db1d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210203/6856db1d/attachment-0001.p7s>