Fair enough, thank you, Ryan.

This is my last formal statement for this issue that I am tired of this 
argument, I need to go to hospital now :-).

First, please treat WoSign as a global trusted CA, DON'T stamp as China CA. We 
need a fair treatment as other worldwide CAs that I am sure WoSign is not the 
first CA that have incident and not the serious one;

Second, I supplement some data for your reference, please consider those 
subscribers benefit, especially from many underdeveloped countries that can't 
afford the too expansive SSL certificate.
    (1) WoSign totally issued 100K SSL certificates in 2015 that we are posting 
to CT log server (not 115K, Sorry, I used the wrong search condition);
    (2) WoSign totally issued 230K SSL certificates till now for worldwide 
websites about 208 countries and regions. 55% from China, 45% is out of China 
that 14% from Russia, 4.2% from Germany, 3.6% from Ukraine, 2.1% from USA. 
Those worldwide subscribers mostly are using WoSign free SSL certificate that 
shared the benefit of China economy grow.  

Third, I believe no one dare to say his system no bug, WoSign admitted we have 
system bug that issued the wrong certificate and fixed. This is why WoSign is 
the first CA in the world for volunteering to "Require CT", we like to use CT 
mechanism to find out the bug quickly and reduce the lost to minimum, we logged 
all issued certificate to CT log server and embedded SCT data to certificate 
since July 5th. Thanks for Google invent so good transparency system.

Finally, I am very sorry to all browsers that we don't execute the incident 
report policy properly, WoSign get a deep lesson for how to deal with this kind 
of incident now, I wish everyone give us a chance to be a good boy, at least 
one-time chance.  Thanks a million.


Best Regards,

Richard Wang
CEO
WoSign CA Limited



-----Original Message-----
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign....@lists.mozilla.org] On 
Behalf Of Ryan Sleevi
Sent: Thursday, September 1, 2016 2:14 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

On Wednesday, August 31, 2016 at 10:07:19 AM UTC-7, watso...@gmail.com wrote:
> Dear Richard,
> 
> It's clear WoSign has continuing compliance issues with CA/Browser forum 
> rules, and has repeatedly failed to correct them. Furthermore there has been 
> lots of questions about what it would take to improve CA practices given the 
> degree of incompetence some have practiced, and it's clear penalties would go 
> a long way.
> 
> Is there a reason we shouldn't permanently ban WoSign, and all CAs controlled 
> by people involved with it, from the root program? 

For how long?

> It seems clear that WoSign has been misleading its auditors repeatedly and 
> has insufficient tracking of which certificates are issued, has been aware of 
> these problems for years, and has not been forthright in addressing them. 

These are all very compelling arguments.

> Making an example would do a lot to encourage better CA behavior in general.

This is less compelling, because "making an example" seems a subjective 
judgement/punitive response, although you to clarify "to encourage better CA 
behaviour".


At present, it looks like there's around 60K (active, valid) WoSign certs 
presently logged in CT logs, either through WoSign's logging or through 
secondary sources (such as Google's crawling). Richard has indicated that 
WoSign issued around 115K certificates in 2015 alone, but it's unclear how much 
overlap that would have; if we assume the worst case, and that they're all 
unique certs not previously before seen/logged (for example, perhaps due to the 
Great Firewall causing difficulty for Google's crawler), and if we generously 
extrapolate the same amounts for 2014, and take a quarter of that for 2013 
certs that could still be valid within the 39 month window, we end up with an 
"Extreme Worst Case" of 319K certs. While I suspect the number if likely much 
lower, especially when considering when WoSign switched to SHA-2 (as the SHA-1 
certs will be invalid by January 1, 2017), let's operate on two assumptions:
1) "Best Case" of say, ~200K valid certs
2) "Worst Case" of, say, ~319K valid certs

If browser vendors/root stores move to distrust WoSign, all of these certs 
would be invalidated. We know that a number of sites within the Alexa Top 1M 
are (intentionally) using WoSign, so we can expect a large number of users, 
across browser vendors, are accessing these sites, and would thus be seeing a 
significant amount of SSL/TLS error pages if the CA was distrusted. We know 
that major platform providers (such as Microsoft Azure) have partnered with 
WoSign as well, and thus further suggest a larger than desired user impact.


Setting aside for a second whether or not distrusting is the right action, 
let's think about what possible responses.

A) Remove the CA. Users may manually trust it if they re-add it, but it will 
not be trusted by default.
B) Actively distrust the CA. Even if manually added (by user or enterprise 
policy), it will not be trusted.
C) Remove the CA. Develop a whitelist of pre-existing certificates to be 
trusted.
  - What form should this whitelist take? 
    * Shipping it in the binary is unacceptably large.
    * Downloading it in full on demand is unacceptably large/unreliable.
    * Checking with a central server for serial number can lead to misleading 
results (WoSign has shown they issue duplicate serials, and nothing would 
prevent them from doing so in the future)
    * Checking with a central server for certificate hash may have privacy 
considerations.
    * Conclusion: Something SafeBrowsing-like would have to be developed ( 
https://developers.google.com/safe-browsing/v4/ ), which could be months away.
D) Distrust any certificate without appropriate CT information. Whitelist certs 
before 2016.
  - See whitelist problems above
E) Distrust certs without appropriate CT information, wholesale.
  - Note: It appears that WoSign is or has had similar issues to Symantec, 
failing to log to a diverse-enough set of logs to ensure a robust CT 
implementation. A quick and random sampling shows, for example, that 
precertificates are only being logged to Google logs (such as for 8-30-16). 
Thus, unless an implementation is willing to fully trust Google CT logs alone - 
something Google themselves are unwilling to do - then this suggests that this 
may be the same as wholesale distrusting.

In effect, a number of these options boil to a set of concerns:
- Distrusting can be significantly disruptive to end-users, potentially 
habituating them to SSL warnings or errors
- Distrusting potentially could interfere with those who may still want to 
trust WoSign manually, themselves
- Distrusting in a way that minimizes disruption has concerns for privacy, 
stability, or timeliness.

I'm not trying to suggest that distrusting is right or wrong, but I am curious 
for those who would advocate distrusting how browser vendors, such as Google 
and Mozilla, for example, might appropriately balance the concerns of the 
broader community, while also minimizing any damage, particularly to their 
users, and avoiding any reactionary responses.

It would seem like a form of whitelist (whether to continue trusting WoSign 
with CT enablement, or distrusting but grandfathering in disclosed certs, ala 
CNNIC) would require active development and assistance from the broader 
security and privacy community on how best to balance and scale such concerns, 
and regardless, would take time to implement, test, and deploy, but would be 
useful and possibly scalable for other future CA incidents. However, are there 
alternatives or concerns that I omitted from the above list?

In either event, hopefully this thought experiment brings into light the set of 
concerns that vendors, such as Mozilla and Google, may have to consider, and 
may help find an appropriate response that reflects the gravity of these 
incidents, and the handling of them, and may spark the community for ideas and 
solutions that can help balance those needs.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to