[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: delta CRLs - NR assumptions




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