MIME-Version: 1.0
From: olivier cano <kindermoumoute@gmail.com>
Date: Fri, 27 Mar 2026 14:20:40 +0100
Message-ID: 
 <CAPGgoKq0t9p4O5eQfdwV1Jnv=0bpw4KsJ6_U98CAGbGr-Ero+Q@mail.gmail.com>
Subject: Proposal: Supporting URI SAN in Certificate Authentication
To: pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000c8aab4064e015e2f"
Archived-At: 
 <https://www.postgresql.org/message-id/CAPGgoKq0t9p4O5eQfdwV1Jnv%3D0bpw4KsJ6_U98CAGbGr-Ero%2BQ%40mail.gmail.com>
Precedence: bulk

--000000000000c8aab4064e015e2f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello PostgreSQL Hackers,

I=E2=80=99d like to open the discussion about adding support for URI Subjec=
t
Alternative Names (URI SAN) in PostgreSQL certificate authentication.
Today, PostgreSQL only supports extracting identity from the certificate
Subject (CN or full DN). This limits interoperability with modern workload
identity systems that rely on URI-based identities:
* Cockroach Labs added URI SAN support for SPIFFE/SPIRE:
https://www.cockroachlabs.com/blog/zero-trust-database-authentication-spiff=
e-spire
* The IETF WIMSE Working Group is standardizing URI-based workload
identities: https://datatracker.ietf.org/group/wimse/about

Proposal: Allow certificate authentication to use URI SAN entries as the
client identity (e.g. via a clientname=3Duri option in pg_hba.conf), in
addition to the existing CN/DN options.

Questions:
* Is there interest in this feature from the community?
* Are there known objections or prior discussions around using SAN (and
specifically URI SAN) for identity in PostgreSQL auth?
* How should multiple URI SAN entries be handled (first match, require
uniqueness, mapping rules, etc.)?

Thanks,
Olivier Cano

--000000000000c8aab4064e015e2f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello PostgreSQL Hackers,</div><div><br></div>I=E2=80=
=99d like to open the discussion about adding support for URI Subject Alter=
native Names (URI SAN) in PostgreSQL certificate authentication. Today, Pos=
tgreSQL only supports extracting identity from the certificate Subject (CN =
or full DN). This limits interoperability with modern workload identity sys=
tems that rely on URI-based identities:<br>* Cockroach Labs added URI SAN s=
upport for SPIFFE/SPIRE: <a href=3D"https://www.cockroachlabs.com/blog/zero=
-trust-database-authentication-spiffe-spire">https://www.cockroachlabs.com/=
blog/zero-trust-database-authentication-spiffe-spire</a><br>* The IETF WIMS=
E Working Group is standardizing URI-based workload identities: <a href=3D"=
https://datatracker.ietf.org/group/wimse/about">https://datatracker.ietf.or=
g/group/wimse/about</a><br><br>Proposal: Allow certificate authentication t=
o use URI SAN entries as the client identity (e.g. via a clientname=3Duri o=
ption in pg_hba.conf), in addition to the existing CN/DN options.<br><br>Qu=
estions:<br>* Is there interest in this feature from the community?<br>* Ar=
e there known objections or prior discussions around using SAN (and specifi=
cally URI SAN) for identity in PostgreSQL auth?<br>* How should multiple UR=
I SAN entries be handled (first match, require uniqueness, mapping rules, e=
tc.)?<br><br>Thanks,<br>Olivier Cano<br><br></div>

--000000000000c8aab4064e015e2f--