The classic usage of TLS is done with X.509 certificates. The certificate is the end of a certificate chain. A certificate should be either signed by another certificate from a third party or a well known certification authority installed on the client machine. In an enterprise scenario all client would be signed by a certificate from the company making it possible for all clients to verify the identity of the other.

Getting a signed certificate is a complex and expensive task unsuitable for normal users. It also raises the question why a client should trust a CA its user does not know. Instead they create a self-signed certificate. The certificate is signed by itself and can not be verified through a certificate chain. To use these certificates in a real scenario the user must know the fingerprint of the peer certificate to verify it. But comparing fingerprints is not very userfriendly and the user may not have the fingerprint before starting the communication.

Instead of relying on a certificate chain the users may rely on a web-of-trust as defined by &rfc4880;. The TLS extension "OpenPGP Keys for Transport Layer Security" (&rfc5081;) describes how to use OpenPGP keys in the TLS handshake. If users share a trusted friend who has signed both their keys they can open a secure connection based on that trust. If there is no trust relationship between the two peers, OpenPGP is as useless as self-signed certificates. The users can verify the fingerprint and communicate that fingerprint over a different medium (e.g. a real-life meeting), but the same problem that occurs with X.509 certificates exists: comparing fingerprints is far away from being userfriendly.

A third way to verify the identify of the peer is a shared secret. This secret could be exchanged on a personal meeting or could be described as riddle only the other person can answer before opening the c2c link. It is up to the user and a good user interface to make the secret exchange as painless as possible.

This document uses the Secure Remote Password (SRP) extension from &rfc5054; when dealing with shared secrets and not the Pre-Shared Key Ciphersuites as defined in RFC4279. SRP allows the users to choose a much smaller password and it still verifies both clients to the other. The password (shared secret) is required by both to calculate the premaster secret which means both will notice if the peer is not who it should be. SRP requires a user name; since it is transmitted in plain text between client and server it has no value in this context. Both clients must use the same username for the calculations. For the TLS handshake using SRP both clients MUST use the bare JID of the initiator as username.

The main problem is what TLS extension to choose. It makes no sense to use OpenPGP if the clients have no trust-relationship or SRP if the users did not exchange a secret. To resolve this problem a client describes its extension in an offer to the peer. The offer lists all supported authentication methods including additional parameter like the certificate that will be used. &xep0189; can be used to look-up the keys or the client can look in its OpenPGP keyring. A client could also know a certificate or password from an earlier connection. The following example contains the X.509 certificate and the OpenPGP key from the examples in XEP-0189.

Note: the keyinfo only contains the name and not the public key itself. If the peer does not know the key, it can not determine if it is an X.509 certificate or OpenPGP key. This does not matter because if the client does not know the key, it can not use it for secure communication.

If both clients know the offer of the other, they can determine what method to use to complete the TLS handshake without an error. Note: this information will be exchanged over an insecure communication channel and may be forged. If the information is altered it will be detected when doing the TLS handshake.

I client MAY want to know the supported extensions of the peer before opening the client-to-client stream. For serverless messaging this is not possible but for server based communication a client can exchange offers with the peer without using Jingle to open a client-to-client stream. The methods the peer supports depend on additional information from the client. Depending on the X.509 certificate of the client the peer may not support this extension because it can not verify the certificate. To receive the offer from the peer the client sends an IQ stanza with its own offer.

The receiver sends its offer back to the client. It MUST only send the keyinfo elements that match a keyinfo of the offer. E.g. if the responder does not find an X.509 certificate it can verify in the offer it MUST NOT send its own X.509 certificate. In the following example the receiver supports SRP and X.509. OpenPGP is either not supported or skipped because the key can not be verified.

A client MAY support X.509 certificates it can not verify to be verified later. In that case it adds the authentication method <insecure>. In the following example the receiver supports SRP and X.509, but can not verify the certificate from the offer.

The offer information described above will be embedded into the XML based part of the STARTTLS handshake described in the XMPP core.