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
