Domínio principal
Segurança
Na faceta Domínio principal, Segurança grupos de inteligência são organizados por domínio principal para que os leitores possam acompanhar uma área de foco em infraestrutura da internet, governança, mercados de conectividade ou capital digital. A página reúne artigos relacionados, evidências públicas, instituições, empresas, pessoas, exposição regional, dependências operacionais e contexto de mercado que, de outra forma, poderiam estar espalhados por páginas de categorias separadas. Ela explica o domínio, a provável classe de atores, o contexto de mercado ou de governança e o material de origem que os leitores devem usar ao comparar sinais. Operadores, analistas e leitores de governança podem ver como o mesmo domínio aparece em eventos, perfis, mudanças de mercado, evidências de fontes públicas, dependências regionais e decisões de infraestrutura de ciclos mais longos ao longo do tempo.
Reportagens
A troca da KSK raiz faz da prontidão dos resolvedores o teste real de continuidade
O DNS pode estar saudável enquanto usuários atrás de um resolvedor validador desatualizado veem falhas. Esse é o paradoxo operacional da troca da KSK raiz: a chave muda no centro, mas a continuidade é decidida por frotas distribuídas de resolvedores.
Reportagens
O anycast de DNS reverso da LACNIC transforma continuidade em controle distribuído
O DNS reverso quase não aparece até deixar de responder. A arquitetura anycast da LACNIC mostra que a continuidade de um registro depende de localização, roteamento, sincronização e observação, não de um servidor isolado.
Reportagens
As medições do LACNIC transformam latência regional em evidência operacional
Um gráfico de latência não encerra um diagnóstico sobre a Internet de um país. Ele ganha valor quando sondas, período e comparação estão visíveis e a observação pode ser repetida.
Reportagens
Os controles RPKI do LACNIC tornam operacional a autoridade de origem
RPKI não torna o BGP seguro apenas por existir uma declaração assinada. Ele oferece evidência criptográfica sobre qual sistema autônomo pode originar um prefixo; cabe aos operadores manter essa autorização coerente com o roteamento real e decidir como a validação afetará suas…
Reportagens
A lista de países do SMS da ARIN virou uma fronteira de custo
Uma proposta para ampliar o SMS acabou respondida como questão de segurança. A ARIN diz que os poucos números de fora de sua região já atendidos criaram um vetor de ataque oneroso. A restrição está documentada; o ataque, o volume e a conta permanecem fora do registro público.
Arquivo de Caso
O desafio atravessou a demora; a autoridade, não: RFC 9891
A RFC 9891 leva uma prova ACME até uma rede tolerante a atrasos. O resultado confirma um controle momentâneo segundo regras definidas, sem transformar essa resposta em propriedade do nome, autorização de rota ou prova de implantação.
Tendências de Telecomunicações nacionais da Europa e Oriente Médio
Sparkle e Hellas Sat testam segurança resistente à computação quântica via satélite
Sparkle e Hellas Sat ampliaram o serviço QSI da Sparkle de um enlace terrestre entre data centers para uma conexão de satélite GEO entre Grécia e Chipre.
IETF
Rich Salz e a exigência de TLS 1.3 que não era um comprovante de implantação
Um padrão pode estabelecer uma regra forte sem produzir, por si só, a prova de que ela se tornou verdadeira em todos os sistemas em execução. Essa distinção não reduz o padrão; ela impede que uma decisão correta de protocolo seja apresentada como uma implantação já observada. O…
IETF
Nancy Cam-Winget e o evento SCIM que não era um recibo de reconciliação
Um domínio de identidade pode informar outro sobre uma mudança sem demonstrar que o destinatário já a incorporou. Ainda é preciso identificar o recurso, conciliar esquemas, decidir se cabe uma consulta de retorno, aplicar uma regra local e observar o próprio estado. O RFC 9967…
IETF
Chris Wendt e a resposta assinada que não autenticava a mídia
Uma chamada que recebe resposta não deveria receber, por associação, todas as garantias que o usuário gostaria de ter. O caminho pode ter alcançado um destino, uma credencial pode ter assinado uma declaração e a mídia pode, ainda assim, ser outra questão. RFC 9970, de Chris Wendt…
IETF
Michael Prorock e o identificador de algoritmo que não escolhia uma política de confiança
Uma assinatura pode ser matematicamente verificável e ainda não responder à pergunta que decide seu efeito: por que esta chave deve ser aceita neste contexto? RFC 9964, trabalho coautorado por Michael Prorock e Orie Steele, melhora a linguagem compartilhada para chaves ML-DSA em…
Arquivo de Caso
O token chegou antes da chamada. A verificação ainda precisou esperar: RFC 9888
O provedor de destino já guardava uma declaração assinada, mas a chamada correspondente ainda percorria outra rede. A RFC 9888 permite que a evidência STIR contorne trechos que não a transportam em SIP. Ela não elimina a obrigação de provar que duas chegadas independentes…
IETF
Dan Harkins e a chave de bootstrap que não podia atestar a própria custódia
Controlar uma chave privada não revela como a chave pública correspondente chegou ao servidor nem se alguém tinha autoridade para associá-la àquele dispositivo. A RFC 9966 trabalha justamente nessa fronteira. Ela entrega uma prova de bootstrap em TLS, sem fingir que essa prova…
Tendências Institucionais da Ásia-Pacífico
C-DOT apresenta 14 produtos de segurança quântica
A C-DOT apresentou 14 produtos de QKD e criptografia pós-quântica para redes de comunicação, levando seu trabalho em segurança quântica a sistemas específicos de hardware e software.
Arquivo de Caso
O pedido foi assinado. A outra chave privada continuou sendo apenas declarada: RFC 9883
Uma assinatura válida pode provar quem assumiu uma declaração sem provar tecnicamente o fato declarado. Na RFC 9883, uma chave privada já certificada assina o pedido; a posse de uma segunda chave, destinada ao estabelecimento de chaves, permanece uma afirmação aceita por…
Arquivo de Caso
O RFC 9882 mandou preencher SHA-512, mas nem sempre usá-lo
Em uma mensagem CMS, um campo obrigatório pode estar correto e ainda assim não participar do cálculo que o auditor imagina. O RFC 9882 torna essa distinção explícita: em um dos caminhos do ML-DSA, SHA-512 precisa aparecer por interoperabilidade, enquanto o verificador é obrigado…
Arquivo de Caso
RFC 9879 modernizou o MAC, mas não aposentou o leitor legado
Um selo de conformidade pode confirmar que um arquivo PKCS #12 usa PBMAC1. Ele não revela se o leitor verificou o MAC, se aceitou parâmetros fracos ou se ignorou uma falha para alcançar a chave criptografada. RFC 9879 melhora a linguagem comum do contêiner; a decisão de confiar…
Arquivo de Caso
O pacote trouxe duas formas, mas ainda não uma só chave: RFC 9935
Uma chave privada ML-KEM pode chegar como semente, como chave de desencapsulamento expandida ou com ambas. A terceira opção resolve interoperabilidade, mas cria uma obrigação: sem recalcular e comparar, o importador viu dois valores, não uma identidade comprovada.
Arquivo de Caso
O OID nomeou o pacote de chaves. Não autorizou seu uso: RFC 9939
O objeto chegou com uma etiqueta CMS reconhecível e uma estrutura PKCS #8 que o leitor aceitou. Isso resolve uma questão de formato. Não resolve quem guarda a chave privada, quem pode recuperá-la ou quem pode decidir seu uso.
Arquivo de Caso
O recurso nomeou seu servidor de autorização. Não concedeu um direito: a fronteira de descoberta da RFC 9728
Um recurso pode informar corretamente qual é o próximo lugar para procurar sem ter permitido que o cliente use sua API. A RFC 9728 padroniza essa descoberta OAuth. Metadados coordenam; não emitem token, não validam token e não provam que uma operação ocorreu.