[20170] in Kerberos_V5_Development
Re: libverto event context for certauth plugin?
daemon@ATHENA.MIT.EDU (Ken Hornstein)
Tue Sep 22 23:44:19 2020
Message-ID: <202009230107.08N16746020482@hedwig.cmf.nrl.navy.mil>
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: Benjamin Kaduk <kaduk@mit.edu>
In-Reply-To: <20200923000019.GT89563@kduck.mit.edu>
MIME-Version: 1.0
Date: Tue, 22 Sep 2020 21:05:57 -0400
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
>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...
I'm not quite understanding how this would help; are you saying that
you would suggest the "read stuff from disk" routines be abstracted
to query servers via OCSP? If so, I don't see how that helps things
with lack of a libverto context in certauth, because if that OCSP
query blocks your whole KDC blocks.
If you're suggesting abstracting out the "read from disk" routines to
read my internal database I use to store CRLs ... ugh. Two things:
I really do not want to depend long-term on this database format,
and my reading of the current code is that it really wants to slurp
everything into memory and search it that way. I am not sure changing
out the "read from disk" code helps in that case. It may very well be
that they changed enough other things that you could substitute a function
that does something smart with regards to CRL querying, but again,
depending on an internal database format is NOT something I want to
do long-term.
This is all probably moot for now, since running a local OCSP server
works perfectly fine today and that's the approach I'll take going forwards.
--Ken
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
