Resumo

  • O draft-ietf-lamps-csr-attestation-29 permite que uma CA ou RA verifique declarações adicionais conforme sua política de emissão ou simplesmente as descarte sem processá-las.
  • Como o próprio texto desaconselha copiar dados sensíveis de atestação para o certificado público, o certificado não prova qual avaliação privada ocorreu. Um recibo de evidência de emissão, protegido e mínimo, poderia ligar o CSR exato à avaliação e ao certificado resultante.

O resultado público chega depois da decisão importante

O IETF abriu em 2 de setembro o Last Call do rascunho do grupo LAMPS, com comentários até 16 de setembro, segundo o anúncio oficial. A página no Datatracker mostra a revisão 29 em avaliação, com revisão ARTART designada em 6 de setembro e indicação de que é necessária análise da IANA. O histórico do documento não registra aprovação como RFC.

A proposta acrescenta informações de atestação a pedidos baseados no PKCS #10 e no CRMF. O AttestationBundle carrega uma ou mais declarações e, opcionalmente, certificados auxiliares. Pelo menos uma declaração deveria conter uma atestação criptograficamente vinculada à chave pública do CSR.

Essa capacidade de transporte não determina a decisão. O texto da revisão 29 diz que CA ou RA pode verificar as atestações para aplicar sua política de emissão, ou descartá-las sem qualquer processamento. Se aceitar ou exigir atestações, a CA deveria documentar a prática em sua CPS. Logo, dois emissores podem receber o mesmo contêiner e atribuir a ele pesos completamente diferentes.

A junção é mais difícil do que a validação isolada

Mesmo declarações válidas podem falar de componentes distintos. A autoridade precisa estabelecer que a chave, a plataforma, o dispositivo e o estado medido pertencem à mesma solicitação. O rascunho deixa com CA ou RA a responsabilidade final por essa vinculação e pelas junções entre várias declarações. Também admite ignorar evidência antiga ou inconclusiva.

A distinção acompanha a arquitetura RATS da RFC 9334, que separa Evidence, Appraisal Policy e Attestation Result. Um rascunho paralelo sobre frescor examina mecanismos para provar quando a evidência foi produzida. O fato de existir esse trabalho mostra por que um pacote assinado não resolve sozinho a atualidade do estado alegado.

A comparação entre as revisões 28 e 29 ajuda a identificar ajustes antes do Last Call. Ela não sustenta a afirmação de que a revisão 29 inventou a opção central entre avaliar e descartar: a revisão 28 já continha a mesma fronteira operacional.

Preservar a decisão sem publicar o dispositivo

Atestações podem expor hardware, nível de correção, propriedade ou outros dados operacionais. Por isso, o rascunho não recomenda copiá-las para um certificado que será público e orienta remover informações sensíveis se houver republicação. Essa cautela preserva a função do certificado e reduz a criação de um inventário mundial de dispositivos.

Mas confidencialidade não exige amnésia institucional. Um recibo mínimo de evidência de emissão poderia guardar o hash do CSR canônico, o hash do conjunto avaliado, a política e a versão usadas, o resultado de frescor, as vinculações de chave e plataforma, exceções autorizadas, o fingerprint do certificado e o instante da decisão. A evidência bruta permaneceria em armazenamento segregado, com acesso e retenção limitados.

Esse recibo é uma proposta analítica de Daniel Kade, não uma exigência do IETF, do CA/Browser Forum ou de alguma CA ou RA. Os requisitos de assinatura de código do CA/Browser Forum oferecem contexto de governança de certificados, mas não comprovam adoção desse mecanismo nem devem ser apresentados como se fossem parte do rascunho LAMPS.

Fontes