CAs are running OCSP responders up to the root tier. Once a CA is terminated in a standards-compliant and densely interoperable way from participating in a trusted discovery path to an embedded root, it should no longer be in the scope of business of root trust store owners.
On Wed, Jun 22, 2016 at 1:52 PM Eric Mill <e...@konklone.com> wrote: > On Tue, Jun 21, 2016 at 12:10 PM, Peter Bowen <pzbo...@gmail.com> wrote: > > > On Tue, Jun 21, 2016 at 8:26 AM, Rob Stradling <rob.stradl...@comodo.com > > > > wrote: > > > Revocation of a "parent intermediate" does not exempt "child > > intermediates" > > > from the disclosure requirement, AFAICT. So I think the KBC Group CAs > do > > > need to be disclosed to Salesforce. > > > > If all paths from a trusted root to a given intermediate are revoked > > or expired, then I don't think it "directly or transitively chain[s] > > to a certificate included in Mozilla’s CA Certificate Program". It > > would be no different than a private CA which isn't part of the WebPKI > > graph. > > > > Expired makes sense. Revoked only makes sense if the certificates are > revoked in practice. My understanding right now is that Chrome and Firefox > only enforce revocations for intermediates if the revocation is distributed > through CRLset or OneCRL, respectively. > > I don't know what Apple's or Microsoft's processes are, and I don't think > that OneCRL alone would be sufficient to say that a certificate has been > practically revoked in the web PI. > > Since this is being done in a comprehensive way, where we have some level > of assurance that this is meaningfully closing off a category of weakness > in the web PKI, perhaps we could get commitments from some or all of the > major browsers to ensure that all undisclosed revoked intermediates are > distributed through channels that make them actionable. Without something > like that, I'm not sure any risk has been mitigated by revocation alone. > > -- Eric > > > > Thanks, > > Peter > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > > > > > -- > konklone.com | @konklone <https://twitter.com/konklone> > _______________________________________________ > 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
