While the internet is moderately good at handling a single cross-sign (modulo the challenges we had with 1024-bit root deprecation due to a bug in OpenSSL's path building -- now fixed), as we extend the chains, it seems evident to me that server operators are unlikely to configure their servers to serve a chain which works on all clients -- the likely result is clients will need AIA chasing. Most (all?) non-browsers do not implement AIA chasing. This isn't an objection, just a flag and a potential action item on the "non-browser" side of this.
Alex On Tue, May 16, 2017 at 10:27 AM, Rob Stradling <rob.stradl...@comodo.com> wrote: > On 16/05/17 14:45, Doug Beattie via dev-security-policy wrote: > >> Ryan, >> >> If you look at the wide range of user agents accessing google.com today >> you'd see many legacy applications and older versions of browsers and >> custom browsers built from variants of the commercial browsers. By the >> time all/most users upgraded to new browsers, it would be time to change >> the roots out again and this will impact the ability for web site operators >> to enable TLS for all visitors. >> >> Before we can implement a short Root usage policy we'd need to convince >> all browsers to follow a process for rapid updates of root stores. >> > > Hi Doug. > > Imagine a root cert A, valid for a short duration; and a root cert B, > valid for a long duration. > > Under Ryan's proposal, Mozilla would put A (but not B) in NSS, whereas > other less agile root stores would contain B. > > A doesn't have to be in every root store, because B can cross-certify A. > (Let's call the cross-certificate A'). > > A widely compatible cert chain would therefore look like this: > B -> A' -> Intermediate -> Leaf > > If you're already cross-certifying from an older root C, then an even more > widely compatible cert chain would look like this: > C -> B' -> A' -> Intermediate -> Leaf > > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
