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 
NSS validation. 
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 
previously listed.

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.

> subscribers 
> 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[6].  This audit may be part of an annual WebTrust BR
>> audit. It must include a full security audit of the CA’s issuing
>> infrastructure.
> 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 
by Mozilla.”

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

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

Reply via email to