Resumo

  • A RFC 8181 torna atômica uma solicitação com várias operações, mas a resposta de sucesso comprova a transação cliente-servidor, não a visão atual de todas as partes confiantes.
  • O manifesto da RFC 9286 liga nomes e hashes do conjunto vigente; o RRDP distribui snapshots e deltas identificados por sessão e serial.
  • Um registro defensável separa solicitado, confirmado pelo servidor, coerente com o manifesto, servido publicamente e observado por uma parte confiante.

Publicar em RPKI parece uma ação única: criar ou retirar um objeto, enviá-lo ao repositório e esperar os validadores. Os padrões descrevem uma cadeia mais precisa. Uma autoridade certificadora ou seu cliente executa a operação; o servidor confirma a transação; o manifesto descreve o conjunto atual; o serviço de distribuição expõe visões; e as partes confiantes recuperam e validam essas visões em seus próprios ciclos.

A RFC 8181 protege a primeira fronteira. Mensagens assinadas autenticam cliente e servidor. Uma consulta pode reunir publicações e retiradas, e o processamento é atômico. Substituições e retiradas carregam o hash do objeto existente na URI. Se o hash divergir, o servidor pode rejeitar a alteração em vez de sobrescrever silenciosamente um estado inesperado.

A resposta de sucesso é importante e limitada. Ela prova que o servidor nomeado aceitou toda a consulta autenticada. Não prova que a notificação RRDP pública mudou, que o rsync já oferece os novos arquivos nem que um validador específico os buscou. A RFC 8181 separa o protocolo de publicação entre cliente e servidor da interface pública de distribuição consumida pelas partes confiantes.

A RFC 9286 define o manifesto como um objeto assinado que enumera nomes e hashes dos objetos ligados ao ponto de publicação de uma CA. Assinaturas individuais não detectam toda substituição por versão antiga nem toda remoção em trânsito. Comparar o conjunto recuperado ao manifesto permite detectar formas específicas de omissão, modificação e repetição.

O escopo é estrito: certificados atuais emitidos pela CA, sua CRL mais recente e os demais objetos assinados correspondentes. Quando várias instâncias de CA compartilham um ponto, cada manifesto cobre apenas os produtos da própria instância. Uma listagem de diretório sem a CA e o manifesto aplicáveis não comprova coerência.

A RFC 9286 também exige novo manifesto ao finalizar mudanças, atualização dos hashes de objetos substituídos e publicação antes de nextUpdate. Isso cria evidência do conjunto, mas ainda não informa qual geração um cache ou parte confiante vê naquele instante.

O RRDP da RFC 8182 oferece a sequência de distribuição. A notificação contém identificador de sessão e serial atual. Um snapshot fornece a visão completa; cada delta representa um incremento de serial e inclui objetos publicados, substituídos ou retirados naquele evento. Assim, a parte confiante obtém uma visão pontual consistente ou avança incrementalmente.

O serial não é um relógio universal. Ele pertence a uma sessão e servidor. Uma parte confiante pode consultar antes da nova notificação, atravessar um cache, rejeitar um delta problemático ou voltar ao snapshot. Registrar apenas “serial avançou” perde a sessão, a notificação, o observador e a hora.

O registro deve começar pela solicitação: identidades do cliente e servidor, hash da mensagem assinada, tags, URIs, hashes anteriores e novos, horários de envio e resposta. Uma falha atômica não pode virar êxito parcial; um sucesso deve preservar a resposta assinada, não somente um indicador verde.

A segunda parte é o commit e o manifesto: ponto de publicação, arquivo e hash do novo manifesto, thisUpdate, nextUpdate, hash da CRL e conjunto enumerado. Telemetria interna pode ajudar em incidentes, mas não é observação pública.

A terceira parte é a distribuição: URI de notificação RRDP, sessão, serial e hashes de notificação, delta e snapshot. Uma verificação rsync guarda URI, horário e hash do conjunto separadamente. A quarta parte registra observações delimitadas: identidade e versão do software, hora, transporte, sessão, serial e resultados do manifesto, conjunto e validação.

Os estados REQUEST_AUTHENTICATED, SERVER_COMMITTED, MANIFEST_COHERENT, PUBLIC_VIEW_OBSERVED, RP_OBSERVED e EXCEPTION_OPEN mantêm as alegações proporcionais à prova. Uma visão antiga após o sucesso pode refletir a ordem das observações; um novo serial com manifesto incoerente continua sendo anomalia.

As RFCs não fixam um prazo mundial para todas as partes confiantes, não revelam caches privados e não definem um único esquema de auditoria operacional. Ausência em um observador não prova ausência global; presença em outro não prova convergência universal.

O registro, portanto, não promete sincronização impossível. Ele conecta o que o cliente pediu, o que o servidor confirmou, o que o manifesto enumerou, o que a distribuição pública serviu e o que observadores identificados receberam. Cada ator permanece autoridade em seu domínio, e nenhuma conclusão cresce além da evidência disponível.

Fontes