At Tue, 25 Aug 2020 22:52:44 -0400, Bruce Momjian <br...@momjian.us> wrote in > On Wed, Aug 26, 2020 at 11:41:39AM +0900, Kyotaro Horiguchi wrote: > > At Tue, 25 Aug 2020 10:04:44 -0400, Bruce Momjian <br...@momjian.us> wrote > > in > > > I think there are a few problems here. In the docs, it says "will still > > > verify", but it doesn't say if it verifies the CA, or the CA _and_ the > > > CN/username. > > > > It verifies only CA. > > OK, that will need to be clarified. > > > > Second, since it is optional, what value does it have? > > > > > > > > Why is this useful? > > > > > > > > I agree, but there seems to be an implementation reason for the > > > > behavior. To identify an hba-line, some connection parameters like > > > > user name and others sent over a connection is required. Thus the > > > > clientcert option in the to-be-identified hba-line is unknown prior to > > > > the time SSL connection is made. So the documentation might need > > > > amendment. Roughly something like the following? > > > > > > Well, I realize internally we need a way to indicate clientcert is not > > > used, but why do we bother exposing that to the user as a named option? > > > > Because we think we need any named value for every alternatives > > including the default value? > > Well, not putting clientcert at all gives the default behavior, so why > have clientcert=no-verify?
clientcert=verify-ca or verify-full don't allow absence of client certificate. We need an option to allow the absence. > > > And you are right that the option name 'no-verify' is wrong since it > > > will verify the CA if it exists, so it more like 'optionally-verify', > > > which seems useless from a user interface perspective. > > > > > > I guess the behavior of no-verify matches our client-side > > > sslmode=prefer, but at least that has the value of using SSL if > > > available, which prevents user-visible network traffic, but doesn't > > > force it, but I am not sure what the value of optional certificate > > > verification is, since verification is all it does. I guess it should > > > be called "prefer-verify". > > > > The point of no-verify is to allow the absence of client > > certificate. It is similar to "prefer" in a sense that it allows the > > absence of availability of an SSL connection. (In a similar way to > > "prefer", we could "fall back" to "no client cert" SSL connection > > after verification failure but I think it's not worth doing.) > > Well, sslmode=prefer gives encryption without identification. > clientcert=no-verify has no value because it is just an optional CA > check that has no value because optional authentication is useless. It The point of the option is not to do optional CA check if possible, but to allow absence of client cert. We need to have that mode regardless of named or not named, and I believe we usually provide a name for default mode. > is like saying you can type in the password if you want, and we will > check it, or you can just not type in the password. Yes, since the point is the fact that I'm allowed to skip typing a password. And the reason for the strange-looking behavior is that I can't help entering a password if I had, but the server has no way other than checking the password that I provided. In the correct words, the server cannot ignore the certificate if client sent it. But the client cannot identify whether the certificate is needed by the server before sending it. > > "prefer-verify" seems right in that sense. But I'm not sure we may > > break backward compatibility for the reason. > > True, but right now it is inaccurate so I think it just need to be fixed > or removed and documented in the PG 14 release notes. I'm fine with that. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
