CRL Checking Text

[Sean Turner <turners@xxxxxxxx>]

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