Resumen

  • abc, "abc", #616263#, 3:abc y |YWJj| pueden representar los mismos tres octetos; la forma canónica es la única codificación única destinada al cálculo de firma.
  • Una indicación de visualización puede formar parte del objeto canónico firmado, pero no demuestra tipo seguro, confianza ni autorización.
  • Un sistema auditable enlaza, sin confundirlos, entrada, perfil del analizador, salida canónica, firma, interpretación, política y efecto observado.

Una pantalla no es el límite criptográfico

Una consola enseña abc; un archivo conserva "abc"; una traza contiene #616263#; un mensaje lleva 3:abc; una herramienta imprime |YWJj|. RFC 9804 muestra que las cinco formas pueden terminar en la misma cadena de tres octetos. La captura de una de ellas no revela qué bytes cruzaron el límite de la firma.

La especificación define una S-expression como una cadena de octetos o una lista finita. Después distingue cuatro entornos. La representación avanzada sirve para personas, interfaces y depuración. El transporte básico mueve una forma canónica por canales que rechazan ciertos bytes o líneas largas. La representación canónica es única y se usa al firmar. La representación en memoria pertenece a cada implementación.

En la forma canónica, una cadena lleva su longitud decimal, dos puntos y los bytes literales; las listas no admiten espacios decorativos. La expresión completa puede viajar codificada en Base64 entre llaves. Es una envoltura de transporte: al retirarla deben reaparecer exactamente los bytes canónicos.

La forma avanzada admite tokens, comillas, hexadecimal, Base64, longitudes y espacios. Su implementación es opcional. Una aplicación debe recibirla porque su perfil la exige o porque descubrió esa capacidad, no porque “parece texto”. Un registro que sólo diga “analizado” omite versión, variantes activadas, límites y restricciones.

Mostrar no equivale a tipar

Una cadena puede llevar una indicación de visualización. RFC 9804 le asigna la función de orientar la presentación y ninguna más. Al estar presente entra en la forma canónica, así que la firma puede cubrirla. Eso prueba que el firmante incluyó esos octetos; no prueba que el tipo sugerido sea verdadero, que el manejador sea seguro ni que una política deba permitir la operación.

Sin indicación, cada aplicación puede elegir un valor por defecto; el general es application/octet-stream. Dos programas pueden presentar de manera diferente datos idénticos. La igualdad también es una decisión de perfil: el RFC recomienda comparar indicación y datos, pero permite ignorar la indicación. Esa regla y su versión deben quedar en el expediente.

Aceptar la gramática es sólo la primera puerta. RFC 9804 permite prohibir formas avanzadas, indicaciones, listas o cadenas vacías e imponer límites. SPKI concreta esa reducción: RFC 2693 no admite listas vacías en sus certificados y exige una cadena de tipo al comienzo.

La cadena de evidencia guarda primero los bytes y el encuadre recibidos. Registra versión y configuración del analizador, perfil y límites, y el objeto abstracto resultante. Después vuelve a serializar en forma canónica y almacena su hash. La verificación nombra ese hash y la clave; nunca sustituye los bytes por una vista de pantalla.

Sólo entonces llega el significado. RFC 2692 deja al autor de la aplicación definir qué significa una autorización SPKI. RFC 2693 describe tuplas confiables y reducción, pero el permiso final sigue siendo de la aplicación. El recibo debe nombrar manejador, versión de política, sujeto, acción, recurso y decisión. La ejecución necesita otra observación.

Así se distingue recepción, admisión, análisis, canonicalización, firma, significado, autorización y efecto. Si dos analizadores discrepan, se comparan entrada y hash canónico. Si la firma coincide y cambia el resultado, se examinan manejador y política. Si la política permite pero no hay efecto, se investiga la ejecución. La forma canónica posibilita acuerdo; no confiere autoridad a todas las etapas.

Fuentes