On Tue, May 16, 2017 at 10:34 AM, Doug Beattie <doug.beat...@globalsign.com> wrote:
> Thanks Rob and Ryan for pointing that out. Will the web servers need to > send down a group of cross certs and then let the client use the ones they > need in order to chain up to a root in their local trust store since the > web server might not know which roots it has? > Doug: Yes, that was the substance of the original proposal, when it posed the following: On Y3, you generate new root and new intermediate, and then cross-sign, > such that you have > (old root) -> (old intermediate) -> (old existing certs) > -> (new root) -> (new intermediate) -> (new leaf certs) > Sites can either rely on AIA (Ideal, but unfortunately, not yet supported > by Mozilla) or simply supply the full chain (less ideal, wasteful on > bandwidth and caching), of either > (site cert) -> (new intermediate) -> (new root) [the AIA path] > (site cert) -> (new intermediate) -> (new root) -> (old root) [the slow, > compatibility path] The important point in this is that there should not be a non-linear path of trust (which is implied, I think, by the reading of "group of cross-certs"). But yes, there would be a linearized path. Unquestionably, this means that performance gets worse for sites who support clients that do not support AIA and who serve the extra (potentially unnecessary) chains. This does put a certain pressure on these clients _to_ support AIA, and the performance implications would only become worse the longer the legacy clients exist. However, if/when 'enough' clients support AIA (or automatic updates), the performance costs evaporate. This helps create a virtuous cycle in which site operators are incentivized to support clients that support AIA/automatic updates, and software developers are incentivized to provide clients that support AIA/automatic updates :) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
