On Mon, Sep 12, 2016 at 7:02 PM, Ryan Sleevi <[email protected]> wrote: > On Monday, September 12, 2016 at 6:09:05 PM UTC-7, Peter Bowen wrote: >> This would have two advantages: >> 1) Helps limit blast radius of whitelisting a name/domain > > I'm unclear what you mean by this. I suggest there's an additional, unstated > threat model or concern?
I'm trying to think of this as potentially reusable code. Just because IssuerA is quasi-trusted for example.com doesn't mean IssuerB should be. From a logic perspective, setting the whitelist per issuer means you are basically creating name-constrained issuers. >> 2) Provides a path for a CA to continue issuing >> certificates for use with trust stores and users that continue to >> trust them. They could create new issuers from the existing roots >> which wouldn't be subject to the whitelist. Users who want to trust >> them simply need to add the roots to their trust store if the roots >> are not already there. > > If such a path seems desirable and worthwhile, that's certainly true. Call > that a variation of G, then, perhaps G.2, as perhaps not all trust stores > would consider a proverbial path to redemption at the Intermediate level, and > might only consider it at the Root level. I guess I wasn't clear enough. I'm thinking that the trust store would remove RootA but add IssuerA1, IssuerA2, etc as trust anchors. So RootA could create IssuerNewA12 or whatever and issuer from that. As the trust store doesn't have RootA at all (not trusted or distrusted), users could choose how to handle RootA going forward. RootA's operator could also apply to have RootA added back to the trust store at some future point. >> Requiring new issuers would also allow #3 to be easily enforced over a >> disjoint set from the whitelist and allow various pinning-like rules >> to be created in software (browsers or otherwise). > > Possibly. However, unless #3 is implemented simultaneously (and as you know, > it has a dependency on a CA component), it's more likely that implementing #2 > and requiring a new root is functionally the same, but with significant less > complexity in code or for relying parties. Again, assuming issuers are added as trust anchors, a "shortest path" algorithm would choose them over a re-added Root. The Root could have additional restrictions applied (e.g. Expect-CT) that don't apply to the old issuers. Thanks, Peter _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
