Resumo

  • Pertencer ao domínio T significava ser conhecido como compatível com Spec(T); confiar em um par exigia, no receptor, conexão segura e configuração que reconhecesse a associação desse par.
  • Uma identidade vinda de nó não confiável não carregava garantia de autenticidade ou integridade e não podia ser exibida, repassada nem usada por serviços.

O acordo não fechava todas as arestas

RFC 3324 partiu de uma limitação de SIP. Um usuário podia colocar em From o nome ou alias que desejasse, enquanto um agente de usuário nem sempre possuía chaves para autenticar outro agente diretamente. Um intermediário de rede, em posição de executar autenticação, poderia derivar uma identidade e entregá-la a participantes que entendessem as mesmas regras. A solução, porém, só funcionava se “participantes” não virasse sinônimo de crença indiscriminada.

O documento definiu o domínio T como um conjunto de nós conhecidos por obedecer a configurações e especificações reunidas sob Spec(T). Pessoas construíam esse conjunto. Um operador podia conhecer o comportamento de seus próprios equipamentos; operadores diferentes podiam formar um domínio maior por acordos bilaterais. A associação dizia que certos procedimentos deveriam ser seguidos. Não criava automaticamente sessões seguras entre todas as duplas, nem entregava a cada nó conhecimento completo dos demais.

A confiança operacional era avaliada a partir do receptor. B confiava em A somente se houvesse uma conexão segura entre os dois e se B tivesse configuração informando que A integrava o domínio. A relação tinha direção. B podia confiar em A sem que A confiasse em B. Um agente externo podia confiar em um intermediário interno sem entrar no domínio. Na figura do RFC, A, B e C estavam sob a mesma linha pontilhada; ainda assim, A confiava em C e não confiava em B.

Por isso a frase “recebido de um nó confiável” era inválida para o texto. Um nó não sabe necessariamente se qualquer outro participante do domínio é confiável para ele. A formulação correta era “recebido de outro nó em que ele confia”. Essa mudança obriga a guardar o ponto de vista: quem recebeu, qual foi o remetente imediato, qual conexão os uniu e qual configuração sustentou o reconhecimento.

A identidade não sobrevivia sem a proveniência

A Identidade Afirmada pela Rede era derivada por um intermediário SIP depois de autenticar a entidade. Poderia usar URI SIP, SIP seguro ou telefônico, desde que tivesse significado para o domínio ou a faixa responsável e conduzisse ao usuário ou à lógica que agia em seu nome. O método de autenticação, ou ao menos sua confiabilidade e força, deveria constar de Spec(T). O usuário podia indicar uma identidade preferida; a política decidia se ela influenciaria o valor final.

Quando o receptor recebia a afirmação de um par em que confiava, poderia entender que a geração e o transporte haviam seguido os procedimentos acordados. Mesmo assim, a validade não superava a promessa de Spec(T). Uma autenticação fraca não se tornava forte ao atravessar a fronteira. O domínio fornecia contexto para julgar a prova, não uma transformação mágica da prova.

Se a identidade chegasse de um nó não confiado, o receptor não saberia se os procedimentos haviam sido cumpridos. RFC 3324 dizia que não existia garantia de autenticidade ou integridade. Em seguida, definia o comportamento: não mostrar a informação ao usuário, não repassá-la a outros nós e não empregá-la como entrada de um serviço. Uma aplicação que apenas acrescentasse um ícone de dúvida ainda permitiria que um nome sem prova orientasse a decisão humana.

O canal seguro também tinha função delimitada. Mensagens não deveriam ser lidas ou alteradas sem detecção por terceiros, e B deveria saber que a mensagem vinha de A. A configuração local ligava A ao domínio esperado. Essas evidências não provavam sozinhas que a autenticação original foi correta, que todos os intermediários obedeceram à política ou que o URI correspondia a uma identidade jurídica. Cada camada precisava de recibo próprio.

Compatibilidade local não era passaporte universal

Os requisitos eram assumidamente de curto prazo. Eles cobriam a troca dentro de uma comunidade de dispositivos conhecidos por seguir o mecanismo e a entrega por conexão segura a uma entidade externa que confiasse diretamente no nó interno. Transporte geral entre hosts arbitrários da Internet estava fora do escopo. O capítulo de segurança advertia que, fora desse contexto, não havia garantia de que a informação não fora modificada ou sequer estivera correta desde o início.

Spec(T) tampouco precisava ser um único documento publicado. Era o conjunto acordado de informações sobre o que se afirmava, como fora determinado, qual autenticação era aceitável, como a integridade era mantida e qual política de privacidade vigorava. Ver uma cabeçalha sem conhecer esse conjunto revelava sintaxe, não a força da identidade.

A privacidade limitava ainda mais o transporte. Uma mensagem poderia indicar que a identidade não devia ser passada a outros usuários. Outra indicação separada poderia registrar que o próprio usuário pedira essa restrição, pois políticas poderiam distinguir intenção individual de razões legais ou operacionais. A identidade podia continuar dentro da rede confiada e desaparecer antes do usuário externo. Isso se aproxima da privacidade relativa ao observador de RFC 3323 sem se confundir com ela.

RFC 3325 depois forneceu extensões privadas concretas; RFC 5876 as atualizou. RFC 4474, RFC 8224 e RFC 8225 seguiram outra linhagem de identidade autenticada e PASSporT, enquanto RFC 4916 tratou da identidade conectada no diálogo. Essa evolução não transforma RFC 3324 em prova de implantação, conformidade ou identidade universal.

Sua contribuição histórica foi deixar a fronteira de validade visível. Um domínio podia organizar compatibilidade. A identidade só adquiria autoridade quando chegava por uma aresta dirigida que o receptor sabia justificar.

Fontes