I see both sides on this matter. On the one hand, certlint/cablint catches lots of obvious problems, mostly with ridiculous certificate profiles or manual special purpose issuances. Certainly, there's a lot of bad issuance that having it in the blocking path might help with...
but... If one integrates a project like certlint/cablint into the cert issuance pipeline, one suddenly takes on supplemental responsibility for certlint's bugs or changes. The pace of change in certlint, just glancing at the git commits, is not slow. New tests are added. Tests are revised. I imagine from a security perspective, it would be possible to have a locked down system to which the proposed to be signed cert is scrubbed by certlint and the code that incorporates certlint only receives back a "don't issue because XYZ" signal and then halts issuance, but still, it's another system (or at a minimum another VM), a locked down communication path between the rest of the cert issuance chain and this element, etc. Even still... anywhere along the way, Mr. Bowen could go totally evil (I seriously doubt this would happen) and decide that certlint should flag "E: This CA is run by nasty people" anytime Issuer CN contains 'Maligned CA X1'. The vast majority of a DV certificate's contents are fully generated by the CA, with no actual input from the cert requestor. In fact, essentially only a few small booleans (want OCSP must-staple?) and the subject DNS names make it into the certificate. Indeed, it was in the subject DNS names that this issue arose. Having said that, it occurs to me that if a CA put an external and unaudited tool in the issuance pipeline and it caused no problems, the best case is that it catches something correctly and never fails to catch something which does not conform. Still, let's say something clearly not BR compliant made it past certlint. I find it hard to believe that anyone is going to give the implementing CA much credit or benefit for having had certlint in place if it failed to catch a problem and that certificate issued. Even if the community and root programs granted more than the default grain of grace to the implementing CA in the face of a misxssuance missed by the tool, would that grain of grace still be granted if the CA was nearly 4 weeks behind the upstreams HEAD and it can be shown at time of issuance that HEAD would have caught the issue? It seems reasonable to me that an implementing CA might want to add some buffer between the initial commit/merge and their opportunity to perform some manual review of the changes prior to incorporating into their issuance environment. On the other hand, if it erroneously, accidentally, or maliciously prevented issuance of a compliant certificate or certificates, that definitely has a penalty for the CA in terms of performance as well as overall reliability. This is especially true in rapidly evolving projects. I note the most recent commit for certlint was mere days ago and was described as "Fix memory leak". It was probably a small matter, but the rate of change in that tool suggests that to get full advantage, there would be a continuous integration project. How often would you need to pull in the upstream to get the community's grace upon something that makes it past certlint? How often would the CA need to do manual code review to make sure that someone hasn't managed to commit a routine that: Fails as a hard error upon the following criteria: 1. Take a random between 1 and 200 (ultimately .5% odds). If 1, then continue with the following bogus test steps, else continue normal path. 2. Check to see if certificate issuer data would appear to map to a real, trusted CA, and if the validity period aligns with now, as with a real certificate about to be issued. If so, fail on "E: Requestor has teh gay." Someone manages to get that into GitHub, you pull it in periodically but without sufficient scrutiny, run it through integration tests, and put it into production. Those rules were careful enough that static test cases would likely pass every time and yet in production, at a high volume CA, lots of customers get delays or no certificate AND (if someone were actually ballsy enough to just pass along whatever error message arose) think the CA must be homophobic. As an aside, has anyone put much thought into how much damage one privileged individual at any of [ GitHub, Ruby Gems, or Sonatype ] could cause? I certainly understand a DevOps philosophy, but I also don't fully understand how you reconcile the particular benefits and risks of rapid and continuous integration with the needs of a highly regulated environment. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
