O certificado expirava em 9999. O vínculo com o documento podia passar sem verificação.

Resumo

• O rascunho One Signature Certificates do LAMPS associa um certificado a uma entrada de assinatura por meio de signedDocumentBinding, mas permite que a validação criptográfica comum termine com sucesso sem conferir esse vínculo. “Assinatura válida” e “dataTbsHash correspondente” são recibos diferentes.
• O certificado também declara que a chave privada nasceu exclusivamente para aquele documento, foi usada uma vez e destruída logo depois. Essa é uma afirmação processual da autoridade certificadora, não uma observação produzida pela extensão. Retirar expiração e revogação reduz uma carga operacional, mas transfere a confiança de longo prazo para política, provas preservadas e futura configuração de confiança.

O campo notAfter aponta para o último segundo de 9999. noRevAvail informa que não existe mecanismo de revogação. signedDocumentBinding contém um hash destinado a um documento. A assinatura convencional é aceita.

Qual desses fatos prova que o aplicativo verificou o vínculo com o documento? Nenhum.

A revisão 02 de One Signature Certificates explicita a separação. Ela define um certificado criado na hora da assinatura para uma chave recém-gerada, empregada numa única assinatura digital e imediatamente destruída. O certificado é vinculado ao conteúdo assinado, não tem uma expiração operacional e não depende de serviço de revogação. A proposta procura simplificar validações futuras, reduzindo a chave persistente e o estado de revogação acumulados por certificados reutilizáveis.

Trata-se de um Internet-Draft do grupo LAMPS, no fluxo IETF, destinado ao nível Proposed Standard. A revisão 02 é de 1º de julho de 2026 e expira em 2 de janeiro de 2027. O Datatracker a mostra como documento do grupo, com estado IESG I-D Exists. Não é RFC nem prova de implantação, emissão real, destruição efetiva da chave ou preservação de validade em arquivo.

Um certificado reúne afirmações de naturezas distintas

A extensão proposta chama-se signedDocumentBinding. Seu valor ASN.1 reúne dataTbsHash, hashAlg e o bindingType opcional. O hash identifica os dados que serão assinados; o tipo descreve como se extraiu essa sequência de bytes do formato que envolve o documento.

Uma parte pode ser reproduzida: o verificador reconstrói a entrada, calcula o resumo e compara. Outra depende do procedimento da AC. O hash não mostra se o serviço realmente gerou uma chave nova, bloqueou um segundo uso, apagou todas as cópias e seguiu sua política. Ao inserir a extensão, a AC autentica uma declaração sobre esses controles. A revisão 02 recomenda que o procedimento e o nível de garantia da destruição apareçam na política de certificação.

Um recibo durável deve separar o valor da extensão, a entrada exata, o resultado do digest, a versão da CP/CPS, o evento de emissão, a geração da chave, a única autorização de assinatura e a evidência de destruição. Reduzir tudo a “certificado de uso único válido” impede saber, numa auditoria futura, qual elo realmente foi comprovado.

A assinatura pode passar sem o vínculo

As considerações de segurança dizem expressamente que verificar signedDocumentBinding não é requisito para a validação criptográfica bem-sucedida da assinatura. Uma biblioteca pode processar o formato e a chave pública corretamente; o aplicativo pode transformar esse retorno em aprovação sem executar a comparação adicional. O relying party deveria comparar o conteúdo assinado com dataTbsHash, porque é essa etapa que impõe o escopo de um documento e reduz substituição do certificado ou reutilização não pretendida.

A interface de decisão precisa expor ao menos dois estados. signature_valid registra o resultado primitivo e do formato. document_binding_match registra tipo de vínculo, bytes reconstruídos, algoritmo de hash, valor esperado e comparação. Se a segunda operação não ocorreu, o estado é not_checked, jamais passed e jamais uma propriedade implícita do primeiro resultado.

Transformar o SHOULD do rascunho numa obrigação local é uma escolha de perfil. Quem depende da restrição a um documento precisa demonstrar que a regra alcança revalidação de arquivos, processamento em lote, aplicativos móveis e serviços externos, e não apenas o caminho feliz do sistema principal.

O tipo de vínculo decide quais bytes formam o documento

Quando bindingType está ausente, o padrão calcula o hash da entrada exata do algoritmo de assinatura: SignedInfo no XML, SignedAttributes codificados em DER no CMS, ou a estrutura equivalente. O problema aparece quando essa entrada inclui o próprio certificado ou um hash dele. O dataTbsHash vive no certificado; calcular um objeto pode depender do outro. A revisão 02 proíbe o padrão nesses casos circulares e define exclusões específicas.

No CAdES, usa-se o SignerInfo em DER depois de retirar SigningCertificate e SigningCertificateV2. No XAdES, usa-se SignedInfo canonicalizado depois de retirar referências do tipo SignedProperties, preservando todos os demais caracteres, espaços e quebras de linha. JWS e COSE vinculam apenas o payload e excluem cabeçalhos protegidos e não protegidos.

Assim, o mesmo documento visível pode produzir dataTbsHash diferente conforme o tipo. Um payload JWS correspondente não prova que o cabeçalho protegido, identificador de chave, algoritmo ou referência ao certificado são os mesmos. Esses elementos permanecem sob a validação normal de JWS e a política do aplicativo. O recibo deve guardar formato, identificador, regra de canonicalização ou exclusão, versão da implementação e hash dos bytes reconstruídos.

Ausência de revogação não comprova destruição

O rascunho recomenda notAfter igual a 99991231235959Z e a extensão id-ce-noRevAvail da RFC 9608. O primeiro indica que não há expiração bem definida; o segundo informa que não existe informação de revogação para o certificado. Nenhum explica por que revogação seria desnecessária.

O argumento depende do modelo: se a chave existiu brevemente, assinou uma vez e foi destruída, eventos posteriores de revogação não deveriam alterar a validade daquele ato já registrado. Uma chave reutilizável abre exposição futura; uma chave de fato destruída reduz essa superfície. Mas o risco muda para o registro de criação. A chave era nova? Houve só uma solicitação autorizada? Backup, log, dump, replicação do HSM ou tentativa automática conservaram cópia? A destruição terminou antes de uma eventual invasão?

noRevAvail apenas instrui o verificador a não esperar CRL ou OCSP. Não responde às perguntas. O sistema deve distinguir “sem revogação por desenho”, “serviço de revogação indisponível” e “perfil desconhecido”.

A hora de emissão amplia a autoridade temporal da AC

A validação duradoura costuma precisar de uma melhor hora da assinatura: a primeira evidência confiável de que ela existia. A RFC 3161 oferece um modelo com autoridade de carimbo do tempo independente. A revisão 02 argumenta que o certificado de assinatura única é emitido na hora do ato; por isso, sua emissão estabelece a hora da assinatura e a AC assume papel semelhante ao de uma autoridade temporal.

Essa integração é eficiente, mas aumenta o que a AC precisa provar. Ela não atesta apenas identidade e chave pública; afirma quando aconteceu o único ato, a quais bytes ele pertenceu, que a chave foi criada para ele e que foi destruída imediatamente. O operador deve registrar se a melhor hora veio da emissão, de um carimbo RFC 3161, de um token de validação, de evidência de arquivo ou de vários desses elementos. Um notBefore sintaticamente válido não deve virar prova temporal independente por conveniência.

O ano 9999 não torna a AC imortal

O próprio rascunho limita a promessa do certificado final sem expiração. A validação continua dependendo da confiança na AC emissora. A primeira validação é presumida durante a validade do certificado da AC. Depois disso, o verificador talvez tenha de manter a chave da AC como trust anchor local, usar certificação cruzada, buscar certificados renovados ou adotar outro mecanismo. A provisão futura de confiança está fora do escopo do documento.

Portanto, remover a expiração do certificado final não preserva o caminho até 9999. Algoritmos envelhecem, trust stores mudam, políticas são substituídas, autoridades fecham ou trocam chaves, arquivos migram e software desaparece. Bytes originais, cadeia, política, tempos confiáveis, evidência de validação e histórico dos anchors precisam continuar recuperáveis.

Mesmo um vínculo plenamente conferido prova uma relação estreita: este certificado foi emitido para esta entrada reconstruída, sob este hash e esta regra. Não prova que o signatário entendeu o documento, tinha poderes para o negócio, viu a apresentação final ou causou o efeito externo prometido. Sintaxe, cadeia de confiança, matemática, vínculo, procedimento da AC, ciclo da chave, tempo, identidade, autorização, decisão do aplicativo e resultado real precisam continuar tipados separadamente.