Resumo

  • No CTT, RFC 9921 pede ao TSA uma marca sobre os bytes codificados da assinatura COSE; no TTC, o TSA marca primeiro os bytes da carga, e a assinatura COSE vem depois.
  • O fato de um token TTC estar protegido pela assinatura posterior não altera o objeto que o TSA recebeu. Ele atesta a existência prévia da carga, não a criação prévia da assinatura.

O relatório de exceção usava um atalho comum: “o arquivo foi assinado antes do bloqueio do certificado”. A evidência anexada era uma assinatura COSE válida e um token de tempo válido, emitido antes da revogação. A frase parecia prudente porque os dois artefatos estavam no mesmo objeto final.

O objeto final, porém, não mostra por si só a sequência em que cada prova foi criada.

Uma organização pode obter na segunda-feira um TimeStampToken para o hash de uma carga. Na terça, o certificado do signatário pode ser revogado. Na quarta, esse signatário pode colocar o token no cabeçalho protegido e assinar o conjunto COSE. A assinatura de quarta protege o token e a carga contra alteração. O token de segunda continua válido. Ainda assim, o TSA de segunda não carimbou uma assinatura que só seria criada na quarta.

RFC 9921 foi escrito para tornar essa fronteira legível entre implementações COSE. Ele leva o mecanismo de RFC 3161 a COSE_Sign e COSE_Sign1, mas define duas composições diferentes, não uma data genérica para todo o documento. A seção de segurança proíbe exatamente a inferência que aceitaria uma assinatura feita após a revogação com base em um token antigo da carga.

A pergunta é: qual conjunto de bytes recebeu o carimbo?

Em COSE, Then Timestamp (CTT), a assinatura nasce primeiro. O solicitante calcula o hash do campo signature codificado em CBOR, no caso de COSE_Sign1, ou do campo signatures codificado em CBOR, no caso de COSE_Sign. O TSA emite o token para essa entrada. O token é colocado no parâmetro de cabeçalho não protegido 3161-ctt.

Isso cria evidência sobre a existência da própria assinatura. Depois de verificar a assinatura COSE, o token, o certificado e a política aplicável do TSA, o validador pode concluir, nos limites da política e da qualidade de tempo do TSA, que a assinatura já estava presente até a hora registrada. É o modo que RFC 9921 associa a assinaturas de longa duração, quando se precisa avaliar uma assinatura apesar de expiração ou revogação posteriores do certificado.

Em Timestamp, Then COSE (TTC), o TSA recebe primeiro o hash dos bytes da carga COSE. Não entram no MessageImprint o invólucro CBOR de string de bytes nem a assinatura ainda inexistente. O token volta no parâmetro protegido 3161-ttc; só então uma assinatura COSE cobre a carga e o cabeçalho protegido.

TTC é particularmente útil quando a organização precisa manter juntos uma declaração e um registro de que seu conteúdo já existia. RFC 9921 o usa no fluxo de transparência/notarização: o token pode ficar dentro da parte assinada de uma declaração antes de ela ser registrada em um log append-only. A escolha preserva uma evidência importante. Não transforma, contudo, a prova de existência da carga em prova de que a assinatura estava pronta na mesma hora. Inclusão no log, consistência do log, identidade do emissor, estado de revogação e política do destinatário continuam sendo verificações próprias.

Cabeçalho protegido não é uma máquina do tempo

No TTC, “protegido” tem um significado útil e limitado. Uma alteração posterior no token quebra a assinatura COSE. O campo não diz que o token, quando emitido, já continha ou cobria uma assinatura COSE. A assinatura ainda não existia no momento da solicitação ao TSA.

No CTT, ocorre o inverso por necessidade cronológica. A assinatura COSE é criada antes do token; por isso não consegue cobrir retroativamente esse token. RFC 9921 reconhece que o 3161-ctt não protegido pode ser removido ou substituído. A defesa exigida está ao lado do objeto: proteção de integridade do COSE Signed Message durante transporte e armazenamento.

Esse detalhe precisa aparecer no desenho de custódia. O repositório deve manter o hash do objeto completo, o modo, os bytes usados na impressão, certificado e política do TSA, evidência de estado de certificados e o mecanismo que preservou a associação assinatura-token. Se uma migração retirar o token CTT, a conclusão correta é que a prova de tempo histórico foi perdida. Não é aceitável herdar automaticamente o status de aprovação de uma versão anterior.

A data só entra na decisão depois da validação de escopo

RFC 3161 descreve um TSA que carimba uma representação em hash, sem interpretar o conteúdo do dado. Quem recebe o token precisa verificar status da resposta, identidade e certificado do TSA, impressão solicitada, algoritmo, atualidade por nonce ou fonte local confiável, estado do certificado do TSA e aceitação da política. genTime é a hora em que o TSA produziu o token; precisão, resolução, latência e política delimitam o alcance da alegação.

RFC 9921 acrescenta a prova de ligação: recomputar a MessageImprint incorporada sobre os bytes exigidos pelo modo. Em CTT são os bytes do campo de assinatura; em TTC são os bytes da carga. Um token CMS encontrado no pacote, mesmo válido, não basta. Uma verificação de CMS sem a comparação da impressão não prova a relação que a política pretende usar.

Daí a sequência operacional: classificar CTT ou TTC; validar COSE; validar TSA e sua política; recomputar a entrada correta; aplicar a conclusão temporal correspondente; e, se houver transparência, verificar separadamente o log e a regra do relying party. O princípio de código em execução de Heng Lu desloca a atenção para esse caminho real. O selo na tela, a verificação criptográfica e a autorização que produz efeito são camadas diferentes e devem permanecer auditáveis como tais.

Sources