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

[Watson Ladd via dev-security-policy]

On Monday, January 25, 2021 at 9:21:53 PM UTC-8, Ben Wilson 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? 

In my opinion they do not. Camerfirma has demonstrated that they do not know 
what good management is, yet they ask us to trust in their ability to evaluate 
their sub CAs. Camerfirma has a history of not following through on their 
commitments, with multiple incidents with similar root causes despite committed 
to addressing the root causes. Camerfirma seems to depend on human evaluation 
in the issuance process  to an alarming extent. I think it's worth revising the 
BRs to require extensive process automation.

> 
> - 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 don't think this plan goes beyond what a reasonable person would have done in 
response to the incidents. It's too little, too late. The repetition of already 
existing commitments is alarming. Either they reneged then, or they are lying 
now.
> 
> - Do you have additional recommendations for steps that you think 
> Camerfirma should take? 

Camerfirma should at minimum insource all subCA operations. Camerfirma should 
automate all BR requirements and steps in the issuance process that is humanly 
possible to automate, and ensure that all manual actions are reviewed 
independently before and after being acted upon. Camerfirma should also replace 
its current legal counsel with a competent one, and ask them to review all 
existing subscriber agreements and other contracts and the BRs and Mozilla root 
program requirements and determine if any conflicts exist, and if so remedy 
them. If conflicts are unresolveable Camerfirma should be distrusted. 
Camerfirma should halt all issuance until the plan is implemented. 

Given the extent of the possible SubCA problems all issuance from the old roots 
should sunset or be limited to explicitly disclosed intermediate certificates, 
no new ones created. Then new roots should be created and a de novo application 
for inclusion created. I'm not sure even this would assauge my worries. 
Ultimately the trust one can place in individuals is dependent upon their 
character, and Camerfirma has a history of being dilatory and lackadaisical 
with critically important issues, and I'm not sure what can change that kind of 
organizational rot.

Sincerely,
Watson Ladd 
> 
> 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

[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

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