With de facto use of AIA, there is no issuer installation on the server that could be improper. Proper is defined at the moment, either by cache or discovery hints.
CA Issuers AIA resolution of EE to issuer is good enough for government work, and fortunately the market offers software that consumes it. I don’t consider the Federal Bridge papered over or the FPKI PA an authority that papers over their solutions. We can roll issuing CAs with less operator error if we can reliably use AIA and educate that the issuing chain does not need to be installed, maintained, or passed in the TLS payload. We all understand that microseconds are core to your business model. We’re talking about one hit every N years or N-thousand certificates. You’re going to earn back the time spent through smaller TLS payload no longer sending intermediates that are already cached. We can deploy AIA CA Issuers support across user agents faster than we can deploy PKCS#7 support across servers. From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Monday, February 13, 2017 3:35 PM To: Steve Medin <steve_me...@symantec.com> Cc: Patrick Figel <patrick@figel.email>; r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org; Gervase Markham <g...@mozilla.org> Subject: Re: Intermediates Supporting Many EE Certs As mentioned, I'm a strong proponent of AIA - I think it serves a valuable role in ecosystem agility for root migrations - but I don't think it's necessarily good for users when it's used to paper over (clear) server misconfigurations, which is the situation you describe - where the path from the EE to the Intermediate is improper. I'm more thinking about situations for where the Intermediate to Root path may change, in order to accommodate changes in the Root (from Root 1 to Root 2).
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
