Resumo

  • RFC 1485 serializava um DN já conhecido em ASN.1; a descoberta a partir de um nome humano incompleto pertencia a outro problema.
  • Vírgula ou ponto e vírgula, dobra de linha, aspas, OID, hexadecimal e RDN multivalorado permitiam formas visuais diferentes.
  • LDAP depois recusou uma cadeia canônica única: igualdade depende de schema e matching rule, e confiança na entrada exige provas adicionais.

O que precisava caber no papel

RFC 1485 partiu de uma restrição física: usuários precisavam trocar Distinguished Names sem um protocolo de diretório. Um DN X.500 era uma estrutura ASN.1; uma mensagem e um cartão precisavam de caracteres. O registro do RFC Editor data a publicação de julho de 1993 e hoje a classifica como Historic.

Não se tratava de adivinhar uma pessoa. RFC 1484 começava com um purported name e o resolvia dentro de um ambiente e de um diretório mutável. RFC 1485 recebia o DN pronto. Sua promessa era transportar a estrutura em texto de maneira inequívoca.

A forma agradável não apagava o caso difícil

Para nomes usuais, o leitor via CN, O, OU, L, ST e C. Para um tipo sem palavra curta, havia OID pontuado; para um valor inconveniente, havia hexadecimal. O próprio RFC chamou o escape geral de feio. O comentário revela a escolha: favorecer leitura no caminho comum sem perder a capacidade de representar qualquer DN.

O componente mais específico vinha primeiro. Vírgula ou ponto e vírgula separavam RDNs. Espaços e quebras de linha podiam montar outra apresentação. Aspas e escapes protegiam sinais especiais. O + ligava várias AVAs no mesmo RDN.

Uma diferença de aparência podia ser apenas layout. Uma diferença pequena na posição de uma vírgula podia alterar a árvore reconstruída. O contrato precisava distinguir as duas coisas.

A linha escondia dois tipos de ordem

RFC 4512 diz que um DN concatena RDNs ao longo da árvore e que cada RDN é um conjunto não ordenado de AVAs. A ordem dos RDNs carrega caminho; a ordem das AVAs dentro de um RDN não carrega identidade. Um formato linear projeta ambas no mesmo papel.

Por isso o parser precisa conhecer a gramática, os limites dos valores, o registro de descritores e o schema. O olho não decide se duas sequências ao redor de + são diferentes. Tampouco decide se uma etiqueta curta corresponde ao mesmo object identifier.

Os sucessores mudaram a moldura

O registro de RFC 1779 e o texto mostram a substituição de 1485, com escapes ajustados e mistura de separadores desaconselhada. RFC 2253 levou a cadeia para LDAPv3 e UTF-8; seu registro marca a etapa seguinte. RFC 4514 e seu registro definem hoje a representação LDAP.

Uma cadeia arquivada sem versão perde parte do sentido. Um cliente pode tolerar ponto e vírgula; outro, rejeitá-lo. Um descritor pode ser registrado em um ambiente e desconhecido em outro. A biblioteca Unicode pode preparar caracteres antes da comparação. Migração textual não é uma troca neutra de campo.

Não há ortografia soberana do DN

RFC 4514 afirma que não define representação canônica. Um algoritmo recomendado gera cadeias, mas outros podem gerar formas conformes. A igualdade deve seguir distinguishedNameMatch, em RFC 4517.

A regra compara RDNs por posição, ignora a ordem de AVAs dentro de cada RDN e aplica a regra de igualdade do tipo a cada valor. RFC 4518 prepara strings internacionais com mapeamento, normalização, caracteres proibidos e tratamento de espaços. Uma comparação necessária ainda pode resultar Undefined.

Usar igualdade bruta de bytes como chave cria outra política. Duas renderizações do mesmo DN podem virar dois cadastros; textos parecidos interpretados por schemas diferentes podem colidir. O índice rápido não é prova do significado correto.

O exemplo Sam preservava menos do que mostrava

Em RFC 4514, um valor TeletexString e outro PrintableString com “Sam” podem aparecer como CN=Sam. A cadeia não garante reconstrução do mesmo BER ou DER. Quando o DER exato importa, inclusive em determinados usos de certificado, a recomendação é conservar a forma hexadecimal.

Portanto há pelo menos três recibos: estrutura recuperada, igualdade do DN e bytes de origem. A cadeia legível pode servir ao primeiro sem servir ao terceiro. Nenhum deles, isoladamente, autentica o remetente.

O DN também pode revelar nome, endereço, localização e vínculo institucional. RFC 4514 discute controles; RFC 1485 declarou que não tratava segurança. Sintaxe não é política de privacidade.

A entrada ficava do outro lado

RFC 4512 afirma que o DN aponta sem ambiguidade para uma entrada da árvore. A entrada guarda atributos sobre um objeto. Ainda é preciso provar que a entrada é atual, que o ator é quem afirma ser, que possui autorização e que a ação aconteceu.

As notas de Heng Lu sobre primazia do código em operação, especificação mínima e decisão localizada e camadas da realidade ajudam a distribuir responsabilidades. A gramática transporta. O schema interpreta. O diretório registra. A aplicação autentica, autoriza e mede o efeito.

RFC 1485 deu mobilidade ao nome. A disciplina histórica consiste em não dar soberania ao texto móvel.

Fontes