Re: Policy 2.7 Proposal: Incident Reporting Updates

[Wayne Thayer via dev-security-policy]

On Tue, Oct 22, 2019 at 7:41 PM Ryan Sleevi  wrote:

>
> On Tue, Oct 22, 2019 at 9:51 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> I have added this proposal to the 2.7 branch:
>>
>> https://github.com/mozilla/pkipolicy/commit/fa843039285b10030490c7eb54d1b754edae1fbc
>>
>> I will greatly appreciate everyone's feedback on these changes.
>
>
> This is almost entirely on the typographical side:
> items 1-4 use ; at the end of line. Item 5 uses "; and", and item 6 ends
> with "."
>
> If the desire is to keep that structure, then I think the following
> changes are needed:
> - item 5 has "; and" changed to ";"
> - item 6 has "." changed to "; and"
> - Item 7 has "Ensure" changed to "ensure"
>

Thanks for catching this Ryan. I've fixed these issues.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Incident Reporting Updates

[Ryan Sleevi via dev-security-policy]

On Tue, Oct 22, 2019 at 9:51 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I have added this proposal to the 2.7 branch:
>
> https://github.com/mozilla/pkipolicy/commit/fa843039285b10030490c7eb54d1b754edae1fbc
>
> I will greatly appreciate everyone's feedback on these changes.


This is almost entirely on the typographical side:
items 1-4 use ; at the end of line. Item 5 uses "; and", and item 6 ends
with "."

If the desire is to keep that structure, then I think the following changes
are needed:
- item 5 has "; and" changed to ";"
- item 6 has "." changed to "; and"
- Item 7 has "Ensure" changed to "ensure"
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Incident Reporting Updates

[Wayne Thayer via dev-security-policy]

Having received no comments, I did not add the proposed guidance on status
update frequency, but I did make the "marked as resolved" change that
Jeremy suggested:
https://github.com/mozilla/pkipolicy/commit/bad3fedc10e1fe9d5237760093ad235326e3bd62

An additional related change has been proposed in issue #193 [1]: require
incident disclosure transitively for all sub-CAs. In the issue, it was
pointed out that  the expectations for incident reporting by subordinate
CAs might not be clear, and a number of options were presented. I proposed
that the most important point to make in policy is that Mozilla holds the
program member (i.e. root CA) accountable.

Ryan suggested the following addition to the list of requirements in
section 2.1 to clarify this requirement:

The CA whose certificates are included in Mozilla's root program MUST
ensure that all certificates within the scope of this policy, as described
in Section 1.1, adhere to this policy.

I have added this proposal to the 2.7 branch:
https://github.com/mozilla/pkipolicy/commit/fa843039285b10030490c7eb54d1b754edae1fbc

I will greatly appreciate everyone's feedback on these changes.

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues/193

On Fri, Oct 4, 2019 at 4:22 PM Wayne Thayer  wrote:

> Jeremy Rowley posted the following comments in a separate thread:
>
> One suggestion on incident reports is to define "regularly update" as some
>> period of time as non-responses can result in additional incident reports.
>> Maybe something along the lines of "the greater of every 7 days, the time
>> period specified in the next update field by Mozilla, or the time period
>> for the next update as agreed upon with Mozilla". I'd also change "the
>> corresponding bug is resolved by a Mozilla representative" to "the
>> corresponding bug is marked as resolved in bugzilla by a Mozilla
>> representative" since the CA is resolving the actual bug, and Mozilla is
>> managing its perception on the bug's status.
>>
>
> While I agree with the intent, I do fear that something this strict in
> policy creates the wrong incentives (e.g. bots that auto-comment bugs with
> no real updates, and others that create new incidents after 7 days and one
> second). I'd be okay with adding something like "CAs SHOULD update status
> weekly and MUST provide status updates at least every 30 days unless
> otherwise agreed by a Mozilla representative."
>
> The addition of "marked as resolved" makes sense to me.
>
> On Tue, Apr 23, 2019 at 4:15 PM Wayne Thayer  wrote:
>
>>
>> On Tue, Apr 16, 2019 at 12:02 PM Wayne Thayer 
>> wrote:
>>
>>>
>>> I've drafted a specific proposal for everyone's consideration:
>>>
>>>
>>> https://github.com/mozilla/pkipolicy/commit/5f1b0961fa66f824adca67d7021cd9c9c62a88fb
>>>
>>>
>> Having received no new comments on this proposal, I'll consider this
>> issue closed and plan to include it in policy version 2.7.
>>
>> - Wayne
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Incident Reporting Updates

[Wayne Thayer via dev-security-policy]

Jeremy Rowley posted the following comments in a separate thread:

One suggestion on incident reports is to define "regularly update" as some
> period of time as non-responses can result in additional incident reports.
> Maybe something along the lines of "the greater of every 7 days, the time
> period specified in the next update field by Mozilla, or the time period
> for the next update as agreed upon with Mozilla". I'd also change "the
> corresponding bug is resolved by a Mozilla representative" to "the
> corresponding bug is marked as resolved in bugzilla by a Mozilla
> representative" since the CA is resolving the actual bug, and Mozilla is
> managing its perception on the bug's status.
>

While I agree with the intent, I do fear that something this strict in
policy creates the wrong incentives (e.g. bots that auto-comment bugs with
no real updates, and others that create new incidents after 7 days and one
second). I'd be okay with adding something like "CAs SHOULD update status
weekly and MUST provide status updates at least every 30 days unless
otherwise agreed by a Mozilla representative."

The addition of "marked as resolved" makes sense to me.

On Tue, Apr 23, 2019 at 4:15 PM Wayne Thayer  wrote:

>
> On Tue, Apr 16, 2019 at 12:02 PM Wayne Thayer  wrote:
>
>>
>> I've drafted a specific proposal for everyone's consideration:
>>
>>
>> https://github.com/mozilla/pkipolicy/commit/5f1b0961fa66f824adca67d7021cd9c9c62a88fb
>>
>>
> Having received no new comments on this proposal, I'll consider this issue
> closed and plan to include it in policy version 2.7.
>
> - Wayne
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Incident Reporting Updates

[Wayne Thayer via dev-security-policy]

On Tue, Apr 16, 2019 at 12:02 PM Wayne Thayer  wrote:

>
> I've drafted a specific proposal for everyone's consideration:
>
>
> https://github.com/mozilla/pkipolicy/commit/5f1b0961fa66f824adca67d7021cd9c9c62a88fb
>
>
Having received no new comments on this proposal, I'll consider this issue
closed and plan to include it in policy version 2.7.

- Wayne
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Incident Reporting Updates

[Wayne Thayer via dev-security-policy]

On Fri, Mar 29, 2019 at 11:59 AM Wayne Thayer  wrote:

> On Thu, Mar 28, 2019 at 5:29 PM Ryan Sleevi  wrote:
>
>>
>> On Thu, Mar 28, 2019 at 7:42 PM Wayne Thayer  wrote:
>>
>>> On Thu, Mar 28, 2019 at 4:11 PM Ryan Sleevi  wrote:
>>>
 On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy <
 dev-security-policy@lists.mozilla.org> wrote:

> **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 , 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.
>
 For comparison, Microsoft's policy is
 https://aka.ms/rootcert#d-ca-responsibilities-in-the-event-of-an-incident

>>> Thanks for the reference. I would note that Microsoft's requirements
>>> appear to be much narrower in scope, applying to "Security Incidents" as
>>> defined in section 6. Having said that, are there specific requirements
>>> that we should consider adding to Mozilla policy?
>>>
>>
>> There are two things that stand out to me that are unclear if you meant
>> to incorporate by reference to the incident report:
>> - Whether it's a policy violation if the CA fails to disclose the
>> affected certificates, which MSFT policy explicitly requires
>>
>
> We would only want this if the certificates were disclosed publicly, and
> that seems challenging. TLS certs will, of course, be logged because of
> other UA's requirements, but for email certs CAs may not have the
> contractual right to disclose publicly. And "GDPR".
>
> - What, if any, timeframe for periodic updates. MSFT policy explicitly
>> states that MSFT shall determine the update cadence. (This may be a
>> non-issue)
>>
>> Conceptually this makes sense, but I would be interested to hear your
> thoughts on what our requirement should be? A one-size-fits-all requirement
> of something like weekly updates could be an enforcement nightmare. We
> already assume the right to set deadlines for responses, so it's not
> obvious to me what we'd want in this requirement.
>
> Additionally, in further consideration of both this proposal and the
>> highlighted difference, it's unclear whether it's intended to create a
>> hierarchy of incidents. I think the language, as worded, does - perhaps
>> inadvertantly - by mentioning misissuance vs a procedural or operational
>> issue.
>>
>> Consider, for example, a CA that determines they're copying the O field
>> directly from CSRs into the final certificates. Such certificates are
>> unquestionably misissued, but the language creates the opportunity that the
>> CA would argue it's a "procedural or operational" issue, and thus they're
>> not required to cease issuance until the problem has been prevented.
>>
>
> This language was cribbed from the wiki page: "In misussuance cases, a CA
> should almost always immediately cease issuance from the affected part of
> your PKI until you have diagnosed the source of the problem, or explain why
> this has not been done"
>
> Perhaps it shouldn't try to account for things like OCSP misconfiguration
> and only state: "CAs SHOULD cease issuance until the problem has been
> prevented from reoccurring."?
>
>

I've drafted a specific proposal for everyone's consideration:

https://github.com/mozilla/pkipolicy/commit/5f1b0961fa66f824adca67d7021cd9c9c62a88fb


>> One thing to consider with such a policy is whether to formalize the use
 of Bugzilla to track these. In looking through incident reports that have
 been filed, we see a fair distribution between the initial reporting being
 on the email list vs Bugzilla. We've certainly seen Bugzilla be more useful
 in tracking unacknowledged questions and responses (via the use of
 Needs-Info). Would it make sense to require that the incident report be
 provided via Bugzilla, with a notification to the mail list?

>>>
>>> I would be interested in everyone's opinion on this. While I agree that
>>> Bugzilla is a necessary mechanism for tracking incidents, I believe that it
>>> reduces community visibility and makes it more difficult for most members
>>> to follow incident discussions. It has been suggested that we create a
>>> process that automatically publishes a summary of new or updated incident
>>> bugs to this list on a periodic basis, but that obviously isn't yet in
>>> place. Even with that, I might argue that the requirement should be to
>>> publish incident reports to m.d.s.p., with a bug then being created by the
>>> CA or a Moz

Re: Policy 2.7 Proposal: Incident Reporting Updates

[Wayne Thayer via dev-security-policy]

On Thu, Mar 28, 2019 at 5:29 PM Ryan Sleevi  wrote:

>
> On Thu, Mar 28, 2019 at 7:42 PM Wayne Thayer  wrote:
>
>> On Thu, Mar 28, 2019 at 4:11 PM Ryan Sleevi  wrote:
>>
>>> On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>>
 **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 , 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.

>>> For comparison, Microsoft's policy is
>>> https://aka.ms/rootcert#d-ca-responsibilities-in-the-event-of-an-incident
>>>
>> Thanks for the reference. I would note that Microsoft's requirements
>> appear to be much narrower in scope, applying to "Security Incidents" as
>> defined in section 6. Having said that, are there specific requirements
>> that we should consider adding to Mozilla policy?
>>
>
> There are two things that stand out to me that are unclear if you meant to
> incorporate by reference to the incident report:
> - Whether it's a policy violation if the CA fails to disclose the affected
> certificates, which MSFT policy explicitly requires
>


We would only want this if the certificates were disclosed publicly, and
that seems challenging. TLS certs will, of course, be logged because of
other UA's requirements, but for email certs CAs may not have the
contractual right to disclose publicly. And "GDPR".

- What, if any, timeframe for periodic updates. MSFT policy explicitly
> states that MSFT shall determine the update cadence. (This may be a
> non-issue)
>
>
Conceptually this makes sense, but I would be interested to hear your
thoughts on what our requirement should be? A one-size-fits-all requirement
of something like weekly updates could be an enforcement nightmare. We
already assume the right to set deadlines for responses, so it's not
obvious to me what we'd want in this requirement.

Additionally, in further consideration of both this proposal and the
> highlighted difference, it's unclear whether it's intended to create a
> hierarchy of incidents. I think the language, as worded, does - perhaps
> inadvertantly - by mentioning misissuance vs a procedural or operational
> issue.
>
> Consider, for example, a CA that determines they're copying the O field
> directly from CSRs into the final certificates. Such certificates are
> unquestionably misissued, but the language creates the opportunity that the
> CA would argue it's a "procedural or operational" issue, and thus they're
> not required to cease issuance until the problem has been prevented.
>


This language was cribbed from the wiki page: "In misussuance cases, a CA
should almost always immediately cease issuance from the affected part of
your PKI until you have diagnosed the source of the problem, or explain why
this has not been done"

Perhaps it shouldn't try to account for things like OCSP misconfiguration
and only state: "CAs SHOULD cease issuance until the problem has been
prevented from reoccurring."?


>
> One thing to consider with such a policy is whether to formalize the use
>>> of Bugzilla to track these. In looking through incident reports that have
>>> been filed, we see a fair distribution between the initial reporting being
>>> on the email list vs Bugzilla. We've certainly seen Bugzilla be more useful
>>> in tracking unacknowledged questions and responses (via the use of
>>> Needs-Info). Would it make sense to require that the incident report be
>>> provided via Bugzilla, with a notification to the mail list?
>>>
>>
>> I would be interested in everyone's opinion on this. While I agree that
>> Bugzilla is a necessary mechanism for tracking incidents, I believe that it
>> reduces community visibility and makes it more difficult for most members
>> to follow incident discussions. It has been suggested that we create a
>> process that automatically publishes a summary of new or updated incident
>> bugs to this list on a periodic basis, but that obviously isn't yet in
>> place. Even with that, I might argue that the requirement should be to
>> publish incident reports to m.d.s.p., with a bug then being created by the
>> CA or a Mozilla representative.
>>
>
> I do share those concerns, hence the attempt to split it in the middle.
>
> My concern is that there have been several high-profile incidents which
> have been discussed in m.d.s.p., in which very relevant questions from
> members of the community go ignored, perhaps deliberately, and it b

Re: Policy 2.7 Proposal: Incident Reporting Updates

[Ryan Sleevi via dev-security-policy]

On Thu, Mar 28, 2019 at 7:42 PM Wayne Thayer  wrote:

> On Thu, Mar 28, 2019 at 4:11 PM Ryan Sleevi  wrote:
>
>> On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> **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 , 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.
>>>
>> For comparison, Microsoft's policy is
>> https://aka.ms/rootcert#d-ca-responsibilities-in-the-event-of-an-incident
>>
> Thanks for the reference. I would note that Microsoft's requirements
> appear to be much narrower in scope, applying to "Security Incidents" as
> defined in section 6. Having said that, are there specific requirements
> that we should consider adding to Mozilla policy?
>

There are two things that stand out to me that are unclear if you meant to
incorporate by reference to the incident report:
- Whether it's a policy violation if the CA fails to disclose the affected
certificates, which MSFT policy explicitly requires
- What, if any, timeframe for periodic updates. MSFT policy explicitly
states that MSFT shall determine the update cadence. (This may be a
non-issue)

Additionally, in further consideration of both this proposal and the
highlighted difference, it's unclear whether it's intended to create a
hierarchy of incidents. I think the language, as worded, does - perhaps
inadvertantly - by mentioning misissuance vs a procedural or operational
issue.

Consider, for example, a CA that determines they're copying the O field
directly from CSRs into the final certificates. Such certificates are
unquestionably misissued, but the language creates the opportunity that the
CA would argue it's a "procedural or operational" issue, and thus they're
not required to cease issuance until the problem has been prevented.

One thing to consider with such a policy is whether to formalize the use of
>> Bugzilla to track these. In looking through incident reports that have been
>> filed, we see a fair distribution between the initial reporting being on
>> the email list vs Bugzilla. We've certainly seen Bugzilla be more useful in
>> tracking unacknowledged questions and responses (via the use of
>> Needs-Info). Would it make sense to require that the incident report be
>> provided via Bugzilla, with a notification to the mail list?
>>
>
> I would be interested in everyone's opinion on this. While I agree that
> Bugzilla is a necessary mechanism for tracking incidents, I believe that it
> reduces community visibility and makes it more difficult for most members
> to follow incident discussions. It has been suggested that we create a
> process that automatically publishes a summary of new or updated incident
> bugs to this list on a periodic basis, but that obviously isn't yet in
> place. Even with that, I might argue that the requirement should be to
> publish incident reports to m.d.s.p., with a bug then being created by the
> CA or a Mozilla representative.
>

I do share those concerns, hence the attempt to split it in the middle.

My concern is that there have been several high-profile incidents which
have been discussed in m.d.s.p., in which very relevant questions from
members of the community go ignored, perhaps deliberately, and it becomes
difficult to track in all of the discussion what those points were.
However, I suppose the same issue may similarly exist if tracking the
discussion through Bugzilla. This suggestion may end up being orthogonal to
the policy update question, but it's one largely motivated by wanting to
either make sure CAs are aware of the need to respond to questions - or to
make sure that it's accurately noted when CAs ignore or otherwise fail to
do so.

>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7 Proposal: Incident Reporting Updates

[Wayne Thayer via dev-security-policy]

On Thu, Mar 28, 2019 at 4:11 PM Ryan Sleevi  wrote:

>
> On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> 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 , 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.
>> >
>>
>
> For comparison, Microsoft's policy is
> https://aka.ms/rootcert#d-ca-responsibilities-in-the-event-of-an-incident
>
>
Thanks for the reference. I would note that Microsoft's requirements appear
to be much narrower in scope, applying to "Security Incidents" as defined
in section 6. Having said that, are there specific requirements that we
should consider adding to Mozilla policy?

One thing to consider with such a policy is whether to formalize the use of
> Bugzilla to track these. In looking through incident reports that have been
> filed, we see a fair distribution between the initial reporting being on
> the email list vs Bugzilla. We've certainly seen Bugzilla be more useful in
> tracking unacknowledged questions and responses (via the use of
> Needs-Info). Would it make sense to require that the incident report be
> provided via Bugzilla, with a notification to the mail list?
>
>
I would be interested in everyone's opinion on this. While I agree that
Bugzilla is a necessary mechanism for tracking incidents, I believe that it
reduces community visibility and makes it more difficult for most members
to follow incident discussions. It has been suggested that we create a
process that automatically publishes a summary of new or updated incident
bugs to this list on a periodic basis, but that obviously isn't yet in
place. Even with that, I might argue that the requirement should be to
publish incident reports to m.d.s.p., with a bug then being created by the
CA or a Mozilla representative.

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 
>> 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
>
>
> As one of the people most frequently exploring incident reports, I do not
> believe this will provide substantial value with respect to the incident
> reporting process. There certainly is an element of curiosity and
> applicability in the case of some bugs, but I do not believe it provides a
> particular value as a blanket requirement. My experience with such
> information is that it more commonly highlights when a CA may be failing to
> adhere to the NCSSRs or their auditor reaching a conclusion different from
> them, rather than being particular to the incident reports.
>
> Would it make more sense to consider this as part of audit reporting and
> disclosure? Namely, that the CA's annual disclosure MUST include such a
> disclosure?
>
>
Either as part of an incident report or an annual disclosure, I don't feel
that this information would be terribly valuable in most situations, and
where it is we can ask for it. Would anyone like to speak in favor of this
change?

I do worry that, regardless of the method chosen, it will be difficult to
> determine whether or not it provides value. For example, given the
> open-source nature of EJBCA, a CA might disclose they use "Custom
> software", when in fact, all they changed was a single line of an EJBCA
> file to thus "customize it". We thus learn nothing 'useful'. Even in the
> cases where this was referred to (KIR S.A. and the serial number incident),
> the disclosure of the software would not ha

Re: Policy 2.7 Proposal: Incident Reporting Updates

[Ryan Sleevi via dev-security-policy]

On Thu, Mar 28, 2019 at 6:45 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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 , 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.
> >
>

For comparison, Microsoft's policy is
https://aka.ms/rootcert#d-ca-responsibilities-in-the-event-of-an-incident

One thing to consider with such a policy is whether to formalize the use of
Bugzilla to track these. In looking through incident reports that have been
filed, we see a fair distribution between the initial reporting being on
the email list vs Bugzilla. We've certainly seen Bugzilla be more useful in
tracking unacknowledged questions and responses (via the use of
Needs-Info). Would it make sense to require that the incident report be
provided via Bugzilla, with a notification to the mail list?

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  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


As one of the people most frequently exploring incident reports, I do not
believe this will provide substantial value with respect to the incident
reporting process. There certainly is an element of curiosity and
applicability in the case of some bugs, but I do not believe it provides a
particular value as a blanket requirement. My experience with such
information is that it more commonly highlights when a CA may be failing to
adhere to the NCSSRs or their auditor reaching a conclusion different from
them, rather than being particular to the incident reports.

Would it make more sense to consider this as part of audit reporting and
disclosure? Namely, that the CA's annual disclosure MUST include such a
disclosure?

I do worry that, regardless of the method chosen, it will be difficult to
determine whether or not it provides value. For example, given the
open-source nature of EJBCA, a CA might disclose they use "Custom
software", when in fact, all they changed was a single line of an EJBCA
file to thus "customize it". We thus learn nothing 'useful'. Even in the
cases where this was referred to (KIR S.A. and the serial number incident),
the disclosure of the software would not have provided any new insight;
EJBCA could have been configured to a more expansive serial number, and
there were enough other issues re: KIR S.A. that the choice of CA software
was hardly the high-order bit.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Policy 2.7 Proposal: Incident Reporting Updates

[Wayne Thayer via dev-security-policy]

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 , 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  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