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 

-----Original Message-----
From: dev-security-policy 
 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

     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 


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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

dev-security-policy mailing list

Reply via email to