> On Apr 28, 2017, at 9:06 AM, Kirk Hall via Public <[email protected]> wrote: > > 1. It appears from various comments over time that your biggest concern > about re-use of prior validation data relates to method 3.2.2.4.6 – Agreed > Upon Change to Website. Old method 6 required “Having the Applicant > demonstrate practical control over the FQDN by making an agreed-upon change > to information found on an online Web page identified by a uniform resource > identifier containing the FQDN” > > New method 6 requires specified content be posted to a > "/.well‐known/pki‐validation" directory, which no CA has ever done (because > this path is brand new, and created for the updated version of this > validation method). So prohibiting reuse of data collected under old method > 6 will necessarily require revalidation of ALL domains ever validated under > old method 6. As I indicated on the CABF teleconference yesterday, this will > require some CAs (including Entrust) to manually review EVERY domain > validation we have done to determine which used old method 6, versus other > approved methods. This would be a massive undertaking, and something CAs > won’t want to do unless there is a demonstrated security need. > > Can you share with us the facts, data, evidence, etc. that leads you to > believe that the domain validations previously done under old method 6 pose a > significant security threat to users? Any statistics to back this up? I’m > not challenging you, I’m just asking you for data that supports what you want > us to do. We are not aware of any instance where we used old method 6 and > later discovered that the domain should not have been authorized for the > customer.
Kirk, I did some research on this back when we were working on ballot 169. See https://cabforum.org/pipermail/public/2016-April/007504.html <https://cabforum.org/pipermail/public/2016-April/007504.html> and https://cabforum.org/pipermail/public/2016-April/007506.html <https://cabforum.org/pipermail/public/2016-April/007506.html> We know that all the following were valid under the old method 6: - Allowing the certificate requester to specify the URI. For example, if the certificate wanted shop.example.com <http://shop.example.com/>, the requester could say “check at http://shop.example.com/tmp/uploads/foo.txt <http://shop.example.com/tmp/uploads/foo.txt>” for the agreed upon change - Looking for the change anywhere in the page. The CA would give the requester a token to put on the website and then look for it to appear somewhere on the page. This is a huge problem for sites that have public comments, message boards, or user-editable content. For example, validate “control” of www.ibm.com <http://www.ibm.com/> by posting a message containing the token at https://www.ibm.com/developerworks/community/forums/html/public <https://www.ibm.com/developerworks/community/forums/html/public> - Simply looking for the existence of a file by name. For example telling the customer to create http://<FQDN>/adfa24r43aefwaer2442.txt and not caring about the content. - Looking for a content to be returned from the server that was included in the URL and not checking the HTTP return code. I would also note that other “old” methods have similar issues. For example, there was no requirement that email validation used a unique token per request. It would have been valid to send an email saying “Does this email work?” to the domain owner and using an out-of-office auto-reply as proof of “communication”, as the requirement was only “Communicating with” the email address. Does that help explain the concern? Thanks, Peter > From: Ryan Sleevi [mailto:[email protected] <mailto:[email protected]>] > Sent: Friday, April 28, 2017 6:09 AM > To: Kirk Hall <[email protected] > <mailto:[email protected]>> > Cc: CA/Browser Forum Public Discussion List <[email protected] > <mailto:[email protected]>>; Wayne Thayer <[email protected] > <mailto:[email protected]>> > Subject: [EXTERNAL]Re: [cabfpub] Ballot 190 > > > > On Fri, Apr 28, 2017 at 1:32 AM, Kirk Hall <[email protected] > <mailto:[email protected]>> wrote: > One other comment. Remember that for the last few months, new Methods 1-4 > and 7-10 were actually included under Method 11 “any other method” after > Ballot 181’s effective date, and that situation will continue until the > effective date of Ballot 190. Also, the same is true for any validations > that followed old Method 7 “any other method” prior to the effective date of > Ballot 169. So be very careful in saying anything in Ballot 190 that would > invalidate validations done prior to Ballot 190 under “any other method” so > long as they complied with any of Methods 1-10 of the new methods or Methods > 1-6 of the old methods. > > I would be open to saying that any prior vetting done under old Method 7 or > more recent Method 11 “any other method” must be revalidated upon the > effective date of Ballot 190 IF they did not follow EITHER Methods 1-6 (as > the existed before Ballot 169) or Methods 1-10 (as put forward in Ballot > 169). In other words, the ONLY validations that have to be redone before the > expiration of the re-use period are validations that were done that did not > comply with either old Methods 1-6 or new Methods 1-10. That should flush > out any unknown and unsecure validations that occurred in the past. > > Not quite, because if you recall, Google's interest in reforming these began > with the fact that a website demonstration of control was not secure. That > is, 3.2.2.4.6 under pre-169 is not acceptable. > > Kirk, given your support for other forms of indicating that a CA has > performed extra diligence, such as the inclusion of OV certificates, would > you be supportive in general of a means of expressing, within a certificate, > conformance with the 'new' validation methods, so that subscribers can have > assurances of the security? > _______________________________________________ > Public mailing list > [email protected] <mailto:[email protected]> > https://cabforum.org/mailman/listinfo/public > <https://cabforum.org/mailman/listinfo/public>
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
