Resumen

  • RFC 1484 llamó purported name al nombre amistoso introducido por una persona: era material para resolver uno o varios Distinguished Names, no el identificador almacenado.
  • La respuesta dependía del entorno local ordenado, el esquema, las entradas vigentes, los valores alternativos, el tipo de coincidencia y, a veces, la selección del usuario.
  • El DN elegido nombraba una entrada del árbol. No demostraba por sí solo quién controlaba esa entrada, qué autoridad tenía la persona ni qué ocurrió después.

Una palabra corta podía abrir árboles distintos

El ejemplo más revelador de RFC 1484 no es una cadena compleja, sino el orden de búsqueda. Con un solo componente, un cliente privado podía probar primero el departamento, luego la universidad, luego el país y por último la raíz. Con dos o tres componentes cambiaba la secuencia. Un cliente público estadounidense tenía otra lista.

Ese orden convertía el contexto local en comportamiento. “Kirstein” podía resolverse rápidamente dentro de una comunidad que ya esperaba ese apellido. Fuera de ella, el mismo texto podía producir varias personas, una organización o ningún resultado. El usuario no había expresado la base de búsqueda; el cliente la aportaba.

La propuesta trataba de acercar X.500 a una conversación. Si alguien decía un nombre en una reunión, debía ser posible escribirlo sin rellenar un formulario de país, organización, unidad y persona. La comodidad no salió de eliminar la estructura, sino de hacer que el sistema la infiriera.

El nombre amistoso era una hipótesis

RFC 1484 utilizó una expresión precisa: purported name. La cadena podía omitir tipos, abreviar niveles superiores, saltar unidades intermedias, usar valores alternativos, tolerar aproximaciones y escribir países de manera familiar. El directorio debía convertir esa hipótesis en uno o más DN.

Algunas omisiones seguían un esquema predeterminado. Otras exigían búsquedas por distintos atributos. Un fragmento de dos letras podía interpretarse como país, estado u organización según el lugar del árbol. Una abreviatura podía coincidir exactamente con un valor alternativo y sólo aproximadamente con otros nombres.

Por eso el documento recomendó guardar casi siempre el DN, no el nombre amistoso. Señaló un riesgo temporal que sigue siendo incisivo: una cadena no ambigua puede volverse ambigua cuando aparece una nueva entrada. La escritura no cambió; cambió el mundo que debía interpretarla.

La coincidencia tenía una máquina de estados

El algoritmo clasificaba resultados como exactos, buenos o pobres. Seguía siempre un exacto. Si no lo había, exploraba los buenos. Cuando sólo quedaban aproximaciones o subcadenas pobres, pedía decisión al usuario. Si este rechazaba todo, podía pasar al siguiente elemento del entorno.

No era una búsqueda neutra seguida de una interfaz. La interfaz participaba en la resolución. La forma de puntuar iniciales, puntuación, apodos, acrónimos y errores tipográficos decidía qué ramas se recorrían. El orden de los entornos decidía cuándo dejar de recorrerlas. La aceptación humana convertía una lista en una selección.

Un registro operativo necesita por ello algo más que “consulta correcta”. Debe conservar entrada original, reglas locales, filtros, base, alcance, estado del directorio, candidatos mostrados y descartados, respuesta humana y DN final. Si sólo queda el resultado, se pierde la explicación de por qué fue ese resultado.

RFC 4511 describe después la búsqueda LDAP con base, alcance, política de alias, límites de tamaño y tiempo, filtro y atributos. Puede haber entradas, referencias de continuación y una respuesta final. Ver una tarjeta plausible antes del cierre no prueba exhaustividad.

Encontrar el DN no cerraba la cuestión de identidad

El sustrato de directorio aparece en RFC 1309: una entrada ocupa una posición en el Directory Information Tree y su DN reúne los RDN del camino. La cobertura ya publicada de RFC 1309 trata la distribución entre DUA y DSA, alias, chaining, referrals y réplicas. El presente problema es anterior y más estrecho: cómo se adivina aquel camino.

RFC 1485 ofrecía la representación textual de un DN ya identificado. Luego llegaron RFC 1779, RFC 2253 y RFC 4514. Es una línea distinta: serializar una estructura, no descubrirla desde un nombre incompleto.

RFC 4514 advierte además que no define una cadena canónica. La igualdad entre DN se decide mediante la regla de matching del directorio. Una diferencia visual no basta para afirmar que hay dos entradas; una igualdad de bytes tampoco sustituye las reglas de tipos y valores.

RFC 4512 atribuye a cada tipo la sintaxis y las reglas con que se comparan valores. RFC 4518 prepara cadenas internacionalizadas para esas comparaciones. El texto visto, los puntos de código procesados, el valor normalizado y el DN seleccionado son recibos distintos.

La entrada representaba un objeto; no juraba por él

En el modelo LDAP, un DN refiere inequívocamente a una entrada. Una entrada es una colección nombrada de información que representa algún objeto de interés. Esa afirmación del modelo no autentica a la persona que usa el teclado ni certifica que todos los atributos sigan vigentes.

El servidor puede aplicar controles de acceso, ocultar información o devolver referrals. El cliente puede usar una instantánea antigua. El usuario puede escoger al homónimo. La aplicación puede atribuir al DN permisos que el directorio nunca definió.

La cadena probatoria continúa: autenticación del sujeto, autorización de la acción, versión de atributos relevante, registro de la operación y efecto observado. Un nombre fácil ayuda a descubrir; no otorga poder.

El prototipo dejó evidencia y preguntas

RFC 1484 informó de una implementación en FRED, dentro del PSI Pilot, y de otra interfaz prototipo para listas de distribución. La reacción de usuarios fue favorable. Esto prueba que hubo código y experiencia, no que toda la Internet adoptara el método.

La experiencia también halló fallos. Cuando había varias unidades organizativas y el usuario omitía una que no era hija inmediata, el algoritmo se comportaba mal. Los comodines iniciales podían rendir poco. El propio documento dejó por resolver ambigüedad, utilidad, rendimiento y variantes, y pidió evolución basada en experiencia.

El registro del RFC Editor conserva esa condición experimental. La sección de seguridad declaró que no discutía seguridad. No hay base para atribuirle privacidad, defensa contra enumeración, autenticación o una medición general de facilidad de uso.

La interfaz fue honesta cuando no fingió ser autoridad

Las ideas de Heng Lu sobre código en ejecución, decisión futura localizada y capas de realidad permiten leer el diseño sin confundir las capas. La notación común era mínima. El cliente local conservaba heurísticas. El directorio conservaba entradas. El usuario conservaba el acto de selección. La aplicación conservaba consecuencias.

La lección histórica no es que un nombre humano sea impreciso y deba prohibirse. Es que su precisión se produce durante una operación. Guardar sólo las palabras borra el contexto; guardar sólo el DN borra la decisión. La historia completa necesita ambos y los recibos intermedios.

Fuentes