Re: Mozilla's Response to Camerfirma's Compliance Issues

[Andrew Ayer via dev-security-policy]

On Mon, 25 Jan 2021 22:21:31 -0700
Ben Wilson via dev-security-policy
 wrote:

> Camerfirma has responded to the list of issues by providing a Remediation 
> Plan,
> https://drive.google.com/file/d/1DV7cUSWqdOEh3WwKsM5k1U5G4rT9IXog/view?usp=sharing,
> with a commitment to align Camerfirma to the highest level of standards of
> the Mozilla community.

For years, Camerfirma has promised to improve but failed to
deliver.  In 2017, they promised technical controls over DNS
names 
yet in 2019 they misissued for an unregistered domain
name because they "did not have the automatic controls yet"
.  In 2017,
they promised linting of all certificates, and are promising it
again in their latest remediation plan.  In 2019 they assured
Mozilla that they had contractual control over their sub-CAs
including mandatory revocation and use of a central lint service
.  Yet their
sub-CA Intesa Sanpaolo continued to delay revoking certificates
 that were
misissued with invalid stateOrProvinceNames
.  Now Camerfirma
is once again proposing to use contractual controls to remediate their
sub-CAs' problems.

Given Camerfirma's past behavior, why should Mozilla trust Camerfirma to
deliver on their latest remediation plan?  Mozilla's users should not
have to assume the risk of trusting Camerfirma while we wait to see if
this time, Camerfirma finally becomes a competent and trustworthy CA.
Instead of making Mozilla users assume the risk, Camerfirma should be
distrusted now.  When Camerfirma applies for re-inclusion, Mozilla can
evaluate whether the remediation plan has worked.

On Tue, 26 Jan 2021 16:01:31 -0700
Ben Wilson via dev-security-policy
 wrote:

> First, it has been Mozilla's long-standing position that, "We believe
> that the best approach to safeguarding secure browsing is to work with CAs
> as partners, to foster open and frank communication, and to be diligent
> in looking for ways to keep our users safe."  So, expect that we will
> take a well-thought and deliberate approach to this issue with Camerfirma.

The other part of this is "participation in Mozilla's CA Certificate
Program is at our sole discretion, and we will take whatever steps are
necessary to keep our users safe."

Mozilla has been working with Camerfirma since 2017 through the
many compliance bugs in Bugzilla.  In several cases, Camerfirma's
communications were lackluster or sluggish rather than "open and
frank.", e.g.:

- Failure to disclose misissuance that they were aware of:


- 4 week delay publishing incident report:


- 2 month delay publishing incident report:


- Failure to provide timely updates or explain reason for remediation
delays: 

Mozilla's years-long effort to work with Camerfirma has not produced
sufficient improvement.  It's now time for Mozilla to exercise its
discretion and distrust Camerfirma to keep its users safe.

> So, expect that we will take a well-thought and deliberate approach to this 
> issue with Camerfirma.

As a point of comparison, the "Summary of Camerfirma's Compliance Issues"
thread has received 20 comments from 12 distinct community-members which
are overwhelmingly critical of Camerfirma, including several comments
calling explicitly for distrust.  This new thread has attracted further
critical comments. The most similar previous incidents (small CAs with
a large number of compliance problems) were PROCERT and Certinomis.
Those discussion periods lasted just 14 and 30 days respectively, and
fewer people commented on them compared to the Camerfirma discussion.
The Camerfirma discussion has gone on for nearly 8 weeks at this point.
Camerfirma has received more deliberation than similar CAs did, and it's
inconsistent for Mozilla to prolong the discussion further.

> So there is another issue that needs to be considered, if distrust is
> chosen, whether to remove just the websites trust bit or to take action
> against all 4 roots, and if so, on what basis?

Like Wayne, I don't believe we have any reason to trust that Camerfirma
manages S/MIME certificate issuance any better than TLS certificate
issuance. Mozilla should distrust all Camerfirma roots so that both
Firefox and Thunderbird users are protected.

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

Re: Mozilla's Response to Camerfirma's Compliance Issues

[Wayne Thayer via dev-security-policy]

Ben,

Here are my thoughts:

- First off, we have given Camerfirma the benefit of the doubt for too long
and Mozilla can't continue to trust Camerfirma while they remediate these
problems. With all the documented issues and Camerfirma's response, that
would represent an unacceptable ongoing risk to Mozilla's users. Distrust
is the first step.
- While most documented incidents are related to TLS certificates, I see
nothing to indicate that Camerfirma manages S/MIME any better. It's more
likely that we simply don't know about many of the email certificate issues
due to the lack of CT enforcement. Mozilla should act to protect
Thunderbird users as well.
- Given the number of issues that have been documented with Camerfirma's
delegated SubCAs, any remediation plan that has them keeping control of CA
certificates is a non-starter for me. Having said that, I don't think
Mozilla should forbid future delegated SubCAs, but rather require
Camerfirma to gain approval for each one (as is currently required by
section 8.1 of the Mozilla Root Store Policy).
- Camerfirma's current certificate hierarchies are quite outdated and
represent a significant risk independent of their operator. They must be
replaced as part of any remediation plan.
- To regain trust, Camerfirma will need to take adequate time to complete
the remediations they have outlined and present evidence of the
improvements from their auditor as part of a new root inclusion request.

Thanks,

Wayne

On Tue, Jan 26, 2021 at 4:01 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> All,
>
> So far there have been several good comments.  Please keep them coming.
>
> I want to take this opportunity just to clarify a few of things.
>
> First, it has been Mozilla's long-standing position that, "We believe that
> the best approach to safeguarding secure browsing is to work with CAs as
> partners, to foster open and frank communication, and to be diligent in
> looking for ways to keep our users safe."  So, expect that we will take a
> well-thought and deliberate approach to this issue with Camerfirma.
>
> Second, many of the compliance issues have dealt with requirements
> applicable to server certificates, yet only two roots of the four trusted
> by Mozilla have the websites bit enabled.
>
> Chambers of Commerce Root – 2008 (Email and Websites)
>
> 063E4AFAC491DFD332F3089B8542E94617D893D7FE944E10A7937EE29D9693C0
>
> Global Chambersign Root – 2008  (Email and Websites)
>
> 136335439334A7698016A0D324DE72284E079D7B5220BB8FBD747816EEBEBACA
>
> Chambers of Commerce Root  (Email only)
>
> 0C258A12A5674AEF25F28BA7DCFAECEEA348E541E6F5CC4EE63B71B361606AC3
>
> Global Chambersign Root (Email only)
>
> EF3CB417FC8EBF6F97876C9E4ECE39DE1EA5FE649141D1028B7D11C0B2298CED
> So there is another issue that needs to be considered, if distrust is
> chosen, whether to remove just the websites trust bit or to take action
> against all 4 roots, and if so, on what basis?
>
> (Also, note that Camerfirma has two other roots that are not included in
> the Mozilla trust store. They are the CHAMBERS OF COMMERCE ROOT – 2016 and
> the GLOBAL CHAMBERSIGN ROOT - 2016.)
>
> Thanks,
>
> Ben
> ___
> 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

Patch immediately LPE vulnerability in sudo

[Burton via dev-security-policy]

If you haven't heard already there is a LPE vulnerability in sudo and must
be patched immediately. Details here:
https://blog.qualys.com/vulnerabilities-research/2021/01/26/cve-2021-3156-heap-based-buffer-overflow-in-sudo-baron-samedit

Thank you

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

Re: Mozilla's Response to Camerfirma's Compliance Issues

[Ben Wilson via dev-security-policy]

All,

So far there have been several good comments.  Please keep them coming.

I want to take this opportunity just to clarify a few of things.

First, it has been Mozilla's long-standing position that, "We believe that
the best approach to safeguarding secure browsing is to work with CAs as
partners, to foster open and frank communication, and to be diligent in
looking for ways to keep our users safe."  So, expect that we will take a
well-thought and deliberate approach to this issue with Camerfirma.

Second, many of the compliance issues have dealt with requirements
applicable to server certificates, yet only two roots of the four trusted
by Mozilla have the websites bit enabled.

Chambers of Commerce Root – 2008 (Email and Websites)

063E4AFAC491DFD332F3089B8542E94617D893D7FE944E10A7937EE29D9693C0

Global Chambersign Root – 2008  (Email and Websites)

136335439334A7698016A0D324DE72284E079D7B5220BB8FBD747816EEBEBACA

Chambers of Commerce Root  (Email only)

0C258A12A5674AEF25F28BA7DCFAECEEA348E541E6F5CC4EE63B71B361606AC3

Global Chambersign Root (Email only)

EF3CB417FC8EBF6F97876C9E4ECE39DE1EA5FE649141D1028B7D11C0B2298CED
So there is another issue that needs to be considered, if distrust is
chosen, whether to remove just the websites trust bit or to take action
against all 4 roots, and if so, on what basis?

(Also, note that Camerfirma has two other roots that are not included in
the Mozilla trust store. They are the CHAMBERS OF COMMERCE ROOT – 2016 and
the GLOBAL CHAMBERSIGN ROOT - 2016.)

Thanks,

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

Re: Mozilla's Response to Camerfirma's Compliance Issues

[pfuen...--- via dev-security-policy]

In my personal opinion, given that most of the actions for the remediation plan 
are expected to be completed during the first quarter of 2021, if the community 
considers that the plan adequately prevents further issues, it would be 
reasonable to establish a deadline to take such a decision based on the 
effective execution of the plan by the date of that deadline, demonstrated by 
means of an independent audit report.

On the other hand, I'd like to understand if the option being in consideration 
is a partial distrust (i.e. eliminate the trust bits for serverAuth) or a total 
distrust.

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

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Ben Wilson via dev-security-policy]

Thanks, Clemens. I'll take a look.

Also, apparently my redlining was lost when my message was saved to the
newsgroup.

I'll see if I can re-post without the text formatting of strikeouts and
underlines.

On Tue, Jan 26, 2021 at 10:24 AM Clemens Wanko via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Ben,
> looking at what was suggested so far for section 3.2, it seems that the BR
> combine and summarize under "qualified" in the BR section 8.2 what you and
> Kathleen describe with the definitions for "competent" and "independent"
> parties.
>
> Based upon that, MRSP section 3.2 could be structured in the following way:
>
> * 1st: definition of "competent party" **
> By "competent party" we mean...
>
> * 2nd: definition of "independency" **
> By "independent party" we mean...
>
> * 3rd: now refer to the BR summarizing 1 and 2 up in the term
> "qualified assessor/auditor" *
> By "qualified party" we mean a person or other entity or group of persons
> who meet *is meeting * the combination of the requirements defined above
> for a "competent party" and an "independent party" and as such meets
> *meeting * the requirements of section 8.2 of the Baseline Requirements.
>
>
> Further following that idea and syncing it with the wording also used by
> the BR, the current suggestion for MRSP section 3.2 could be
> revised/amended as follows:
>
> *
> 3.2 Auditors
> Mozilla requires that audits MUST be performed by a competent, independent
> and herewith qualified party.
> [...]
> By "competent party" we mean a person or other entity *group of persons*
> who has the proficiency and is authorized to perform audits according to
> the stated criteria (e.g., by the organization responsible for the criteria
> or by a relevant agency) and for whom is sufficient public information
> available to determine and evidence that the party is competent *has
> sufficient education, experience, and ability* to judge the CA’s
> conformance to the stated criteria.
> In the latter case, "Public information" referred to SHOULD *** -> SHALL -
> Why not being more strict here?*** include information regarding the
> party’s:
> - evidence of being bound by law, government regulation, or professional
> code of ethics;
> - knowledge of CA-related technical issues such as public key cryptography
> and related standards;
> - experience in performing security-related audits, evaluations, and risk
> analyses; and
> - honesty and objectivity *ability to deliver an opinion as to the CA’s
> compliance with applicable requirements*.
> [...]
> *
>
> Best regards
> Clemens
>
> ___
> 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: Mozilla's Response to Camerfirma's Compliance Issues

[Jonathan Rudenberg via dev-security-policy]

On Tue, Jan 26, 2021, at 00:21, Ben Wilson via dev-security-policy wrote:
> 
> - Do the proposed actions in the Remediation Plan address the underlying
> issues?
> 
> - If Camerfirma fully executes on this plan, will that be sufficient to
> regain trust so that they can remain a CA in Mozilla's root store?
> 
> - Do you have additional recommendations for steps that you think
> Camerfirma should take?

Given the history of major failures and inadequate response over a long period 
of time, I don't believe that there is a remediation plan that can work here.

Mozilla should move forward with distrusting this CA.

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

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

[Clemens Wanko via dev-security-policy]

Hi Ben,
looking at what was suggested so far for section 3.2, it seems that the BR 
combine and summarize under "qualified" in the BR section 8.2 what you and 
Kathleen describe with the definitions for "competent" and "independent" 
parties.

Based upon that, MRSP section 3.2 could be structured in the following way:

* 1st: definition of "competent party" **
By "competent party" we mean...

* 2nd: definition of "independency" **
By "independent party" we mean... 

* 3rd: now refer to the BR summarizing 1 and 2 up in the term "qualified 
assessor/auditor" *
By "qualified party" we mean a person or other entity or group of persons who 
meet *is meeting * the combination of the requirements defined above for a 
"competent party" and an "independent party" and as such meets  *meeting * the 
requirements of section 8.2 of the Baseline Requirements.


Further following that idea and syncing it with the wording also used by the 
BR, the current suggestion for MRSP section 3.2 could be revised/amended as 
follows:

*
3.2 Auditors
Mozilla requires that audits MUST be performed by a competent, independent and 
herewith qualified party.
[...]
By "competent party" we mean a person or other entity *group of persons* who 
has the proficiency and is authorized to perform audits according to the stated 
criteria (e.g., by the organization responsible for the criteria or by a 
relevant agency) and for whom is sufficient public information available to 
determine and evidence that the party is competent *has sufficient education, 
experience, and ability* to judge the CA’s conformance to the stated criteria.
In the latter case, "Public information" referred to SHOULD *** -> SHALL - Why 
not being more strict here?*** include information regarding the party’s:
- evidence of being bound by law, government regulation, or professional code 
of ethics;
- knowledge of CA-related technical issues such as public key cryptography and 
related standards;
- experience in performing security-related audits, evaluations, and risk 
analyses; and
- honesty and objectivity *ability to deliver an opinion as to the CA’s 
compliance with applicable requirements*.
[...]
*

Best regards
Clemens

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

Re: Mozilla's Response to Camerfirma's Compliance Issues

[Matthias van de Meent via dev-security-policy]

On Tue, 26 Jan 2021 at 06:21, Ben Wilson via dev-security-policy
 wrote:
>
> - Do the proposed actions in the Remediation Plan address the underlying
> issues?

One of the underlying issues is that Camerfirma has multiple SubCAs
with each their own control over ICA keys, CPS, certificate profiles,
conformance and validation. As the proposed plan doesn't seem to
remove all of those (reasons mentioned in the other thread), I do not
think this Remediation Plan addresses that part of the concern.

> - If Camerfirma fully executes on this plan, will that be sufficient to
> regain trust so that they can remain a CA in Mozilla's root store?

I find it difficult to trust in a CA that supplies other companies
with unconstrained ICAs. One CA can have a few classes of problems,
but now we have one CA which has their own classes of problems, plus
the problems of their SubCAs.

As we've seen before, and probably will continue to see in the future;
unconstrained SubCAs that are not direct part of a root program are an
antipattern for public trust. It can provide a false impression of
"the CA didn't make the mistake, the SubCA did", whereas the mistakes
of the SubCA _are_ the mistakes of the CA due to the delegation of
trust by the CA to the SubCA; any mistakes made by that SubCA
(trust-wise) are the mistakes of the CA as long as the SubCA is valid.

I have not seen much improvement in communication, self-reporting and
problem resolving of problems with regards to Camerfirma's SubCAs, nor
have I seen substantial improvements in Camerfirmas' stance regarding
their SubCAs. If this was only about the CA activities of Camerfirma
(excluding the SubCAs), the improvements would scrape the bottom, but
the existence of externally managed SubCAs more than triple the risks
involved.

> - Do you have additional recommendations for steps that you think
> Camerfirma should take?

- Stop using the current roots / request removal of current roots /
revoke all external SubCAs.
- Start a new root of trust (the current roots are 'poisoned' due to
the delegated OCSP responder issue and missing key destruction audits
of some of said OCSP responder keys).
- Operate all of the CA infrastructure of this new root of trust
without delegating any of keys, management, validation, and operations
to SubCAs.
- Ensure that you comply to the BR and relevant root store policies
and that you can respond to problems promptly.
- Then, and only then, request inclusion of the new root(s) into the
relevant root stores.

Regards,

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

Re: Summary of Camerfirma's Compliance Issues

[Ramiro Muñoz via dev-security-policy]

El lunes, 25 de enero de 2021 a las 13:31:18 UTC+1, Matthias van de Meent 
escribió:
> On Sun, 24 Jan 2021 at 20:58, Ramiro Muñoz via dev-security-policy 
>  wrote: 
> > 
> > Thanks everyone for your valuable contribution to the discussion. We’ve 
> > prepared a throughful Remediation Plan that addresses all areas of 
> > improvement emerged both in this public discussion as well as direct 
> > contacts with some of the members 
> > https://drive.google.com/file/d/1DV7cUSWqdOEh3WwKsM5k1U5G4rT9IXog/view?usp=sharing.
> >  The plan is very ambitious but, we’ve our BoD commitment to align 
> > Camerfirma to the highest level of standards of the Mozzilla community. 
> > Please feel free send us any request for clarification or any suggestion to 
> > improve the attached document.
> In one of your previous replies on this thread you stated the following: 
> 
> > . We are rethinking the SubCA policy since some of the problems come from 
> > there. Camerfirma has increase the control imposing our 3 external SubCA to 
> > use the camerfirma central lint control in the pre-isuance process. 
> > However, next year we plan to convert external SubCA to Wite label CA, 
> > that's means to run them inside Camerfirma infrastructure. 
> 
> But in this document it looks like this decision has been reverted: 
> 
> > a. Action Point 10.
> > Insource the management of all the operational activities of the 
> > intermediate CAs (June 
> 2021).
> > How: 
> > - Obligation of the SubCA to use the application of controls defined by 
> > Camerfirma (obligation to send us evidence that they have implemented 
> > them). 
> > - SubCA obligation to submit to audits set by Camerfirma and with an 
> > auditor selected by Camerfirma. 
> > - Insource management of all the operational activities of the intermediate 
> > CAs in a discretionary manner. 
> > 
> > Resources: Internal resources (Legal). 
> 
> Specifically, the need for SubCAs to submit to audits implies that 
> this SubCA (company) is still in control of the ICA's signing. 
> Additionally, the lack of operational resources required for this 
> change further reinforces this implication. 
> 
> As we've seen a lot of problems also stemming from the implementation 
> of external SubCAs, this seems like a serious deterioration in 
> trustability, as that requires Mozilla to trust Camerfirma to hold the 
> SubCA to the requirements of the relevant root stores, while it has 
> repeatedly shown not to do that. 
> 
> Could you explain why you decided to revert that decision? 
> 
> Regards, 
> 
> Matthias van de Meent

Dear Matthias;

We’ve had the chance to discuss the topic with some of our subCAs and arrived 
to the proposed solution.
What we’re proposing is not an immediate insourcing of all SubCAs operational 
activities but, a right to do so if and when we deem it necessary.
This means the following:

1.  SubCAs will be obliged to implement the application controls defined by 
Camerfirma
2.  SubCAs will be obliged to submit to audits set by Camerfirma and with 
an auditor selected by Camerfirma
3.  SubCAs will accept contractually that Camerfirma can at any time decide 
to gain full control of their operational activities

In such a way we’ll be able,  at any timer, to insource the management of 
operational activities of our ‘problematic’ intermediate CA.
While virtuous intermediate CA will be allowed to retain the control of their 
operational activities as long as they remain virtuous.

In addition, In our remediation plan we are going to incorporate additional 
resources and controls that will allow us to carry out this monitoring with all 
guarantees. 
However, we are open to discuss further tuning of our remediation plan to gain 
the community confident and  assure the security and compliance with the BRs 
and Mozilla's policies.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla's Response to Camerfirma's Compliance Issues

[Burton via dev-security-policy]

Hi Ben,

The CA has been given chance after chance to improve after incident after
incident but failed to do so. The remediation plan is a doorstop plan for
the CA to wedge the door open to remain in the Mozilla root store but it's
time to face the inevitable conclusion and the door must close on the CA
for good to protect the safety of Mozilla users. Removal should happen
immediately.

The damage to the users of the CA is minimal. Less than 8,000 active
certificates (according to crt.sh) and other CAs can pick up the pieces
easily.

It's disappointing to see another CA bite the dust. No way forward in
my opinion.

Thank you

Burton


On Tue, 26 Jan 2021, 05:21 Ben Wilson via dev-security-policy, <
dev-security-policy@lists.mozilla.org> wrote:

> Dear All,
>
> We appreciate your comments and participation in the discussion about the
> Summary of Camerfirma's Compliance Issues,
> https://wiki.mozilla.org/CA:Camerfirma_Issues.
>
> Mozilla has not yet made a decision about Camerfirma's continuation in our
> root store. We intend to continue with our public discussion process to
> determine whether Camerfirma's root certificates can remain included in
> Mozilla's root store, and what actions they need to take.
>
> Camerfirma has responded to the list of issues by providing a Remediation
> Plan,
>
> https://drive.google.com/file/d/1DV7cUSWqdOEh3WwKsM5k1U5G4rT9IXog/view?usp=sharing
> ,
> with a commitment to align Camerfirma to the highest level of standards of
> the Mozilla community.
>
> They asked if there are parts of the Remediation Plan that need
> clarification and for suggestions to improve the Remediation Plan.
>
> We will appreciate your constructive feedback on it.
>
> - Do the proposed actions in the Remediation Plan address the underlying
> issues?
>
> - If Camerfirma fully executes on this plan, will that be sufficient to
> regain trust so that they can remain a CA in Mozilla's root store?
>
> - Do you have additional recommendations for steps that you think
> Camerfirma should take?
>
> Thanks,
>
> Ben
> ___
> 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: Mozilla's Response to Camerfirma's Compliance Issues

[Andrey West Siberia via dev-security-policy]

In my opinion, Mozilla is too soft on violators... (sorry)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy