Patrick, thanks, it appears my attempt at brevity produced density.

- No amount of mantra, training, email notification, blinking text and
certificate installation checkers make 100% of IT staff who install
certificates on servers aware that issuing CAs change and need to be
installed with the server certificate when they do.
- Many servers do not support PKCS#7 installation.
- When you roll an intermediate issuer and you modify the end entity
certificate's AIA CA Issuers URI at the same time, the server presents an EE
to the browser that provides a remedy to path validation failure.
- The browser does its normal path discovery using cached discovered
- At rollover, the browser doesn't find the EE's issuer cached locally.
- The browser chases AIA to the issuer that the EE asserts is its issuer,
validates that, and caches the issuer for another <lifespan limit> years.
It's a one-validation latency cost per end user given cached path discovery.

Recently, we renewed a subordinate under the Federal Bridge CA and we
deployed trust across the community by updating a JBoC PKCS#7 file
referenced by the CA Issuers AIA. Granted, this is what some may call a
cross-certificate rather than subordination, but my point is that the end
entities that point to the .p7c enable peers and clients to discover path of
FBCA > SSP Gen 1 CA > EE as easily as FBCA > SSP Gen 2 CA > EE. 

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
>] On Behalf Of
> Patrick Figel via dev-security-policy
> Sent: Monday, February 13, 2017 2:10 PM
> To:
> Cc: Gervase Markham <>; mozilla-dev-security-
> 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 <
> >> 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
> >
> >
> > 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
> 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
> allowed retrieving the intermediate certificate programmatically, there
> still a number of clients and guides with static intermediates out there,
> 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
> 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
> 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
> rotating the keys, but doing that causes interoperability issues[2], so I
> suspect most CAs wouldn't want to do that regularly.)

Attachment: smime.p7s
Description: S/MIME cryptographic signature

dev-security-policy mailing list

Reply via email to