Subject: Re: delta CRLs - NR assumptions

From: "Tom Gindin" <[email-masked]>
Date: Wed, 20 Jun 2001 17:21:27 -0400

Denis:

     With respect to your second point, there is no requirement that
revoked certificates be removed from the CRL as quickly as possible after
they expire, especially for NR.  To quote from X.509v4 section 7.3, "It is
a matter for the security policy and responsibility of the authority to
keep old certificates for a period of time if a non repudiation of data
service is provided." (The same statement appears in X.509v3 section 11.2)
I think that it is appropriate for PKIX to specify a minimum time after
expiration before an NR certificate may be removed from a CRL, or to state
that a CA should publish such a minimum time.
     The question of the length of a grace period for compromise discovery
is a separate issue.  In the "espolicies" document you have the RP
(actually the Signature Validation Policy) specifying the length of the
grace period - but how does the CA know what the maximum grace period
allowed should be? The conformity of the two S/MIME documents with each
other and with your views reflects the fact that you are an author of both
of them, of course.

          Tom

Denis Pinkas <[email-masked]> on 06/20/2001 08:54:04 AM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   [email-masked]
Subject:  Re: delta CRLs - NR assumptions

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 <[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: Fri, 22 Jun 2001 18:33:12 +0200

Tom,

> service is provided." (The same statement appears in X.509v3 section 11.2)

The phrase you quote has no relationship with your argument just below:
keeping an old certificate is different from maintaining a certificate
number on a CRL.

> that a CA should publish such a minimum time.

I agree if this minimum is about a few days, even a week, otherwise CRLs
would grow. In most cases, people should get their new certificate about a
month in advance before the expiration of their current certificate and thus
use the new one instead of the old one. In this way the problem disappears.

> allowed should be? 

The caution period is part of the validation policy (not the grace period).

The caution period has to take into account the grace period, the time for
the CA to process revocation requests and the maximum time to make available
the revocation status; the two laters being defined by the policy of the CA.

Denis

> The conformity of the two S/MIME documents with each