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 

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

Reply via email to