CA/Comodo Misissuance Response: Difference between revisions

← Older edit

CA/Comodo Misissuance Response (view source)

Revision as of 21:13, 30 December 2021

739 bytes added , 30 December 2021

m

Kathleen Wilson moved page CA:Comodo Misissuance Response to CA/Comodo Misissuance Response: Moved from CA: to CA/

Kathleen Wilson

Confirmed users, Administrators

5,526

edits

@@ Line 1: / Line 1: @@
-On 25th March 2011, in the wake of the Comodo misissuance incident, Mozilla began a wide-ranging discussion about the future of web security. This page links to resources related to that discussion. If you have a researched and carefully written paper on the subject, please feel free to add a link in the appropriate section. (Note that this page is not the venue for the debate - that is [https://www.mozilla.org/about/forums/#dev-security-policy here].)
+On 25th March 2011, in the wake of the Comodo misissuance incident, Mozilla began a wide-ranging discussion about the future of web security. This page links to resources related to that discussion. If you have a researched and carefully written paper on the subject, please feel free to add a link in the Position Papers section. (Note that this page is not the venue for the debate - that is [https://www.mozilla.org/about/forums/#dev-security-policy here].)
 ==Overall Aims==
@@ Line 9: / Line 9: @@
 * Accessibility - solutions should not put the cost of security, either in terms of single sites or large deployments, out of the reach of ordinary people
 * Simplicity - solutions should be simple to deploy, or capable of being made simple.
+* Privacy - ideally, web users should not have to reveal their browsing habits to a third party.
 ==Position Papers==
-''none yet''
+* [http://www.imperialviolet.org/2011/03/18/revocation.html Adam Langley]: "revocation doesn't work"
 ==Actions Within the Current Model==
@@ Line 37: / Line 38: @@
 * Require that all CAs arrange things so that each RA issues from a different subordinate cert.
 * Require that RAs are audited to the same standards as CAs.
+* Require that the identity of all RAs and SubCAs be publicly disclosed.
 * Require that all RA functions are protected by two-factor authentication and/or IP address restrictions.
+* Require that the domain control checks are always done by the CA, never the RA.
 * Require DNS Name Constraints to a specified number of [http://publicsuffix.org/ Public Suffixes] to be put on any non-leaf certificate the CA issues which it does not control (e.g. subordinate CAs).
+* Require a current-cert-is-not-EV check for all non-EV issuances (open a connection to port 443 on the target domain(s), or www. for wildcard certs, and flag for manual review if the current cert is EV)
+* Require the use of high-value target domain lists to flag requests, pre-issuance, for manual review.
 ===Changes to NSS===
@@ Line 56: / Line 61: @@
 * Turn on OCSP "hard fail" by default for everything.
 * Turn on OCSP "hard fail" just for EV (currently, we have a soft-fail - EV is downgraded to DV if OCSP fails).
-* Change it so that an OCSP failure is a hard failure if the site is using [http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security HSTS]
+* Change it so that an OCSP failure is a hard failure if the site is using [http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security HSTS]. Note that [http://www.ietf.org/mail-archive/web/websec/current/msg00296.html Chrome is moving in the opposite direction] for site uptime reasons.
-OCSP improvement solutions would need to deal with protocol problems such as the current ability to return "try again later". In addition, Google (as an example of a large site) are [https://mail1.eff.org/pipermail/observatory/2011-March/000115.html on record] as saying that they would oppose this, as they are not willing to tie their site's uptime to their CA's OCSP responder's uptime.
+OCSP improvement solutions would need to deal with protocol problems such as the current ability to [http://thoughtcrime.org/papers/ocsp-attack.pdf return "try again later"], as well as the uptime objections raised by large sites. They would also need to deal with issues like captive portals on WiFi hotspots where the login page is SSL-protected, and scenarios around proxy auth.
-They would also need to deal with issues like captive portals on WiFi hotspots where the login page is SSL-protected.
 ==Future Technologies==
@@ Line 96: / Line 99: @@
 * Yngve Pettersen [http://my.opera.com/yngve/blog/2009/10/16/extending-certificate-status-in-tls-extensions has proposed] [http://www.ietf.org/id/draft-pettersen-tls-ext-multiple-ocsp-02.txt an extension to OCSP stapling] which allows the stapling of more than one OCSP response.
-Google are [https://mail1.eff.org/pipermail/observatory/2011-March/000118.html on record] as saying that stapling multiple OCSP responses would unacceptably increase the amount of data that had to be exchanged for SSL setup beyond the initial TCP window size, thereby slowing down sites.
+Google are [https://mail1.eff.org/pipermail/observatory/2011-March/000118.html on record] as [http://www.ietf.org/mail-archive/web/websec/current/msg00296.html saying] that stapling multiple OCSP responses would unacceptably increase the amount of data that had to be exchanged for SSL setup beyond the initial TCP window size, thereby slowing down sites.
 * Rob Stradling has suggested that browsers should make sure to try every IP address that the OCSP server hostname resolves to before giving up, and even try multiple ones in parallel.