[Bug 29018] Allow interactive TLS certificate verification

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=29018

--- Comment #3 from Sjoerd Simons <sjoerd at luon.net> 2010-07-22 10:01:32 PDT ---
Had a nice chat with smcv about the interface. We agreed that while the model
is a bit odd (one channel that just points to another object), it makes sense
for the reasons we've discussed earlier.

* Authentication_TLS_Certificate should document which properties are immutable
(CertificateType ad CertificateChainData i assume)
* Channel_Type_Server_TLS_Connection should document this as well.

We were pondering if it would be useful to put the immutable properties of the
Autehntication_TLS_Certificate object in the ServerCertificate property on the
channel. But i think me and smcv agreed in the end that that might be a bit too
much data for a signal.

The biggest update is to change the Reject method call on TLSCertificate to
pass onwards some more information. Using
http://people.collabora.co.uk/~cosimoc/tls-connection-spec/Connection.html#org.freedesktop.Telepathy.Connection.ConnectionError
as an example (given that if we reject a certificate while connecting, it
should signal a ConnectionError with the reason).. Keep the enum though as
that's useful for clients that don't understand a dbus error.

So Reject would look like Reject (enum reason, DBus_Error_Name error, a{sv}:
Details). Do document which reasons map to specific DBus_Error_names by
default, like connection errors do.

We came up with to use-cases for some extra information (so well-known keys for
the details):
  - Give a hint whether or not the rejection was automatically done or at the
request of a user (in
    the latter case empathy should not show its awfullbar for example)
  - Give a bit more details when things went wrong, e.g. If there is a hostname
mismatch have a key with the (expected, received) hostname pairs

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.