I think rotating intermediates is a good way to limit the impact of intermediate revocation/compromise, and one we tried to implement a while ago. We had a policy that every x companies would be put on an intermediate. I think we even pitched it as a suggested requirement on the Mozilla list back in 2010.
As we tied the intermediate to a specific set of companies (which correlated roughly to a specific volume of certificates), renewal and pinning were non-issues. As long as each company was identified under the same umbrella, an entity renewing, ordering a new cert, or pinning received the same intermediate each time and was tied to the specific entity. Jeremy -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Patrick Figel via dev-security-policy Sent: Monday, February 13, 2017 12:10 PM To: [email protected] Cc: Gervase Markham <[email protected]>; [email protected] Subject: Re: Intermediates Supporting Many EE Certs On 13/02/2017 18:25, Ryan Sleevi via dev-security-policy wrote: > On Mon, Feb 13, 2017 at 8:17 AM, Steve Medin via dev-security-policy < > [email protected]> wrote: > >> Getting all user agents with interest is issuance limits to implement >> the CA Issuers form of AIA for dynamic path discovery and educating >> server operators to get out of the practice of static chain >> installation on servers would make CA rollovers fairly fluid and less >> subject to operator error of failing to install the proper intermediate. > > > Can you explain more to support that statement? > > The issue that Gerv is discussing is primarily related to intermediate > issuance; a CA an easily roll over to a new intermediate and provide > their customers a holistic chain that represents a path to a Mozilla > root. The issue you describe - with AIA fetching - is one primarily > restricted to handling _root_ rollover, not _intermediate_ rollover; > that is, when you're constructing an alternative trust path for a set > of existing certificates, rather than, as Gerv raised, ensuring that > new certificates come from a single ('new') trust path once the > existing intermediate has been 'exhausted'. > > While a strong proponent of AIA, I don't believe your argument here is > relevant, although I'm quite happy to understand what technical > criteria exist that make you believe it would be beneficial to address > this specific problem. I suspect many CAs would be reluctant to rotate intermediates regularly because updating the intermediate certificate would be yet another thing that server administrators can get wrong during renewal. Data from Chrome shows that incorrect or missing intermediates account for 10-30% of all certificate validation errors depending on platform[1], though I'm guessing missing intermediates would account for most of that. Let's Encrypt switched to a new intermediate certificate about a year ago. Despite plenty of warnings that it may change at any time and a protocol that allowed retrieving the intermediate certificate programmatically, there were still a number of clients and guides with static intermediates out there, which caused breakage for some sites once they renewed. This is the main reason why later versions of the ACME draft switched to delivering the end-entity certificates and intermediates as one file by default. Having support for AIA fetching in all major browsers would reduce the impact of such misconfigurations. IIRC the only browsers that currently don't do this are Firefox and Chrome on Android, though the latter seems to have plans to change this. Something else that needs to be considered is how it affects HPKP deployment. I don't know if there are any CAs out there who recommend pinning to (not-customer-specific) intermediates, but if there are any, we might need either an exemption for renewals or make sure CAs recommend pins that aren't affected by the rotation policy. I'd be interested in the CA perspective on this; perhaps the lack of HPKP adoption and CA documentation on this topic makes this a non-issue anyway. (It would, of course, be possible to rate the intermediate certificates without rotating the keys, but doing that causes interoperability issues[2], so I suspect most CAs wouldn't want to do that regularly.) [1]: https://docs.google.com/document/d/1ryqFMSHHRDERg1jm3LeVt7VMfxtXXrI8p49gmtni NP0/edit?pli=1 [2]: https://serverfault.com/questions/706252/iis-sends-incorrect-intermediate-ss l-certificate/706278#706278 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
