RE: OCSP and LDAP

["Ambarish Malpani" <ambarish@xxxxxxxxxxx>]

Hi Peter,
    One of the things that I didn't mention in my original mail,
but that I think I had said on this list before, is that we do
allow our VA to use its own data to indicate that a certificate
is revoked/suspended if the VA knows that a certificate has
been revoked/suspended, but the CA has not had a chance to indicate
that.

3 other issues:
    a. When people try to keep their CAs offline, they not only
want keep the CAs signing key offline, but also its database. Having
the responder access the CAs database means that some of the CAs
data now needs to be online.

    b. If you want to locate VAs at multiple remote locations and
you have the VA access the CAs database, it needs to access that
database from remote locations.

    c. Most CA operators are prefectly happy to combine the
capablity above (of temporary suspension at the VA) and the fact
that a VA can accept a CRL issued at any time, to deal with the
issue of needing to revoke/suspend a cert while a CA is offline.

Hope this helps,
Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      ambarish@xxxxxxxxxxx
http://www.malpani.biz



> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Peter Gutmann
> Sent: Sunday, January 05, 2003 12:20 AM
> To: ambarish@xxxxxxxxxxx; ietf-pkix@xxxxxxx; madwolf@xxxxxxxxxxxxxxx;
> pgut001@xxxxxxxxxxxxxxxxx
> Subject: RE: OCSP and LDAP
>
>
>
> "Ambarish Malpani" <ambarish@xxxxxxxxxxx> writes:
>
> >I have still to see a place where using CRLs as the mechanism
> for letting a
> >VA know of changes in the revocation data has led to poorer
> performance than
> >having the VA access the CA's database directly.
>
> Most of the CAs I know of issues CRLs a few times a day, some as
> infrequently
> as once a day.  If I'm doing processing with any kind of value
> attached to the
> transaction, I want to know whether the cert is valid right now,
> not whether
> it was OK last night when the CRL was issued (substitute "credit card" for
> "cert" to see why this is important).  I have never seen a
> situation where an
> offline CRL gives better performance than a real-time check of a live
> database, unless you happen to catch it just as the CRL is being
> issued, which
> (for a 24-hour CRL time) only works about once in 86,400 times.
>
> I think one of the reasons why there aren't more complaints about CRLs is
> because so many apps only pay lip service to revocation checking, so it
> doesn't really matter if it doesn't work proprely ("We go through
> the motions
> because the CA policy requires it"/"It's turned off by default, but we can
> claim it's there"/"We realise the CRL is almost always out of
> date, but our
> accounting processes should catch any problems"/etc are all excuses I've
> heard).  If you build a system where you can tell users that
> there's a simple
> online check which guarantees that at the time the check was done
> the cert was
> valid (rather than being valid a couple of hours ago) following the credit
> card model that businesses are used to, perhaps people would lend
> more weight
> to the value of checking.  Actually, as mentioned in my previous message,
> implementors are already doing this, and have been doing it for some time,
> because people care about real-time cert status information, it's just not
> standardised in any spec (yet :-) so you get a pile of proprietary ways of
> doing it.
>
> Peter.
>