Resumo

  • A IESG abriu em 2 de setembro a consulta final da revisão 29 do rascunho de atestação em pedidos de certificado. O prazo para comentários é 16 de setembro.
  • Havendo vários verificadores para um mesmo identificador de formato, a especificação desse formato deve esclarecer a seleção. Compatibilidade de leitura não encerra a integração.

A equipe de certificados pode receber duas propostas de serviço com a mesma lista de formatos suportados. Antes de tratá-las como substitutas, precisa saber como o sistema escolhe o verificador de cada evidência. Uma regra não documentada nessa etapa pode exigir trabalho de integração que a lista não revela.

É essa divisão de responsabilidades que aparece na consulta final anunciada pela IESG em 2 de setembro. O documento draft-ietf-lamps-csr-attestation-29 está sendo considerado para Proposed Standard, com comentários até 16 de setembro. Continua sendo um rascunho; o anúncio não comprova implantação nem aprovação como RFC.

A proposta cria uma estrutura para levar atestações remotas em pedidos PKCS#10 e CRMF, aceitando formatos padronizados ou proprietários. A autoridade certificadora ou de registro, CA ou RA, pode verificar as informações internamente ou encaminhá-las a um verificador externo. A diversidade de arranjos é parte do desenho.

O formato precisa explicar o encaminhamento

Na seção 4.3 da revisão 29, o texto reconhece a ambiguidade quando vários verificadores suportam o mesmo identificador de objeto, ou OID, de formato de atestação. Recomenda OIDs distintos para tipos de verificador ou de verificação, mesmo com estrutura idêntica, ou um invólucro que leve uma indicação explícita. Os mecanismos precisos de encaminhamento e escolha do nonce cabem à especificação do formato.

Não se trata de usar o OID como endereço de servidor. O identificador informa a representação dos dados, que pode ser compreendida por diferentes serviços. Selecionar o processamento pretendido exige uma convenção. O documento comum indica quem deve defini-la, sem uniformizar todas as decisões de destino.

A consequência de governança surge na manutenção dessa correspondência. Quem pode alterá-la pode influenciar qual serviço avalia as evidências. Por isso, uma declaração de compatibilidade mais útil explicaria tanto os formatos aceitos quanto a convenção de seleção, incluindo a resposta a uma indicação ausente ou contraditória.

Duas camadas de identificação

Na tabela de atributos S/MIME da IANA, o valor 59 ainda aparece como id-aa-evidence. O rascunho solicita mudar o nome para id-aa-attestation, preservando o número. Esse registro é do atributo externo do pedido de certificado. Não é um catálogo de verificadores.

Já os OIDs dos formatos carregados dentro da estrutura ficam, pela seção 4.2, a cargo dos autores desses formatos, usando ramos de identificadores sob seu controle. O responsável pelo registro externo não resolve, com esse registro, a escolha operacional do serviço. Confundir as duas camadas faria parecer completa uma informação que ainda depende da especificação interna.

A RFC 9334 esclarece por que o destino interessa. O responsável pelo verificador define a política de avaliação das evidências; o responsável pela parte que usa o resultado define como utilizá-lo. Encaminhar dados a um serviço pode selecionar um contexto de avaliação, não apenas um decodificador. Os papéis podem coexistir na mesma organização, mas continuam distintos.

Para uma integração, seria útil testar o mesmo formato sob cada condição de seleção documentada e observar qual verificador é acionado. Essa é uma proposta de verificação deste artigo, não uma obrigação adicional da IETF. Também não substitui o trabalho posterior: a revisão 29 mantém com a CA ou RA a responsabilidade de validar o vínculo da atestação com a chave pública do pedido.

As fontes examinadas não registram um incidente de encaminhamento nem medem custos de troca. A notícia é a fronteira de projeto em consulta. Um transporte comum pode simplificar a conexão, mas a possibilidade de escolher ou substituir serviços depende de uma convenção separada e explícita.

Fontes

  1. Consulta final da IESG
  2. Atestação em CSR, revisão 29
  3. Arquitetura RATS, RFC 9334
  4. Registros SMI da IANA