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. > Note: I was *not* proposing that the root's validity (e.g. expiration time) be expressed. Merely it's duration/participation in the Mozilla store. This purposefully allows 'never-updating' clients to continue to consume the store (within the bounds of the root validity), while allowing 'frequently-updated' clients - e.g. what Mozilla actually ships - to maintain a more agile basis of trust. > > 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
