RE: CRL Checking Text

[Santosh Chokhani <chokhani@xxxxxxxxxxxx>]

I think either there should be a reference or the text should be taken
from X.509 and revised for pkix as applicable.  I will be glad to take
the lead on revising it.

> -----Original Message-----
> From:	Sean Turner [SMTP:turners@ieca.com]
> Sent:	Thursday, July 22, 1999 6:11 PM
> To:	Santosh Chokhani
> Cc:	PKIX
> Subject:	Re: CRL Checking Text
> 
> Santosh,
> 
> Is the plan then to put a reference in the update to RFC2459 to point
> to
> Annex M of X.509 for CRL checking?
> 
> spt
> 
> Santosh Chokhani wrote:
> 
> > We have done detailed work on this topic and Annex M of the latest
> X.509
> > FPDAM has the pertinent language/rules.  I think PKIX should start
> with
> > Annex M and revise it if and only if necessary.
> >
> > > -----Original Message-----
> > > From: Sean Turner [SMTP:turners@ieca.com]
> > > Sent: Thursday, July 22, 1999 5:45 PM
> > > To:   PKIX
> > > Subject:      CRL Checking Text
> > >
> > > All,
> > >
> > > I asked a few weeks ago where the explicit requirements were to
> > > check/verify CRLs in RFC 2459.  The is some text in section 6.1
> that
> > > says:
> > >
> > >          Verify ... the certificate had not been revoked at time T
> and
> > > is not
> > >          currently on hold status that commenced before time T,
> (this
> > >          may be determined by obtaining the appropriate CRL or
> status
> > >          information, or by out-of-band mechanisms),
> > >
> > > I think we need a little more information that explicitly states
> what
> > > the verification steps are for CRLs.  Attached is some suggested
> text:
> > >
> > > Prior to trusting an issuer’s CRL, the signature across the CRL
> must
> > > itself be validated.  When required to validate a CRL during
> > > certificate
> > > path verification, CRL verification requires the following checks:
> > >
> > > 1. Verify the signature on the CRL, distribution point CRL, or
> delta
> > > CRL
> > > by employing the public key from the CRL issuer’s certificate. If
> the
> > > signature across the CRL is invalid, the user shall be notified
> that
> > > the
> > > signature was invalid and instructed to obtain a new CRL from the
> > > repository. If a valid CRL cannot be obtained, then the user will
> be
> > > given the option to proceed without a valid CRL and without using
> the
> > > invalid CRL.
> > >
> > > 2. Verify the certification path (see clause 6 of RFC2459) of the
> CRL
> > > issuer’s signature certificate.
> > >
> > > 3. Verify that the present time, T, falls between thisUpdate and
> > > nextUpdate.  If time T is later than the nextUpdate value, the
> user
> > > shall receive guidance to obtain a later CRL from the repository,
> and
> > > be
> > > given the option to proceed with the out-of-date CRL (signature
> must
> > > still be checked).
> > >
> > > 4. Verify that the cRLNumber is greater than that of the last CRL
> that
> > > the user possesses.
> > >
> > > 5. Verify that the name in the CRL's issuer field or the
> > > certificateIssuer extension is the issuer of the certificate.
> > >
> > > 6. If the keyUsage extension is present in the CRL issuer’s
> > > certificate
> > > and is flagged critical, verify that the cRLSign bit is set to 1.
> > >
> > > 7. Check whether the certificate’s serialNumber appears on the
> CRL,
> > > distribution point CRL, or delta CRL.  If the certificate's serial
> > > number is present, and if no reasonCode exists, or a reasonCode
> exists
> > > and is either unspecified, affiliationChanged, superseded, or
> > > cessationOfOperation, notify the user of which certificate is on
> the
> > > CRL, distribution point CRL, or delta CRL and allow the option to
> > > proceed with data processing.  If the reasonCode is keyCompromise
> or
> > > certificateHold, the user shall be notified and the certificate
> shall
> > > be
> > > rejected thereby halting all associated processing.  If a
> certificate
> > > that appears on the CRL, distribution point CRL, or delta CRL is a
> CA
> > > certificate, regardless of the reasonCode, the user shall be
> notified
> > > and the certificate shall be rejected thereby halting all
> associated
> > > processing.  If the revoked certificate is the user’s certificate,
> the
> > > user will be directed to notify the associated CA.
> > >
> > > The notification returned to the user at the end of the CRL check
> > > shall
> > > at a minimum shall:
> > >
> > > - List all expired certificates in the certificate chain.
> > >
> > > - Explicitly state that the certificate(s) is/are expired.
> > >
> > > - Explicitly state that the certificate(s) may have been revoked,
> and
> > > that the certificate will not appear on current CRLs even if the
> > > certificate has been revoked.
> > >
> > > - Explicitly state that the signature applied to the entity being
> > > verified may not be valid. Verification of signatures using
> expired
> > > certificates requires the assistance of the originator’s CA.
> > >
> > > - Require positive user action to acknowledge the warning message
> > > (i.e.
> > > clicking an on-screen OK button) before data processing
> > > continues.
> > >
> > > Thoughts?  Too restrictive or not enough info?
> > >
> > > spt