<story><title>Around 293 intermediate CAs in violation of CA/Browser guidelines</title><url>https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13493.html</url></story><parent_chain><item><author>zenexer</author><text>The link is very technical, resulting in some confusion as to why this is such a big problem. The comments on HN reflect that. Here’s my understanding:&lt;p&gt;This isn’t a problem because a sub-CA can revoke any certificate from any other sub-CA of the same CA. That would be bad, but, at worst, it’s denial-of-service.&lt;p&gt;Rather, this is a problem because any sub-CA can effectively &lt;i&gt;reverse&lt;/i&gt; the revocation of any other sub-CA, or the CA itself. That’s immensely problematic. Suddenly, the CA has no reliable way fully revoke certificates. Revocation is already somewhat broken as it is, but this gives a lot of entities the ability to deliberately interfere with revocation in ways that they shouldn’t be able to.&lt;p&gt;The author goes on to explain that revocation of the affected certificates is insufficient, because they could be used to effectively reverse their own revocation at any point in the future. Instead, it must be proven that all copies of the keys have been destroyed. That’s quite an undertaking.&lt;p&gt;What the author fails to mention is that revocation is already pretty broken. Most major browsers have their own built-in CRL replacements that contain the most important revocations they need to know about. Some browsers, like Firefox, may make additional efforts to ensure that any given certificate hasn’t been revoked; others, like Chrome, don’t. If you’ve ever visited a site that gives you a certificate error in Firefox but not Chrome, that’s likely why.&lt;p&gt;In the case of browsers, it should be possible for each browser to forcefully revoke affected certificates, but revoking a sub-CA certificate is quite disruptive, so I’d be surprised if that happens within 7 days. The catch is that this technique is really only effective in modern, up-to-date browsers.&lt;p&gt;In any case, the title is misleading. I don’t see where the author guarantees that this will happen within 7 days. The author claims it &lt;i&gt;should&lt;/i&gt; happen within 7 days, but considering that the damage is already done and cannot be fully reversed by revocation, I find it hard to believe enforcing that deadline makes sense here.</text></item></parent_chain><comment><author>terom</author><text>There&amp;#x27;s a reply from Ben Wilson (Mozilla) further down in the thread &amp;#x2F; the next day stating that Firefox as a client is not affected by the security issue (OCSP responses signed by these intermediate CAs would be rejected), and that Mozilla is not planning on enforcing the 7 day deadline for revocation of these intermediate certificates. The CAs  will still need to replace these intermediate CAs, but with a more gradual timeline.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.mail-archive.com&amp;#x2F;dev-security-policy@lists.mozilla.org&amp;#x2F;msg13537.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.mail-archive.com&amp;#x2F;dev-security-policy@lists.mozil...&lt;/a&gt;&lt;p&gt;&amp;gt; We are concerned that revoking these impacted intermediate certificates within 7 days could cause more damage to the ecosystem than is warranted for this particular problem. Therefore, Mozilla does not plan to hold CAs to the BR requirement to revoke these certificates within 7 days. However, an additional Incident Report for delayed revocation will still be required, as per our documented process[2].  We want to work with CAs to identify a path forward, which includes determining a reasonable timeline and approach to replacing the certificates that incorrectly have the id-kp-OCSPSigning EKU (and performing key destruction for them).</text></comment>
<story><title>Around 293 intermediate CAs in violation of CA/Browser guidelines</title><url>https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13493.html</url></story><parent_chain><item><author>zenexer</author><text>The link is very technical, resulting in some confusion as to why this is such a big problem. The comments on HN reflect that. Here’s my understanding:&lt;p&gt;This isn’t a problem because a sub-CA can revoke any certificate from any other sub-CA of the same CA. That would be bad, but, at worst, it’s denial-of-service.&lt;p&gt;Rather, this is a problem because any sub-CA can effectively &lt;i&gt;reverse&lt;/i&gt; the revocation of any other sub-CA, or the CA itself. That’s immensely problematic. Suddenly, the CA has no reliable way fully revoke certificates. Revocation is already somewhat broken as it is, but this gives a lot of entities the ability to deliberately interfere with revocation in ways that they shouldn’t be able to.&lt;p&gt;The author goes on to explain that revocation of the affected certificates is insufficient, because they could be used to effectively reverse their own revocation at any point in the future. Instead, it must be proven that all copies of the keys have been destroyed. That’s quite an undertaking.&lt;p&gt;What the author fails to mention is that revocation is already pretty broken. Most major browsers have their own built-in CRL replacements that contain the most important revocations they need to know about. Some browsers, like Firefox, may make additional efforts to ensure that any given certificate hasn’t been revoked; others, like Chrome, don’t. If you’ve ever visited a site that gives you a certificate error in Firefox but not Chrome, that’s likely why.&lt;p&gt;In the case of browsers, it should be possible for each browser to forcefully revoke affected certificates, but revoking a sub-CA certificate is quite disruptive, so I’d be surprised if that happens within 7 days. The catch is that this technique is really only effective in modern, up-to-date browsers.&lt;p&gt;In any case, the title is misleading. I don’t see where the author guarantees that this will happen within 7 days. The author claims it &lt;i&gt;should&lt;/i&gt; happen within 7 days, but considering that the damage is already done and cannot be fully reversed by revocation, I find it hard to believe enforcing that deadline makes sense here.</text></item></parent_chain><comment><author>gruez</author><text>&amp;gt;The author goes on to explain that revocation of the affected certificates is insufficient, because they could be used to effectively reverse their own revocation at any point in the future. Instead, it must be proven that all copies of the keys have been destroyed. That’s quite an undertaking.&lt;p&gt;How would this be verified? Presumably the keys are stored on HSMs, but you can I&amp;#x27;m not sure how you can prove that you didn&amp;#x27;t make a backup of the key.</text></comment>