Using PKIX over Secure HTTP (POSH) as a Prooftype for XMPP Domain Name Associations

The specification defines a framework for secure delegation and strong domain name associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP). This document defines a DNA prooftype using PKIX certificates obtained over secure HTTP ("POSH"), as well as a secure delegation method, based on HTTPS redirects, that is appropriate for use with the POSH prooftype. The rationale for POSH is driven by current operational realities. It is effectively impossible for a hosting service to provide and maintain PKIX certificates that include the appropriate identifiers for each hosted domain. It is true that DNS-based technologies are emerging for secure delegation, in the form of DNS Security ( and ); however, these technologies are not yet widely deployed and might not be deployed in the near future for domains outside the most common top-level domains (e.g., ".COM", ".NET", ".EDU"). Because the XMPP community wishes to deploy secure delegation and strong domain name associations as widely and as quickly as possible, this document specifies how to use secure HTTP ( and ) and PKIX certificates to verify that a domain is delegated to a hosting provider and also establish a strong assocation between a domain name and an XML stream.

This document inherits XMPP terminology from and security terminology from . The terms "source domain", "derived domain", "reference identifier", and "presented identifier" are used as defined in the "CertID" specification . This document is applicable to connections made from an XMPP client to an XMPP server ("_xmpp-client._tcp") or between XMPP servers ("_xmpp-server._tcp"). In both cases, the XMPP initiating entity acts as a TLS client and the XMPP receiving entity acts as a TLS server. Therefore, to simplify discussion this document uses "_xmpp-client._tcp" to describe both cases, unless otherwise indicated. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

POSH stands for PKIX Over Secure HTTP: the server's proof consist of a PKIX certificate , the certificate is checked according to the rules from and , the client obtains its verification material by retrieving the certificate over HTTPS ( and ) from a well-known URI , and secure DNS is not necessary since the HTTPS retrieval mechanism relies on the chain of trust based on the public key infrastructure. The process for retrieving a PKIX certificate over secure HTTP is as follows. The initiating entity performs an HTTPS GET at the source domain to the path "/.well-known/posh._<service>._tcp.json"; where "_<service>" MUST be either "_xmpp-client" for XMPP client-to-server connections or "_xmpp-server" for XMPP server-to-server connections. Here is an example:

If the source domain HTTPS server has a certificate for the requested path, it MUST respond with a success status code, with the message body as a JSON Web Key Set (JWK Set) , which itself contains at least one JWK of type "PKIX" that the XMPP server at the source domain will present during the TLS negotiation phase of XMPP stream setup (linebreaks and whitespace added for readability). Here is an example:

When PKIX Over Secure HTTP (POSH) is the DNA prooftype, it is possible to use HTTPS redirects in determining if a domain is securely delegated, as follows: The initiating entity performs an HTTPS GET at the source domain to the path "/.well-known/posh._<service>._tcp.json"; where "_<service>" MUST be either "_xmpp-client" for XMPP client-to-server connections or "_xmpp-server" for XMPP server-to-server connections. Here is an example:

If the source domain HTTPS server has delegated to a derived domain, it MUST respond with one of the redirect mechanisms provided by HTTP (e.g., using the 302, 303, 307, or 308 response). The 'Location' header MUST specify an HTTPS URL, where the hostname and port is the derived domain HTTPS server, and the path MUST match the pattern "_<service>._tcp.json"; where "_<service>" MUST be identical to the "_<service>" portion of the original request (line breaks added for readability). Here is an example:

The initiating entity performs an HTTPS GET to the URL specified in the 'Location' header. Here is an example:

If the derived domain HTTPS server has a certificate, it MUST respond with a success status code, with the message body as a JSON Web Key Set (JWK Set) , which itself contains at least one JWK of type "PKIX" that the XMPP server at the derived domain will present during the TLS negotiation phase of XMPP stream setup. Here is an example:

Care needs to be taken with which redirect mechanism is used for delegation. Clients might remember the redirected location in place of the original, which can lead to verification mismatches when a source domain is migrated to a different delegated domain. To mitigate this concern, source domains SHOULD use only temporary redirect mechanisms, such as HTTP status codes 302 (Found) and 307 (Temporary Redirect). Clients MAY treat any redirect as temporary, ignoring the specific semantics for 301 (Moved Permanently) or 308 (Permanent Redirect) .

The processes for the POSH prooftype MUST be complete before the TLS handshake over the XMPP connection finishes, so that the client can perform verification of reference identities. Ideally a TLS client ought to perform the POSH processes in parallel with other XMPP session establishment processes; this is sometimes called the "happy eyeballs" approach, similar to for IPv4 and IPv6. However, a TLS client might delay as much of the XMPP session establishment as it needs to in order to gather all of the POSH-based verification material. For instance, a TLS client might not open the socket connection until it retrieves the PKIX certificates.

Ideally, the initiating entity relies on the expiration time of the certificate obtained via POSH, and not on HTTP caching mechanisms. To that end, the HTTPS servers for source and derived domains SHOULD specify a 'Cache-Control' header indicating a short duration (e.g., max-age=60) or "no-cache" to indicate the response (redirect or content) is not appropriate to cache at the HTTP level.

To indicate alternate PKIX certificates, such as when an existing certificate will soon expire, the returned JWK Set can contain multiple "PKIX" JWK objects. The JWK Set SHOULD be ordered with the most relevant certificate first as determined by the XMPP server operator (e.g., the certificate soonest to expire), followed by the next most relevant certificate (e.g., the renewed certificate). Here is an example:

This document supplements but does not supersede the security considerations provided in , , , and . Specifically, communication via HTTPS depends on checking the identity of the HTTP server in accordance with .

This specification registers the "posh._xmpp-client._tcp.json" well-known URI in the Well-Known URI Registry as defined by . URI suffix: posh._xmpp-client._tcp.json Change controller: IETF Specification document(s): [[ this document ]]

This specification registers the "posh._xmpp-server._tcp.json" well-known URI in the Well-Known URI Registry as defined by . URI suffix: posh._xmpp-server._tcp.json Change controller: IETF Specification document(s): [[ this document ]]