Re: Proposal: Make readable CPSes easier to find

[Matt Palmer via dev-security-policy]

On Tue, Apr 21, 2020 at 01:23:49AM -0400, Ryan Sleevi wrote:
> On Mon, Apr 20, 2020 at 10:04 PM Matt Palmer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > 1. Make cPSuri mandatory
> 
> We really don’t need to be stuffing everything into subscriber
> certificates, especially when it’s relevant to who the issuer is. We also
> need to make sure we are optimizing for the right case - the vast majority
> of certificates who, for their entire lifetime, have no need to express the
> CPS URI, and would waste countless bytes (and electrons and fossil fuel)
> unnecessarily.

That ship sailed so very, very long ago, though.  Practically every
certificate out there already provides a (far less useful) cPSuri, and many
certificates are also jammed full of all sorts of other cruft, like Explicit
Text.

> 2. Make the cPSuri actually point to the relevant CPS
> 
> That doesn’t really capture what a CPS is. There can be many relevant CPSes
> to a single certificate, both for a single path and multiple paths. That’s
> literally how audits came to be - to support the model of multiple CPSes.

>From what I can see in a CSV o' Doom, a CA can only provide a single CPS
link for a given intermediate.  That does rather suggest that there's only
one CPS for a given certificate.

> The problem is that a CA's repository, or "online information provided by
> > the CA", typically looks something like this:
> >
> >  * CPS for Device PKI
> >  * Frambingaling CP and CPS v2.1
> >  * Latest Certificate Practice Statement for Small Furry Creatures
> >  * Subscriber Agreement and Addendum for Something Something
> >
> > ... and so on.  How I get from "I have a certificate that I need to
> > report",
> > which contains an issuer CN and not much else, to the correct document out
> > of that list above, is a non-trivial problem.  Having the cPSuri point *to
> > the CPS* would completely solve that.
> 
> Do you disagree? If Mozilla Policy made normative that there be some form
> of binding problem reporting statement for each issuer certificate, would
> that address your problem or not?

Not particularly, because while problem reporting addresses are the major
part of why I have gone looking for CPSes in the recent past, it is not the
only reason.

- Matt

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

Re: Proposal: Make readable CPSes easier to find

[Ryan Sleevi via dev-security-policy]

On Mon, Apr 20, 2020 at 10:04 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> A major difficulty I found in trying to report compromised keys to CAs was
> in finding a reporting address to use.  Now, by itself, that could be
> solved
> by making CCADB reporting addresses be authoritative, but that would also
> require standardisation of reporting types, and it's a whole rabbit hole.
> There are also many other reasons why someone might want to examine the CPS
> that pertains to a particular certificate, so it makes sense to be able to
> easily find that document as and when required.
>
> Being unable to find the correct CPS for a CA had several causes:
>
> 1. Certificates don't *have* to have a cPSuri (although the vast majority
> do);
>
> 2. cPSuri, when present, doesn't point at a CPS, but rather at a CA's
> repository, which often contains a myriad of documents which often are
> unclearly related to the certificate in hand;
>
> 3. When a relevant-looking CPS is found, it can be in a non-English
> language, with no clear pointers to the location of the (Mozilla-required)
> non-authoritative English translation of that document.
>
> My various sub-proposals are, unsurprisingly, closely aligned to these
> sub-issues.
>
> 1. Make cPSuri mandatory


I really appreciate that you first framed the problem you were trying to
solve, before offering a solution. Despite my disagreement (and I do not
support these ideas), knowing the problems you’re trying to solve with them
at least help us try to find better solutions :)

I don’t think you can just be dismissive about “it bloats certificates”
when we continue to see that presents a challenge to new protocols. Just
look at the work on certificate compression in the IETF.

We really don’t need to be stuffing everything into subscriber
certificates, especially when it’s relevant to who the issuer is. We also
need to make sure we are optimizing for the right case - the vast majority
of certificates who, for their entire lifetime, have no need to express the
CPS URI, and would waste countless bytes (and electrons and fossil fuel)
unnecessarily.

This is exactly the sort of case CCADB is supremely positioned to solve,
efficiently. In fact, all of these problems can be addressed by CCADB
improvements, providing programmatically readable data while also making
use of efficiencies and economies of scale.

There were alternatives, for sure; the notion of machine readable CPSes is
*why* we have CPS structure in the first place, but getting “CPS
Validation” the way we have ALV is... a bigger change. Luckily, CAs can
configure CCADB themselves.

When there's no link to a CPS, in any way shape or form, I'm left flailing
> around in the giant CCADB CSV o' doom to figure out where the CPS lives,
> and
> that...  ain't easy.  In one case, I sent a problem report to *completely*
> the wrong CA.  If each certificate had a link to the right place, that
> problem, at least, couldn't happen.


I can understand and appreciate CSVs are hard. I don’t think they justify
costing users and providers tens of millions of dollars to make your life
easier. Which is what those bytes cost, in very real terms. That’s ... not
a good trade-off.

To that end, figuring out ways to make this data easier, or open-source
tools to assist and transform, is not at all unreasonable.

2. Make the cPSuri actually point to the relevant CPS


That doesn’t really capture what a CPS is. There can be many relevant CPSes
to a single certificate, both for a single path and multiple paths. That’s
literally how audits came to be - to support the model of multiple CPSes.

So a statement like “the relevant CPS” is going to be flawed, for better or
worse. That’s a much bigger change to make (in how policies are managed).
Despite the merits of forbidding the policy-based approach proposed by the
ABA PAG, the problem reporting email is probably the least compelling
reason for scrapping that :(

However, that seems moot if addressed as above?

The problem is that a CA's repository, or "online information provided by
> the CA", typically looks something like this:
>
>  * CPS for Device PKI
>  * Frambingaling CP and CPS v2.1
>  * Latest Certificate Practice Statement for Small Furry Creatures
>  * Subscriber Agreement and Addendum for Something Something
>
> ... and so on.  How I get from "I have a certificate that I need to
> report",
> which contains an issuer CN and not much else, to the correct document out
> of that list above, is a non-trivial problem.  Having the cPSuri point *to
> the CPS* would completely solve that.


So would CCADB. crt.sh is one easy way for one to link things.

Do you disagree? If Mozilla Policy made normative that there be some form
of binding problem reporting statement for each issuer certificate, would
that address your problem or not?

3. Require non-English language CPSes to link to the English translation


CCADB can solve this. It also seems a 

Proposal: Make readable CPSes easier to find

[Matt Palmer via dev-security-policy]

A major difficulty I found in trying to report compromised keys to CAs was
in finding a reporting address to use.  Now, by itself, that could be solved
by making CCADB reporting addresses be authoritative, but that would also
require standardisation of reporting types, and it's a whole rabbit hole. 
There are also many other reasons why someone might want to examine the CPS
that pertains to a particular certificate, so it makes sense to be able to
easily find that document as and when required.

Being unable to find the correct CPS for a CA had several causes:

1. Certificates don't *have* to have a cPSuri (although the vast majority
do);

2. cPSuri, when present, doesn't point at a CPS, but rather at a CA's
repository, which often contains a myriad of documents which often are
unclearly related to the certificate in hand;

3. When a relevant-looking CPS is found, it can be in a non-English
language, with no clear pointers to the location of the (Mozilla-required)
non-authoritative English translation of that document.

My various sub-proposals are, unsurprisingly, closely aligned to these
sub-issues.

1. Make cPSuri mandatory

I assume there was a Very Good Reason for cPSuri to be optional, but for the
life of me I can't think of what it would be.  Unless someone comes up with
the killer argument against it (and no, "it bloats certificates" doesn't
count, IMAO), I think this one's a no brainer.

When there's no link to a CPS, in any way shape or form, I'm left flailing
around in the giant CCADB CSV o' doom to figure out where the CPS lives, and
that...  ain't easy.  In one case, I sent a problem report to *completely*
the wrong CA.  If each certificate had a link to the right place, that
problem, at least, couldn't happen.

2. Make the cPSuri actually point to the relevant CPS

It seems odd to me that the BRs have relaxed what RFC5280 has to say about
cPSuri, which is "The CPS Pointer qualifier contains a pointer to a
Certification Practice Statement (CPS) published by the CA", to say "HTTP
URL for the Subordinate CA's Certification Practice Statement, Relying Party
Agreement or other pointer to online information provided by the CA".  I'm
not a fan of 5280's laxity regarding specifying *which* CPS published by the
CA should be linked to, but at least it's pretty clear that the content at
the end of the link should be *a* CPS, rather than the BRs allowing a CA to
link to basically anything they like.

The problem is that a CA's repository, or "online information provided by
the CA", typically looks something like this:

 * CPS for Device PKI
 * Frambingaling CP and CPS v2.1
 * Latest Certificate Practice Statement for Small Furry Creatures
 * Subscriber Agreement and Addendum for Something Something

... and so on.  How I get from "I have a certificate that I need to report",
which contains an issuer CN and not much else, to the correct document out
of that list above, is a non-trivial problem.  Having the cPSuri point *to
the CPS* would completely solve that.

There is a bit of a side point here, about whether the correct CPS to link
to is CPS-at-time-of-issuance, or CPS-at-time-of-retrieval.  Given that CAs
don't seem to ever provide old CPSes in their repository, I assume that the
general consensus is that the appropriate CPS to review is *always* the
current version.  Presumably, if a CA publishes a non-backwards-compatible
CPS (ie the new CPS would not permit issuance of a certificate that was
OK under the old CPS), the CA is obliged to revoke all those now-invalid
certificates.

3. Require non-English language CPSes to link to the English translation

I am sympathetic to CAs which operate primarily in a non-English market, in
that they want their primary materials to be in the language of their
market.  That's no problem.

However, there is a problem when I need to go from "here is a CPS I found in
a language I don't speak" to "here is the corresponding CPS in English". 
So, I'd like to see it a requirement that the "primary language" CPS have,
in some easily-findable-by-monoglots-like-myself spot, a link to the
corresponding English transation for *this CPS*.

A link to the "English language translations" repository doesn't help, for
much the same reason that cPSuri linking to the CA's repository doesn't
help.  if I don't know what the translation of the relevant CPS' title is,
I'm not going to be able to pick out the right English language CPS from the
list.

If the word "English" is in the text surrounding the link, that'd
make it easy enough: ^F, "English", copy-paste URL, done.

- Matt

___
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: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

[Sándor dr . Szőke via dev-security-policy]

Dear Ben,

I confirm that Microsec will correct all issues in the CP and CPS documents as 
promised during the public discussion.

Thanks to everyone who took the time to read Microsec CP and CPS and to comment 
on them.

If there are no more comments on the content of our CP and CPS documents in the 
public discussion, we will review the thread again and gather all the issues to 
be resolved. 
As usual, Microsec will review current versions of all applicable requirements 
for changes.

I confirm that the section 1.5.2 will be changed. The High Priority Certificate 
Problem Report will be reviewed and will be moved here from section 4.9.3.

Other issues I can see after a brief overview:
- Preliminary report in case of Certificate problem report in section 4.9.5
- correct the reference to section 1.3.1 instead of 1.2 in section 4.9.5
- review the email address validation rules in case of non-automatic validation 
procedure in section 3.2.7

I expect that Microsec will be able to do it within one week and will prepare 
the draft version of the public documents by the end of April.

We publish the drafts on our website and send them to the auditor and our 
supervisory authority at the same time.

This is followed by a 30-day commenting period during which anyone can comment 
on the planned changes. 
If significant issues arise during this period, the draft shall be amended and 
the 30 days shall begin again.
If there are no significant issues, the new document will enter into force by 
the end of May 2020. 

Please let us know if you expect us to take any further steps in this process.

Best regards,

Sándor

dr. Sándor Szőke
Microsec deputy director
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy