Re: [PATCH] Automatic client certificate selection support for libpq v1
От | Tom Lane |
---|---|
Тема | Re: [PATCH] Automatic client certificate selection support for libpq v1 |
Дата | |
Msg-id | 14727.1241816192@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCH] Automatic client certificate selection support for libpq v1 (Seth Robertson <in-pgsql-hackers@baka.org>) |
Ответы |
Re: [PATCH] Automatic client certificate selection support for libpq v1
|
Список | pgsql-hackers |
Seth Robertson <in-pgsql-hackers@baka.org> writes: > In message <12314.1241809436@sss.pgh.pa.us>, Tom Lane writes: > BTW, I was reminded today that Fedora/Red Hat are hoping to standardize > all crypto-related functionality in their entire distro on the NSS > libraries: > I am not perfectly up to speed, but switching to NSS would solve this > (automatic client certificate selection) problem in the crypto > library, since NSS supports a client certificate database and > furthermore has a default callback function NSS_GetClientAuthData > which searches the certificate database for a suitable match. Interesting. > It also > supports OCSP (online certificate status protocol) which is an online > certificate revocation check (better than the current TODO item of > "Allow SSL CRL files to be re-read during configuration file reload, > rather than requiring a server restart"). > Well, I guess that openssl supports OCSP as well, but the support does > not seem as complete (no AIA support--revocation URL embedded in the > certificate--that I can see). Well, one of the arguments the Fedora crowd is making for NSS is that it's more feature-complete than the other crypto libraries, so this doesn't surprise me much. > It is of course possible to support both at the same time (at > compile-time, if nowhere else). Yes, I suppose we'd not wish to just drop openssl completely. I wonder how much code duplication would ensue from a compile-time choice of which library to use ... regards, tom lane
В списке pgsql-hackers по дате отправления: