Skip to end of banner
Go to start of banner

SWS Description

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 5 Next »

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?



Ports and Protocols Usages (firewall rules)

Below the list of port and protocol used by SWS:

OperationDescriptionFrequencyProtocolPortsTCP/UDPAddressSWS Environment
SignatureSends a request to the Namirial server for signing the hashEvery callHTTPS443TCPfra.firmacerta.itPROD
TimestampSends a request to the Namirial server for applying the timestamp to the hashEvery callHTTP80TCPtimestamp.firmacerta.itPROD
TimestampSends a request to the Namirial server for applying the timestamp to the hashEvery callHTTPS443TCP timestamp.firmacerta.itPROD
Verification OCSPSends a request to the OCSP link for checking  the certificate Every call (whenever possible)OCSP80TCPIt depends on the the CA that issued the certificate for the signature. For Namirial, the link is: "ocsp.firmacerta.it"PROD
SignatureThis operation sends a request to the Namirial server for signing the hashEvery callHTTPS443TCPfra.test.firmacerta.itTEST
TimestampSends a request to the Namirial server for applying the timestamp to the hashEvery callHTTP80TCPtimestamp.test.firmacerta.itTEST
TimestampSends a request to Namirial server for applying the timestamp to the hashEvery callHTTPS443TCP timestamp.test.firmacerta.itTEST
Verification OCSPFor validate the certificate send request to OCSP for check the certificateEvery call (whenever possible)OCSP80TCPIt depends on the CA issued the certificate used for the signature. For Namirial it's: "ocsp.firmacerta.it"PROD
Verification CRLFor validate the signature certificate check the serial number into CRL
HTTP/LDAP80, 389TCPIt depends on the CA issued the certificate used for the signature. For Namirial it's: "crl.firmacerta.it"PROD
VerificationAt startup SWS download all European Trusted Root from European supervisory agenciences
HTTPS443TCP

ec.europa.eu (the full link is: https://ec.europa.eu/information_society/policy/esignature/trusted-list/tl-mp.xml)

TEST, PROD
Updates and MonitoringUsed for receiving automatic updates and receive AlwaysJABBER, HTTP, HTTPS5222, 443, 80TCPscm.firmacerta.itTEST, PROD
NTP syncUsed for synchronization of date and timeAlwaysNTP123UDP
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:

ServiceDescriptionProtocolPortTCP/UDPSWS Environment
Web ServicesWeb services interfacingHTTP8080TCPTEST, 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.

  • No labels