Subject: RE: CRL Checking Text

From: Santosh Chokhani <[email-masked]>
Date: Thu, 22 Jul 1999 17:56:04 -0400

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:[email-masked]]
> 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

---

From: Sean Turner <[email-masked]>
Date: Thu, 22 Jul 1999 18:10:31 -0400

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

---

From: "Khaja E. Ahmed" <[email-masked]>
Date: Thu, 22 Jul 1999 16:55:15 -0700

Santosh,

The only X.509 recommendation I am able to find on the ITU web site is the
08/97 version which does not have Annex M.  Can you send the Annex or the
pointer to this group so we can review it.  Thanks.

Khaja