Tu sistema firma con un certificado que está en la nube: qué sale de tu servidor y qué tiene que autorizar el firmante
La reunión de arranque de una integración con firma remota suele tropezar en la misma pregunta, casi siempre la hace alguien de seguridad o de legal: «¿entonces los contratos salen de nuestro servidor y se van al proveedor?». La respuesta del comercial suele ser vaga, y la del equipo técnico depende de qué API le hayan enseñado.
Hay una respuesta mejor, y está escrita. La Resolución 175-2024/DGI-INDECOPI, de 24 de junio de 2024, fija qué certificaciones tiene que presentar quien quiera acreditarse como prestador de firma remota. Entre las alternativas que acepta está la ETSI TS 119 432, cuyo título es «Protocolos para creación de firma digital remota». Es el documento que describe, pieza por pieza, qué viaja entre tu sistema y el servicio de firma. Casi nadie en el mercado peruano lo ha abierto, y responde a la pregunta de la reunión.
El documento no tiene por qué salir
La especificación, en su apartado 4.3.1 (igual en la versión 1.2.1 de octubre de 2020 y en la 1.3.1 de marzo de 2026), parte de una observación sencilla. Una firma digital no se calcula sobre el documento: se calcula sobre su resumen criptográfico. Y ese resumen se puede calcular en cualquier sitio.
Lo dice así: la creación del resumen «puede hacerse donde se almacena el documento o en el componente de creación de firma». En el primer caso viaja solo el resumen. En el segundo viaja el documento.
Y a continuación dice lo que tiene que decidir quien diseña la integración: dónde tiene que estar disponible el documento es «una decisión de diseño importante», porque enviar solo el resumen «limita las amenazas a la confidencialidad», pero puede recortar funciones. Pone los ejemplos: firmas que envuelven el documento o van dentro de él, y la representación visual de la firma.
Traducido a lo que te van a ofrecer, hay dos caminos:
| Envías el resumen | Envías el documento | |
|---|---|---|
| Qué sale de tu servidor | un valor de 32 bytes si es SHA-256 | el PDF o el XML completo |
| Quién arma el PAdES o el XAdES | tu sistema | el proveedor |
| Quién pinta el sello visible en el PDF | tu sistema | el proveedor |
| Método en la API del Cloud Signature Consortium | signatures/signHash | signatures/signDoc |
| Lo que tienes que desarrollar | más | menos |
La especificación remite a la API del Cloud Signature Consortium para la parte concreta, y es más exigente con un método que con el otro. En la versión 1.3.1, el apartado 7.5 dice que signatures/signHash «se aplicará y se implementará completamente», y el 7.6 dice de signatures/signDoc que «debería» implementarse. Es decir: el envío de solo el resumen es lo que un servicio conforme tiene que ofrecer siempre. El envío del documento es un extra.
Si tu proveedor dice estar certificado en ETSI TS 119 432 y solo acepta documentos completos, pídele que te lo explique por escrito.
Qué es exactamente lo que se firma
La versión 1.3.1, en el apartado 4.3.3, nombra la pieza: el componente de creación de firma prepara los datos a firmar formateados, «calcula el resumen y envía el valor del resumen» al servidor de firma. Ese servidor devuelve el valor de la firma. Tu sistema lo mete en el formato final.
Ahí hay un detalle que se olvida. Lo que se resume no es el PDF tal cual, es el PDF más los atributos firmados. El apartado 4.3.2 recuerda que los formatos CAdES y XAdES básicos exigen al menos dos, el tipo de documento y la hora declarada de firma, y que también entra el identificador del certificado de firma. Por eso el resumen se calcula después de saber con qué certificado vas a firmar, no antes, y por eso tu sistema necesita consultar el certificado al servicio antes de pedir la firma. En la API del CSC eso es credentials/info.
Si quieres el detalle de esos formatos y de las decisiones que no se pueden deshacer después, está en PAdES, XAdES y las decisiones de integración.
La petición de firma, en la versión 2.0.0.2 de la especificación del Cloud Signature Consortium, lleva el identificador de la credencial, la autorización, una lista de resúmenes en Base64 y los identificadores de algoritmo. La misma especificación pone un suelo: solo se admiten algoritmos de resumen «tan fuertes o más fuertes que SHA256». Si tu código heredado todavía resume en SHA-1, este es el momento de cambiarlo.
Lo que decide la seguridad: quién autoriza cada firma
Que la clave privada esté en un módulo criptográfico ajeno es lo que asusta. Lo que debería preocupar es otra cosa: qué impide que ese módulo firme sin que el firmante lo haya pedido.
La especificación ETSI lo resuelve con un concepto de la norma europea EN 419 241-1, los datos de activación de firma, y distingue dos niveles de control exclusivo.
SCAL1. El texto dice que las claves de firma se usan bajo control del firmante «con un nivel de confianza bajo». El servicio autentica al firmante y la activación de la clave de firma «puede permanecer durante un periodo y/o para un número de firmas». En la versión de 2026 se añade la precisión que importa: no hay vínculo criptográfico entre la autorización y los datos que se firman.
SCAL2. Control exclusivo «con un nivel de confianza alto». El firmante aporta los datos de activación para habilitar la clave de firma «para firmar documentos concretos». La especificación del CSC lo concreta en dos rasgos: la autorización queda ligada a los documentos que se van a firmar, y hacen falta dos factores.
La diferencia práctica es fácil de ver con la API. Cuando pides autorización con credentials/authorize, el parámetro hashes es opcional si la credencial es de nivel 1. Si es de nivel 2 es obligatorio, y la propia especificación explica para qué: sirve para que el servidor ligue la autorización a esos resúmenes, «evitando que una autorización se use para firmar un contenido distinto».
Con SCAL1, un atacante que se haga con la autorización de tu sesión puede firmar lo que quiera mientras dure. Con SCAL2 solo puede firmar lo que el firmante aprobó. La autorización caduca, además: si el servicio no dice otra cosa, el valor por defecto en la especificación del CSC es de 3.600 segundos.
Por qué esto tiene que ver con la norma peruana
El artículo 8 del reglamento de firmas digitales, en la redacción que le dio el D.S. 029-2021-PCM, publicado en El Peruano el 19 de febrero de 2021, presume que el suscriptor controla su clave privada «con un elevado grado de confianza, incluso cuando la misma es gestionada por un Prestador de Servicios de Valor Añadido acreditado en la modalidad de sistema de creación de firma remota».
«Elevado grado de confianza» es la misma expresión con la que ETSI define el nivel 2, y no con la que define el 1. Ninguna norma peruana dice que una cosa equivalga a la otra, y la Resolución 175-2024 no exige un nivel concreto: exige certificaciones. Así que lo que sigue es nuestra lectura, y así hay que tomarla. Si la presunción del artículo 8 habla de un control con confianza elevada y el servicio que usas reconoce por escrito que el suyo es de confianza baja, esa presunción te protege menos de lo que crees el día que alguien niegue haber firmado.
Qué exige INDECOPI para acreditar el servicio, con la lista completa de normas técnicas, está en el pilar de este tema, firma remota: qué exige INDECOPI. Y por qué el lugar donde vive la clave privada cambia la conversación, en firma remota y HSM.
El caso de los lotes
La pregunta que llega después de SCAL2 es siempre la misma: si cada firma exige un segundo factor ligado a su documento, ¿cómo firma alguien trescientas resoluciones?
La especificación lo tiene previsto. Una sola autorización puede cubrir varios resúmenes: se indica cuántas firmas se autorizan con numSignatures y se pasan todos los resúmenes en la misma petición. Existe además credentials/extendTransaction para renovar la autorización entre llamadas cuando el lote no cabe en una. El firmante aprueba una vez un conjunto cerrado de documentos, y el servicio no firma nada fuera de ese conjunto.
Lo que no resuelve la API es la parte que no es técnica: que el firmante vea lo que aprueba. Dónde está ese límite en la práctica está en firma por lote.
Cinco preguntas para el proveedor, con la respuesta que esperas
- ¿Qué norma técnica certificaron para acreditarse? Tiene que ser una de las que lista la Resolución 175-2024. Si dicen ETSI TS 119 432, lo que sigue aplica tal cual.
- ¿Tengo que enviarles el documento o me basta con el resumen? Un servicio conforme ofrece el resumen siempre.
- ¿Qué nivel de control exclusivo declara cada credencial? En la API del CSC es el campo
SCALque devuelvecredentials/info. Pide que te lo enseñen en una respuesta real, no en una presentación. - ¿Cuánto dura una autorización y cuántas firmas cubre? Si la respuesta es «la sesión entera», estás ante un nivel 1 aunque lo llamen de otra forma.
- ¿Dónde se introduce el segundo factor? La versión 1.3.1 advierte en su apartado 5.3.2 que cuando es tu aplicación la que recoge el PIN o el código de un solo uso, ese mecanismo «no debería ser adecuado» para el nivel 2. Si el firmante lo teclea en tu pantalla, pregunta cómo cumplen.
Lo que este artículo no afirma
Que INDECOPI exija SCAL2. La Resolución 175-2024 no lo dice. Exige certificaciones de normas técnicas y deja abierta la puerta a reconocer otras.
Qué nivel ofrece un prestador concreto. Eso solo lo dice su política y la respuesta de su API.
Que enviar el resumen sea siempre mejor. Para un equipo sin experiencia en PAdES, delegar el armado del formato puede ser la opción sensata. Pero tiene que ser una decisión, no algo que descubres cuando legal pregunta.
Si vas a integrar firma digital en tu sistema y todavía estás decidiendo si el certificado va en un token, en tu propio HSM o en un servicio remoto, en mifirmadigital.pe te ayudamos a elegirlo con estas cinco preguntas ya respondidas.
Última revisión: 16 de septiembre de 2026.
Fuentes de esta página
- Resolución 175-2024/DGI-INDECOPI, de 24 de junio de 2024, artículo segundo.
- ETSI TS 119 432 V1.2.1 (octubre de 2020) y V1.3.1 (marzo de 2026), apartados 4.3, 4.4.1.2, 5.3 y 7.5 a 7.6.
- Cloud Signature Consortium, «Architectures and protocols for remote signature applications», versión 2.0.0.2, apartados 8.2, 11.5, 11.6 y 11.10.
- D.S. 029-2021-PCM, Segunda Disposición Complementaria Modificatoria, que da su texto actual al artículo 8 del D.S. 052-2008-PCM.