Introduction

SWS (Sign Web Services) allow to sign and verify different document type, you can use this application only with devices enrolled by Namirial. There are multiple devices supported:

• Automatic signature
• Remote signature
• Disposable 
• Lean Disposable
• eSeal (electronic seal)

And there are multiple signatures supported:

• CAdES
• PAdES
• XAdES
• JAdES
• RAW signature (PKCS#1)

Additionally, it is possible to set the different levels of signature such as B, T, LT, LTV etc... These details are described in the documentation about integration with SWS.

The timestamps applied are in accordance with RFC 3161 and RFC 5544 standards.

During the verification of the signatures, SWS can verify certificates issued by all accredited Certification Authorities in the Countries of the European Community. Also, it is possible to verify signatures in any of the CAdES, PAdES and XAdES formats. 

You can see a SWS like a blackbox like in this image:

This is the flow during the signing process

While during the verify, this is the flow:

Naturally SWS contact external services to complete the flow of signing and verify. Below will be described the external services used.

How SWS works during signing flow?

When SWS receive the file to sign, calculates the file hash and asks to the FRA component (located in the Namirial CA datacenter) to sign it. FRA represents the system component which manages HSMs and uses the RSA algorithm-type signature.

Assuming SWS is inside the LAN (the same LAN hosting the applications that require the signature services) the documents are exchanged inside a private network. We have the confidentiality of the information contained in the hash that SWS has transmitted to FRA and a low impact on the Internet bandwidth. For each signature sent between SWS and FRA, approximatively 7KB are used, regardless of the document size. In the case of submissions of merged requests, the bandwidth usage decreases thanks to TCP, HTTPS and SOAP lower impacts.

SWS exposes its services via the SOAP and REST protocol.
On the other hand, it operates as a client in the following ways:

1. For signing operations it needs to contact the RAW signature services (PKCS#1 format) at https://fra.firmacerta.it
2. For timestamping operations it must be able to contact the Timestamping Authority (TSA) set in the call. In this case the supported protocols are HTTP and HTTPS. More precisely, Namirial TSA can be reached at http://timestamp.firmacerta.it and at https://timestamp.firmacerta.it
3. For signing verifications it must be able to contact the CA that issued the signer's certificate in order to prove its validity
4. For Updating TLS (TrustedList), it contacts periodically every EC national agency that supervises the Certification Authority (in Italy, this is AgID).

The RAW signature service (PKCS#1) is high reliability provided. The HSM and the FRA element are functional purpose redundants. The VA SWS high reliability can be achieved operating as you usually do for a generic web server: run the VA SWS setup (2 or more) and display the web services via a load balancer. Since SWS does not handle any application session, it is enough to set a load balancer policy with a same-weight Round-Robin type.

How SWS works during verify flow?

Type of distributions

SWS can be used in different mode:

• onPremise
• SaaS

The solution onPremise, the customer will receive the Docker image

While in SaaS solution, the customer will receive the endpoint and SSL certificate for integrate with this solution

Best practice

Namirial reccomends to have 2 instances of SWS active at same time to warranty the high reliability. Every instance is stateless and don't share session with other instance active.

Reccomandations

The SWS appliance must not be publicly displayed on the internet!!!!

Namirial don't assume responsability.

License

Below the list of library/framework used in SWS: