Re: Suggestion of change to certauth plugin interface

>It would probably be great to share that functionality between certauth
>and pkinit plugins. PKINIT code already has it, if we could have turned
>that into a common library that could be used by certauth plugins, it
>would probably helped everyone to keep the configuration and behavior
>the same way between authentication and authorization parts...

I mean ... yes?  But this would require some extremely careful thinking
about the exact contours of the plugin API, and it gets complicated
when you start thinking about the details (and it's hard to imagine
every use case).  E.g., I asked previously about the possibility of
passing down the libverto context into certauth and Greg basically
said, "Whelp, it's super complicated" (no argument there!).  In every
KDC plugin I've written I basically have to re-implement the details of
the configuration parsing code, for starters.  In the specific case of
certauth, it is difficult to design a plugin interface that covers all
of the cases without having an OpenSSL dependency (I suppose you could
pass in an array of the encodings of all certificates in the chain, and
maybe that would get you a lot of what I need ... but maybe not, because
you then have to think about how you verify an OCSP response).  But
given the choice between a slightly imperfect plugin API or patching the
KDC code, I'll choose the plugin interface every time.  It's about 100x
worse if you have to patch the PKINIT plugin (which I am desperately
trying to get away from).

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