Resumo

  • O IESG aprovou draft-ietf-acme-device-attest como Proposed Standard em 30 de julho de 2026. A revisão 10 está na fila do RFC Editor; não há aqui alegação de RFC final ou adoção.
  • device-attest-01 pode conciliar o identificador do Order, a chave atestada e a chave do CSR. A força depende do formato, da autoridade e da cobertura do token sozinho ou da key authorization ligada à conta.
  • A evidência autoriza uma emissão. Ela não atualiza a saúde do equipamento, e a emissão com privacidade pode omitir do CSR e do certificado qualquer identidade física.

Um recibo com escopo

Um certificado válido costuma receber uma descrição maior do que seu conteúdo: “veio de um dispositivo confiável”. A frase não informa qual challenge foi concluído, qual autoridade sustentou a alegação, se a chave da conta participou ou quanto tempo passou desde a observação da postura.

A extensão aprovada cria permanent-identifier, para uma identidade geralmente atribuída pelo fabricante, hardware-module, para tipo e número do módulo criptográfico, e o challenge device-attest-01. A IANA já exibe os registros com referência RFC-to-be. Registro e aprovação são fatos; implementação e saúde operacional ainda precisam de prova própria.

O servidor envia um token novo. No caminho comum, o cliente o combina com a impressão da chave da conta ACME e obtém uma atestação da key authorization. O servidor verifica formato, valor coberto e identificador. Para emitir, precisa ainda ligar uma autoridade aceita, a mesma chave pública na atestação e no CSR, e o mesmo identificador na atestação e no Order. Quando o identificador entra no certificado, a igualdade deve ser byte a byte.

Alguns formatos externos assinam antes que a chave da conta esteja disponível. Eles cobrem só o token. Isso preserva frescor, não o vínculo à conta. Tratar os dois casos como um único attested=true elimina uma diferença de segurança.

Oferecer não é executar

Uma authorization pode oferecer device-attest-01 e outro challenge. A conclusão de qualquer um pode satisfazê-la. A flexibilidade ajuda frotas mistas, mas exige guardar o caminho realmente concluído.

External Account Binding controla quais contas empresariais entram. Não prova que a chave do CSR pertence ao hardware declarado. A atestação, por sua vez, não torna eterna a autorização daquela conta. Se o serviço concede privilégios adicionais a emissões atestadas, deve receber um comprovante autenticado do challenge, formato, autoridade e vínculo usados.

A identidade física pode não sair da CA

A revisão 10 permite omitir esses identificadores do CSR. Um servidor que privilegia privacidade pode rejeitar um CSR que os revele. Assim, a CA usa a prova material para autorizar, mas entrega um certificado com identidade lógica da carga de trabalho.

Um número permanente em certificado ou log de transparência permite correlacionar renovações e apresentações por anos. A exposição não desaparece com rotação de chave e pode dificultar a troca do equipamento. Porém, a omissão também impõe disciplina: o relying party não pode deduzir a atestação olhando apenas o certificado.

Payloads podem trazer firmware, boot, sistema operacional ou nível de proteção. A CA pode rejeitar com base neles, mas o texto não uniformiza a verificação. TPM, TEE e keystore do sistema oferecem garantias diferentes. Todos os atributos têm data; o certificado pode sobreviver à configuração, à custódia e à política que existiam no challenge.

Nas camadas de realidade de Heng Lu, aprovação, registro, challenge, emissão, postura atual e decisão de acesso são recibos separados. A separação torna a automação auditável.

Fontes