lovele0107 / signatures-conformance-checker

7 stars 0 forks source link

XAdES: Error with order of SignedProperties #7

Closed dfdiego closed 3 years ago

dfdiego commented 3 years ago

Hello,

I'm receiving this error:

Location-{CodeTest}:SignedProperties-{CheckSchemaForChildren}
--
Children order and number DO NOT MATCH specificationSpecification: xadesv132:SignedSignatureProperties, xadesv132:SignedDataObjectProperties
Elements found: xadesv132:SignedSignatureProperties
Error indication (^ appears at the end of the last correct child): xadesv132:SignedSignatureProperties^

In the XAdES I've only one children SignedSignatureProperties and no SignedDataObjectProperties, I'm pretty sure this is ok, because the specification states that there can be 0 or more of each children types:

<!-- targetNamespace="http://uri.etsi.org/01903/v1.3.2#" -->
<xsd:element name="SignedProperties" type="SignedPropertiesType" />
<xsd:complexType name="SignedPropertiesType">
       <xsd:sequence>
            <xsd:element ref="SignedSignatureProperties" minOccurs="0"/>
            <xsd:element ref="SignedDataObjectProperties" minOccurs="0"/>
       </xsd:sequence>
       <xsd:attribute name="Id" type="xsd:ID" use="optional"/>
</xsd:complexType>

This is the XAdES document part:

    <Object>
      <xades:QualifyingProperties Target="#XSIG1" xmlns:xades="http://uri.etsi.org/01903/v1.3.2#">
        <xades:SignedProperties Id="XSIGXADES1">
          <xades:SignedSignatureProperties>
            <xades:SigningTime>2021-02-26T15:28:46.387058+01:00</xades:SigningTime>
            <xades:SigningCertificate>
              <xades:Cert>
                <xades:CertDigest>
                  <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
                  <ds:DigestValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...removed for example...</ds:DigestValue>
                </xades:CertDigest>
                <xades:IssuerSerial>
                  <X509IssuerName>...removed for example...</X509IssuerName>
                  <X509SerialNumber>...removed for example...</X509SerialNumber>
                </xades:IssuerSerial>
              </xades:Cert>
            </xades:SigningCertificate>
          </xades:SignedSignatureProperties>
        </xades:SignedProperties>
      </xades:QualifyingProperties>
    </Object>
jccruellas commented 3 years ago

Good morning dfdiego,

First of all I apology for not reacting before. I had problems during some time and did not receive notifications from github in my email so I was not aware of the arrival of issues, and also had a heavy workload in the university where I work.

Regarding your question, I guess that you get this error because you requested to XAdESCC to check conformance against ETSI EN 319 132-1, which defines the building blocks of XAdES and the XAdES baseline signatures profiles. When you request to XAdESCC to check signatures against this spec, the tool checks whether the signature meets the requirements defined in all the normative clauses of EN 319 132-1, including clause 6. This clause defines a set of additional requirements on presence and cardinality to all the components that have been defined in previous clauses. And one of the requirements defined is that any XAdES baseline signature must include the signed attribute DataObjectFormat....which is a child of SignedDataObjectProperties. And this is the reason why the XAdESCC most likely raises this error.

I would say that if instead checking against EN 319 132-1 you request to check your signature against EN 319 132-2, the error shall disappear: this specification defines XAdES forms that do not require the DataObjectFormat.

Could you please proceed as indicated and let me know what you get?

Regards Juan Carlos.

dfdiego commented 3 years ago

Hello Juan Carlos,

I've already tested against the various profiles, and the same error also appears with "ETSI TS 103 171 v2.1.1 Baseline Profile" and "ETSI pre EN 319 132-1 v1.0.0 Building Blocks and Baseline". For me the strange part is with "103 171".

Thanks you for the help.

jccruellas commented 3 years ago

Hi Diego. It is logical that XAdESCC generates the same error when checked against "ETSI TS 103 171 v2.1.1 Baseline Profile". Notice that this document also defines a baseline profile. Now some hints of the history of XAdES.

ETSI TS 101 903 was the first spec of XAdES. It defined the building blocs and some combinations of properties: no requirements of having the dataobjectformat. Therefore you will not get the error we are dealing with. As the degree of optionality was high, ETSI produced a baseline profile for minimizing this degree, and then it required the presence of dataobjectformat.

When the EU Regulation eIDAS was published the EC requested ESI to produce ENs (European Norms: European Standards, approved by all the National Standardization Organizations of the EU Member States), so ETSI built the EN 319 132-1 which specified the building blocks (some of them modified) and the baseline profile (dataobject mandatory), because this was seen as more for becoming the first part of the new standard. EN 319 132-2 was then left to other combinations of properties and therefore dataobjectformat is not mandatory

So, this is the reason for the different results that you get.

What I would expect is that new implementations implement the EN (one or two parts), more than the old TSs

Hope this helps to understand the whole situation Juan Carlos

PSD: do you think that we can close this issue?

dfdiego commented 3 years ago

Ok, I understand the logic of the tool.

Thanks.