Re: libverto event context for certauth plugin?

On Tue, Sep 22, 2020 at 07:49:05PM -0400, Ken Hornstein wrote:
> >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.

FWIW I think that OpenSSL 3.0 will make it a bit easier, with the "read
stuff from disk" having been genericized/modularized and letting you "drop
in" alternative implementations via "provider" modules, but of course
OpenSSL 3.0 is not done yet...

-Ben
_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev