Обсуждение: 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> w= rote: > > The following bug has been logged online: > > Bug reference: =A0 =A0 =A05895 > Logged by: =A0 =A0 =A0 =A0 =A0Christopher Head > Email address: =A0 =A0 =A0chris2k01@hotmail.com > PostgreSQL version: 9.0.3 > Operating system: =A0 Linux amd64 > Description: =A0 =A0 =A0 =A0Ability to match more than just CN in client = certificate > Details: > > This is a feature request/wishlist, not a bug. Right now, when using clie= nt > certificates over SSL for authentication, the username map maps from the > Subject Common Name field in the certificate to a username in the databas= e. > 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 t= he > subject's distinguished name fields (e.g. write something like > /O=3DFooOrg/CN=3DChristopher Head/ to require that both fields must be pr= esent > 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 ow= ner > 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)? --=20 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