There are a couple of assumptions underlying some of Denis Pinkas's arguments that warrant closer examination. I have derived the assumptions from the clear & helpful description of Denis's rational (in an e-mail on 12 May). I think these assumptions are the root cause of much of the disagreement. I also believe these assumptions are incorrect.
Assumption 1 (A1): Two different verifiers must get the same result about a certificate's revocation state at any instant in time for a non-repudiation service to work, since the goal of NR is to resolve disputes.
A non-repudiation service works because an independent 3rd party can confirm that the evidence PRODUCED BY THE RELYING PARTY (signature, certificates, CRLs, timestamps) is correct. Whether or not there were different sets of evidence - perhaps giving a different answer - that the relying party could have collected (by noticing an "emergency" CRL for instance) is irrelevant. Only one set of evidence matters for a given NR dispute: that produced by the relying party.
The rule for deciding if NR evidence is "correct" is also very important, which bring us to the 2nd assumption.
Assumption 2 (A2): The validation rule, for a non-repudiation service, may say "use the freshest revocation information that is provided by the CA".
As Denis points out, the relying party cannot be sure they have the freshest information if "emergency" CRLs are allowed. The solution, however, is not to impose rules on CRL extensions & update times, but to recognize that A2 is a bad validation rule for a NR service.
A better validation rule for a NR service may be "the relying party must use revocation information that they reasonably assume to be the freshest information provided by the CA (delta CRLs do not need to be supported)". Now a relying party can protected themself, as the nextUpdate field indicates when it is reasonable to expect new revocation information to be available.
Consequences: "emergency" CRLs should be allowed (but NR validation rules should not require them to be noticed); thisUpdate values may be before the previous nextUpdate (but NR validation rules should not require that the new CRL is noticed until the old nextUpdate time); CRLs do not need to include a freshedCRL extension (but NR validation rules should not require a delta CRL to be noticed if neither the cert nor full CRL reference it). In short, keep the X.509 CRL rules, change the NR validation rules.
In practise, NR validation rules are unlikely to mention "freshest information" at all, as the period for which information is "freshest" is controlled by the CRL issuer, not the relying party or signer. Instead, a NR validation rule should specify how fresh the revocation information has to be (e.g. 12 hours). This value will often be a time in the future (e.g. the revocation information must be 24 hours fresher than the signature) to give the signer time to detect & report a compromise of their key (and the CA to publish it & relying parties to notice it) before they lose their right to repudiate a signature created with the compromised key.