Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

[Ben Wilson via dev-security-policy]

 Dear Andrew,

The purpose of my email was to alert the Mozilla community of a COVID-19
concern as it arose and to start/continue a dialogue on these COVID-19
matters. I was hoping to get some general feedback to help guide our
COVID-19 policy.

I appreciate the feedback so far. As mentioned in the responses, the CA
will have to come forward to this list with more details about the issues
it faces, that way, the specific merits of its situation can be openly and
transparently evaluated.  If the CA chooses not to come forward, I will
assume that it will comply with the July 1 EKU deadline.

Sincerely yours,

Ben

On Thu, Apr 23, 2020 at 2:56 AM westmail24--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hello Ben,
> What CA you present here?
> Andrew.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

[westmail24--- via dev-security-policy]

Hello Ben,
What CA you present here?
Andrew.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

[Eric Mill via dev-security-policy]

On Sun, Apr 19, 2020 at 2:41 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Dear MDSP community,
>
> As you are aware from past discussions on this list, there has been a
> concern about the impact of COVID-19 on CA operations.  COVID-19 continues
> to impact certain areas of the world more severely than others. For
> example, there has been a recent resurgence of COVID-19 in Japan.[1]
> Globally,
> COVID-19 has not leveled out.[2]
>
> Recently at least one CA has expressed concern about Action 3 of Mozilla's
> January 2020 CA Communication [3] and enforcement of Section 5.2 of
> Mozilla’s Root Store Policy, which provide that as of 1-July-2020,
> end-entity certificates MUST include an EKU extension containing
> KeyPurposeId(s) describing the intended usage(s) of the certificate, and
> the EKU extension MUST NOT contain the KeyPurposeId anyExtendedKeyUsage.
> See [4].
>

(personal capacity)

"At least one CA" is unusually non-transparent for Mozilla, when it comes
to requests for changes to policy. I would generally expect that Mozilla
would ask affected CAs to make their requests to the list to support a more
robust discussion, and to not force Mozilla to act as an intermediary for
CAs.


>
> Some CAs (and their customers) located in Japan, the U.S., and elsewhere
> are dealing with new priorities that were not apparent back in January.
> Some
> have had to reorganize to deal with reduced staff and reallocate resources,
> while other companies have modified their schedules to delay changes that
> might cause instability.[5], [6]
>
> For some parties, the benefit of a 3-month delay (to 1-October-2020) in
> enforcement of Mozilla’s EKU requirement may result in more flexibility,
> resilience and secure operations.
>
> Several options are being considered:
>
> 1.   Require that a CA request an extension, to be submitted on
> Bugzilla and flagged as “covid-19”, similar to audit delays [7] AND
>
> a.   Not require an incident report, OR
>
> b.   Require an incident report
>
> 2.   Grant a blanket 3-month extension and not require revocation of
> certificates that do not comply
>
> 3.   Replace July 1 with October 1 in section 5.2 of the Mozilla Root
> Store Policy and publish a new version
>
> 4.   Recognize broader exceptions for COVID-19 issues, e.g. enlarge the
> scope of the delayed-audit approach to include other non-conformities/other
> issues and not require immediate certificate revocations
>
> I look forward to hearing your opinions and suggestions.
>
> Sincerely yours,
>
> Ben Wilson
>
> Endnotes:
>
> [1]  https://apnews.com/9140ddd7283d534d8464778d9c4bd92a
>
> [2]
>
> https://ourworldindata.org/coronavirus#what-is-the-total-number-of-confirmed-cases
>
> [3]
>
> https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J3waNOW=Q00086,Q00087,Q00097
>
>
> [4]
>
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices
>
> [5]  https://docs.microsoft.com/en-us/security/trusted-root/2020/april2020
>
> [6]
> https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html
>
> [7]  https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>


-- 
Eric Mill
617-314-0966 | konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

[Roland Shoemaker via dev-security-policy]

(Posting in a personal capacity)

I think everyone so far has made valid points about why this is unexpected, and 
a dangerous precedent to set going forward. That said I'd like to reiterate 
that this feels like rewarding undesirable behavior. The CAs that will benefit 
from an exemption, especially one that allows them to take advantage of it 
silently, are those that have chosen to drag their heels until the last 
possible moment.

This behavior should not be encouraged and Mozilla policy should not be 
dictated by the minority of CAs that are holding it back via inaction.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

[Andrew Ayer via dev-security-policy]

Like others, I am concerned with the lack of transparency around this
proposal. Many of the options under consideration would be a departure
from Mozilla's no exceptions policy, which could have serious
consequences that undermine trust in Mozilla's root program.  This
ought to require compelling justification.  Yet the only evidence
provided are two examples of unrelated changes.

It is therefore not clear whether the EKU change (which as others have
pointed out is rather modest) is a problem for the entire industry,
just one CA (and if so, why only them?), or not a problem at all. And
given the history of CAs seizing whatever justification is available at
the moment, no matter how tenuous it may be, to try to delay changes,
the presumption should be that no delay is necessary.  Therefore, Mozilla
should not even be considering these alternatives without the CA first
providing solid evidence of the necessity, in an open and transparent
manner here on m.d.s.p.

Regards,
Andrew


On Sun, 19 Apr 2020 15:41:34 -0600
Ben Wilson via dev-security-policy
 wrote:

> Dear MDSP community,
> 
> As you are aware from past discussions on this list, there has been a
> concern about the impact of COVID-19 on CA operations.  COVID-19
> continues to impact certain areas of the world more severely than
> others. For example, there has been a recent resurgence of COVID-19
> in Japan.[1]  Globally, COVID-19 has not leveled out.[2]
> 
> Recently at least one CA has expressed concern about Action 3 of
> Mozilla's January 2020 CA Communication [3] and enforcement of
> Section 5.2 of Mozilla___s Root Store Policy, which provide that as of
> 1-July-2020, end-entity certificates MUST include an EKU extension
> containing KeyPurposeId(s) describing the intended usage(s) of the
> certificate, and the EKU extension MUST NOT contain the KeyPurposeId
> anyExtendedKeyUsage. See [4].
> 
> Some CAs (and their customers) located in Japan, the U.S., and
> elsewhere are dealing with new priorities that were not apparent back
> in January.  Some have had to reorganize to deal with reduced staff
> and reallocate resources, while other companies have modified their
> schedules to delay changes that might cause instability.[5], [6]
> 
> For some parties, the benefit of a 3-month delay (to 1-October-2020)
> in enforcement of Mozilla___s EKU requirement may result in more
> flexibility, resilience and secure operations.
> 
> Several options are being considered:
> 
> 1.   Require that a CA request an extension, to be submitted on
> Bugzilla and flagged as ___covid-19___, similar to audit delays [7] AND
> 
> a.   Not require an incident report, OR
> 
> b.   Require an incident report
> 
> 2.   Grant a blanket 3-month extension and not require revocation
> of certificates that do not comply
> 
> 3.   Replace July 1 with October 1 in section 5.2 of the Mozilla
> Root Store Policy and publish a new version
> 
> 4.   Recognize broader exceptions for COVID-19 issues, e.g.
> enlarge the scope of the delayed-audit approach to include other
> non-conformities/other issues and not require immediate certificate
> revocations
> 
> I look forward to hearing your opinions and suggestions.
> 
> Sincerely yours,
> 
> Ben Wilson
> 
> Endnotes:
> 
> [1]  https://apnews.com/9140ddd7283d534d8464778d9c4bd92a
> 
> [2]
> https://ourworldindata.org/coronavirus#what-is-the-total-number-of-confirmed-cases
> 
> [3]
> https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J3waNOW=Q00086,Q00087,Q00097
> 
> 
> [4]
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices
> 
> [5]
> https://docs.microsoft.com/en-us/security/trusted-root/2020/april2020
> 
> [6]
> https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html
> 
> [7]  https://wiki.mozilla.org/CA/Audit_Statements#Audit_Delay
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

[Filippo Valsorda via dev-security-policy]

I am also personally surprised and confused by this announcement.

I could imagine of course incident reports being handled with more
leniency when the details reveal that the health emergency contributed
to the issue. I thought that was the point of the no exceptions policy,
to push the CAs to handle the situation as well as possible, and force a
learning process out in the open.

With an opaque exception, the ecosystem is not learning anything about
the circumstances that put the CAs in this situation, and about the
challenges imposed by something that might be a long-term emergency,
giving no opportunity or incentive to improve and avoid similar issues
in the future.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

[Jonathan Rudenberg via dev-security-policy]

On Sun, Apr 19, 2020, at 17:41, Ben Wilson via dev-security-policy wrote:
> Recently at least one CA has expressed concern about Action 3 of Mozilla's
> January 2020 CA Communication [3] and enforcement of Section 5.2 of
> Mozilla’s Root Store Policy

Please have the CA post complete details of their concerns publicly on the 
list. Unlike other root programs, the Mozilla program operates publicly on this 
list and in Bugzilla, as guided by Principle 8 of the Mozilla Manifesto: 
"Transparent community-based processes promote participation, accountability 
and trust." 
 
> Some CAs (and their customers) located in Japan, the U.S., and elsewhere
> are dealing with new priorities that were not apparent back in January.  Some
> have had to reorganize to deal with reduced staff and reallocate resources,
> while other companies have modified their schedules to delay changes that
> might cause instability.[5], [6]

While this may be true generally, it's not clear how this applies to the 
specific case of the EKU requirement. It is important to hear from CAs that 
have not implemented this change yet (if any) with far more detail before 
jumping to the conclusion that changes need to be made to the requirement. 
Given that this is an extremely simple requirement codifying already widely 
implemented best practices that was known many weeks before the impact of 
COVID-19 was felt in most places, it's not immediately clear why it should be a 
problem to deploy with over two months left before the deadline.

> For some parties, the benefit of a 3-month delay (to 1-October-2020) in
> enforcement of Mozilla’s EKU requirement may result in more flexibility,
> resilience and secure operations.

It's not clear to me how changing the EKU field in a certificate profile would 
impact resilience or security. I think it would be more productive to have 
specific public discussions with CAs about challenges in implementing this 
change by the deadline instead of speculating about possible issues.

> Several options are being considered:

Given the complete lack of public discussion about this deadline being a 
problem, I don't think discussing options for a problem that hasn't been 
established as existing yet is productive. Additionally, as Ryan points out, 
most of these options are not compatible with how the program has operated to 
date.

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

Re: COVID-19 Policy (especially EKU Deadline of 1-July-2020)

[Ryan Sleevi via dev-security-policy]

On Sun, Apr 19, 2020 at 5:41 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Recently at least one CA has expressed concern about Action 3 of Mozilla's
> January 2020 CA Communication [3]


What CA?

Transparency seems essential here, for the community, for Mozilla, and for
other CAs. This is a change already required by other Root Programs, and
one Mozilla discussed well in advance of the global pandemic, so it’s
unclear what the challenges are and why three months make a meaningful
difference.

For CAs that went about making timely and effective changes, this only
reinforces the benefits to waiting to the last possible minute and
prioritize other interests and changes, such as those which may not benefit
the community. Think about the employees at these CAs, who agitated for
prompt compliance, against the wishes of those who put short-term benefits
first, and the message this sends to them: It’s not worth it.

For the community, it seems essential to the trust in the ecosystem to
better understand the factors here. For example, if the CA is incapable of
making changes, that’s very concerning. However, equally concerning would
be a CA that placed short-term business interests in a priority over
ecosystem-beneficial changes. That is, is the reason for the delay because
they were doing other things first, or because they’re incapable of doing
things? Having a detailed and holistic picture of the challenges is key to
knowing the reasonableness of the proposal.

For Mozilla, this seems a marked step back from the normal transparency and
certainty of policy. While these are unquestionably challenging times we
are going though, and understanding is needed by all, it’s not clear
whether some of these options are believed to even be viable or reasonable.

Some CAs (and their customers) located in Japan, the U.S., and elsewhere
> are dealing with new priorities that were not apparent back in January.
> Some
> have had to reorganize to deal with reduced staff and reallocate resources,
> while other companies have modified their schedules to delay changes that
> might cause instability.[5], [6]


I think this is a fairly gross and unreasonable comparison to make, unless
the assertion here is that adding EKUs causes some instability that has
been quantified, measured, and has a known-mitigation.

The items you quote were decisions backed by quantifiable and empirical
data about specific sites and backwards-incompatible impact. The changes
proposed here lacks any data to support the conclusion, let alone the
parallel. These comparisons seem quintessentially Apples-to-Orangutans,
although I can understand the appeal being made of “Other changes were
delayed”

Several options are being considered:
>
> 1.   Require that a CA request an extension, to be submitted on
> Bugzilla and flagged as “covid-19”, similar to audit delays [7] AND
>
> a.   Not require an incident report, OR


This seems to be a significant and sudden reversal in Mozilla’s stance that
it does not grant exceptions. It’s unclear how this 1.a. meaningfully or
quantifiably differs from 2.

It also seems to conflict with 1, unless the notion is that there’s a
category in CA compliance that is not CA compliance? That also would be
something new and has been, to date, unnecessary.

In these challenging times, it can certainly be understandable the need to
chart new courses. However, the data from this thread seems to make a very
uncompelling case here, and it seems like it would have lasting impact on
the legitimacy and enforceability of policy through its second order impact.

b.   Require an incident report
>
> 2.   Grant a blanket 3-month extension and not require revocation of
> certificates that do not comply
>
> 3.   Replace July 1 with October 1 in section 5.2 of the Mozilla Root
> Store Policy and publish a new version
>
> 4.   Recognize broader exceptions for COVID-19 issues, e.g. enlarge the
> scope of the delayed-audit approach to include other non-conformities/other
> issues and not require immediate certificate revocations


This seems like a dangerous precedent to set, and one that seems counter to
how Mozilla has operated things for a number of years. There are already CA
incidents being tracked related to COVID-19 other than audits, such as
revocation delays, but there’s been no suggestion to date that Mozilla is
somehow saying it’s acceptable for CAs to ignore the BRs, or that these are
anything less than incidents to be tracked.

I’m concerned that the explanations in this thread don’t even consider the
existing and long-standing approach by Mozilla, which is that Mozilla
doesn’t grant exceptions, and to treat the policy as-is with incident
reports associated for any CA in non-compliance, including those CAs that
anticipate non-compliance before a non-compliance event occurs.

What has changed here, that Mozilla is now considering granting exceptions?
And have the second-order