======Signature Archival====== The trust in electronic signature technology depends on the signing of any validation data used in signature by a trusted authority and the strength of the cryptographic algorithms used in signing against the existing attacks. Computational capabilities of computers are determinative in the power of cryptographic attacks. Therefore, a signature which is created today is open attacks when the life of cryptographic algorithms used in it expires. Malevolent people with the ability to perform cryptographic attacks may change the contents of the signed document, make the signer certificate valid or invalid at the date of signature, so can take control completely. Here, the necessity of the archive signature comes to the fore. The archiving of the signature means that the signature is protected by using a more powerful algorithm. Archiving can be done when the CA’s certificate is near to the end of the validity period, the certificates are revoked or if announced that the used algorithms become invalid or is changed. In archival, a timestamp is added to the weak signature to cover all extensions in the signature by using a stronger hashing algorithm than the timestamps on the signature. This timestamp is the archive timestamp. Archiving should be repeated by entering timestamp settings from a new hierarchy by TSP if the validity of the last archive timestamp in the currently signed archive documents is compromised. The test packages in the sub-sections of [[en:imza_dogrulama| Signature Validation]] can be used for testing archival scenarios. The signed files of the signature format according to the needs of the application should be preferred among the test packages. The valid signed files in the selected test package can be archived, while invalid signed files should not be allowed to be archived. Similarly, for multiple-signed files, archiving cannot be performed if there are invalid signatures. However, if one of the parallel signatures is valid, the archiving process can be applied to the valid signature, optionally. The test package in the [[en:e-yazisma_paketi| e-Correspondence Package]] section can be used for testing archival scenarios. Since the Electronic Seal component in the ECP is the type of archive signature, the other electronic signatures whose type is [[CAdES P4 X-LONG|P4 CAdES X-LONG]] will also be secured by archive time stamp. Therefore, archiving scenarios for ECP cover the cases only specific to archive signature. Accordingly, only **P4_A90** and **P4_A94** packages which are within [[e-yazisma_paketi#Procedures | ECP procedure table]] need to be archived. The relevant infrastructure for archiving on the application side should be provided. Trusted algorithms should be kept in the whitelist. A signed document with a timestamp, whose algorithm is not in the whitelist, must be re-archived. At the same time, the root certificates that are no longer considered trusted should be kept on the blacklist. Signed documents created with Qualified Certificates or Electronic Seal Certificates that are issued from roots in this list should also be archived. In the following section, scenarios that need archiving are determined. More comprehensive information is available in the {{https://yazilim.kamusm.gov.tr/eit-wiki/data/media/documents/arsivleme_rehberi.pdf | Archiving Procedure}}. ===== Archiving Scenarios ===== **1. Scenarios about certificate** * The revocation and expiration of OCSP certificate * The revocation and expiration of signature time-stamp certificate * The revocation and expiration of "signature and reference timestamp" and "reference time-stamp" certificate (if exists in the signature) * The expiration of archive timestamp certificate * The revocation and expiration of the subordinate certificate * The expiration of the root certificate **2. Scenarios about trusted root store** * Blacklisting of the root certificate **3. Scenarios about invalid algorithms** * Invalid signature timestamp algorithm * Invalid “signature and reference timestamp” or “reference timestamp” algorithm (if exists) * Invalid archive timestamp algorithm * Invalid signature algorithm This section is created to test the compatibility of archival practices with standards and it includes the signature formats [[CAdES]], [[XAdES]] and [[PAdES]] defined by ETSI within the scope of the test of signature archival applications. =====Signed Files Must Be Archived===== Signed documents that must be archived according to the signature type created by the application are given in the tables below. When valid signed documents can be archived, invalid signed documents should not be allowed to be archived. Similarly, for multiple-signed documents, archiving cannot be performed if there is an invalid signature. However, if one of the parallel signatures is valid, the archiving process can be applied to the valid signature, optionally. Archiving decision of the signed documents which has selective and optional validation result in the [[en:imza_dogrulama | Signature Validation]] sub-sections must be same as the validation policy. All invalid signed documents except listed above and valid signed documents should not be archived. **Signed Documents to be Archived** ^**ES X-LONG**| ESXL_1 | ESXL_6 | ESXL_8 | ESXL_16_2 | |:::| ESXL_17_2 | ESXL_24_2 | ESXL_29_2 | ESXL_32_2 | |:::| ESXL_37_2 | ESXL_45 | ESXL_47 | ESXL_102((The OCSP certificate is expired after signing time)) | |:::| ESXL_103((The signature TS certificate is expired after signing time)) | ESXL1_104((The SigAndRefTS certificate is expired after signing time)) | ESXL_107((The intermediate certificate is expired after signing time)) | ESXL_108((The root certificate is expired after signing time)) | |||||| |||||| |||||| ^**ES X-LONG Type 1**| ESXL1_1 | ESXL1_6 | ESXL1_8 | ESXL1_16_2 | |:::| ESXL1_17_2 | ESXL1_24_2 | ESXL1_29_2 | ESXL1_32_2 | |:::| ESXL1_37_2 | ESXL1_45 | ESXL1_47 | ESXL1_1021) | |:::| ESXL1_1032) | ESXL1_1074) | ESXL1_1085) | Applications that sign directly in the archive type need to archive ES-X LONG signed documents. In addition, ** ESA_106 ** and ** ESA_109 ** signed files must be archived. ** Signed Documents to be Archived for P4 ** ^**P4 ES-X LONG**| P4_1 | P4_6 | P4_15 | P4_25 | |:::| P4_31 | P4_42 | P4_44 | P4_871) | |:::| P4_882) | P4_893) | P4_914) | P4_925) | Applications that sign directly in the archive type need to archive P4 ES-X LONG signed documents. In addition, ** P4_A90 ** and ** P4_A94 ** signed documents must also be archived. =====Archive Packages===== Archive packages for selected signature types are given in the table below. |[[https://yazilim.kamusm.gov.tr/?q=tr/system/files/private/eyp2.0_test_paketleri.rar|e-Correspondence Package]]| |[[https://yazilim.kamusm.gov.tr/?q=tr/system/files/private/cades_ayrik_arsiv_paketi.rar|CAdES Detached]]| |[[https://yazilim.kamusm.gov.tr/?q=tr/system/files/private/cades_butunlesik_arsiv_paketi.rar|CAdES Attached]]| |[[https://yazilim.kamusm.gov.tr/?q=tr/system/files/private/p4_cades_ayrik_arsiv_paketi.rar|P4 CAdES Detached]]| |[[https://yazilim.kamusm.gov.tr/?q=tr/system/files/private/p4_cades_butunlesik_arsiv_paketi.rar|P4 CAdES Attached]]| |[[https://yazilim.kamusm.gov.tr/?q=tr/system/files/private/xades_enveloping_arsiv_paketi.rar|XAdES Enveloping]]| |[[https://yazilim.kamusm.gov.tr/?q=tr/system/files/private/xades_detached_arsiv_paketi.rar|XAdES Detached]]| |[[https://yazilim.kamusm.gov.tr/?q=tr/system/files/private/p4_xades_enveloping_arsiv_paketi.rar|P4 XAdES Enveloping]]| |[[https://yazilim.kamusm.gov.tr/?q=tr/system/files/private/p4_xades_detached_arsiv_paketi.rar|P4 XAdES Detached]]| |[[https://yazilim.kamusm.gov.tr/?q=tr/system/files/private/pades_arsiv_paketi.rar|PAdES]]| |[[https://yazilim.kamusm.gov.tr/?q=tr/system/files/private/p4_pades_arsiv_paketi.rar|P4 PAdES]]|