From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: PQgetssl() and alternative SSL implementations |
Date: | 2014-08-19 14:55:47 |
Message-ID: | 20140819145547.GB30525@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-08-19 10:48:41 -0400, Stephen Frost wrote:
> > Exposing the SSL information as generic key/value pairs allows
> > adding more attributes in the future, without breaking the ABI, and
> > it also allows exposing implementation-specific information in a
> > generic way. The attributes listed above cover the needs of psql.
> > What else do we need?
>
> At first blush, I'd say a whole bunch.. Off the top of my head I can
> think of:
>
> For all certificates:
> (client, server, cert that signed each, any intermediate CAs, root CAs)
> Certificate itself (perhaps in DER, PEM, X509 formats..)
> Fingerprint
> Signed-By info
> Common Name
> Organization (et al)
> Alternate names
> Issue date, expiration date
> CRL info, OCSP info
> Allowed usage (encryption, signing, etc)
>
> CRL checking done?
> OCSP used?
I'm not really sure we need all that. We're not building a general ssl
library abstraction here. Presenting all those in a common and useful
format isn't trivial.
What I'm wondering is whether we should differentiate 'standard'
attributes that we require from ones that a library can supply
optionally. If we don't we'll have difficulty enlarging the 'standard'
set over time.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2014-08-19 15:00:03 | Re: PQgetssl() and alternative SSL implementations |
Previous Message | Stephen Frost | 2014-08-19 14:48:41 | Re: PQgetssl() and alternative SSL implementations |