Ryan Sleevi <[email protected]> wrote: > On Thu, Nov 17, 2016 at 3:12 PM, Nick Lamb <[email protected]> wrote: > > There's a recurring pattern in most of the examples. A technical > counter-measure would be possible, therefore you suppose it's OK to > screw-up and the counter-measure saves us. I believe this is the wrong > attitude. These counter-measures are defence in depth. We need this defence > because people will screw up, but that doesn't make screwing up OK. > > I think there's an even more telling pattern in Brian's examples - > they're all looking in the past. That is, the technical mitigations > only exist because of the ability of UAs to change to implement those > mitigations, and the only reason those mitigations exist is because > UAs could leverage the CA/B Forum to prevent issues. > > That is, imagine if this was 4 years ago, and TCSCs were the vogue, > and as a result, most major sites had 5 year 1024-bit certificates. > The browser wants the lock to signify something - that there's some > reasonable assurance of confidentiality, integrity, and authenticity. > Yet neither 5 year certs nor 1024-bit certificates met that bar. >
The fundamental problem is that web browsers accept certificates with validity periods that are years long. If you want to have the agility to fix things with an N month turnaround, reject certificates that are valid for more than N months. In fact, since TCSCs that use name constraints as the technical constraints basically do not exist, you could even start enforcing even stricter enforcement than other certificates. For example, externally-operated name constrained intermediates could be limited to 12 months of validity even if other certificates aren't so restricted. Just make sure you actually enforce it in the browser. If you have a better plan for getting people to actually issue TCSCs of the name constrained variety, let's hear it. Cheers, Brian. -- https://briansmith.org/ _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
