Resumo

  • O token RFC 3161 vincula uma impressão digital a hora, política e chave, mas não carrega a cadeia metrológica que demonstra como o relógio da autoridade acompanhou o UTC.
  • O RFC 3628 separou política de prática e exigiu rastreabilidade a UTC(k), detecção de perda de sincronismo, suspensão da emissão, uma chave ativa por unidade, auditoria e divulgação de incidentes.
  • UTCr atende a operação rápida; a Circular T fornece o resultado definitivo de rastreabilidade. Uma decisão durável precisa conservar ambos, além da versão das práticas, histórico de chave, intervalo afetado e estado de confiança.

Dois relógios editoriais para duas decisões

O Bureau International des Poids et Mesures calcula o UTC a partir de dados fornecidos por laboratórios de tempo. Esses laboratórios mantêm realizações locais em tempo real, chamadas UTC(k). A Circular T, publicada mensalmente, apresenta as diferenças entre UTC e UTC(k) e constitui o registro definitivo de rastreabilidade.

Há também o Rapid UTC, ou UTCr. Ele é publicado semanalmente porque a operação não pode esperar indefinidamente pelo cálculo final. Serve para orientar laboratórios com menor latência. Mas o próprio BIPM afirma que UTCr complementa o UTC: não substitui os resultados definitivos nem a informação de rastreabilidade da Circular T.

Portanto, receber UTCr primeiro não torna a Circular T redundante. Um é uma observação operacional rápida; a outra consolida a comparação metrológica. Guardar apenas o dado mais veloz pode permitir conduzir o serviço, mas não reconstituir mais tarde a prova final da sua relação com UTC.

O Z assinado não revela o caminho

O RFC 3161 define um token disciplinado. A messageImprint deve reproduzir o hash solicitado. O número de série precisa permanecer único para a autoridade, inclusive após interrupções. genTime registra o instante em que a TSA produziu o token. O identificador de política nomeia as regras aplicáveis. Nonce, quando pedido, volta na resposta. Assinatura e identificador do certificado associam a declaração a uma chave.

Mesmo assim, o Z ao fim de genTime não identifica o laboratório UTC(k), o meio de distribuição, o desvio observado, a incerteza, o instante da última calibração ou o estado de holdover. A assinatura comprova que a autoridade se comprometeu com aquela representação temporal; não mostra como a representação foi medida.

O token também não certifica a verdade, autoria, completude ou legalidade do dado original. Não é, por si, recibo de um servidor nem confirmação de uma aplicação. A precisão opcional forma um intervalo ao redor do horário. Quando ordering não é verdadeiro, dois tokens da mesma autoridade só podem ser ordenados pelo horário se a separação superar a soma das precisões.

A política cabia no token; a prática, não

O RFC 3628 foi publicado como Informational em 2003 e era tecnicamente equivalente a uma especificação ETSI daquele período. Não é um Internet Standard atual nem um manual completo de conformidade contemporânea. Sua separação conceitual, porém, continua útil: a política declara o que deve ser cumprido; a declaração de práticas da TSA explica como um provedor concreto cumpre isso em sua organização, instalações e sistemas.

O OID no token aponta para a política. Não incorpora a versão das práticas em vigor no dia, a aprovação, a topologia do tempo, a cerimônia de chave, os papéis de confiança ou o registro de incidentes. O RFC previa que a TSA sustentasse sua alegação disponibilizando evidências ou passando por avaliação independente. O nome da política era uma referência ao dossiê, não uma autenticação automática do dossiê.

Terceirizar uma fonte de tempo, um módulo criptográfico ou uma plataforma de emissão não transfere essa responsabilidade. A TSA continua responsável pelos controles e pelas divulgações. A evidência precisa atravessar os contratos: quem mediu, quem guardou, quando o registro foi obtido, como sua integridade foi protegida e o que ocorre quando o fornecedor sai.

Uma referência de tempo também envelhece

O RFC 3628 citava a recomendação ITU-R TF.460-5. Essa revisão foi substituída; a TF.460-6 está em vigor. A ETSI EN 319 421 V1.3.1, adotada em 2025, usa a referência atual. Um identificador estável de política não congela as normas, laboratórios ou algoritmos dos quais sua execução depende.

Esse detalhe é maior que uma atualização bibliográfica. Um arquivo de longo prazo pode preservar perfeitamente o token e ainda perder a informação sobre qual definição, qual prática e qual cadeia de comparação estavam vigentes. Se o sistema só registra “conforme RFC 3628”, ele apaga mudanças que podem ser decisivas para uma verificação futura.

A solução não é reescrever tokens antigos. É preservar a versão da política, das práticas, dos documentos de divulgação, da referência de tempo, dos certificados e das avaliações que existiam quando cada população de tokens foi emitida.

Quando o relógio sai da faixa, a autoridade deve parar

O RFC 3628 exigia que a hora do token fosse rastreável a um valor em tempo real distribuído por um laboratório UTC(k), dentro da precisão declarada. Também exigia detecção de deriva ou salto. Uma vez detectada dessincronização além do limite, a unidade deveria interromper a emissão e só retomar após recuperação.

A ETSI EN 319 421 V1.3.1 conserva esse princípio. Ela pede proteção contra mudanças não detectadas, registro da sincronização normal, recalibração e perda de sincronismo, suspensão da emissão e recuperação antes da volta. Durante um segundo intercalar anunciado, a unidade deve manter sincronismo e registrar o instante exato do ajuste dentro da precisão declarada.

“Sincronizado agora” não explica quando o desvio começou, quanto tempo o detector levou, quantos tokens foram emitidos antes da parada nem o que autorizou a retomada. O registro útil conecta a última calibração confiável, a primeira observação suspeita, a detecção, a parada, a recuperação e o intervalo de tempo ou números de série potencialmente afetado.

A indisponibilidade correta é parte da prova. Um serviço que para no limiar declarado respeita sua autoridade. Um serviço que permanece verde enquanto desconhece o próprio tempo amplia uma população que talvez nunca possa ser classificada.

Uma chave ativa também é uma medição de estado

O RFC 3628 descreveu uma Time-Stamping Unit como hardware e software administrados em conjunto, com uma única chave de assinatura de carimbo ativa por vez. A TSA pode ter várias TSUs identificáveis, cada qual com sua fronteira. A norma ETSI atual mantém uma chave ativa, papéis de confiança, controle dual, dispositivo criptográfico seguro, uso exclusivo para carimbos e rejeição automática após o fim da vida operacional da chave privada.

Validar o certificado responde a uma pergunta diferente. Mostra que a chave pública foi certificada e que a assinatura confere. Não demonstra que uma segunda chave não estava ativa, que backups ficaram protegidos, que a geração ocorreu sob controle dual, que a chave privada não ultrapassou o limite interno ou que serviços qualificados e não qualificados estavam devidamente separados.

O RFC 5816 acrescentou ESSCertIDv2 para modernizar a ligação ao certificado do signatário. Isso melhora a manutenção criptográfica, mas não leva para dentro do token a cerimônia, a exclusividade ou o ciclo de vida da chave.

Um incidente precisa delimitar sua população

O RFC 3628 exigia divulgação de comprometimento, suspeita de comprometimento ou perda de calibração, suspensão até a recuperação e, quando possível, informação para identificar os tokens afetados. A ETSI atual prossegue com essa estrutura e separa registros de ciclo de vida de chaves e certificados, sincronização normal, recalibração e perda de sincronismo.

“Serviço restaurado” não é um limite. O relying party precisa saber qual TSU e certificado estavam envolvidos, o último ponto confiável, o período suspeito, os seriais alcançados, a parada e a condição de recuperação. Sem isso, tokens criptograficamente íntegros permanecem operacionalmente inclassificáveis.

Uma trilha de auditoria pode distinguir tokens genuínos de falsificações retrodatadas após comprometimento. Dois carimbos de autoridades independentes podem acrescentar uma observação. A independência, contudo, precisa ser provada: duas autoridades podem compartilhar a mesma fonte de tempo, plataforma criptográfica ou avaliador.

O status qualificado também chega de fora

O Regulation (EU) No 910/2014 atribui ao carimbo eletrônico qualificado uma presunção de exatidão da data e hora indicadas e de integridade dos dados vinculados. O Commission Implementing Regulation (EU) 2025/1929 referencia, com adaptações, ETSI EN 319 421 V1.3.1 e EN 319 422 V1.1.1 para a presunção de conformidade.

Isso não transforma uma extensão do token em decisão autônoma de qualificação. A ETSI diz que a declaração qualificada no token é apenas indicação da alegação; o relying party deve consultar a lista confiável relevante para estabelecer o status. Supervisão, avaliação de conformidade e a fotografia da lista aplicável continuam externas.

Certificação criptográfica, treinamento, varredura de vulnerabilidades, teste anual de intrusão, transporte seguro e plano de encerramento também não aparecem só porque o token foi analisado com sucesso. Quanto maior o efeito jurídico, maior a necessidade de guardar o estado institucional que o sustentava.

Verificar por décadas é acumular observações

O RFC 3628 advertiu que um token verificável hoje pode não permanecer verificável. Durante a validade do certificado da TSU, a informação corrente de revogação deve ser consultada. Depois do vencimento, a publicação comum de status talvez já não demonstre que a chave privada nunca foi comprometida. Resistência a colisão e força de assinatura também se degradam.

O Anexo C trata validade longa como conhecimento contínuo: chave não comprometida, hash ainda resistente e assinatura ainda fora do alcance prático. Quando essas condições não podem ser conservadas diretamente, outro carimbo protetor pode ser necessário. Um visto verde antigo é uma observação datada, não uma propriedade eterna.

O pacote durável inclui os bytes e o hash exatos do token; versões de política, práticas e divulgação; cadeia e status de certificados; fonte UTC(k), UTCr e Circular T pertinentes; sincronização e calibração; ciclo da chave; incidentes; estado de lista confiável quando relevante; avaliação de algoritmos; eventos de preservação; e a própria decisão de confiança.

Fontes

  1. RFC 3628 — Policy Requirements for Time-Stamping Authorities
  2. RFC 3628 plain text
  3. RFC Editor information for RFC 3628
  4. IETF Datatracker record for RFC 3628
  5. RFC 3628 errata search
  6. RFC 3161 — Time-Stamp Protocol
  7. RFC Editor information for RFC 3161
  8. IETF Datatracker record for RFC 3161
  9. RFC 3161 with inline errata
  10. RFC 5816 — ESSCertIDv2 Update for RFC 3161
  11. RFC Editor information for RFC 5816
  12. IETF Datatracker record for RFC 5816
  13. ETSI EN 319 421 V1.3.1
  14. ETSI EN 319 422 V1.1.1
  15. BIPM Circular T
  16. BIPM Coordinated Universal Time
  17. BIPM Rapid UTC
  18. ITU-R Recommendation TF.460
  19. ITU-R Recommendation TF.536-2
  20. Consolidated Regulation (EU) No 910/2014
  21. Commission Implementing Regulation (EU) 2025/1929
  22. Lu Heng — Running Code Primary
  23. Lu Heng — Minimum Initial Specification
  24. Lu Heng — On Reality Layers
  25. Lu Heng — On Authority and Belief