Resumo

  • O grupo ACME enviou draft-ietf-acme-profiles-02 ao IESG em 21 de setembro de 2026. O estado Publication Requested não é aprovação do IESG nem publicação de RFC.
  • newOrder.profile antecipa a seleção de características, mas anúncio, elegibilidade, aceitação do pedido, emissão e implantação continuam sendo provas diferentes.

Configurações de automação tendem a transformar um nome que funcionou ontem em contrato para amanhã. O rascunho ACME Profiles melhora esse cenário ao tornar a seleção explícita na ordem. Ao mesmo tempo, seu próprio texto impede a leitura mais confortável: o nome não é uma promessa autossuficiente.

Ele pode estar anunciado para o público, ser aceito como perfil privado sem anúncio ou falhar no momento da finalização depois de uma ordem aceita. A arquitetura reconhece que a política de uma autoridade certificadora pode variar por conta, ambiente e tempo.

O marco do IETF tem limites claros

Em 21 de setembro, o Datatracker registrou a passagem de Working Group Last Call para “Submitted to IESG for Publication”. O estado do IESG é “Publication Requested”, Deb Cooley aparece como Area Director responsável e não há data de telechat. Mike Ounsworth fez o pedido em nome do grupo.

O objetivo declarado é Proposed Standard, mas a revisão 02 ainda é Internet-Draft. O shepherd write-up descreve consenso fraco, pois a extensão foi vista como simples e recebeu poucas manifestações fortes de apoio; não registra controvérsia ou recurso. A lista de implementações e a implantação da Let’s Encrypt são experiência delimitada, não prova de adoção generalizada.

A seleção passa a ocorrer na ordem

No RFC 8555, o cliente cria uma ordem e depois entrega o CSR ao recurso finalize. A extensão acrescenta ao Directory o objeto opcional profiles, um mapa entre identificadores curtos e URLs com descrições legíveis. Uma data URL também é permitida.

O cliente envia o identificador em newOrder.profile. Quando aceita, a resposta Order ecoa o mesmo nome. A CA pode então decidir características antes de analisar o CSR, que continua transportando a chave pública e subjectAltName. O rascunho aponta a redução potencial de parsing e cópia ASN.1.

Nada disso altera a gestão de contas nem a validação de identificadores. Também não cria um vocabulário universal. O significado é do endpoint que publica o Directory e do conteúdo vinculado naquele instante.

A fronteira entre oferta e direito

Se o perfil não for compatível com o pedido, o servidor deve responder invalidProfile. O texto cita um perfil de autenticação de servidor TLS usado com identificador de e-mail e uma conta não autorizada por allowlist. Portanto, anúncio não é direito de uso.

A ausência no Directory também não fecha todas as possibilidades. Cliente e servidor normalmente devem evitar um nome não anunciado, porém o servidor pode aceitá-lo em situações excepcionais. O rascunho menciona um perfil privado acordado fora do protocolo e a reposição de certificado antigo após revogação em massa.

Se o cliente não enviar o campo, recomenda-se que o servidor selecione e associe um perfil. A resposta Order, não apenas a requisição, é a prova do seletor aplicado.

Aceitar a ordem ainda não é emitir. Se a CA deixar de estar disposta a emitir sob o perfil antes de finalize, deverá devolver invalidProfile. O texto recomenda esperar as ordens abertas expirarem antes de interromper o perfil, mas preserva o erro para situações em que a política muda durante a vida da ordem.

Um nome acompanha o ambiente e a data

A Let’s Encrypt chama o Directory atual de lista canônica e informa que nem todos os perfis existem em todos os ambientes; alguns podem exigir allowlist. classic, tlsserver e shortlived têm diferenças de reutilização de autorização, duração de ordem e certificado, tipos de identificador e campos emitidos.

O antigo tlsclient está indisponível desde 8 de julho de 2026. tlsserver passou para certificados de 45 dias em 13 de maio, e há reduções futuras planejadas para classic. São fatos sobre um operador, não uma definição inter-CA.

A trilha necessária para auditoria

O primeiro registro guarda o Directory bruto, a URL e a hora. O segundo guarda a descrição e seu hash. Depois vêm endpoint, conta, identificadores, nome pedido, decisão de elegibilidade e resposta Order com o perfil ecoado.

Na finalização, guardam-se o hash do CSR, a resposta e eventual problem type. Após emissão, a impressão digital e os atributos analisados mostram o que foi assinado. A implantação exige outra observação: tempo, ponto de vista e certificado apresentado pelo serviço.

Esses registros não são redundantes. Directory não concede elegibilidade; Order não é certificado; certificado emitido não comprova instalação. Separá-los torna a automação explicável mesmo quando a política evolui.

Fontes

  1. Estado atual no Datatracker
  2. Histórico do documento
  3. draft-ietf-acme-profiles-02
  4. Pedido de publicação
  5. Shepherd write-up
  6. RFC 8555
  7. Documentação de perfis da Let’s Encrypt
  8. Anúncio de ACME Profiles
  9. Roteiro de duração dos certificados
  10. Anúncio da última chamada do grupo
  11. Conclusão da última chamada
  12. Acompanhamento da implementação Boulder
  13. Atas de ACME no IETF 126