Are you suggesting this because you personally make use of some server that uses OpenPGP TLS, or are you just suggesting it "because it's there"?

No browser or MUA supports it yet, so I don't use it in production but did some testing. My hope is that it can get into libsoup (and afterwards into WebKit) and evolution. Moreover, gvfs and could use it in combination with seahorse.

Right, so we're not really interested in writing OpenPGP TLS code ourselves if no one is actually using it in the real world, but we'd take (well-written) patches if you want to write it.

We had talked about APIs for non-X.509 TLS support at some point, but there doesn't seem to be a bug about it, so I'll just take over this bug...

The general idea is:

    - gio TLS remains biased towards X.509; GTlsCertificate continue
      to mean "an X.509 certificate", GTlsConnection only supports X.509
      by default (you need to call some method to enable other auth
      types), etc.

    - There would be an abstract GTlsCredentials type, with
      implementations for each supported auth type
      (GTlsCredentialsOpenPGP, GTlsCredentialsPSK, etc)

    - When using non-X.509 auth, the "certificate" argument of the
      "accept-certificate" callback would be %NULL, but you can call
      g_tls_connection_get_peer_credentials() to get a GTlsCredentials
      object. The credentials object would have authtype-specific
      methods. Eg:

        GTlsCertificateOpenPgp *g_tls_credentials_open_pgp_get_peer_certificate (GTlsCredentialsOpenPgp *creds);
        void                    g_tls_credentials_open_pgp_set_certificate      (GTlsCredentialsOpenPgp *creds,
                                                                                 GTlsCertificateOpenPgp *cert);

    - (There would also be a GTlsCredentialsX509, but you wouldn't
      normally need to use its methods, because accept-certificate already
      provides you with the GTlsCertificate object, etc.)

GnuTLS removed OpenPGP support and it seems that with TLS 1.3 only X.509 certificates and PSKs will be supported. So I think this bug can be closed.

I'm not fan of the proposed extra layer for credential. Unlike X.509, the PSK exchange is not symmetrical, client application provide username/key, and server application will provide the key base on the received username. Having an object to wrap half the information, sometimes seems counter intuitive. (Optionally, server may provide a hint, but this is not the username, so I would not consider this a symmetry).

So far, we have specific methods for certificate and password (used to unlock keyring). I think the logical thing to do is to add specific PSK methods too. Specially on the TlsInteraction side, this makes everything simpler.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/414.

Reopening. This bug was migrated to https://gitlab.gnome.org/GNOME/glib, but it should have been migrated to https://gitlab.gnome.org/GNOME/glib-networking.

No, it's a GLib issue, since the API in GLib is needed first.