Integrar firma digital en tu sistema: lo que la ley exige y casi nadie implementa
La conversación se repite. Un equipo integra firma digital, el sistema produce PDF firmados, el visor de Adobe muestra el panel verde y el proyecto se da por terminado. Dos años después alguien tiene que presentar uno de esos documentos en un procedimiento administrativo y aparece la pregunta incómoda: ¿esto vale?
La respuesta depende de tres condiciones que el reglamento peruano exige a la vez. La primera la cumple cualquiera. La segunda se cumple casi siempre por accidente. La tercera no la cumple casi ninguna integración construida a partir de una biblioteca de firma, y es la que decide si el documento se admite como prueba.
Este artículo ordena las tres, en el orden en que hay que decidirlas.
Qué firma vale, según la norma
El punto de partida es el artículo 3 del D.S. 052-2008-PCM, reglamento de la Ley 27269: «La firma digital generada dentro de la Infraestructura Oficial de Firma Electrónica tiene la misma validez y eficacia jurídica que el uso de una firma manuscrita».
La frase que importa es «generada dentro de la Infraestructura Oficial de Firma Electrónica». Fuera de la IOFE hay criptografía perfectamente correcta que no produce ese efecto. El artículo 6 cierra qué certificados están dentro: los emitidos por entidades de certificación acreditadas ante INDECOPI, los incorporados por certificación cruzada, los reconocidos por acuerdos de reconocimiento mutuo y los de entidades extranjeras incorporadas por reconocimiento.
De ahí sale la primera decisión de la integración, y es de compras, no de código: el certificado con el que va a firmar tu sistema tiene que estar en la IOFE. Un certificado generado con OpenSSL para pruebas produce firmas técnicamente válidas y jurídicamente irrelevantes.
El requisito que se salta todo el mundo
El artículo 4 es el que decide si el documento se admite como prueba. Dice que los documentos firmados digitalmente dentro de la IOFE «deberán ser admitidos como prueba en los procesos judiciales y/o procedimientos administrativos, siempre y cuando la firma digital haya sido realizada utilizando un certificado emitido por una Entidad de Certificación acreditada en cooperación con una Entidad de Registro o Verificación acreditada», y añade una condición más: «asimismo deberá haberse aplicado un software de firmas digitales acreditado ante la Autoridad Administrativa Competente».
Ese «asimismo» es el problema. No basta con que el certificado esté acreditado: el software que firma también tiene que estarlo. Una integración que llama a una biblioteca de firma cualquiera, por buena que sea la biblioteca, no cumple ese requisito.
Es verificable antes de escribir una línea de código. INDECOPI, que es la Autoridad Administrativa Competente, mantiene el Registro Oficial de Prestadores de Servicios de Certificación Digital y la lista de servicios de confianza; ahí se comprueba qué está acreditado y con qué alcance. Si el componente que vas a usar no aparece, hay dos caminos: usar uno que sí lo esté, o firmar a través de un proveedor cuyo software lo esté.
Vale la pena decir la parte incómoda: esto encarece la integración respecto a la versión con biblioteca libre. También es la diferencia entre un documento que se admite y uno sobre el que hay que discutir.
Un detalle del mismo artículo que rompe los PDF combinados
El artículo 4 añade una precisión que casi nunca se implementa: la garantía de no repudio «no se extiende a los documentos individuales que conforman un documento compuesto, a menos que cada documento individual sea firmado digitalmente».
Traducido a diseño: si tu sistema junta veinte anexos en un solo PDF y firma el resultado, has garantizado el conjunto, no cada pieza. Quien luego extraiga el anexo 12 no tiene nada que verificar. Si los anexos van a circular sueltos, se firman sueltos.
Qué presume la ley cuando la firma es válida
El artículo 8 establece tres presunciones sobre un documento firmado dentro de la IOFE: que el suscriptor tiene el control exclusivo de la clave privada asociada, que el documento se firmó empleando esa clave privada y que el documento no ha sido alterado después de la firma. Y su consecuencia: «el suscriptor no podrá repudiar o desconocer un documento electrónico que ha sido firmado digitalmente usando su clave privada».
Esas presunciones son la razón de ser de todo lo anterior, y también una advertencia para el diseño. La primera —control exclusivo de la clave privada— es una afirmación sobre tu arquitectura. El artículo 7 la repite como característica de la firma: «Su generación está bajo el control exclusivo del suscriptor».
Un sistema que guarda el certificado de un funcionario en el servidor y firma en su nombre cuando le llega una petición está contradiciendo esa presunción, aunque funcione. Dónde vive la clave privada y quién la acciona es una decisión de arquitectura con consecuencias legales, y la tratamos aparte en firma remota y HSM.
Qué formato y qué nivel
Esta parte ya está resuelta y escrita: los formatos que el Estado reconoce, los niveles de firma y cuándo hace falta cada uno están en PAdES, XAdES y las decisiones que no se pueden deshacer.
El resumen para quien esté decidiendo hoy: si el usuario abre el archivo, PAdES; si lo lee otro sistema y ya es XML, XAdES; y si los documentos tienen que sobrevivir a la vigencia del certificado, el nivel con datos de validación incrustados desde el principio, porque subir de nivel después obliga a re-firmar lo que ya circuló.
La fecha, que es una firma aparte
Una firma dice quién y qué. No dice cuándo, o al menos no de forma oponible: la hora que consta es la del reloj de quien firmó.
El reglamento trata el asunto como un servicio distinto. Su artículo 36 define la modalidad de Prestador de Servicios de Valor Añadido sin firma digital del usuario final como «el sistema de Sellado de Tiempo, el cual permite consignar la fecha y hora cierta de la existencia de un documento electrónico», y el artículo 33 lo incluye entre las funciones de esos prestadores: «Certificar los documentos electrónicos con fecha y hora cierta».
Cuándo hace falta y qué pasa si no se pone lo detallamos en el artículo sobre sellado de tiempo. La regla corta: si el documento tiene que seguir verificándose después de que caduque el certificado del firmante, necesita sello de tiempo desde el día uno.
Conservar no es guardar el archivo
El artículo 5 es el que más proyectos sorprende, porque no habla de firmar sino de después. Cuando se exige formalidad para la conservación de documentos electrónicos firmados, estos deben ser accesibles para posterior consulta, conservarse en su formato original o en otro que reproduzca de forma demostrable la exactitud e integridad del contenido, y conservar «todo dato que permita determinar el origen, destino, fecha y hora del envío y recepción».
Y añade el requisito caro: en esos supuestos los documentos «deberán ser conservados mediante microformas o microarchivos», con la participación de un notario o fedatario con Diploma de Idoneidad Técnica registrado ante su colegio profesional, conforme al Decreto Legislativo 681.
Es decir: para ciertos documentos, el archivo firmado en un bucket no es conservación en el sentido de la norma. Conviene saberlo al presupuestar, no al año siguiente.
El orden en que conviene decidir
Para un equipo que empieza mañana:
- Certificado. Qué certificado usa el sistema y bajo qué titularidad. Persona natural, persona jurídica o agente automatizado cambia quién responde. Está en tipos de certificado.
- Software. Comprobar en el registro de INDECOPI que el componente de firma está acreditado. Antes de elegir biblioteca.
- Formato y nivel. Según quién abra el archivo y cuánto tenga que durar.
- Sello de tiempo. Sí, salvo que el documento caduque antes que el certificado.
- Control de la clave privada. Quién firma de verdad cuando el proceso es automático.
- Conservación. Si aplica la formalidad del artículo 5, presupuestar microformas y fedatario.
- Verificación. Probar los documentos que produce tu sistema en el validador de Firma Perú antes de poner nada en producción.
El paso 7 es gratis y ahorra discusiones. Si el validador oficial no entiende lo que produce tu integración, el problema aparecerá tarde y con un documento concreto encima de la mesa.
Si necesitas certificados para integrar
En Mi Firma Digital emitimos certificados dentro de la IOFE para personas naturales, personas jurídicas y agentes automatizados, que son los que se usan cuando el que firma es un proceso y no una persona sentada frente a la pantalla. Si estás diseñando la integración y no tienes claro qué titularidad te corresponde, escríbenos antes de comprar: cambiar de tipo de certificado a mitad de proyecto obliga a rehacer la parte de identidad.