VESPER lookup privacy — what signing and verifying endpoints reveal
In SHAKEN, carriers sign and verify calls, and the lookups that involves leave from carrier infrastructure. VESPER puts the signing key with the Domain Operator, the entity that holds the right-to-use for its numbers, and makes verification possible in messaging, web and asynchronous contexts as well as SIP. Signing and verification can then run in an enterprise’s systems, an application or a device. Every lookup those parties make leaves from their own IP address, which tells the service at the other end where the caller or the called party is, and that a call or message happened.
What each lookup reveals
| Lookup | Made by | Who receives it | What it reveals |
|---|---|---|---|
| Publish a PASSporT to the PPS | the signer | the PASSporT Placement Service | the signer’s IP address, the calling and called numbers, and the time |
| Retrieve PASSporTs from the PPS | the verifier | the PASSporT Placement Service | the verifier’s IP address, the called number, and the time |
| Publish a response PASSporT (Connected Identity) | the called party | the PASSporT Placement Service | the called party’s IP address and that it answered |
| Find the PPS for a number | the verifier, or a monitor it asks | a transparency-log monitor, if the verifier does not monitor logs itself | the number being looked up, and the time |
Fetch the certificate by x5u |
the verifier | the signer’s own certificate repository | the verifier’s IP address and when it checked the call |
| Resolve the PPS or repository hostname | either side | a DNS resolver | which service the device is contacting |
The certificate fetch is specific to VESPER and the most direct of these. The repository is hosted under the signer’s own domain, so a verifier that fetches from it tells the caller’s organization the called party’s IP address and the moment the call or message was checked.
What VESPER and RFC 8816 already do
VESPER requires both x5c, carrying the certificate chain inline,
and x5u, naming the repository location. The verifier checks that
the x5u domain matches the certificate’s SubjectAltName without
fetching it. A verifier that follows that design makes no request to
the signer. One that dereferences x5u anyway creates the leak in the
table, and nothing in the profile tells it not to.
VESPER OOB follows RFC 8816 in defining publish, retrieve and respond as abstract operations and leaving the interface and its authorization undefined. RFC 8816 was designed with these exposures in mind. It encrypts each PASSporT to a key for the called number, so the placement service cannot read it. The service must answer every retrieval with at least one plausible encrypted response, so a query does not show whether a call exists, and a retriever may ask for ranges of numbers to hide which ones it controls. Senders are meant to connect anonymously, over a network that cannot be correlated with the token that authorized the storage. RFC 8816 names the caller’s IP address as a leak and suggests routing submissions through a third party. VESPER OOB does not yet say which of these a PPS must apply.
Discovery through transparency logs removes the per-call discovery query only for a party that monitors the logs itself. A device will usually ask a monitoring service, and that service learns the number.
The mechanisms
Oblivious HTTP (RFC 9458) is the standardized form of RFC 8816’s third-party routing. The client encrypts an HTTP request to the gateway’s public key with HPKE and sends it through a relay. The relay sees the client’s IP address and not the request; the gateway sees the request and not the IP address. The guarantee holds only if relay and gateway do not collude, and only if every client receives the same gateway key configuration. Each request stands alone, so a session or client certificate that links requests defeats it. It applies to PPS publish, retrieve and respond, to monitor queries, and to any certificate fetch.
Oblivious DoH (RFC 9230, Experimental) applies the same split to DNS: a proxy sees the device, a target resolver sees the name.
Privacy Pass (RFC 9576, 9577, 9578) fills the authorization VESPER OOB leaves undefined without identifying the requester. An issuer that knows a party is entitled, for example from its VESPER delegate certificate or its carrier account, hands it tokens; the PPS checks a token is valid but cannot link it to the issuance or to other requests. RFC 8816’s anonymous store with a token describes the same separation before Privacy Pass was standardized.
What is open
- Whether VESPER should tell verifiers not to dereference
x5uwhenx5cis present. - Which of RFC 8816’s protections a PPS must apply: encryption to the called party, plausible dummy responses, range queries.
- Whether PPS operations should be reachable over Oblivious HTTP, and who runs the relay. The guarantee depends on a relay that does not collude with the PPS; a carrier backing a consumer’s identity may not qualify.
- How a device finds its PPS without telling a monitoring service the number.
- What a PPS operator gives up. Traceback and abuse handling rely on knowing who published, and no VESPER document says what a PPS must log.