I really sorry for the Delay Burton.

Obviously we do not intend to send inaccurate answers. Maybe I was not using 
the right wording may be I should use “precise” instead ? sorry for my English 
language limitation. Your complain about my email prove that some 
misunderstanding problem could have happen also in our bugs reports. We want to 
be sure that the answers are fully understand to give to the community the 
complete information to evaluate them. As you can imagine in the situation we 
are, it’s critical for us. That’s the reason.

Thanks
Ramiro


De: Burton <j...@0.me.uk>
Enviado el: martes, 15 de diciembre de 2020 19:39
Para: Ramiro Muñoz <rami...@camerfirma.com>
CC: r...@sleevi.com; mozilla-dev-security-policy 
<mozilla-dev-security-pol...@lists.mozilla.org>; Ben Wilson 
<bwil...@mozilla.com>
Asunto: Re: Summary of Camerfirma's Compliance Issues

It doesn't look great to the community when a CA that is under investigation 
for serious compliance issues asks for more time to provide detailed answers.

Also you said 'accurate answers' ? Were the answers you were going to post 
today inaccurate in some way?

Burton

On Tue, Dec 15, 2020 at 6:13 PM Ramiro Muñoz via dev-security-policy 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Hi Ryan

Thanks. We will take into account your observations.
As I said we planed to send the formal answer today but the team has asked me 
for more time in order to give a more accurate answer. We plan to postpone to 
this Friday.

KR
Ramiro


De: Ryan Sleevi <r...@sleevi.com<mailto:r...@sleevi.com>>
Enviado el: lunes, 14 de diciembre de 2020 22:41
Para: Ramiro Muñoz <rami...@camerfirma.com<mailto:rami...@camerfirma.com>>
CC: r...@sleevi.com<mailto:r...@sleevi.com>; Ben Wilson 
<bwil...@mozilla.com<mailto:bwil...@mozilla.com>>; mozilla-dev-security-policy 
<mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>>
Asunto: Re: Summary of Camerfirma's Compliance Issues

Thanks Ramiro for the update.

I do want to make sure we're on the same page. Responding point-by-point to the 
issues would probably be the least productive path forward. If there are 
specific disagreements with the facts as presented, which were taken from the 
Bugzilla reports, it would be good to highlight that. However, I believe the 
intent is that the Bugzilla report is the source of truth, so if there are 
details that were *not* on the incident reports, I would say that's more 
concerning than it is reassuring.

I'm a bit concerned to see your latest reply still highlight the "increased the 
PKI team", since that's been a sort of repeated refrain (e.g. Issue T, Issue 
BB, Issue PP). I don't disagree that it's important to ensure that there are 
adequate resources devoted to compliance _and_ development, but I think it's 
also important to make sure that the solution is not to throw more people at 
the problem.

While the integrity of the CA is perhaps not as obviously cut and dry, as was 
the case with WoSign/StartCom, I do believe it's reasonable to ask whether or 
not the CA has the skills, expertise, and understanding of the systemic issues 
to effectively manage things going forward, especially when we have seen the 
regular repetition of issues. This suggests more systemic fixes are needed, but 
also suggests that there are more systemic flaws in how things are operated, 
designed, and administered that do call into question the trustworthiness of 
the current infrastructure.

If Camerfirma were approaching with a new CA/new certificate hierarchy, it 
would be reasonable to ask why, given all of these incidents, Camerfirma should 
be included, since it puts a lot of risk onto the community. Regaining trust 
and reputation, once lost, is incredibly difficult, and requires going above 
and beyond. I hope that, in your formal response, you provide a holistic 
picture of how Camerfirma has changed its operations, implementation, 
infrastructure, management process, policies, and quite frankly, the use 
cases/subscribers that it targets with these certificates, so that the 
community can make an informed decision about risk.

Similarly, in thinking about what this would be for a "new" PKI, and how 
difficult it would be, given the current evidence, to see that as good for 
users, it's also worth asking what should happen with the current PKI. Should 
we continue to assume that the implementation of the EV guidelines is correct, 
even though we have ample evidence of basic RFC 5280 and BR violations? Should 
we consider sunsetting (e.g. with a notBefore restriction) trust? Would it be 
reasonable to remove trust altogether?

For example, Camerfirma currently has four roots ([1], [2], [3], [4]). [1] 
appears to have issued less than 3,500 still valid certificates, [2] / [3] are 
only trusted for e-mail, and [4] seems to be a super-CA of sorts (with sub-CAs 
operated by Intesa Sanpaolo, Infocert, Multicert, and Govern d'Andorra). For 
the sub-CAs that aren't constrained/revoked, it seems Intesa Sanpaolo has only 
issued ~2200 certificates, Infocert ~650, and Multicert ~3000.

Is that accurate? I totally could have made a mistake here, since this was just 
manually inspecting every sub-CA from Camerfirma and I totally could have 
clicked wrong, but that suggests that there is... very little practical risk 
here to removal, compared to the rather significant risk of having a CA that 
has established a pattern of compliance and supervision issues.

[1] https://crt.sh/?caid=869
[2] https://crt.sh/?caid=140
[3] https://crt.sh/?caid=8453
[4] https://crt.sh/?caid=1114
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org<mailto: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

Reply via email to