lovele0107 / signatures-conformance-checker

7 stars 0 forks source link

Number of transforms within SignaturePolicyId #19

Open bseddon opened 3 years ago

bseddon commented 3 years ago

Hi

It's great to have found the checker and today I've been learning how to understand the messages it can produce. As I am new to the tool, my understanding is not likely to be great so please accept my apologies in advance if I've missed something obvious.

The attached file causes the checker to report two errors. The error that is the focus of this issue post is the first which is also shown in the screenshot below.

signature.zip

In every case that I have investigated, this error is displayed whenever there is more than one <Transform> within <SignaturePolicyId>. If there is one no error is displayed. If the signature process is modified to create an additional preceding <Transform> then an error is produced. Note that adding a succeeding <Transform> also results in an error. In the example shown below, it appears to be the case that a working <Transform> becomes an error only because there is more than one.

A <SignaturePolicyId> containing this single does not produce an error:

<Transforms xmlns="http://www.w3.org/2000/09/xmldsig#">
    <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
        <XPath xmlns:dsig="&mynamespace;">not(ancestor-or-self::dsig:SignPolicyDigest)</XPath>
    </Transform>
</Transforms>

Precede this with an additional <Transform>, in this case to include a canonicalization step, an error is produced. This is the transform set included in the example signature file attached.

<Transforms xmlns="http://www.w3.org/2000/09/xmldsig#">
    <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
    <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
        <XPath xmlns:dsig="&mynamespace;">not(ancestor-or-self::dsig:SignPolicyDigest)</XPath>
    </Transform>
</Transforms>

The type for <SignaturePolicyId> is defined in section 5.2.9.1 of ETSI 319 132 and in section 7.2.3 of ETSI TS 101 903 V1.4.2. Both describe the xsd type SignaturePolicyIdentifierType which, in turn, references the standard XmlDSig <Transforms> type allowing zero or more <Transform> instances.

Information within the generated error message also indicates that more than one or more instances should be permitted but I cannot understand why only the second <Transform> instance causes an error (even though no error is generated when it is the only <Transform> present).

xades checker transform issue

jccruellas commented 3 years ago

Good morning,

First of all, thank you very much for using the XAdESCC tool.

As for your question, indeed you are right. Your ds:Transforms element is correct in terms of its children.

The tool checks this aspect concatenating the qualified names of the children of the ds:Transforms element and checking whether the obtained concatenation matches a regular expression. The reason for the failure was that the regular expression for this particular element was not fully correct.

I have fixed it in my local copy and with this fix, your signature, when checked against the ETSI TS 101 903 v1.4.2 does not raise any error.

You may assume that your ds:Transforms element is correct.

I am fixing other things of the XAdESCC. When I finalize them, I will upload a new version to the server and you will see no errors in this part.

Best regards Juan Carlos

bseddon commented 3 years ago

What a fast response! Thanks for the information.