Long-Term Archiving and Notary Service
Long-Term Archiving and Notary Service is a term from cryptology .
From 2003 to 2011, the working group of the same name within the Internet Engineering Task Force ( IETF ) worked on specifications relating to the ability to prove the integrity of electronic documents, specially signed, in the context of long-term archiving . The first goal was to convert the concepts obtained in the ArchiSig project into a standard. After a further phase of the requirements analysis for an archive system that provides the corresponding services, further exchange formats and protocols were specified.
Requirements for a long-term archive service
The primary goal of a Long-Term Archive Service is to secure the evidence of a claim recorded in an electronic document at any point in the future. A long-term archive service must therefore electronically support use cases such as wills, land tenure deeds, medical data, criminal case files, personal documents or contracts. A long-term archive service must be able to be used by different users such as organizations, residents, judges or notaries in the same way:
- A company saves contracts on a service provider's system
- A hospital stores medical data in an internal system.
- A private individual wants to prove that they owned a certain document at a certain point in time, e.g. B. for the purpose of proving an authorship or an additional contractual clause
- A law enforcement officer wants to save his criminal case files in such a way that their integrity can be demonstrated years later
For each of the examples mentioned there is the complementary example of a receiver, e.g. B. A company receives the contract in the event of a dispute or a law enforcement officer puts together material for an indictment.
Due to the long-term aspect, a long-term archive service must be able to deal with the fact that the technologies used age over time. That applies to
- the storage media used, including the readers
- Document formats such as Tagged Image File Format (TIFF) and now also PDF / A , which are current today, but will probably be replaced by others in 20 years' time
- for cryptographic algorithms that were used to sign a document
In the event of aging, a long-term archive service must therefore be able to
- Migrate data from the previous media to another without loss or at least export it including the associated index data
- correctly carry out the transformation of a document into another format including the handling of signatures (see also the web link for the TransiDoc project)
- to re-sign signed documents with a time stamp (so far only legally required in Germany)
It must be possible to prove that these services have been carried out properly even years later (→ Notary Service).
Published specifications
- LTANS - Long-Term Archive Service Requirements
- After the requirements ( RFC 4810 ) were published in 2006, the LTANS Working Group tackled the issue of verifying the integrity and authenticity of signed documents.
- LTANS-ERS
- The result was the publication of RFC 4998 with the description of the Evidence Record Syntax in 2007, which defines the data format for the complete evidence of a signed document including its re-signing.
- LTANS-ERS-SCVP
- The subsequently published RFC 5276 specifies the interface to the service from which an evidence record for an object is requested. The object was previously registered in this system known as the SCVP service. All certificates ( certificate path ) including the revocation lists that were received from the certification service providers during the first verification are saved by the SCVP service for future inquiries.
- LTANS-XMLERS
- Following the specification of RFC 4998 , an equivalent standard RFC 6283 in XML format was also adopted in 2011 . Both ( RFC 4998 and RFC 6283 ) are equivalent in their function, ensure complete evidence of a signed document including its re-signing and differ mainly in the formats they use (RFC4998 uses ANS.1, RFC 6283 uses XML).
Specifications in progress
The LTANS Working Group is working on the following additional RFCs:
- LTANS-DSSC
- The specification Data Structure for the Security Suitability of Cryptographic Algorithms describes the data structure of information about the strength of a cryptographic algorithm in the past, the present and the future, as it should be made available by an organization such as the Federal Network Agency . As of today, the algorithm strengths are published annually in a PDF document by the Federal Network Agency in the context of the Signature Act and entered manually in SCVP systems. With the DSSC-formatted file, SCVP systems should in future be able to process relevant information automatically.
- LTANS-LTAP
- The long-term archive protocol serves as a uniform interface for an application to exchange data with a long-term archive service, e.g. B. to hand them over for safekeeping, to search for them or to retrieve them for advertisement.
Implementations
So far, mainly the Evidence Record Syntax including the corresponding data storage in an SQL database has been implemented by German manufacturers of signature application components (see article Evidence Record Syntax ) with their own proprietary interfaces.
Solutions have existed since 2010 in which the evidential values are stored and sealed directly in the document container. Proprietary, separate systems for the administration of evidence records can be completely dispensed with.
Certification
The technical guideline TR-03125 of the BSI ([Federal Office for Security in Information Technology]) uses the Evidence Record Syntax to provide evidence and allows corresponding certifications on the basis of the Protection Profile ArchiSafe .
criticism
To criticize the re-signing of qualified signed documents that are stored in an electronic archive, see the article ArchiSig .
It may be doubted whether the Internet draft LTANS-LTAP will prevail. In the meantime, all market-dominant manufacturers such as IBM, SAP, Microsoft, EMC and ORACLE have come together to define the CMIS standard under the authority of the Organization for the Advancement of Structured Information Standards (OASIS). The Content Management Interoperability Service (see web link) specifies on the basis of the SOAP and REST protocol how applications can store, search and find content in corresponding repositories (including archives) in file structures with regard to access rights.
Web links
Individual evidence
- ↑ IETF LTANS Working Group ( Memento of the original of July 10, 2009 in the Internet Archive ) Info: The archive link was automatically inserted and not yet checked. Please check the original and archive link according to the instructions and then remove this notice.
- ↑ LTANS Status Page
- ↑ Internet Draft: Data Structure for the Security Suitability of Cryptographic Algorithms - LTANS-DSSC
- ↑ Internet Draft: Long-term Archive Protocol - LTANS-LTAP
- ↑ Product description: SecDocs - long-term archiving with evidence
- ↑ BSI TR-03125 Preservation of evidential value of cryptographically signed documents ( Memento of the original dated September 28, 2011 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.
- ↑ BSI-DSZ-CC-0685-2012 ( Page no longer available , search in web archives ) Info: The link was automatically marked as defective. Please check the link according to the instructions and then remove this notice.
- ↑ Common Criteria Protection Profile for an ArchiSafe Compliant Middleware for Enabling the Long-Term Preservation of Electronic Documents (ACM PP) ( page no longer available , search in web archives ) Info: The link was automatically marked as defective. Please check the link according to the instructions and then remove this notice.
- ↑ ArchiSafe module
- ↑ Certification Report BSI-CC-PP-0049-2008 ( Memento of the original dated January 30, 2012 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. (PDF; 543 kB)
