esig / dss-demonstrations

Examples of DSS integration
GNU Lesser General Public License v2.1
92 stars 70 forks source link

peruvian TSL error xml #27

Closed AnguelSC closed 2 years ago

AnguelSC commented 3 years ago

Hello, I am trying to validate the TSL of Peru

https://iofe.indecopi.gob.pe/TSL/tsl-pe.xml

And I am using the online validation engine.

image

INFO | Thread-4 | eu.europa.esig.dss.tsl.job.TLValidationJob | Online refresh is running... 2021-07-13 12:26:08,458 INFO | Thread-4 | eu.europa.esig.dss.tsl.job.TLValidationJob | Running analysis for 1 TLSource(s) 2021-07-13 12:34:52,834 ERROR | pool-2-thread-1 | eu.europa.esig.dss.tsl.runnable.TLAnalysis | Cannot parse the TL with the cache key 'https___iofe_indecopi_gob_pe_TSL_tsl_pe_xml' : Unable to parse binaries. Reason : 'cvc-complex-type.4: El atributo 'lang' debe aparecer en el elemento 'tsl:URI'.' 2021-07-13 12:34:52,840 INFO | pool-2-thread-1 | eu.europa.esig.dss.validation.CommonCertificateVerifier | + New CommonCertificateVerifier created.

According to the error there is a problem with the content of the XML, which I do not understand since the Test that they have in their liberia dds-tsl-validation is already configured in the tsl-pe.xml.

I will be grateful if you help me know if I should pass any other parameter.

jeperezhernandez commented 3 years ago

Hello,

Unfortunately this error is due to the fact that the Peruvian Trusted List is a Trusted List v3: \3</tsl:TSLVersionIdentifier>

DSS however is primarily designed to handle Trusted Lists v5, which are the trusted lists used in the EU.

The problem is that there is a retro-compatibility between the Specifications of Trusted Lists v3 and the Specifications of Trusted Lists v5: In TL v3 the tsl:ElectronicAddress element MUST contain a "NonEmptyURI" whereas in TL v5 it must contain a "NonEmptyMultiLangURI".

It is this retro-compatibility issue that causes DSS to be unable to parse the Peruvian TL.

You can find the Spefications of TL v3 in ETSI TS 102 231 V3.1.2. In particular, you will find in clauses 5.3.5.2 and 5.4.3.2 that the format of an electronic address is a sequence of character strings. And indeed in the companion XSD document you will find

<xsd:element name="ElectronicAddress" type="tsl:ElectronicAddressType"/>
<xsd:complexType name="ElectronicAddressType">
    <xsd:sequence>
        <xsd:element name="URI" type="tsl:NonEmptyURIType" maxOccurs="unbounded"/>
    </xsd:sequence>
</xsd:complexType>

On the other hand, you can find the Specifications of TL v5 in ETSI TS 119 612 v2.1.1. In there you will find in the same clauses 5.3.5.2 and 5.4.3.2 that the format of an electronic address is a sequence of multilingual character strings. And indeed in the companion XSD document you will find

<!-- 2013-10. XML Schema CHANGE-->
<!-- ElectronicAddress changed to include MultilLan URIs for e-mails and web sites URIs as specified in TS 119 612-->
<xsd:element name="ElectronicAddress" type="tsl:ElectronicAddressType"/>
<xsd:complexType name="ElectronicAddressType">
    <xsd:sequence>
        <xsd:element name="URI" type="tsl:NonEmptyMultiLangURIType" maxOccurs="unbounded"/>
    </xsd:sequence>
</xsd:complexType>

Since the TL v3 is a historical standard, I would really recommend a migration to TL v5. Furthermore, this would improve the chance of mutual recognition with the EU. FYI: The European Commission has set up a pilot for the recognition of trust services with other countries, and there is a useful documentation included in the pilot: https://esignature.ec.europa.eu/intl-comp/dss-demo There Commission also makes publicly available a "Trusted List Manager non-EU" suitable to create, sign and edit a Trusted List v5: https://ec.europa.eu/cefdigital/wiki/display/TLSO/Trusted+List+Manager+non-EU

Hope this helps,

Kind regards,

Jean-Emmanuel PEREZ HERNANDEZ