Are you saying that's what actually happened, or that we should all pretend that's what happened?
Because I don't believe anyone from GoDaddy has made such a claim, and we ought not put words in their mouths. Alex On Fri, Apr 13, 2018 at 12:39 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 13/04/2018 18:07, Ryan Sleevi wrote: > >> Indeed, it was a public demonstration that they'll happily issue, that >> their stated policies and guidelines disclaim responsibility for the >> content, but that they will happily revoke anything that is publicly >> embarassing, even if it is entirely technically correct. >> >> Or perhaps it demonstrates the arbitrary, capricious, and opaque nature of >> what some CAs call "phishing", such as being anything that might be seen >> (unreasonably so) as embarrassing to them for having issued, so they try >> to >> pretend by revocation that it never happened. >> >> > That's not at all what I was saying. I am saying that the security > researchers created a (harmless) simulation of how a phishing site could > game the systems (specifically the US company registry system and the EV > CA system combined). > > The CA's then simulated how they would respond if a real phishing > site had done the same. Not because the simulation was embarrassing, > but simply as the logical continuation of the simulated scenario. > > It's like a fire drill where the mayor "pretends" that an old school > building is on fire, and the firemen then proceed to evacuate the > building and douse it in enough water to put out a real fire. > > Everybody knows it's just a make-believe drill, but they proceed to > demonstrate their abilities to handle the make-believe situation, > because doing so is kind of the point of having a drill in the first > place. > > On Fri, Apr 13, 2018 at 12:00 PM, Jakob Bohm via dev-security-policy < >> >> dev-security-policy@lists.mozilla.org> wrote: >> >> My point, and that of some others is that the blunt revocation was a >>> public demonstation of how that CA would respond to a real phishing >>> site, thus completing your public demonstration of the problematic >>> scenario. >>> >> >> >> >>> >>> On 13/04/2018 02:40, James Burton wrote: >>> >>> We both work in the security space and yes, usually blocking a proof of >>>> concept is good practice but in this situation I feel that revoking this >>>> cert was heavy handed and unnecessary. The probability of Ian using the >>>> EV >>>> certs for deceptive purposes was extremely low. >>>> >>>> There are tons more ways of using EV certs for bad purposes. >>>> >>>> James >>>> >>>> >>>> >>>> >>>> >>>> On Thu, 12 Apr 2018 at 23:35, Jakob Bohm via dev-security-policy < >>>> dev-security-policy@lists.mozilla.org> wrote: >>>> >>>> On 12/04/2018 21:20, James Burton wrote: >>>> >>>>> >>>>> Both mine and Ian's demonstrations never harmed or deceived anyone >>>>>> as >>>>>> >>>>>> they >>>>> >>>>> were proof of concept. The EV certs were properly validated to the >>>>>> EV guidelines. Both companies are legitimate. So what's the issue? >>>>>> None. >>>>>> >>>>>> >>>>>> >>>>>> In the security space, blocking a proof of concept exploit is usually >>>>> considered the right thing to do. But doing so in a way that is >>>>> entirely limited to the concrete example rather than the underlying >>>>> problem is considered cheating. >>>>> >>>>> Consider, as an analogy, a hypothetical freedom of speech law whose >>>>> only >>>>> exception was that you must not shout "fire" in a packed theater. Then >>>>> an actor standing on stage making speech about the silliness of that >>>>> law >>>>> and then shouting "fire", with full warning of the audience to avoid >>>>> panic, should not be surprised to get charged with the specific >>>>> offense, >>>>> as it was a deliberate test of the law. Of cause, such an actor might >>>>> deserve some leniency in the punishment, such as a $1 fine, but he >>>>> should not be surprised the law is formally upheld. >>>>> >>>>> > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
