Resumo

  • Uma assinatura válida é necessária, mas não suficiente, para um Validation Token válido. O Registry ainda verifica objeto assinado, algoritmos, certificado, credenciamento da VE, Registrar, número, método, datas e política contra repetição.
  • O token comunica uma validação. Ele não é a decisão de delegação, o commit EPP, a publicação DNS autoritativa, a observação do resolvedor nem a conclusão de um serviço.

Um sistema recebe um token sem expirationDate e grava “autorização permanente”. O XML foi interpretado conforme o formato, mas a conclusão institucional não existe no documento.

O RFC 5105 realmente define que a ausência dessa data representa validade infinita do Token. Na mesma seção, porém, exige que o Registry verifique se a data apresentada — inclusive nenhuma data — está de acordo com a política local. A política também precisa estabelecer por quanto tempo, após executionDate, o Token pode autorizar uma delegação.

Há, portanto, diferença entre a semântica do campo e a decisão de aceitá-lo. O formato diz como ler. A política diz se aquela leitura pode sustentar esta solicitação, neste momento.

ENUM associa um nome de domínio a um número E.164. O RFC 4725 separa Assignee, Registrant, Validation Entity, Registrar, Registry, provedor DNS e provedor da aplicação. A VE verifica a relação com o número. O Registrar apresenta o pedido. O Registry mantém o banco mestre e a zona autoritativa.

O RFC 5105 cria o artefato que leva o resultado da VE ao Registry, mesmo quando o caminho passa por um Registrar sem autoridade própria para afirmar o direito de uso. A assinatura protege origem e integridade. Ela não transfere a competência decisória da VE, do Registrar ou do Registry.

O núcleo obrigatório registra serial único por VE, número E.164, eventual final de bloco, identidade da VE, identidade do Registrar, método, data de execução e expiração opcional. Há ainda dados opcionais de contato. Cada componente tem alcance próprio; nenhum campo isolado representa a delegação.

O serial não é global. Dois VEs podem usar a mesma sequência. Para correlacionar com segurança, é preciso VE mais serial; para decidir, também hash exato, Registrar, intervalo numérico, método, datas, política e histórico de uso. Uma tabela que guarda apenas o serial cria uma unicidade que o RFC nunca prometeu.

O intervalo E.164 começa no número principal e termina, de forma inclusiva, no lastE164Number, se houver. Ambos precisam ter o mesmo comprimento. Uma rotina que expande ou normaliza o intervalo fora desses limites muda a declaração. A assinatura protege a representação assinada, não a interpretação inventada depois.

O Token usa XML-DSIG enveloped e canonicalização XML exclusiva. Isso impede que namespaces herdados do XML externo alterem a entrada do resumo. É importante quando o documento é transportado dentro de EPP. Mas canonicalização não valida o esquema, não escolhe uma política e não confirma o direito atual sobre o número.

O Reference URI="#TOKEN" deve apontar para o elemento que leva Id="TOKEN". Se o ID for movido para tokendata, um verificador genérico ainda pode aprovar uma assinatura sobre o bloco de contato. Para o objetivo do Registry, número, método e datas ficaram fora. A matemática respondeu corretamente a uma pergunta errada.

Por isso o Registry deve confirmar transformações e algoritmos aprovados, referência ao Token completo e pertencimento da chave a uma VE credenciada. O exemplo assinado do RFC é explícito: assinatura válida é condição necessária, não suficiente, de um Token válido. Certificado e XML Schema são verificações adicionais.

O certificado incorporado não escolhe sua própria confiança. O Registry pode operar como CA, aceitar uma CA pública ou usar somente chaves pré-cadastradas. Essa escolha é política local. Uma cadeia criptograficamente montável não prova que a VE mantinha credenciamento institucional no instante da decisão.

A trilha precisa preservar o trust store e a época de credenciamento. Um certificado pode estar dentro da validade X.509 e a VE já não ser aceita. Uma alteração posterior pode mudar a avaliação atual sem apagar o que o sistema histórico observou. Estado antigo e julgamento presente devem coexistir.

O registrarID fecha outra brecha. Um segundo Registrar pode copiar o Token sem modificar seus bytes. A assinatura continua correta. Ao comparar o Token com o pedido, o Registry constata que ele foi emitido para outra parte. A integridade perfeita passa a ser prova da incompatibilidade, não da autorização.

O methodID também não executa a validação. Ele nomeia o método declarado. O RFC 4725 reconhece variações conforme dados, partes, escolha do Assignee e regulação. O Registry decide se o método era admitido para aquele número e política. Um rótulo não substitui a evidência do procedimento.

A validação inicial não congela o futuro. A delegação precisa acompanhar mudanças na atribuição E.164. Revalidação bem-sucedida pode manter o domínio; revalidação malsucedida leva à suspensão por ação explícita ou expiração, talvez com período de graça. Uma antiga assinatura positiva não cancela um evento posterior.

Repetição exige estado. Um Token aceito pode reaparecer dentro da validade aparente. VE, serial, hash, Registrar, escopo, primeira apresentação, resultado e janela permitida precisam ser unidos. Sem esse livro, não se distingue reenvio legítimo, tentativa já rejeitada e segunda autorização indevida.

Os dados de contato opcionais não são o núcleo. Podem ajudar numa revalidação, mas organização, endereço ou e-mail não provam a atribuição atual. O conteúdo do Token não é cifrado. Se houver dever de confidencialidade, outro mecanismo deve protegê-lo. Assinatura e sigilo respondem a ameaças diferentes.

Algoritmos também pertencem a uma época. O RFC exigia suporte a RSA-SHA1 e RSA-SHA256 e já registrava dúvidas sobre SHA-1. A política escolhe o que aceita. Uma biblioteca conseguir verificar um algoritmo antigo não obriga o Registry a usá-lo para uma nova delegação.

Depois da aceitação ainda há execução. O RFC 5076 define uma extensão EPP para adicionar, alterar, remover e consultar informação de validação. Uma resposta EPP positiva comprova aquela transação; não é observação da zona DNS autoritativa.

O banco do Registry pode mudar enquanto a geração de zona falha. A zona pode ser publicada enquanto caches ainda servem o passado. O RFC 3761 pode levar o resolvedor a um URI; o URI pode estar errado, o destino indisponível ou a comunicação incompleta. A assinatura da VE não governa essas etapas.

Um modelo confiável preserva recibos separados. O recibo criptográfico contém bytes, hash, parser, esquema, ID resolvido, nó referenciado, transformações, forma canonicalizada, algoritmos, cadeia, âncoras e resultado. Ele não declara autorização.

O recibo de política contém VE e credenciamento, método, Registrar, escopo E.164, execução, expiração, janela, versão de política e histórico de repetição. O Registry emite uma decisão própria. EPP, banco de delegação, publicação autoritativa, resolvedor e aplicação emitem resultados posteriores com seus relógios.

Assim um incidente pode ser localizado: alvo XML errado, VE sem credenciamento, Registrar incompatível, método obsoleto, Token repetido, EPP falho, zona atrasada ou aplicação indisponível. Um único estado “validado” apaga a causa e concentra autoridade num sistema que não a possui.

Essa separação segue as camadas de realidade de Heng Lu. A assinatura é uma evidência forte de representação e procedência. Sua força depende de não falar em nome da política ou do sistema em execução. Running code aparece quando cada componente registra a própria transição verificável.

Fontes