Ryan, GlobalSign has been thinking along these lines, but it's not clear how browsers build their path when a cross certificate is presented to them in the TLS handshake.
Can you explain how chrome (windows and Android) builds a path when a cross certificate is delivered? What about the case when the OS (Microsoft specifically) has cached the cross certificate, is it different? With this approach, we'd require our customers to configure their web servers to always send down the extra certificate which: * complicates web server administration, * increases TLS handshake packet sizes (or extra packet?), and * increases the certificate path from 3 to 4 certificates (SSL, issuing CA, Cross certificate, Root), which increases the path validation time and is typically seen as a competitive disadvantage Do you view these as meaningful issues? Do you know of any CAs that have taken this approach? -----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Ryan Sleevi via dev-security-policy Sent: Thursday, August 1, 2019 2:51 PM To: Bruce <bruce.mor...@entrust.com> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Entrust Root Certification Authority - G4 Inclusion Request 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
