Re: delta CRLs - NR assumptions

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Tom,

>      Denis:
> 
>      In NR, you can expect to have consistent results for time T from any
> CRL with thisUpdate >= T (exclusive of the effects of hold), 

Not really. For two reasons:

1) it may take time for a signer to discover that his key has been
   compromised.

2) in addition, if the certificate is close to expire, in case it is
   revoked, it will not appear in the CRL any more.

> but not from any CRL retrieved at time T.  

In practise, when you receive a signature, you want to have a reasonable
assurance that the signature is going to be valid. So you use the current
CRL, i.e. the one where time T is between thisUpdate and nextUpdate.

The next (normal) CRL is not necessarilly adequate either, since as said
above, it may take time for a signer to discover that his key has been
compromised. So why, in the document "Electronic Signature Formats for long
term electronic signatures" from the S/MIME working group, soon to be
published as RFC 3126, in section 2.8 a grace period is mentionned "allowing
any entity from the certification chain to declare a key compromise".

Along the same idea, a caution period is defined in the document "Electronic
Signature Policies" from the S/MIME working group, soon to be publised as
RFC 3125, in section B.8.3.:

Caution Period

   Before an electronic signature may really be valid, the verifier has
   to be sure that the holder of the private key was really the only one
   in possession of key at the time of signing.  However, there is an
   inevitable delay between a compromise or loss of key being noted, and
   a report of revocation being distributed.  To allow greater
   confidence in the validity of a signature, a "cautionary period" may
   be identified before a signature may be said to be valid with high
   confidence.  A verifier may revalidate a signature after this
   cautionary signature, or wait for this period before validating a
   signature.

> That's why section 4.6 of the techNR draft reads the way it does, as does section 5.5.  

This is why I disagree with the writing of these two sections.

Denis

> The security considerations
> section of new-part-1 should certainly warn even non-NR users that caching
> CRL's on a CA that issues emergency CRL's may cause them to get obsolescent
> revocation information.  However, given that the publication of CRL's is
> not truly instantaneous, even re-fetching them or using OCSP is not an
> absolute protection against that problem, although it reduces it greatly.
> 
>           Tom Gindin
> 
> Denis Pinkas <Denis.Pinkas@xxxxxxxx>@mail.imc.org on 06/18/2001 12:39:59 PM
> 
> Sent by:  owner-ietf-pkix@xxxxxxxxxxxx
> 
> To:   "Housley, Russ" <rhousley@xxxxxxxxxxxxxxx>
> cc:   ietf-pkix@xxxxxxx
> Subject:  Re: delta CRLs - NR assumptions
> 
> Russ,
> 
> > Denis:
> 
> > > > Consequences: "emergency" CRLs should be allowed
> 
> > >I disagree.
> 
> > I believe that this is the core of the disagreement, and I do not see
> > anyone changing their minds.  The PKIX Profile does not require CAs to
> > issue CRLs, or emergency CRLs.  However, when CAs choose to employ CRLs,
> > the CAs policy will dictate whether emergency CRLs are issued or not.
> 
> > The PKIX Profile is NOT going to be changed to prohibit the issuing of
> > emergency CRLs.
> 
> This seems fine as far as CAs are concerned: this leaves the choice to the
> CAs.
> 
> However, this has implications on the way relying parties should process
> CRLs.
> 
> It would be appropriate to give some guidance or some warnings
> in the security considerations section.
> 
> If a CA issues no emergency CRLs, then there is no problem. Only one CRL
> may
> be valid at one time.
> 
> If a CA indicates that it MAY issue emergency CRLs at any time (for some
> scope or reason), then a cache for that CRL should not be used. In this
> way,
> the client will always try to fetch the latest CRL, ... but will have no
> guarantee that he ever got the latest.
> 
> Finally, when CRLs are used for supporting non repudiation, since one goal
> of non repudiation is to solve disputes, we had better to have non
> conflicting information from the same authority while using the same
> revocation mechanism.
> 
> A few words in the security considerations section would certainly be
> appropriate. If you agree in principle, I would be happy to provide them.
> 
> Denis
> 
> > Russ