In bug 485052, Rob implemented the PSM callback for functionality Nelson implemented in bug 483168 to allow us to associate default OCSP responders with CAs. This was motivated largely by the fact that the version of NSS in deployment at the time lacked CRLDP support, and the CAs in question had not yet migrated to OCSP. Trunk is now using an NSS version well beyond the implementation of CRLDP support, so it makes sense to me that we should remove the provisions added to compensate for its absence. (In fact, older supported versions of Firefox have since moved to newer NSS tags as well, but I'm in no rush to backport these changes - getting it removed on trunk should be good enough to remove the maintenance burden going forward.)

Johnathan, I accept that planning the removal of the Default OCSP PSM callback code (aka "my code") is a legitimate housekeeping exercise. However, I'd rather you wait until it's 100% no longer useful before removing it. Here are some reasons why I believe it's still useful... 1. There are still some certs in the wild (from Issuers mentioned in myDefaultOCSPResponders[]) that contain CRLDP but not AIA->OCSP. My code causes PSM to do an OCSP lookup instead of a CRL lookup for these certs. IMHO, OCSP lookups are preferable, because CRLs are normally significantly larger than OCSP responses. 2. Nelson posted to mozilla.dev.security.policy 1.5 months ago: "There are separate code paths in the browser (in PSM) for EV and for non-EV certs. The non-EV code path is the old original code path. It uses an old NSS API for cert path validation, one that is not able to do CDP support. When the new PSM code was written for EV support, it was written to use the new NSS API with CDP support, and the non-EV PSM code path was not changed. To get the non-EV PSM code path to support CDP, it would have to be re-written to use the new NSS API that supports CDP. That can be done, but it's work that the browser PSM folks have not yet planned to do, AFAIK." My code currently causes PSM to do OCSP lookups for some non-EV certs that don't contain AIA->OCSP. If it's true that PSM still doesn't support CRLDP for non-EV certs, then removing my code would mean that PSM would do *no* revocation checking of these certs. And if it's true that PSM does *no* revocation of non-EV certs that don't contain AIA->OCSP, perhaps there are other CAs who now operate OCSP Responders who might like to *add* their details to myDefaultOCSPResponders[] ?!? 3. Removing my code would cause a reduction in OCSP traffic and a corresponding increase in CRL traffic. At the very least, I think the affected CAs should be notified of this and have a chance to plan for it. (At Comodo, we've recently been scaling up our OCSP Responder infrastructure; we haven't been scaling up our CRL hosting capability nearly as much. I'm sure we'd cope with an increase in CRL traffic, but I think we'd rather see an increase in OCSP traffic). 4. If it ain't broke, don't fix it. ;-) What "maintenance burden going forward" do you foresee?

To be clear, Rob, I'm talking about doing this on mozilla-central - so there is no scenario that would see it in deployment code any earlier than Firefox 3.7, which will be a minimum of 5-6 months after Firefox 3.6, which still hasn't (quite) gone out the door. With that being said, then: (In reply to comment #2) > 1. There are still some certs in the wild (from Issuers mentioned in > myDefaultOCSPResponders[]) that contain CRLDP but not AIA->OCSP. My code > causes PSM to do an OCSP lookup instead of a CRL lookup for these certs. IMHO, > OCSP lookups are preferable, because CRLs are normally significantly larger > than OCSP responses. Yeah, but you and I know that legacy is a bad reason to hold off client changes, because it just prompts more legacy. c.f. Nelson's recent thread about SSL handshake downgrades. How many fewer of those legacy certs will be around in 7 months? How much time should we give them? > 2. Nelson posted to mozilla.dev.security.policy 1.5 months ago: > "There are separate code paths in the browser (in PSM) for EV and for non-EV > certs. The non-EV code path is the old original code path. It uses an old NSS > API for cert path validation, one that is not able to do CDP support.... > My code currently causes PSM to do OCSP lookups for some non-EV certs that > don't contain AIA->OCSP. If it's true that PSM still doesn't support CRLDP for > non-EV certs, then removing my code would mean that PSM would do *no* > revocation checking of these certs. > And if it's true that PSM does *no* revocation of non-EV certs that don't > contain AIA->OCSP, perhaps there are other CAs who now operate OCSP Responders > who might like to *add* their details to myDefaultOCSPResponders[] ?!? Yep, this is an important point. Kai - what is the reason we haven't enabled CRLDP support on non-EV chains, and is it appropriate to do that as part of this patch? > 3. Removing my code would cause a reduction in OCSP traffic and a corresponding > increase in CRL traffic. At the very least, I think the affected CAs should be > notified of this and have a chance to plan for it. (At Comodo, we've recently > been scaling up our OCSP Responder infrastructure; we haven't been scaling up > our CRL hosting capability nearly as much. I'm sure we'd cope with an increase > in CRL traffic, but I think we'd rather see an increase in OCSP traffic). While it's tautological that removing OCSP-preferring code will decrease OCSP traffic, the degree to which it does so is really down to the issuing CAs. I'd like to see more OCSP traffic too, and it's great to see the work Comodo and others have done to improve their OCSP capacity. I don't think it's a good reason to keep non-standard validation paths around longer than we need to, though. And if this lands, there'll be at least 6-7 months' notice. > 4. If it ain't broke, don't fix it. ;-) > > What "maintenance burden going forward" do you foresee? When it comes to adding code, I agree, if it ain't broke, keep away. But all code has costs, and this code is: - workaround code - that behaves in a non-standard way - in a module that lies at the intersection of discrete codebases (NSS & Gecko) - and meaningfully impacts security decisions made by the browser If a scary bug shows up here, the number of people who can be counted on to turn around a fix during an emergency release is pretty small, and the chance of making a mistake is high. But really, it doesn't need to be any of that to be justifiable deletion -- we shouldn't keep code around through inertia. We knew this code had an expiry date when we wrote it, I just don't want to lose track of that.

Hi Johnathan. Thanks for clarifying the situation. Since this won't be rolled out for 5+ months, I withdraw my objections. I will follow the "CRLDP support on non-EV chains" developments with interest. Do you plan to notify the other affected CAs about this bug?

Comment on attachment 415103 [details] [diff] [review] Patch v1 r=honzab

IINM (and I might be), removing Rob's code will have these effects on visits to sites whose certs now trigger Rob's code: a) For EV certs with CDP extensions, OCSP fetches will be reduced and CRL fetches will be increased. Probably a net increase (hopefully small) in perceived network latency due to increased size of revocation information being downloaded, in some cases. No net effect on security though. b) for non-EV certs, OCSP fetches will cease, and revocation checking will also effectively cease, unless and until PSM's non-EV code is modified to use CERT_PKIXVerifyCert for non-EV certs, also. I perceive this is a net reduction in user security. I'd recommend that the patch to remove Rob's code be held off until such time as Mozilla elects to modify PSM to use CERT_PKIXVerifyCert.

(In reply to comment #6) > IINM (and I might be), removing Rob's code will have these effects on visits > to sites whose certs now trigger Rob's code: > ... > b) for non-EV certs, OCSP fetches will cease, and revocation checking will > also effectively cease, unless and until PSM's non-EV code is modified to > use CERT_PKIXVerifyCert for non-EV certs, also. I perceive this is a net > reduction in user security. > > I'd recommend that the patch to remove Rob's code be held off until such > time as Mozilla elects to modify PSM to use CERT_PKIXVerifyCert. I agree - as I say in comment 3, I think that point is an important one that needs resolving before we land this.

reassign bug owner. mass-update-kaie-20120918

Here is Kai's patch, rebased to the NSS trunk and updated to remove now-unnecessary #includes. (In reply to Rob Stradling from comment #2) > 1. There are still some certs in the wild (from Issuers mentioned in > myDefaultOCSPResponders[]) that contain CRLDP but not AIA->OCSP. Comment #2 was written 2009-11-30 (nearly four years ago). At that time, the relevant CAs were: * Comodo * Network Solutions * GlobalSign * Trustwave Is this issue still relevant for any CAs now? Surely by now they are all including an OCSP AIA URL in all their EV end-entity and intermediate certificates. I did a little testing and my testing seems to support that conclusion. So, I think this argument is no longer valid. > 2. Nelson posted to mozilla.dev.security.policy 1.5 months ago: > "There are separate code paths in the browser (in PSM) for EV and for non-EV > certs. The non-EV code path is the old original code path. It uses an old > NSS API for cert path validation, one that is not able to do CDP support. > When the new PSM code was written for EV support, it was written to use the > new NSS API with CDP support, and the non-EV PSM code path was not changed. It doesn't make sense to special-case the four CAs above for this behavior, and there's no way we're going to expand the use of this mechanism beyond what it currently does. We're working on finalizing the plan for revocation checking in Firefox and this mechanism is never going to be part of that plan. > 3. Removing my code would cause a reduction in OCSP traffic and a > corresponding increase in CRL traffic. At the very least, I think the > affected CAs should be notified of this and have a chance to plan for it. This should be a non-issue now that all CAs have had years to put an OCSP AIA link in their certificates since 2009. > 4. If it ain't broke, don't fix it. ;-) In fact, we've received complaints about this behavior from one CA on the list. See bug 865440. So, at least one CA on the list doesn't even want to be on it anymore. > What "maintenance burden going forward" do you foresee? This feature complicates the replacement of the classic (some would say broken) certificate verification logic. Unless there are any new, surprisingly-compelling, arguments, this will be removed very soon.

(In reply to Brian Smith (:bsmith) from comment #9) Brian, IINM the issue discussed in comment #6 and comment #7... > for non-EV certs, OCSP fetches will cease, and revocation checking will > also effectively cease, unless and until PSM's non-EV code is modified to > use CERT_PKIXVerifyCert for non-EV certs, also. I perceive this is a net > reduction in user security. ...is the only reason that the Default OCSP Responders code wasn't removed back in 2009. Has this issue been resolved? Or is this issue no longer relevant in the context of your current plans for revocation checking?

(In reply to Rob Stradling from comment #10) > (In reply to Brian Smith (:bsmith) from comment #9) > > Brian, IINM the issue discussed in comment #6 and comment #7... > > > for non-EV certs, OCSP fetches will cease, and revocation checking will > > also effectively cease, unless and until PSM's non-EV code is modified to > > use CERT_PKIXVerifyCert for non-EV certs, also. I perceive this is a net > > reduction in user security. > > ...is the only reason that the Default OCSP Responders code wasn't removed > back in 2009. Has this issue been resolved? Or is this issue no longer > relevant in the context of your current plans for revocation checking? Our current code DOES do OCSP fetching for non-EV EE certs and EV EE certs already. I think it's almost definitely never going to be the case that Firefox requests CRLs for any reason. We managed to avoid it forever except for EV, and now thanks to the work of the CABForum in requiring OCSP AIA URIs in EV certs, we can even stop doing CRLs for EV. OCSP AIA URIs are mandatory now, according to CABForum guidelines. There should not be any CAs that rely on CRL support from browsers now. If there are, that is an issue that has to be dealt with in a way different than using this hack.

(In reply to Brian Smith (:briansmith), was bsmith@mozilla.com (:bsmith) from comment #11) <snip> > Our current code DOES do OCSP fetching for non-EV EE certs and EV EE certs > already. Great. In that case, I agree that the Default OCSP Responders hack should now be removed.