Subject: Re: delta CRLs - NR assumptions

From: "Tom Gindin" <[email-masked]>
Date: Tue, 19 Jun 2001 13:39:06 -0400

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), but not from
any CRL retrieved at time T.  That's why section 4.6 of the techNR draft
reads the way it does, as does section 5.5.  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 <[email-masked]>@mail.imc.org on 06/18/2001 12:39:59 PM

Sent by:  [email-masked]

To:   "Housley, Russ" <[email-masked]>
cc:   [email-masked]
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

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 20 Jun 2001 14:54:04 +0200

Tom,

> 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

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 20 Jun 2001 17:43:15 +0200

Denis Pinkas wrote:
> Tom Gindin wrote :

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

This is the signer's problem if he did not report the compromise in time.

Just as it is today if your credit card is stolen.

From the time, the information is published, it becomes the verifier's problem if he did not
take it into account.

I think Tom's assertion makes lot of sense.

>    revoked, it will not appear in the CRL any more.

This simply means that for NR, a certificate will be unusable not from the expiration date,
but from the thisUpdate of the last CRL issued before the expiration date.

In real life, the user will have a new certificate issued at least a few days before the
revocation date, there will be a short time overlap between the two certificates, and he
will switch to the new certificate before the actual revocation.

It's not convenient for him to wait the very last second or even very last day to renew his
certificate.

Therefore this is not a real problem.