Resumo

  • Em 2 de setembro de 2026, o IESG abriu o Last Call da revisão 29 de Use of Remote Attestation with Certification Signing Requests, até 16 de setembro. O texto pretende chegar a Proposed Standard, mas ainda é Internet-Draft, não RFC aprovado nem prova de uso em produção.
  • O pacote permite transportar várias atestações em um pedido PKCS #10 ou CRMF. Cabe ao CA/RA demonstrar que chave pública, HSM, propriedade, condição da plataforma e contexto de frescor pertencem à mesma transação de inscrição.

O exemplo central da revisão 29 deveria soar como um alerta para qualquer autoridade certificadora. Uma declaração confirma que a chave nasceu em um HSM. Outra confirma que uma plataforma pertence à empresa. Uma terceira confirma que uma plataforma está em condição conhecida como boa. As três podem estar certas e, ainda assim, descrever três máquinas.

O rascunho padroniza um envelope enxuto. AttestationStatement reúne um OID de tipo e o conteúdo da declaração. AttestationBundle contém uma ou mais declarações e pode incluir certificados. Um único bundle de nível superior segue no pedido sob id-aa-attestation, como atributo PKCS #10 ou extensão CRMF.

Esse envelope resolve transporte, não atribuição. Certificados opcionais podem apoiar a construção de um caminho de validação. Sua presença não determina ordem de autoridade, âncora de confiança adequada ou política de emissão. Ler o bundle, validar uma cadeia e autorizar o certificado são atos independentes.

O rascunho não define os formatos internos nem cria um novo registro para eles. Outros padrões ou fornecedores definem formato e OID. Por isso, o OID é uma etiqueta de roteamento, não um selo de verdade. Decodificar não é validar assinatura; assinatura válida não escolhe confiança; confiar no emissor não prova que sua afirmação se refere à chave pública examinada.

O roteamento fica ambíguo quando mais de um Verifier aceita o mesmo OID. O texto sugere OID distintos ou uma indicação de wrapper definida pelo formato. A indicação precisa estar autenticada. Fora da proteção criptográfica, uma falha de integração ou manipulação pode levar a evidência ao Verifier mais permissivo.

A cadeia começa na chave pública do CSR. A proof of possession demonstra controle da chave privada no protocolo de solicitação. Ela não prova onde a chave foi criada, se pode ser exportada, quem possui o hardware, se a plataforma está saudável ou se o requerente tem direito ao certificado.

A declaração do HSM reduz apenas uma dessas incertezas. O CA/RA ainda precisa ligar o HSM à plataforma por um identificador estável. O registro de propriedade deve descrever essa mesma plataforma e cobrir o momento relevante. A medição precisa apontar para o mesmo objeto, com época e valores de referência identificados. Nomes parecidos ou fornecedor comum não bastam.

Frescor limita replay, mas não produz identidade. O rascunho complementar mantém nonce e CSR no mesmo contexto operacional: CMP pode usar o contexto da transação; EST, a mesma sessão TLS ou estado HTTP preservado. Se o CA/RA não consegue associar o CSR ao intercâmbio anterior, não deve tratá-los como ligados.

Quando solicitado, o nonce tem de 8 a 64 octetos; comprimento zero indica que frescor não foi pedido. Um Attester principal pode distribuir o mesmo desafio a Attesters subordinados. Várias Evidence respondem então a um intervalo comum, sem demonstrar que descrevem a mesma chave ou plataforma.

RFC 9334 também separa frescor de permanência. A propriedade, o software ou a condição de segurança podem mudar logo após a produção da evidência. A medição pertence a uma época; o certificado costuma permanecer válido por mais tempo.

A decisão consequente continua com o CA/RA. Ele escolhe formatos aceitos, âncoras, valores de referência, regras de avaliação e perfil de emissão. Pode comparar o pacote com uma política entre várias ou descartar a informação se ela não for pertinente. O rascunho recomenda registrar os requisitos na certification practice statement.

A versão dessa política faz parte da prova operacional. Um registro reproduzível guarda hash e chave do CSR, bytes das declarações, signatários, versões dos Verifiers, referências, nonce e contexto, registro de propriedade, avaliação, política aplicada e ator que autorizou a emissão.

Esse dossiê não deve virar conteúdo público do certificado. Identidade de hardware, firmware, patches, propriedade e estado de cadeia de fornecimento podem ser sensíveis. A revisão 29 desaconselha copiar a atestação para o certificado. Logs de inscrição, bundles armazenados e registros dos Verifiers continuam sendo superfícies de privacidade.

As camadas de realidade de Heng Lu impedem que um recibo ocupe o lugar do seguinte. Existência do rascunho, sintaxe correta, assinatura válida, avaliação positiva, emissão, implantação e aceitação são fatos separados. O padrão coordena o envelope; o CA/RA precisa preservar a execução que transforma evidência em decisão.

Fontes