[20405] in Kerberos_V5_Development
Re: Suggestion of change to certauth plugin interface
daemon@ATHENA.MIT.EDU (Ken Hornstein via krbdev)
Fri Feb 24 16:11:23 2023
Message-ID: <202302242109.31OL9Q83004635@hedwig.cmf.nrl.navy.mil>
To: Nico Williams <nico@cryptonector.com>
cc: krbdev@mit.edu
In-Reply-To: <Y/kRV0yia8itzZL3@gmail.com>
MIME-Version: 1.0
Date: Fri, 24 Feb 2023 16:09:26 -0500
From: Ken Hornstein via krbdev <krbdev@mit.edu>
Reply-To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
>> Sure. I talked before that one of my plugins was for doing OCSP
>> checking of client certificates for PKINIT. Well, it turns out that
>> to do that, you need to build up the complete certificate chain so you
>> can check the status of intermediate certificates. To do that, you
>> [...]
>
>Wait, why doesn't the KDC furnish the whole chain to the certauth
>plugin?
¯\_(ツ)_/¯
I imagine it probably should, but I have to live with the API as it
exists now. I suspect this wasn't thought about when the plugin API
was created, and that's fine; it's hard to imagine all of the things you
might want to do with a plugin when it is first created. Also, depending
on what kind of OCSP server you are talking to you probably need the
original list of CAs to verify the OCSP responder certificate.
I think my other points about the realm list being provided to the certauth
plugin initializer still stand.
--Ken
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
