Richard Barnes <rbar...@mozilla.com> wrote: > Small CAs are a bad risk/reward trade-off. >
Why do CAs with small scope even get added to Mozilla's root program in the first place? Why not just say "your scope is too limited to be worthwhile for us to include"? > One way to balance this equation better is to scope the risk to the scope > of the CA. If a CA is only serving a small slice of the web, then they > should only be able to harm a small slice of the web. A CA should only be > able to harm the entire web if it's providing benefit to a significant part > of it. > > I wonder if we can agree on this general point -- That it would be > beneficial to the PKI if we could create a mechanism by which CAs could > disclose the scope of their operations, so that relying parties could > recognize when the CA makes a mistake or a compromise that goes outside > that scope, and prevent harm being done. > Mozilla already tried that with the HARICA CA. But, the result was somewhat nonsensical because there is no way to explain the intended scope of HARICA precisely enough in terms of name constraints. > I think of this as CA scope transparency. Not constraining what the CAs > do, but asking them to be transparent about what they do. That way if they > do something they said they don't do, we can recognize it and reject it > proactively. > In general, it sounds sensible. But, just like when we try to figure out ways restrict government CAs, it seems like when we look at the details, we see that the value of the name constraints seems fairly limited. For example, in the HARICA case, their name constraint still includes "*.org" which means they can issue certificates for *.mozilla.org which means they are a risk to the security of the Firefox browser (just like any other CA that can issue for *.mozilla.org) except when the risk is limited by key pinning. It would be illustrative to see the list of CAs that volunteer to be constrained such that they cannot issue certificates for any domains in *.com. It seems like there are not many such CAs. Without having some way to protect *.com, what's the point? Cheers, Brian _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
