On 08/08/2017 21:24, Jeremy Rowley wrote:
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.

And I would suggest that until that has been resolved (one way or
another), we should have a moratorium on mass-filing revocation demands
for the kinds of violations which are expected to get a longer deadline
if the proposed changes go through.

For such, maybe post public descriptions, but delay on the formal filing that would start the 24 hour clock.

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.
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

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

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

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
- 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

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.


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
              • ... Paul Kehrer via dev-security-policy
              • ... Jeremy Rowley via dev-security-policy
              • ... Alex Gaynor via dev-security-policy
              • ... Jeremy Rowley via dev-security-policy
              • ... Jakob Bohm via dev-security-policy
              • ... Paul Kehrer via dev-security-policy
              • ... Jeremy Rowley via dev-security-policy
              • ... Jeremy Rowley via dev-security-policy
              • ... Jakob Bohm via dev-security-policy
              • ... Matt Palmer via dev-security-policy
              • ... Jakob Bohm via dev-security-policy
              • ... Matthew Hardeman via dev-security-policy
              • ... Peter Gutmann via dev-security-policy
              • ... Ryan Sleevi via dev-security-policy
              • ... Ryan Sleevi via dev-security-policy
      • Re: Certificates ... Jakob Bohm via dev-security-policy
      • Re: Certificates ... Ryan Sleevi via dev-security-policy
      • Re: Certificates ... Matthew Hardeman via dev-security-policy
  • Re: Certificates with inva... okaphone.elektronika--- via dev-security-policy

Reply via email to