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.
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…
CASE FILE
The Authorization Conversation Was Still Pending. It Was Not an API Right: GNAP’s Continuation Boundary
A client can be entitled to continue an authorization conversation without being entitled to call the API it asked about. RFC 9635 makes the distinction unusually explicit: a continuation credential advances one grant request at the authorization server; a resource right appears…
IETF
Sean Turner and the Private-Key Proof That Did Not Authorize a Certificate
A certification request can carry a valid signature and still have no right to become the certificate it asks for. The signature answers a narrow question about a key; identity, namespace entitlement, intermediary action and issuance remain separate decisions.
IETF
Panos Kampanakis and the SSH Session with Three Different Security Receipts
An SSH client can negotiate a hybrid ML-KEM key exchange, verify the server through a conventional host key, and admit a user through a still separate credential. The session is one connection; the evidence is not one claim.
IETF
Bas Westerbaan and the Hybrid TLS Handshake That Did Not Make the Certificate Post-Quantum
A browser can report `X25519MLKEM768`, derive a session secret from classical and post-quantum components, and still authenticate the server with a classical certificate signature. Both observations can be true in the same TLS 1.3 connection. Calling the whole service…
IETF
Daniel Fett and the QR Context That MFA Never Authenticated
The password was right, the second factor was real and the authorization server behaved as designed. The attacker still received the session, because the ceremony proved who the user was without proving whose request the user had approved.