Carimbos de tempo e tempo confiável

Spec: RFC 3161 Spec: RFC 5816 Spec: ISO 32000-2, §12.8.5 Evidence: Standard-backed

Visão geral

Um carimbo de tempo não registra “quando isso foi assinado.” Ele comprova algo mais restrito e mais forte: que um item de dados específico existia antes de um instante específico, atestado por uma parte que não é o signatário. Essa distinção concentra todo o valor do tempo confiável e é frequentemente mal compreendida.

Por que isso importa

O horário de assinatura contido em uma assinatura é aquilo que o computador do signatário afirmou. Um relógio pode estar errado, por acidente ou de propósito. Se a única evidência do quando for a declaração do próprio signatário, então um signatário pode antedatar ou pós-datar um documento à vontade. Um certificado revogado ontem pode ser apresentado como se tivesse assinado no ano passado. O “quando” não é um detalhe. Ele determina se uma assinatura feita com um certificado agora expirado ou agora revogado ainda é válida. E, se o tempo confiável estiver errado, todo argumento de validade de longo prazo construído sobre ele desmorona.

A versão curta

O horário de assinatura do próprio signatário é uma alegação, não uma prova. Ele é trivialmente falsificável.
Um carimbo de tempo RFC 3161 é um token assinado de uma Autoridade de Carimbo de Tempo (TSA) que vincula um hash dos seus dados ao horário da TSA.
O que ele comprova é preciso: os dados existiam antes do horário declarado pela TSA. Não o momento exato da criação — trata-se de um limite superior.
O token ecoa o seu nonce e a sua impressão de mensagem, de modo que ele não pode ser uma repetição nem se referir a dados diferentes.
Um carimbo de tempo de documento aplica o mesmo mecanismo ao PDF inteiro, ancorando tudo o que está sob ele — a assinatura e a evidência de validação incorporada — em um instante confiável.

Como o NextPDF aborda isso

O NextPDF trata um carimbo de tempo como algo a ser verificado, não apenas obtido. Solicitar um token é a menor parte do trabalho. O entendimento do motor é que um token não verificado não é evidência.

Quando o motor carimba o tempo de uma assinatura, ele envia à TSA um hash dos dados e um novo nonce aleatório, nunca os dados em si. O token retornado é então conferido contra o conjunto completo de propriedades que o tornam significativo: o status retornado pela autoridade foi “granted”, o nonce no token corresponde ao que foi enviado, a impressão de mensagem no token corresponde ao hash enviado, a própria assinatura criptográfica do token é verificada, o tipo de conteúdo do token é o tipo de carimbo de tempo e o horário declarado fica dentro de uma tolerância aceitável. Qualquer divergência é uma falha definitiva com um motivo tipado. Não existe um caminho de “parece próximo o suficiente”. Um carimbo de tempo de documento segue a mesma regra, aplicada ao arquivo inteiro em vez do valor de uma única assinatura.

Hash the data Only a digest of the signature value (or the whole PDF, for a document timestamp) is computed — never the data itself.
Send hash + nonce The digest and a fresh random nonce go to the Time-Stamp Authority.
TSA returns a token A signed token binds the digest to the TSA’s genTime and echoes the nonce.
Verify the token Status granted, nonce matches, message imprint matches, token signature verifies, time within tolerance.
Conclude an upper bound The data provably existed before the TSA’s stated time — attested by a party that is not the signer.

Como um carimbo de tempo confiável é obtido e o que ele comprova: um hash mais um nonce são enviados à TSA, a TSA retorna um token assinado que vincula esse hash ao seu horário, e o verificador confirma o vínculo antes de tratá-lo como prova de que os dados existiam antes daquele horário.

O que a evidência diz

Evidence: Standard-backed A definição é exata. Spec: ISO/IEC 18014-2, §3 define um serviço de carimbo de tempo como aquele que fornece evidência de que um item de dados existia antes de um determinado ponto no tempo — um limite superior, não um instante de criação. Spec: ISO/IEC 18014-2, §7 define o conteúdo TSTInfo do token: uma impressão de mensagem (o hash dos seus dados), um horário de geração, um número de série e um nonce opcional. Spec: ISO/IEC 18014-2, §6 declara a conclusão que um verificador pode tirar quando a verificação é bem-sucedida: que o item de dados existia antes do horário no token — nada mais e nada menos.

Para PDF, Spec: ISO 32000-2, §12.8.5 especifica o carimbo de tempo de documento: o intervalo de bytes cobre o arquivo inteiro excluindo o valor Contents, esse hash é enviado a uma autoridade de carimbo de tempo, e o token RFC 3161 retornado — conforme atualizado por Spec: RFC 5816 — é colocado em Contents. É a mesma disciplina de intervalo de bytes de uma assinatura, aplicada ao tempo em vez da identidade. E Spec: RFC 6960, §4.4.4 é o motivo pelo qual isso importa para a longevidade: o tempo confiável é o que permite que um validador comprove que uma assinatura era confiável no dia em que foi produzida, mesmo depois que o certificado expirou.

O motor do NextPDF envia um hash e um nonce, nunca os dados, e verifica o token retornado em relação a status, nonce, impressão de mensagem, assinatura do token, tipo de conteúdo e tolerância de tempo antes de tratá-lo como evidência.

Exemplo prático

Você não monta um token de carimbo de tempo manualmente. O que importa é o ponto de integração da confiança. Uma TSA é algo que você configura e protege, porque o horário dela se torna a sua evidência.

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// Asking for any level at or above B-T requires a TSA.
$level = SignatureLevel::PAdES_B_T;
$level->requiresTimestamp(); // true → a Time-Stamp Authority must be supplied

// The TSA endpoint, its transport security, and its trust anchor are
// deployment-supplied. The engine sends a hash plus a fresh nonce — never the
// document — and verifies the returned token before the signature is accepted.
// A token that fails any check (status, nonce, imprint, signature, time)
// is a hard error, not a warning.

O ponto de integração importante é que o motor envia um hash, não o documento, de modo que a TSA nunca vê o seu conteúdo. E ele verifica a resposta. Uma TSA que você não consegue autenticar não é tempo confiável. Ela é apenas mais um relógio.

Equívoco comum

A armadilha é ler um carimbo de tempo como “isso foi assinado exatamente às 14:32 nesta data.” Ele não funciona como cronômetro do evento de assinatura. Ele comprova que os dados existiam no máximo até o horário da TSA, que é um limite superior definido por um terceiro. A criação pode ter ocorrido em qualquer momento antes disso. Uma segunda armadilha é supor que qualquer servidor de carimbo de tempo fornece tempo confiável a você. Um token cuja assinatura você não consegue verificar, ou em cuja autoridade você não confia, não comprova nada. É um relógio em que você não tem motivo para acreditar. O tempo confiável vem de uma TSA que você consegue autenticar e de um token que você verificou, não do ato de pedir um número a um servidor.

Limites e fronteiras

O NextPDF constrói a requisição, envia apenas um hash e verifica o token retornado. Ele não responde pela autoridade por trás dele. A precisão da TSA, a validade do certificado dela e a confiabilidade dessa TSA são propriedades do serviço e da configuração da sua implantação, não do motor. Um carimbo de tempo vincula um hash a um horário. Ele não diz nada sobre o significado dos dados, a identidade do signatário ou se o certificado do signatário era válido. Essas são verificações separadas, abordadas em Validando uma assinatura corretamente. O motor não pode tornar confiável uma TSA não confiável. Esta página também não afirma nenhum peso jurídico específico para um carimbo de tempo; isso depende do status da TSA e da jurisdição. A forma como o tempo confiável é reutilizado para manter uma assinatura verificável ao longo de décadas é abordada em Validação de longo prazo.

Disponibilidade do carimbo de tempo por edição:

RFC 3161 timestamping (signature timestamp and document timestamp) — edition availability
Edition	Availability
Core	Not in this edition
Pro	PAdES B-T — um carimbo de tempo RFC 3161 verificado sobre o valor da assinatura, contra uma TSA fornecida pela implantação.
Enterprise	Adiciona o carimbo de tempo de documento usado por B-LT e B-LTA para ancorar a evidência de validação incorporada e para conduzir o ciclo de renovação de arquivamento.

Documentos relacionados

Validação de longo prazo — como o carimbo de tempo de documento sela a evidência incorporada e é renovado ao longo do tempo.
Perfis de baseline PAdES — onde o carimbo de tempo de assinatura (B-T) e o carimbo de tempo de documento (B-LTA) se encaixam na progressão de níveis.
Assinaturas qualificadas, explicadas — onde um carimbo de tempo qualificado se encaixa no panorama de confiança do eIDAS.

Glossário

Carimbo de tempo (RFC 3161) — um token assinado de uma TSA que vincula um hash de dados ao horário da TSA, comprovando que os dados existiam antes desse horário.
Autoridade de Carimbo de Tempo (TSA) — o serviço confiável que emite tokens de carimbo de tempo.
TSTInfo — a estrutura de conteúdo do token: impressão de mensagem, horário de geração, número de série e nonce opcional.
Impressão de mensagem — o hash dos dados que recebem o carimbo de tempo, ecoado no token.
Nonce — um novo valor aleatório enviado com a requisição e ecoado no token, de modo que a resposta não possa ser uma repetição.
Carimbo de tempo de documento — um carimbo de tempo RFC 3161 sobre o PDF inteiro (conforme atualizado pela RFC 5816), ancorando a assinatura e a evidência dela em um instante confiável.