Resumo

  • RFC 3029 permitia que o serviço de validação fosse executado corretamente e produzisse um DVC assinado cujo resultado dizia que o objeto era inválido.
  • O certificado preservava requisição ou impressão digital, tempo, número de série, política, estado coletivo e detalhes; cabia ao consumidor verificar a resposta e decidir seu alcance.

Certificado costuma soar como aprovação. O Data Validation Certificate de RFC 3029 tinha função mais rigorosa: registrar, com assinatura, o que um servidor concluiu sob determinadas regras. Um resultado negativo não era defeito do recibo. Podia ser sua informação mais importante.

O RFC afirma que DVCSCertInfo resulta da execução bem-sucedida do serviço e logo alerta que isso não significa sucesso da validação. A requisição pode ser processada, a resposta pode ter assinatura autêntica e o objeto pode falhar. Misturar esses três fatos transforma “o servidor respondeu corretamente” em “o objeto está correto”, exatamente o salto que o formato evitava.

Quatro serviços observavam fatos diferentes

No cpd, os dados reais eram apresentados, permitindo certificar que o solicitante os possuía naquele momento. No ccpd, só uma impressão digital era enviada; o servidor via a alegação ligada ao resumo, não os bytes originais. Prova de uma impressão não podia ser promovida a prova de entrega do conteúdo.

O vsd examinava documentos assinados, incluindo correção matemática, certificados, estado e caminhos de confiança. O vpkc tratava de um ou mais certificados em horário especificado. CRL, OCSP, diretórios e outros DVCS podiam fornecer insumos, mas RFC 3029 dizia que o serviço não substituía CRL e OCSP em ambientes abertos de grande escala.

As quatro saídas tinham aparência semelhante e semântica distinta. Dados apresentados, resumo apresentado, documento assinado aceito e certificado aceito não eram o mesmo evento.

O envelope assinado guardava as condições

O DVC era CMS SignedData. Reunia informações da requisição, messageImprint, número de série crescente, tempo de resposta, política, estado coletivo e resultados por certificado ou assinatura. Um tempo vindo de serviço externo precisava ser validado pelo próprio DVCS.

O cliente não devia apenas verificar a assinatura externa. Precisava conferir tempo, nome do servidor, referência à requisição, impressão, assinatura, estado, serviço e política, além da validade do certificado de assinatura do DVCS. Uma resposta assinada para outra impressão respondia a outra pergunta. Uma política não aceita pelo consumidor não ganhava autoridade pela criptografia.

A política explicava resultados diferentes para o mesmo objeto. Raízes, fontes de revogação e limiares de assinatura podiam mudar. O DVC não proclamava validade universal; registrava que um servidor, em um momento, segundo uma política, chegou a um resultado para uma impressão específica.

O estado coletivo dependia dos elementos

Num conjunto de certificados, falha coletiva exigia identificar o elemento que falhou. Num documento com várias assinaturas, uma assinatura ruim não precisava derrubar o todo se a política aceitasse um conjunto suficiente; o resultado podia ser grantedWithMods. O inverso também era possível: assinaturas corretas individualmente podiam ser insuficientes para a regra global. granted só cabia quando todas eram verificadas.

WAITING indicava ausência de resposta final, não aprovação provisória. O resumo era consequência da política, nunca substituto dos detalhes.

Negação assinada e erro sem autoridade

Se o serviço fosse executado, um DVC assinado podia declarar o objeto inválido. Se formato ou autenticação impedissem a execução, surgia uma notificação de erro. O primeiro caso respondia “não”; o segundo não alcançava o mérito.

Quando o DVCS não conseguia produzir assinatura válida, como diante de chave sabidamente comprometida, RFC 3029 previa estrutura sem informação de signatário. O cliente devia tratá-la como erro crítico e fatal e não confiar implicitamente no texto. Um veredito negativo assinado é evidência atribuível; um erro sem assinatura é falha da própria autoridade de resposta.

RFC 3029 foi publicado em fevereiro de 2001 como Experimental, não como Internet Standard. RFC 3379 e RFC 5055 depois trataram de requisitos e protocolo de validação delegada. Eles não demonstram adoção do DVCS. A contribuição histórica permanece no modelo: terceirizar o cálculo não terceiriza automaticamente a decisão do aplicativo.

Fontes

Lu Heng não escreveu nem endossou RFC 3029 ou os padrões PKIX relacionados. Seus ensaios aparecem como lentes analíticas explicitamente declaradas.