Resumen

  • draft-birkholz-did-x509-03 valida una cadena aportada en orden hoja-primero, toma su último certificado como ancla para ese cálculo y comprueba una huella de CA y predicados de la hoja.
  • Una validación correcta no incorpora esa CA al almacén de confianza de la parte verificadora. La aceptación debe proceder de una política local independiente del material recibido.
  • Hay que separar el recibo de resolución, la confianza, la firma del mensaje, la autorización para el fin concreto, la escritura persistente y el resultado exterior. La revisión 03 es un borrador informativo de presentación independiente.

Una cadena de certificados puede presentar un pequeño mundo autosuficiente: una hoja firmada por un intermedio, el intermedio enlazado con el certificado final y un identificador cuyas condiciones coinciden con la hoja. Si el programa recibe todo ese mundo en un mismo paquete, puede verificar que no tiene contradicciones internas.

La organización receptora vive fuera del paquete.

Esta separación es la aportación más útil de la revisión 03 de did:x509. El método evita depender de un registro persistente de documentos DID. A cambio, la cadena llega durante la resolución y el identificador contiene la regla con la que seleccionarla. El mecanismo obtiene una clave pública de forma reproducible; no obtiene de forma automática la voluntad del verificador.

Una identidad definida por huella y condiciones

El identificador comienza con did:x509:0. Después incluye el algoritmo de huella, la huella de un certificado que no sea la hoja y uno o más predicados. Se admiten SHA-256, SHA-384 y SHA-512. La huella puede corresponder a un intermedio o al certificado terminal que funciona como ancla del cálculo.

Los predicados hablan de la hoja. subject aplica una prueba de subconjunto sobre atributos seleccionados del nombre. san exige un correo, DNS o URI concreto. eku busca un OID entre los usos extendidos. fulcio-issuer compara la extensión de emisor Fulcio, reconstruyendo el prefijo https://, y requiere una extensión presente y no crítica.

Así, un mismo DID puede admitir hojas renovadas. No queda atado al número de serie de un único certificado. La propiedad deseada —continuidad— crea a la vez una obligación de precisión. Un subconjunto de sujeto demasiado escaso puede aceptar muchas hojas. Un SAN correcto no concede una función administrativa. Un EKU dice para qué clase de uso se emitió una credencial, no quién ha autorizado una transacción particular.

El último certificado tiene dos significados posibles

La opción x509chain contiene certificados DER completos codificados en base64url y separados por comas. La hoja ocupa la primera posición; el supuesto ancla, la última. Deben existir al menos dos certificados.

La resolución ejecuta la validación de ruta de la RFC 5280. Examina firmas, restricciones básicas y de nombre, políticas, usos de clave, extensiones críticas, algoritmos e instante de validación. Después comprueba la huella no-hoja y todos los predicados. Finalmente deriva de la hoja el JWK y las relaciones de verificación del documento DID.

En ese algoritmo, el último certificado es el punto de partida de confianza. Pero “ancla de confianza” es un término técnico relativo a la ejecución. La política empresarial puede no haber aceptado jamás ese certificado. Si la aplicación borra la diferencia, el remitente no solo aporta pruebas: también elige la autoridad que juzga esas pruebas.

La RFC 9360 establece el límite en el entorno COSE: una cadena recibida no debe actualizar de forma silenciosa las anclas configuradas por la aplicación. did:x509 necesita la misma disciplina. El certificado final sirve para responder “¿forma esta cadena el objeto descrito por el DID?”. Otra fuente debe responder “¿admitimos a esta autoridad para este propósito?”.

Estado Afirmación limitada Pregunta pendiente
DID analizado La versión, la huella y los predicados tienen forma válida Si existe una cadena legítima que los cumpla
Ruta validada La hoja enlaza con el último certificado recibido bajo unos parámetros Si ese certificado pertenece a la política local
Predicados coincidentes La hoja entra en la clase declarada Si la clase es bastante estrecha
Ancla aceptada localmente La CA o el DID están permitidos en un contexto Si los bytes del mensaje fueron firmados
Firma correcta La clave verifica el contenido cubierto Si el firmante puede ordenar la operación
Autorización registrada La regla permite actor, recurso y acción Si el cambio se confirmó y produjo el efecto esperado

El texto visible no es una credencial

Los componentes del DID se pueden leer sin criptografía. Precisamente por ello son peligrosos antes de resolver. Una aplicación que extrae O=Empresa o un dominio de la cadena de texto y concede un rol ha creado un atributo autodeclarado.

La revisión 03 exige no usar esos componentes para autorización sin una cadena verificada. Incluso tras verificarla, la afirmación solo queda ligada a la CA y a la hoja. Falta la aceptación local. Más tarde faltarán todavía la firma del mensaje, el alcance del permiso y el recibo del efecto.

Esta secuencia no es burocracia. Es la única forma de distinguir un identificador inventado, una cadena coherente con una CA no aceptada, una firma válida pero fuera de función y una operación realmente ejecutada.

La respuesta depende del reloj y de la política de revocación

La validación puede usar el tiempo presente o un tiempo relevante, como el de firma. Una hoja expirada hoy quizá fuera válida cuando se generó el objeto. El campo iat de un JWT o CWT no adquiere autoridad temporal solo por aparecer; las RFC 7519 y RFC 8392 definen la reclamación, mientras que integridad y aceptación quedan en manos de la aplicación.

La revocación se comprueba cuando la aplicación lo exige, mediante CRL, OCSP u otro sistema. También pueden intervenir transparencia, endosos y reglas contra algoritmos inseguros. Por eso un resultado reproducible debe llevar la hora, el modo de revocación, las respuestas consultadas y la versión de política.

Los recibos de transparencia y registro estudiados en las RFC 9597 y RFC 9943 ayudan a recordar que un objeto probatorio no define por sí solo la decisión del consumidor.

Sin registro no significa sin gobernante

El método carece de operación de actualización del documento DID y de autorización para actualizarlo. También carece de operación de desactivación. Crear es una actividad local; resolver combina el identificador con una cadena aportada.

Si caducan o se revocan todas las hojas coincidentes, el DID puede parecer desactivado. Sin embargo, la CA podría emitir otra hoja compatible. La capacidad de reanimar la identidad no reside en una operación DID, sino en la autoridad emisora y en el ancho de los predicados. Quien valore el sistema debe investigar quién controla esa autoridad, cómo se retira de las listas locales y qué señal demuestra el fin de una relación.

La multiplicidad de cadenas también significa multiplicidad potencial de claves. El archivo probatorio debe conservar la cadena concreta que resolvió cada mensaje. Guardar únicamente el DID elimina la pieza que permite repetir la verificación.

La implementación revela la frontera real

El borrador presenta el método como implementado por Microsoft y enumera otros proyectos y casos relacionados con firma, SCITT, CCF y contenedores confidenciales. El README, la especificación y los vectores de prueba del repositorio de Microsoft permiten observar comportamiento ejecutable.

La propia sección de implementaciones señala diferencias con Nuts en eku y en un SAN otherName. Una lista de productos no prueba interoperabilidad; una divergencia concreta sí identifica el ensayo que falta. Las declaraciones proceden de colaboradores y no son un aval del IETF.

La revisión 02 declaraba intención Standards Track. La 03 pasa a Informational y amplía confianza, operaciones, resolución, privacidad e implementación. El Datatracker, el historial y el anuncio permiten situarla correctamente: trabajo en curso, presentación independiente, no RFC ni producto del IETF.

DID Core y los registros de especificaciones DID del W3C aportan el vocabulario general, pero no transforman esta propuesta en consenso normativo.

Un expediente que se pueda auditar

Hay que guardar el DID exacto, sus bytes decodificados, toda la cadena DER y su orden; parámetros y resultado de ruta; tiempo elegido; restricciones, políticas, nombres, usos y algoritmos; comprobación de revocación y transparencia; certificado de la huella; resultado de cada predicado; regla local de confianza y su versión; documento DID y JWK obtenidos; objeto firmado y bytes cubiertos; resultado de firma; autorización por propósito; actor, acción y recurso; identificador de confirmación; y evidencia del resultado externo.

Los desconocidos no deben rellenarse con una conclusión favorable. “No exigido por política” no equivale a “no revocado”. “Resuelto” no equivale a “aceptado”. “Firmado” no equivale a “autorizado”.

La especificación inicial mínima de Lu Heng propone compartir lo estrictamente necesario sin apropiarse de futuras decisiones. La primacía del código en ejecución obliga a contrastar implementaciones y efectos. El espejo de la política hace visible a quien controla la lista de confianza. Las capas de realidad mantienen separados símbolo, certificado, juicio, acción y mundo exterior.

Fuentes