I think you're largely objecting to a strawman, no one is proposing revoking trust in any of these threads.
The only CAs that have ever had _any_ penalty applied to them have been for grotesque abuse of the trust vested in them. Alex On Tue, Aug 8, 2017 at 2:25 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> 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. 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. > > 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. > > An example of a graduated response: > > - Deliberately issued super-interception certificate: Instant revocation > of CA trust. > - SubCA that does no vetting at all: Instant revocation and adding to > OneCRL. > - Certificate issued to someone who should not have it (like the github > certs issued by WoSign): 24 hour revocation, faster if possible. > - Certificate that violates rules and triggers a bug preventing Mozilla > NSS from detecting if it is revoked: 24 hour revocation and adding > special case code to NSS to treat this form of certificate as not valid > instead of non-revocable. > - Certificate issued in such a way as to increase the risk of > post-issuance attacks (such as SHA-1 cert issued in 2016 or later with > insufficient random bits near the start of the TBSCertificate): 24 hour > revocation of cert itself, issuing SubCA revoked with 2 month delay to > replace affected good certificates from a new clean SubCA. > - Single Certificate that violates rules, but works with revocation > checking in NSS and was issued to the proper party (possesses domains, > matches any real world identity in DN etc.): Revoke after 14 days, try > to replace before that. > - Thousands of certificates that violate rules, but work with revocation > checking in NSS and were issued to the proper parties (example: O= > field replaced by "test" after full vetting of actual name): Revoke > after 2 months, try to replace before that. > - Certificate that violates a previously unclear interpretation of a > rule, but works with revocation checking in NSS and was issued to the > proper party (example: 20 byte serial withe extra leading 0 byte, if > NSS revocation didn't fail on that): Clarify rule, but only revoke if > it has more than 9 months left before expiry. > > Comparison with some recent cases: > > 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). > > 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. > > 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. > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > _______________________________________________ > 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
