We currently expect CAs to deliver incident reports whenever they fail to
comply with our policy, but this is not a requirement of our policy. There
is no obvious place to add this in the existing policy, so I propose
creating a new top-level section that reads as follows:

**Incidents**
> When a CA fails to comply with any requirement of this policy - whether it
> be a misissuance, a procedural or operational issue, or any other variety
> of non-compliance - the event is classified as an incident. At a minimum,
> CAs MUST promptly report all incidents to Mozilla in the form of an Incident
> Report <https://wiki.mozilla.org/CA/Responding_To_An_Incident>, and MUST
> regularly update the Incident Report until the corresponding bug is
> resolved by a Mozilla representative. In the case of misissuance, CAs
> SHOULD cease issuance until the problem has been prevented from reoccurring.
>

This is https://github.com/mozilla/pkipolicy/issues/168

It has also been proposed that we add a disclosure of the CA software being
used to the list of topics we expect an incident report to cover. [1] This
addition was proposed before the serial number entropy issue arose, so it
is more than a reaction to that specific issue. I propose adding the
following item to the list of incident report topics:

>
> Information about the CA software used to generate the certificates. For
> COTS <https://en.wikipedia.org/wiki/Commercial_off-the-shelf> solutions,
> provide the name, vendor, and version of the software in use. For
> home-grown solutions, provide information about the architecture including
> the name and version of relevant 3rd party components.
>

This is https://github.com/mozilla/pkipolicy/issues/162

I will greatly appreciate everyone's input on these proposals.

- Wayne

[1] https://wiki.mozilla.org/CA/Responding_To_An_Incident
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to