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

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

Mike,

To understand the broad assumptions more clearly, can you clarify the
distinction you see between "periodic" information and "on-demand class
timeliness" information?

An RFC 2560 OCSP response contains a "producedAt" field.  Is there any
specific time beyond which a consumer should consider an OCSP response
produced at a certain time to be stale or potentially replayed?

1. If not, what prevents the consumer from relying on out-of-date
"on-demand class" information?  Why would that prevention mechanism
not be equally applicable to CRLs that were produced immediately upon
each update to the revocation database?

2. If there is a specific timeliness requirement, why would periodic
CRLs generated more frequently than the requirement not be considered
to have "on-demand class timeliness"?

In other words, there are three possible signing strategies:
timer based (periodic), revocation event based, and query based.
There are two response data structures: CRL and OCSP.
Each of the two data structures can be generated using each of
the three signing strategies.

If you have some particular system-level issues, they would seem
to be more related to the choice of signing strategy than
the choice of data structure.  For any meaning of "on-demand", and
for every choice of partition size (number of in-scope certificates
per response), a CRL can be as timely as, and is definitely much
smaller than, the equivalent OCSP request and response.  What issues
do you see that could not be solved most efficiently by using CRLs
in a manner different from the traditional infrequent-update,
big-partition mode?

Dave



Michael Myers wrote:
> 
> Denis,
> 
> Thank you for your consideration of historic aspect of digital signatures.
> I'm sure more work remains to be done in this area.  I for one however
> remain more concerned of our broad assumptions regarding the use of periodic
> CRLs as the basis for aperiodic OCSP-based services that deliver on-demand
> class timeliness.  Several systems-level issues are under-explored in this
> context.  Within closed environments there might exist data exchange
> mechanisms that are fully responsive to the security requirements CRLs
> satisfy but do so in a means that enables not only the timely inter-domain
> exchange of revocation status, but validation status as well.
> 
> Mike