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:r...@sleevi.com] 
Sent: Monday, February 13, 2017 6:45 PM
To: Steve Medin <steve_me...@symantec.com>
Cc: r...@sleevi.com; Patrick Figel <patrick@figel.email>; 
mozilla-dev-security-pol...@lists.mozilla.org; Gervase Markham 
<g...@mozilla.org>
Subject: Re: Intermediates Supporting Many EE Certs

 

 

 

On Mon, Feb 13, 2017 at 2:39 PM, Steve Medin <steve_me...@symantec.com 
<mailto:steve_me...@symantec.com> > 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.

 

Attachment: 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

Reply via email to