Table of Contents |
---|
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:
- For signing operations it needs to contact the RAW signature services (PKCS#1 format) at https://fra.firmacerta.it
- 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
- For signing verifications it must be able to contact the CA that issued the signer's certificate in order to prove its validity
- 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?
Ports and Protocols Usages (firewall rules)
Below the list of port and protocol used by SWS:
Operation | Description | Frequency | Protocol | Ports | TCP/UDP | Address | SWS Environment |
---|---|---|---|---|---|---|---|
Signature | Sends a request to the Namirial server for signing the hash | Every call | HTTPS | 443 | TCP | fra.firmacerta.it | PROD |
Timestamp | Sends a request to the Namirial server for applying the timestamp to the hash | Every call | HTTP | 80 | TCP | timestamp.firmacerta.it | PROD |
Timestamp | Sends a request to the Namirial server for applying the timestamp to the hash | Every call | HTTPS | 443 | TCP | timestamp.firmacerta.it | PROD |
Verification OCSP | Sends a request to the OCSP link for checking the certificate | Every call (whenever possible) | OCSP | 80 | TCP | It depends on the the CA that issued the certificate for the signature. For Namirial, the link is: "ocsp.firmacerta.it" | PROD |
Signature | This operation sends a request to the Namirial server for signing the hash | Every call | HTTPS | 443 | TCP | fra.test.firmacerta.it | TEST |
Timestamp | Sends a request to the Namirial server for applying the timestamp to the hash | Every call | HTTP | 80 | TCP | timestamp.test.firmacerta.it | TEST |
Timestamp | Sends a request to Namirial server for applying the timestamp to the hash | Every call | HTTPS | 443 | TCP | timestamp.test.firmacerta.it | TEST |
Verification OCSP | For validate the certificate send request to OCSP for check the certificate | Every call (whenever possible) | OCSP | 80 | TCP | It depends on the CA issued the certificate used for the signature. For Namirial it's: "ocsp.firmacerta.it" | PROD |
Verification CRL | For validate the signature certificate check the serial number into CRL | HTTP/LDAP | 80, 389 | TCP | It depends on the CA issued the certificate used for the signature. For Namirial it's: "crl.firmacerta.it" | PROD | |
Verification | At startup SWS download all European Trusted Root from European supervisory agenciences | HTTPS | 443 | TCP | ec.europa.eu (the full link is: https://ec.europa.eu/information_society/policy/esignature/trusted-list/tl-mp.xml) | TEST, PROD | |
Updates and Monitoring | Used for receiving automatic updates and receive | Always | JABBER, HTTP, HTTPS | 5222, 443, 80 | TCP | scm.firmacerta.it | TEST, PROD |
NTP sync | Used for synchronization of date and time | Always | NTP | 123 | UDP | TEST, PROD |
Outbound communication to the Namirial FRA service are done through HTTPS, with a mutual authentication, and take place via a unique TLS certificate that Namirial distributes to every applicant, in order to identify the virtual appliance SWS caller.
Here is a table with the incoming protocols:
Service | Description | Protocol | Port | TCP/UDP | SWS Environment |
---|---|---|---|---|---|
Web Services | Web services interfacing | HTTP | 8080 | TCP | TEST, PROD |
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:
Library/framework name | license link |
---|---|
DSS (Digital Signature Service) | https://www.gnu.org/licenses/lgpl-3.0.en.html |
bouncycastle | https://www.bouncycastle.org/licence.html |
apache-commons | https://www.apache.org/licenses/LICENSE-2.0 |
CXF | https://www.apache.org/licenses/LICENSE-2.0 |
pdfbox | https://www.apache.org/licenses/LICENSE-2.0 |
xerces | https://www.apache.org/licenses/LICENSE-2.0 |
xalan | https://www.apache.org/licenses/LICENSE-2.0 |
xml-apis | https://www.apache.org/licenses/LICENSE-2.0 |
xmlschema-core | https://www.apache.org/licenses/LICENSE-2.0 |
xmlsec | https://www.apache.org/licenses/LICENSE-2.0 |
...