Here’s a summary of your input, and my thoughts.
What about NSS?
We discussed this in the NSS team call last week, and the general decision was
that the rules we put in place regarding these Affected Roots for Mozilla will
also be put in place inside NSS.
That doesn’t help all consumers of the NSS root store, just the ones who use
I’m not sure what we can do about other consumers of the NSS root store, other
than publish what we are doing and hope those folks read the news and update
their version of their root store as they see appropriate for their use.
Several comments about Mozilla’s Action #4.
> 4) Remove the Affected Roots from NSS after the SSL certificates
> issued before October 1, 2016, have expired or have been replaced.
I will change the date to October 21, 2016 to be consistent with the date
When I wrote that we would remove the Affected roots after the certs had
expired or been replaced, I was incorrectly only thinking about the 1-year SSL
My intent was to find a reasonable date in the future when current clients have
had enough notice and time to transition to other root certificates. Based on
the data from Kurt, it looks like a year might be too little time. Two years
seems like a lot of time.
Regarding actions for the CA…
Several suggestions that Mozilla require or strongly urge the CA owners of the
Affected Roots to reach out to their subscribers asap to let them know about
these changes, and give those clients time to transition.
> deserve some warning even of the risk that invalidation would
> happen in future, not to mention that they will not be able to
> receive renewals from these CAs, at least for some time.
> WoSign and StartCom are still actively selling certs which cost
> one hundreds or more dollars. I think Mozilla should mandate
> that WoSign/StartCom inform their users of such incidents or
> at least the imminent distrust by Mozilla
I would hope that the CA would figure out how to communicate this to their
customers in order to help their customers have minimum disruption.
The CA could create new root certs, and put information on their website to
make it easier for users to manually import their new root certs, and also put
information on their website for their current customers who will need to get
new intermediate certs, and instruct their customers about downloading the new
root certs. That’s basically what CAs whose root certs aren’t included in NSS
(and aren’t cross-signed by an included root) have to do anyways.
I’m not sure what I could reasonably require (and enforce) of the CA in regards
to communicating with their customers.
I recall that my security blog about CNNIC got censored in China, so I'm not
sure what Mozilla can do about informing the CA's customers of this pending
>> 4. Provide auditor attestation that a full performance audit has been
>> performed confirming compliance with the CA/Browser Forum's Baseline
>> Requirements. This audit may be part of an annual WebTrust BR
>> audit. It must include a full security audit of the CA’s issuing
> I would recommend that Mozilla retain the option to approve the
> security auditor, and that it be an external company.
I will add the sentence: “The auditor must be an external company, and approved
> 5. 100% embedded CT for all issued certificates, with embedded SCTs
> from at least one Google and one non-Google log not controlled by the
As suggested, I will add:
”The CA SHOULD NOT fulfill the non-Google log requirement by using
logs that they run themselves. For as long as they do so, they will
need to demonstrate ongoing evidence of efforts to get other logs
to take their volume, and why those efforts have not been successful."
> I should add that if StartCom/WoSign have a CT log codebase capable of
> taking the volume necessary, they could always open source it, and then
> pay a 3rd party to run an instance of it, with an arms-length contract.
> That sort of solution may well be acceptable, depending on contract details.
I don't think that changes the sentence that is being added.
> Please can Mozilla ensure that both EY Hong Kong and the overarching parent
> organisation in the United Kingdom (in Southwark) are informed of this ban
> and get a copy of Mozilla's findings if they haven't already ?
I think Gerv is doing that.
It will also impact CNNIC.
So, does CNNIC's audit get grandfathered in? Or does CNNIC have to get audited
by a different auditor before they can re-apply for full inclusion?
I think we need to add an action item regarding making sure that all of the
code and systems used by the CA are well-designed and updated, and fully meet
the CA/Browser Forum’s Baseline Requirements.
What would be a reasonable requirement to state for each of the CAs?
Are there tests that we could require the CA to run/pass that would satisfy our
concerns about quality of the code and systems?
dev-security-policy mailing list