Create Qualified Electronic Signatures

This tutorial explains how to create Qualified Electronic Signatures and Seals (QES) with an SKA key stored in a Primus HSM. Smart Key Attributes (SKA) act as the Signature Activation Module (SAM), authorizing the use of the SKA key for signing.

The only difference between a QES and a normal SKA signature is that this executes in SAM mode. In SAM mode, the HSM partition enforces that the approver certificates in the SKA policy have a valid signature from the configured CAs. This ensures that the humans using the signing keys are identified (as required by eIDAS). For more details, please see the How It Works article.

Prerequisites

This tutorial assumes that:

1. You have configured your HSM and partition for eIDAS and SAM.
2. You have created one or more approvers and have created an SKA key.

Make a Signing Request

Making a signing request for a QES is the same as making a signing request for a normal SKA key:

1. A user requests to sign with an SKA key.
2. Human approvers review and approve the request.
3. Wait for all approvals to be given.
4. Send the complete request to the HSM, getting the signature made by the SKA key.

From the view of the HSM, only the single, synchronous API call in step 4 matters. This call needs to contain the complete signing request, as well as sufficient valid approvals. (Approvals are signatures made by the approver key.) How you implement steps 1, 2, 3 to assemble this request payload is up to you.

For a QES of a single user, steps 1., 2., 3. usually happen directly on the user's device in your custom application. For organization seals with an m-of-n SKA policy, an asynchronous wait time is common, as you need to collect approvals from multiple approvers.

For doing these steps with the TSB's REST API, see this tutorial. If you are using the JCE API or the PKCS#11 API, please see the linked API documentation for how to make the SKA signing request in step 4.