Resumen

  • La RFC 6920, publicada en abril de 2013, definió los nombres Named Information (ni): el algoritmo y el resumen calculado identifican un objeto digital. La autoridad opcional de una URI ayuda a buscarlo, pero no decide si dos nombres señalan los mismos bytes.
  • El esquema puede traducirse a una URL HTTP(S) bajo /.well-known/ni/. El servidor ofrece bytes candidatos y el cliente puede comprobarlos con el resumen. IANA registra los nombres y longitudes de los algoritmos, no el inventario de copias disponibles.
  • La integridad depende de que el nombre esperado llegue de una fuente fiable y de que el cliente haga el cálculo. Una captura fechada de la petición, la respuesta y esa comparación demostraría el uso concreto del mecanismo.

El servidor podía cambiar el archivo sin cambiar el enlace

En la web, una URL reúne un esquema, un servidor y una ruta. Esa combinación dice dónde preguntar. Una institución puede publicar una nueva versión en la misma ruta y conservar intactos los enlaces que conducen a ella. Sirve para contenidos vivos. Si alguien necesita una edición exacta, la comodidad se vuelve una incertidumbre práctica: recibir una respuesta correcta desde el servidor esperado no prueba que haya recibido los bytes esperados.

Los resúmenes criptográficos ya se insertaban en distintos identificadores, cada uno con su propia gramática. La RFC 6920 dio una forma común a esa práctica. Una URI ni nombra el algoritmo, coloca un punto y coma y añade el resumen en base64url sin caracteres de relleno. Por defecto se calcula sobre los bytes del objeto que se espera recibir. Cuando otro protocolo define un material de entrada distinto, debe explicar esa regla.

La diferencia es una cuestión de autoridad. Con una URL ordinaria, el servidor controla en gran medida qué devuelve la ruta. Con un nombre basado en el resumen, el emisor del nombre fija una identidad que el servidor no puede modificar sin producir otro valor. Dos servidores pueden entregar copias idénticas. Uno puede desaparecer y otro continuar el servicio. El nombre permanece mientras permanezcan los bytes y el algoritmo.

La RFC formula la comparación con precisión. El cliente debe mirar el algoritmo y el valor del resumen, incluida la longitud indicada, e ignorar otros componentes como la autoridad opcional o los parámetros de consulta. Una URI con un servidor y otra sin servidor pueden designar el mismo objeto. La dirección puede orientar la búsqueda, pero no vota en la decisión sobre qué archivo es.

La red volvió a pedir una dirección

Eliminar el servidor de la prueba de identidad no elimina el trabajo de encontrarlo. La RFC 6920 ofrece una conversión a HTTP o HTTPS: la petición va a una ruta /.well-known/ni/ con el algoritmo y el valor en el camino. Si el nombre ni indica una autoridad, la conversión usa ese servidor; si no, la aplicación puede elegirlo a partir del contexto. El servidor también puede redirigir la petición. Al término del viaje, queda la comparación entre los bytes recibidos y el resumen que figuraba en el nombre.

La conversión no promete que el objeto esté allí. Un nombre impecable puede conducir a un servidor vacío o inaccesible. Ese fallo es de disponibilidad. Cuando llegan bytes diferentes de los nombrados, el problema es de identidad. Mezclar ambas cosas bajo la etiqueta «enlace roto» ahorra palabras pero esconde quién debe actuar.

La división de trabajo tiene tres piezas. Quien entrega al cliente el nombre establece qué bytes se esperan. Quien aloja el objeto decide si una copia estará disponible. Quien programa el cliente decide si verificará el vínculo entre el nombre y los datos. La RFC permite procesar identificadores ni sin hacer siempre esa verificación. La sintaxis estandarizada proporciona la herramienta; la comprobación vive en el código.

También se definieron una representación binaria, útil para protocolos con poco espacio, y una forma nih más apta para decirse en voz alta gracias a caracteres hexadecimales y un dígito de control. Son formatos de transporte del nombre. Ninguno proporciona por sí mismo almacenamiento ni distribución.

El registro no guarda el objeto

Para que varios programas interpreten el nombre del mismo modo, necesitan designaciones compartidas para los algoritmos y sus longitudes. El registro Named Information de IANA ofrece esas entradas y el parámetro ct de tipo de contenido. La RFC 6920 exige compatibilidad con SHA-256 completo y contempla resúmenes truncados con nombres explícitos. Al acortar el valor, aumenta la posibilidad de colisión; por eso la longitud debe quedar visible en el identificador.

IANA coordina el vocabulario. Su tabla no contiene el archivo ni una lista de máquinas que lo mantienen disponible. Pedirle eso sería confundir una regla para escribir identidades con un servicio de reparto. La estrechez de la función también limita el poder institucional: una oficina puede evitar que los programas discrepen sobre el nombre de un algoritmo sin convertirse en propietaria de cada objeto nombrado.

El límite de seguridad merece igual claridad. La propia RFC 6920 advierte que el resumen solo enlaza un nombre con unos bytes hasta el grado de confianza que merezca el nombre original. Un atacante puede entregar un archivo peligroso y una huella que coincida perfectamente con él. El cálculo verifica consistencia; la procedencia del nombre se resuelve en otro paso. Publicar una huella tampoco oculta un objeto fácil de adivinar: alguien puede probar candidatos y comparar sus resúmenes.

El documento y el registro oficial prueban el formato, la regla de comparación y la conversión a HTTP. Para atribuir el mecanismo a un producto o archivo concreto haría falta un registro fechado de la entrega del nombre, la recuperación y la comprobación del cliente. La aportación histórica de 2013 fue dar a los bytes una identidad que podía sobrevivir a un cambio de anfitrión.