Resumen

  • RFC 1485 convertía en texto un DN estructurado que ya existía; no resolvía un nombre amistoso incompleto.
  • Separadores, plegado, comillas, OID, valores hexadecimales y RDN multivaluados permitían representaciones visibles distintas.
  • Las reglas LDAP posteriores niegan una cadena canónica y separan comparación, entrada de directorio, autenticación, autorización y resultado.

La ambigüedad podía desaparecer sin crear autoridad

El objetivo de RFC 1485 era preciso: representar sin ambigüedad un Distinguished Name de X.500 cuando dos usuarios no estaban intercambiando el protocolo del directorio. La ficha histórica fecha el RFC en julio de 1993 y hoy lo registra como Historic.

El DN ya estaba determinado. Esa frontera lo distingue del RFC 1484 sobre User Friendly Naming, donde una expresión incompleta debía buscar y seleccionar una entrada. Aquí el problema era de serialización: ¿cómo conservar una estructura ASN.1 en una forma que cupiera en una tarjeta, un mensaje o una frase?

La respuesta tenía que ser intuitiva para nombres corrientes y general para cualquier DN. Por eso la sintaxis ofrecía un camino bonito y otro deliberadamente áspero. Los tipos comunes aparecían como CN, L, ST, O, OU o C. Un tipo raro podía identificarse con OID punteado y un valor difícil podía conservarse en hexadecimal. La legibilidad era una optimización, no el modelo de datos.

Una línea no era la estructura

RFC 1485 colocaba primero el componente más específico. Aceptaba coma o punto y coma entre RDN, espacios opcionales, saltos de línea y delimitación con ángulos en texto corrido. Las comillas y escapes protegían signos especiales. El + reunía varias afirmaciones de tipo y valor en un solo RDN.

Un nombre podía aparecer en una línea o en cuatro. La puntuación podía cambiar dentro de lo permitido. Dos AVA podían invertir su posición visible dentro del mismo RDN. RFC 4512 explica por qué: el RDN es un conjunto no ordenado, mientras que el DN concatena RDN a lo largo del árbol. La forma lineal debía transportar ambas propiedades.

El parser, no el parecido visual, decide dónde termina un valor citado, qué signo separa componentes y qué identificador corresponde a una etiqueta. Guardar solo una captura de pantalla pierde esos recibos.

Cada relevo cambió el contrato

La ficha de RFC 1779 confirma que reemplazó RFC 1485. Su texto afinó los escapes y desaconsejó mezclar separadores. RFC 2253 llevó la representación a LDAPv3 y UTF-8; la ficha muestra que también quedó obsoleto. La forma actual está en RFC 4514 y su registro.

Esta secuencia no vuelve falso el intento de 1993. Muestra que una cadena histórica necesita versión. Qué descriptor era conocido, qué escape era válido y cómo se decodificaba un octeto dependían del perfil. El software que migra miles de DN por búsqueda y reemplazo está tomando una decisión de protocolo sin nombrarla.

Igualar texto era otra política

RFC 4514 dice que no existe una representación canónica de DN. Define una salida recomendada, pero permite otros algoritmos que produzcan cadenas conformes. La igualdad debe evaluarse con distinguishedNameMatch de RFC 4517.

La regla exige el mismo número de RDN en las mismas posiciones. Dentro de cada RDN, el orden de las AVA no importa; cada valor se compara según la regla de igualdad de su tipo. RFC 4518 prepara cadenas internacionales mediante mapeo, normalización, prohibiciones y tratamiento de espacios. El resultado puede ser verdadero, falso o indefinido.

Por eso una clave única basada en caracteres puede romper el directorio de dos maneras. Puede rechazar como distintos dos rendidos del mismo DN. También puede aceptar como iguales dos textos que se parsean bajo esquemas diferentes. La eficiencia de la base de datos no corrige la semántica que decidió ignorar.

La procedencia se podía evaporar en CN=Sam

RFC 4514 observa que un valor X.501 TeletexString y otro PrintableString pueden producir el mismo CN=Sam. La cadena ya no garantiza reconstruir el BER o DER original. Si una aplicación necesita el DER exacto, como en ciertos pasos de verificación de certificados, debe conservar la forma hexadecimal.

El ejemplo separa tres controles: reversibilidad de la estructura, igualdad del nombre y fidelidad de los bytes originales. No son sinónimos. Tampoco son autenticación. Que un DN refiera sin ambigüedad a una entrada, como establece RFC 4512, no demuestra quién envió la cadena, quién controla la entrada o qué atributos siguen vigentes.

Los DN pueden exponer nombres, direcciones, ubicaciones y afiliaciones. RFC 4514 recomienda reglas de nombre y controles de seguridad. RFC 1485 no trató la seguridad. La ausencia no debe rellenarse con la apariencia seria de una cadena jerárquica.

El nombre viajaba; la decisión seguía local

La primacía del código en funcionamiento de Heng Lu pide comprobar qué hace realmente el sistema. Su especificación mínima con decisión local limita lo común a lo necesario. Y sus capas de realidad impiden que el símbolo ocupe el lugar del hecho.

Aplicado aquí: la gramática transporta el DN; el esquema decide tipos y coincidencias; el directorio ofrece una entrada; la aplicación autentica, autoriza y registra el efecto. RFC 1485 resolvió el primer paso. Su valor histórico crece cuando no lo confundimos con los demás.

Fuentes