Resumen

  • RFC 1558 representó como texto prefijo el Filter binario de LDAP. Los signos visibles definían conjunción, alternativa, negación, comparación, presencia y subcadena.
  • El filtro no era la búsqueda entera: objeto base, alcance, alias, límites, reglas de coincidencia, control de acceso, atributos pedidos y secuencia final seguían siendo entradas y recibos independientes.
  • RFC 1960, RFC 2254 y RFC 4515 cambiaron el estatus y precisaron LDAPv3, UTF-8 y escapes de octetos. RFC 1558 era Informational y no discutía seguridad; no prueba un incidente ni una vulnerabilidad actual.

El carácter que podía ampliar la consulta

En la gramática de RFC 1558, attr=* pregunta por la presencia de un atributo. En (o=univ*of*mich*), los asteriscos delimitan una coincidencia por subcadenas. Si el asterisco pertenece al valor, el documento de 1993 indica que debe precederse con barra inversa.

La diferencia visual es pequeña, pero la población seleccionada puede cambiar por completo. Lo mismo ocurre con la estructura prefija. & exige filtros hijos, | ofrece alternativas y ! niega. El ejemplo (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) es un árbol de decisiones, no una descripción del árbol.

El registro de Datatracker y la ficha de RFC Editor fijan diciembre de 1993 y la categoría Informational. La copia de texto permite contrastar el contenido y la superficie de erratas separa correcciones. El memo declara que no especifica un estándar de Internet y que no discute seguridad. Por eso no debe presentarse como informe de una inyección, una brecha o un producto vulnerable.

El texto representaba una pieza, no la operación completa

RFC 1487 ya colocaba el Filter BER dentro de SearchRequest junto al objeto base, el alcance, el tratamiento de alias, límites de tamaño y tiempo, la opción de devolver solo tipos y la selección de atributos. RFC 1488 aportaba las representaciones de valores de su época. RFC 1558 normalizó la cara humana del Filter, no todos esos controles.

El mismo predicado bajo otra base examina otra zona. wholeSubtree puede abarcar más que singleLevel; seguir alias puede abrir trayectorias adicionales; un límite puede cortar la respuesta; seleccionar atributos cambia qué datos se solicitan. Una revisión que compara solo la cadena no puede probar qué búsqueda se ejecutó.

El protocolo actual, RFC 4511, con su registro oficial, obliga a distinguir sintaxis y evaluación. Cada filtro produce TRUE, FALSE o Undefined. Solo TRUE permite devolver una entrada, y aun así se aplican restricciones de acceso. Un atributo desconocido, una regla inadecuada o un valor inválido pueden producir Undefined.

La salida tampoco es un sí único: llegan cero o más SearchResultEntry y SearchResultReference, y después un SearchResultDone. Una referencia señala terreno todavía no explorado; una entrada puede carecer de valores por la petición o la política. Coincidencia, devolución, completitud y terminación son hechos distintos.

De IA5 a UTF-8 y escapes de octetos

RFC 1960 conservó la forma prefija y sustituyó a RFC 1558 como Proposed Standard, según su ficha. Más tarde fue sustituida por RFC 2254.

RFC 2254 incorporó filtros extensibles de LDAPv3 y un entorno UTF-8; los octetos especiales pasaron a representarse con barra inversa y dos dígitos hexadecimales. Su registro conserva esa transición.

RFC 4515, identificada en su página de estado, exige escapar los octetos de *, (, ), barra inversa y NUL, y define cadenas UTF-8 válidas. Su (cn=*\2a*) conserva los asteriscos exteriores como operadores de subcadena, mientras \2a representa un asterisco literal.

El historial de escapes demuestra por qué una captura visual no basta. Sin los octetos originales, la rutina usada y el árbol analizado, no se puede atribuir con seguridad si el carácter era valor u operación.

La legibilidad tenía un alcance limitado

La forma común fue una mejora: permitió revisar configuración, compartir filtros y observar un objeto que en la red seguía siendo BER. Su autoridad legítima terminaba en la representación fiel.

La doctrina de Heng Lu sobre una especificación inicial mínima y decisiones futuras localizadas ayuda a conservar ese límite. Running-Code Primacy desplaza la prueba hacia el analizador y el servidor que funcionaron realmente. Las capas de realidad separan cadena, árbol, BER, evaluación, acceso, respuesta y acción posterior.

Las fuentes no miden adopción, no identifican una instalación actual, no narran una intrusión y no prueban exposición de datos. La secuencia de RFC documenta una evolución técnica, no una migración universal. La contribución duradera de RFC 1558 fue hacer inspeccionable el Filter; el trabajo pendiente fue hacer inspeccionable su poder.

Fuentes