Open hafedh-trimeche opened 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:
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.
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.
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>
Best regards.
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
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.
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
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:
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.
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:
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.
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.
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.
I should talk with ETSI so that they change the messages in the options
I can't figure out why the attached document doesn't pass validation? CounterSignature.Txt
The error message:
despite this CounterSignature node:
Best regards.