* Heikki Linnakangas (hlinnakan...@vmware.com) wrote: > On 08/19/2014 06:44 PM, Stephen Frost wrote: > >>>Hmm. That seems a bit too much. Perhaps provide just the certificate > >>>itself in DER/PEM format, and have the client parse it (using > >>>OpenSSL or something else) if it wants more details. > >I really don't care for that approach. Our SSL support has always been > >horrible- I was hoping we'd actually improve that situation. Adding > >things in piecemeal over time will just be painful for our users and I > >don't see why we should wait. > > What would you like to do with the certificates?
In applications which I've developed in the past, I've had to rely on the CN, serial number, and signing root CA to ensure that there were no duplicates (this was a government environment which trusted multiple independent root CAs, and there was no guarantee that even a given CA wouldn't issue the same serial number to different individuals). In other cases, I've had to rely on the fingerprint, but that gets painful when you have certificate roll-over since you then have to re-enroll individuals when they get issued a new certificate. I've also implemented systems which have certificate expiration warnings. Checking the extended attributes of the certificate has been a requirement in the past (to verify it's only being used for its intended purpose). One of the things we don't support today is anything beyond matching on the CN of the certificate in pg_ident, to map from a client certificate to a PG role. That wouldn't be acceptable in environments I've worked in because two different individuals could have identical CNs. Another interesting twist are systems (such as Windows..) where the client certificate to be presented depends on which root CA the server's certificate is signed with. I'm not asking this patch to fix that, but you asked what else a developer might be looking for when it comes to SSL and I'm telling you things I've actively used. Generally speaking, these have been on the server side (eg: with mod_ssl), but I could see a client wanting to use them, and if we abstract getting this information on the server side to meet the needs I've described above, wouldn't we be able to (and want to) share that abstraction with users of libpq? > I'm imagining that a GUI tool like pgAdmin might want to extract all > information from the certificate, display it in a window, and let > the user look at the whole chain and all the fields. While that'd certainly be nice, it's not what I'm referring to and I agree that having a third party library to handle that makes sense, as some operating systems do. In general, I'm all for more (and better) integration with the OS-provided certificate systems. For one thing, they also can address the issues around ensuring that the client side certificate is encrypted-at-rest, and can handle prompting the user for the passphrase to decrypt it. > But I don't think that exists in OpenSSL, let alone > in other libraries, and the attribute names would be all different > anyway. As I said- let's look at mod_ssl/gnutls as a minimum set to start with.. That's certainly a set I'm familiar with and one which I expect most other developers who work with SSL are also. There are bits missing from that list (mainly around the extended attributes..), but it's certainly better than the list originally proposed. > But if we provide an interface to grab the whole certificate chain, > then you can use any library you want to parse and present it to the > user. Yes- we should do this also because there may be cases where the app developers wants to pass that off to another library or do something else with it, sure. Thanks, Stephen
Description: Digital signature