Resumo

  • A RFC 9908 é um IETF Proposed Standard, publicada em janeiro de 2026, e atualiza as RFC 7030 e RFC 9148.
  • Ela esclarece a codificação de OIDs e valores de atributos CSR, especialmente valores de extensões X.509, e introduz o CertificationRequestInfoTemplate.
  • O servidor pode enviar um modelo parcialmente preenchido, fixando o que exige e deixando em branco o que o cliente deve fornecer. Isso não aprova a CSR nem substitui autenticação ou a política da CA.

A mudança essencial é semântica: /csrattrs deixa de ser apenas uma lista de tipos aceitáveis e passa a descrever a forma esperada da CSR seguinte. O cliente precisa distinguir três casos: campo ausente, campo presente com valor omitido e campo cujo valor foi fornecido pelo servidor. Presença, ausência e valor opcional têm significados ASN.1 diferentes; tratá-los como um simples “obrigatório” ou “opcional” perde informação de controle.

O CertificationRequestInfoTemplate pode conter subject, mas subject é opcional. Ele aparece quando o servidor tem requisitos de RDN. Um RDN pode aparecer sem valor para indicar que o cliente deve fornecer um valor apropriado. Quando o servidor fornece o valor de um RDN, espera-se que o cliente o utilize; quando não fornece, o cliente preenche a lacuna. Logo, uma lacuna explícita não significa ausência de restrição.

subjectPKInfo fica ausente quando o servidor não tem requisitos de chave. Quando aparece, seu algoritmo identifica o tipo de par de chaves esperado. subjectPublicKey normalmente fica ausente, mas pode carregar um placeholder quando é necessário expressar um requisito de comprimento do módulo RSA. Esse placeholder não é a chave pública final do cliente e não deve ser persistido como se fosse uma identidade criptográfica.

A motivação operacional aparece no ingresso de ACP e BRSKI. O servidor precisa transmitir um subjectAltName específico por meio de /csrattrs, em vez de somente listar uma extensão possível. A RFC 8994 fornece o contexto do autonomic control plane, e a RFC 8995 o contexto de bootstrap. A RFC 9908 esclarece o mecanismo para uso compatível com o EST existente; não substitui a autenticação do EST, não concede aprovação à CSR e não determina a política da CA.

Análise de Theo March: um modelo é uma restrição expressa, não um certificado de aprovação. O envio do modelo não significa que o servidor assinou ou aprovou a CSR. A autenticação continua sendo uma questão própria do EST, e a CA pode aceitar ou recusar segundo sua política. Uma resposta que pode ser decodificada também não prova que os requisitos chegaram corretamente à CSR e ao certificado final.

Fontes