Resumen

  • La extensión signedDocumentBinding contiene un hash de los datos que debían firmarse, pero el borrador reconoce que la firma puede validarse sin revisar ese vínculo. El éxito criptográfico y la coincidencia de dataTbsHash son comprobaciones independientes.
  • El certificado también expresa que la CA creó la clave para una única operación y la destruyó después. Esa es una afirmación de procedimiento. noRevAvail y una fecha 9999 no prueban la destrucción ni preservan por sí solos la confianza en la CA.

El sistema recibió una firma correcta, una cadena aceptable y un certificado que no caducaría en una escala humana. El expediente parecía cerrado. Nadie había registrado si el documento presentado coincidía con la huella para la que la CA emitió el certificado.

La revisión 02 de One Signature Certificates convierte ese detalle en una frontera operativa. Propone generar una clave y su certificado al firmar, usar la clave una vez y destruirla de inmediato. El certificado queda ligado al contenido, suele carecer de vencimiento significativo y no ofrece revocación. Así se reduce el estado persistente de una credencial reutilizada.

Es un Internet-Draft activo del grupo LAMPS, de flujo IETF y con intención Proposed Standard. La revisión 02 es del 1 de julio de 2026, vence el 2 de enero de 2027 y figura como WG Document con estado I-D Exists. No es un RFC ni evidencia de emisión real, destrucción, despliegue o validación de archivo.

El hash se comprueba; la destrucción se atestigua

signedDocumentBinding reúne dataTbsHash, hashAlg y un bindingType opcional. El receptor puede reconstruir los datos de firma, aplicar el algoritmo y comparar el resultado. Esa parte produce evidencia reproducible.

Al incluir la extensión, la CA afirma además que la clave privada nació exclusivamente para el documento ligado y fue destruida después de firmar. El borrador remite los detalles y garantías a la política de certificación.

Una extensión no ve el interior del HSM. No detecta una réplica, un backup, una reanudación tras fallo ni una segunda solicitud concurrente. Por eso el registro debe separar la huella verificable de la evidencia de generación, uso único y destrucción.

Conservar solo el certificado traslada toda la confianza procesal a una frase implícita. Conservar la transacción permite preguntar qué CP/CPS regía, qué reloj usó la CA, qué identificador de clave efímera produjo el HSM, qué autorización se consumió y qué componente observó la eliminación.

La biblioteca puede decir “válida” sin revisar el alcance

La revisión 02 afirma que comprobar el binding no es requisito para que la validación criptográfica de la firma tenga éxito. Por tanto, una API genérica puede devolver un booleano verdadero aunque nunca haya calculado dataTbsHash.

La aplicación necesita estados separados: resultado de firma; resultado de cadena; presencia del binding; tipo reconocido; bytes reconstruidos; digest recibido y calculado; política final. Si la comparación no se ejecutó, el estado es “no comprobado”.

Esto no es una distinción académica. Una clave que incumplió el uso único podría producir otra firma matemáticamente correcta. Un certificado sustituido podría llevar una clave válida pero un binding destinado a otra entrada. Solo la comparación adicional aplica el perímetro de un documento.

El SHOULD del borrador deja margen de perfil. Una organización que compra la propiedad de una sola firma debe convertirlo en regla local obligatoria. También debe probar todos los caminos: servicio interactivo, lotes, móviles, proveedores externos y revalidación histórica.

El tipo de binding cambia los bytes

Sin bindingType, el modo por defecto toma los datos exactos entregados al algoritmo: SignedInfo en XML, SignedAttributes DER en CMS u otra estructura equivalente.

Si esa entrada contiene el certificado o su hash, aparece una dependencia circular: el certificado necesita el hash de una estructura que, a su vez, necesita el certificado. Por eso el modo por defecto está prohibido en esos casos.

CAdES elimina SigningCertificate y SigningCertificateV2 del SignerInfo antes de calcular. XAdES retira las referencias a SignedProperties y conserva el resto de caracteres, espacios y saltos. JWS y COSE vinculan solo el payload, no sus cabeceras.

Una coincidencia de payload JWS no autentica automáticamente alg, kid o una referencia de certificado. Esos elementos siguen en el contrato JWS. Del mismo modo, el nombre “cades” no demuestra que dos bibliotecas hayan retirado y codificado exactamente los mismos bytes.

El futuro registro IANA debe exigir un procedimiento determinista y resolver la circularidad. La operación debe guardar además la versión normativa, la implementación y el hash de la secuencia reconstruida.

Sin revocación no significa sin posibilidad de error

El borrador recomienda notAfter=99991231235959Z y id-ce-noRevAvail. El primer valor señala que no hay un vencimiento definido; el segundo informa que no existe un mecanismo de revocación para ese certificado.

El argumento depende del tiempo de firma: si la clave solo existió durante una operación, una revocación posterior no debería alterar la evaluación de la firma histórica. La exposición futura de una clave destruida es menor que la de una credencial reutilizada.

Pero un error de creación sigue siendo relevante. La clave pudo copiarse, el reloj pudo fallar, la firma pudo repetirse o la destrucción pudo quedar incompleta. noRevAvail no demuestra lo contrario; únicamente cambia lo que el verificador debe esperar del estado del certificado.

Los sistemas deben diferenciar ausencia intencional de revocación, fallo de red al consultar estado y perfil desconocido. También necesitan un proceso para corregir decisiones empresariales cuando una auditoría posterior cuestiona la ceremonia, aun cuando los bytes históricos no se puedan “revocar”.

La hora de emisión convierte a la CA en testigo temporal

Para validar pasado el tiempo hace falta una referencia fiable del momento en que existía la firma. RFC 3161 usa una autoridad de sellado temporal. El modelo de una sola firma acopla emisión y firma y trata la hora del certificado como hora del acto.

Así la CA declara identidad, clave, contenido, momento, generación y destrucción. Esa concentración debe aparecer en el modelo de riesgo. Una cola de reintento o una divergencia de reloj puede afectar más de una propiedad.

El recibo ha de decir si el best-signature-time procede de la emisión, de un sello RFC 3161, de un Signature Validation Token o de evidencia archivística. Una fecha X.509 correcta no equivale automáticamente a una observación independiente.

Una fecha 9999 no mantiene viva la raíz

La validez indefinida del certificado final no prolonga el certificado de la CA. El borrador supone validación inicial durante su vigencia. Para años posteriores puede hacer falta conservar la CA como trust anchor, cruzarla, renovar certificados en un repositorio o aplicar otra provisión.

Ese mecanismo queda fuera de alcance. También envejecen los algoritmos, el software y las políticas. El archivo debe retener objeto original, cadena, política, evidencia temporal, resultado de validación e historial de anclas.

La pregunta de compra no es “¿caduca el certificado?”. Es “¿quién conserva toda la capacidad de validar y con qué independencia?”. Un servicio que desaparece no debe llevarse consigo la única interpretación del binding.

La relación documental no autoriza el resultado

Un binding correcto prueba que el certificado fue emitido para determinada entrada bajo una regla concreta. No prueba intención humana, mandato, presentación visual, validez jurídica, entrega ni resultado externo.

La evidencia útil mantiene capas: sintaxis, cadena, firma, binding, procedimiento de la CA, ciclo de la clave, tiempo, identidad, autorización, decisión, archivo y efecto. El perfil puede reducir un ciclo de vida. No puede fundir todas las autoridades en el certificado.