XADES-XL about xml-signer HOT 26 CLOSED

Thanks for letting me know. I am starting today to add support for the archive or 'A' form of an XEdES signature. I believe this is the same as what the EU commission site calls LTV. I now have a certificate authority (CA) I can use to create certificates. The CA is able to respond to requests for CRL and OCSP responses. These responses are needed to create a valid 'ArchiveTimestamp' element.

from xml-signer.

Here is an update on my progress towards supporting the LTA profile. LTA support is defined in the XAdES specification ETSI EN 319 132-1 V1.1.1 (2016-04) in section 5. At least this section defines the content of the elements that must be present to support LTA. The exact list of elements is defined in table 2 in section 6.3 on page 50.

So far, the code is now able to generate the element <ArchiveTimeStamp> (see section 5.5.2 of the specification). The message imprint computed by the code is confirmed by both the ETSI XAdES conformance checker (see the red marker in the screenshot) and the EU commission site you have used.

The code to add an <ArchiveTimeStamp> element has been pushed to the repository. There is a new static function to add this element to an existing signature:

	XAdES::archiveTimestamp(
		new SignedDocumentResourceInfo( 
			__DIR__ . '/existing-signature.xml', 
			ResourceInfo::file,
			XAdES::SignatureRootId, // optional id
			__DIR__,
			'existing-signature-with-archive-timestamp.xml',
			XMLSecurityDSig::generateGUID('archive-timestamp-')
		)
	);

The archive element alone is not enough for the signature to be recognized as LTA. I think to be recognized as LTA the signature will need to include at least the <CertificateValues> and <Revocation> elements (see sections 5.4.1 and 5.4.2). It may also need to include <TimeStampValidationData> (section 5.51).

The issue is not adding the elements - that is straight forward, The issue is making sure the element content is complete, correct and exactly what any other XAdES signature tool will produce or compute when validating the signature. This is why it's a shame I can't produce an LTA signature on the EU commission site or with the standalone application.

Anyway, my next tasks are to add support for sections 5.4.1 and 5.4.2 and to see if I can generate the correct content for the respective elements.

Bill

from xml-signer.

Thank you, that will be great. I have tried and failed so far. There are several projects out there one written using Java, one written using JavaScript even one written in C++ but they all stop at the BASELINE-T level. And of course the standalone Java project doesn't work for me or only produces BASELINE-T level signatures.

from xml-signer.

Thanks, I will let you know, hopefully early next week.

It has affected the requester and responder dependency projects as well so you will need to update these as well. One of the LT/LTA elements is <RevocationValues> which is there to store information about certificate revocation (OCSP and CRL responses). To provide the information in exactly the form needed by the XAdES specification its been necessary to change how responses are processed. For example, one of the certificates to be added to <CertificateValues> is the certificate used to sign the OCSP and CRL responses. Until this requirement, there was no need to provide access to the signing certificate as it was good enough that it was used to confirm the responses are correctly signed.

from xml-signer.

That's great, thanks for letting me know. I will add a link from the read me to your comment so others are able to see it is possible to use the LTA profile.

I also see two timestamps but that's because I created the original signature with a timestamp (element <SignatureTimeStamp>).

The new function adds another timestamp (<ArchiveTimeStamp>). If you want to use the LTA profile then the archive time stamp is the most important. However I recommend you use both. The code is able to add the signature timestamp as the signature is created. This provides evidence of the time the signature was created. The archive timestamp also covers the original signature but also includes the signature timestamp, any additional certificate values and any revocation values. However, the archive timestamp is added some time later (may be just a short time later) so if there is no signature timestamp it is conceivable the archive content may be added much later with no verifiable confirmation of the original signing time.

The code will add the certificates (up to the root) and add the revocation information of the TSA for each of the existing timestamps found. The element <TimeStampValidation> (see section 5.5.1) is designed to hold this information. A signature validator is expected to use the information recorded in this element to confirm the certificate signing the timestamp was valid at the time.

Yes, two timestamps are ideal but the 'A' in LTA is the archive timestamp so this one is mandatory if the LTA level is required.

from xml-signer.

The code grabs a copy the full certificate chain of all certificates used (for signing and timestamping). However, this assumes a certificate used includes information about it's issuer (CA). Almost all do as there is a specific variable in a certificate (called an 'extension' in the jargon) for this URL.

If a certificate does not include information about how to access it's issuer then this can be added to the certificate PEM file referenced by the CertificateResourceInfo class. All certificates in this PEM file are added to the ./KeyInfo/X509Data element when the signature is created.

from xml-signer.

Hi, as I mentioned in this issue #5 I was not able to get to it straight away. However, I am hoping to make a start on Monday.

It will be great if you can upload as an attachment a copy of a long term signature you create on the EU commission site. The content being signed is not important - it can be your weekly shopping list. Of course I can create an example, and I will, but getting a copy from you serves two purposes:

1 It's an example of what you want so there is no question about the minimum I should aim for;
2 I'm not marking my own homework. Validating a document I have created may result in me making false assumptions.

I'll keep you updated.

Bill

from xml-signer.

Have you been able to create a signed document using the EU commission web site? I have not been able to use the site to create a signature. I have downloaded and installed the Java client application but it seems to need a signing device I do not have.

from xml-signer.

I have the same problem @bseddon. I'm looking how solve it from Friday. I can't install the java client. I will ask to my legal department if they can provide me an example

from xml-signer.

@bseddon here you have the eu equivalences for xades
https://ec.europa.eu/cefdigital/DSS/webapp-demo/doc/dss-documentation.html#_xades_profiles

from xml-signer.

I have installed this Java app: which appears to be a standalone version of the web application on the EU commission site. It offers to produce -B, -B-T, -B-LT and -B-LTA signatures. I am able to get it to produce signatures to the -B and -B-T levels but it complains when I try to produce -B-LT or -B-LTA signatures,

Are you able to try this application to see you are able to produce -B-LTA signatures?

from xml-signer.

Is only a windows version? I can't run the app.
Until next week, i don't have access to windows computer

from xml-signer.

It's a Java application. It includes an OpenJDK run-time so it should run on Linux. I have tried it using Windows sub-system for Linux - using Ubuntu - and it works but I see the same problem. The zip file only includes a Windows command file but I took the command out of the .bat file, changed the back slash characters to forward slashes and pasted it to the command line while in the root folder of the unzip file. Of course it may not work when using a different distribution that is not run in a virtual machine on Linux.

from xml-signer.

Excellent Bill! Great progress! I will continue searching a valid xades-xl examples or how we can generate them

from xml-signer.

@bseddon reading the documentation I've found this:
https://github.com/esig/dss/blob/master/dss-cookbook/src/main/asciidoc/dss-documentation.adoc#xades-baseline-lt

There are some examples:
https://github.com/esig/dss/blob/master/dss-cookbook/src/main/asciidoc/_samples/xades-revocation-data.adoc
https://github.com/esig/dss/blob/master/dss-cookbook/src/main/asciidoc/_samples/xades-archive-timestamp.adoc

https://github.com/esig/dss/tree/master/dss-cookbook/src/main/asciidoc/_samples

Can it help you?

from xml-signer.

These are not so good for me. These documents are confirming what elements should be included but this is covered in the specification. So I know what should go into the signature but I can't be 100% sure the way I am reading the specification is correct. The '.adoc. links show fragments from a signature. But how was it decided that those values should be included?

With access to a full signature that is accepted by the EU commission demo web app or the XAdES conformance checker I will be able to apply my reading of the specification to the document to see I generate the same values. If not, I can try to better understand what the specification really says.

Right now I am writing code that I think implements the specification which I will be able to test. But if the generated signature is not accepted by any of the validators then I have to scratch my head and try to find what I have done wrong. Is the code wrong or have I misunderstood what the specification says.

I am really surprised there are no complete signatures provided by ETSI for all profiles (-B, -T, -LT, -LTA etc,). I have written to ask if there are any but I've no had a response yet.

from xml-signer.

Or take this example from the DSS GitHub page (which I saved as a file and attached) - it does not validate on the DSS web app site (at least for me)

Usually support for conformance testing is critically important. Major standards (XML, XPath, XQuery, etc.) come with huge test libraries so implementers are able to ensure their code is able to produce the correct output. This doesn't seem to be the case with XAdES. Ah,well, hopefully the way I am reading the specification is correct and the signatures produced will be great!
signedXmlXadesLT.zip
.

from xml-signer.

If you need me to validate your tests with my signature and my TA (which are validated in the EU certifier) you just have to tell me. You could, for example, prepare a branch for me to try to sign your progress with my signatures and my TA if necessary.

from xml-signer.

The repository now includes updates I believe add support for the LT and LTA profiles. The composer packages for the XAdES project and the supporting requester project have also been updated.

Some comments have been added to the readme about the support and its known limitations (there are likely to be many other unknown limitations).

At the moment I am able to generate a signature which the ETSI XAdES conformance checker is able to process without any error reports. That is, the way it computes content hashes over the new elements (<CertificateValues>, <RevocationValues> and <TimeStampValidationData> is the same as the signing project. However, I don't think it evaluates the content so the content could be wrong or incomplete.

It will be great if you are able to try to use the new static function to see if it generates a signature.

from xml-signer.

It's encouraging that the EU DSS web app identifies the signature I can generate as LTA. Obviously my certificate does not have one of the recognized trust service providers as it's root so the signature is not valid.

from xml-signer.

Excellent @bseddon !! We have LTA !! Great job!

We have some questions:

• Why are there two timestamps ? Shouldn't there be just one?
• We are creating too PADES-BASELINE_LT documents. With the software for creating them, we need to add the root certificates for TSA and the signature root certificate for revocation. Could be possible that this implementation saves us to make a new timestamping with the TSA. Could be they create the revocation before make a request to the TSA to save one timestamping?

Great job @bseddon ! Thank you!

Edit:
I've read this:

• B-LTA level, which is the level of a Signature providing Long Term Availability and Integrity of Validation Material . It is built from the previous level by adding a time stamp token on the validation material as unsigned properties, thereby establishing evidence that the validation data existed at the indicated time.

The two timestamps is for achieve B-LTA level?

from xml-signer.

I have understood it!
Thank you @bseddon !
Great job!!

from xml-signer.

Ok! @bseddon ! I understand this!

Another question:

• If you don't add a new SignatureTimeStamp, it will produce a Xades-baseline-LT format? Could be interesting produce it if is easy. p.ex with another method.
  Thank you!!

from xml-signer.

I don't know. The code does not add a SignatureTimeStamp element unless you ask it to (either by using the option to add one when the signature is created or by using the static method). So you should be able to create a signature with just the ArchiveTimeStamp element and see what level the web app reports.

from xml-signer.

Thanks for your help (and encouragement)

from xml-signer.

Thanks to you Bill! If you come to Girona let me know and we will celebrate this great package! Thank you!

from xml-signer.