Kirk, I’m very hesitant to call anything “misissuance” based on the old methods as the CA followed the rules.
I am reasonably sure that the following certificates were issued using either “any other” or an agreed upon change to website method: https://crt.sh/?id=106122476 <https://crt.sh/?id=106122476> https://crt.sh/?id=18752248 <https://crt.sh/?id=18752248> https://crt.sh/?id=128494659 <https://crt.sh/?id=128494659> https://crt.sh/?id=91029499 <https://crt.sh/?id=91029499> https://crt.sh/?id=17296948 <https://crt.sh/?id=17296948> https://crt.sh/?id=81977675 <https://crt.sh/?id=81977675> I’m not suggesting these are mis-issued, but I have a rather high confidence that they do not represent what I would call “best practices”. Thanks, Peter > On Apr 28, 2017, at 9:37 AM, Kirk Hall <[email protected]> wrote: > > Yes, that’s good information on possible exploits - thanks. That’s why we > worked so long on improving BR 3.2.2.4 – as you may recall, I was deeply > involved in that, and very supportive. > > But I’d really like to know if there is evidence that cert “misissuance” > occurred in the past because of these potential vulnerabilities. Do you know > if there is any data on that? I think we would need more than one or two > anecdotal (and maybe unconfirmable) stories to justify revetting of all > outstanding domains by all CAs. The improvements will be implemented over > time, on a going-forward basis. > > As Gerv said, there will be significant reluctance to change / improve > validation methods in the future if it always requires massive revalidation > of all existing domains, without a showing of actual past abuses and related > security concerns. > > From: Peter Bowen [mailto:[email protected] <mailto:[email protected]>] > Sent: Friday, April 28, 2017 9:31 AM > To: CA/Browser Forum Public Discussion List <[email protected] > <mailto:[email protected]>> > Cc: Kirk Hall <[email protected] > <mailto:[email protected]>> > Subject: [EXTERNAL]Re: [cabfpub] Ballot 190 > > > On Apr 28, 2017, at 9:06 AM, Kirk Hall via Public <[email protected] > <mailto:[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 createhttp://<FQDN>/adfa24r43aefwaer2442.txt > <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
