On Fri, Jul 26, 2019 at 4:29 PM Bruce via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On Friday, July 26, 2019 at 1:45:06 PM UTC-4, Ryan Sleevi wrote: > > (In a personal capacity, as normally noted but making sure to extra-note > it > > here) > > > > Hi Wayne, > > > > It wasn't clear to me from the inclusion request, did Entrust give a > reason > > for the requested addition? For example, do they plan to stop issuing > from > > one of the included roots and have it removed? > > The purpose of the inclusion request is to add a 4096-bit RSA root which > will be used to support larger keys as we move ahead. We are not looking at > this root to replace our current roots, but plan to migrate to the new root > as the demand for larger keys grows. We are not planning remove any of our > roots at this time. > It seems like it should be technically possible to use this root to replace an existing root, which seems like it would align well with the goal of ensuring larger key support going forward. For example, if "tomorrow" (hypothetically; I know it takes time) you: 1) Cross-signed the 4K root with an existing root 2) Issued a new issuing intermediate under the 4K root 3) Issued all new certificates going forward from that new issuing intermediate Then it would seem like there's a path to ensure that all clients which support your existing, legacy roots, would automatically support your 4K root, building a path to your legacy root. Clients which installed/shipped the 4K root would build shorter paths, and without the intermediate signature from the legacy root to the 4K root. Once all of your existing "Legacy" certificates expire (that is, those issued from your old legacy issuing intermediate) - which, admittedly, would likely be 825 days from "tomorrow" - clients could remove support for the "Legacy" certificate without breaking any existing certificates. Did you consider such a transition plan? That would allow clients to minimize the number of roots a given organization has, which helps reduce the security risk and maintenance overhead to clients, while still allowing a smooth and seamless transition. It seems like a win for everyone, and would be great to know more about those considerations if deciding to accept this new root. >From the current description, it sounds like this new root may not provide clear user benefit, since it's not clear that it's functionally differentiated from the existing root, which seems to be wholly sufficient for the cryptographic needs of Firefox users. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
