Thanks for committing this!
At Thu, 18 Feb 2021 08:24:23 +0100, Peter Eisentraut
wrote in
> On 2021-02-17 05:05, Kyotaro Horiguchi wrote:
> > The commit fe61df7f82 shot down this.
> > This patch allows a new GUC ssl_crl_dir and a new libpq connection
> > option sslcrldir to specify CRL
On 2021-02-17 05:05, Kyotaro Horiguchi wrote:
The commit fe61df7f82 shot down this.
This patch allows a new GUC ssl_crl_dir and a new libpq connection
option sslcrldir to specify CRL directory, which stores multiple files
that contains one CRL. With that method server loads only CRLs for the
CA
The commit fe61df7f82 shot down this.
This patch allows a new GUC ssl_crl_dir and a new libpq connection
option sslcrldir to specify CRL directory, which stores multiple files
that contains one CRL. With that method server loads only CRLs for the
CA of the certificate being validated.
Along with
At Sat, 30 Jan 2021 22:20:19 +0100, Peter Eisentraut
wrote in
> On 2021-01-19 09:32, Kyotaro Horiguchi wrote:
> > At Tue, 19 Jan 2021 09:17:34 +0900 (JST), Kyotaro Horiguchi
> > wrote in
> >> By the way we can do the same thing on CA file/dir, but I personally
> >> think that the benefit from
On 2021-01-19 09:32, Kyotaro Horiguchi wrote:
At Tue, 19 Jan 2021 09:17:34 +0900 (JST), Kyotaro Horiguchi
wrote in
By the way we can do the same thing on CA file/dir, but I personally
think that the benefit from the specify-by-directory for CA files is
far less than CRL files. So I'm not
At Tue, 19 Jan 2021 09:17:34 +0900 (JST), Kyotaro Horiguchi
wrote in
> By the way we can do the same thing on CA file/dir, but I personally
> think that the benefit from the specify-by-directory for CA files is
> far less than CRL files. So I'm not going to do this for CA files for
> now.
This
On 2021-01-19 01:17, Kyotaro Horiguchi wrote:
Thank you for the information. The only reason for sharing the same
variable for both file and directory is to avoid additional variable
only for this reason. I'll post a new version where new GUC
ssl_crl_path is added.
Okay, I look forward to that
At Fri, 15 Jan 2021 08:56:27 +0100, Peter Eisentraut
wrote in
> On 2020-08-31 11:03, Kyotaro Horiguchi wrote:
> > At Tue, 18 Aug 2020 16:43:47 +0900 (JST), Kyotaro Horiguchi
> > wrote in
> >> Thank you very much. I'll do that after some polishing.
> >>
> >> A near-by discussion about
On 2020-08-31 11:03, Kyotaro Horiguchi wrote:
At Tue, 18 Aug 2020 16:43:47 +0900 (JST), Kyotaro Horiguchi
wrote in
Thank you very much. I'll do that after some polishing.
A near-by discussion about OpenSSL3.0 conflicts with this but it's
easy to follow.
Rebased. Fixed bogus tests and
On Mon, Aug 31, 2020 at 06:03:02PM +0900, Kyotaro Horiguchi wrote:
> Rebased. Fixed bogus tests and strange tentative API change of
> SSLServer.pm. Corrected a (maybe) spelling mistake. I'm going to
> register this to the coming CF.
Stephen, are you planning to look at that? I know that you
At Tue, 18 Aug 2020 16:43:47 +0900 (JST), Kyotaro Horiguchi
wrote in
> Thank you very much. I'll do that after some polishing.
>
> A near-by discussion about OpenSSL3.0 conflicts with this but it's
> easy to follow.
Rebased. Fixed bogus tests and strange tentative API change of
SSLServer.pm.
Hello.
At Sat, 15 Aug 2020 13:18:22 -0400, Stephen Frost wrote in
> > Looking closer I realized that certificates are verified in each
> > backend so CRL cache doesn't work at all for the hashed directory
> > method. Therefore, all CRL files relevant to a certificate to be
> > verfied are
Greetings,
* Kyotaro Horiguchi (horikyota@gmail.com) wrote:
> At Mon, 03 Aug 2020 16:20:40 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > Thanks for the opinion. I'll continue working on this.
>
> This is it, but..
Thanks!
> Looking closer I realized that certificates are verified in
At Mon, 03 Aug 2020 16:20:40 +0900 (JST), Kyotaro Horiguchi
wrote in
> Thanks for the opinion. I'll continue working on this.
This is it, but..
Looking closer I realized that certificates are verified in each
backend so CRL cache doesn't work at all for the hashed directory
method.
Uggg.
At Mon, 03 Aug 2020 16:19:37 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Fri, 31 Jul 2020 05:53:53 -0700, Henry B Hotz wrote in
> > A CA may issue a CRL infrequently, but issue a delta-CRL frequently. Does
> > the logic support this properly?
>
> If you are talking about regsitering
At Fri, 31 Jul 2020 09:00:14 -0400, Stephen Frost wrote in
> Greetings,
>
> * Kyotaro Horiguchi (horikyota@gmail.com) wrote:
> > PostgreSQL server accepts only one CRL file. It is easy to expand
> > be_tls_init to accept a directory set in ssl_crl_file. But I'm not
> > sure CRL is actually
At Fri, 31 Jul 2020 05:53:53 -0700, Henry B Hotz wrote in
> A CA may issue a CRL infrequently, but issue a delta-CRL frequently. Does the
> logic support this properly?
If you are talking about regsitering new revokations while server is
running, it checks newer CRLs upon each lookup according
Greetings,
* Kyotaro Horiguchi (horikyota@gmail.com) wrote:
> PostgreSQL server accepts only one CRL file. It is easy to expand
> be_tls_init to accept a directory set in ssl_crl_file. But I'm not
> sure CRL is actually even utilized in the field so that could ends
> with just bloating the
A CA may issue a CRL infrequently, but issue a delta-CRL frequently. Does the
logic support this properly?
Personal email. hbh...@oxy.edu
> On Jul 31, 2020, at 1:39 AM, Kyotaro Horiguchi
> wrote:
>
> Hello.
>
> PostgreSQL server accepts only one CRL file. It is easy to expand
> be_tls_init
Hello.
PostgreSQL server accepts only one CRL file. It is easy to expand
be_tls_init to accept a directory set in ssl_crl_file. But I'm not
sure CRL is actually even utilized in the field so that could ends
with just bloating the documentation.
Is it work doing?
regards.
--
Kyotaro Horiguchi
20 matches
Mail list logo
