Resumen

  • El borrador individual de CAID publicado el 28 de septiembre mantiene las suites, el resumen y la forma canónica de los objetos que las versiones -03 y -04 aceptan conjuntamente.
  • El nuevo texto identifica objetos con CAID válido bajo -03 que ahora deben rechazarse. Un resultado histórico y una evaluación actual necesitan registros separados.

Una plataforma de autorizaciones calcula un identificador para una acción. Otra lo recibe en un comprobante de ejecución. Durante meses ambas usan el mismo criterio de validación. Después solo una instala una versión más estricta. La discusión que sigue puede sonar a seguridad rota: «el identificador sigue siendo el mismo, ¿por qué falla?». La respuesta puede ser menos espectacular y más importante para la operación. El conjunto de objetos admitidos cambió; la prueba de igualdad de bits no decide si ambos extremos siguen hablando la misma versión de la regla.

Ese es el hecho distintivo de la cuarta revisión de The Canonical Action Identifier, propuesta por Iman Schrock como Internet-Draft individual. CAID intenta dar un nombre comparable a una acción representada en piezas diferentes de autorización, delegación, ejecución y auditoría. Propone un objeto tipado, una combinación de canonización y resumen criptográfico, un identificador compacto y definiciones versionadas de los campos materiales. El Datatracker del IETF registra el documento como borrador individual sin posición formal en el proceso de estándares. Ni la etiqueta de intención que figura en su portada ni los ejemplos de conformidad prueban aprobación, uso general o fallo de un servicio real.

La sección de cambios es poco ambigua en lo esencial. La revisión -04 es sustancial para el modelo de procesamiento, pero no modifica la suite, el resumen ni la forma canónica de los objetos aceptados por ambas revisiones. Esta frase no promete que todo objeto aceptado antes siga siéndolo. El mismo apartado enumera entradas recién rechazadas y dice que varias podían producir identificadores válidos con -03. Entre ellas hay objetos con más de 64 niveles de anidamiento, representaciones canónicas superiores a 16.777.216 octetos, cadenas con no caracteres Unicode y ciertas marcas de tiempo con t o z minúsculas o un segundo igual a 60. El alcance concreto de cada rechazo importa más que un titular genérico sobre «romper hashes».

Conviene distinguir tres preguntas. ¿Representan dos cadenas compactas la misma acción según una suite y una definición? ¿Puede el verificador actual admitir el objeto de entrada? ¿Debía alguien autorizar o ejecutar esa acción? CAID se ocupa de la primera y precisa las condiciones técnicas de la segunda. No responde la tercera. Un resumen idéntico para los casos comunes no hace que un objeto excluido por la versión nueva sea aceptable; tampoco convierte el rechazo nuevo en prueba de que la decisión histórica fue fraudulenta. Se necesita conocer con qué reglas se tomó cada decisión.

La definición del tipo de acción deja de ser una etiqueta informal. -04 introduce definition_sha256, calculado sobre la proyección de validación de esa definición. El verificador puede comparar con un valor esperado y producir definition_mismatch. Dos equipos que pronuncian el mismo nombre de tipo pero usan definiciones distintas no deben dar por supuesta una comparación válida. El registro de referencia del autor avanza a la versión 5 y conserva íntegro el archivo anterior como historia. Esa conservación ayuda a reproducir evaluaciones, pero no constituye la creación de los registros IANA que el borrador solicita.

La revisión endurece también la entrada JSON, ordena los motivos de rechazo y especifica qué ocurre con definiciones no conformes. Rechaza nombres duplicados en el texto JSON incluso si la duplicidad aparece tras interpretar escapes. Hay una lección general sobre parseo, pero el punto aquí no es presentar un nuevo relato de ataques por claves duplicadas. Es precisar un límite de interoperabilidad: una parte puede conservar el mismo identificador compacto y otra cambiar legítimamente las condiciones para emitirlo o verificarlo. Si un intermediario resume ambos resultados como «CAID coincide», oculta el estado de validación relevante.

El borrador incluye un perfil para proyectar artefactos nativos ya verificados hacia un tipo de acción común. Sus resultados son equivalencia bajo perfil, no equivalencia e indeterminación; el último no se convierte en coincidencia por conveniencia. Aun una equivalencia bien establecida no acredita identidad, autoridad, autorización, ejecución ni seguridad. El propio resumen del borrador lo advierte. Por eso esta noticia no es otra discusión sobre si una firma otorga autoridad: es una advertencia más temprana sobre la versión de la regla que permitió hacer la comparación.

Para evaluar una implantación futura, Daniel Kade propone conservar un comprobante de validación: objeto original o referencia verificable, identificador y suite, versión del validador, definición o registro fijados, resultado y motivo, y la decisión de migración. No se trata de un campo exigido por CAID. Es una forma de evitar que la actualización de un extremo reescriba la historia del otro y de reconocer que una divergencia puede venir de la entrada, la definición o la política local.

Fuentes