search

lovele0107 / signatures-conformance-checker

7 stars 0 forks source link

CounterSignature validation problem #13

Open hafedh-trimeche opened 3 years ago

hafedh-trimeche commented 3 years ago

I can't figure out why the attached document doesn't pass validation? CounterSignature.Txt

The error message:


Children order and number DO NOT MATCH specification

Specification: (xadesv132:CounterSignature || xadesv132:SignatureTimeStamp || xadesv132:CertificateValues || xadesv132:RevocationValues || xadesv132:AttrAuthoritiesCertValues || xadesv132:AttributeRevocationValues || xadesv132:ArchiveTimeStamp || xadesv141:ArchiveTimeStamp || xadesv141:TimeStampValidationData || xadesv141:CompleteCertificateRefsV2 || xadesv132:CompleteRevocationRefs || xadesv141:AttributeCertificateRefsV2 || |xadesv132:AttrAuthoritiesCertValues || xadesv132:AttributeRevocationValues\s* || xadesv132:AttributeRevocationRefs || xadesv141:RefsOnlyTimeStampV2 || xadesv141:SigAndRefsTimeStampV2 )+

Elements found: CounterSignature xadesv132:SignatureTimeStamp xadesv132:RevocationValues

Error indication (^ appears at the end of the last correct child): ^CounterSignature xadesv132:SignatureTimeStamp xadesv132:RevocationValues

despite this CounterSignature node:

<xades:CounterSignature xmlns:xades="http://uri.etsi.org/01903#CountersignedSignature">
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="DSIG-0C06EEEFFA">
...
</ds:Signature>
</xades:CounterSignature>

Best regards.

jccruellas commented 3 years ago

Good aternoon, Hafedh-trimeche. Making an inspection to your signature, I have noticed something in the CounterSignature element. The element starts as follows:

Now, look to the xmlns:xades="http://uri.etsi.org/01903#CountersignedSignature". The xmlns attribute define namespace's URIs. More specifically, this attribute defines a new namespace whose URI is "http://uri.etsi.org/01903#CountersignedSignature". The consequence of this is that your CounterSignature is not defined in the ETSI namespace whose URI is "http://uri.etsi.org/01903/v1.3.2#", but in this other one. And this is the reason why the AdESCC signals the error just in this element. Please note that the report says that it has found an error in the CounterSignature, not in the xadesv132:CounterSignature...and the reason is that the AdESCC does not have information about what prefix is associated to the namespace whose URI is "http://uri.etsi.org/01903#CountersignedSignature". I am not sure why you have added this xmlns attribute. The URI "http://uri.etsi.org/01903#CountersignedSignature" is reserved for the Type attribute of a signature that is countersigned by a non-embedded counter signature, not for the namespace of the embedded CounterSignature qualifying property. Hope that this helps. Could you please confirm that you agree with my considerations so that I may close the issue? Regards Juan Carlos
hafedh-trimeche commented 3 years ago

Hello Juan Carlos,

Thank you for your valuable clarification.

Namespace removed but error content changed to:

80. Error   Tool    Location-{CodeTest}:UnsignedSignatureProperties/CounterSignature[1]/SignedInfo/Reference[1]-{CheckSignedInfoReference}
Problems while trying to access a variable. Details: Required attribute 'refsMap'is not present or its value is empty in driving file.Contact developer

81. Error   Tool    Location-{CodeTest}:UnsignedSignatureProperties/CounterSignature[1]/SignedInfo/Reference[2]-{CheckSignedInfoReference}
Problems while trying to access a variable. Details: Required attribute 'refsMap'is not present or its value is empty in driving file.Contact developer

82. Error   Tool    Location-{CodeTest}:UnsignedSignatureProperties/CounterSignature[1]/SignedInfo/Reference[3]-{CheckSignedInfoReference}
Problems while trying to access a variable. Details: Required attribute 'refsMap'is not present or its value is empty in driving file.Contact developer

100. Error  Tool    Location-{CodeTest}:SignedSignatureProperties-{CheckSchemaForChildren}

Children order and number DO NOT MATCH specification

Specification: xadesv132:SigningTime?, xadesv132:SigningCertificate?, xadesv132:SignaturePolicyIdentifier?, xadesv132:SignatureProductionPlace?, xadesv132:SignerRole?

Elements found: xadesv132:SigningTime xadesv132:SigningCertificateV2

Error indication (^ appears at the end of the last correct child): xadesv132:SigningTime^ xadesv132:SigningCertificateV2

Please note the file attached: xmlsec.txt

Best regards.

jccruellas commented 3 years ago

Good morning Hafedh, The first messsages (the ones starting "Problems while trying to access a variable.") needs a closer look, which I will take either today or tomorrow.

The last one seems to indicate that there is some mismatch between the spec against you try to check your signature and the signature itself. Look: Specification: xadesv132:SigningTime?, xadesv132:SigningCertificate?, xadesv132:SignaturePolicyIdentifier?, xadesv132:SignatureProductionPlace?, xadesv132:SignerRole?

is telling you that the specification you have chosen for checking your signature against, is one that expects xadesv132:SigningCertificate (which is defined in TS 101 903 and used in TS 103 131...but instead, your signature is using xadesv132:SigningCertificateV2; please notice the V2 at the end....and this element is specified in EN 319 132-1....so I would say that you have made a wrong choice when selecting the specification you check your signature against. Maybe you could retry and be sure that you check your signature against ETSI EN 319 132-1 and let me know if you still have problems?

Hope this helps

Regards Juan Carlos.

hafedh-trimeche commented 3 years ago

Hello Juan,

Please note that SigningCertificate used instead SigningCertificateV2 and problem related to spec mismatch solved.

I guess that first messages are due to the impossibility to locate the previous signature value by using URI target Id="DSIG-VALUE-8B882EF90B".

<SignatureValue xmlns="http://www.w3.org/2000/09/xmldsig#" Id="DSIG-VALUE-8B882EF90B">PxtC2PvNxKh5PUvD95CtnTqk8TBCphCII5+Z+xQSUDGG2drQ1Xnm980uzwkz5HmC1r+ESTQE5If2ou1IlG+aORRfIu/16v3VrdAdJbgGgmlvMzqEjrJEerovei+a/IuiY8LGIRYlgjrA757i2RD0zOQPMGmTa8JVQSddSU6La2teu+0Ht4KKmKwd8okpqVZyrlsTVF2T6vmTgrI0op1IvC4khF9ENHIepW5Uo7MfxDjYDkXTg3epgrEw/d6IzCZh/6/5nM8bL/ju6zkqICmIQG4KtLGVXXnnksChuyrkXTuJ3A2YltRaBc8RrTahrLNWbcF1ZeGGDfarSIjuSPR2SPgyYAKIqKuWtKgQipxh5gKZi2Io58Z//YZvly7QjuNsfEKoakPbkmKJUkGj2RuIISoqz0ZfG9A9e+m0SfQ0zsuthqcrlKhPSukM9dDALHBZhZ+hfsT16SHpU6JZFDrDsxc6+CYNbfOUzqdGSvPmr2EQXS/g6Fg6TADbtZVNEEZdpzBTxsQsGPWgLiFE2FnFifS5QQ+I5avjObxtcXSrXADvdunJJbKsRcWHRRZms3kh6/3xxyjBOSdvbiMo9G5BBOjBWdakaeUDnfU09Ha4OZ7Wp5krVpSpVG80IvvRkJtJDE5Dp6yCYUj5d0tPShEoZa5ClWA5il8Llk+hI7DStks=</SignatureValue>

<ds:Reference Id="REF-SIG-801762E0E3" URI="#DSIG-VALUE-8B882EF90B">...</ds:Reference>

xmlsec-countersigned.txt

Best regards.

jccruellas commented 3 years ago

Good morning Hafedh, Glad to hear that you solved the problem of SigningCertificate. One comment though: using SigningCertificate instead SigningCertificateV2 you are not compliant against the latest XAdES spec, which is the EN. Again, XAdESCC allows you to check your signatures against both the old and the latest spec. And I understand that if you keep SigningCertificateV2 and request to XAdESCC check against ETSI EN 319 132-1, this error would not appear either. Having said that, it is up to you the type of signatures you want to create, although initially one could think that it is more convenient to manage signatures compliant with the latest versions.

From your message I also conclude that still you have the other problem. I am going to check it with my local version of the CC and let you know my findings

Best regards

jccruellas commented 3 years ago

Hi again Hafedh, I have opened the latest signature and I have noticed that it has the SigningCertificateV2, not the SigningCertificate, so my understanding is that you have conducted a check against the ETSI EN 319 132-1 and that this has solved the second issue. Sorry for the missunderstanding

Juan Carlos.

jccruellas commented 3 years ago

Hi again Hafedh,

I have uploaded to the XAdESCC portal the file that you have sent me, with the suffix changed to ".xml", I have selected to check against ETSI pre EN 319 132-1 v1.0.0 Building Blocks and Baseline, and the XAdESCC has not reported any error.

Could you please try to do the same? Because I have not been able to replicate the errors that you reported in your messages.

Juan Carlos

jccruellas commented 3 years ago

Hi again Hafedh, I have been doing some testing with a local copy of the XAdESCC which I plan to upload soon to the portal. This version includes recent versions of tools on which XAdESCC is built, XML Signature tool from Apache Santuario. Actually, your signatures have been very useful, as they have uncovered some issues in the code that I have fixed. After these ammendments, my local version of the tool still has one issue.

Another issue that I would like to bring and that has caused some problems is that in your xml file there is an end of line character as the first character of your ds:X509Certificate elements. You should not allow to do this. Every character within the elements is considered data, and therefore the X509 certificates parsing tools take it into account. I can tell you that for instance, when I tried to create an object of class CertificateHolder from BouncyCastle, one of them gave me an error, and I think that this was because of this character. What I am trying to say is that the ds:X509Certificate elements should start:

MIIGMDCCBRigAwIBAgISBGj4SJdvo3hCsTLl1cH Without any line break. Finally, another issue: Looking at the XML Signature W3C Recommendation, I am not sure whether the ds:X509Certificate elements can not have a xml:id attribute. I know that you use it for signing it, but I would say that you could have the same effect using a suitable Transforms element within the ds:Reference. Hope this helps Juan Carlos.
hafedh-trimeche commented 3 years ago

Dear Juan,

thank you for your availability.

As per:

a) Requirement for SigningCertificateV2. The SigningCertificateV2 qualifying property shall be
  present if the signing certificate is not present within the ds:KeyInfo element, or if the signing certificate is
  present within the ds:KeyInfo element but it is not signed by the signature. Otherwise the
  SigningCertificateV2 qualifying property may be absent.

b) Requirement for SigningCertificateV2. The references to certificates should not include the IssuerSerialV2 element.

SigningCertificate/SigningCertificateV2 removed since the signing certificate is referenced within ds:KeyInfo.

Line Feeds are removed from X509Certificate.

xmlsec-signed passed ETSI pre EN 319 132-2 validation.

xmlsec-signed.txt xmlsec-countersigned.txt

Best regards.

jccruellas commented 3 years ago

Hi again Hafedh,

I have checked your files with my local copy of XAdESCC, which, as I said, plan to deploy asap to the ETSI portal. Below some considerations:

  1. The suffix of the files should not be .txt but .xml.
  2. Once changed the suffix XAdESCC does not throw any error for both signatures if I check them against EN 319 132-2 BUT
  3. It raises two errors if I try to check them against EN 319 132-1. The reason is that this spec defines the XAdES baseline profile, and in its section 6 it mandates the presence of the SigningCertificateV2: it is mandatory. The XAdES baseline profile prefers to secure the signing certificate using the signed property SigningCertificateV2. Take a look to the table of requirements of presence and cardinality of the different properties in clause 6.

Once said that, I would say that my local copy of XAdESCC properly deals with your signatures and that, unless you have any other consideration we could close this issue.

Do you agree in closing it?

Juan Carlos.

hafedh-trimeche commented 3 years ago

Hi Juan,

Please note that the txt suffix is for building link under GitHub comment. GitHub doesn't accept xml file as an attached file.

I would like to know when the EN 319 132-2 will be published on https://signatures-conformance-checker.etsi.org? The actual version is qualified as pre one (ETSI pre EN 319 132-2).

Best regards.

jccruellas commented 3 years ago

Hi Hafedh, Actually the pre EN 319 132-2 is the EN 319 132-2 v1.0.0 version that is handed to the editHelp team, which introduces only editorial changes and generates the official EN 319 132-2 v1.1.1. You should consider that the XAdESCC properly deals with EN 319 132-2v1.1.1

Regards Juan Carlos.

jccruellas commented 3 years ago

I should talk with ETSI so that they change the messages in the options