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> 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>
> Enviado el: lunes, 14 de diciembre de 2020 22:41
> Para: Ramiro Muñoz <rami...@camerfirma.com>
> CC: r...@sleevi.com; Ben Wilson <bwil...@mozilla.com>;
> mozilla-dev-security-policy <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
> 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