Resumo

  • A versão 25 do Internet-Draft GAAP, datada de 25 de setembro, chama a seção 5 de “Illustrative GAAP API” e afirma que GAAP é um protocolo, não uma biblioteca ou API em Python. O pseudocódigo é uma possibilidade de integração; outra interface ou nenhuma interface pode ser usada se o protocolo Claim no fio for seguido. A versão 24 já classificava o exemplo como ilustrativo e não normativo.
  • O texto agora ressalta que o registro Claim tem apenas quatro campos e detalha por que ChaCha20 sem integridade autenticada é maleável. São esclarecimentos de leitura e risco, não alteração comprovada do pacote, proibição inédita ou relato de ataque.

Uma equipe pode organizar o pedido de endereço multicast em um processo local, enquanto outra embute a mesma função em um equipamento. A diferença não impediria que seus componentes trocassem Claims compatíveis. O inverso também é verdadeiro: copiar os nomes de métodos vistos no rascunho não garante que dois participantes entendam os mesmos dados. Essa distinção é central no GAAP, que propõe alocar endereços de grupo multicast sem um servidor único de atribuição. A revisão 25 tira a API em pseudocódigo da posição de possível referência implícita de conformidade e declara o ponto comum no intercâmbio pela rede.

É preciso medir corretamente a mudança. Na versão 24, o exemplo já não era normativo. A revisão 25 não retirou uma exigência anterior de uso de Python, pois essa exigência não estava lá. Ela adicionou uma afirmação categórica: GAAP não é uma biblioteca, e o exemplo não fixa a interface que o aplicativo deve oferecer. O implementador pode expor uma API diferente ou nem expor uma API, desde que siga o protocolo Claim no fio. Os modelos de software usados aqui para ilustrar essa liberdade não são afirmações sobre produtos existentes.

Na seção 4, o rascunho também separa campos de instruções sobre campos. O registro Claim contém endereço de grupo IPv4, endereço de grupo IPv6, carimbo de tempo e nome do grupo. Parágrafos sobre comparação, uso ou análise desses dados não adicionam outros itens à mensagem. É uma melhora na leitura do documento. Não há suporte para anunciar um quinto campo, nova ordem dos bytes ou migração de um formato já implantado. Uma especificação mais nítida ainda precisa de implementação e teste para produzir evidência de interoperabilidade.

A parte de segurança acrescenta uma justificativa, não uma nova regra. A versão 24 já dizia que ChaCha20 sem código de autenticação de mensagem não satisfaz a integridade exigida pelo GAAP e não deve ser usado sozinho. A versão 25 explica que, sem integridade, o texto cifrado de um algoritmo de fluxo pode ser manipulado: um agente no caminho poderia inverter bits e fazer surgir, após a decifração, outro endereço de grupo, outro carimbo de tempo ou outro nome sem aviso. O documento alerta que a falsa confiança em proteção talvez seja pior do que um modo básico assumidamente sem criptografia.

Não há neste material um incidente, uma implantação vulnerável identificada nem um ensaio operacional.

O recado de governança está na combinação das duas fronteiras. Escolhas locais de linguagem e integração não precisam ser padronizadas para que Claims sejam compartilhados. Por outro lado, chamar uma mensagem de “criptografada” não substitui a prova de que ela não pode ser alterada silenciosamente. Um teste que se concentre apenas na presença de uma função Python ou do nome de uma cifra avalia o rótulo, não o comportamento entre pares. Essa conclusão é análise editorial da proposta, não selo de conformidade do IETF.

No Datatracker, a revisão 25 continua sendo um Internet-Draft do grupo PIM sob IESG Evaluation, em AD Followup, com status Experimental pretendido. Não é RFC. Uma reportagem anterior da BTW sobre GAAP-23 examinou faixas fixas de alocação e a convergência de Claims de mesmo nome após partições de rede. A nova revisão não prova a solução daquele problema. O fato jornalístico desta vez é a explicitação do limite entre intercâmbio comum, exemplo de software e integridade verificável.

Fontes