Resumo

  • RFC 9641 oferece bolsas nomeadas de certificados e chaves públicas, referências centrais e definições inline; ele representa material disponível, não uma autenticação concluída.
  • Âncoras central e inline podem ser idênticas em um instante e divergir depois por terem proprietários, alcance de mudança e mecanismos de reversão diferentes.
  • O recibo defensável liga origem e autorização da configuração aos bytes resolvidos, ao par, ao caminho, ao relógio, ao nome de serviço, ao propósito, à revogação, ao veredito e à autorização posterior.

Dois clientes estavam configurados com a mesma âncora. O primeiro guardava o certificado diretamente em sua configuração. O segundo apontava para uma bolsa central. As impressões digitais coincidiam, e os testes retornavam a mesma aceitação. O inventário marcou os dois controles como equivalentes.

Uma rotação desfez essa equivalência. O truststore central mudou e o segundo cliente herdou a atualização. O primeiro permaneceu com a cópia antiga. Nada estava errado no formato de qualquer configuração; a diferença estava na propriedade futura da decisão.

RFC 9641 torna esse desenho explícito. O módulo ietf-truststore organiza certificados e chaves públicas brutas em bolsas nomeadas. Agrupamentos reutilizáveis permitem que outro modelo escolha uma definição inline ou uma referência central. O padrão coordena a representação sem fingir que todas as implantações compartilham o mesmo processo de validação.

Igualdade de conteúdo não é igualdade de governança

RFC 9641 foi publicado em outubro de 2024 como Standards Track pelo grupo NETCONF do IETF. Quando as funções correspondentes estão presentes, os agrupamentos inline-or-truststore exigem uma escolha. Essa escolha não é apenas uma economia de bytes; ela define quem pode mudar a entrada e quantos consumidores sentirão o efeito.

O truststore central reduz duplicação. Uma retirada urgente pode alcançar vários serviços por uma única alteração. A mesma eficiência cria um raio de impacto: adicionar a âncora errada pode ampliar a aceitação de todos os consumidores. Material inline localiza a mudança e a reversão, mas facilita deriva, exceções esquecidas e instâncias que não acompanham decisões globais.

Logo, o recibo de um evento deve ir além do nome da bolsa. Ele preserva identificador do objeto, bytes ou impressão digital, hash de conteúdo, origem do datastore, caminho do consumidor, momento da resolução e versão operacional. Um nome central é mutável; não responde qual versão participou de uma sessão passada.

A bolsa declara propósito sem executar a política

Bolsas reúnem objetos para um propósito comum. A descrição de uma bolsa de certificados deveria declarar esse propósito; a de uma bolsa de chaves públicas deve fazê-lo. É uma disciplina útil para governança e revisão.

O modelo genérico, contudo, não impõe sozinho limites de nome, operação ou caminho de certificação. Sem restrições do consumidor ou de política auxiliar, as âncoras configuradas são implicitamente confiáveis para caminhos que podem conter qualquer nome e servir qualquer finalidade. A amplitude permite reutilização; não deve ser confundida com permissão irrestrita.

Uma bolsa chamada “servidores de produção” não compara nomes DNS, não avalia Extended Key Usage e não decide revogação. Os agrupamentos TLS de RFC 9645 podem selecionar a fonte de confiança, mas o verificador implantado precisa mostrar quais regras executou. Chaves públicas brutas e certificados X.509 ainda exigem fluxos distintos.

Origem system preserva atribuição, não prova procedência

Fabricantes podem fornecer âncoras para serviços próprios, bootstrap seguro ou autoridades públicas. RFC 9641 espera que apareçam no estado operational e, onde houver datastore system, também ali, com origem de sistema em vez de origem de configuração pretendida.

Essa separação evita atribuir ao operador uma escolha incorporada. Não reconstrói, porém, quem aprovou a imagem de fábrica, qual build introduziu a âncora, como uma atualização foi autenticada ou se um consumidor a selecionou. O método para definir e alterar âncoras embutidas fica fora do escopo da RFC.

No provisionamento seguro de RFC 8572, uma confiança inicial pode decidir qual controlador recebe autoridade depois. Misturar intended, system e operational em uma lista única destrói a trilha dessa transferência.

NACM cobre a porta de gestão

Nós e referências do truststore usam nacm:default-deny-write. Pelo RFC 8341, a escrita começa negada salvo autorização mais específica. O cuidado vale para certificados públicos: trocar uma chave pública pode redirecionar a identidade aceita.

O padrão de negação não é um histórico. O recibo deve trazer identidade da sessão NETCONF ou RESTCONF, canal, versão das regras NACM, regra correspondente, caminho e operação, valores anterior e posterior, aprovação, commit e projeção operational. O RFC 8342 distingue datastores, mas não presume que intenção e execução sejam idênticas.

RFC 9641 também reconhece que YANG não especifica proteção em repouso. NACM governa a API; root local, pacote, restauração de backup ou corrupção de armazenamento podem seguir outro caminho. A implementação precisa demonstrar integridade contra modificação não autorizada fora do plano de gestão.

Expiração avisa; não substitui

Quando suportada, a notificação certificate-expiration sinaliza aproximação ou chegada da expiração. Ela não prova entrega, reconhecimento, aprovação do substituto, atualização das referências nem primeira validação bem-sucedida.

O ciclo deve unir função habilitada, assinatura, emissão, entrega, confirmação, objeto novo, implantação, resolução e uso verificado. Uma bolsa central pode estar correta enquanto uma cópia inline permanece velha. Um certificado ainda válido no calendário pode falhar por nome, uso, algoritmo ou revogação.

Um caminho válido não encerra a identidade

O RFC 5280 define validação de caminhos X.509. O verificador escolhe caminhos, processa restrições e aplica política local. O RFC 6125 separa identidade do serviço da validade do caminho. O RFC 8446 fornece o contexto de sessão TLS.

Uma decisão reproduzível registra certificado ou chave do par, sessão, bolsa e âncora resolvidas, caminhos candidato e aceito, hora e fonte de relógio, validade, identidade de referência, regra de correspondência, usos, restrições, políticas, algoritmos, estado de revogação exigido, implementação do verificador e motivo final.

Autenticar não é autorizar. O par pode ler telemetria e não editar configuração; uma identidade de bootstrap pode não ter mandato operacional. O resultado de autorização após a autenticação precisa de seu próprio registro, ligado à ação solicitada.

Transformar configuração em recibo verificável

Começar por revisão do módulo, features e caminho exato. Identificar modo inline, central ou embutido; origens intended, system e operational; ator, aprovação, decisão NACM e prova de integridade em repouso.

Na execução, resolver a referência para bytes exatos e unir consumidor, par, sessão, caminho, tempo, nome, propósito, algoritmo, revogação, veredito e autorização. Mudança central exige inventário de dependentes e comparação antes/depois. Notificação de expiração só fecha depois do uso confirmado.

Essa cadeia preserva a autonomia local defendida por uma especificação mínima. RFC 9641 cria um idioma compartilhado para o material de confiança. Cada consumidor mantém a responsabilidade pelo que aceita. O recibo mostra a passagem entre as duas camadas sem declarar que bytes iguais carregam para sempre a mesma autoridade.

Fontes