Resumo

  • RFC 9642 define um keystore YANG para chaves simétricas e assimétricas, certificados, referências centrais e definições inline; não atesta a recuperação operacional.
  • A portabilidade dos valores cifrados depende do KEK compartilhado, das chaves primárias específicas de cada servidor, do reempacotamento e da autorização que percorre esse grafo.
  • O recibo termina no uso: consumidor certo, certificado certo, operação permitida executada, operação proibida recusada e resultado do serviço observado.

O responsável de criptografia conseguiu reempacotar o KEK compartilhado para o servidor substituto. Em minutos, centenas de chaves cifradas voltaram a aparecer. A eficiência parecia confirmar a arquitetura.

Ela também revelou a concentração de poder: a mesma pessoa e a mesma operação tinham capacidade de reativar identidades de vários serviços. O problema não era o mecanismo, mas a conclusão de que possuir o KEK equivalia a ter mandato para todos os usos dependentes.

RFC 9642 cria o módulo ietf-keystore para centralizar chaves simétricas e assimétricas, associar certificados e permitir que outros modelos escolham material inline ou uma referência central. O padrão reduz incompatibilidades. Ele não distribui responsabilidades organizacionais nem registra sozinho quem exerceu a autoridade.

O modelo começa pelas funções declaradas

Keystore central, definições inline, chaves assimétricas e chaves simétricas são features separadas. Um modelo consumidor pode instanciar agrupamentos em outro lugar e acrescentar novas alternativas. Duas implementações podem cumprir o RFC e, mesmo assim, expor caminhos de restauração diferentes.

O recibo fixa revisão, features, YANG Library, datastore, caminho, hash e consumidor. O nome de uma lista localiza uma entrada naquele contexto; não é identidade global, prova de posse ou afirmação de finalidade.

Uma leafref válida demonstra ligação de configuração. Ainda faltam a versão carregada pelo processo, a prioridade entre central e inline e a operação que usou o objeto. Estado e evento não podem compartilhar a mesma frase de certeza.

Origem de sistema não é cadeia de fabricação

Pelo RFC 8342, chaves fornecidas pelo servidor podem surgir em <operational> e <system> com origem de sistema. Elas podem ter sido instaladas na fábrica, geradas no primeiro boot ou criadas ao ativar um serviço.

A anotação separa o valor fornecido pelo servidor daquele configurado pelo operador. Não identifica fabricante, entropia, firmware, fronteira de hardware, possibilidade de exportação ou validade do certificado. O processo que cria ou altera a chave embutida fica fora do escopo de RFC 9642.

Quando o operador anexa um certificado de implantação a uma chave embutida, o objeto passa a reunir origens diferentes. Uma exportação achatada apaga essa distinção. A recuperação precisa preservar a origem da chave, de cada certificado e do ato de associação.

O elo encrypted-by participa do patrimônio

Uma chave cifrada inclui formato, ciphertext e referência à chave que a cifrou. O servidor deve alcançar o KEK ou uma API que o utilize. Sem isso, o backup preserva bytes, não a capacidade de assinar ou decifrar.

O fluxo não normativo de RFC 9642 coloca várias chaves sob um KEK compartilhado, protegido por uma chave primária exclusiva do servidor. No destino, substitui-se a entrada do KEK por outra cifrada sob a nova chave primária. Os demais ciphertexts podem continuar iguais.

Essa economia aumenta o raio de impacto. Perder o KEK bloqueia muitos serviços; trocá-lo afeta todos; ampliar sua interface amplia poder. A integridade do arquivo é necessária, mas a recuperabilidade exige fechamento do grafo: ciphertexts, referências, chaves primárias, KEK, formatos, algoritmos, ator autorizado, resultado do reempacotamento e rollback.

O relatório deve nomear backup, origem, destino, hashes, chaves, aprovações e testes. A figura do RFC não prova que um produto executou o fluxo.

Hidden e encrypted não são promessas universais

RFC 9640 fornece as representações usadas pelo keystore. Uma chave hidden não é devolvida por aquela superfície de gestão; isso não prova não extração por memória, console, API local, backup ou hardware. Um valor encrypted não comprova que o KEK está seguro e disponível.

RFC 9642 recomenda cifrar conteúdo persistido e zerar cópias claras em memória volátil quando deixam de ser usadas. Se a persistência não for cifrada, o armazenamento deve ser inacessível. A árvore YANG não observa réplica, swap, crash dump, log ou privilégio local.

Por isso, o recibo acrescenta evidência de armazenamento, memória, custódia, acessos e testes negativos. Sem prova de hardware, a afirmação permanece limitada à interface observada.

NACM controla uma porta

Todos os nós graváveis têm nacm:default-deny-write; segredos legíveis herdam negação ainda mais forte. RFC 8341 fornece a política, mas não registra por si só qual sessão e regra decidiram um evento.

A mudança deve ligar identidade NETCONF ou RESTCONF, canal, versão NACM, regra, caminho, antes/depois, commit, aprovação e projeção operacional. Também enumera interfaces locais, do fornecedor e do hardware fora de YANG. RFC 6241 e RFC 8040 contextualizam a gestão; não reconstroem a cerimônia da chave.

RFC 9642 não define RPC nem action. A geração pode estar em modelos consumidores de SSH/TLS ou ocorrer fora do servidor. A presença final da chave não revela quem gerou, aprovou ou viu o valor claro.

A associação ainda precisa chegar ao serviço

Uma chave assimétrica pode carregar certificados. A referência de certificado final escolhe a chave e o certificado. O Errata verificado 8441 corrige um comentário copiado que dizia “chave simétrica”; a estrutura sempre apontou para o par assimétrico.

RFC 9644 e RFC 9645 mostram consumidores SSH e TLS. O recibo resolve a referência, fixa a revisão do consumidor, observa assinatura, decriptação ou sessão e liga o efeito ao objeto selecionado.

O módulo também não restringe o uso da chave privada. O certificado pode limitar a chave pública associada, mas mandato e operação seguem separados. O teste deve aprovar o uso esperado e recusar usos não autorizados.

Expiração é fila de trabalho

A notificação informa uma data. Não prova entrega, reconhecimento, aprovação, substituição, atualização do consumidor ou sucesso posterior. Um backup antigo pode reinstalar certificado já aposentado.

O acompanhamento liga evento, receptor, reconhecimento, novo certificado, correspondência com a chave, referência ativa e operação observada. Divergências entre central e inline permanecem explícitas.

Fechar o recibo

Primeiro, fixar backup, módulos, features, datastores, origens, fingerprints, formatos e todas as arestas de cifragem. Depois, registrar as chaves primárias, o KEK, o reempacotamento autorizado e seu resultado.

No destino, provar que o KEK abre os objetos necessários, que cada referência escolhe a versão certa, que o certificado está associado, que o consumidor opera e que usos proibidos falham. O último elo é o resultado limitado do serviço e o rollback independente.

RFC 9642 alinha a especificação mínima. O código em execução exerce a autoridade. A governança conserva a prova para não transformar um backup legível em uma promessa de recuperação.

Fontes