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
