Thanks for raising this, Ian. The question and concern about QIIS is extremely reasonable. As discussed in past CA/Browser Forum activities, some CAs have extended the definition to treat Google Maps as a QIIS (it is not), as well as third-party WHOIS services (they’re not; that’s using a DTP).
In the discussions, I proposed a comprehensive set of reforms that would wholly remedy this issue. Given that the objective of OV and EV certificates is nominally to establish a legal identity, and the legal identity is derived from State power of recognition, I proposed that only QGIS be recognized for such information. This wholly resolves differences in interpretation on suitable QIIS. However, to ensure there do not also emerge conflicting understandings of appropriate QGIS - and in particular, since the BRs and EVGs recognize a variety of QGIS’s with variable levels of assurance relative to the information included - I further suggested that the determination of a QGIS for a jurisdictional boundary should be maintained as a normative whitelist that can be interoperably used and assessed against. If a given jurisdiction is not included within that whitelist, or the QGIS is not on it, it cannot be used. Additions to that whitelist can be maintained by the Forum, based on an evaluation of the suitability of that QGIS for purpose, and a consensus for adoption. This would significantly reduce the risk, while also further reducing ambiguities that have arisen from some CAs attempting to argue that non-employees of the CA or QGIS, but which act as intermediaries on behalf of the CA to the QGIS, are not functionally and formally DTPs and this subject to the assessment requirements of DTPs. This ambiguity is being exploited in ways that can allow a CA to nominally say it checked a QGIS, but is relying on the word of a third-party, and with no assurance of the system security of that third party. Do you think such a proposal would wholly address your concern? _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
