Resumen

  • kid reduce el conjunto de claves que una aplicación puede probar, pero su valor no tiene estructura normalizada ni garantía de unicidad y no equivale a una huella criptográfica.
  • El registro defendible conserva el ámbito de búsqueda, todos los candidatos, la huella de la clave que verificó, los bytes firmados, el vínculo de identidad, la regla de autorización y el efecto final.

Un dispositivo recibe un objeto COSE con el valor corto 0x19. Su almacén local devuelve una clave antigua aún válida para leer archivos y otra clave activa para un cliente diferente. Una firma pasa con la segunda. El sistema, sin embargo, guarda solo una línea: «0x19: correcto».

La línea no permite reconstruir nada importante. No dice qué claves estaban disponibles, cuál se probó primero, con cuál se validó, en qué espacio de nombres ocurrió la búsqueda ni qué política autorizó el uso del mensaje. El valor corto ha ocupado el lugar de cinco decisiones distintas.

El caso es deliberadamente hipotético. La RFC 9052 ya contiene la precaución necesaria; el problema aparece cuando el modelo de datos la omite.

La consulta puede tener varias respuestas

La tabla de parámetros comunes de COSE reserva la etiqueta entera 4 para kid y le asigna un valor binario. Su objetivo es ofrecer un dato que ayude a encontrar la clave criptográfica necesaria. Puede coincidir con el miembro kid de COSE_Key o con otro campo equivalente de un mecanismo de distribución.

La norma no deja la unicidad a la imaginación. Varias claves pueden compartir el mismo valor y la aplicación quizá deba comprobarlas todas. Tampoco define una estructura interna. En un objeto de clave, el identificador puede ser una cadena elegida por un usuario o un valor calculado a partir de la parte pública; aun así, puede repetirse en objetos de claves diferentes.

Por tanto, una búsqueda correcta necesita ámbito. Debe indicar aplicación, emisor, cliente o tenant, versión del almacén, instante y bytes recibidos. El resultado es una lista de candidatos. La huella completa de la clave que finalmente valida el mensaje es un dato nuevo, no una expansión automática de kid.

El registro COSE de IANA mantiene el significado de cable: etiqueta 4, bstr, identificador de clave. También contiene un parámetro separado, kid context. No todos los perfiles tienen que usarlo, pero la separación demuestra que contexto e identificador son objetos diferentes.

Un campo no protegido no recibe autoridad por proximidad

Cada estructura de seguridad COSE tiene contenedores de parámetros protegidos y no protegidos. Los primeros intervienen en la protección criptográfica; los segundos pueden acompañar el mensaje sin quedar autenticados de esa forma. La distinción es visible precisamente para que las aplicaciones no traten ambos grupos como equivalentes.

RFC 9052 define kid como una pista, no como un campo crítico de seguridad, y por ello permite colocarlo en el contenedor no protegido. Esto no significa que una implementación deba aceptar cualquier coste o ámbito de consulta. Un valor alterado puede causar trabajo excesivo, abrir una búsqueda en el almacén equivocado o ensuciar la auditoría. Significa que la seguridad no puede descansar en la autenticidad de esa pista.

Sustituir el kid no genera una firma válida con una clave ajena. La comprobación aún necesita una clave real capaz de verificar los bytes exactos. Un diseño robusto limita el número de candidatos, separa tenants, registra todos los intentos y rechaza ambigüedades que su perfil no pueda resolver.

La firma cubre una construcción precisa

COSE forma Sig_structure con un texto de contexto, los parámetros protegidos del cuerpo, los parámetros protegidos del firmante cuando corresponda, los datos autenticados externos aportados por la aplicación y la carga útil completa. Su codificación produce ToBeSigned. El algoritmo de verificación recibe esa secuencia, la clave, el algoritmo y la firma.

Por eso «firma válida» debe ir acompañado de una huella de clave y de un hash de los datos exactos que entraron en la operación. Conviene conservar los bytes de los encabezados protegidos, la receta de external_aad, la referencia a la carga y la versión del parser. Un rechazo por mapa mal formado o parámetro crítico desconocido también pertenece al historial, aunque nunca se llegue a probar una clave.

El panel puede mostrar campos no protegidos junto al resultado, pero no debe colorearlos como si la firma los hubiera cubierto. La cercanía visual no amplía el alcance matemático.

Verificar, identificar y autorizar

El propio procedimiento de RFC 9052 ordena una tarea posterior: la aplicación comprueba que la clave esté correctamente vinculada con la identidad firmante y que esa identidad tenga autorización antes de ejecutar acciones.

La primera unión puede apoyarse en un certificado, una atestación, un comprobante de aprovisionamiento o un registro local. La segunda depende de una política con recurso, rol, propósito, tiempo y versión. Una firma histórica puede seguir siendo correcta después de que la identidad pierda el cargo. Una clave puede estar autorizada en un tenant y no existir en otro. Dos claves de rotación pueden compartir kid mientras solo una admite operaciones nuevas.

También hay resultados posteriores. La autorización puede aprobar una solicitud que la aplicación no logra confirmar; una operación puede ejecutarse y no producir el efecto externo previsto. Ni el rótulo ni la firma contienen ese recibo.

ACE confirma el límite dentro de la autorización

La sección de perfiles de RFC 9052 deja a cada aplicación la selección de estructuras, servicios, parámetros, algoritmos y negociación. COSE define cómo se protegen objetos; el contexto operativo define quién puede hacer qué.

La RFC 9200 aplica OAuth a entornos restringidos y vuelve a marcar la frontera. En un ejemplo con una COSE_Key de prueba de posesión, declara que kid se usa solo para simplificar la indexación y recuperación de la clave. No puede suponerse único en el dominio del cliente ni en el del Resource Server.

Eso obliga a registrar el perfil, el servidor de autorización o emisor, la audiencia, el ámbito de búsqueda y las restricciones de uso. Un identificador corto puede acelerar el paso inicial sin absorber las reglas de acceso.

Un autor documentado, no un soberano técnico

Jim Schaad firmó la RFC 8152, especificación original de COSE publicada en 2017. La RFC 9052, que también nombra a J. Schaad como autor, reemplazó su parte de estructuras y proceso, mientras los algoritmos pasaron a RFC 9053. El perfil de Jim Schaad en el Datatracker sitúa estas piezas dentro de una trayectoria más amplia.

Son documentos de consenso del IETF; no convierten al autor en dueño de una implementación ni demuestran adopción. La semblanza de Oregon Wine Press aporta la fotografía pública acreditada que sirve de referencia a la ilustración. La fotografía acredita identidad visual, no comportamiento de una red.

El recibo que no pierde la ambigüedad

Al llegar el objeto, hay que conservar su hash, tipo COSE, encabezados protegidos y no protegidos, carga y datos externos. La consulta se registra aparte con el espacio de nombres, la versión del almacén y la lista completa de claves devueltas.

Cada candidato conserva huella, origen, periodo, operaciones permitidas y resultado. La verificación exitosa apunta a uno de ellos y al hash de ToBeSigned. Después se enlazan la prueba de identidad, la política de autorización y el recibo de aplicación. Ninguna relación se sobrescribe con el nombre corto.

Los candidatos fallidos permiten explicar una rotación, una diferencia entre nodos o un cambio de orden en la base. Si se borran, el historial parece más simple y se vuelve menos verdadero. El informe final puede ser preciso: esta clave validó estos bytes; esta evidencia la vinculó con esta identidad; esta política permitió o negó esta acción; este fue el resultado observado.

Fuentes