Keep membership and certificate checks separate
04An advertised origin is only a candidate. The connection must still be authoritative, including suitable TLS certificate validation for that origin.
The same membership and certificate gates remain. Consulting DNS MAY be skipped, but Section 4 adds risks even with a valid certificate. ORIGIN is not a promise that the server or its claims are harmless.
Source for this drawing: RFC 8336 · Read RFC section 2.4 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
An ORIGIN advertisement cannot make a bad certificate acceptable.
- Once initialized, an implementing client MUST NOT consider the connection authoritative for an origin absent from its Origin Set.
- Membership is necessary, not sufficient. The certificate MUST satisfy the checks a new TLS connection for the requested host would require, not just checks for the original host (current RFC 9113 §9.1.1).
- Clients SHOULD use an authoritative connection for requests to origins in its set unless operational reasons call for a new connection. This is not a universal MUST reuse rule.
- Clients MAY avoid consulting DNS for these authority decisions. Section 4 warns that an attacker holding a valid certificate can exploit this relaxation without being on the victim’s DNS path; additional confidence such as transparency or revocation evidence can help, not guarantee safety.
- Authority also governs which direct responses and server pushes can be considered authoritative. Server push offers a resource without a matching client request; an ORIGIN frame does not require a client to enable push.
No live DNS query, certificate validation or HTTP request is performed. Certificate Transparency and revocation checks are examples of additional confidence, not mandatory ORIGIN fields or complete defenses. Offline fictional examples only. The illustrations assume certificate-check results; they do not perform those checks. MUST, SHOULD and MAY retain their RFC meanings; SHOULD exceptions require carefully weighing the implications.
Read the RFC section ↗