Tópico
Identidade digital e credenciais
Na faceta Tópico, a inteligência do tópico Identidade digital e credenciais conecta artigos que compartilham um assunto específico, foco de sinal ou tema de monitoramento. A página oferece aos leitores um percurso mais rico por meio de reportagens relacionadas, evidências de fontes, atores do mercado e implicações de infraestrutura, com contexto suficiente para entender por que o tópico é relevante em movimentações de empresas, decisões de governança, exposição regional e risco operacional. Os leitores podem comparar sinais recorrentes, organizações afetadas, evidências públicas, contexto de mercado, continuidade de serviço, compras, concorrência, conformidade e questões de planejamento estratégico por trás do assunto, em vez de se limitar a uma lista enxuta de artigos correspondentes. A página explica o que o tópico abrange, quais atores ou políticas de infraestrutura estão envolvidos, quais evidências sustentam a cobertura e por que o assunto pode ser importante para operadores, clientes, investidores e leitores de políticas.
História
O servidor não precisava do texto claro. Ainda controlava a disponibilidade: RFC 3157
Guardar uma chave sem conseguir lê-la não torna o guardião irrelevante. Em agosto de 2001, a RFC 3157 aplicou essa distinção à mobilidade de credenciais criptográficas entre computadores, notebooks, telefones e roteadores. A cifra podia impedir que o servidor usasse a chave…
Reportagens
No RPKI, trocar a chave não basta: é preciso provar onde a autoridade termina
O plano trimestral do RIPE NCC reúne duas decisões que deveriam orientar a mesma arquitetura. A organização começou a migrar o painel e as credenciais RPKI para OpenID Connect. Também recusou usar, numa baliza de roteamento, uma API capaz de editar ROAs para todo o espaço do RIPE…
História
O servidor precisava de um terceiro desafio: RFC 3163
No modo de autenticação mútua da RFC 3163, o terceiro valor aleatório não era enfeite. Ele respondia a uma assimetria na ordem da troca: quando o cliente escolhia seu próprio valor, já tinha visto o primeiro desafio do servidor. A correção era específica — e as garantias do…
IETF
O envelope foi assinado. O texto cifrado separado ficou fora da assinatura.
O sistema guardou o objeto COSE em uma tabela, o conteúdo cifrado em outro serviço e, no fim, exibiu uma única confirmação de validade. Essa confirmação apaga a pergunta que decide o risco: quais bytes realmente entraram em cada cálculo criptográfico?
IETF
O calendário o chamou de proprietário. O controle ainda não havia sido concedido.
Um registro portátil pode chamar um participante de proprietário sem torná-lo editor autorizado. O rótulo descreve um papel; o protocolo de troca ainda precisa decidir quem pode remarcar o evento, alterar participantes ou enviar uma atualização em seu nome.
IETF
O redirecionamento funcionou. A credencial já tinha cruzado em texto claro.
A chamada terminou em HTTPS, devolveu o objeto esperado e alimentou um painel verde. O resultado não revela a ordem real: antes de receber o redirecionamento, o cliente já havia colocado a credencial na primeira requisição HTTP.
IETF
A cadeia validou a âncora que trouxe. A parte verificadora ainda não confiava nela.
O did:x509 pode produzir uma resolução tecnicamente perfeita sem responder à pergunta que decide o uso da identidade. A cadeia fecha, a impressão digital da CA confere e os predicados da folha são verdadeiros; a confiança local, a assinatura da mensagem e a permissão para agir…
História
A prova de longo prazo precisava sobreviver à chave: RFC 3126
A RFC 3126 tratou a assinatura antiga como problema de custódia. Um cálculo correto em 2001 não conseguiria explicar-se décadas depois se certificados, dados de revogação, bytes exatos ou algoritmos confiáveis tivessem desaparecido. A resposta foi uma cadeia renovável, não…
IETF
O handshake abriu; a memória do grupo ainda faltava
Um receptor externo do MLS pode decifrar o mesmo Commit ou Proposal visto pelos membros e ainda não ter o estado necessário para autenticar quem enviou. A peça ausente é o GroupContext que liga época, folha, credencial e lista acordada de receptores.
História
Uma assinatura válida ainda precisava de uma política: RFC 3125
A RFC 3125 tentou transformar as regras em torno de uma assinatura eletrônica em um objeto identificável e processável. O cálculo criptográfico abria apenas a primeira porta: ainda era preciso localizar a política exata, o compromisso, as condições de confiança e o contexto que…
IETF
A chave ativa assinou a sucessora. Esse era o risco.
O registro de rotação pode estar inteiro, a assinatura pode ser correta e a troca ainda assim pertencer ao invasor. O que falta é provar que a autoridade para operar hoje incluía o direito de escolher quem governaria amanhã.
IETF
A chave passou na validação; a relação comercial ainda precisava aprová-la
Uma equipe pode instalar um certificado novo, completar o handshake, validar a assinatura e receber um MDN perfeito. Ainda assim, se não houver registro de quem vinculou aquela chave ao parceiro certo, a operação terá comprovado a matemática antes de comprovar o mandato.
Institucional da Ásia-Pacífico
TrueMoney: o que os números da maior carteira digital do Sudeste Asiático realmente mostram
A Ascend Money, braço de fintech do grupo CP e operadora da marca TrueMoney, publica números impressionantes de escala: 50 milhões de clientes, 21 milhões de usuários de carteira eletrônica, 88.000 agentes e 14 bilhões de dólares processados. Um exame das fontes primárias datadas…
IETF
O Voucher prometeu outro. A renovação ainda não aconteceu.
No projeto atual da ANIMA, `last-renewal-date` é uma projeção informativa do MASA, não uma extensão de validade. A revisão 36 explicita os controles que ainda precisam ocorrer depois: RVR nova, chave do Domínio, certificado, política, emissão e aceitação.
IETF
O núcleo encolheu; o inventário não apareceu junto
O candidato a sucessor do RFC 9180 deixa Base e PSK no núcleo do HPKE e reserva os valores antes destinados a Auth e AuthPSK. A decisão reduz a especificação comum, mas não produz o mapa de perfis, executáveis, exceções, objetos armazenados e pares que precisa acompanhar a…
IETF
O assinante entrou na rede. Ele não virou todos os hosts dela
Uma VPN de camada 2 pode autenticar corretamente a pessoa que pediu acesso remoto e, ainda assim, permitir que essa pessoa envie uma trama com o endereço MAC de outro equipamento. CONNECT-ETHERNET torna o caminho HTTP interoperável; a autoridade para representar identidades…
IETF
O servidor devolveu o objeto antigo, não uma trilha de auditoria
O JMAP Entidade History propõe recuperar versões anteriores e destruídas de um objeto. As próprias regras da proposta mostram por que esses retratos guardados não provam toda mudança, seu autor, sua autorização nem seu resultado.
IETF
A nova autoridade ganhou a primeira tentativa, não a confiança do cliente
Na troca de uma autoridade certificadora, o servidor pode oferecer primeiro a cadeia nova e guardar a antiga como alternativa. Os clientes atualizados avançam; os demais talvez abram uma segunda conexão. O mecanismo proposto pelo IETF torna essa passagem mais controlável, mas não…
IETF
O exportador gerou 128 bytes. Eles não ligavam o portador do token ao túnel
A revisão 04 do EAP-PPT remove uma saída que parecia material de chave fornecido pelo método interno. Um exportador TLS pode gerar bytes exclusivos da sessão sem provar que o portador do token ao portador é também quem termina o túnel.
História
A senha não tinha uma entrada no diretório para alterar: RFC 3062
Em 2001, a operação comum de alteração do LDAP não alcançava todas as senhas. A RFC 3062 definiu um pedido separado de troca, ligado ao usuário da sessão ou a uma identidade que não precisava ser um DN, mesmo quando a senha ficava fora do diretório. A regra de sucesso era…