Annex 2: EDSSI digital signature architecture

This document describes a proposed architecture for digital signatures in EDSSI (L2). The proposal is based on the digital signature service architecture in use in Swedish public sector administration for several years and described by the Swedish agency for digital administration (digg.se) in https://github.com/swedenconnect/technical-framework

Architecture overview

The architecture involves the following components:

• An Identity Provider - in EDSSI L2 this will be fulfilled by the MyAcademicID identity and access management platform bridging both eIDAS and eduGAIN
• An application that relies on document signatures - eg. Online Learning Agreement platform
• A document signing API that is responsible for creating a DSS signature request
• Signing service which creates and applies a signature, this service will be built on the basis of the eduSign service operated for the academic community in Sweden
• Certification Authority (CA) that issues certificates for the signature, this will be fulfilled by the Certification Authority operated by AUTh.

In this architecture each signature is done using a separate key and certificate. Each signature relies on the CA to create a signature-specific certificate that embeds information about the identity of the user that authenticated the signature (communicated by the Identity Provider).

The application uses a custom REST API to submit a document (PDF or XML) to the document signing API where the signature is prepared according to the standards applicable to each document format - in essence the document signing API “knows” about PDF and XML signatures but does not “know” about the cryptography of digital signatures.

The document signing (aka “helper” API) uses OASIS DSS to request the actual signature from a sign service.

The sign service creates an ephemeral key (in an HSM or in memory) which is used to create a CSR which includes the user information from the IdP. The CSR is sent to the CA which issues the certificate which the sign service then uses to complete the signature operation.

This architecture has some important security and usability properties:

• Signatures are done “server-side” which guarantees that key generation is done in trusted hardware. This essentially eliminates issues related to bad user-adjacent hardware eg the ROCA attack.
• No certificate is ever re-used for multiple signatures which essentially eliminates the need for certificate revocation.
• Each certificate need only be valid for a very short period of time - typically in the order of seconds which additionally reduces the attack vector.
• Signatures can be integrated into normal web user flows which is a requirement for modern usability requirements.
• The sign service is an authenticated signing oracle - ie it signs everything it receives from the document signing API which therefore by necessity becomes part of the trust boundary.
• The sign service does not have access to original document content which can be important in certain situations.

Example Flow

1. User requests a document to be signed (eg a contract)
2. The application authenticates the user at the IdP
3. The application forms a PDF and submits it for signature via the REST API - the request includes user information from the IdP
4. The REST API computes the HASH of the document and prepares the signature
5. The REST API returns a signature request to the application which submits a request to the DSS sign service.
6. The sign service authenticates the user to confirm signature and optionally verify additional policy (eg multi-factor authentication)
7. The sign service generates a signature key and creates a CSR from the signature key and the user information.
8. The sign service submits a CMP request to the CA
9. The CA issues a signature certificate and returns it to the sign service
10. The sign service process the signature request and returns the signed HASH to the REST service which completes the process by embedding the signature in the format-appropriate way.