RE: delta CRLs - NR assumptions

["Tom Gindin" <tgindin@xxxxxxxxxx>]

     The critical point here is actually that NR normally operates on
archived evidence, and revocation evidence will have been archived before
(usually long before) the independent third party starts work.  Current
evidence about whether a CA key has been compromised may be relevant in
some cases, and current evidence about whether a TSA key has been
compromised will be relevant in many cases, but not current evidence about
the signer's key.

          Tom Gindin


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


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


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.