On 17/04/2018 00:13, Ryan Sleevi wrote:
On Mon, Apr 16, 2018 at 3:22 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
If that CA has a practice that they actually do something about high
risk names, it would still be expected (in the normal, not legal,
sense of the word) for that CA to include PayPal on their list of
such names.
If you expect that, you're absolutely wrong for expecting that, because
that's not what a High Risk Request is.
I am not the only one with that expectation. In the concrete case the
expectation was succinctly stated by Mathew in Message-ID
mailman.312.1523571519.2176.dev-security-policy at lists.mozilla.org as
Mathew> With respect to domain name labels, all CAs maintain high risk
Mathew> lists. I doubt XXXX would issue for
Mathew> paypal.any_valid_tld even if CAA would permit.
[ Name of CA elided ]
You can't simply ignore the very definition and requirements and attempt to
argue it should be anything.
The definition is in section 1.6.1 of the BRs and does not limit itself
to blacklisted site names. The most illustrative part of this
definition being the inclusion on the suggestive list of "names
contained in previously rejected certificate requests". Fraudulent and
thus rejected requests for highly-prominent subject names by someone who
is not that prominent entity seem reasonably common enough to often be
rejected for failing to validate, and also seem to be the kind of name
that would require additional scrutiny to ensure the request is from the
real entity as part of a CA-specific risk-mitigation strategy.
If the list in the definition in 1.6.1 is considered limiting in what
can be treated as a High Risk Certificate Request, the inclusion of
checks for selected VIP names would fall under "names at higher risk for
phishing or other fraudulent usage", with the phishing case being
grabbing that name under an unexpected TLD for phishing purposes, and
the "other fraudulent usage" case being trying to get a certificate for
the real DNS name without being the entity that actually has that domain
name.
Note that this is not a sunset or trademark like rejection mechanism, it
is an "additional scrutiny" criteria, meaning that a CA could still
issue after doing their "additional scrutiny" as defined by the CA
written procedures.
But just to please your pedantry, I will add two additional outcome
options:
-1. Thay CA does not really check for high risk names at all. This
might be permitted by some readings of BR 4.2.1 / Ballot 78.
It absolutely is permitted, and not a negative. Your expectations are
wrong, and you should adjust them, because they're not based in reality.
BR 4.2.1 is a SHALL, not a SHOULD.
0. That CA uses a form of "additional scrutiny" for "High Risk
Certificate Requests" which is sufficiently weak as to still allow
this proof of concept incident.
It's not sufficiently weak, for any sense, because it's not defined what
weak or strong is.
Weak is a common security term and a common English term with similar
meaning in both contexts.
The language in BR 4.2.1 expresses the minimum goals of the CA
procedures (ensure proper verification under the BRs), but leaves
reasonably open the ability of a CA to strengthen this to also ensure
proper verification in some (CA defined) broader sense. Thus weak
versus strong refers to the ability of the procedures to achieve those
BR and CA goals. Only the CA can state what their broader goals for
their high risk procedures are and why they consider their procedures
sufficient to achieve those goals.
The question asked by Matthew and me, and which you keep blocking, is if
jomo has publicly disclosed a case in which that CA's procedures
accidentally fail to achieve that CA's security goals for those
procedures. This is a perfectly normally vulnerability issue
investigation, which jomo (not I) made public 4 days ago.
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
