Resumen

  • La revisión 03 firmaba el hash de un contexto anterior que podía existir de antemano; el coordinador podía recoger las firmas en sentido inverso.
  • La revisión 04 incluye la firma real del predecesor en el objeto resumido y rechaza cadenas antiguas, mixtas o sin el perfil exacto.
  • La mejora prueba dependencia criptográfica entre pruebas completas. No prueba una hora fiable, lectura consciente, autorización final, ejecución ni efecto.

El problema no era una firma falsa. Todas podían ser auténticas. El problema era que juntas contaban una secuencia que nunca había ocurrido.

draft-schrock-ep-quorum-04, presentado el 6 de septiembre como borrador informativo individual, reconoce ese límite. En la revisión 03, cada aprobador posterior firmaba un contexto con prev_context_hash, el resumen del contexto anterior. La redacción afirmaba que la propia firma demostraba que la aprobación anterior ya existía.

Pero el contexto no contenía la prueba de su antecesor. Un orquestador podía crear todos los contextos, pedir primero la firma final, avanzar hacia atrás y ordenar después el paquete según la lista. Ninguna firma tenía que romperse. El fallo estaba en la inferencia.

De un contexto disponible a una prueba terminada

El perfil EP-QUORUM-SIGNOFF-CHAIN-v1 mueve el enlace. Toma el objeto JSON completo de la firma anterior, incluida la firma efectivamente transportada, lo canonicaliza con JCS y calcula SHA-256 tras un separador de dominio y un octeto cero. El sucesor incorpora ese valor como prev_signoff_hash en su propio contexto firmado.

La primera aprobación omite el campo. Un nulo, el perfil desconocido, el antiguo enlace de contexto, una mezcla de formatos o una firma predecesora sustituida invalidan la modalidad fuerte. Incluso otra firma válida sobre el mismo contexto cambia el resumen y obliga a firmar de nuevo al sucesor.

Eso sí crea una dependencia causal entre objetos de prueba bajo las hipótesis criptográficas declaradas. No crea tiempo confiable. Las marcas issued_at siguen siendo afirmaciones. Tampoco demuestra que la segunda persona viera el mismo contenido, leyera la decisión anterior, entendiera el riesgo o actuara sin presión.

El paquete no puede elegir la política que lo valida

El predicado comprueba la forma de la política, cada firma, la acción exacta, roles admitidos, personas y claves distintas, umbral, orden, cadena fuerte y ventana. Un firmante real fuera del rol autorizado no cuenta. Dos nombres con la misma clave no son dos aprobadores. Una secuencia parcial no concede autoridad parcial.

Sin embargo, el receptor debe obtener por otra vía autenticada la política y el directorio de aprobadores. Aceptar la política que viene dentro del mismo paquete sería permitir que la evidencia nombrara a su propio juez. El borrador base también limita la identidad: la firma acredita a una clave inscrita bajo un identificador; la relación con una persona natural depende del control de alta.

La admisión incremental ayuda a rechazar temprano, pero no sustituye la verificación final. El ejecutor recalcula todo el quorum porque no confía en que el orquestador haya aplicado bien sus reglas. Después todavía quedan decisiones distintas: autorizar localmente, ejecutar, comprobar el efecto y consumir la autorización una sola vez.

La corrección merece crédito sin fabricar consenso

Tres verificadores —JavaScript, Python y Go— comparten un corpus con casos adversarios. Su acuerdo es evidencia de consistencia del mismo equipo. No es una implementación independiente, una prueba formal, una prueba de interoperabilidad ni una instalación productiva. El texto no pide acciones IANA y su presencia en el Datatracker no lo convierte en consenso del IETF.

La utilidad de la revisión está precisamente en su modestia. Una especificación común puede impedir que se reordenen pruebas completas. La organización sigue siendo responsable de quién puede aprobar, qué ve cada persona, cuándo caduca el permiso y qué ocurrió en el sistema real.

Fuentes

  1. Registro del Datatracker de IETF
  2. EP-QUORUM, revisión 04
  3. EP-QUORUM, revisión 03
  4. EP Authorization Receipts, revisión 12
  5. RFC 8785: JSON Canonicalization Scheme
  6. Web Authentication, nivel 2
  7. RFC 2119: palabras normativas
  8. RFC 8174: mayúsculas y minúsculas normativas
  9. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  10. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  11. Running-Code Primacy