libverto event context for certauth plugin?

[Ken Hornstein]

>Just to acknowledge: this seems like a valid use case(*), but it would
>require a significant restructuring of the PKINIT server code (which
>contains a lot of technical debt as it is), so I wouldn't expect it to
>happen soon.  Changing the certauth plugin API isn't a big problem; new
>methods could be added for async plugins.

Yeah, when I dug into this I got a sense of the scope of the problem.
Certainly this is NOT easy, and I just wanted to float it as a trial
balloon in case someone else came up with this as a requirement.

>For now, I'd suggest seeing if you can sync a copy of the cert deny list
>to each KDC, and check against it locally in the plugin module.

Well, we do that today with our existing PKINIT server side plugin that
I am trying desperately to kill, and it works fine ... with the caveat
that we talk to an OCSP responder running locally on the KDC (like I
explained in my previous message).  The problem is the total number of
CRL entries we have to deal with is more than 8 million, changes daily,
and most applications simply can't deal with that.  My reading of the
PKINIT code is that it loads all of the CRLs into memory at startup and
doesn't reload them if they change (but I fully admit that I could
be reading that wrong, since it involves a lot of OpenSSL code).

>(*) With the caveat that online OCSP checking hasn't been successful in
>the context browsers, because of the added latency and the bad user
>experience if the browser fails closed.  And there isn't much security
>value if you fail open, because an attacker could potentially deny
>access to the OCSP server.  In the context of PKINIT and a
>within-the-enterprise OCSP server, online checking might make more sense.

It's not that I disagree with you here and we don't typically enable
OCSP checking on clients, but it is a requirement that we do client
certificate revocation checking on our servers and I can't really
ignore that.  We have a custom OCSP server that can handle 8 million
CRL entries without a problem (it stores them in a Berkeley DB and can
handle updates and adding/removing CAs without issues), and from from
my perspective it makes sense to make the interface for CRL checking
via OCSP since that seems to be where the world is going and the OCSP
protocol is already handled well by OpenSSL and we can re-use our OCSP
server code with applications like Apache.

Anyway, I understand where you are coming from and I knew this was going
to be a heavy lift; I don't need it in the short term since having a
co-located OCSP server on the KDC has been working fine, but if you ever
get around to adding async support the PKINIT plugin I'll definitely
make use of it.

--Ken