Timestamping questions

[sangar82]

Hi again :)

I've some questions about timestamping: 1- There is a way to pass a custom tsa_url to the signDocument method ? 2- If no there is a way, can you provide an example to timestamp after signDocument method has executed?

I try this with no success (A timestamp cannot be created because there is no existng signaure with @Id '')

        XAdES::timestamp(
            new InputResourceInfo(
                $path_xml, // The source signed document with signDocument method
                ResourceInfo::file, // The source is a file
                $partes_ruta['dirname'], // The location to save the timestamped document
                $partes_ruta['filename'].'_timestamped', // The name of the file to save the timestamped document in,
            ),
            $tsaURL );
    }

[bseddon]

You ask a good question. When you add a timestamp using the static function, it is always being added to an existing signature. However the existing signature might be a counter signature within the main signature not the main signature itself. Because of this potential ambiguity when a timestamp is being added to an existing signature the @id of the signature to timestamp has to be supplied. So your InputResourceInfo instantiation will look something like:

new InputResourceInfo(
    $path_xml, // The source signed document with signDocument method
    ResourceInfo::file, // The source is a file
    $partes_ruta['dirname'], // The location to save the timestamped document
    $partes_ruta['filename'].'_timestamped', // The name of the file to save the timestamped document in,
    null, // Transforms
    true, // Detached?
    'the_sig_id' // @id of the signature to timestamp
)

However, it will be better to be able to pass a url when the original signature is being created so I have updated XAdES.php to allow an alternative url to be passed. At the moment this file is not available via composer so you will need to grab it from the repository.

Please note that the example in the README is not correct when considering the last parameters so I've updated it. You will see now that the last two parameters have been replaced with a single parameter called $options which is an array of named values. This allows for more flexibility as an endless number of parameters can be provided and this is useful for being able to handle different policies. It is not a new change, its just that I didn't update the README before making the repository public.

Anyway, the relevance to you is that the $options element called 'addTimestamp' can now be a string value so the TSA url can be provided. If a string value is passed it is obviously also 'true' so a timestamp will be added using the url passed.

What TSA are you using?

[sangar82]

I'm using a pay service TSA to ensure get a qualified timestamp called Firma Profesional and digicert and freetsa for testing.

After the last changes we achieved a valid XAdES-BASELINE-T Signature format and timestamp the xml! Thank you!!

At this moment, i haven't implement the bundle certification that you have commented in https://github.com/bseddon/xml-signer/issues/4#issuecomment-929304421 . ¿This if for achieve a xml with LTV (Long term validation)? Is working without it.

The last question: Can this package sign with XAdES-BASELINE-LT or XADES-XL?

XAdES-BASELINE-LT: Signature with Long Term Data Certificates and revocation data are embedded to allow verification in future even if their original source is not available. This level is equivalent to the old -XL level.

[sangar82]

OFFTOPIC: We can use composer to download code without release, pointing to a branch

in composer.json

    "require": {
         ...
        "lyquidity/xml-signer": "dev-main",
         ...
     },

    "repositories": [      
        {
            "type": "git",
            "url": "https://github.com/bseddon/xml-signer.git"
        }
    ],

[bseddon]

Great to learn that you have been able to produce a timestamp. The comment about a bundle was 'just in case' you needed it. Fortunately you didn't need it.

In principle the additional forms can be produced. The elements defined in the XAdES specification, such as CompleteCertificateRefsV2 or AttributeCertificateRefsV2, are implemented by the signer however have zero testing. I do not have a reason to use them so I have no example I can use to test the functionality.

If you have a use case it will be great to have a reason to create tests and examples of the extended forms.

[sangar82]

The main reason for us is that a file witit LTV is a proof by itself in a judgmenet and valid for the entire European Union and it is a proof that does not expire thanks to the LTV. Without LTV, the sign expires. You do not have to provide the signer's keys because they are already included in the file. Even if they are revoked, the signed item and the time stamp will remain valid, because the intermediate certificates of the signer and the TA are included. On our platform, we will make the xml file available to our users to download and in the future, to be able to use it as a judicial evidence. In a way, it is a file with a self-validating signature. Another important reason is that, for example, in the case of PDF, Acrobat Reader detects if the pdf is signed with LTV or if the signature will expire on a certain date. Is something that is used and known on another file formats. (the equivalent of xades-xl to pdf is pades-ltv)

Example pdf without LTV (the sign will expire):

Example pdf with LTV (the sign will not expire):

https://ec.europa.eu/cefdigital/DSS/webapp-demo/doc/dss-documentation.html#_xades_baseline_lt

[bseddon]

Thanks for the links. It's interesting that the DSS web app documentation uses the older specification terms not the specification from 2016.

I will look at adding examples of using the elements used to support long term validation but I will not be able to get to it for at least a couple of weeks. In the meantime, if you find or know of any examples of existing signatures that include elements that are part of the support for long term validation it will be great to be able to access them. Extending the signer to be able to validate existing documents first will give me confidence about the content added to them when creating these elements.

[sangar82]

@bseddon great news! With the web app you can sign documents with any format! It could be great to generate examples!

https://ec.europa.eu/cefdigital/DSS/webapp-demo/sign-a-document

[bseddon]

Good point!