24 hours is super short when it's a Saturday morning at 4 am and it’s a European government entity. I agree that is what the policy says now, but, for lower risk items, the policy should change, preferably to at least one business day.
-----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org] On Behalf Of Alex Gaynor via dev-security-policy Sent: Tuesday, August 8, 2017 12:46 PM To: Jakob Bohm <jb-mozi...@wisemo.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Certificates with invalidly long serial numbers It's from the BRs 4.9.1.1: The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: It's also not a penalty on the CA, it's a remediation step for them to undertake. Alex On Tue, Aug 8, 2017 at 2:43 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Some people seemed to require 24-hour revocation of these, which I > also find possibly excessive. > > On 08/08/2017 20:28, Alex Gaynor wrote: > >> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
