Date: Wed, 12 May 2021 10:06:05 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: pgsql-hackers@postgresql.org, Andrew Dunstan <andrew@dunslane.net>
Subject: Re: PG 14 release notes, first draft
Message-ID: <20210512150605.GR27406@telsasoft.com>
References: <20210510060308.GC6088@momjian.us>
 <20210510140005.GB27406@telsasoft.com>
 <20210511143523.GQ6088@momjian.us>
 <20210511221321.GL27406@telsasoft.com>
 <20210512024504.GH6088@momjian.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210512024504.GH6088@momjian.us>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20210512150605.GR27406%40telsasoft.com>
Precedence: bulk

On Tue, May 11, 2021 at 10:45:04PM -0400, Bruce Momjian wrote:
> On Tue, May 11, 2021 at 05:13:21PM -0500, Justin Pryzby wrote:
> > On Tue, May 11, 2021 at 10:35:23AM -0400, Bruce Momjian wrote:
> > > > | Allow more than the common name (CN) to be matched for client certificate authentication (Andrew Dunstan) 
> > > > Your description makes it sound like arbitrary attributes can be compared.  But
> > > > the option just allows comparing CN or DN.
> > > 
> > > OK, new text is:
> > > 
> > > 	<para>
> > > 	Allow the certificate's distinguished name (DN) to be matched for client
> > > 	certificate authentication (Andrew Dunstan)
> > > 	</para>
> > > 	
> > > 	<para>
> > > 	The new pg_hba.conf keyword "clientname=DN" allows comparison with
> > > 	non-CN certificate attributes and can be combined with ident maps.
> > > 	</para>
> > > 	</listitem>
> > 
> > I think this part is still misleading.  The option just allows DN/CN, so it's
> > strange to say "non-CN attributes".
> 
> OK, so this is where I am confused.  I searched for distinguished name
> (DN) and came up with DN being a concatentation of all the fields
> provided to the certificate signing request (CSR).  Is that right? 
> Wouldn't people test _parts_ of the DN, rather than all of it.

+Andrew

The full DN is probably not the postgres username, so the docs suggest that:
| This option is probably best used in conjunction with a username map.

You're right that clientname=DN allows testing *parts*, of the DN, but I don't
know if there's any reason to believe that's the typical use case.

The primary utility of clientname=DN seems to be that the CN alone is (or can
be) ambiguous - matching on the full DN is intended to resolve that.  I think
the release notes should focus on this.

Matching parts of the DN (other than the CN) seems like a 2ndary use.

Maybe a variation on your original words is better.
| Allow the distinguished name (DN) to be matched for client certificate authentication (Andrew Dunstan) 
| Previously, matching was done only the common name (DN).
| With a username map, the DN can be matched in full or in part.

> The test in the patch seems to do that:
> 
> +     "# MAPNAME       SYSTEM-USERNAME                           PG-USERNAME\n",
> +     "dn             \"CN=ssltestuser-dn,OU=Testing,OU=Engineering,O=PGDG\"    ssltestuser\n",
> +     "dnre           \"/^.*OU=Testing,.*\$\"                    ssltestuser\n",
> +     "cn              ssltestuser-dn                            ssltestuser\n";
> 
> I think someone need to explain to me exactly what the DN is and how it
> is used.  Sorry.

-- 
Justin