On Mon, Feb 13, 2017 at 2:39 PM, Steve Medin <[email protected]> wrote:
> 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. > I think this may be the crux of our disagreement. I believe that an ideal configuration is one that is the most efficient for the most users. Anything less - that is, things that slow connections or require all clients to introduce additional logic - is an improper configuration. This is similar to an HTTP server that always forced an extra redirect or which failed to use modern cryptographic algorithms or which sent along an extra 40KB of non-gzip'd JS. It may be valid in the protocol, but it's an improper configuration. Some improper configurations - however valid - can cause breakage. Others can be papered over. Any time it's papered over, that's a "hack", not a desired end state. > 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. > In practice, we don't, given CAs' poor responsiveness for AIA fetches and the poor configurations for cache lifetimes. In theory, yes. In practice, no. > > > We can deploy AIA CA Issuers support across user agents faster than we can > deploy PKCS#7 support across servers. > This is false for most values, because "user agents" extend beyond the Big Five browsers (Chrome, Edge/IE, Firefox, Safari, Opera). Consider software such as curl, or clients such as Python or Perl. In those scenarios, your deployment scenario is as-bad-or-worse than the server support, but focusing on server support is a several orders of magnitude less work for implementation or deployment. Also, to be clear, the deployment of intermediates in no way requires PKCS#7 support. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
