Resumo

  • Com o RFC 9908, o servidor EST pode entregar valores fixos, tipos obrigatórios e espaços a serem preenchidos pelo cliente em um futuro pedido PKCS #10.
  • A resposta registra uma instrução de montagem; assinatura, posse da chave, autenticação, autorização da AC, certificado emitido, instalação e uso observado continuam sendo evidências separadas.

O equipamento ainda não tinha enviado uma CSR, mas o painel já exibia “identidade aprovada”. A base desse estado era uma resposta /csrattrs: unidade organizacional fixa, nome comum deixado ao cliente, curva P-256 obrigatória e um campo aberto em subjectAltName. Havia uma descrição detalhada do pedido desejado. Não havia assinatura do pedido, autenticação para a matrícula, decisão da autoridade certificadora nem certificado.

O painel é um exemplo hipotético. Ele ilustra por que automação bem estruturada pode enganar: uma instrução codificada parece carregar a autoridade das etapas seguintes. O RFC 9908 resolve uma ambiguidade de representação. Não transforma o modelo em uma autorização.

O texto atualiza o EST do RFC 7030 e o EST sobre CoAP do RFC 9148. O cliente já podia consultar os atributos que o servidor ou a AC esperava ver no pedido. A dificuldade era comunicar, de maneira uniforme, não apenas OIDs, mas valores concretos, especialmente os de extensões X.509.

O novo CertificationRequestInfoTemplate lembra a parte informativa de uma solicitação PKCS #10, sem o invólucro de assinatura e com campos cuja ausência tem semântica. É uma forma parcialmente preenchida, anterior à CSR completa e muito anterior ao certificado.

Se o servidor não exige nada do nome distinto do sujeito, subject fica ausente. Se exige determinado RDN, o tipo aparece. Tipo com valor significa que o cliente deve conservar o valor; tipo sem valor pede que o cliente forneça um conteúdo adequado. subjectPKInfo ausente indica que o servidor não expressou requisito de chave ali. Quando presente, informa o algoritmo; um valor público de preenchimento pode representar o tamanho exigido para uma chave RSA.

O id-aa-extensionReqTemplate aplica a mesma lógica às extensões. O servidor identifica a extensão e pode fornecer o valor todo, omiti-lo ou deixá-lo incompleto. Assim, um SAN pode combinar um nome fixado pelo servidor e outro valor a cargo do cliente. O caso do Autonomic Control Plane em RFC 8994, que precisa transmitir um subjectAltName específico, explica a utilidade operacional.

A estrutura CsrAttrs no fio é preservada. O modelo usa v1, não admite repetição de id-aa-extensionReqTemplate e não pode misturar essa forma com id-ExtensionReq. A atualização também alcança o transporte CoAP. São controles de sintaxe e interoperabilidade; nenhum deles comprova direito sobre um nome.

O RFC 7030 separa a consulta da matrícula. Pedir atributos é opcional, e o servidor normalmente não deve exigir autenticação ou autorização apenas para responder. Independentemente do conteúdo retornado, o servidor EST e a AC podem rejeitar o pedido posterior por qualquer motivo. Receber uma lista de requisitos não cria expectativa vinculante de emissão.

Quando a CSR assinada chega, começam outras verificações. O servidor autentica o cliente e decide se ele pode usar o serviço solicitado. A assinatura da CSR demonstra posse da chave privada quando o mecanismo se aplica. O EST também pode vincular a solicitação assinada à sessão TLS autenticada. O RFC 5272 fornece a base CMC de prova de posse e controles de gestão de certificados.

Posse, autenticação e autorização respondem a perguntas diferentes. A primeira relaciona a chave pública a uma chave privada controlada. A segunda identifica a parte aceita no canal. A terceira decide se essa parte pode receber aqueles nomes, extensões e usos. Controlar uma chave não concede um domínio; autenticar uma conta não legitima todo SAN proposto.

A emissão permanece sob a política local da AC. O RFC 7030 admite revisão manual e resposta HTTP 202 enquanto a decisão está pendente. PKCS #10 descreve uma AC que autentica o solicitante, verifica a assinatura e, se considerar válido o pedido, constrói o certificado usando também suas escolhas e outras informações. Uma CSR correta pode ser recusada, suspensa ou transformada.

O certificado assinado é um artefato novo. Número de série, validade, emissor, extensões e restrições devem ser lidos nele. Comparar modelo, CSR final, registro de decisão e certificado mostra o que veio fixo, o que o cliente completou, o que a política aceitou, mudou ou acrescentou.

Emissão ainda não é implantação. O RFC 5280 disciplina o perfil X.509 e a validação de caminhos pelas partes confiantes. Um certificado pode ficar numa fila, ser instalado no alvo errado, coexistir com o anterior ou ser rejeitado por outra política. Inventário e sessões observadas formam camadas posteriores.

O registro mínimo, portanto, é uma cadeia. Guarde os bytes exatos de /csrattrs, identidade do servidor, horário, prazo de cache e hash do modelo. Marque valores fixos, lacunas do cliente e campos ausentes. Vincule a CSR à versão usada e registre validação de assinatura, prova de posse, identidade autenticada, entrada e versão da política, decisão, impressão digital do certificado, alvo de instalação e janela de observação.

Um campo ausente só prova que o servidor não expressou requisito por aquele campo. Não prova que um valor posterior é permitido. Um SAN fixo prova que o servidor pediu ao cliente para solicitá-lo; não prova a origem do direito de autorizar esse nome. Essa procedência deve existir fora do ASN.1.

Compatibilidade de fio não é compatibilidade de parque. Clientes antigos podem não interpretar corretamente atributos novos ou valores parciais. Antes da mudança, inventarie capacidades, detecte descarte silencioso e defina uma política explícita para a forma legada. Um fallback acidental corrói o controle sem deixar decisão.

O retorno também depende do estágio. É possível retirar o modelo, expirar caches ou negar uma CSR pendente. Depois de emitir e instalar, restaurar o modelo anterior não remove credenciais. Revogação, troca, dispositivos desconectados e comportamento das partes confiantes tornam-se ações próprias.

A primazia do código em execução de Heng Lu separa publicação de implementação. A ideia de especificação inicial mínima, decisão futura localizada e adoção voluntária impede que uma semântica comum e limitada vire autoridade implícita.

As camadas da realidade distinguem instrução, pedido, posse, identidade, autorização, artefato assinado e operação observada. A análise sobre soberania de dados acrescenta que capacidade técnica não equivale a autoridade jurídica ou organizacional. Inserir um nome numa CSR não cria o direito sobre ele.

O RFC 9908 melhora o EST ao dizer com clareza o que o cliente deve montar. Uma arquitetura madura conserva essa modéstia. O modelo orienta; o cliente completa e assina; o servidor autentica; a política autoriza; a AC emite; o operador instala; a parte confiante valida. Confiabilidade é conseguir provar cada verbo.

Fontes