Cuando un algoritmo deja de servir: qué dice la norma peruana, qué pasa con tu certificado vigente y con lo que ya firmaste
Imaginemos a Rosa, contadora en Arequipa (el caso es inventado). En 2024 firmó las actas de junta de un cliente con un certificado RSA de 2048 bits y SHA-256. Un colega le dice que ese algoritmo «ya no sirve» y que sus actas «ya no valen». Rosa se hace tres preguntas: si su certificado deja de funcionar, si las actas se invalidan y quién tendría que avisarle. Nadie ha anunciado nada parecido, y ninguna fuente que leímos lo anuncia. Pero la pregunta es razonable, y este artículo cierra la serie del pilar sobre cómo funciona la firma digital buscando qué responde la norma peruana.
Consultamos las fuentes el 25 de octubre de 2026. Cuando concluimos algo nosotros, lo marcamos como «nuestra lectura». Adelanto lo principal: no encontramos ningún texto peruano que fije fechas, un calendario o un procedimiento para retirar un algoritmo, ni para volver a sellar lo ya firmado. Sí encontramos piezas sueltas, y son las que siguen.
Lo que dice INDECOPI: un principio y una prohibición sin fecha
La guía de acreditación de entidades de certificación (versión 4.1, 28 de agosto de 2019) pide, en su apartado de ingeniería criptográfica, «algoritmos criptográficos de reconocimiento internacional de tamaño y seguridad criptográfica suficiente». Y que las llaves y los algoritmos sean «suficientemente seguros para proteger de ataques el resultado criptográfico durante el tiempo de duración del certificado». La frase está en el cuerpo de la guía. En el anexo 8 no aparece; lo que ese anexo dice de algoritmos es el mínimo de 2048 bits, como vimos en el artículo sobre la longitud y el algoritmo del certificado. Nuestra lectura: la guía mira hasta el vencimiento del certificado, no hasta el final de la vida del documento firmado con él.
La pieza más concreta está en otra guía, la de acreditación de aplicaciones de software de firma digital (versión 4.0, revisión 2016). Su requerimiento 6 (el 16 y el 26 repiten el texto para el software de agentes) se titula «No se deben utilizar funciones criptográficas obsoletas» y explica que conforme pasa el tiempo se encuentran vulnerabilidades, «tal es el caso del algoritmo HASH MD5, SHA-1 y las claves RSA 1024». Exige que la aplicación use «algoritmos criptográficos vigentes, no vulnerados o no obsoletos» y recomienda, si se usa SHA, que sea «a partir del SHA-2».
Tres límites de ese texto:
- No trae fecha ni calendario. Dice qué se considera obsoleto en la revisión de 2016, no cuándo pasa lo siguiente.
- Remite a una lista: «La lista de estándares criptográficos recomendados se lista en el anexo 1.» El anexo 1 publicado en gob.pe es la ficha de solicitud de acreditación, y el anexo A de la propia guía enumera RFC sin nombrar algoritmos de firma. No encontramos esa lista.
- El texto se repite para el software de firma de usuario final, el de firma por agentes automatizados y el de verificación por agentes. No distingue entre firmar con un algoritmo obsoleto y verificar una firma antigua hecha con él. Esa distinción importa para lo ya firmado, y la retomamos más abajo.
Lo que hace la entidad de certificación: la CPS de RENIEC
La declaración de prácticas de la ECEP-RENIEC (versión 5.1, 4 de junio de 2026) declara en su numeral 6.1.5 sha512WithRSAEncryption con 4096 bits para sus propias llaves y sha256WithRSAEncryption con 2048 bits para las entidades finales. El numeral 5.6 prevé el cambio de llaves de la entidad en tres casos, uno de ellos «en caso de verse afectada la seguridad de los algoritmos criptográficos en uso». Las llaves reemplazadas «no se usarán para emitir nuevos certificados, sino solamente para firmar las CRL correspondientes hasta la fecha de expiración del último certificado subordinado emitido utilizando dichas llaves».
Es el único procedimiento peruano que encontramos para un algoritmo debilitado, y habla de las llaves de la entidad, no de las tuyas. Nuestra lectura: si RENIEC cambiara de llaves por esa causa, los certificados ya emitidos seguirían consultables en la lista de revocados hasta su vencimiento, y la CPS no dice que haya que reemplazarlos.
Otra cosa es el compromiso de una llave. Ahí sí hay plazo: si se compromete una llave privada de la ECEP-RENIEC online, «se procede a cancelar de inmediato todos los certificados emitidos de la clase correspondiente» y se comunica a suscriptores y terceros «en un plazo máximo de 24 horas» (numeral 4.9.12). Un algoritmo que envejece no es una llave comprometida, y la CPS no los trata igual. Cómo se publica una cancelación lo cuenta el artículo sobre revocación, CRL y OCSP.
El reglamento: cuándo se cancela un certificado
El artículo 10 de la Ley 27269 (El Peruano, 28 de mayo de 2000) enumera tres causas de revocación: información inexacta, muerte del titular e incumplimiento contractual. El artículo 17 del D.S. 052-2008-PCM (El Peruano, 19 de julio de 2008) amplía la lista de cancelación a diez literales: solicitud del titular, decisión de la entidad, vencimiento, cese de la entidad, orden administrativa o judicial, interdicción, extinción de la persona jurídica, muerte, solicitud de un tercero con pruebas, y la última, «Otras causales que establezca la Autoridad Administrativa Competente.».
Ninguna dice «algoritmo obsoleto». El literal j) deja la puerta abierta a que INDECOPI añada una causa, y no encontramos que lo haya hecho. El artículo 16 añade que el período de vigencia del certificado «comienza y finaliza en las fechas indicadas en él», salvo cancelación; esa frase ya estaba en el texto de 2008 y la repite el D.S. 070-2011-PCM (27 de julio de 2011); el D.S. 029-2021-PCM reproduce solo parte del artículo, y no podemos confirmarla en esa versión. Y el artículo 17 dice dos cosas más: la cancelación indica el momento «precisando la fecha, hora, minuto y segundo», y «no puede ser aplicada retroactivamente».
Qué pasa con tu certificado vigente
Con esos textos, nuestra lectura es esta: un certificado sigue vigente entre sus fechas mientras nadie lo cancele, y un algoritmo debilitado no figura entre las causas de cancelación. Lo que no sabemos es cuántos programas o validadores seguirían aceptándolo, porque eso lo deciden ellos.
Un dato observable. La lista de confianza de INDECOPI (TSL, secuencia 25, copia del 22 de octubre) tiene 74 certificados de servicio, y 19 están firmados con sha1WithRSAEncryption. Seis de esos 19 siguen sin vencer a hoy, con vencimientos entre 2028 y 2039. También figuran dos certificados de la jerarquía del Estado de julio de 2010, uno rotulado «CLASE III SHA 1» y otro «CLASS III SHA 256», que vencen el mismo día, el 18 de julio de 2020. Nuestra lectura es que durante una década convivieron dos cadenas con funciones hash distintas y la antigua terminó por vencimiento. Ningún documento que leímos cuenta cómo se decidió.
Qué pasa con lo que ya firmaste
Son tres preguntas distintas, y la norma responde a medias.
La cancelación no es retroactiva. Eso dice el artículo 17, pero habla de cancelar un certificado, no de un algoritmo débil. Es un argumento por analogía, no un texto aplicable.
La presunción de integridad. El artículo 8 c) del reglamento presume «Que el documento electrónico no ha sido alterado con posterioridad al momento de la firma». Y el artículo 5, en la redacción del D.S. 105-2012-PCM (El Peruano, 21 de octubre de 2012), dice que la firma digital de la IOFE «no requiere mecanismos adicionales para conservar dicho documento a salvo de adulteraciones». La norma nunca dice que esas presunciones caduquen si el algoritmo se debilita, ni que sigan en pie. Cómo se discute una firma en juicio lo cuenta el artículo sobre impugnar un documento firmado.
La prueba técnica. Aquí los estándares sí dicen algo. Los niveles B-LT y B-LTA de PAdES, en el ETSI EN 319 142-1 (V1.2.1, enero de 2024), son adecuados cuando «certificate expiration, revocation and/or algorithm obsolescence is of concern». Del B-LTA añade que puede ayudar a validar la firma más allá de eventos como «the weakness of used cryptographic algorithms». El reglamento peruano ya reconoce el concepto: desde el D.S. 029-2021-PCM (19 de febrero de 2021), el artículo 36 b) define el sistema de preservación digital como el que «Provee capacidades que permiten validar una firma digital en el largo plazo y/o pruebas de existencia de objetos digitales utilizando firmas digitales y sellos de tiempo.»
Esa misma norma, en su disposición complementaria final trigésima, dio a INDECOPI 180 días para aprobar estándares técnicos de preservación digital y un año para las guías de acreditación correspondientes. La colección de guías de INDECOPI en gob.pe, que consultamos hoy, lista cuatro (entidades de certificación, de registro, servicios de valor añadido y software de firma) y ninguna es de preservación digital ni de firma remota. La de servicios de valor añadido (v. 4.0, revisión 2016) habla de sellado con el RFC 3161 y de archivo por «mínimo de 10 años», pero no de renovar sellos. Puede haber otra guía en otro sitio; nosotros no la encontramos.
El mecanismo: sellar, y volver a sellar
Un sello de tiempo (RFC 3161, agosto de 2001) prueba que algo existía en un momento dado, y es lo que fija que tu certificado estaba vigente cuando firmaste, como cuenta el artículo sobre sellado de tiempo. Pero el sello también usa algoritmos. El RFC 4998 (agosto de 2007) lo dice así: «Before the cryptographic algorithms used within the Archive Timestamp become weak or timestamp certificates become invalid, Archive Timestamps have to be renewed by generating a new Archive Timestamp.»
El RFC distingue dos renovaciones. Si lo que se debilita es el algoritmo de clave pública o el certificado de la autoridad de sellado, basta con sellar el sello anterior. Si se debilita la función hash, hay que volver a sellar todos los datos archivados. Y añade que la información sobre el debilitamiento de algoritmos «has to be closely watched» por el prestador del archivo o por el dueño de los datos, por vías ajenas al protocolo. Los textos peruanos que leímos no asignan ese vigilante.
La condición es temporal: la renovación tiene que ocurrir antes de que el algoritmo se debilite, no después. Por eso el artículo sobre conservar documentos firmados insiste en que lo que no se selló a tiempo no tiene arreglo retroactivo.
Cómo luce una transición escrita: el ejemplo de NIST
Como contraste, no como norma peruana. El NIST SP 800-131A Rev. 2 (marzo de 2019) es guía para agencias federales de Estados Unidos y no obliga en Perú. Define «legacy use» como el uso de un algoritmo «only to process already protected information (e.g., to decrypt ciphertext data or to verify a digital signature)». Sobre SHA-1 dice que para generar firmas solo se admite donde lo permita una guía específica del NIST, y que «When used for digital signature verification, SHA-1 is allowed for legacy use». Para los módulos RSA de 1024, 1280, 1536 y 1792 bits dice que «may continue to be used for signature verification but not signature generation».
Lo útil del ejemplo es la forma: separa generar de verificar. El texto peruano de software que vimos no hace esa distinción. En el sitio del NIST figura un borrador de la revisión 3, publicado el 21 de octubre de 2024; no lo leímos.
Qué hacer tú
- Mira con qué algoritmo está firmado tu certificado. Con
openssl x509 -in tu-certificado.cer -noout -textbuscaSignature AlgorithmyPublic-Key(añade-inform DERsi falla por formato). El artículo sobre la longitud y el algoritmo explica qué leer, y el del hash qué función usa la firma. - Sella desde el primer día lo que deba durar más que tu certificado. Y si el formato lo admite, firma en PAdES con nivel LTA (lo vemos en PAdES, XAdES y las decisiones que no se pueden deshacer).
- Valida hoy los documentos importantes y guarda el resultado con su fecha. No sustituye al sello, pero deja constancia de cómo se veían. Se hace con el validador.
- Pregunta por escrito a tu entidad de certificación si ofrece sellado de tiempo acreditado, si ofrece resellado o preservación, y cómo avisaría si cambia el algoritmo de sus certificados. La CPS de RENIEC no responde la tercera.
Lo que sale mal
- Dar por cierto que «SHA-256 ya no sirve». No encontramos ninguna fuente peruana ni de las citadas aquí que lo diga.
- Confundir debilidad de algoritmo con llave comprometida. La segunda tiene procedimiento y plazo de 24 horas en la CPS; la primera no.
- Sellar una vez y olvidarse. El RFC 4998 describe el sello como algo que se renueva.
- Archivar el PDF sin el material de validación. Un validador futuro necesitará los certificados y las respuestas de revocación de la fecha de firma.
Nuestra opinión
Si un documento debe valer más años que tu certificado, el sello de tiempo es la decisión que no admite demora, porque sellar hoy cuesta poco y sellar después no existe. En cambio, no vale la pena cambiar de certificado por miedo a un anuncio que nadie ha hecho: cámbialo cuando venza o cuando tu entidad lo indique por escrito. Y si guardas archivos por diez años o más, elige un prestador que te diga por contrato si resella, porque la norma peruana todavía no dice quién lo hace.
Lo que este artículo no afirma
- Que un algoritmo concreto vaya a dejar de ser seguro, ni cuándo. No citamos fechas de ruptura ni estimaciones. Tampoco tratamos la computación cuántica.
- Que exista, o no exista, una norma peruana de transición de algoritmos. Buscamos en las guías de EC, ER, SVA y software, la CPS de RENIEC, el D.S. 052-2008-PCM y sus modificatorias leídas (070-2011, 026-2016, 105-2012, 029-2021, 155-2022 y 082-2024), y no apareció. No leímos un texto consolidado del reglamento ni todas las normas de INDECOPI.
- Qué efecto jurídico tiene una firma hecha con un algoritmo después declarado obsoleto. Los textos no lo dicen.
- Que el requerimiento 6 de la guía de software impida verificar firmas antiguas. Hablamos de lo que dice, no de cómo lo aplica cada programa.
- Que la convivencia de las dos cadenas de 2010 fuera una migración planificada. Es lectura nuestra de dos fechas.
- Qué hace hoy cada programa con un certificado firmado con SHA-1. No lo probamos.
Fuentes
Consultadas el 25 de octubre de 2026. Copias locales en reports/redaccion-diaria/; lo descargado hoy, en 2026-10-25-notas/fuentes/mfd-algoritmo/.
- INDECOPI, Guía de Acreditación de EC v. 4.1 (28 de agosto de 2019), apartado «Ingeniería criptográfica». Copia:
2026-10-17-notas/fuentes/mfd-ec/guia-ec.txt. - INDECOPI, Guía de Acreditación de Aplicaciones de Software de Firma Digital v. 4.0 (revisión 2016), requerimiento 6 y anexo A, y su anexo 1. Copias:
mfd-algoritmo/guia-sfd.txt,mfd-algoritmo/sfd-anexo1.txt. - INDECOPI, Guía de Acreditación de Prestadores de Servicios de Valor Añadido v. 4.0 (revisión 2016). Copia:
mfd-algoritmo/guia-sva-2017.txt. - INDECOPI, colección de guías de acreditación de firma digital. Copia:
mfd-algoritmo/col-39025.html. - RENIEC, Declaración de Prácticas de Certificación ECEP-RENIEC v. 5.1 (4 de junio de 2026), numerales 4.9.12, 5.6, 5.7.3 y 6.1.5. Copia:
2026-10-24-notas/fuentes/mfd-cadena/cps-ecep-v5.1.txt. - Ley 27269, El Peruano, 28 de mayo de 2000, artículo 10. Copia:
2026-10-17-notas/fuentes/mfd-ec/ley27269_gobpe.txt. - D.S. 052-2008-PCM, El Peruano, 19 de julio de 2008, artículos 8, 16 y 17. Copia:
2026-10-24-notas/fuentes/mfd-cadena/ds052_gobpe.txt. - D.S. 070-2011-PCM, El Peruano, 27 de julio de 2011 (artículo 16, lectura por OCR). Copia:
2026-10-24-notas/fuentes/mfd-cifrar/ds070-2011-ocr.txt. - D.S. 105-2012-PCM, El Peruano, 21 de octubre de 2012, artículo 1 (nuevo último párrafo del artículo 5). Copia:
2026-10-17-notas/fuentes/mfd-ec/elperuano-2012-10-21.txt. - D.S. 029-2021-PCM, El Peruano, 19 de febrero de 2021: artículo 36 b) del reglamento de la Ley 27269 y disposición complementaria final trigésima. Copia:
2026-10-17-notas/fuentes/mfd-ec/ds029_elperuano.txt. - INDECOPI, lista de confianza TSL, secuencia 25. Copias:
2026-10-24-notas/fuentes/mfd-cadena/tsl-pe-22oct.xmlytsl-servicios-algoritmos.txt. - IETF, RFC 3161, agosto de 2001, y RFC 4998, agosto de 2007, apartados 1 y 1.2. Copias:
mfd-algoritmo/rfc3161.txt,mfd-algoritmo/rfc4998.txt. - ETSI, EN 319 142-1 V1.2.1 (2024-01), apartado 6.1. Copia:
mfd-algoritmo/etsi-319142-1.txt. - NIST, SP 800-131A Rev. 2 (marzo de 2019) y su página en CSRC (borrador de la rev. 3, 21 de octubre de 2024). Copias:
mfd-algoritmo/nist800-131Ar2.txt,mfd-algoritmo/nist-csrc-131A-r3.txt.
Si lo que necesitas es un certificado con el que firmar, en mifirmadigital.pe vendemos certificados digitales emitidos dentro de la Infraestructura Oficial de Firma Electrónica.
Última revisión: 25 de octubre de 2026.