[glib/tls] update gio/TLS-NOTES.txt

[Dan Winship <danw src gnome org>]

commit 5d494f84564d63c7b7e9bba4ec06692125d43191
Author: Dan Winship <danw gnome org>
Date:   Thu Nov 11 18:50:03 2010 -0500

    update gio/TLS-NOTES.txt

 gio/TLS-NOTES.txt |  143 +++++++++++++++++++++++++++++++++++++++++++++-------
 1 files changed, 123 insertions(+), 20 deletions(-)
---
diff --git a/gio/TLS-NOTES.txt b/gio/TLS-NOTES.txt
index 9923c35..d2ef129 100644
--- a/gio/TLS-NOTES.txt
+++ b/gio/TLS-NOTES.txt
@@ -1,37 +1,140 @@
-CRLs?
-  - get/set on connection
+Need g_tls_backend_supports_tls() or something, so you can distinguish
+the dummy backend from real ones.
+
+
+CA handling
+  - add GTlsCertificateDatabase
+      - Default implementation for now uses system CA file
+      - NSS implementation would use secmod.db
+      - Eventually will use PKCS#11 APIs, gnome-keyring awesomeness
+
+  - Replace GTlsConnection:ca-list with GTlsConnection:certdb,
+    which defaults to g_tls_certificate_database_get_default()
+
+  - How does an app provide additional CAs to use in addition to the
+    defaults? You don't want to modify the DB returned by
+    g_tls_certificate_database_get_default(), because that would apply
+    to all TLS-using parts of the program (and maybe even other
+    programs), not just your connection.
+      - Create a new GTlsCertificateDatabase that "inherits" the
+        default but can then be modified?
+      - Have separate "system-certdb" and "application-certdb"
+        properties on GTlsConnection?
+      - Allow adding certs to the default certdb with
+        application-specific "allowed use" flags? (eg, "this cert can
+        be used for validating certificates for evolution-webcal, but
+        not anything else")
+
+  - How do servers make use of the certdb? Does their cert/key have to
+    be stored in the certdb? (This would be annoying but would make
+    the NSS backend simpler...)
+
+  - When connecting to a server, we have to (a) verify that the server
+    cert matches the hostname/service name, (b) verify expiration,
+    etc, (c) verify that the signing CA is allowed, (d) verify that
+    the cert isn't revoked, (d) check whether or not to accept the
+    certificate anyway if one of those fails, (e) possibly record the
+    accept-anyway status in the certdb. What part of that happens in
+    GTlsClientConnection and what happens in GTlsCertificateDatabase?
+
+      - At least part of this operation needs to be asynchronous.
+        However, it will be invoked from inside a callback from
+        gnutls/NSS, which has to block until it has an answer.
+        Possibly this means we have to always do handshakes from
+        another thread, so that thread can block?
+
+      - Is there any way to store cert override status when not using
+        the gnome-keyring backend? (Midori is probably going to want
+        this.) At the very least there could be signals and the app
+	could do it itself.
+
+      - Is there any UI helper anywhere for "accept this cert" dialogs
+        and/or "select client cert to use" dialogs?
+
+  - Likewise for GTlsServerConnection / GTlsCertificateDatabase, who
+    does what where?
+
+  - asking db for a private key may invoke password/pin callback,
+    which has the same async-vs-gnutls-callback issues as with
+    handshaking
+
+
+CRLs
+  - Apps should mostly not think about these explicitly, but they'd be
+    stored in the certdb, and maybe you can add additional ones if
+    necessary. (Is there really a use case for adding CRLs from an
+    application?)
 
-pkcs11? tokens, etc
-  - GTlsCertificateDatabase, g_tls_certificate_database_get_default()
-  - looking up a cert may invoke password callback
-    - automatically does looking in a thread so callback can block it?
-  - lookup by DN/nick?/other?
-  - get list of available certs
 
 sessions?
   - NSS handles this transparently on the client side; could make
     the gnutls backend do this too, via a global (mutexed) sessiondb
 
+
 misc options
   - ciphersuites
+      - for API simplicity, we should identify these via strings;
+        then when gnutls/NSS get support for new suites, we don't
+	need to add enum values to gio for them.
+  - ssl versions (rather than just everything vs ssl3-only)
   - compression options?
   - list/enable/disable TLS extensions?
+      - FIXME: we aren't currently using SNI in gnutls backend,
+        and the API may not currently allow using it usefully from
+	the server side.
+
+
+Non-X.509 auth types
+  - Eg, PSK, SRP, Anonymous DH, Kerberos
+
+  - GTlsConnection should make X.509 simple, and other types
+    possible.
+
+  - Need to be explicitly requested
+
+  - Add abstract GTlsCredentials, with subclasses for different types.
+    The application can examine/modify the creds object from the
+    (now-incorrectly-named) "accept-certificate" callback
+      - Eg, GTlsCredentialsPSK would have something like:
+            g_tls_credentials_psk_get_identity_hint (creds)
+	    g_tls_credentials_psk_set_identity (creds, id, key);
+      - GTlsCredentialsX509 would behave similarly
+        (g_tls_credentials_x509_get_peer_certificate()), but you
+        wouldn't have to manipulate it directly because you could just
+        use the GTlsConnection methods.
+      - (Anon DH would have NULL credentials)
+
+
+Support for channel bindings
+  - enum { G_TLS_CHANNEL_BINDING_TLS_UNIQUE,
+           G_TLS_CHANNEL_BINDING_TLS_SERVER_END_POINT,
+           G_TLS_CHANNEL_BINDING_TLS_UNIQUE_FOR_TELNET }
+  - before handshake:
+      g_tls_connection_set_channel_binding_type (conn, type);
+  - after handshake
+      bytearray = g_tls_connection_get_channel_binding_data (conn);
+
 
-stupid server SSL 3.0 fallback support
-  - via GSocketClient, or higher level?
-  - if this is really only a problem for HTTP then just punt to libsoup
+DTLS?
+  - Having TLS be based on GSocketesque/GPollableIOStream/GIOAdapter
+    rather than directly on GIOStream makes this more likely.
+  - GNUTLS doesn't currently support TLS anyway though
 
-XMPP forbids renegotiation
-  - could be handled by having an about-to-handshake signal, and
-    the handler could kill the connection from there
 
-need a FIPS140 violation error code
+GTlsCertificate attribute getters. What do people need? (Check empathy
+file sharing code, re: https://bugzilla.gnome.org/show_bug.cgi?id=507802)
 
-"handshaked" signal?
-  autohandshake in a thread so callback can block in signals?
 
-how will the dynamic types work with bindings?
+how will the dynamic types work with language bindings?
+  - we need non-varargs constructors instead of / in addition to the
+    g_object_new-like ones
 
-GTlsConnection:validation-errors
 
-g_socket_client_connect_to_uri(): does TLS? when?
+misc API issues:
+  - XMPP forbids renegotiation
+      - could be handled by having an about-to-handshake signal, and
+        the handler could kill the connection from there
+  - "handshaked" signal?
+  - need a FIPS140 violation error code
+  - GTlsConnection:validation-errors ?
+  - how does g_socket_client_connect_to_uri() know when to do TLS?