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.
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.
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.
Arquivo de Caso
A conversa de autorização ainda estava pendente. Isso não era um direito de API: o limite de continuação do GNAP
Um cliente pode ter permissão para continuar uma conversa de autorização sem ter permissão para chamar a API solicitada. A RFC 9635 separa esses fatos: a credencial de continuação faz uma solicitação avançar no servidor de autorização; o direito sobre o recurso, se vier a…
IETF
Sean Turner e a prova de chave privada que não autorizou o certificado
Uma chave capaz de assinar demonstra controle criptográfico. Não demonstra que o controlador é a pessoa declarada, que pode reivindicar o nome solicitado ou que uma autoridade certificadora aprovou o certificado final.
IETF
Panos Kampanakis e a sessão SSH com três comprovantes de segurança
O mesmo terminal pode mostrar um acordo de chaves híbrido, a impressão digital de uma chave de host convencional e, alguns instantes depois, a autenticação de um usuário. A conexão é contínua; a conclusão de segurança precisa continuar dividida.
IETF
Bas Westerbaan e o TLS híbrido que não tornou o certificado pós-quântico
Um painel pode acender em verde ao encontrar `X25519MLKEM768`. O mesmo handshake ainda pode usar uma assinatura clássica para provar a identidade do servidor. O painel não está necessariamente errado; ele só se torna enganoso quando o nome de uma propriedade passa a descrever o…
IETF
Daniel Fett: a MFA autenticou o usuário, não o contexto do QR
A vítima não digitou a senha em uma página falsa. Ela chegou ao serviço verdadeiro, concluiu o segundo fator e autorizou uma solicitação real. O erro estava na origem da solicitação: quem a havia iniciado era o invasor.
Arquivo de Caso
O certificado confirmou o par. A PSK externa ainda precisava de um custodiante: RFC 9973 e a autoridade no TLS
Há uma diferença entre conseguir abrir um canal protegido e conseguir explicar a cadeia de decisões que o tornou aceitável. Em uma frota de dispositivos, essa diferença costuma aparecer tarde: o certificado continua válido, o TLS continua funcionando, mas ninguém sabe mais qual…