On Monday, September 12, 2016 at 6:09:05 PM UTC-7, Peter Bowen wrote: > I'm not clear from this description, are you proposing to whitelist > eTLD+1 or full hostnames? How large would the lists be if you > whitelisted eTLD+1?
This is whitelisting at eTLD+1 (although with a slightly older version of the PSL - hence reference to domains my myasustor.com); that is, it tries to be compatible with Alexa's notion of "effective domain". > I also think per-issuer whitelists might make more sense than a single > massive WoSign/StartCom whitelist. >From a security standpoint, absolutely; the technical details I was >intentionally being a little handwavy on (e.g. you can get better compression >when using a single list), but at least now it gives us concrete numbers to >talk about. > 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? > 2) Provides a path for WoSign/StartCom 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. > 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. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
