[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                         T. Gondrom
Internet-Draft                                             July 12, 2010
Intended status: Informational
Expires: January 13, 2011


                           LTANS Architecture
                        draft-ietf-ltans-ari-01

Abstract

   This document outlines best practices how to use and integrate
   components based on the various specifications prepared by the LTANS
   WG for long term archiving and non-repudiation services can work
   together in a best practices environment.  It especially takes care
   of the overall architecture and integration of the protocol and the
   data structures.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 13, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Gondrom                 Expires January 13, 2011                [Page 1]


Internet-Draft                     ARI                         July 2010


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  General Architecture Overview  . . . . . . . . . . . . . . . .  3
   3.  ERS and XMLERS . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Hot to verify a combination of ERS and XMLERS  . . . . . .  6
   4.  Protocols and DSSC . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Implementation details . . . . . . . . . . . . . . . . . . . .  6
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     7.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10




























Gondrom                 Expires January 13, 2011                [Page 2]


Internet-Draft                     ARI                         July 2010


1.  Introduction

1.1.  Motivation

   Over the last years various implementations of the specifications of
   the LTANS drafts have been build.  And as the current specifications
   come to their final state, an architectural information about how to
   best integrate these specifications and how to best build such an
   archive system seems helpful.

   After ERS, XMLERS, ERS-SCVP and DSSC have specified the necessary to
   standards for the protocol and the data structures for such a service
   this document only has informational character helping to understand
   and follow best practices on how to design such a system and combine
   the variosu drafts for maximum effect.

   The weaknesses identied in some of today's most common hash
   algorithms like SHA-1 also make it clear that a protection of the
   integrity of data after the compromise of a specific hash algorithm
   is of elemtary importance to society.  Considering that one of today
   in digital signatures used hash algorithms might loose its security
   attributes (by e.g. cryptoanalysis attacks showing that the collision
   resistance can no longer be guaranteed) will put all until today
   already signed messages and data at risk.  This can e.g. also hit
   data that only needed simple integrity protection by applying
   timestamps as defined by RFC3161.


2.  General Architecture Overview

   The central design principle in electronic archiving is to provide a
   simple identification for an electronic data object.  Any user who
   knows this id and has the proper authorization can at a later point
   in time access the digital object from any place in the world.

   This of course has certain implications for the data.

   1.  Availability: How long shall the data be stored

   2.  Integrity: is the object still the one that has been entrusted to
       the electronic archive?

       *  protect against modifications by the system or an attacker

       *  can the owner proof to another party that the data has not
          been altered since archiving (including not been altered by
          himself)?




Gondrom                 Expires January 13, 2011                [Page 3]


Internet-Draft                     ARI                         July 2010


   3.  Confidentiality: how can the data best be protected against
       disclosure to e.g. service providers operating the system or
       during transmission of data to and from the archive?

   For the general system design it may also be considered how can the
   data later be found and retrieved.  Is there additional metadata
   necessary and by which system is it handled best?

   Availability
   As nearly all data has only to be stored for a limited (although
   possibly very long) time and after this can be deleted, the system
   should deploy rules or configuration parameters when data can be
   removed and destroyed.  As the data also represents an important
   value to its users it is also necessary that retrieval and retention
   management employ a consistent access control management.

   System Architecture
   The genral server architecture of a LTANS archive service can follow
   several possible architecture concepts:

   1.  the LTANS archiving and signature renewal system can be managed
       as a stand-alone solution:
       Users submit data directly via any simple protocol (e.g.  HTTP,
       WebDAV, or others) to the service.  The system stores the
       documents and based on system policies manages the signature
       renewal and integrity protection.  In the most simple
       implementation the system may even not apply any actions
       automatically but always need the command of a responsible data
       owner to initiate them.  The minimum actions that may be needed
       to be performed are data storing, data retrieval, signature
       renewal and data delete.  In theory all these actions could also
       be requested by the user.  But usually a normal user does not
       know, e.g. when a specific algorithm is no longer secure and
       initiate a renewal in time.  In the best configuration this would
       be managed by the system.  And with the long storage times coming
       with electronic archiving the usual user may also not want to
       manage the data retention by himself but simply want to tell the
       system at the time of storage (or any later time) when to
       securely delete and irreversly destroy the stored data.  An
       example of a very simple client could e.g. be a WebDAV or File
       system like interface that directly speaks with the service and
       stores all data with a predefined policy.  Server configuration
       and operations defines the used parameters, retention times and
       when a signature renewal is initiated.

   2.  The LTANS signature renewal service can also be loosely coupled
       with a normal archiving system.  This can have various
       implementations:



Gondrom                 Expires January 13, 2011                [Page 4]


Internet-Draft                     ARI                         July 2010


       *  The service might be completely hidden by the normal archive
          system with two differnet techniques:
          the archive system may simply transfer all its data that shall
          be integrity protected by LTANS Evidence Records directly to
          the LTANS server or it may keep its own data and only simply
          submit copies of data that needs the integrity protection and
          non-repudiation of the LTANS system to the service.  With the
          second approach it may still use its own techniques for the
          normal operation and management and only in the case of the
          needed integrity and non-repudiation proof retrieve data from
          the service and verify the evidence record.

       *  the service might be provided in parallel to the normal
          archive in a more complex system architecture.
          In such a case a client may access either the normal document
          management system/archive or also directly access the LTANS
          service.  Documents may be directly tansferred from the normal
          document management system to the LTANS service for integrity
          protection and non-repudiation services.  Depending on the
          need of the user he requests data from the document management
          system or (if he requires a valid evidence reocrd for his
          data) directly accesses the LTANS archive service.  The
          connection to these two services in parallel may make the
          integration in some parts easier as every system can
          specialize on its defined tasks but may raise issues of how to
          ensure access control.  In this case a ticketing system may be
          helpful where the user has to obtain a secure authorization
          ticket from the document management system or application to
          get access to the evidence record in the LTANS system.

   3.  The LTANS signature renewal can be directly integrated in an
       existing archiving system:
       In this case a commercial archiving system might simply add the
       functionality of applying timestamps and signature renewal to its
       backend storage system.  This can be done at two layers: Either
       in the archiving system or if a more intelligent storage system
       (like e.g. in some commercial hard disk arrays) is used in the
       storage itself.  The advantage of a tighter integration with an
       archiving system can be that existing infrastructure and
       management systems can be used, renewal and retention times can
       be based on metadata available to the overall system, the
       organization of the data on storage media and in data groups for
       the evidence record can also be determined (and optimized) by
       this metadata available to applications and document management
       systems.  This integration can result in various use cases for
       the specific protocols.  As most of the today existing document
       management systems already implemented their own proprietary or
       open protocol it may be the case that the system only extends its



Gondrom                 Expires January 13, 2011                [Page 5]


Internet-Draft                     ARI                         July 2010


       own protocol with the ERS functionality.  Or it may offer a
       second protocol extension in parallel to it's own protocols for
       specific clients for non-repudiation and integrtity verification.
       In the case that the LTANS service will be implemented on the
       storage level it may be that the storage vendors will implement a
       protocol for their data access layer which may impose very
       different requirements than the normal software application
       oriented implementations.


3.  ERS and XMLERS

   The Evidence Records provided by ERS and XMLERS provide evidence
   records in ASN.1 and XML.  They both follow identical design
   principles and provide the same level of security.  But as the
   signature renewal process also must involve and includes parts of the
   byte representation of the data structures which are used, there is
   no bidirectional transformation from one format to the other.  In
   general a system willeither implement ERS (using the ASN.1 format) or
   XMLERS (using XML).  However as the renewal and protection process
   applies to data independent of the used data containers and formats
   it is possible to store ERS in systems using XMLERS and vice versa.
   But a verification process would in these cases be more complex and
   require a system supporting both standards.

3.1.  Hot to verify a combination of ERS and XMLERS

   tbd


4.  Protocols and DSSC

   tbd


5.  Implementation details

   An LTANS system consists in its minimum implementation of a sevice
   speaking a basic transfer protocol (e.g.  HTTP or WebDAV), a data
   management system organizing the data by grouping, building hashtrees
   and executing renewal procedures, a storage media where the system
   keeps the initial documents (for the case of later Hashtree renewals)
   and the evidence records and a trusted time stamp source which would
   best be provided by an independent trusted third party.

   A client stores his to the system by using directly or indirectly
   (e.g. via a WebDAV client to file share).  As most systems already
   deploy their own access control management the used protocol can rely



Gondrom                 Expires January 13, 2011                [Page 6]


Internet-Draft                     ARI                         July 2010


   on the already existing infrastructure with authenticated and
   authorized requests.  This may e.g. be done via a Kerberos or other
   implementation.

   The system receives the data and collects it.
   In case of digital signed documents it may in a first step verify
   these and also receive additinal necessary verification data from
   other sources as specified in the draft draft-ietf-ltans-validate.
   It is recommended to integrate any necessary verification data at
   this step into the document as e.g. specified in RFC3126 or to
   combine all necessary date for verification with the document and
   signatures themselves together in one container for storage and non-
   repudiation protection so that any later party can rely on the
   unbroken integrity and chain of custody for the documents and all the
   verification data since the time of archiving and redo the
   verification procedure based on the complete information as some of
   the verification information might be difficult to obtain at a later
   time, e.g. 30 years later.

   The specification of ERS relies as an example on time stamps based on
   RFC3161, but can explicitely also support and use other time stamping
   mechanisms that rely on certain basic mechanisms: Public key
   algorithms, using a trusted time source, and from a trusted third
   party (which may in some countries require an accreditation by a
   government agency.  Such other time stamp sources may e.g. also be
   the Time stamp mechanism specified by ISO.

   Additionally to the verification data certain systems may require the
   storage of certain metadata additional with the document as the
   document may only be complete and understandable with this context
   (metadata information).  This can e.g. also be accomplished by
   storing document and metadata within one container, which can be the
   same or another container within the container of the docuemnht and
   the verification data.

   After the retrieval of the document and the possible enrichment of
   the data, the document or the container is stored in the system.  In
   the case that time stamps or signatures have been applied before the
   submission of the data, this data already has a certain level of
   evidence based on the security level of the used algorithms and
   procedures.  Instead of evaluating the algorithms used in the initial
   data, the system applies one initial archivetimestamp with its own
   secure timestamps and hash algorithms to "equalize" all data to a
   defined integrity and non-repudiation assurance level.  For this step
   the system groups all data within a hashtree and applies a timestamp
   it received from an external trusted third party.  Thhe frequency of
   this initial step may be configured in the system, some may require
   only a granularity of once per week, others with a high volume may



Gondrom                 Expires January 13, 2011                [Page 7]


Internet-Draft                     ARI                         July 2010


   execute this every hour or even shorter interval.  Current
   implementations have shown that the granularity of a daily initial
   ArchiveTimestamping seems an adequate protection.

   After this initial Archivetimestamp the system now knows the well
   defined algorithms it used during this step and will renew the
   archive timestamp (and together with this, all the data already
   stored in the container and signed or encrypted with other
   algorithms) if the algorithms of the initial Archivetimestamp get
   weak.

   The execution of renewal can be configured at the LTANS server or
   even manually executed before the algorithms used in the last
   Archivetimestamp of the ArchiveTimestampchain as specified in ERS get
   weak.

   The system stores data and the created archivetimestamps, later in
   the form of Evidence Record.  For better data management it is
   recommended to store them on the same type of media or even on the
   same media, as the stored data may be worthless without the Evidence
   Record and vice versa.

   At a later point in time the client may request the data or the
   Evidence record from the LTANS system.  A certain implementaion of
   the LTANS system may even only implement an interface to retrieve the
   Evidence Record and not the the data itself which in such a
   configuration would have to be stored and kept by the user or client
   separately.  (For renewals due to identified weaknesses in used hash
   algorithms it is still necessary to store the data to the system so
   that a hashtree renewal as defined by ERS can be performed.)

   The client then verifies the received Evidence Record based on a
   defined archive policy (which defines which algorithm was considered
   secure for which period of time (begin and end) and which time stamp
   sources and verification data may be trustworthy).  This may be done
   automatically or also done manually by an expert (e.g. during a
   lawsuit).


6.  Security Considerations

   System design

   the system architecture raises a number of security questions
   especially in the area of access control and confidentiality as the
   security of a system can always only as strong as the security of the
   weakest part of the chain.




Gondrom                 Expires January 13, 2011                [Page 8]


Internet-Draft                     ARI                         July 2010


7.  References

7.1.  Normative References

   [ANSX995]  American National Standard for Financial Services,
              "Trusted Timestamp Management and Security", ANSX X9.95-
              2005, June 2005.

   [I180141]  ISO/IEC JTC 1/SC 27, "Time stamping services - Part 1:
              Framework", ISO ISO-18014-1, February 2002.

   [I180142]  ISO/IEC JTC 1/SC 27, "Time stamping services - Part 2:
              Mechanisms producing independent tokens", ISO ISO-18014-2,
              December 2002.

   [I180143]  ISO/IEC JTC 1/SC 27, "Time stamping services - Part 3:
              Mechanisms producing linked tokens", ISO ISO-18014-3,
              February 2004.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", RFC 2026, 1996.

   [RFC2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
              Requirement Levels", RFC 2119, 1997.

   [RFC3126]  Adams, C., Pinkas, D., Ross, J., and N. Pope, "Electronic
              Signature Formats for long term electronic signatures",
              RFC 3126, 2001.

   [RFC3161]  Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
              "Internet X.509 Public Key Infrastructure Time-Stamp
              Protocol (TSP)", RFC 3161, August 2001.

   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              August 2001.

   [RFC3852]  Housley, R., "Cryptographic Message Syntax (CMS)",
              RFC 3852, July 2004.

7.2.  Informative References

   [ETSI2003]
              European Telecommunication Standards Institute (ETSI),
              Electronic Signatures and Infrastructures (ESI);,
              "Algorithms and Parameters for Secure Electronic
              Signatures", ETSI SR 002 176 V1.1.1, March 2003.



Gondrom                 Expires January 13, 2011                [Page 9]


Internet-Draft                     ARI                         July 2010


   [MER1980]  Merkle, R., "Protocols for Public Key Cryptosystems,
              Proceedings of the 1980 IEEE Symposium on Security and
              Privacy (Oakland, CA, USA)", pages 122-134, April 1980.

   [REQ2004]  Wallace, C., Brandner, R., and U. Pordesch, "Long-term
              Archive Service Requirements", I-D ???, 2005.


Author's Address

   Tobias Gondrom
   Munich
   Germany

   Email: tobias.gondrom@gondrom.org




































Gondrom                 Expires January 13, 2011               [Page 10]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/