On 27/03/14 17:11, Emilia Kasper wrote: <snip>
Right. So this particular case could be handled by carefully constructing the shortest possible chain from all AIA information available (system store, p7c, crt).
In that particular case, yes, I suppose so. However, our "older" AddTrust/UTN roots have also cross-certified some of our "newer" roots. So, in some cases, shortest possible chain (to a known, trusted root) would be too short!
But I agree that it's gnarly, a bunch of ugly code, and hugely undeterministic (what if the .crt responds but the .p7c request errors out?).
Indeed.
Would you agree that it's safe to do a one-hop AIA-autocorrection for leaves only, i.e. certs with NO intermediates configured? My hunch is that this would fix the bulk of misconfigured chains while leaving the ugly cross-signing cornercases alone.
I think it's probably "safe" in the sense that it wouldn't cause additional misconfiguration (and would sometimes cause correct configuration).
But I'm in two minds about whether or not it's a good idea. IMHO, AIA chasing bears much of the blame for the problem we're trying to fix here. Why? Because when a site administrator tests their site in a browser that does AIA chasing (such as Internet Explorer), it "works", so they don't notice and fix the misconfiguration.
One-hop AIA-autocorrection might well make the configuration less broken (e.g. a missing intermediate is added), but still not correct (e.g. a missing cross-certificate is not added). Being less broken would mean that the remaining brokenness is less likely to be detected and corrected.
So if the goal is to maximize the % of servers that are 100% correctly configured, one-hop AIA-autocorrection might actually be counterproductive.
-- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online
