PKIX over Secure HTTP (POSH)
Extracted elements (30)
POSH operations are ideally performed in parallel with DNS SRV resolution and address lookups, similar to the Happy Eyeballs approach for IPv4/IPv6, to avoid adding serial latency to connection establishment.
POSH was designed to address the multi-tenancy problem where hosting providers cannot obtain PKIX certificates identifying their customers' domains (CAs won't issue them; customers won't share private keys). By hosting certificate fingerprints at a well-known HTTPS URI on the customer's domain, POSH allows verification without private key transfer.
POSH was developed as an alternative to DNSSEC/DANE specifically because deployment of DNSSEC and DANE was expected to take years for many operators due to tooling and top-level domain delays, making a more immediately deployable HTTP-based solution desirable.
The reference document mechanism (returning a 'url' instead of fingerprints) reduces operational burden: the hosting provider does not need to re-provision each customer's domain with updated POSH documents every time the delegated domain's certificate expires or is replaced.
If POSH fingerprint verification fails (no match found), the POSH client MAY still accept the connection if another verification method succeeds, such as DANE (RFC 6698). POSH and DANE are complementary, not mutually exclusive.
The 'url' member name in reference documents is 'url' (not 'uri') for historical reasons. Implementations must not expect 'uri' as an alternative field name.
For POSH-using protocols that rely on DNS SRV records, the POSH service name SHOULD be the same as the DNS SRV 'Service' field (e.g., 'xmpp-server' for XMPP server-to-server connections).
If none of the fingerprint descriptor objects match the POSH server's PKIX information, the POSH client SHOULD reject the connection; however, the client might still accept the connection if other verification methods such as DANE succeed.
It is RECOMMENDED that POSH clients follow no more than 10 redirects when retrieving POSH documents from source domains, to protect against circular references.
POSH operations MUST be complete before any application-layer data is exchanged for the source domain. In cases where the POSH client initiates the connection, it SHOULD perform all POSH retrievals before initiating the connection.
POSH servers MUST use HTTPS. The POSH client MUST verify the certificate of the HTTPS service at the source domain in order to securely bootstrap into the use of POSH; specifically, the rules of RFC 2818 apply to this bootstrapping step.
The document retrieved from a reference document's 'url' MUST NOT itself be a reference document (i.e., must not contain a 'url' member instead of a 'fingerprints' member), in order to prevent circular delegations.
The 'expires' member in both fingerprints and reference documents MUST be a non-negative integer. If the 'expires' value is 0, the POSH client MUST consider the verification material (or delegation) to be invalid.
The fingerprints array SHOULD be ordered with the most relevant certificate first (e.g., the renewed certificate), followed by the next most relevant (e.g., soonest to expire), to guide clients during certificate rollover.
The fingerprints document returned by the source domain MUST NOT contain a 'url' member (that member is reserved for reference documents). The 'fingerprints' array MUST include at least one fingerprint descriptor.
The location provided in any redirect response to a POSH HTTPS request MUST specify an HTTPS URI. Source domains SHOULD use only temporary redirect mechanisms (HTTP 302 or 307).
The POSH client MUST NOT cache results indefinitely. When a reference is returned, the client MUST use the lower of the two 'expires' values (reference vs. fingerprints) when determining cache lifetime.
The POSH client MUST NOT consider an expired PKIX certificate to be valid, in accordance with RFC 5280, regardless of the 'expires' hints in POSH documents.
The POSH client SHOULD NOT rely on HTTP caching mechanisms; instead it SHOULD use the expiration hints provided in the POSH reference or fingerprints document. HTTPS servers SHOULD specify a very short Cache-Control header (e.g., max-age=60 or no-cache).
A POSH fingerprints document is a JSON object containing a 'fingerprints' member (JSON array of fingerprint descriptor objects) and an 'expires' member (JSON number, seconds). Each fingerprint descriptor maps hash function names (from IANA Hash Function Textual Names) to base64-encoded fingerprint values.
A POSH reference document is a JSON object containing a 'url' member (HTTPS URI where fingerprint information can be obtained) and an 'expires' member (seconds). It MUST NOT contain a 'fingerprints' member, and the resource at 'url' MUST be a fingerprints document.
POSH client retrieval begins with an HTTPS GET to '/.well-known/posh/{servicedesc}.json' at the source domain. The source domain responds with either a fingerprints document (200), a reference document (200 with 'url'), or HTTP 404 if no POSH information exists.
RFC 7711 establishes the 'POSH Service Names' registry under the 'Uniform Resource Identifier (URI) Schemes' group. Registration policy is Expert Review or IETF Review; requests go to [email protected]; review period is 14 days, with 21-day escalation to IESG.
RFC 7711 registers the 'posh' well-known URI suffix in the IANA 'Well-Known URIs' registry (RFC 5785). The suffix is expected to be followed by an additional path component of the form '{servicename}.json'.
Hash function agility is critical for POSH security. Because POSH verification material is relatively short-lived compared to long-lived PKIX certificates, operators are advised to swap out POSH documents promptly if hash functions are found subject to practical attacks (RFC 4270).
POSH does not enable a hosted domain to transfer private keys to a hosting service via HTTPS, nor does it enable certificate enrollment with a CA (as distinct from EST/RFC 7030). POSH only conveys public-key fingerprints for server identity verification.
The security of POSH depends on the POSH client correctly verifying the HTTPS server's identity at the source domain per RFC 2818 and following TLS best practices per RFC 7525. POSH can additionally benefit from HSTS (RFC 6797) and HTTP key pinning (RFC 7469) if the client shares a common HTTPS implementation.
POSH client state flow: (1) GET /.well-known/posh/{service}.json at source domain; (2) if 404 → no POSH; if 200 with 'url' → fetch fingerprints from delegated domain; if 200 with 'fingerprints' → proceed to verification; (3) compare each fingerprint descriptor against server cert; (4) match → accept; no match → SHOULD reject (unless DANE or other method succeeds).
Each fingerprint hash is computed by applying the named hash function over the DER encoding of the PKIX X.509 certificate, then base64-encoding the result per RFC 4648 Section 4 with padding bits set to zero. Member names are textual hash function names (e.g., 'sha-256', 'sha-512').
The well-known URI path pattern is '/.well-known/posh/{servicedesc}.json' where '{servicedesc}' is an application-specific service name registered in the POSH Service Names registry. An example full URI is 'https://bar.example.com/.well-known/posh/spice.json'.