On 13/04/2018 18:05, Ryan Sleevi wrote:
On Fri, Apr 13, 2018 at 11:53 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 13/04/2018 05:56, Ryan Sleevi wrote:
On Thu, Apr 12, 2018 at 11:40 PM, Matthew Hardeman via
dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Wow. I’m impressed.
Let’s Encrypt by their own declaration and by observed interactions in
their community help forums maintains a high value blacklist of domains.
This is misrepresenting what is stated.
It’s difficult to imagine how that list doesn’t include PayPal but did
include mail.ru.
Can you repeat that test with, say, microsoft.cologne?
Just testing a theory...
I think there's sufficient discussion in the past on such theories that it
would seriously detrimental to try to rehash or relitigate - e.g.
https://groups.google.com/d/msg/mozilla.dev.security.policy/
vMrncPi3tx8/ZOqtG2DBBgAJ
That link does not discuss or answer what practices any real CA uses in
complying with the high-risk list BR. The thread that followed
contained lots of policy discussion, but almost nothing about what any
real world CA does about the question posed above (are global high risk
names flagged as high risk when used as 2nd level domains or public
suffix+1 level domains).
While I am thrilled that you viewed all of the links, you will find that
the past discussion of what constitutes a "High Risk Domain" is not at all
aligned with the notion you or Matthew is advocating. I can understand your
desire to understand what "real CAs" do, but that's not at all aligned with
what is required, which is the conversation that matters - as are the
reasons for revocation. The simple answer is "It doesn't matter, because
they're not required to, so stop trying to make it seem like they are" -
and the threads all demonstrate the various flaws with the argument being
made/advocated :)
While I hope it is well-intentioned questioning, the answer is irrelevant
to any of the discussions.
What constitutes a high risk domain is mostly up to the CA in question,
and no policy is being proposed to change that.
However a new observation has been made that indicates that at least one
well-behaved CA may have implemented their test against their own list
of high risk subject identities in a way that is subject to a particular
attack (registering the high risk name under an unexpected TLD or
unexpected public suffix).
It is thus relevant, as an incident response investigation (not a policy
change investigation) to figure out if that is indeed a technical
vulnerability in that CA's systems and if so to close the vulnerability
and check for active exploits.
Possible outcomes of such an investigation:
1. That CA does not consider paypal to be a high risk name. This is
within their right, though unexpected.
2. That CA only considers paypal.com to be a high risk name, but not for
example paypal.de (which has a real EV cert for PayPal San Jose).
This is within their right, though unexpected.
3. That CA considers paypal.CCTLD to be high risk, but not paypal.NEWTLD
(e.g. paypal.museum or paypal.bank or paypal.cologne). Again, within
their rights though still somewhat unexpected.
4. This is indeed an implementation or design bug in their automated
software, a fix will be deployed shortly and the database of currently
issued certificates will be retroactively scanned with the new tests.
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
