[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: delta CRLs - NR assumptions
Tom,
> 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)
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.
> 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.
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.
> 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 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
> other and with your views reflects the fact that you are an author of both
> of them, of course.
>
> Tom
>
> Denis Pinkas <Denis.Pinkas@xxxxxxxx> on 06/20/2001 08:54:04 AM
>
> To: Tom Gindin/Watson/IBM@xxxxx
> cc: ietf-pkix@xxxxxxx
> 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 <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