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
