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
              • ... Matthew Hardeman via dev-security-policy
              • ... Alex Gaynor via dev-security-policy
              • ... Matthew Hardeman via dev-security-policy
              • ... James Burton via dev-security-policy
              • ... okaphone.elektronika--- via dev-security-policy
              • ... okaphone.elektronika--- via dev-security-policy
              • ... Jakob Bohm via dev-security-policy
              • ... James Burton via dev-security-policy
              • ... Jakob Bohm via dev-security-policy
              • ... Ryan Sleevi via dev-security-policy
              • ... Jakob Bohm via dev-security-policy
              • ... Alex Gaynor via dev-security-policy
              • ... Peter Gutmann via dev-security-policy
              • ... Ryan Sleevi via dev-security-policy
              • ... Jakob Bohm via dev-security-policy
              • ... Matthew Hardeman via dev-security-policy
              • ... Matt Palmer via dev-security-policy
      • Re: Sigh. stripe.... Alex Gaynor via dev-security-policy
  • Re: Sigh. stripe.ian.sh b... Ian Carroll via dev-security-policy
  • Re: Sigh. stripe.ian.sh b... Peter Bachman via dev-security-policy

Reply via email to