esig
How can I create a new trust list and add it to the DSS Demonstration WebApp?
Hello!
I want to experiment using my new trust list.
-
How should I create a trust list? As of now, It seems that development of the software at the following URL has stopped. Trusted List Manager non-EU Do you know of any other alternative software?
-
Assuming that I want to use something that already exists, how can I load the following XML into a DSS Demonstration WebApp? https://eidas.ec.europa.eu/efda/intl-pilot/api/v1/intl-pilot/mra_lotl.xml
I apologize for the broad question, but I want to try various things.
Thank you.
Hello,
-
You may try to use TL Manager or TL Manager non-EU, they still should be working, as no changes in the TL framework has been done since that time. However, there may be some changes in the future with introduction of a Trusted List v6 (as per ETSI TS 119 612 v2.3.1), but I do not know whether or how soon the aforementioned applications will be updated. The mentioned standard is not yet in force and the TL v5 is still applicable.
-
Yes, you may to load the given LOTL or a custom LOTL/TL within the demo-webapp. The quickest option will be to specify the URL of the LOTL within the dss-custom.properties file available at apache-tomcat-*\lib\ of the built bundle within the one of the following parameters:
current.lotl.url = ***
for the main LOTL, or
tl.loader.ades.enabled=true
tl.loader.ades.lotlUrl=*
for an additional one.
Please note that a keystore also should be provided for a successful configuration.
For LOTL/TL configuration within the source code of the application, please see TL Validation Job chapter of the documentation.
Best regards, Aleksandr
@bsanchezb Hi! It might not be related to trust list, but i am using the DSS standalone application to create a custom Xades signature signer in C# using the bouncy castle library.
Anyways, signing with DSS and my code would garner me this result (using a .pfx):
Do you have any explanation as to what these warnings mean or a documentation where they would be explained? I didnt find any in the DSS docs.
Also, when signing with eParaksts (the Latvian esignature manager) with an eID card, the created .edoc brought up no warnings and the Qualification level was QESig:
I did sign the first document with a .pfx file, but i also tried my eID card with the DSS signer with these settings:
And this too brought up the exact same warnings and qualification level as the first image. Im trying to figure out what im doing wrong.
The eParaksts version was Xades-Baseline-LT, which adds a timestamp, but i dont think that would be responsible for all of the warnings going away.
Hello @JJeris ,
The warnings are related to the qualification status of the signing-certificate used to create the signature. In the first case, the used signing-certificate is not qualified, thus not suitable for creation of qualified eSignature or eSeals (QESig or QESeal).
While in the second case (with Latvian eID) no warnings are displayed, meaning the certificate is qualified for creation of electronic signatures and the private key resides in a QSCD. Which also results to a QESig qualification status for the signature.
If you expect to have a qualified electronic certificate for signature creation in the first scenario, please contact the Trust Service Provider issued you the certificate, so they can explain you why the certificate was not issued as qualified and whether they may issue a qualified one.
Besides, both signatures have been created correctly, cryptographically valid and conformant to the XAdES-B-* profile, as indicated by the TOTAL-PASSED indication. The difference is caused by the used signing-certificate only.
Best regards, Aleksandr
@bsanchezb Thanks for the reply, but i dont think i made my point clear.
I used my eID card (that got no warnings when using the eParaksts application) when signing a document with the DSS standalone application and got this result:
Essentially the same as with my .pfx, that also had the warnings.
The warnings are related to the qualification status of the signing-certificate used to create the signature. In the first case, the used signing-certificate is not qualified, thus not suitable for creation of qualified eSignature or eSeals (QESig or QESeal).
Would this mean that the DSS is not using my eID certificate correctly?
Also, by TOTAL_PASSED, would it mean that this signature is essentially okey for use? For example, if i were to sign a ePhyto xml document for the TRACES NT system, would a total_passed be the bare minimum that a xades signature should try to achieve?
I used my eID card (that got no warnings when using the eParaksts application) when signing a document with the DSS standalone application and got this result:
It is merely means that two different certificate have been used, as you get different validation results. Quite often eID smartcards are distributed with two certificates, one of them being qualified and the other one not. If it is the case, please ensure the qualified certificate is selected on signing.
Would this mean that the DSS is not using my eID certificate correctly?
When signing with PKCS#11, the signing key is managed by the middleware distributed with your smartcard. DSS only retrieves the available option(s).
Also, by TOTAL_PASSED, would it mean that this signature is essentially okey for use? For example, if i were to sign a ePhyto xml document for the TRACES NT system, would a total_passed be the bare minimum that a xades signature should try to achieve?
It depends on the entity requirements where you want to provide the signature. Based on the reports you shared, the signature is compliant to the "advance electronic signature" as per Article 26 of eIDAS (Regulation No 910/2014), but not to the "qualified electronic signature" as per Article 32 of eIDAS.
Best regards, Aleksandr
It is merely means that two different certificate have been used, as you get different validation results. Quite often eID smartcards are distributed with two certificates, one of them being qualified and the other one not. If it is the case, please ensure the qualified certificate is selected on signing.
I opened up the "Sertificate" window in the eParakstitājs 3.0 and was shown this:
I think this shows the 2 certificates within my eID card, the first being for authentication and the second for signing.
I always used the first pin in DSS, because if i enterd the second pin i got this error:
The set up looked something like this:
But as i understand from you, youre saying that when i signed with the pfx and the eID card using the dss (or my own custom C# implementation i suppose) is that the pfx as a signing-certificate is not qualified and that in the eID case i was accessing the wrong certificate from the eID card?
If it is the case, please ensure the qualified certificate is selected on signing.
How would i do this using the DSS standalone application? I seem to be only able to sign using my first pin, though after signing with my first pin (authentication certificate, if i understood correctly), i can then enter my second pin and sign the document again, but this yields a signature with the exact same warnings, so im not sure if that worked.
Thanks again for your reply!
Ok, I see. You have two certificates within the keystore of the smartcard eID, one is for authentication and one for a eSignature. You are not able to access the certificate for the eSignature, but only the certificate for authentication. When you sign using certificate for authentication, the signature is not qualified with a returned "Unknown" qualification status, as the certificate used to create the signature is not suitable for signing.
Could you please share the stacktrace of the error you receive in DSS when selecting the second certificate, which is for eSignature?
Also, if the eID issuer delivers a software to be installed on PC, you may also try to sign using the MSCAPI signature token API, instead of relying on PKCS#11 library.
Ill send it later, the stack trace, but yeah, i wrote my code to access the second certificate and it worked, no warnings, no errors.
Ill try to mscapi too.