Re: delta CRLs - NR assumptions

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

This a response to James Manger, rather than Tom, since I missed the e-mail
from James.

> "Manger, James H" <James.H.Manger@xxxxxxxxxxxxxxxx>@mail.imc.org on
> 06/06/2001 01:37:13 AM
> 
> Sent by:  owner-ietf-pkix@xxxxxxxxxxxx
> 
> To:   ietf-pkix@xxxxxxx
> cc:
> Subject:  RE: delta CRLs - NR assumptions
> 
> 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.

What about when they are two differents sets of evidence from the same
relying party which are both valid (according to the way to use CRLs) but
are contradictory ?
 
> [Tom Gindin] A third party may be used as the archiver of such evidence, by
> prior agreement.  This does not affect your argument, since the independent
> third party is operating on an archived set of evidence.
> 
> 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.

You are right, this is not stated correctly. The rule may be: "use
delta-CRLs (with full CRLs)". 

> 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)".

I see a problem here. If you use delta-CRls, full CRL only or OCSP (from the
same CA) you do not necessarily get the same result. For a given signature
policy, allowing only one means to obtain the revocation status would allow
to make sure that everydody gets the same information.

> 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 

I disagree.

> (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, 

Correct.

> 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.

In other words, it will be necessary to wait to make sure that a report of
key compromise can be done. 

Denis