On Mon, Oct 7, 2019 at 11:54 AM Jeremy Rowley <jeremy.row...@digicert.com>
wrote:

> Are both roots trusted in the Mozilla root store? If so, could you say
> that Mozilla has approved of the root not-withstanding the non-compliance?
> If root 2 did go through the public review process and had the public look
> at the certificate and still got embedded, then Mozilla perhaps signed off
> on the root.
>

Good question!

Yes, it turns out that a version of this cross-sign is included, and while
there was a public discussion phase, this non-compliance was not detected
during the inclusion request nor part of the discussion. In fact, there
were zero comments during the public discussion phase.


> That said, I don't personally see the harm in incident reports (other than
> the fact that they can be used for negative marketing). They are there for
> documenting issues and making the public aware of issues. Like qualified
> audits, they don't necessarily mean something terrible since they represent
> a disclosure/record of some kind. Even if the incident report is open,
> discussed, and closed pretty quickly, then you end up with an a record that
> can be pointed to.  Filing more incident report (as long as they are
> different issues) is a good thing as it gives extra transparency in the
> CA's operations that is easily discoverable and catalogable. Makes data
> analytics easier and you can go back through the incidents to see how
> things are changing with the CA.
>

Well, the reason I raised it here, rather than as an incident, was to try
and nail down the expectations here. For example, would it be better to
have that discussion on the incident, with "Foo" arguing "You approved it,
ergo it's not a violation to cross-sign it"? Or would it be better to have
visibility here, perhaps in the abstract (even if it is trivial to scan CT
and figure out which CA I'm talking about), if only to get folks
expectations here on whether or not new certificates should be signed that
violate the BRs?
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to