Subject: RFC 3280bis issue: guidance on handling circularity situations of revocation checking

From: "Wen-Cheng Wang" <[email-masked]>
Date: Wed, 5 Jul 2006 20:04:55 +0800

After participating the recent discussion about some circularity
situations of revocation checking and after reading Santosh's
presentation slides at 2006 NIST PKI research conference,
I would like to suggest that REC 3280bis should provide
guidance on handling circularity situations of revocation checking.

(Actually, I remember that the circularity issues has raised several
times since the inital call for issues for RFC 3280bis. However,
I do not think the current of RFC 3280bis address these issues
well.)

I think maybe REC 3280bis should add a section to compile
the guidance to CA implementators and relying parties on handling
different circularity situations of revocation checking. 

At least, the following circularity situations of revocation checking
should be addressed:

1. When the Root CA re-keys, RFC 3280bis currently suggest the
    Root CA should follow procedures for "CA key update"
    specified in RFC 4210. That is the Root CA should issued
    new-with-old self-issued certificate and old-with-new self-issued
    certificate. But, neither RFC 4210 nor RFC 3280bis provide
    guidance on how the revocation info of the new-with-old and
    old-with-new certificates should be provided to relying parties.

2. When an intermediate CA re-keys, the CA might request
    a new cross-certificate from its parent CAs or the CA might
    issue a key-rollover self-issued certificate. In either situations,
    is it mandatory for the CA to continue using the old key to issue
    CRLs for old certificate signed by the old key?

3. When a CA uses another key to sign CRLs, how the revocation info
    of the certificate of the CRL signing key should be provided to relying
    parties?

4. When a CA delegates its CRL signing responsibility to other CRL
    issuers, how the revocation info of the certificate of the delegated CRL
    issuers should be provided to relying parties?

5. When a CA provide OCSP service or delegate its responsibility of
    providing revocation info to a third-party OCSP server, how the
    revocation info of the OCSP responder certificate should be provided
    to relying parties?

Any other situations?

Regards,
Wen-Cheng Wang