On Tuesday, August 8, 2017 at 11:26:11 AM UTC-7, Jakob Bohm wrote: > On 08/08/2017 18:43, Ryan Sleevi wrote: > > On Tuesday, August 8, 2017 at 11:05:06 PM UTC+9, Jakob Bohm wrote: > >> I was not advocating "letting everyone decide". I was advocating that > >> Mozilla show some restraint, intelligence and common sense in wielding > >> the new weapons that certlint and crt.sh have given us. > >> > >> This shouldn't be race as to who wields the weapon first, forgiving CAs > >> only if they happen to report faster than some other newsgroup > >> participant. > >> > >> This is similar to if a store boss gets a new surveillance camera in the > >> shop and sees that some employees are taking extra breaks when there are > >> few customers in the store. It would be unreasonable for such a store > >> boss to discipline this with similar zeal as seeing some employees > >> genuinely steeling cash out of the register or selling stolen items out > >> of the back door. Instead the fact that they work less when there is > >> less work to do should inspire reevaluation of any old rule that they > >> are not allowed to have a watercooler chat during work hours. > >> > >> Now such a reevaluation might result in requiring them to use such > >> occasions to clean the floors or do some other chores (Mozilla equiv: > >> Deciding that the rule is important for good reason and needs to be > >> followed in the future) or it could result in relaxing the rule as > >> long as they stand ready the moment a customer arrives (Mozilla equiv: > >> Relaxing the requirement, initially just for Mozilla, later perhaps as a > >> BR change). > >> > >> Dogmatically insisting on enforcing rules that were previously not > >> enforced due to lack of detection, just because "rules are rules" or > >> other such arguments seems overzealous. > >> > > > > Such tools have been available for over a year. CAs have been aware of > > this, the ability to run it over their own corpus and self-detect and > > self-report. These tools, notably, were created by one of the newest CA > > applicants - Amazon - based on a methodical study of what is required of a > > CA. > > > > Your attempts to characterize it as overzealous ignore this entirely. At > > this point, it's gross negligence, and attempts to argue otherwise merely > > suggest a lack of understanding or concern for standards compliance and > > interoperability. > > > > Mozilla has already communicated to CAs these tools exist and their > > relevance to CAs. > > > > Perhaps we can move on from misguided apologetics and instead focus on how > > to make things better. Suggestions we ignore these, at this point, are > > neither productive nor relevant. Attempts to suggest tortured metaphors are > > like attempting to suggest rich people deserve to be robbed, or poor people > > just need to work harder - arguments that are both hollow and borderline > > offensive in their reductionism. A pattern of easily preventable > > misissuance has been happening,CAs have been repeatedly told to > > self-detect, and clearly, some CAs, like presumably some businesses, aren't > > taking security seriously. That needs to stop. > > > > I am questioning the fairness of applying these tools, which did not > exist when the rules were written, to enforce every rule with the same > high weight.
Did anything prevent the CAs responsible from writing these tools? Do you believe there is any excuse for issuance in 2017 that violates these rules? Is your view that until someone else does the CA's work for them (reading and understanding the rules), the CA should not be responsible for reading or understanding themselves? You're arguing against a strawman. It's 2017 - it's both time to stop making excuses and time to recognize that the ability of CAs to adhere to the rules is core to their trustworthiness. Technical rules are but a proxy for procedure rules. > I am not apologizing for bad behavior, I am saying if > everybody gets scrutinized this hard, we will eventually have to > distrust pretty much all the CAs, because there is no such thing as a > perfect CA organization. No, you are apologizing for their bad behaviour by suggesting they shouldn't be held to an objective standard, because someone else hadn't done the work for them. The compliance or noncompliance is extremely relevant to the CAs ability to react and respond to changes, and you continue to offer a view that suggests CAs shouldn't have to respond consistently or should not be expected to consistently follow the rules, which undermine the very trust. If these are violations, and they are, we should expect each CA to take action and explain to the community why they failed to detect these issues, as well as what changes they are making in the future to stay on top. Prioritization is both a misdirect to responsibility and an attempt to undermine trustworthiness. > > So we need to prioritize the rules instead of just saying off-with- > their-heads (revoke all affected certificates in 24 hours) whenever any > formal rule was broken without actually harming security. That is what the Baseline Requirements say, and which both CAs and browsers agreed was an appropriate and responsible remediation. You are barking up the wrong tree, and in the wrong Forum, to suggest in the abstract that more lenient is required, and you've also failed to grasp the risk presented to clients in several cases, so such arguments will have a high burden to bear. > Symantec's Korean RA replaced O with test (a minor thing, since no real > organization was impersonated), but also failed to keep proper vetting > records (a major thing, requiring urgent revocation). Your analysis does not match the facts of the situation. > > The interpretation of the 20 byte serial rule as being "160 arbitrary > bits, sometimes encoded as a 23 byte DER structure (1 byte tag, 1 byte > length, 1 leading 0, 20 significant bytes) would have been a lack of > clarity and a future requirement, had it not been for the apparent fact > (I haven't tested this) that NSS would be unable to detect revocation of > such certs, but would accept them regardless of actual revocation, which > escalates it to urgent revocation and a security bug filed against NSS > to either block all such certs or implement revocation checking for > them. You have also misunderstood the risk to interoperability or compatibility here. Such certs actively don't work in Mozilla clients, creating interoperability issues in the Web Platform due to nonadherance to the standards. > > Certificates issued with the IDNA in a SAN, but the equivalent unicode > in CN: Falls in the 14 day bucket or perhaps the 9 month bucket > (depending on clarity of old rules). This is if NSS will only look > at the SANs anyway when there is at least one SAN, as is required by > once of the RFCs. Ditto if NSS would not successfully match any network > name to the UNICODE CN, because no pure ASCII string would compare equal > to a string with at least one significant non-ASCII char. This equally fails to understand the risk, but perhaps more importantly, the Mozilla Manifesto and its goals for interoperability and security. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
