It's possible to verify the certificate against more than one expected peername. For this we add the immutable ReferenceIdentities property, which is an array of strings. These identities must be specified by the user. Obviously the results of DNS resolution (such as SRV DNS resolution in XMPP) should never be put into the ReferenceIdentities property. It's conceivable and possible for a telepathy account to have more than one expected TLS certificate identity. An example of this is with XMPP, when a server is manually specified. I will be filing other tickets for implementing this in gabble, and using the property in empathy. I'll be documenting use cases there. The ReferenceIdentities property always contains at least the value of the Hostname property. The Hostname property stays, and is the source domain that the user expects to be connecting to. This is used when displaying messages to the user, looking up and storing trust assertions. For example it makes sense to store a pinned certificate exception associated with the Hostname (and not ReferenceIdentities). Will attach patches that add ReferenceIdentities to ServerTLSConnection
telepathy-spec changes on my git.collabora.co.uk reference-identities branch: http://git.collabora.co.uk/?p=user/stefw/telepathy-spec.git;a=commit;h=19d4def6459766b82277eab506b5fb770d912c57
Matching telepathy-glib changes on my git.collabora.co.uk reference-identities branch: http://git.collabora.co.uk/?p=user/stefw/telepathy-glib.git;a=commit;h=35f4d52fc3941c83191d334d2d0c0716e21d2bc5
Comments from sjoerd: <sjoerd> stefw: for your spec patch, please document that if ReferenceIdentities doesn't excist the UI should use Hostname instead <stefw> good, will do. <sjoerd> tp:name-for-bindings should be Ugly_Case so Reference_Identities in your case did the spec compilation not warn about that ? the may in the Clients may display should probably be a MAY Made the above changes in reference-identities branch.
Merged into master by sjoerd.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.