Resumo

  • O rtt opcional do RFC 9891 é uma estimativa do cliente para o percurso de um Challenge Bundle e sua resposta. O servidor ACME continua responsável pelo intervalo aceito, por seus limites e pela comparação com a vida útil do desafio original.
  • Uma resposta íntegra e pontual comprova controle de um Node ID naquele desafio e sob aquela política. Ela não comprova propriedade duradoura, estabilidade de rota, emissão ou instalação do certificado, sessão TCPCL, entrega de Bundle ou efeito de aplicação.

Uma equipe viu o valor 300 no pedido de validação e o registrou como “prazo aprovado de cinco minutos”. A primeira informação dizia o que o cliente esperava da rede. A segunda dizia o que o servidor aceitaria. O protocolo só havia recebido a primeira.

O RFC 9891 estende o Automatic Certificate Management Environment para validar um DTN Node ID. O servidor cria uma autorização para o identificador bundleEID, oferece o desafio bp-nodeid-00 e envia um Challenge Bundle ao Node ID. O BP Agent preparado pelo cliente devolve um Response Bundle associado à conta, ao desafio e ao Bundle específico.

Em uma Delay-Tolerant Network, atrasos longos e desconexões podem fazer parte do desenho. A validação precisa acomodar essa realidade sem deixar que a parte interessada no certificado escreva sozinha a regra de aceitação.

A previsão entra no cálculo, não comanda o relógio

O Response Object pode levar um rtt em segundos. O RFC o chama de hint e afirma que não é authoritative. Em condições normais, o servidor deve usar duas vezes o valor informado como ponto de partida e aplicar limites inferiores e superiores próprios da rede. Em uma DTN apenas terrestre, o teto recomendado não passa de sessenta segundos.

Redes com outras características podem exigir outro teto. Mesmo assim, o princípio permanece: o cliente conhece sua expectativa de caminho; o servidor conhece sua capacidade, a duração aceitável do estado de validação, a exposição a abuso e a política da autoridade certificadora.

O cliente não pode autorizar o início antes que o BP Agent esteja configurado para responder. Como a rota efetiva não é garantida, a estimativa deve ser pessimista. Isso impõe ao cliente uma obrigação de prontidão e honestidade, não um direito de estender a janela.

O Challenge Bundle original carrega o início e a Lifetime que controlam a decisão. O Response Bundle também declara criação e vida restante, mas o servidor verifica a chegada contra o intervalo do desafio. A mensagem de volta não pode reabrir uma porta fechada alterando seu próprio prazo.

Janelas maiores beneficiam nós intermitentes, mas consomem estado e ampliam o período em que tráfego de repetição ou negação de serviço precisa ser filtrado. Janelas menores protegem recursos, mas podem excluir o caso de uso. A escolha é política operacional, não uma constante matemática escondida no RTT.

Duas partes do token, duas superfícies de observação

O retorno de um Bundle não basta. O RFC 9891 separa o material necessário entre o canal ACME e o canal BP.

token-chal é exclusivo da autorização e permanece no canal ACME. Vários Challenge Bundles da mesma tentativa compartilham esse valor. Cada Bundle recebe um token-bundle exclusivo, visível na DTN. O BP Agent combina ambos com o thumbprint da chave da conta, calcula a Key Authorization e devolve um digest.

Para aprovar uma perspectiva, o servidor verifica chegada dentro da janela, Source Node ID igual ao alvo, Block Integrity Block confiável sobre bloco primário e payload, tokens corretos, algoritmo aceito e digest esperado. A ausência de resposta antes do prazo também produz falha.

O resultado liga a pessoa que controla o contexto da conta à capacidade de responder pelo Node ID em um momento delimitado. Não estabelece uma identidade civil e não promete que a próxima rota funcionará.

O RFC 9171 diz que Node ID é um Endpoint ID singleton capaz de identificar um BP Node. Ele não tem garantia de unicidade global, e um nó pode usar vários Node IDs. A Administrative EID é única para o nó dentro de um esquema URI específico.

Os registros de ACME da IANA e do Bundle Protocol da IANA tornam bundleEID, bp-nodeid-00, o registro administrativo e os esquemas dtn e ipn reconhecíveis por implementações independentes. Eles coordenam identificadores de protocolo; não observam a alocação local, a rota nem a legitimidade da organização.

Mais perspectivas exigem mais contabilidade

O servidor pode enviar desafios de várias origens ou por rotas distintas. Como cada Bundle tem token próprio, as respostas permanecem separadas. A técnica reduz alguns ataques em rota única, mas não garante que os caminhos lógicos sejam fisicamente independentes.

O RFC deixa a agregação à política do servidor. Uma regra recomendada exige que a perspectiva principal tenha sucesso e aceita no máximo uma falha secundária. A classificação de principal e secundária também depende da implementação.

Assim, valid resulta de observações e de uma regra. Guardar apenas o resultado final impede distinguir três sucessos de um sucesso principal com uma falha tolerada. Também impede explicar por que duas CAs chegaram a decisões diferentes com os mesmos retornos.

Um gateway de integridade pode validar localmente a origem e acrescentar um BIB. O destinatário precisa configurar qual Security Source pode atestar quais padrões de origem. A assinatura preserva o testemunho; não define o alcance institucional do testemunho.

O caráter Experimental do RFC é relevante. Ainda se avaliam utilidade prática, ataques em rota, diversidade e delegação de autoridade entre a CA e outra rede. Uma entrada de registro permite a experiência; não anuncia seu sucesso.

Essa divisão ecoa Especificação inicial mínima e decisão futura localizada, de Heng Lu. O padrão fixa tokens, comparação, integridade e estrutura de tempo. Cada participante mantém decisões cuja consequência ele precisa suportar.

A autorização válida ainda não está em uso

No RFC 8555, challenge, authorization e order têm estados próprios. O desafio válido autoriza a conta para um identificador e uma validade determinada. Não é o certificado.

O pedido descrito no RFC 9891 pode combinar NODE-ID, DNS-ID e IP-ID. Cada um precisa de validação. A CA ainda aplica política de emissão, usos da chave e restrições de algoritmo. Um retorno correto no canal DTN não obriga a emissão.

Depois da emissão, o RFC 9174 define como um certificado pode autenticar NODE-ID durante uma sessão TCPCL. O peer pode exigir identidade de rede, Node ID ou ambos e encerrar a sessão se a validação falhar.

O RFC 9891 deixa a instalação do certificado no BP Agent para a implementação. Logo, autorização, emissão, instalação, seleção em TLS, sessão, encaminhamento e resultado final precisam de evidências distintas.

O RFC 9172 fornece a arquitetura BPSec. A verificação do BIB prova integridade dos dados cobertos em um contexto; a confiança na Security Source continua sendo uma escolha de política.

Em Código em execução como evidência primária, Heng Lu exige que a especificação e a execução permaneçam separadas. Em Camadas da realidade e poder simbólico, ele mostra como um rótulo pode ganhar autoridade fora do que observou. Um status valid sem tempo, perspectiva e política sofre exatamente esse risco.

O cliente estimou a demora, e o servidor ganhou informação. O servidor manteve a janela, e a prova manteve seu limite. A arquitetura funciona porque cooperação não significa transferência silenciosa de autoridade.

Fontes