Resumo

  • O RFC 9646 coloca um HTTP 400 entre duas chamadas get-bootstrapping-data: anúncio de capacidade, seleção do servidor e CSR devolvido são registros diferentes.
  • A assinatura do CSR prova a posse da chave privada correspondente, mas não prova sozinha a origem do dispositivo, a aprovação da CA, a entrega, a instalação ou o uso autorizado.
  • Como o csr-request viaja em um erro HTTP que não pode ser assinado como os dados de inicialização do RFC 8572, o mecanismo não pode operar por meio de um servidor não confiável.

O erro era a próxima instrução

RFC 9646 amplia o Secure Zero Touch Provisioning para que um equipamento possa obter, durante a integração, um certificado de identidade próprio do ambiente de produção. A troca tem duas requisições, não uma resposta mágica.

Na primeira chamada, o cliente SZTP envia csr-support. Ele informa se consegue gerar uma chave assimétrica nova, quais algoritmos aceita e quais formatos de CSR produz. Se o servidor quiser um pedido, responde com HTTP 400 e inclui um csr-request no error-info do RESTCONF. Essa estrutura escolhe algoritmo e formato e pode definir informações do certificado.

O cliente então faz a segunda chamada get-bootstrapping-data, agora com p10-csr, cmc-csr ou cmp-csr. Servidor, autoridade de registro e autoridade certificadora podem validar o pedido. Somente se a política aprovar, a informação de integração pode trazer o certificado assinado.

O 400 é, ao mesmo tempo, um status HTTP de erro do cliente e uma transição esperada do protocolo. Nenhum dos sentidos diz que a identidade foi aprovada. Um painel que mostra apenas vermelho perde a instrução; um painel que mostra apenas “CSR solicitado” perde a semântica do transporte.

Capacidade não é execução

csr-support anuncia possibilidades. Não demonstra que a chave nasceu, que o gerador aleatório era adequado ou que o segredo ficou em um TPM. A seleção do servidor reduz o conjunto, mas continua sendo comando. O dispositivo ainda precisa escolher ou gerar a chave, construir o objeto e correlacionar a segunda requisição.

A Especificação Inicial Mínima de Lu Heng oferece a disciplina correta: padronizar a passagem indispensável e manter decisões locais visíveis. O RFC 9646 não cria uma política universal de emissão, um transporte único para o certificado nem autorização para o serviço que usará a identidade.

Resumir tudo como “suporte a CSR” impede reconstruir se o servidor escolheu opção anunciada, se a chave dita nova já existia e se a resposta final correspondeu ao mesmo ciclo.

Posse e origem respondem a perguntas diferentes

A prova de posse verifica a assinatura do CSR usando a chave pública contida nele. Se passar, quem produziu o objeto controlava a chave privada correspondente. É uma conclusão criptográfica forte, mas estreita.

A prova de origem identifica de qual equipamento ou principal autorizado veio o pedido. Um PKCS #10 bruto não inclui autenticação de origem dentro da própria estrutura. Ela pode vir da identidade TLS ou HTTP do cliente. Nesse caso, separar o arquivo CSR de sua sessão elimina o contexto que sustentava a origem.

CMC e CMP admitem autenticação de origem por PKI ou segredo compartilhado e podem incluir uma autoridade de registro antes da CA. Isso oferece evidência mais rica, não emissão automática. O caminho IDevID, o segredo ou a proteção do protocolo ainda precisam ser verificados antes da política da CA.

Quando a chave de identidade do fabricante é reutilizada, valida-se o caminho de certificação IDevID e confirma-se que o CSR usa o mesmo par. Quando há uma chave local nova, CMC ou CMP pode vinculá-la à chave do fabricante ou a um segredo. Tratar ambos como simples “CSR válido” esconde quem autenticou a origem.

Chave nova não é sinônimo de chave melhor

O RFC recomenda uma nova chave privada para cada CSR. Se o equipamento realmente a gera depois da ordem, os bytes aleatórios também funcionam como uma espécie de nonce. Quando o certificado devolvido contém a nova chave pública, o cliente obtém evidência de que a resposta pertence à troca atual.

Isso precisa ser medido. Uma interface que marca key-generation não prova novidade se a impressão digital se repete. E há um compromisso: se a nova chave não puder ser protegida tão bem quanto a chave interna do fabricante, o RFC recomenda reutilizar a chave mais bem protegida. Novidade reduz determinados replays; custódia forte reduz determinados riscos de personificação.

A chave dinâmica deve ser protegida contra divulgação, de preferência em HSM ou TPM. Sem essa proteção, a rotação reduz o tempo de exposição. Certificado de implantação e chave recém-gerada são dados do usuário e devem ser apagados no retorno ao padrão de fábrica. A trilha precisa registrar esse encerramento.

A mensagem não assinada define o limite

O RFC 8572 admite que um cliente se conecte a um servidor de inicialização ainda não confiável e dependa de dados assinados. O csr-request do RFC 9646 não recebe essa garantia: ele está dentro de um erro HTTP, que não pode ser assinado como os dados de inicialização.

Por isso, o mecanismo CSR não pode ser usado nessa relação. O cliente não deve enviar csr-support ao servidor não confiável; deve preferir signed-data-preferred. É um limite de autoridade, não um detalhe de observabilidade.

Ignorar esse limite deixa uma parte não autenticada escolher algoritmo, formato e conteúdo do futuro pedido de identidade. Um CSR posteriormente bem assinado só mostra que o equipamento obedeceu. A correção criptográfica da etapa seguinte não legitima a instrução anterior.

Emissão, transporte, instalação e uso

Depois de receber o CSR, a infraestrutura verifica posse, origem, inventário, propriedade e atributos. A RA ou CA aprova ou rejeita. A assinatura do CSR não substitui essa decisão.

O RFC 9646 deixa fora de escopo a forma exata de transportar o certificado assinado dentro da informação de integração. Os exemplos mostram alternativas, inclusive associação com o keystore do RFC 9642. Emitir e entregar continuam sendo resultados distintos.

Instalar é outro resultado: ligar certificado à chave correta, confirmar a gravação e selecionar a identidade no serviço pretendido. A primeira autenticação bem-sucedida cria evidência de uso. A aplicação ainda decide se aquele principal pode executar a operação solicitada.

A Primazia do Código em Execução de Lu Heng impede que um modelo completo substitua efeitos observados. YANG descreve a troca; CA, armazenamento e serviço produzem fatos próprios.

Construir o recibo de integração

Comece pela confiança: identidade do servidor, caminho da âncora, autenticação TLS e HTTP e razão para usar csr-support ou signed-data-preferred. Preserve nonce, características do dispositivo, algoritmos e formatos da primeira chamada.

Registre o HTTP 400 como transição: csr-request completo, algoritmo, formato, conteúdo, horário e identificador de correlação. Para a chave, registre geração ou reuso, impressão digital pública, evidência de aleatoriedade ou HSM, fronteira de proteção e conclusão sobre novidade.

Na segunda chamada, guarde formato e hash do CSR. Julgue posse e origem separadamente, nomeando IDevID, segredo, identidade TLS ou HTTP. Em seguida registre decisão RA/CA, certificado emitido, transporte, instalação, primeiro uso, rotação e remoção.

As camadas de realidade são o controle conceitual: status, instrução, posse, origem, aprovação institucional, estado instalado e efeito operacional ficam próximos, mas não são equivalentes.

Sources