SIVA-606 Update documentation links, fix typos and remove References …

…chapter

docs/index.md

@@ -21,11 +21,11 @@ Main purpose of this documentation is to give overview what SiVa is, how it is b
 Below list will give You an overview of what each section of the
 SiVa architecture document will cover:
 
-* [**Definitions**](siva3/definitions) - defines and explines most common concepts used in SiVa documentation
-* [**Overview**](siva3/overview) - gives overview what SiVa is and
+* [**Definitions**](siva3/definitions) - defines and explains most common concepts used in SiVa documentation
+* [**Background**](siva3/background) - gives overview what SiVa is and
   it's main features.
 * [**Structure and activities**](siva3/structure_and_activities) - gives overview of
-  main SiVa subsystems and and and base validation Java libraries
+  main SiVa subsystems and base validation Java libraries
   used for different validation services
 * [**Interfaces**](siva3/interfaces) - Description of SiVa
    SOAP and JSON API request and response

docs/siva3/appendix/validation_policy.md

@@ -31,7 +31,7 @@ The following validation policy versions are marked as obsolete in SiVa 2.0 serv
     * Validation rules defined by base libraries used in SiVa that implement the supported digital signature formats, i.e. the validation constraints that are imposed by the source code implementation or configuration of the base libraries (described in [Base libraries' constraints](#common_libraries) section).
 
 !!! note
-	When no specific validation rule is set in the present document, the requirements and rules from the abovementioned implicit sources for validation requirements shall apply in their entirety. When specific requirements and rules are set in the present validation policy document, they shall prevail over the corresponding requirements set in the implicit resources.
+	When no specific validation rule is set in the present document, the requirements and rules from the aforementioned implicit sources for validation requirements shall apply in their entirety. When specific requirements and rules are set in the present validation policy document, they shall prevail over the corresponding requirements set in the implicit resources.
 
 
 ## SiVA Signature Validation Policy - Version 3 (POLv3)
@@ -91,7 +91,7 @@ http://open-eid.github.io/SiVa/siva3/appendix/validation_policy/#POLv4
 ### General constraints
 
 1. The validation result returned by SiVa determines whether a signature is technically valid and depending of a container type also conforms to a set of validation constraints that are specific to Estonian legislation and local practices of digital signing. **The policy may not be suitable for signatures created in other territories.**
-2.  The validation result returned by SiVa comprises validation results of all the signatures in a single signature container (in case of detached signatures) or all signatures in a signed document (in case of enveloped or enveloping signatures). I.e. in case of multiple detached/enveloped/enveloping signatures, overall validation result correspoinding to the collection of signatures is not determined.
+2. The validation result returned by SiVa comprises validation results of all the signatures in a single signature container (in case of detached signatures) or all signatures in a signed document (in case of enveloped or enveloping signatures). I.e. in case of multiple detached/enveloped/enveloping signatures, overall validation result corresponding to the collection of signatures is not determined.
 
 ### Signature format constraints
 <a name="common_format"></a>
@@ -144,9 +144,9 @@ Legend:
 ### Cryptographic algorithm constraints
 1. Hash algorithm constraints:
 	* In case of BDOC format: when validating a signature where SHA-1 function has been used then a validation warning about weak digest method is returned.
-2. Asymmetric cryptographic algorithm contraints:
+2. Asymmetric cryptographic algorithm constraints:
 	* RSA and ECC cryptographic algorithms are supported
-	* In case of PAdES/XAdES(also BDOC)/CAdES formats, the RSA key lenght must be at least 1024 bits and ECC key length at least 192 bits.
+	* In case of PAdES/XAdES(also BDOC)/CAdES formats, the RSA key length must be at least 1024 bits and ECC key length at least 192 bits.
 
 ### Trust anchor constraints
 1. The signature must contain the certificate of the trust anchor and all certificates necessary for the signature validator to build a certification path up to the trust anchor. This applies to the signer’s certificate and the certificates of trust service providers that have issued the time-stamp token and revocation data that are incorporated in the signature.
@@ -167,7 +167,7 @@ Legend:
 ### Signer certificate's revocation freshness constraints
 1. In case of BDOC and DIGIDOC-XML 1.0...1.3 BASELINE_LT_TM signatures with time-mark: revocation data is always considered fresh as the revocation data is issued at the trusted signing time.
 2. In case of XAdES/CAdES/PAdES BASELINE_LT and BASELINE_LTA signatures with signature time-stamp: revocation data freshness is checked according to the following rules:
-	* In case of OCSP responce if difference between signature time-stamp's production time (genTime field) and signer certificate OCSP confirmation’s production time (producedAt field) is more than 24 hours then the signature is considered invalid. If the difference is more than 15 minutes  and less then 24h then a validation warning is returned.
+	* In case of OCSP response if difference between signature time-stamp's production time (genTime field) and signer certificate OCSP confirmation’s production time (producedAt field) is more than 24 hours then the signature is considered invalid. If the difference is more than 15 minutes and less than 24h then a validation warning is returned.
 	* In case of Certificate Revocation List the signature time-stamp's production time (genTime field) must be within validity range of the CRL (between thisUpdate and nextUpdate)
 
 
@@ -178,7 +178,7 @@ Legend:
 	* In case of basic signature (BASELINE_B) - the trusted signing time value cannot be determined as there is no Proof-of-Existence of the signature.
 
 
-### BDOC container spceific requirements
+### BDOC container specific requirements
 The BDOC container must conform with [BDOC 2.1](https://www.id.ee/wp-content/uploads/2021/06/bdoc-spec212-eng.pdf) standard.
 1.	File extension
 	* ".bdoc" file extension is supported during signature validation.
@@ -189,12 +189,12 @@ The BDOC container must conform with [BDOC 2.1](https://www.id.ee/wp-content/upl
 6. Only relative file paths are supported, for example "META-INF/signatures.xml" and "document.txt" instead of "/META-INF/signatures.xml" and "/document.txt".
 7. "META-INF/manifest.xml" file shall be conformant to OASIS Open Document Format version [1.0](http://docs.oasis-open.org/office/v1.0/OpenDocument-v1.0-os.pdf) or [1.2](http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part3.pdf).
 
-### ASICE container spceific requirements
+### ASICE container specific requirements
 The ASICE container must conform with [ETSI EN 319 162-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.01.01_60/en_31916201v010101p.pdf) standard.
 1. Warning is returned when signatures in the container do not sign all of the data files.
 2. Manifest file must be present.
 
-### ASICS container spceific requirements
+### ASICS container specific requirements
 The service supports both signature and Time Stamp Token (TST) based ASIC-S containers. Evidence record based containers are not supported. The ASIC-S container must conform with [ETSI EN 319 162-1](http://www.etsi.org/deliver/etsi_en/319100_319199/31916201/01.01.01_60/en_31916201v010101p.pdf) and [ETSI EN 319 162-2](http://www.etsi.org/deliver/etsi_en/319100_319199/31916202/01.01.01_60/en_31916202v010101p.pdf) standards.
 
 1. Manifest file can not be present in case of signature based ASIC-S containers.

docs/siva3/overview.md → docs/siva3/background.md

@@ -1,40 +1,40 @@
-<!--# SiVa overview-->
-
-## What is SiVa?
-
-SiVa (Signature Validation) web service provides JSON and SOAP based API web interface to validate digital signatures.
-Please take a look in [Validation Policy](../appendix/validation_policy/) section for supported formats and applied constraints.
-
-SiVa uses following Java libraries and command line utilities:
-
-* DigiDoc4J Java library to validate BDOC (supported signature
-  types are `TimeStamp` and `TimeMark`) and DDOC containers.
-* EU DSS (Digital Signature Service) library is used to validate all other types of digital signatures that are not covered above.
-
-## Validation libraries
-
-### DigiDoc4j EU DSS fork
-
-[DigiDoc4J EU DSS fork](https://github.com/open-eid/sd-dss) is used as the main validation library. The fork includes [Estonian specific changes](https://github.com/open-eid/sd-dss/wiki/BDoc-specific-modifications) and may not be suitable for all signatures.
-
-**SiVa will use the following functionality of EU DSS library:**
-
-* XAdES/CAdES/PAdES Validation Functionality
-* ASIC-E and ASIC-S container validation
-* TSL loading functionality
-
-### DigiDoc4J
-
-DigiDoc4J is used to validate both `TimeMark` and `TimeStamp` based BDOC and DDOC containers. For more information on DigiDoc4J visit [Github](https://github.com/open-eid/digidoc4j)
-
-SiVa will use the following functionality of DigiDoc4J:
-
-* BDOC validation functionality
-* DDOC validation functionality
-
-## Main features of SiVa validation service:
-
-- SOAP and REST/JSON API to validate signatures.
-- SOAP and REST/JSON API to retrieve data files from DDOC containers.
-- SOAP API is compadible with X-Road v6.
+<!--# SiVa overview-->
+
+## What is SiVa?
+
+SiVa (Signature Validation) web service provides JSON and SOAP based API web interface to validate digital signatures.
+Please take a look in [Validation Policy](../appendix/validation_policy/) section for supported formats and applied constraints.
+
+SiVa uses following Java libraries and command line utilities:
+
+* DigiDoc4J Java library to validate BDOC (supported signature
+  types are `TimeStamp` and `TimeMark`) and DDOC containers.
+* EU DSS (Digital Signature Service) library is used to validate all other types of digital signatures that are not covered above.
+
+## Validation libraries
+
+### DigiDoc4j EU DSS fork
+
+[DigiDoc4J EU DSS fork](https://github.com/open-eid/sd-dss) is used as the main validation library. The fork includes [Estonian specific changes](https://github.com/open-eid/sd-dss/wiki/BDoc-specific-modifications) and may not be suitable for all signatures.
+
+**SiVa will use the following functionality of EU DSS library:**
+
+* XAdES/CAdES/PAdES Validation Functionality
+* ASIC-E and ASIC-S container validation
+* TSL loading functionality
+
+### DigiDoc4J
+
+DigiDoc4J is used to validate both `TimeMark` and `TimeStamp` based BDOC and DDOC containers. For more information on DigiDoc4J visit [Github](https://github.com/open-eid/digidoc4j)
+
+SiVa will use the following functionality of DigiDoc4J:
+
+* BDOC validation functionality
+* DDOC validation functionality
+
+## Main features of SiVa validation service:
+
+- SOAP and REST/JSON API to validate signatures.
+- SOAP and REST/JSON API to retrieve data files from DDOC containers.
+- SOAP API is compatible with X-Road v6.
 - Signing of validation report.

docs/siva3/deployment.md

@@ -7,14 +7,14 @@ The deployment view of the architecture describes the various physical nodes in
 In the following section, a description of each network node element is described in detail.
 
 | Node | Setup description |
-| ------ | ----------- |
-| **Load balancer server** | Load balancer distributes traffic between SiVa server nodes when there is more than one Siva server instance running. SiVa does not set any specific requirements for load balancer. As an example, the nginx reverse proxy is used.|
-| **Siva server** | The **SiVa webapp** service is set up to run on SiVa server.<br/>SiVa web appliction is executable Spring Boot JAR file. This means all the dependencies and servlet containers are packaged inside single JAR file. The JAR file can be placed anywhere in server and the JAR must be marked executable if its not already.<br/><br/>There also should be separate user created to run executalbe JAR as Linux service.<br/><br/>Read more about running [Spring Boot applications as Linux system service](https://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html#deployment-service)|
-| **X-road security server** | A standard X-road security server setup. The SiVa validation service wsdl has to be registered to provide service to other organisations using XRoad infrastructure. Setting up XRoad Security server is out of scope for SiVa documentaton (see the [official installation instructions](https://www.x-tee.ee/docs/live/xroad/ig-ss_x-road_v6_security_server_installation_guide.html)).|
-| **Demo server** | Demo server hosts the **Demo webapp** provided within SiVa project as a reference client implementation. <ul><li>Demo webapp - single Java web application that provides a simple form to upload and validate a signed file in Siva webapp. Demo webapp serves as a tool for evaluating and testing the validation service. </li></ul>|
+|------|-------------|
+| **Load balancer server** | Load balancer distributes traffic between SiVa server nodes when there is more than one Siva server instance running. SiVa does not set any specific requirements for load balancer. As an example, the nginx reverse proxy is used.                                                                                                                                                                                                                                                                                                                                                                           |
+| **Siva server** | The **SiVa webapp** service is set up to run on SiVa server.<br/>SiVa web application is executable Spring Boot JAR file. This means all the dependencies and servlet containers are packaged inside single JAR file. The JAR file can be placed anywhere in server and the JAR must be marked executable if its not already.<br/><br/>There also should be separate user created to run executable JAR as Linux service.<br/><br/>Read more about running [Spring Boot applications as Linux system service](https://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html#deployment-service) |
+| **X-road security server** | A standard X-road security server setup. The SiVa validation service wsdl has to be registered to provide service to other organisations using XRoad infrastructure. Setting up XRoad Security server is out of scope for SiVa documentation (see the [official installation instructions](https://www.x-tee.ee/docs/live/xroad/ig-ss_x-road_v6_security_server_installation_guide.html)).                                                                                                                                                                                                                     |
+| **Demo server** | Demo server hosts the **Demo webapp** provided within SiVa project as a reference client implementation. <ul><li>Demo webapp - single Java web application that provides a simple form to upload and validate a signed file in Siva webapp. Demo webapp serves as a tool for evaluating and testing the validation service. </li></ul>                                                                                                                                                                                                                                                                         |
 
 ### Horizontal scaling
 
-Neither the **Siva webapp**, nor **Demo wbapp** persist their state in sessions between requests. Therefore it is possible to install multiple instances of these services behind respective load balancers.
+Neither the **Siva webapp**, nor **Demo webapp** persist their state in sessions between requests. Therefore, it is possible to install multiple instances of these services behind respective load balancers.
 
 

docs/siva3/deployment_guide.md

@@ -93,11 +93,11 @@ For that we first need to create service file:
 vim siva-webapp.service
 ```
 
-Inside it we need to paste below text. You need to change few things in service setup file.
+Inside it, we need to paste below text. You need to change few things in service setup file.
 
 * First you **must not** run service as `root`. So it's strongly recommended to change line `User=root`
 * Second You can change Java JVM options by modifying the `JAVA_OPTS` inside the `siva-webapp.service` file.
-* Also You can change the SiVa application configuration options by modifying `RUN_ARGS` section in file
+* Also, You can change the SiVa application configuration options by modifying `RUN_ARGS` section in file
 
 ```ini
 [Unit]
@@ -197,7 +197,7 @@ cp siva-parent/siva-webapp/target/siva-webapp-X.X.X.war apache-tomcat-8.5.24/web
 ./apache-tomcat-7.0.77/bin/catalina.sh run
 ```
 
-> **IMPORTANT** siva-webapp on startup creates `etc` directory where it copies the TSL validaiton certificates
+> **IMPORTANT** siva-webapp on startup creates `etc` directory where it copies the TSL validation certificates
 > `siva-keystore.jks`. Default location for this directory is application root or `$CATALINA_HOME`. To change
 > this default behavior you should set environment variable `DSS_DATA_FOLDER`. 
 
@@ -206,7 +206,7 @@ cp siva-parent/siva-webapp/target/siva-webapp-X.X.X.war apache-tomcat-8.5.24/web
 
 ### How-to set WAR deployed SiVa `application.properties`
 
-SiVa override properties can be set using `application.properties` file. The file can locate anywhare in the host system.
+SiVa override properties can be set using `application.properties` file. The file can locate anywhere in the host system.
 To make properties file accessible for SiVa you need to create or edit `setenv.sh` placed inside `bin` directory.
 
 Contents of the `setenv.sh` file should look like:
@@ -219,7 +219,7 @@ export CATALINA_OPTS="-Dspring.config.location=file:/path/to/application.propert
 ### Smoke testing your deployed system
 
 **Step 1**. Install HTTPIE
-`httpie` is more user friendly version of `curl` and we will use to verify that SiVa was installed
+`httpie` is more user-friendly version of `curl` and we will use to verify that SiVa was installed
 and started correctly on our server.
 
 If you have Python and its package manager `pip` installed. Then You can issue below command: