On Mon, Sep 18, 2017 at 8:12 AM, Inigo Barreira <in...@startcomca.com> wrote: > > We are not seeking to identify personal blame. We are seeking to > understand what, if any, improvements have been made to address such > issues. In reading this thread, I have difficulty finding any discussion > about the steps that StartCom has proposed to improve its awareness of the > expectations placed upon it as a potential participant in the Mozilla > store. Regardless of who bears responsibility for that, the absence of a > robust process - and, unfortunately, the absence of a deep understanding - > does mean that the restablishing of trust can present a significant risk to > the community. > > > > I think I´ve posted everything we did to improve our systems. I replied to > every error posted in the crt.sh explaining what happened and what we did > to fix it for not having the same issue again, but will try to recap here > again. > > > > - Test certificates. We issued test certificates in production > to test the CT behaviour. After the checking those certs were revoked, > within minutes. This was due to an incorrect configuration in the EJBCA > roles that was changed and updated accordingly for not allowing anyone to > issue certs from the EJBCA directly > > - Use of unallowed curves. We issued certificates with P-521 > which is not allowed by Mozilla. We revoked all those certs and configure > the system to not allow it. This remediation was put into production on > mid-july not issuing certs with that curve. > > - RSA parameter not included. We issued one certificate which no > RSA parameter included. We revoked that certificate and started an > investigation. The EJBCA system didn´t check the keys, concretely for this > issue. We developed a solution to check the CSR files properly before > sending to sign > > - Country code not allowed. We issued one certificate with > country code ZR for Zaire, which does not exist officially. We revoked the > cert and checked our internal country code database with the ISO one. We > made the correspondent changes. The cert was reissued with the right code > representing the Democratic Republic of Congo. > > > > Furthermore, we have added x509lint and cablint to our issuance process. > We have integrated crt.sh tool into our CMS system. We have developed a CSR > checking tool. We have updated the EJBCA system to the latest patch, > 6.0.9.5 which also came with a Key (RSA and ECC) validator, and we are also > willing to integrate the zlint once is getting more stable. We have applied > all these tools and we are not misissuing certificates. >
Unfortunately, I am not sure how to more effectively communicate that this pattern of issues indicates an organization failure in the review of, application of, and implementation of the Baseline Requirements. Through both coding practices and issuing practices, security and compliance are not being responded to as systemic objectives, but rather as 'one offs', giving the impression of 'whack-a-mole' and ad-hoc response. For example, the country code failure indicates a more deeper failing - did you misunderstand the BRs? Were they not reviewed? Was the code simply not implemented correctly? With the RSA parameters, it similarly indicates a lack of attention. I greatly appreciate the use of and deployment of x509lint and cablint, but those merely offer technical checking that, as an aspiring trusted root CA, you should have already been implementing - whether your own or using those available COTS. The continued approach to issue-and-revoke rather than holistically review the practices and take every step possible to ensure compliance - particularly at a CA that was previously distrusted due to non-compliance - is a particularly egregious oversight that hasn't been responded to. In every response, it still feels as if you're suggesting these are one-offs and coding errors, when the concern being raised is how deeply indicative they are of systemic failures from top to bottom, from policy to technology, from oversight to implementation. Rather than demonstrate how beyond reproach StartCom is, it feels like an excessive emphasis is being put on the ineffective revocation of these certificates, while ignoring the issues that lead to them being issued in the first place - both from policy and from code. It´s not like disagreements, but the example was about a root certificate > private key in a USB stick, so IMO that example starts with a very > problematic issue, because it´s about a root private key and in a USB stick > left in the table, while the issues Startcom did was about end entity > certificates, and nothing related to private keys and not in the root, > that´s what I meant with “quality”. > I understand what you meant. I'm suggesting the community has a perception that the issues StartCom is presently being faced with is as egregious and as serious. I understand you disagree it's as significant. The suggestion is that it _is_ this significant - and the failure to respond to why it isn't, or the responses offered so far, is not particularly inspiring for trust. > > > But, if we want to talk about the option that someone can do anything in > the meantime when there´s a lack of security measures or procedures, or > that you can´t check that those measures, remediations, etc. have been set > and create uncertainty, etc. I think the best way is to check the CT, in > which all the certs are logged. Also, in the audits, when an external party > checks the CA. But, I mean, as any other CA. We´ve seen misissuances from > all CAs, none is free more or less, and all act the same, remediate the > issue for not happening again, and how do you check it, with CT, with > crt.sh, audits, etc. But, if you need anything else, just as kit. I can > provide whatever you may ask to avoid that uncertainty. > This response is deeply concerning, and continues to be. First, you appear to be suggesting "Everyone makes mistakes, so we should not be held accountable for our mistakes." Second, you appear to be suggesting "Audits aren't great, so we shouldn't put so much trust in them." Yes, mistakes happen. When a pattern of mistakes happen, CAs get distrusted. When a CA is distrusted, and continues a pattern of mistakes, it is not trusted for reapplication. To avoid the uncertainty is to _not misissue in the first place_. Once that uncertainty has been introduced - or, in the case of a CA with a pattern of failures, reintroduced - it is incredibly difficult to regain trust. CAs that are previously distrusted are, in effect, needed to operate at an even higher level of compliance and operational efficacy, to demonstrate that the past issues are not present. Instead, we have multiple data points suggesting worse. > I can´t remember of any notification about this regarding Startcom > certificates. And I don´t think any notification has not been discussed. > For this certificate, we should start this is a warning, and we have been > focused in crt.sh errors, to deal with warnings later. This one was due to > a issue with the translation from unicode to punnycode and a fail in the > comparision check with CN and SAN. We´re working on it. > https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 was due to StartCom acting as an RA for DNS validation for Camerfirma. Which is now (but not at the time) forbidden. > The fact that it was revoked an hour after issuance does not raise > confidence - it reduces it. > > > > I don´t think so. > Perhaps it's a translation issue, but a better way of phrasing is not "I don't think so" (which implies that you know whether or not it reduces confidence), but "I don't think it should". I'm trying to be charitable here, but it absolutely reduces confidence when a CA actively misissues a certificate, and then claims revocation is sufficient. No. You never should have issued such a certificate in the first place. That you have causes a loss of confidence - revocation does not and cannot restore that by itself. What restores confidence is how effectively you respond - and revocation may be part of that answer, but a systemic evaluation of the process and policies that allowed it to happen, and steps to prevent both the _specific_ incident from happening and a holistic review of all related practices so that all other bugs of that class are addressed can. That is, if you detect, for example, a BR violating cert, a 'minimum' answer is to revoke it, a 'necessary' action is to prevent that specific BR violation, but the 'correct' action is to holistically review the BRs, from top to bottom, and audit against the system that every technical control is met, and every policy and procedure for non-technical controls is written and effective. > I can understand your assertion that these certificates are revoked. That > does not mean they do not present risk to the ecosystem. > > > > Then I assume like many other of the certificates revoked from everyone. > On the basis of this reply alone, I think it demonstrates a cavalier enough attitude towards security and compliance - and on emphasizing external blame rather than the opportunity for internal improvement - that I would wholly agree with Gerv's suggestion of new keys, and with an explicit prohibition against any cross-signing from any member CA. There's simply no room in public trust stores for such approaches to security - it's fundamentally untrustworthy. > Yes, it´s true. The certificate was issued in April because Certinomis had > to do something at their facilities and took the opportunity. That > certificate was custodied by them until we could provide a valid Webtrust > certificate, which we did and then disclosed in the CCADB. > Then they misissued a CA certificate and failed to disclose it, and we should start an incident report into it. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
