O que é um selo temporal qualificado: RFC 3161 e o artigo 42.º do eIDAS

Um token temporal é uma declaração assinada de uma autoridade temporal: o hash deste token existia nesta hora. A RFC 3161 chama-lhe prova da existência — indica que os dados existiam antes de uma hora determinada. Nada no token anuncia a quem pertencem os dados: por conceção, a autoridade assina apenas o resumo que recebeu.

O selo temporal eletrónico qualificado, definido no artigo 3.º, n.º 34, do eIDAS, é um selo que cumpre o artigo 42.º; nos termos do artigo 41.º, n.º 2, beneficia da presunção da exatidão da data e da hora que indica e da integridade dos dados aos quais a data e a hora estão associadas. É essa presunção que o eleva acima de um selo não qualificado numa discussão jurídica.

policy: um identificador de objeto que indica as condições de utilização do token — é também assim que um revisor posterior descobre que política se aplicava. Sim, isso é política; o token regista qual.

messageImprint: o hash submetido pelo cliente, e o token de resposta tem de trazer o mesmo valor do pedido. É isto que torna a vinculação mecânica: o token não descreve os dados, está criptograficamente atado exatamente aos dados que enviou.

serialNumber: um número inteiro único da autoridade emissora — a RFC 3161 exige que os utilizadores estejam preparados para números até 160 bits, e diz que o nome da autoridade mais este número identificam um token único. genTime: a hora de criação do token, expressa em UTC.

nonce: se o cliente enviar um nonce, o servidor tem de o devolver inalterado na resposta — é o único campo opcional que a RFC 3161 exige que as implementações suportem. Amarra a resposta a este pedido exato. tsa: o nome da autoridade, transportado opcionalmente.

O token contém exatamente uma assinatura: a da TSA. O identificador do certificado da própria TSA (ESSCertID) tem de viajar dentro dos atributos de assinatura do token — um validador identifica qual chave assinou o token sem adivinhar.

O dever do imprint corre numa direção: os bytes submetidos é que recebem o token, e a resposta tem de os repetir. Um token sobre outro resumo falha à vista de todos — é assim que a autoridade não pode ligar silenciosamente outra coisa.

O artigo 42.º, n.º 1, fixa três requisitos. Primeiro, o selo tem de vincular a data e a hora aos dados de forma a tornar razoavelmente impossível a alteração dos dados de forma não detetável — a metade de integridade da alínea d) do artigo 26.º, aplicada ao selo. Segundo, tem de se basear numa fonte horária precisa ligada à Hora Universal Coordenada. Terceiro, tem de ser assinado ou selado pelo prestador qualificado de serviços de confiança.

O artigo 42.º, n.º 2, acrescenta a presunção das normas: quando a vinculação e a fonte horária seguem normas referenciadas num ato de execução da Comissão, presume-se a conformidade. O artigo 41.º, n.º 3, fecha o quadro: um selo temporal qualificado emitido num Estado-Membro é reconhecido como selo temporal qualificado em todos os Estados-Membros.

Não assina. Ninguém aceitou nada por possuir um hash dos seus dados — a autoria e o consentimento vivem na assinatura e na evidência da cerimónia, não no selo.

Não olha para o futuro. Um selo certifica o que existia antes do seu genTime; sobre o que vem depois não diz nada. Provar que o conteúdo é o mesmo anos mais tarde é trabalho do nível da assinatura (B-LT e B-LTA), não do selo sozinho.

Não é notarização. Nenhum selo certifica que os dados são verdadeiros; certifica existência antes de uma hora. Se o conteúdo está certo é assunto do documento e dos seus leitores, não da autoridade.