Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt

["Tom Gindin" <[e-mail]>]

     I'm not sure what protocol would typically be used to retrieve CRL's
for retrospective validation, if the reference time is more than a day or
two old.  If the reference time is far back, the old CRL's would probably
not be available from the HTTP or FTP locations in the distribution point
extensions - those would have been overwritten.  A local database in the CA
would be likelier to have this stuff - but that would return multiple
values for a query just as LDAP would.  In the TechNR draft, I suggested
that the responsible party (either the RP or the escrow holder) would
archive them himself and present them to the retrospective validator.
     In general, assuming single-valued attributes for delta CRL's would be
dangerous in retrospective validation, as can be seen in the following
example (ignoring time units other than days for simplicity):
a)   Suppose the base CRL has thisUpdate D and nextUpdate D+7.
b)   Suppose delta CRL's were produced on D+3, and D+5.
c)   Attempt to validate a transaction occurring on D+6.  The second delta
is needed.
d)   Attempt to validate a different transaction occurring on D+4.  The
first delta is needed.

     On your question about LDAP retrieval of CRL's by time range, there
was some discussion on this group last summer by Steven Legg (the thread is
"Matching Rules for Constructed Syntaxes"), with David Chadwick and I also
contributing, about how to search LDAP for ASN.1 subfields, which is
reflected in an Internet-Draft
draft-legg-ldapext-component-matching-02.txt.  Until this is actually part
of LDAP, you probably can't do it.  If it is adopted as part of LDAP,
someone needs to give samples for the filters people actually would want to
run - notably times in certificates and CRL's, and values of KeyUsage.

          Tom Gindin


"David P. Kemp" <[e-mail]>@mail.imc.org on 06/29/2001 02:44:53
PM

Sent by:  [e-mail]


To:   [e-mail]
cc:
Subject:  Re: I-D ACTION:draft-ietf-pkix-new-part1-07.txt



Tom Gindin wrote:
>
> [Tom] I'll leave SHOULD vs. MUST for Russ, although I don't understand
what
> would lead a retrospective verifier to use the second or third most
current
> delta CRL rather than the most current, if he recognizes them as such.
> Your last sentence is helpful, although I don't think that the measures
> which guarantee both deltas being seen are security measures.  The most
> common reason to only see one would be an LDAP client implementation
which
> only picked up one value of a multi-valued attribute.


Tom,

Wouldn't a retrospective verifier use a protocol other than LDAP to
retrieve
non-current CRLs?  I believe that searching the CDP attributes on an LDAP
server would always return a single CRL for the current wallclock time.
Could there conceivably be an LDAP mechanism to return all CRLs issued
between 10:00 June 3 2001 and 9:30 June 4 2001, or would such a retrieval
requirement be better satisfied using some other protocol (database search,
http query, ftp get by directory/filename, etc.)?

In other words, is there a downside to profiling as single-valued any
directory attributes that hold CRLs?

I agree with Denis that identifying the fact that an unscheduled CRL
is missing is a security consideration.  If the consideration rose to
the level of a security concern (which I doubt), it could be addressed
by sequential numbering or by a new CRL extension holding a backpointer
to the previously-issued CRL.

Dave