Resumo

  • Resposta válida prova assinatura, inclusão do pedido e uma alegação temporal delimitada; não prova que o relógio estava certo.
  • Relatório encadeado prova a ordem e que pelo menos um servidor errou. Ele não escolhe sozinho o responsável nem executa a revogação.

Três servidores assinam intervalos que não cabem na ordem comprovada de chegada. A cadeia elimina a dúvida sobre a existência do conflito, mas preserva outra pergunta: qual relógio produziu a afirmação falsa?

Essa honestidade lógica define Roughtime revisão 19. O Internet-Draft ativo do grupo NTP pretende publicação Experimental e está no processo do RFC Editor, mas ainda não é RFC. A comparação com a revisão 18 é sobretudo editorial; não se inventa uma mudança normativa na versão 19.

O cliente envia um nonce, incluído numa árvore de Merkle. A resposta traz MIDP, RADI e a raiz. Uma chave Ed25519 temporária assina a resposta; a chave de longo prazo assina a delegação limitada por MINT e MAXT. Verificar assinaturas, inclusão e intervalo torna a resposta válida.

O próprio texto nega o salto seguinte: validade não prova hora correta. Prova que o servidor assinou aquela alegação dentro de (MIDP-RADI, MIDP+RADI). A assinatura protege autoria e integridade; não corrige a fonte física do tempo.

No modo multisservidor, a lista precisa de ao menos três servidores operacionais de partes diferentes. As consultas ocorrem em sequência e se repetem. Cada nonce posterior depende da resposta anterior e de nova aleatoriedade, prendendo a ordem causal ao material assinado.

Isso é mais forte do que recolher três leituras soltas. A segunda rodada incorpora respostas que o cliente já recebeu, reduzindo a possibilidade de reorganizar a cronologia depois do fato. O cliente consegue entregar a um terceiro não apenas valores de relógio, mas uma prova verificável de que certa resposta precedeu certo pedido posterior. A ordem causal permanece auditável mesmo quando os intervalos de tempo não podem ser todos verdadeiros.

Se respostas válidas violam essa ordem, há malfeasance. O relatório guarda chaves esperadas, valores aleatórios, pedidos e respostas. Ele demonstra que ao menos um servidor informou hora errada. Não identifica qual: duas fontes correlacionadas podem isolar a fonte honesta. Diversidade de operador, origem temporal e governança da lista continuam essenciais.

O protocolo padroniza formatos, não o tribunal. Não decide inclusão na lista, aceitação do relatório, atribuição, recurso ou revogação. Um fórum humano é apenas uma possibilidade. Mesmo assim, o rascunho chama manutenção da lista e adjudicação de essenciais à segurança.

Essa separação revela onde o poder realmente permanece. Quem escolhe a lista de confiança decide quais vozes podem participar da prova; quem aceita o relatório decide quando um conflito vira caso; quem controla a revogação decide quando uma conclusão passa a alterar clientes. Se essas autoridades não forem nomeadas, sua política reaparece como padrão silencioso de software, sem desaparecer de fato.

Guardar tudo num único status apagaria essa autoridade. Resposta bruta, validação, par contraditório, versão da lista, envio, revisão, atribuição, revogação, distribuição e reparo são fatos diferentes. E uma chave temporária comprometida após MAXT ainda pode retroassinar falsidades dentro do antigo período.

Roughtime ajuda a iniciar validação de certificados e limitar observações NTP/PTP. Não é carimbo legal, ordem total de transações, prova de integridade do equipamento ou recibo de execução real.