Top comments for readability.
- IT professionals, server administrators, are humans, often overworked, who need care, assistance, and attention. In my past version, I offered helpdesk to helpdesk support and lost business that demanded helpdesk to end user server admin. - The caching I’m talking about is not header directives, I mean how CAPI and NSS retain discovered path for the life of the intermediate. One fetch, per person, per CA, for the life of the CA certificate. - AIA CAI URIs pushed to CDN? Mindless, one click. - I use the term user agent intentionally acknowledging that if all it took was 6 contracts, we’d have to run CABF meetings in convention centers. - When Microsoft first supported dynamic path discovery using AIA, we all fielded the support questions: why does IE work and X does not? We all pulled our AIA CAI extensions because the confusion wasn’t worth the benefit. - Ever since Vista, CAPI’s root store has been pulled over a wire upon discovery. Only kernel mode driver code signing roots are shipped. - Once the mass market UAs enable dynamic path discovery as an option, server admins can opt in based on analytics. - PKCS#7 chains are indeed not a requirement, but see point 1. It’s probably no coincidence that IIS supports it given awareness of the demands placed on enterprise IT admins. At this point, I may as well be hitting tennis balls off a cliff. You’re dug in. From: Ryan Sleevi [mailto:[email protected]] Sent: Monday, February 13, 2017 6:45 PM To: Steve Medin <[email protected]> Cc: [email protected]; Patrick Figel <[email protected]>; [email protected]; Gervase Markham <[email protected]> Subject: Re: Intermediates Supporting Many EE Certs On Mon, Feb 13, 2017 at 2:39 PM, Steve Medin <[email protected] <mailto:[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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
