La SET de Paraguay publica las Notas Técnicas No.16 y 17, referente a la firma digital.

La Subsecretaria de Estado de Tributación (SET) de Paraguay, publicó en su página web las Notas Técnicas No.16 y 17, en la sección de Documentación Técnica, las cuales comprenden ajustes que se incorporan al Manual Técnico del Sistema Integrado de Facturación Electrónica Nacional (SIFEN).

¿Qué cambios se incorporan en la Nota Técnica No. 16?

Se realizaron cambios en algunas secciones relacionadas con el formato de la firma digital y sus validaciones:

1. Sección 7.6. Estándar de firma digital.

2. Sección 12.2.4 Validación de certificado de firma.

3. Sección 12.2.5 Validación de la firma digital.

4. Sección 12.4. Validaciones del formato.

5. Sección 12.2.1 Validaciones del certificado de transmisión. Protocolo TLS.

 

1. En la sección “7.6. Estándar de firma digital” se realizaron las siguientes modificaciones :

  • Para el ID XS02 se corrige el nombre del campo a SignedInfo.

ID

Campo
ANTERIOR

Campo
NOTA 16

XS02

SinnedInfo

SignedInfo

  • Para el campo Algorithm, ID XS04 se incorporó tres nuevos atributos en la observación (Inclusiva con comentarios, Exclusiva y Exclusiva con comentarios)

ID

Observación
ANTERIOR

Observación
NOTA 16

XS04

Atributo Algorithm de CanonicalizationMethod
https://www.w3.org/TR/2001/REC-xml-c14n- 20010315

Atributo Algorithm de CanonicalizationMethod

Atributos válidos:

http://www.w3.org/TR/2001/REC-xml-c14n-20010315
(Inclusiva)

http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments
(Inclusiva con comentarios)

http://www.w3.org/2001/10/xml-exc-c14n
(Exclusiva)

http://www.w3.org/2001/10/xml-excc14n#WithComments
(Exclusiva con comentarios)

  • Para el campo Algorithm, ID XS06 se incorporó dos nuevos atributos en la observación (RSA-SHA-384 y RSA-SHA-512).

ID

Observación
ANTERIOR

Observación
NOTA 16

XS06

Atributo Algorithm de SignatureMethod: Sha256RSA

http://www.w3.org/2001/04/xmldsig-more#rsa- sha256

Atributo Algorithm de SignatureMethod

Atributos válidos:

http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 (RSA-SHA-256)

http://www.w3.org/2001/04/xmldsig-more#rsasha384 (RSA-SHA-384)

http://www.w3.org/2001/04/xmldsig-more#rsasha512 (RSA-SHA-512)

  • Al campo Transform, ID XS12 se le realizan ajustes en el nombre del “Campo”, la “Ocurrencia” y en “Observación”, como se muestra en el siguiente cuadro:

ID

Campo
ANTERIOR

Campo
NOTA 16

Ocurrencia
ANTERIOR

Ocurrencia
NOTA 16

Observación
ANTERIOR

Observación
NOTA 16

XS12

Transforms

Transform

2-2

1-1

Grupo del Transform

Tag del algoritmo de transformación

En la “Ocurrencia” cambia de 2-2 a 1-1, lo cual significa que el número Mínimo de veces que el campo debe aparecer paso de dos (2) a uno (1) y el número Máximo de veces que el campo debe aparecer en el grupo paso de dos (2) a (1).

 

  • Con respecto al ID XS13, se realizan ajustes con respecto a la “Ocurrencia” y a la “Observación”, como se muestra en el siguiente cuadro:

ID

Ocurrencia
ANTERIOR

Ocurrencia
NOTA 16

Observación
ANTERIOR

Observación
NOTA 16

XS13

2-2

1-1

Atributos válidos Algorithm de Transform:
https://www.w3.org/TR/xmldsig-core1/#sec- EnvelopedSignature
http://www.w3.org/2001/10/xml-exc-c14n#

Atributo Algorithm del tag Transform Atributo válido:
http://www.w3.org/2000/09/xmldsig#enveloped-signature (Enveloped Signature)

En la “Ocurrencia” cambia de 2-2 a 1-1, lo cual significa que el número Mínimo de veces que el campo debe aparecer paso de dos (2) a uno (1) y el número Máximo de veces que el campo debe aparecer en el grupo paso de dos (2) a (1). En la Observación se actualiza la URL del atributo válido Enveloped Signature.

 

  • Se elimina el elemento XPath, ID XS14:

ID

Campo

Descripción

Nodo Padre

Observaciones

XS14

XPath

Elemento

XS12

XPath

  • Se actualiza las observaciones para el campo Algorithm, ID XS16, actualizando la URLdel atributo SHA-256 e incorporando dos nuevos atributos (SHA-384 y SHA-512).

ID

Observación
ANTERIOR

Observación
NOTA 16

XS16

Atributo del algoritmo utilizado para el DigestMethod:

https://www.w3.org/TR/2002/REC-xmlenc-core-20021210/Overview.html#sha256

Atributo Algorithm del tag DigestMethod

Atributos válidos:

http://www.w3.org/2001/04/xmlenc#sha256 (SHA-256)

http://www.w3.org/2001/04/xmldsig-more#sha384 (SHA-384)

http://www.w3.org/2001/04/xmlenc#sha512 (SHA-512)

 

  • El campo DigestValue, ID XS17 en su campo observación pasó de indicar que se trataba de un HASH SHA-256 a indicar que el valor del campo corresponderá al valor retornado por el campo Algorithm, ID.
  • El campo SignatureValue, ID XS18 pasará a tomar el valor indicado en el campo Algorithm, ID XS06.
  • En nueve (9) ID se realizan ajustes únicamente en el campo de “observación” en relación con los siguientes ID: XS03, XS05, XS07, XS08, XS10, XS15, XS19, XS20 y XS21.

 

2. En la sección “2.4 Validación de certificado de firma”. se realiza un ajuste en el campo de “Observación, para el ID AC01 (Certificado Inválido), en el cual se incorpora una validación adicional correspondiente a “Cadena de Certificación inválida”.

ID

Mensaje de la Validación

Código

Observación
ANTERIOR

Observación
NOTA 16

AC01

Certificado inválido

120

* No existe el certificado de firma en el mensaje.
* No se aceptan certificados del PSC.
* KeyUsage no define firma digital y no Repudio.

* No existe el certificado de firma en el mensaje.
* No se aceptan certificados del PSC.
* KeyUsage no define firma digital y no Repudio.
* Cadena de certificación inválida.

 

3. En la sección “12.2.5 Validación de la firma digital”, se realizan ajustes en los campos de “Resultado de la validación” y de “Observación”, para los ID AD01 y AD02, incorporando 4 nuevas validaciones para el ID AD01 (Canonicalization Method, Signature Method, Digest Method y Reference URI). Por otro lado, se eliminan 9 validaciones del valor de la firma.

ID

Resultado de la Validación ANTERIOR

Resultado de la Validación
NOTA 16

Observación                ANTERIOR

Observación
NOTA 16

AD01

Firma difiere del estándar

Firma difiere del estándar
[Detalle del error]

No fue firmado el documento completo (falta Reference URI en la firma).

Transform Algorithm previsto en la firma (“C14N” y Enveloped) no informado.

No fue firmado el documento completo (falta Reference URI en la firma).

Transform Algorithm previsto en la firma (Enveloped Signature) no informado o no válido.
Canonicalization Method previsto en la firma no informado o no válido.

Signature Method previsto en la firma no informado o no válido.

Digest Method previsto en la firma no informado o no válido.

Reference URI no coincide con el atributo Id del documento.

AD02

Valor de la firma (SignatureValue) diferente del calculado por el PKI

Valor de la firma (SignatureValue) diferente del calculado por el PKI
[Detalle del error]

XML modificado luego de la firma o mal firmado.

Certificado del PCSC no habilitado por el MIC.

Certificado del PCSC revocado.

Certificado no está firmado por el PCSC.

Dirección de la LCR no informada (CRLDistributionPoint).

Error en el acceso a la LCR.
LCR inexistente.

Certificado de firma revocado.

Certificado raíz no corresponde al MIC.

XML modificado luego de la firma o mal firmado.

 

4. En la sección “12.4. Validaciones del formato”, subsección I. Información de la Firma Digital del DTE (I001-I049), se realizan ajustes en los campos de “Resultado de la validación” y de “Observación”, para el ID I002, en el campo Observación se agregan 10 validaciones, 9 de las cuales venían de las eliminadas de la validación AD02.

ID

Resultado de la Validación
ANTERIOR

Resultado de la Validación
NOTA 16

Observación
ANTERIOR

Observación
NOTA 16

I002

Certificado digital no vigente al momento de firma
del DE

Certificado digital no vigente al momento de firma del DE
[Detalle del error]

El certificado digital (I002) debe estar vigente (no revocado) al momento de la firma digital (A004).

El certificado digital (I002) debe estar vigente (no revocado) al momento de la firma digital (A004).

Certificado del PCSC no habilitado por el MIC.

Certificado del PCSC revocado.

Certificado no está firmado por el PCSC.

Dirección de la LCR no informada (CRLDistributionPoint).
Error en el acceso a la LCR.

LCR inexistente.

Certificado de firma revocado.

Certificado raíz no corresponde al MIC.
Certificado expirado.

 

5. En la sección “12.2.1 Validaciones del certificado de transmisión. Protocolo TLS”, Se incorpora un nuevo inconveniente a la tabla denominado “inconveniente temporal del SIFEN”.

 

¿Qué cambios se incorporan en las Nota Técnica No. 17?

La nota técnica No.17, realiza únicamente ajustes en los campos de “Mensaje de Validación” y “Observación” de las reglas de validación No. 71 y 74, en las cuales aclara que la descripción del distrito y de la ciudad corresponden al receptor y no al de emisión, como se muestra a continuación:

N° Val

ID

Mensaje de la Validación ANTERIOR

Mensaje de la Validación              NOTA 17

Observación     ANTERIOR

Observación                   NOTA 17

71

D222

Descripción del distrito de emisión no corresponde al código

Descripción del distrito del receptor no corresponde al código

Descripción del distrito        de emisión no coincidente con lo informado en el campo D221

Descripción del distrito del receptor no coincidente con lo informado en el campo D221

74

D224

Descripción de la ciudad de emisión no corresponde al código

Descripción de la ciudad del receptor no corresponde al código

Descripción de la ciudad        de emisión no coincidente con lo informado en el campo D223

Descripción de la ciudad del receptor no coincidente con lo informado en el campo D223

 

¿Cuándo entran en vigencia las Notas Técnicas No. 16 y 17?

Las notas presentan como fecha de puesta a disposición para ambiente de producción el 22 de septiembre de 2023 para la Nota Técnica 16, y el día 25 de agosto de 2023 para la Nota Técnica 17, como se muestra en el siguiente cuadro:

Nota Técnica 16

Fecha puesta a disposición para el Ambiente de Test

25/08/2023

Fecha puesta a disposición para el Ambiente de Producción

22/09/2023

Nota Técnica 17

Fecha puesta a disposición para el Ambiente de Test

24/08/2023

Fecha puesta a disposición para el Ambiente de Producción

25/08/2023

 

Más información: Se incorpora el enlace de consulta de las Notas Técnicas.  

NOTA TECNICA No. 16

NOTA TECNICA No. 17

 

¿Tiene dudas sobre estos cambios?

Si quiere ver esta u otras noticias regulatorias dentro de la región, lo invitamos a visitar nuestro Centro de Recursos.

Si tiene alguna consulta relacionada con el comunicado que acaba de recibir, por favor contáctese el consultor o escríbanos a info@gosocket

Sobre Gosocket: Gosocket es un proveedor líder Latinoamericano que ofrece soluciones de emisión y recepción de documentos electrónicos basados en firma digital, incluyendo factura electrónica. Gosocket funciona bajo un modelo de red empresarial abierta que integra Compradores, Proveedores, Entidades Tributarias y Terceros en un ecosistema que facilita los negocios, genera eficiencias, ofrece servicios de valor agregado para todos los actores de la cadena de suministro y garantiza el cumplimiento de los requisitos técnicos relacionados con las regulación y las normas en materia de los modelos de factura electrónica en el país donde opere su organización.

Aviso de privacidad: Gosocket no se hace responsable por las acciones u omisiones de terceros que puedan implicar responsabilidades ante las autoridades tributarias. La información aquí descrita solo constituye nuestra interpretación de la información pública disponible en el momento de publicación. Si usted desea asesoría personalizada le invitamos a contactar con nuestro equipo de consultoría.

Compartir

Artículos relacionados