On Mon, Nov 26, 2018 at 12:12 PM Jakob Bohm via dev-security-policy < [email protected]> wrote:
> 1. Having a spare certificate ready (if done with proper security, e.g. > a separate key) from a different CA may unfortunately conflict with > badly thought out parts of various certificate "pinning" standards. > You blame the standards, but that seems an operational risk that the site (knowingly) took. That doesn't make a compelling argument. > 2. Being critical from a society perspective (e.g. being the contact > point for a service to help protect the planet), doesn't mean that the > people running such a service can be expected to be IT superstars > capable of dealing with complex IT issues such as unscheduled > certificate replacement due to no fault of their own. > That sounds like an operational risk the site (knowingly) took. Solutions for automation exist, as do concepts such as "hiring multiple people" (having a NOC/SOC). I see nothing to argue that a single person is somehow the risk here. > 3. Not every site can be expected to have the 24/7 staff on hand to do > "top security credentials required" changes, for example a high- > security end site may have a rule that two senior officials need to > sign off on any change in cryptographic keys and certificates, while a > limited-staff end-site may have to schedule a visit from their outside > security consultant to perform the certificate replacement. > This is exactly describing a known risk that the site took, accepting the tradeoffs. I fail to see a compelling argument that there should be no tradeoffs - given the harm presented to the ecosystem - and if sites want to make such policies, rather than promoting automation and CI/CD, then it seems that's a risk they should bear and make an informed choice. Thus I would be all for an official BR ballot to clarify/introduce > that 24 hour revocation for non-compliance doesn't apply to non- > dangerous technical violations. > As discussed elsewhere, there is no such thing as "non-dangerous technical violations". It is a construct, much like "clean coal", that has an appealing turn of phrase, but without the evidence to support it. > Another category that would justify a longer CA response time would be a > situation where a large batch of certificates need to be revalidated due > to a weakness in validation procedures (such as finding out that a > validation method had a vulnerability, but not knowing which if any of > the validated identities were actually fake). For example to recheck a > typical domain-control method, a CA would have to ask each certificate > holder to respond to a fresh challenge (lots of manual work by end > sites), then do the actual check (automated). Like the other examples, this is not at all compelling. Solutions exist to mitigate this risk entirely. CAs and their Subscribers that choose not to avail themselves of these methods - for whatever the reason - are making an informed market choice about these. If they're not informed, that's on the CAs. If they are making the choice, that's on the Subscribers. There's zero reason to change, especially when such revalidation can be, and is, being done automatically. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
