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

["Tom Gindin" <tgindin@xxxxxxxxxx>]

     Denis:

     Given what the other proponents of a mechanism like this one are
suggesting, I think my second alternative will be considered
overcomplicated anyway.  They don't seem to want to enforce multiple dates
for retention.  The only reason for separate retention dates which I can
think of is to allow NR to have a multi-year retention while DS (say) has a
week or two, and if NR relying parties check for revocation information
periodically and stop after the date of the signature, they won't have a
problem.

          Tom Gindin

Denis Pinkas <Denis.Pinkas@xxxxxxxx> on 09/07/2001 08:32:14 AM

To:   Tom Gindin/Watson/IBM@xxxxx
cc:   IETF-PKIX <ietf-pkix@xxxxxxx>
Subject:  Re: Removing expired certificates from CRLs.....


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