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
Date: Wed, 12 May 2021 10:06:05 -0500
Message-ID: <20210512150605.GR27406@telsasoft.com> (raw)
In-Reply-To: <20210512024504.GH6088@momjian.us>
References: <20210510060308.GC6088@momjian.us>
<20210510140005.GB27406@telsasoft.com>
<20210511143523.GQ6088@momjian.us>
<20210511221321.GL27406@telsasoft.com>
<20210512024504.GH6088@momjian.us>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pryzby@telsasoft.com, bruce@momjian.us, andrew@dunslane.net
Subject: Re: PG 14 release notes, first draft
In-Reply-To: <20210512150605.GR27406@telsasoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox