RE: Removing expired certificates from CRLs.....

[Ambarish Malpani <ambarish@xxxxxxxxxxxx>]

Hi Denis, Tom,
    What I would recommend we add to CRLs, is something similar
(or the same) as the ArchiveCutoff extension in OCSP. If a CA
added that to a CRL, it would be easy for a responder to add it
in responses.

It is unclear to me that there is a huge benefit to CAs to go
through the trouble of retaining only signing certs in the CRL
and not the others.

Regards,
Ambarish


Denis, since you are bcc-ing the X.509 group, could you please
also forward this message to that list?

Thanks,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  ambarish@xxxxxxxxxxxx
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> Sent: Friday, September 07, 2001 5:32 AM
> To: Tom Gindin
> Cc: IETF-PKIX
> 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
>