Re: PQgetssl() and alternative SSL implementations
От | Andres Freund |
---|---|
Тема | Re: PQgetssl() and alternative SSL implementations |
Дата | |
Msg-id | 20140819145547.GB30525@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: PQgetssl() and alternative SSL implementations (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: PQgetssl() and alternative SSL implementations
|
Список | 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
В списке pgsql-hackers по дате отправления: