Resumo

  • RFC 9640 padroniza tipos e agrupamentos YANG para senhas, chaves, certificados, valores criptografados e solicitações de certificado.
  • Confirmar que chave pública, privada e certificado combinam prova coerência estrutural; não prova geração legítima, finalidade permitida nem uso autorizado.
  • O recibo completo liga sessão, NACM, aprovação, datastore, origem, fronteira de custódia, operação real e descarte.

O servidor recebeu uma chave privada, derivou sua parte pública e confirmou que o certificado carregava a mesma chave. O teste passou. Em seguida, a equipe concluiu que aquele material estava autorizado para assinar atualizações de produção.

O primeiro enunciado era uma verificação matemática. O segundo exigia governança e política de uso que não estavam no teste. RFC 9640 deliberadamente não impõe restrições genéricas de finalidade às chaves públicas ou privadas. O módulo consumidor precisa dizer se uma chave pode assinar, verificar, cifrar ou decifrar.

Um vocabulário mínimo e reutilizável

Publicado em outubro de 2024 na trilha de padrões, o ietf-crypto-types reúne identidades, typedefs e agrupamentos para aplicações criptográficas. Objetos ASN.1 codificados em DER incluem PKCS #10, certificados X.509, CRLs, OCSP e estruturas CMS. Agrupamentos cobrem senha, chave simétrica, chave pública, chave privada, par assimétrico, certificados e ação de CSR.

Essa base comum reduz incompatibilidades sem centralizar cada decisão. Ela não é um keystore ou truststore completo; esses papéis vizinhos aparecem nos RFCs 9642 e 9641. Um RPC genérico de geração foi retirado por falta de consenso sobre identificação de algoritmos. Logo, o estado aceito na árvore não reconstrói a cerimônia de geração ou importação.

Três formas, três perguntas

O RFC admite chaves em claro, ocultas e criptografadas quando as funcionalidades são habilitadas. Armazenamento em claro não é recomendado; leituras sensíveis recebem default-deny-all e escritas, default-deny-write.

Uma chave oculta não é retornada pelas interfaces de gerenciamento, mas permanece disponível ao servidor. Isso não demonstra residência em HSM nem ausência de outro caminho de exportação. Para afirmar não extração, o recibo deve nomear hardware ou software, versão, atributos do objeto, interfaces administrativas, backup e testes negativos.

Uma chave criptografada traz uma dependência. CMS organiza o conteúdo e, para criptografia simétrica, RFC 9640 exige AEAD ou CBC com IV aleatório e proíbe ECB. O módulo consumidor ainda precisa preencher encrypted-by com a referência da chave de envelopamento. Sem provar proteção, disponibilidade, rotação e autoridade dessa chave, o ciphertext não constitui recuperação confiável.

NACM não substitui o evento

Padrões restritivos são importantes, inclusive para certificados, cujos identificadores podem revelar relações. Mas uma anotação de esquema não informa qual regra estava ativa, quem abriu a sessão, qual exceção foi aplicada nem se outra interface contornou o caminho YANG.

O recibo precisa da identidade NETCONF ou RESTCONF, transporte e channel binding, versão de NACM, regra selecionada, caminho, operação, estados anterior e posterior, commit e aprovação de negócio. Autenticação de canal, autorização de modelo e mandato organizacional são camadas separadas.

Do CSR ao uso

A ação generate-csr recebe default-deny-all, e o RFC recomenda channel binding para aproximar solicitante da aplicação e dispositivo autenticado. O resultado prova que um objeto de solicitação foi produzido. Não prova que a autoridade certificadora aceitou, que o certificado foi instalado ou que a chave realizou a operação pretendida.

Registre inputs, referência da chave, digest do CSR, identidade e autorização; depois, submissão à CA, decisão, certificado emitido, correspondência, instalação e primeiro uso validado. O mesmo princípio vale para cada assinatura ou decifragem: solicitante, política, versão da chave, input, output, horário e resultado.

Deletar é só o começo do descarte

RFC 9640 diz que valores claros devem ser zerados na exclusão. A ausência do nó prova uma transição do datastore. Memória, journal, réplica, swap, crash dump e backup podem sobreviver. Um recibo de destruição identifica implementação, domínios de armazenamento, mecanismo de zeragem, réplicas offline, validade dos backups e método de verificação.

Assim se forma a cadeia: revisão do módulo, sessão, NACM, aprovação, commit, origem, fronteira confiável, usos permitidos, dependência de envelopamento, execução, rotação, revogação e eliminação. YANG descreve com precisão; o código em execução e os registros mostram o que de fato aconteceu.

Fontes