Resumo

  • draft-ietf-dtn-eid-pattern-11 propõe formas textuais e CBOR para conjuntos de Endpoint IDs e um OtherName BundleEIDPattern para certificados X.509.
  • Como não há uma lógica geral de subconjunto entre padrões, as restrições EID não alteram a validação comum do caminho PKIX; elas são aplicadas depois ao Node ID concreto.
  • Uma correspondência pertence a um processador e a um uso. Esquemas suportados, normalização, elisão, limites e lógica superior determinam o resultado e sua consequência.

O equipamento que não conhecia o esquema

O Bundle Protocol usa EIDs como origem e destino. BPSec emprega EID como identidade da fonte de segurança; TCPCL, como identidade do par. Agentes também precisam selecionar grupos de EIDs para roteamento, encaminhamento, entrega, política de segurança e camada de convergência.

A proposta oferece uma estrutura comum, incluindo intervalos compactos para ipn. Na forma any-SSP, o emissor pode omitir o nome textual ou o número de um esquema se acreditar que todos os decodificadores conseguirão reconstruí-lo. Quando essa hipótese falha, duas versões podem extrair conjuntos diferentes da mesma entrada. A configuração visível permanece; a tabela de esquemas muda; a decisão muda junto.

Um esquema desconhecido pode causar falha total ou ser ignorado. Numa tabela de encaminhamento, a entrada se torna inutilizável e o nó passa para uma alternativa ou para o padrão. Essa escolha não foi uma seleção deliberada da rota padrão. Foi um desvio produzido por falta de capacidade. O recibo operacional precisa registrar as regras que não participaram, além da regra vencedora.

Identificador e seletor podem ter a mesma aparência

Um padrão textual com um único item pode ser idêntico ao EID exato que ele seleciona. Os caracteres não bastam para dizer se o valor nomeia um endpoint ou escolhe uma população. O envelope fornece o tipo.

Essa distinção limita acesso. A seção de segurança alerta que interpretar um EID como EID Pattern pode elevar privilégios. PKIX usa OtherNames distintos; em texto, um | inicial torna o padrão inequivocamente diferente de um EID válido. Um banco intermediário que converte ambos em “string de identidade” descarta a proteção.

Normalização não corrige essa perda. Itens são logicamente desordenados e podem ser reordenados, deduplicados ou fundidos. O processador pode manter o conjunto equivalente sem guardar a codificação recebida. Para executar, basta. Para explicar por que um nó foi aceito ontem, é preciso reter entrada, resultado normalizado, versão e catálogo de esquemas.

A cadeia válida encontra uma segunda porta

O novo id-on-bundleEIDPattern é um SAN otherName cujo valor UTF8String contém um padrão e não é uma URI. Um certificado final pode usar NODE-ID ou EID-PATTERN-ID para autenticar o Node ID TCPCL; o perfil BPSec COSE recebe regra correspondente para a entidade da operação de segurança.

O detalhe decisivo está em Name Constraints. Padrões EID não definem uma relação universal de subconjunto. Por isso, essas restrições não conseguem limitar diretamente SANs subordinados e não interferem na validação de caminho do RFC 5280. Elas entram na validação final da identidade: o Node ID concreto deve respeitar todos os padrões permitidos e excluídos encontrados nas CAs do caminho.

Uma cadeia pode, então, ser criptograficamente válida e o Node ID continuar inválido. Os estados respondem a perguntas diferentes. Um painel com apenas “certificado válido” encobre a segunda decisão.

Dentro de um padrão, vários itens formam OR. AND, NOT e o significado de padrões separados são definidos pelo contexto. *:** também muda de poder: não acrescenta nada em subárvores permitidas, equivale a bloquear o uso bundle-security nas excluídas e pode capturar todos os destinos numa regra de encaminhamento. A sintaxe é reutilizável; a autorização não.

O documento é a revisão 11, atualizado em 23 de setembro de 2026 e com expiração em 27 de março de 2027. Datatracker o classifica como trabalho ativo do grupo DTN, sem intended RFC status no campo da API; o cabeçalho declara Standards Track. O artigo não converte essa diferença em RFC, consenso ou implantação.

A Minimum Initial Specification de Lu Heng sugere o limite: padronizar a representação e a correspondência deterministas necessárias à interoperabilidade; manter consequência e aceitação locais e explícitas. Running-Code Primacy dá precedência ao processador realmente executado e ao Node ID realmente testado. As camadas de realidade separam bytes, conjunto, caminho, identidade, sessão, operação, encaminhamento e entrega.

Fontes e limites

As fontes não provam OID atribuído, implementação, prática de emissão, interoperabilidade, ataque, incidente, adoção, desempenho ou resultado comercial.