Summary

  • draft-ietf-stir-certificates-ocsp-14 adds TNQuery so an OCSP responder can say whether a certificate remains valid for the particular telephone number being checked.
  • A signed “good” response is certificate-scope evidence, not a verdict on the caller, the call’s purpose or the terminating network’s local decision.
  • Missing, stale or unavailable status must retain its real cause; flattening every uncertain result into “fraud” converts a security control into an unreviewable blocking system.

One number changes the meaning of “good”

Ordinary OCSP answers a certificate question with three familiar states: good, revoked or unknown. That vocabulary is too coarse for a STIR delegate certificate whose authority can cover a changing set of telephone numbers. A certificate may remain cryptographically valid while a particular number has left its authorized scope.

Revision 14 therefore places a TNQuery extension in the single certificate-status request. The queried value is normally the number in the PASSporT orig claim. When the responder returns the number in the signed response, the verifier learns a bounded fact: the certificate is still valid for that queried number at the response’s status boundary.

The boundary matters more than the reassuring word “good”. The response does not prove which person is speaking, whether a subscriber still controls a handset, whether a call is wanted, whether its pitch is honest, or whether a requested payment should be made. It does not even make the final call-treatment decision. RFC 8224 says that verification feeds an authorization process outside its scope.

If TNQuery is missing from a response to a request that carried it, the responder could not validate that the number remained in scope. The profile also requires clients to treat unknown as not good. Neither condition is a finding of malicious intent. One may reflect stale authority data, an unsupported path, an unavailable responder, a broken chain or an actual loss of authority. A system that records only “blocked” destroys the distinction.

The staple moves a receipt; it does not enlarge it

A live OCSP lookup adds a round trip to delay-sensitive call setup. The draft therefore defines stpl, a PASSporT claim that carries an OCSP response. The authentication service may fetch the staple for a particular call or receive pre-generated responses.

Stapling changes who transports the receipt and when it is fetched. It does not transform certificate status into caller reputation. A verifier still has to check the response signature, its time boundary, the queried number, the certificate path, delegated scope and the PASSporT. The terminating side then applies its own policy.

Scale creates another separation. A certificate covering a large range may need a pre-generated staple for each possible originating number. The inventory can therefore be incomplete even when every stored staple is correctly signed. Freshness, number coverage and distribution are operational facts distinct from cryptographic validity.

The same distinction applies to failure. If the OCSP service cannot be reached, or if a supplied staple is stale, the draft leaves treatment to the terminating domain. It may warn the callee, allow the call under degraded assurance, challenge it or block it. “The protocol blocked the call” would be false. Local policy did.

Privacy is part of the control surface

The query reveals more than a generic certificate identifier. It reveals the calling number and, to the responder, which verification service is handling that call. TLS can protect the exchange from passive observers, but the OCSP operator still receives the query. Stapling reduces that disclosure by allowing status to travel with the PASSporT.

That creates a real governance trade-off. Live queries may offer fresher answers but concentrate a call-observation stream at the status service. Pre-generated staples can reduce that visibility but create cache, coverage and expiry obligations. The correct design cannot be chosen by cryptography alone; it depends on the risk the terminating domain is authorized to accept.

Keep ten receipts, not one green light

A defensible implementation preserves the observed orig number; exact certificate and chain; TN authorization scope; request bytes; signed response and TNQuery; status times; live-query or staple path; verification result; policy version and reason; executed call treatment; and observed outcome.

Those records answer different questions. Combining them in one “verified caller” flag makes later review impossible. A complaint investigator needs to know whether the certificate was valid for the number, whether the signature checked, whether the status was fresh, which policy acted and what the network actually did.

Revision 14 was published on 10 June 2026 and has been approved by the IESG for the Standards Track, but it remains an Internet-Draft in the RFC Editor queue. That process state is evidence of advancement, not an RFC number, implementation claim or measured reduction in unwanted calls.

Sources