Resumo

  • RFC 5276 ajuda um verificador a recuperar certificados, caminhos e dados de revogação acompanhados por EvidenceRecords, mantendo a relação com os bytes devolvidos pelo SCVP.
  • Mesmo com todos esses materiais verificados, a aplicação precisa confirmar a assinatura do arquivo, escolher sua política e suas âncoras e registrar a autorização e o resultado separadamente.

Um arquivo antigo é recuperado. A plataforma de preservação confirma seu hash. Um servidor SCVP devolve o caminho do certificado que deveria validar a assinatura na data de interesse. O caminho vem acompanhado de EvidenceRecords, e as renovações de carimbo de tempo estão em ordem.

Nesse ponto, muitos fluxos encerrariam o caso com “validado”. RFC 5276 descreve um ponto intermediário, não o fim. O cliente ainda precisa processar a resposta, verificar os EvidenceRecords e verificar a assinatura do material arquivado usando o certificado validado. Depois disso, a aplicação decide se aquela assinatura autoriza a ação que está sendo pedida.

O documento técnico é valioso porque separa o transporte de evidência da decisão. Ele permite que cada passagem seja testada, em vez de transformar a reputação do arquivo ou do validador em substituto para execução verificável.

A sequência começa no item arquivado

O modelo operacional de RFC 5276 parte de um item assinado recuperado de um arquivo de longo prazo. O cliente prepara uma solicitação SCVP para validar o certificado do signatário na data relevante e pede EvidenceRecords para os materiais de PKI necessários. O servidor devolve o status e as provas. O cliente processa a resposta e, só então, verifica a assinatura do item arquivado.

Essa ordem impede um atalho comum. Um certificado validado não prova que o item possui uma assinatura feita com a chave correspondente. Pode haver um certificado correto ao lado do arquivo errado, uma assinatura sobre outros bytes ou uma referência que perdeu o vínculo ao longo de uma migração.

O recibo inicial deve, portanto, identificar os bytes do item, sua assinatura, o certificado efetivamente usado e a relação entre eles. O caminho SCVP entra depois para sustentar o certificado sob uma política. A autorização de negócio entra depois para interpretar a assinatura em um contexto.

Se uma plataforma registra apenas o resultado SCVP, ela preserva uma resposta sobre um certificado e deixa implícita a pergunta mais importante: esse era mesmo o certificado da assinatura que motivou a decisão?

Cada WantBack exige uma associação verificável

SCVP permite solicitar informações adicionais por meio de WantBacks. RFC 5276 acrescenta pedidos de EvidenceRecord para certificado individual, caminho completo, caminho parcial e informações de revogação.

O EvidenceRecord de um caminho cobre o CertBundle DER devolvido no campo correspondente. Para um certificado individual, cobre o valor do certificado em CertReply. Para revogação, cada CRL ou resposta OCSP deve estar coberta por uma prova identificável. A forma agregada usa targetWantBack para indicar o tipo de resposta associado e exige correspondência um a um.

Isso transforma uma coleção de blobs em um mapa. O verificador pode mostrar qual prova cobre qual retorno. Sem esse mapa, um EvidenceRecord válido poderia ser apresentado como cobertura de material diferente, simplesmente por estar armazenado no mesmo pacote.

Quando a prova não está disponível, o padrão preserva a falta. O valor fica vazio ou o campo é omitido para aquele alvo. Quando o cliente pede a prova sem pedir o material subjacente, a solicitação fica insatisfeita. Nenhum desses casos, sozinho, declara o certificado inválido; informa que a etapa de preservação não foi cumprida como solicitada.

Economizar caminho aumenta a obrigação de montagem

Um caminho completo inclui o certificado final até a âncora. Um caminho parcial começa na autoridade que emitiu o certificado final. O próprio item arquivado pode carregar o certificado do signatário e protegê-lo com sua evidência.

O modelo parcial reduz duplicação: vários itens de uma mesma época reutilizam o trecho de CA até a âncora. Operacionalmente, porém, cria uma junção entre dois domínios de custódia. No futuro será necessário provar que o certificado final veio com o item, que a assinatura confere, que o emissor se conecta ao caminho parcial e que a revogação cobre a janela correta.

Essa obrigação deve ser registrada no momento da ingestão. Guardar “caminho parcial 27” não basta. É preciso registrar hashes, relações, política e localização do certificado final. Caso contrário, a economia de hoje vira uma investigação impossível amanhã.

A política SCVP precisa viajar com o resultado

RFC 5055 permite que o cliente escolha política de validação, horário, âncoras, usos de chave, usos estendidos e parâmetros de revogação. Também pode aceitar padrões publicados pelo servidor. O resultado só tem significado dentro dessas entradas.

Se a organização pretende demonstrar depois qual política completa foi usada, deve preservá-la por valor ou manter uma referência estável com os parâmetros efetivos. O nome de uma política que mudou de conteúdo não reconstrói uma decisão antiga.

RFC 5280 reforça a fronteira: a âncora de confiança é entrada do algoritmo, aplicações diferentes podem escolher âncoras diferentes e uma aplicação pode limitar ainda mais os caminhos aceitos. Um caminho tecnicamente válido não é uma permissão universal.

RFC 5276 exige ainda que a assinatura da resposta SCVP seja verificada por uma chave pública confiável para quem depende da resposta. Âncoras carregadas dentro da resposta podem ser usadas ou ignoradas. Se a resposta não for assinada, suas âncoras não devem ganhar confiança apenas por estarem presentes.

Portanto, a aplicação não recebe uma ordem. Recebe evidência autenticada sob condições declaradas. Sua própria política determina se isso basta para o uso pretendido.

O passado pode receber uma correção tardia

O campo validationTime permite perguntar sobre o estado de um certificado no passado. Isso evita tratar o vencimento atual como prova de que a assinatura antiga era inválida. O servidor precisa ter informação histórica adequada; se não tiver, deve retornar erro.

Mas uma resposta afirmativa pode ser ultrapassada. RFC 5055 observa que uma revogação conhecida mais tarde pode trazer invalidityDate anterior à data consultada. A primeira resposta continua sendo evidência autêntica do que o servidor afirmou com o conhecimento disponível, mas não deve continuar controlando a decisão atual.

O sistema precisa registrar tanto o tempo do fato quanto o tempo do conhecimento. Uma trilha de supersessão mostra quando nova CRL, resposta OCSP ou política modificou a conclusão. Apagar a resposta antiga destrói o histórico; ignorar a nova informação transforma preservação em cegueira.

Nonce e autenticação de resposta também importam. Sem comparar o nonce ou verificar assinatura/MAC, o cliente pode aceitar resposta repetida ou modificada. A custódia começa na aquisição, não no primeiro backup.

A evidência envelhece em ritmos próprios

RFC 4998 usa carimbos de arquivo, cadeias e sequências. Antes que a credencial ou algoritmo de assinatura de um carimbo deixe de ser seguro, um novo carimbo cobre o anterior. Se o hash da árvore se enfraquece, uma renovação de árvore cobre provas antigas e dados sob um novo algoritmo.

Isso exige calendário operacional. Cada cadeia tem um próximo ponto de intervenção. Um serviço que apenas guarda o EvidenceRecord, mas não acompanha a política criptográfica, pode manter todos os bytes e perder a continuidade probatória.

O campo cryptoInfos pode guardar certificados, revogação, âncoras ou avaliações de algoritmos, mas não fica protegido por carimbo de tempo. Essas informações precisam de verificação externa. Estar junto da prova não é o mesmo que estar coberto por ela.

Os cinco recibos de uma decisão

Uma implantação clara pode organizar o fluxo em cinco recibos:

  1. custódia: quais bytes e assinatura foram recuperados;
  2. vínculo: qual certificado verifica aquela assinatura;
  3. validação: qual política, tempo, âncora e informação de revogação produziram o resultado SCVP;
  4. preservação: qual EvidenceRecord cobre cada certificado, caminho ou resposta de revogação e como a cadeia foi renovada;
  5. consequência: qual aplicação autorizou qual ação e qual resultado foi observado.

Cada recibo pode falhar sem falsificar os demais. O arquivo pode estar íntegro e a assinatura não conferir. A assinatura pode conferir e a política recusar a âncora. O caminho pode ser aceito e o EvidenceRecord estar ausente. Tudo pode ser válido e a aplicação ainda negar o uso por falta de autoridade de negócio.

Essa decomposição é mais econômica do que um selo universal porque permite reparo localizado. Ela também deixa explícito o que RFC 5276 não afirma: nenhum produto, operador, implantação, resultado jurídico ou adoção real é provado pela publicação do padrão.