On Monday, September 12, 2016 at 8:01:36 PM UTC-7, Peter Bowen wrote: > 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.
To the immediate relevance, we know that two issuers can be, as is alleged w/ considerable evidence with StartCom & WoSign. My point in mentioning that, again, is to demonstrate the practical implications, since that is as relevant - and moreso - than the generic solution at this point in the conversation. But I think we're in agreement that it's not mutually exclusive. > 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. In every variation that I can interpret this as, this seems to be more work for limited value; among other things, it presumes adding back Root A is sufficient to avoid the whitelist, but the complexity involved in there, and the objective opinion being offered by software, makes that seem a profoundly unwise and undesirable scenario. I think if the goal is to allow re-recognition, that should be spelled out, and we should carefully think of the conditions of that and the implications of it. In my mind, it's not and shouldn't be a goal, if the overarching goal is to protect user security. > 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. I'm not aware of any path building library that prefers a "shortest-path" algorithm. They prefer "fastest path I can discover that works" algorithm. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
