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