I agree that the 24 hours seems excessive for some of these. Ive proposed at 
the cab forum we bifuracte the revocation periods to key compromise vs non key 
compromise. I'd love support there on the proposal. However, I think that until 
the rules change formally, CAs should be required to meet that strict period. 
It's not hard to make a change once general agreement is reached.

> On Aug 8, 2017, at 1:02 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

Reply via email to