I agree with Corey. On Wed, Jun 12, 2019 at 4:28 AM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> That argument applies to every extension not expressly permitted by the > BRs. Yup. It definitely puts the onus on the CA to demonstrate how they're not violating, and to put a clear and cogent argument forward as to how it meets that constraint. > Even if I just put a number in s private extension, a relying party could > be led to think jts their age. I think one way a CA would respond to a complaint that this was misissuance would be to refer to an appropriate specification or draft that defines how it is not. > Can we better define what could constitute as potentially misleading > extensions? Without that definition, this is the same as saying mo > additional extensions are allowed, which is clearly not the intent of the > existing language. Minimally, Subject Identity Information (or some modification therein to indicate it's applicable to the Subscriber/Applicant/Subject and not just the Certificate's Subject distinguishedName field) This would mean, for example, that any element of logoType, LEI, or alternative naming schemes would fundamentally be SII. The CA would have to demonstrate how the information included was verified, but also not applicable to the Subscriber/Applicant/Subject. The downside to this approach is that it's still not sufficient to address "stupidity". For example, I can imagine a CA would exploit such a language loophole by, say, including the Mozilla logo in a certificate for Google, arguing that they verified that the Mozilla logo had been verified as belonging to Mozilla. However, that should still be a 'clear' violation of 7.1.2.4(b). A more extreme version would be to argue that 7.1.2.4(b) would forbid anything without an appropriate definition for how that information is verified in a public context, and what those standards might be (e.g. W3C, IETF, ETSI?) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
