Re: CRL Checking Text

[Sean Turner <turners@xxxxxxxx>]

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