BUG #5895: Ability to match more than just CN in client certificate
The following bug has been logged online:
Bug reference: 5895
Logged by: Christopher Head
Email address: chris2k01@hotmail.com
PostgreSQL version: 9.0.3
Operating system: Linux amd64
Description: Ability to match more than just CN in client certificate
Details:
This is a feature request/wishlist, not a bug. Right now, when using client
certificates over SSL for authentication, the username map maps from the
Subject Common Name field in the certificate to a username in the database.
It would be nice if matches could be done on a few other fields in the
certificate. For example, my name is not particularly unusual, so it's
reasonable that someone else in the world might (and probably does) have the
same name. That doesn't mean I want to give that person access to my
database, even if they also get a certificate from e.g. cacert.org!
A few fields to match on that would pretty much instantly close this hole
would be e-mail address and certificate serial number. While the e-mail
address suggestion could be generalized to match an arbitrary subset of the
subject's distinguished name fields (e.g. write something like
/O=FooOrg/CN=Christopher Head/ to require that both fields must be present
with the specified values), matching certificate serial number would be
slightly different as the serial number is not part of the distinguished
name. It would probably be the most secure field to match on, however, as no
CA will ever issue two certificates with the same serial number. E-mail
address would be a close second as an address can only be held by one
person, though it relies on the CA being able to verify the legitimate owner
of the address.
On Sun, Feb 20, 2011 at 5:30 PM, Christopher Head <chris2k01@hotmail.com> wrote:
The following bug has been logged online:
Bug reference: 5895
Logged by: Christopher Head
Email address: chris2k01@hotmail.com
PostgreSQL version: 9.0.3
Operating system: Linux amd64
Description: Ability to match more than just CN in client certificate
Details:This is a feature request/wishlist, not a bug. Right now, when using client
certificates over SSL for authentication, the username map maps from the
Subject Common Name field in the certificate to a username in the database.
It would be nice if matches could be done on a few other fields in the
certificate. For example, my name is not particularly unusual, so it's
reasonable that someone else in the world might (and probably does) have the
same name. That doesn't mean I want to give that person access to my
database, even if they also get a certificate from e.g. cacert.org!A few fields to match on that would pretty much instantly close this hole
would be e-mail address and certificate serial number. While the e-mail
address suggestion could be generalized to match an arbitrary subset of the
subject's distinguished name fields (e.g. write something like
/O=FooOrg/CN=Christopher Head/ to require that both fields must be present
with the specified values), matching certificate serial number would be
slightly different as the serial number is not part of the distinguished
name. It would probably be the most secure field to match on, however, as no
CA will ever issue two certificates with the same serial number. E-mail
address would be a close second as an address can only be held by one
person, though it relies on the CA being able to verify the legitimate owner
of the address.
It seems like there are a lot of possible combinations here that could
be useful, so we'd want something that allowed a fairly flexible
specification of what to match.
Is this a problem you're interested in working on (i.e. contributing code)?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, 3 Mar 2011 10:20:06 -0500
Robert Haas <robertmhaas@gmail.com> wrote:
[snip]
It seems like there are a lot of possible combinations here that could
be useful, so we'd want something that allowed a fairly flexible
specification of what to match.Is this a problem you're interested in working on (i.e. contributing
code)?
I agree, it seems like something along the lines of a full
distinguished name with the option to leave out fields would make the
most sense, plus some way of specifying other fields not in the formal
DN (serial #, fingerprint, or so). Thinking about it, serial number is
not necessarily ideal either, since one could reasonably want to trust
more than one CA. I feel like I'm pretty much saying I want to specify
a single certificate, in which case the full PKI is really kind of
pointless, but X.509 certificates are for better or worse the only sane
way of doing non-password-based authentication over TLS right now, so
that's what we've got to work with.
As for contributing code, not right now, but sometime in the near
future (next handful of months) I might be interested in hacking at
this.
Chris