Resumen

  • RFC 3494 sostuvo que una implementación independiente y fiel a RFC 1777 no interoperaría con las implementaciones LDAPv2 existentes, porque la práctica había adoptado sintaxis y semánticas diferentes.
  • El paso a Historic orientó el trabajo futuro hacia LDAPv3, pero no apagó equipos heredados ni convirtió el número de versión en prueba de autenticación, integridad o confidencialidad.

La especificación había dibujado un repertorio estrecho. RFC 1777 definía LDAPString sobre OCTET STRING, pero limitaba sus caracteres a IA5; RFC 1778 completaba las representaciones de sintaxis y el contexto de T.61. RFC 3494 encontró otra realidad: unas implementaciones usaban ISO 8859-1, otras UCS-2, otras UTF-8 y otras el juego de caracteres local.

No eran cinco nombres para la misma transformación. Cada elección cambiaba qué secuencias podían enviarse y cómo se reconstruía un nombre. Dos productos podían funcionar en una oficina y fallar al incorporar un apellido o una organización de otra escritura. Un cliente nuevo podía superar todas las pruebas derivadas del RFC y ser menos útil que otro que imitara una desviación popular.

El segundo ejemplo cabía en una letra. RFC 1777 exigía el nombre textual de X.500: para el atributo con OID 2.5.4.10, organizationName. Los productos LDAPv2 existentes solían usar o, el NAME corto del esquema LDAPv3 definido en la familia de RFC 2252. La convención del sucesor había entrado en el predecesor sin modificar su contrato nominal.

La abreviatura no eliminaba las demás capas. El token debía resolverse a un tipo, el esquema debía aceptarlo, el servidor tenía que autorizar la operación y la aplicación debía interpretar el resultado. Un alias podía reparar la compatibilidad de una pareja concreta y a la vez ocultar qué forma se había guardado, firmado o auditado.

RFC 3494 eligió bien su sujeto: la adhesión general a la especificación. No afirmó que cada servidor LDAPv2 fuera incapaz de hablar con cualquier cliente. Linajes que compartían codificación y alias podían interoperar. El problema era que un tercero independiente ya no podía obtener esa compatibilidad sólo leyendo el documento público.

Ahí aparece el bloqueo. El proveedor instalado conserva sus irregularidades porque corregirlas rompe clientes. El cliente copia esas irregularidades porque necesita servicio. Las pruebas terminan midiendo semejanza con un producto, no conformidad con una norma. El estándar sigue disponible para todos, pero la información decisiva vive en la historia de despliegue.

La seguridad agravó esa pérdida de autoridad. LDAPv2 no ofrecía integridad ni confidencialidad y, según RFC 3494, no soportaba mecanismos modernos basados en DIGEST-MD5, Kerberos V o claves públicas X.509. RFC 1777 permitía un simple bind con contraseña en claro y mecanismos Kerberos 4. RFC 3377 reunió LDAPv3 con los textos de autenticación y seguridad de transporte que respondían a la advertencia previa del IESG.

Pero migrar la etiqueta no completa el control. RFC 4510 reorganizó después la especificación LDAP y RFC 4513 detalló sus métodos de autenticación y seguridad. Un operador aún debe elegirlos, proteger el canal, verificar credenciales y aplicar autorización. Una solicitud Bind con versión 3 es evidencia de versión solicitada, no de sesión protegida.

El cambio de estado arrastró dependencias. RFC 1781 se apoyaba en sintaxis de nombres de RFC 1779 que RFC 2253 eliminó. RFC 2559 aplicaba LDAPv2 a repositorios PKIX, dependía de RFC 1777 y actualizaba RFC 1778. RFC 3494 recomendó mover esos textos, el núcleo LDAPv2 y sus antecesores RFC 1484, 1485, 1487 y 1488 a Historic.

Historic pertenece al registro documental. RFC 2026 lo asigna a especificaciones reemplazadas u obsoletas. RFC 2400 advertía que el rótulo de una palabra sólo orienta y debe leerse con la declaración de aplicabilidad. La recomendación de 2003 decía a los desarrolladores que no implementaran LDAPv2 según RFC 1777 y a los despliegues que eligieran LDAPv3. No cerraba puertos, no descargaba procesos y no contaba el tráfico residual.

El episodio no niega la aportación de LDAP. Reducir el coste de entrada a X.500 permitió aplicaciones reales y una base instalada capaz de formar sus propias convenciones. Precisamente ese éxito hizo visible el conflicto: el documento, el código y la práctica ya no apuntaban al mismo sitio. RFC 3494 cambió el destino de la coordinación futura sin fingir que el pasado había desaparecido.

La comprobación correcta conserva recibos separados para estado del RFC, comportamiento de la implementación, configuración, versión negociada, codificación, alias de esquema, mecanismo de seguridad, intercambio, autorización y efecto aplicativo. Historic prueba una decisión institucional. No prueba ninguno de los estados de ejecución posteriores.

Fuentes