Re: Removing expired certificates from CRLs.....

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Tom,

I still believe that this discussion is more appropriate, at this time, to
X.509 currently rather than PKIX. So I have bindly copied the X.509
discussion list. Having said that, making sure that PKIX members agree with
the proposal cannot hurt.

> I would argue for SHOULD for that extension rather than MUST, but its
> presence can hardly hurt if it is non-critical.  

I believe that we basically agree. When this extension is present, then it
is non critical.

> BTW, I hadn't read your note when I composed mine.  
> Now, what is the proper syntax for this extension, which could be named 
> "RevokeRetention"?  Here are some possibilities:

> 1    Assume that all usage types have either no retention or the same one.
>   A simple syntax for this would be:
>      RevokeRetention ::= SEQUENCE  {
>           basicUsages    KeyUsage OPTIONAL,
>           extUsages      SEQUENCE OF OBJECT IDENTIFIER OPTIONAL,
>           incExpsAfter   GeneralizedTime
>      }

Since in practice, I would expect a policy where all certicates having DS or
NR set are kept one month longer, this seems sufficient.

> 2    Assume that usage types may have different non-null retentions.
    A slightly less simple syntax for  this would be:
>
>  RevokeRetention ::= SEQUENCE OF UsageRevokeRetention
>
>    UsageRevokeRetention ::= SEQUENCE   {
>      CHOICE {
>        basicUsage     INTEGER, 
                        -- 0-based bit offset from KeyUsage definition
>        extUsage       OBJECT IDENTIFIER,
>     }
>      incExpsAfter     GeneralizedTime
>    }

I would prefer:
 
        basicUsage     BIT STRING  rather than
        basicUsage     INTEGER


We could also have a simpler syntax:

RevokeRetention ::= SEQUENCE OF UsageRevokeRetention

    UsageRevokeRetention ::= SEQUENCE  {
        incExpsAfter     GeneralizedTime,
        basicUsage       BIT STRING                      OPTIONAL, 
        extUsages        SEQUENCE OF OBJECT IDENTIFIER   OPTIONAL
    }

If some dates are different but some dates are common to various types of
certificates, this can save some entries. 

> Naturally, any revocation matching a specified usage would be expected
> to be retained on the CRL if the certificate expiration time is after
> "incExpsAfter", but not otherwise.  Furthermore, do you think
> extendedKeyUsage should be omitted?

For completness, since X.509 is a framework, extendedKeyUsage should be
there. PKIX can then decide to keep it or leave it in its profile.

Now, suppose we do this, this is fine for CRLs. How should an OCSP server
behave whether or not expired certificates are kept longer than strictly
mandatory ? RFC 2560 is rather vague on that topic.

Denis


>           Tom Gindin