Primary Domain
Security
Within the Primary Domain facet, Security intelligence groups reporting by primary domain so readers can follow a focused area of internet infrastructure, governance, connectivity markets, or digital capital. The page brings together related articles, public evidence, institutions, companies, people, regional exposure, operating dependencies, and market context that may otherwise sit across separate category pages. It explains the domain, the likely actor class, the market or governance context, and the source material readers should use when comparing signals. Operators, analysts, and governance readers can see how the same domain appears across events, profiles, market shifts, public-source evidence, regional dependencies, and longer-cycle infrastructure decisions over time.
Story
The root KSK rollover makes resolver readiness the real continuity test
A DNS service can be healthy while users behind a stale validating resolver see failure. That is the operational paradox of a root key-signing-key rollover: the cryptography changes centrally, but continuity is decided across distributed resolver fleets.
Story
LACNIC’s reverse-DNS anycast turns registry continuity into a distributed control
Reverse DNS is easy to overlook until it stops answering. LACNIC’s use of anycast for delegated reverse zones shows why registry continuity is not a single-server property, but an operating discipline built from placement, routing, synchronization and observation.
Story
LACNIC’s measurement commons turns regional latency into operating evidence
A latency chart is not a verdict on a country’s Internet. It becomes useful when operators can see the probes, time window and comparison behind it—and when the result leads to a question that can be tested again.
Story
LACNIC’s RPKI controls make route origin authority operable
LACNIC’s RPKI controls make route origin authority operable intelligence summary explains the development, the public evidence available to readers, the organisations involved, the regional context, market exposure, and the infrastructure consequences that may follow. The Story…
Story
ARIN's SMS Country List Is Now an Attack-Cost Boundary
A request to make SMS authentication more convenient ended with a security-cost decision. ARIN says the limited numbers it supported outside its service region created a costly attack vector; the public record explains the boundary it chose, but not the attack it measured.
CASE FILE
The Certificate Challenge Crossed the Delay. Authority Did Not: RFC 9891
RFC 9891 carries an ACME proof through a delay-tolerant network, but it carefully stops the proof at control of a Node ID during one policy-bound exchange. Everything beyond that boundary still needs its own evidence.
Europe and Middle East National Telecom Trends
Sparkle, Hellas Sat test quantum-safe satellite link
Sparkle and Hellas Sat have extended Sparkle's QSI service from a terrestrial data-centre link to a GEO satellite connection between Greece and Cyprus.
IETF
Rich Salz and the TLS 1.3 Requirement That Was Not a Deployment Receipt
A standard can make a demanding rule without manufacturing the evidence that the rule has become true in every running system. That distinction is not a loophole; it is how an operator can tell a sound protocol decision from an unsupported deployment claim. Rich Salz’s…
IETF
Nancy Cam-Winget and the SCIM Event That Was Not a Reconciliation Receipt
An identity system can tell another domain that something changed and still leave the receiving domain with consequential work to do. It must decide whether the resource is the one it knows, whether the schemas align, whether a callback is needed, what local rule applies, and…
IETF
Chris Wendt and the Signed Response That Did Not Authenticate the Media
A telephone caller needs more than a signal that looks official. The practical question is whether the party reached is the intended party, what evidence supports that conclusion, and what a device should do when the evidence does not arrive. Chris Wendt’s co-authored RFC 9970…
IETF
Michael Prorock and the Algorithm Identifier That Did Not Choose a Trust Policy
An algorithm label can make two implementations speak precisely about the same kind of key. It cannot tell a verifier why that key arrived, who stands behind it, which claims it may support, or what action the verifier should take. RFC 9964, co-authored by Michael Prorock and…
CASE FILE
The Token Arrived Before the Call. Verification Still Had to Wait: RFC 9888
The signed identity token reached the destination service first. The telephone call was still crossing a path that could not carry that token with it. RFC 9888 makes this split useful for legacy networks, but it also leaves an operational obligation: two arrivals on two channels…
IETF
Dan Harkins and the Bootstrap Key That Could Not Supply Its Own Custody
A device can demonstrate control of a private key without answering the question that mattered before the handshake: who put the corresponding public key in the server’s hands, under what conditions, and with what right? RFC 9966 makes that boundary unusually plain. Its…
Asia-Pacific Institutional Trends
C-DOT unveils 14 quantum-security products
C-DOT has unveiled 14 QKD and post-quantum products for communications networks, moving its quantum-security work into named hardware and software systems.
CASE FILE
The Request Was Signed. The Other Private Key Was Still Only Asserted: RFC 9883
A certificate request can carry a valid signature and still offer no technical proof that the requester holds the private key named by its new public key. RFC 9883 does this deliberately. It turns the gap into an explicit policy choice—and a revocation dependency that operators…
CASE FILE
RFC 9882 Put SHA-512 in the Field. It Did Not Always Use It
A CMS record can truthfully name SHA-512 while that algorithm contributes nothing to the signature being checked. RFC 9882 requires exactly that combination on one of its two ML-DSA paths. The apparent contradiction disappears only when an auditor follows the bytes rather than…
CASE FILE
RFC 9879 Modernised the MAC. It Did Not Retire the Legacy Reader
Two applications can open the same PKCS #12 file and report success for different reasons. One may verify its new PBMAC1 envelope. Another may fail to understand that envelope, ignore the failed check and continue to the encrypted key material. RFC 9879 makes the first path…
CASE FILE
The Package Held Both Forms. They Were Not Yet One Key: RFC 9935
An ML-KEM key package can carry a compact seed and a full decapsulation key together. That convenience creates an import decision: until the recipient regenerates one from the other and compares them, a well-formed package has shown two values, not one coherent key.
CASE FILE
The OID Named the Key Package. It Did Not Authorize Its Use: RFC 9939
The package parsed cleanly and its CMS content-type OID was correct. That establishes a useful syntactic fact. It does not establish who controls the private key, whether it was recovered safely, or whether any later use is permitted.
CASE FILE
The Resource Named Its Authorization Server. It Did Not Grant a Right: RFC 9728’s Discovery Boundary
A resource can accurately publish where a client should look next and still have made no decision to let that client do anything. RFC 9728 gives protected resources a disciplined way to publish OAuth metadata. Its value is coordination: it narrows a discovery problem. It is not…