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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
