Wishlist: TLS, PKI

A quick search of the source code and archives failed to show 
anything related to this (which may reflect my searching skills 
more than anything else), so I'll toss it out here as a wishlist
item.  

Wishlist: TLS (SSL) authentication
----------------------------------

While superficially similar to SSL, the emphasis here is
on mutual strong authentication via digital certificates,
not an encrypted data channel.

SERVER AUTHENTICATION

The database server requires an X.509 certificate and private
key before it will accept TLS/SSL connections, and it can provide
this cert to the client.  If the certificate does not match a 
previously published one or is not verifiable via external means
then the connection can be refused.  This prevents a server from 
being "hijacked" - the connection may be forwarded, but the 
certs won't match.

This functionality can be largely duplicated with careful
configuration of an SSL tunnel with port forwarding, but 
OpenSSL tunnels require that the user has a "shell account"
(even if the "shell" is /bin/yes) on the database server.
This approach does not require user "shell accounts."

If "anonymous DH" session keys are supported, this functionality
makes the database server "ssl-aware" much like HTTPS servers.
(In fact, the implementation will almost certainly start with
"anonymous DH" and add client authentication later.)

CLIENT AUTHENTICATION

The clients require an X.509 certificate before it will accept
TLS connections, and this can be used as strong authentication
of the client.  ("something they have" - an X.509 certificate,
and "something they know" - the password to the private key for
that certificate.)  This can be tied into the PostgreSQL 
authentication mechanism in the usual way.

The client certs can be issued by the server (if it acts as a
certificate authority for this purpose), or issued elsewhere and
stored in the server.  With PKI, the certs could also be checked
against external certificate stores.  You *don't* want to simply
check the "distinguished name" on the certificate since it's
trivial to create a fradulent self-signed certificate.

Long term: X.509 certificates can be stored on "smart cards,"
USB fobs, or the like.  Clients could be written that only 
successfully connect when the user has attached such a device 
to the system, providing strong evidence (with a USB keychain
fob, at least) that the individual is actually present.

This functionality cannot be duplicated with OpenSSL tunnels.

PUBLIC KEY INFRASTRUCTURE (PKI) RESOURCES

Hinted at above are extensions to the server itself to support
PKI.  This can be supported in phases:
1) new data types to store PKI information.
2) self-hosting certificate authority (CA) functionality, allowing   the database to maintain its own server and client
certificates.  (no need to bother with external CAs - most users just needto run a program like pg_keygen and it will
handleeverything.)
 
3) public certificate store functionality, for storage and retrievalof certificates used by other applications.

------------------------------------------------------------

As a practical matter, the lion's share of the work to implement
this is in moving the network code from sockets to SSL.  Once
that's been done it's straightforward to request the client
certificate and tie it into the authentication code.

However, I have finished[*] TOASTable user-defined types for 
various PKI items:  X509, X509_REQ, X509_CRL, PKCS7, PKCS8, SPKAC,
plus some utility classes.  I've also written all of the useful 
user-defined accessor functions, e.g., x509_subject(x509).  I'm
willing to contribute this code to the PostgreSQL contrib (or
main ADT) section.

[*] I lie.  The implementation with the old interface was
finished, the port to TOASTable 7.1.3 should be finished by 
this weekend.  But I wanted to get this message out now since
many people will be distracted next week. :-)

---
Bear Giles
bgiles (at) coyotesong (dot) com