RE: CRL Checking Text

["Khaja E. Ahmed" <khajaa@xxxxxxxxxxxx>]

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


-----Original Message-----
From: Santosh Chokhani [mailto:chokhani@cygnacom.com]
Sent: Thursday, July 22, 1999 2:56 PM
To: 'Sean Turner'; PKIX
Subject: RE: CRL Checking Text


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