LTANS A. Jerman Blazic
Internet-Draft SETCCE
Expires: December 28, 2006 P. Sylvester
EdelWeb SAS - Groupe ON-X
C. Wallace
Orion Security Solutions
June 26, 2006
Long-term Archive Protocol (LTAP)
draft-ietf-ltans-ltap-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 28, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a service operated as a trusted third party
to securely archive electronic document called a long-term archive
service (LTA). We describe an architecture framework and a protocol
allowing clients to interact with such a service. Bindings to
concrete transport and security protocol layers are given.
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 1]
Internet-Draft LTAP June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Functional Overview . . . . . . . . . . . . . . . . . . . 8
3.2. Operation of LTA . . . . . . . . . . . . . . . . . . . . . 8
3.3. Transactions . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Life cycles of objects . . . . . . . . . . . . . . . . . . 10
3.4.1. Life cycle of one transaction . . . . . . . . . . . . 11
3.4.2. Long term life cycle. . . . . . . . . . . . . . . . . 11
3.5. Roles, Service Types, Policies and Configurations . . . . 12
3.6. Entities . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6.1. Entity Identifiers . . . . . . . . . . . . . . . . . . 14
3.6.2. Attributes . . . . . . . . . . . . . . . . . . . . . . 15
3.7. Data Model . . . . . . . . . . . . . . . . . . . . . . . . 15
3.7.1. Data objects . . . . . . . . . . . . . . . . . . . . . 15
3.7.2. Collection objects . . . . . . . . . . . . . . . . . . 16
3.7.3. MetaData . . . . . . . . . . . . . . . . . . . . . . . 16
3.7.4. Binding Information . . . . . . . . . . . . . . . . . 17
3.7.5. Evidence Data . . . . . . . . . . . . . . . . . . . . 17
4. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Message Imprint . . . . . . . . . . . . . . . . . . . . . 18
4.3. MetaData . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5. RawData . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6. DataOrTransaction . . . . . . . . . . . . . . . . . . . . 21
4.7. Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.8. SerialNumber . . . . . . . . . . . . . . . . . . . . . . . 22
4.9. RequestTime . . . . . . . . . . . . . . . . . . . . . . . 22
4.10. Version . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.11. EntityIdentifier . . . . . . . . . . . . . . . . . . . . . 23
4.12. ServiceType . . . . . . . . . . . . . . . . . . . . . . . 24
4.13. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.14. RequestInformation . . . . . . . . . . . . . . . . . . . . 25
4.15. Request . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.16. ErrorNotice . . . . . . . . . . . . . . . . . . . . . . . 26
4.17. OperationResponse . . . . . . . . . . . . . . . . . . . . 27
4.18. Response . . . . . . . . . . . . . . . . . . . . . . . . . 27
5. Service Operations . . . . . . . . . . . . . . . . . . . . . . 29
5.1. Requests . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2. Response . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3. ARCHIVE operation . . . . . . . . . . . . . . . . . . . . 29
5.3.1. Request . . . . . . . . . . . . . . . . . . . . . . . 30
5.3.2. Response . . . . . . . . . . . . . . . . . . . . . . . 30
5.4. STATUS operation . . . . . . . . . . . . . . . . . . . . . 30
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 2]
Internet-Draft LTAP June 2006
5.4.1. Request . . . . . . . . . . . . . . . . . . . . . . . 30
5.4.2. Response . . . . . . . . . . . . . . . . . . . . . . . 30
5.5. EXPORT operation . . . . . . . . . . . . . . . . . . . . . 30
5.5.1. Request . . . . . . . . . . . . . . . . . . . . . . . 31
5.5.2. Response . . . . . . . . . . . . . . . . . . . . . . . 31
5.6. VERIFY operation . . . . . . . . . . . . . . . . . . . . . 31
5.6.1. Request . . . . . . . . . . . . . . . . . . . . . . . 31
5.6.2. Response . . . . . . . . . . . . . . . . . . . . . . . 31
5.7. DELETE operation . . . . . . . . . . . . . . . . . . . . . 31
5.7.1. Request . . . . . . . . . . . . . . . . . . . . . . . 32
5.7.2. Response . . . . . . . . . . . . . . . . . . . . . . . 32
5.7.3. Delete . . . . . . . . . . . . . . . . . . . . . . . . 32
6. Presentation and Bindings . . . . . . . . . . . . . . . . . . 33
7. Security and Transport . . . . . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 36
9. IPR Patent Information . . . . . . . . . . . . . . . . . . . . 37
10. ASN.1 module . . . . . . . . . . . . . . . . . . . . . . . . . 39
11. XML schema . . . . . . . . . . . . . . . . . . . . . . . . . . 40
12. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 41
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
13.1. Normative references . . . . . . . . . . . . . . . . . . . 42
13.2. Informative references . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 44
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 3]
Internet-Draft LTAP June 2006
1. Introduction
In all contexts of documents, conservation plays an important role;
one can often say that appropriate conservation rules are a
prerequisite for data to be come a document. Conservation has
several aspects, e.g. duration or accessibility, that vary based on
the nature of the document. For example, a document may be conserved
for a certain period and may be destroyed after that. A document may
be accessible on a public or restricted basis to a set of potentially
interested or authorized entities.
The protocol described in this document enables the use of a
specialized service for conservation of electronic documents. The
service creates and delivers enough information to demonstrate the
existence, integrity and authenticity of electronic data over any
period of time. In other words, the service assumes the
responsibility to retrieve and, optionally, store data for
conservation, create and store evidence to guarantee data integrity
and completeness, and to maintain accessibility of data and evidence
created.
This document describes a protocol for interacting with a long-term
archive service (LTA). The document contains only description of a
general request and response structure, and a detailed protocol
description concerning access to an LTA. Other specifications and
descriptions, e.g. a framework protocol containing mappings to
transport and security services, are addressed elsewhere. The
protocol is intended to be used in client-server architecture, where
client is simply an end user (a physical user or another service) and
the server as an LTA.
The process of replacing paper based workflow and document handling
is known as 'dematerialization', ignoring to a certain degree the
requirements for long term stability of documents. Document
conservation is generally performed by specialized services. For
electronic formats it is proposed to use similar approaches, while
maintaining the distance of technical characteristics (paper versus
electronic). Conservation might be taken out from other workflow
activities, while the same procedures (evidence creation) might be
used for any milestone in electronic document lifecycle (e.g. version
marking).
Since conservation of documents created by one entity is only
necessary if there is a potential entity to which the document may be
presented at some time, the conservation service (LTA) acts as a
trusted third party for those two entities. The main role of an LTA
is to generate and provide enough information for archived data
existence in time, integrity and authenticity demonstration over long
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 4]
Internet-Draft LTAP June 2006
periods of time. Provision of data storage services is optional and
may be assured by supportive infrastructure (e.g. database or
document storage/management system).
Note: This is still a very incomplete text. The abstract service and
protocol is almost finished.
Note: This document does not contain a concrete binding to lower
layers. This may be added later or defined in a separate document.
Means to exchange protocol messages are not explicitly defined.
Transport should be possible over http/soap and other protocols.
Defined data structures are presented in XSD and ASN1 forms.
1.1. Requirements notation
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].
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 5]
Internet-Draft LTAP June 2006
2. Background
A conservation service or long term archive (LTA) consists of several
functional blocks. Some of these blocks are not considered by LTANS
as they present the basic infrastructure, such as the communication
network, storage device, data management, etc. Instead, an LTA
implements the archive interaction protocol as defined by this
specification (LTAP) and manages archive objects (logically
interpreted as packages of archive data and conservation attributes)
and evidence records [I-D.ietf-ltans-ers]. An LTA is a part of a
general archive service that provides evidence used to demonstrate
the existence of an archived data object at a given time and the
integrity of the archived data object since that time. The LTA is
the primary part tasked with creating and delivering conservation
attributes for archived data.
[I-D.ietf-ltans-reqs] defines the services that must be provided by
an LTA. A pricipal function of the LTA is to generate or obtain
evidence information for (archive) data submited. It may accept data
and generate (or acquire from another service) evidence inforamtion
or it may simply act as an evidence and demonstration information
servce without data storage capabilities (it only handles evidence
and demonstration information). Evidence generated and maintained by
an LTA addresses the problems of long-term integrity and temporal
existence.
Archive objects are the central logical structures defined by the LTA
and maintained on a long-term basis. They are atomic elements of an
LTA service consisting of three logical elements. The logical
structure of an archive object consists of:
o Archive data (including meta-data or other related data) entering
the LTA using the interaction protocol,
o Archive process related meta or binding information and
o Evidence information
The archive data may contain any data type, e.g., raw data, signed
data, encrypted data or time stamped data as defined by [I-D.ietf-
ltans-reqs]. Archive data may be associated with additional data or
attributes, e.g. meta information or digital signatures.
Data generated or collected by the LTA are archive process related
meta or binding information including demonstration information and
evidence information. Archive meta data is needed to provide enough
information for e.g. special (legal) purposes or validity
demonstration purposes (e.g. complementary information to digital
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 6]
Internet-Draft LTAP June 2006
signatures). The LTA collects meta or binding information directly
from a user or some other entity (e.g. Certificate Authority). Such
information may contain the data owner name, organization, location,
etc. Meta or binding information may be submitted by the LTAP
protocol.
Demonstration information is collected to demonstrate facts on the
archive data. Such information may be digital signature reference
information. The LTA may use external resources to collect such
information usually without user intervention. Evidence data is
generated by the LTA or collected from an external resource, e.g. a
time stamping authority. Evidence information is provided for all
data: archive data submitted by a client and archive process related
data (including binding and demonstration information) collected by
the LTA from the client or alternative resource.
The LTA performs perpetual maintenance of generated archive objects
for the main purpose of demonstrating archive data existence in time
and providing integrity information for the complete archiving time.
Archive objects are periodically processed to provide long term
stability (e.g. by proof-reading, copying to new material, or
performing time stamp renewal).
The LTAP protocol interprets the logical data structure to hold all
needed information (including references) to build an archive object
including archive data itself (or reference to archive data). The
logical structure of the LTAP messages includes archive data,
archiving process related information and references together with
request and processing information. Using LTAP, the LTA should have
enough information to build and perform operations on an archive
object(s).
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 7]
Internet-Draft LTAP June 2006
3. Framework
This chapter describes a general framework for secure exchange of
request and response messages between an archive client and archive
server, e.g. an LTA. It provides a high level outline and identifies
common and external aspects from the concrete protocol data units.
3.1. Functional Overview
The requirements for LTAP are defined in [I-D.ietf-ltans-reqs]. The
protocol consists of two layers that are largely distinct but share
some common features, for example, identificaton and authentication.
It is assumed that an LTA ensures the long term availability of
stored data and created evidence information, as necessary, and uses
appropriate means to manage data and access rights. These important
features of an LTA are outside the scope of this specification.
The common high-level architecture consists of a protocol used to
exchange requests and responses securely, potentially over different
types of transport connections, to ensure the long term validity of
responses.
Clients and servers use one of several object types to build requests
and responses. Data objects include raw (archive) data, request
information, meta information, identification information and
attestations.
Requests and responses are exchanged in a secure way responding to
different security requirements, which may concern the security of
the transport as well as the long term validity of the data being
exchanged.
The LTA is not a method for implementing something like a secure file
system. In general, archived data are rarely accessed, restored or
transferred. Thus, the archive operation is the most important one
and performance is an important concern. In this case that client
applications need frequenet access to the data, they generally keep a
copy of the data including evidence information, whose integrity can
be compared from time to time or when requested.
3.2. Operation of LTA
An LTA, as defined by LTANS working group in [I-D.ietf-ltans-reqs],
is a service that is responsible for preserving evidence data and/or
data for long periods of time. The LTA interface enables clients to
perform at least the following operations:
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 8]
Internet-Draft LTAP June 2006
o ARCHIVE: submit data to an LTA and request creation of evidence
information for data
o STATUS: check the status of data.
o EXPORT: retrieve data (including archive data, meta information
and evidence information) from an LTA
o DELETE: remove data and/or evidence information from an LTA.
o VERIFY: validate the integrity and validity of LTA archived data
These operation form the minimal set and they MUST be implemented by
any LTA service. Furthermore, there is a minimal profile for the
parameter structures targetted for transactions with a single server
that does act as a final repository. Parameters and functions MAY be
extended in order to allow services to propose more complex
operations like data splitting or relaying.
The status operation actually has two flavors depending on whether
the status of a object or an operation is to be retrieved. In case
of a status of an operation, the client retries the operation using
the artifact identifying the transaction.
The primary aim of this protocol is to enable a formal interaction
between a user and an LTA. The result of the interaction is a
verifiable attestation of procedures performed by an LTA (e.g.
archive data plus evidence record). The format for data structures
used to demonstrate integrity, i.e. to demonstrate that data has not
undergone any transformations while in the care of the archive, is
partially defined in other documents, namely in [I-D.ietf-ltans-ers].
This specification does not place any requirements on the structure
of archived data objects. However, it operates on elements that are
derived from archive data objects (e.g. message imprints).
3.3. Transactions
The model for the exchange of LTAP requests and responses is borrowed
from other environments like EDI, X.400 or ebXML. It's main
caracteristic is that exchanges for LTAP are conceptually
asynchronous. As a conseuence, transfer of responsibilty does not
occur immediately. An LTAP exchange consists of sending a request
and retrieving one of two different types of responses. A client
initiates an archive service by submiting a request. This LTAP
request consists of data to be archived and information related to
the archive process. The process information may include client
authorization, archive policy, service parameters, etc. The first
type of response is a technical acknowledgement from the LTA that the
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 9]
Internet-Draft LTAP June 2006
request has been received and the process information has been
accepted (or rejected). The second type of response is a statement
from an LTA containing an indication of the outcome of the requested
operation. This result (called an attestation) is, in general, a
document with long term validity allowing the client to reference the
operation, and, in particular, to reference the data that has been
preserved by the LTA. The two types of responses are similar to
X.400 delivery reports and receipt notifications.
The asynchronous nature of the LTAP protocol is required by LTA
operations, which may require a specific amount of time to perform,
e.g. the archive operation needs to safely store the data and to
produce evidence information.
Not all operations may require the use of an asynchronous response.
The LTA therefore responds with either the first category or second
category information, as appropriate. The first category includes
response information regarding process information (e.g., receipt of
the request) while second category adds response information
regarding operation(s) performed by the LTA. For some operations, an
LTA may initally deliver a complete (second category) information
(e.g. STATUS request).
A LTA is assumed to perform an operation with a best effort.
Nevertheless, it is allowed that an operation can fail or get totally
lost. The possibility to deliver the result attestation in a
asynchronous way is to allow cost effective implementations of the
LTA. A client SHOULD be able to recover from lost requests, i.e.,
avoid deleting data until an attestation has been received.
Until the receipt of the technical acknowledgement, a client can
repeat an operation (or use a status request), since the request or
the response might have been lost. The client can provide a unique
identification for the request that SHOULD be used by the LTA to
ensure idempotence of transactions.
After receipt of the technical acknowledgement (first category
information), the client can use a STATUS operation to determine the
progress of the transaction. Depending on the lower layer bindings,
sending a status request (polling) may be the only way to determine
the outcome of an archive operation.
3.4. Life cycles of objects
Using the defined transactions and the operations on object, the life
cycle is as follows defined.
There are two levels in the lifecycle. One is directly derived from
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 10]
Internet-Draft LTAP June 2006
the operation of a single transaction. The other is related to the
long term situation after operations like DELETE for the an object.
3.4.1. Life cycle of one transaction
When a client initiates an archive operation, client and server have
some knowledge of the progress of the operation. The following list
shows the different states of a transaction seen by both the client
and the service, and decribes possible actions for progress.
T1: Client has not initiated an archive operation. The TAS does not
know anything about an object.
T2; Client has initiated an archive operation, it cannot assume that
TAS has received the request. The TAS may have received the object.
Client may retry the operation operation after a timeout.
T3: TAS has received the request and has generated an initial
response containing an transaction artifact. The server ensures
idempotence of an operation, i.e. on multiple occurences of the
request, TAS sends the same acknowledge and transaction artifact.
The TAS may still forget about the operation (e.g., in case of a
power failure).
T4: Client has received the initial response. Client retry the
initial operation using the transaction artifact as data. In case of
negative response, client falls back to T1.
T5: Server has send a definitive answer for an operation and has
assumed the responsible of operation.
T6: Client has received a definitive answer and can consider the
operation as terminated.
In case of negative reponses to a transaction, the TAS keeps the
result for a certain time in order to provide a reasonable answer to
a client that retries an operation.
3.4.2. Long term life cycle.
When a TAS has archived an object, it keep a certain number of
metadata for it, which give information about the current status of
the object. Metadata may remain available even after deleting the
object, among the remaining metadata there is the date of deletion or
an information where the information can actually be received.
We can therefore distinguish the following phases in the lifetimes of
an archived object:
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 11]
Internet-Draft LTAP June 2006
T1: A TAS has archived an object. A TAS can accept other operations,
i.e., READ, DELETE or VERIFY operations. When receiving READ or
VERIFY operations, some metadata may be updated, e.g., last time of
access, last verification operation etc.
T2: After a DELETE operation prior to the initially defined lifetime
of the operation, the TAS MAY keep an information about the actual
status of the object (e.g. deleted) until the end of the lifetime.
If available, the TAS returns an information of the new TAS usable by
a client to access to it.
T3: After the lifetime of an object, an object or the reference to it
is deleted. When an object is moved to another service to prolong
its lifetime, the initial reference may be deleted after the end of
the initial lifetime.
3.5. Roles, Service Types, Policies and Configurations
The protocol assumes a number of different actors playing different
roles. The basic roles are a client and a server. These roles are
simply defined by the types of protocol data units, i.e., requests
and responses. Several other roles may exist, which are currently
not in the scope of the protocol specification. An example of an
additional role is a relay or a proxy using both the basic roles of
client and server. In general two entities are distinguished, based
on different characteristics: an entity that requests its data to be
archived or to be acted upon, and an entity that accepts data and
assures responsibility of archived data, or acts on the data. Other
entities serving as a lower layer transport services, data storage
services or security services are out of the scope of protocol
definition.
Clients may occur in different roles. Besides users that archive
data, there may be relying or controlling entities like a judge who
must be able to get access to it. Or, there are entities like
auditors that may access to some data. The protocol distinguish such
roles by the definition of the following service types and service
policy information.
The LTA interface implementation MUST enable clients to perform all
five service operations.
A client implementation MAY only support a subset of the service
types in order to have a small footprint. This is motivated from the
fact that different operations are generally invoked by different
entities in totally different environments, e.g., a client may only
submit data and never verify an evidence record.
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 12]
Internet-Draft LTAP June 2006
As mentioned above, depending on the lower layer transport bindings,
a client may be required to have implemented the STATUS operation in
order to retrieve the outcome of another operation.
The way a particular operation is performed is only defined at the
LTA server side implementation and can be influenced by policy
information parameters. A client MAY indicate one or more service
policy identifiers associated to a service type in order to select
different features to be performed by the LTA. The goal of policy
identifiers is to have client configurations simple.
An LTA service may provide additional features, which may be
identified by clients, that govern how services are performed. An
LTA might offer a series of features based on quality
characteristics, e.g. number of timestamps used, refresh period, etc.
The protocol specification builds on the assumption that features are
clearly identifiable and are included in the protocol elements.
Features enable clients to request specific handling by the LTA, such
as requesting a premium service that assures prompt and immediate
archiving vs. a standard service that handles queues and generates
evidence data periodically based on data collections, i.e., one
timestamp per a document bundle. Also, services may differ according
to data storage characteristics (e.g. client may request full
evidence and storage capacity or only evidence creation service),
redundancy characteristics (single timestamp versus multiple time
stamping), etc. Service characteristics are defined by archive or
operation policies.
An LTA may use external services, like validation and evidence
creation services. Another service is provision of physical
infrastructure or data storage and management systems. Such entities
can also be referenced by service policy identifiers.
In general, for each client, in particular those that are archiving,
a default or single possible configuration is defined at the server
in order to group features and policies into defined sets. A server
may operate different configurations and from the protocol
standpoint, general configuration is selected by the policy
identificator.
As a last mechanism to provide parameters to the archive server, LTA
clients MAY use specific configuration parameters in their requests.
The definition of such parameters is not in the scope of this
protocol. Configuration parameters allow clients to transfer
arbitary key/value pairs from the client to the server.
In principle, a single sequence of policy information is sufficient
to indicate both the service type and the configuration parameters.
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 13]
Internet-Draft LTAP June 2006
A multi-dimensional approach with configuration and service types
rounds up the requirements for LTA and scenarios of archiving
processes.
Often, an extension of the initial lifetime of an object has to be
forseen by an LTA service. To extend the lifetime of an object, an
EXPORT operation is used to transfer or copy the object to an LTA
service having the required lifetime policy/configuration.
This document defines no particular policy or configuration.
3.6. Entities
Entities that participate in protocol exchanges are represented by
identifiers and may possess attributes. It is outside the scope of
this definition to define an organisation of identifiers and
attributes, in particular the way how entity identifiers are related
to identifiers used for authentication, or what attributes are
associated to data.
As the current LTAP specification assumes end-to-end communication
only, there is no distinction between technical roles like 'client,
'server', 'relay', 'proxy' or 'authorized agent'. For LTAP, only
client and server roles are defined.
The explicit usage of identifiers and attributes enables decisions to
be traceable, i.e., the participating entities can indicate to a
certain degree why they want a service or why it has been provided.
Furthermore, entity identifiers and attributes MAY be provided by the
transport or security layer information. These information can be
added to protocol elements as trace attributes.
3.6.1. Entity Identifiers
Entity identifiers are used in the protocol to indicate the
participating entities. A client can indicate one or more
identifiers indicating who is making the request or participating in
its creation and one or more identifiers indicating who should
perform the service. A server can indidate who has provided the
service and who is the indented client.
It MUST be ensured in some way that in an actual context of a client/
server network names are scalable and global both in terms of actual
community space and time to live of the treated data objects.
Identifiers are labeled in some way, i.e. string representations are
typed and can be derived from various external layers. Identifiers
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 14]
Internet-Draft LTAP June 2006
SHOULD use an appropriate structure such as ASN.1 definition of
GeneralName.
3.6.2. Attributes
Entities may possess additional attributes like roles, scopes or
capabilities. Entities MAY indicate attribute values in protocol
exchanges so that they can be used for authentication purposes or
billing.
Attributes may be related to attributes of data, for example, an
entity may acts as a judge or arbitrator for a particular
jurisdiction. The attribute jurisdiction is associated to the entity
and to data treated by the service, and thus, can be used for
authorisation control.
3.7. Data Model
The data fields of a LTAP request are as follows:
o request information or status information
o raw data to archive, or references to data or to transactions.
o metadata providing additional information about the data to
archive
o authorisation and authentication information of the entities
paticipating in the procedure
o other information, required for supporting functions like billing
3.7.1. Data objects
The data to be archived are arbitrary binary data and, minimally, an
associated type that must be either available as part of a server
configuration policy or explicitly indicated by the client.
Data can be referenced by identifiers. Data identifiers are used to
uniquely identify data objects. Data identifiers SHOULD have an
additional local structure (e.g., contain a checksum), in order to
avoid or detect client copying errors. An additional measure to
enhance the redundancy of identifiers is the usage of time values
which can be used in combination with data identifiers.
Servers MUST create a server-wide unique identifier for each data
object managed by the LTA. The identifier MUST be global during the
intended lifetime of an object at least.
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 15]
Internet-Draft LTAP June 2006
Clients may provide their own data identifiers in requests. Whether
the client provided identifiers are unique is outside the scope of
the protocol. LTAs treat these identifiers as opaque information.
In order to identify data for the short lifespan of a transaction,
artifacts can be used to reference data or transactions.
3.7.2. Collection objects
Data grouping can occur for various reasons, i.e. logical,
contextual, semantic, operational, etc. It is out of the scope of
the LTA to perform grouping for other reasons than operational, e.g.
reducing costs or improving performance or scalability. Grouping is
performed on the level of evidence creation by building hash trees as
defined in [I-D.ietf-ltans-ers]. Grouping characteristics are
defined by service policies, e.g. per user or on a daily or volume
basis. The global parameters for selecting appropriate collection
strategies are entity and policy identfiers.
Collections of data can be defined explicitly or implicitly. A
document is added to a collection using policy and entity identifiers
to request a specific collection strategy (e.g. a collection of data
that is processed on a daily basis for a specific user). A
collection identifier may be presented as an extension to an object
identifier and is intially local to one object. Adding another
object to a collection requires the identification of the initial
object and the identification of one object in the collection.
3.7.3. MetaData
Meta information is associated with archive data and can be included
implicitly, i.e. be a part of a document, or explicitly, i.e. as a
document attachment. An LTA does not interprete meta data that may
express logical relations among documents in the archive that is
submitted selectively using several requests. For LTAs, the client
is only in control of selecting and enclosing meta information, which
is logically, contextually or for any other reason related to a
document.
Meta information may occur in various forms and may be an integral
part of archive data, e.g. security attributes in form of digital
signatures. To process such information, the LTA MUST retrieve
enough information on the type and purpose of information enclosed,
which may simply be defined with the use of an apropriate archive
service policy, e.g. archive service for digitally signed documents.
An LTA may perform specific actions related to meta information
processing (and preservation, such as complementary data collection
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 16]
Internet-Draft LTAP June 2006
in form of digital certificates). This can also be done by an
external service, e.g. [RFC3029] or SVCP.
In some scenarios, a specific set of meta information must be
preserved together with archive data, e.g. information identifying
the document owner/author, location or time. The LTAP protocol does
not define constraints on information type and structure. The LTAP
request structure is defined to accept any type of data.
3.7.4. Binding Information
Clients and servers MAY include additional information in their
requests and responses concerning the lower layer binding to a
transport like SOAP, HTTP or S/MIME, i.e. end-point addresses etc.
This category may also include things like billing/accounting
information, i.e. whatever a business transaction needs but which is
not part of metadata, i.e. outside the scope of the archived data.
Note: This section needs further discussion.
3.7.5. Evidence Data
Evidence information demonstrates the integrity and existence of
archived data. The LTA accepts data for the single purpose of
generating or obtaining evidence information for data submitted by a
client. The evidence information structure is defined in [I-D.ietf-
ltans-ers].
In case the LTA accepts data only for the purpose of generating
evidence information (without storage capabilites to avoid, e.g.
confidentiality issues), the archivation process is limited in time.
When an LTA performs a renewal of evidence, archived data may be
required to be available, e.g. when renewing a hash tree. In such
scenarios, the LTA requires availability of archived data for hash
re-computation. The LTAP protocol does not support function for data
re-submission.
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 17]
Internet-Draft LTAP June 2006
4. Data Types
A number of data types are common to both requests and responses. We
give definitions of data as well in XML schema notation as well as in
ASN.1. It is intended that an encoding using XML encoding rules of
the ASN.1 defined data give the same encoding as the XML Schema
defined type. We note that the ASN.1 definitions are not
automatically derived from the XSD definitions (but almost).
To be discussed: current some data definitions are not equivalent.
NOTE: Data structures are still not complete! The following
desription only outlines the characteristics of the protocol. ASN.1
and XML representation needs rework. To be done in the next version.
4.1. Artifacts
Artificats are identifiers used to reference a transaction, or a
result of a transaction. They can be returned as a protocol answer
instead of a response, and allow to retrieve a response or progress
of a transaction later by the initial client or another authorised
entity.
XML Schema
<simpleType name="Artifact">
<restriction base="string">
</restriction>
</simpleType>
ASN.1 Definition
Artifact ::= UTF8STRING
4.2. Message Imprint
A Message Imprint is a short representation of data which can be used
in evidences to link to some data. This is just another way of
saying that they are the result of a one way hash function applied to
some data.
We do not assume that a message imprint will always identify some
data in a unique way (which is not the case by definition of a hash
function), neither do we assume that collisions may not exist now or
in the future. We only assume that within a bounded collection of
data objects (in time and number), which are stored phyically safe,
message imprints uniquely designate other data.
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 18]
Internet-Draft LTAP June 2006
Nevertheless, it is assumed that for the lifetime of protocol
exchanges, hash functions used to create message imprints are
crytographically safe.
The structure of a message imprint is a sequence of an globally
defined identification of a hash function and an representation of an
octet string encoding a value of the hash function.
Message Digests have two components, a description of the hash
algorithm used, and a value of the hash algorithm.
XML-DSIG does not seem to allow digests algorithms to have parameters
(or initialization vectors) as for example with [RFC4491].
XML Schema
<complexType name="MessageImprint">
<sequence>
<element name="DigestAlgorithm" type="anyURI" />
<element name="DigestValue" type="base64Binary" />
</sequence>
</complexType>
ASN.1 Definition
MessageImprint ::= SEQUENCE {
digestAlgorithms AlgorithmIdentifier,
digestValue OCTET STRING
}
IMPORTS AlgorithmIdentifier FROM AuthenticationFramework
{joint-iso-itu-t(2) ds(5) module(1)}
4.3. MetaData
Metadata are a list of open types which can be regarded as key/value
pairs giving addtional information about entities or data and are
related to preservation process.
XML Schema
<complexType name="MetaData">
<sequence maxOccurs="unbounded">
<element namespace="##any" processContents="lax" />
<sequence>
</complexType>
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 19]
Internet-Draft LTAP June 2006
ASN.1 Definition
Metadata ::= SEQUENCE OF SEQUENCE {
type OBJECT IDENTIFIER,
value UTF8STRING
}
4.4. Nonce
A Nonce is an octetstring used to avoid replays of responses for the
STATUS operation. If present in a request, a server MUST respond
with a response containing the Nonce value..
XML Schema
<simpleType name="Nonce">
<restriction base="hexBinary">
</restriction>
</simpleType>
ASN.1 Definition
Nonce ::= OCTET STRING
4.5. RawData
This type carries binary data to be verified, archived or returned.
A client MAY select a metadata type to indicate the type of the data.
TBD: For preservation purposes, an LTA must have information on
archive data type (e.g. signed or unsigned). If type is not
included, it is assumed that data retrived must be processed as
binary string (e.g signatures are not verifed and artifacts
collected).
XML Schema
<simpleType name="RawData">
<restriction base="base64" />
</simpleType>
ASN.1 Definition
RawData ::= OCTET STRING
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 20]
Internet-Draft LTAP June 2006
4.6. DataOrTransaction
This choice type is used to identify data by:
o themselves
o an artifact identifying a transaction
o a data identifier
XML Schema
<complexType name="DataOrTransaction">
<choice>
<element ref="RawData" / >
<element ref="Artifact" />
<element name="DataReference" type="anyURI" />
</choice>
</complexType>
ASN.1 Definition
DataOrTransaction::= CHOICE {
raw RawData ,
artifact Artifact ,
datareference UTF8STRING
}
4.7. Data
This type is used to describe data together with metadata.
XML Schema
<complexType name="Data">
<sequence>
<element ref="DataOrTransaction" / >
<element ref="MetaData" />
<element ref="MessageDigest />
</sequence>
</complexType>
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 21]
Internet-Draft LTAP June 2006
ASN.1 Definition
Data ::= SEQUENCE {
dataorid DataOrTransaction ,
metaData ,
messageDigest MessageDigest ,
}
4.8. SerialNumber
Serial numbers are used to identify requests and responses. They are
represented as integers. Servers MAY add an additional verifyable
structure to identifiers, e.g. checksum digits, in order to avoid
copying errors in long term applications with potential media break.
XML Schema
<simpleType name="SerialNumber">
<restriction base="integer" />
</simpleType>
ASN.1 Definition
SerialNumber ::= Integer
4.9. RequestTime
Clients and servers can add an indication of (its idea of) the time
when a request or response was created. A time value is represented
as string representation of the content of the ASN.1 type
GENERALIZEDTIME permitted to be encoded in ASN.1 distinguished
encodeing rules (DER).
XML Schema
<simpleType name="RequestTime">
<restriction base="xs:dateTime">
<pattern
value="[\-]{0,1}\d{4}\-\d{2}\-\d{2}T\d{2}:\d{2}:\d{2}.\d{3}Z"/>
<restriction>
</simpleType>
ASN.1 Definition
Time ::= GENERALIZEDTIME
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 22]
Internet-Draft LTAP June 2006
4.10. Version
Version is used in requests and responses to indicate the protocol
version used. This specification is provided for two values:
o v0 - This version should be used by implementation that want to
experiment with draft version of this specification.
o v1 - this version is used to indicate that the request and
response corresponds to this specification.
TBD: The purpose of verison identifier.
XML Schema
<simpleType name="Version">
<restriction base="NMTOKEN">
<enumeration value="v0"/>
<enumeration value="v1"/>
</restriction>
</simpleType>
ASN.1 Definition
Version ::= ENUMERATED {v0(0), v1(1), ... };
4.11. EntityIdentifier
Entity identifiers are used in the protocol to indicate the
participating entities. A client can indicate one or more
identifiers indicating who is making the request or participating in
its creation and one or more identifiers indicating who should
perform the service. A server can indidate who has provided the
service and who is the indented client.
It MUST be ensured in some way that in an actual context of a client/
server network names are scalable and global both in terms of actual
community space and time to live of the treated data objects.
Since identifiers can be derived from various external layers an
appropriate structure in ASN.1 or XML structure is used.
XML Schema
<simpleType name="EntityIdentifier">
<restriction base="string">
</restriction>
</simpleType>
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 23]
Internet-Draft LTAP June 2006
ASN.1 Definition
Entityidentifier ::= GeneralName
4.12. ServiceType
This types is an enumeration of the different operations accessible
by the protocol. This element provides an explicit general protocol
element to indicate the intended class of operation which may not
explicitely be available otherwise with policy information.
TBA: ASN.1 and XML structure need redefintion.
XML Schema
<simpleType name="ServiceType">
<restriction base="NMTOKEN">
<enumeration value="archive" />
<enumeration value="status" />
<enumeration value="verify" />
<enumeration value="export" />
<enumeration value="delete" />
</restriction>
</simpleType>
ASN.1 Definition
ServiceType ::=
ENUMERATED {archive , status, verify , export, delete };
4.13. Status
Status information: Servers indicate some details of the outcome of
the request in form of a status information.
Temporary: We are current reusing the PKIStatusInfo for this until we
discover that this is inappropriate
Status information are mapped to a PKIStatusInfo structure to convey
status information. It MUST contain a status field and MAY contain
statusString containung a textual description of the status. It MUST
contain a failInfo if the status differs from granted. This
structure can be used to indicate a per archived data object status
when used in a submission response or can be used to convey failure
information for all types of requests.
The protocol actually only use the values granted, grantedWithMods,
rejection, waiting in a status field of a PKIStatusInfo.
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 24]
Internet-Draft LTAP June 2006
TBA: XML and ASN.1 structure.
XML Schema
ASN.1 Definition
4.14. RequestInformation
This data structure comprises information about the request others
that the raw data and metadata.
TBA: ASN.1 and XML Structure to be redefined.
XML Schema
<complexType name="RequestInformation">
<sequence>
<element name="Version" type="xs:int" fixed="1" />
<element name="Nonce" minOccurs="0" />
<element name="SerialNumber" type="xs:long" minOccurs="0" />
<element name="RequestTime"/>
<element name="RequestEntityIdentifier" />
<element name="ServerEntityIdentifier" />
<element name="ServiceType" minOccurs="1" maxOccurs="1"/>
<element name="ServicePolicyInformation"
minOccurs="0" maxOccurs="1">
<element name="ServiceConfiguration" minOccurs="0" />
</sequence>
</complexType>
ASN.1 Definition
RequestInformation ::= SEQUENCE {
version Version DEFAULT v1 ,
nonce Nonce OPTIONAL,
serial SerialNumber OPTIONAL,
service ServiceType,
time RequestTime OPTIONAL,
requester SEQUENCE OF RequestEntityIdentifier OPTIONAL,
server SEQUENCE OF RequestEntityIdentifier OPTIONAL,
policies PolicyIdentifier REQUIRED
}
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 25]
Internet-Draft LTAP June 2006
4.15. Request
This data structure describes a request made by a client. It
contains a RequestInformation data structure, as well as data or data
references. At least one of the Data and MessageDigest elements must
be provided.
XML Schema
<complexType name="Request">
<sequence>
<element name="RequestInformation" minOccurs="1" />
<element name="Data" />
</sequence>
</complexType>
ASN.1 Definition
Request::= SEQUENCE {
requestInformation RequestInformation,
theData SEQUENCE OF Data OPTIONAL ,
}
4.16. ErrorNotice
A server may return a general error notice indicating an important
failure with referencing the request. This may occur for example
when the request cannot be decoded, or also as a simulated response
returned from the client lower layers when a connection cannot be
established.
XML Schema
<complexType>
<element name="ErrorNotice" minOccurs="0">
<sequence>
<element name="ErrorIdentification" type="xs:int"/>
<element name="ErrorInformation" type="xs:string"/>
</sequence>
</element>
</complexType>
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 26]
Internet-Draft LTAP June 2006
ASN.1 Definition
ErrorNotice::= SEQUENCE {
errorIdentification INTEGER,
errorInformation BIT STIRNG,
}
4.17. OperationResponse
This structure is returned on a successful or unsuccessful operation
of the service. It references the initial request as well as the
data that had been submitted.
XML Schema
<complexType name="OperationResponse">
<sequence>
<element name="RequestInformation" />
<element name="Data" />
<element name="ServiceInformation" />
</sequence>
</complexType>
ASN.1 Definition
Response::= SEQUENCE {
requestInformation RequestInformation ,
data SEQUENCE OF Data ,
serviceInformation ServiceInformation OPTIONAL,
}
4.18. Response
This structure is returned on a successful or unsuccessful operation
of the service.
XML Schema
<complexType>
<choice>
<element name="OperationResponse" >
<element name="ErrorNotice" >
</choice>
</complexType>
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 27]
Internet-Draft LTAP June 2006
ASN.1 Definition
Response::= CHOICE {
response OperationResponse ,
error [0] ErrorNotice
}
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 28]
Internet-Draft LTAP June 2006
5. Service Operations
This section describes in detail the different operations that a
client can initiate with a request and their outcomes. All
operations share the same data types for the input and output but the
choices are filled in differently. Note that the STATUS operation
comes in two
5.1. Requests
Depending on the operation, the client fills the necessary parameters
and adds the following global information:
o List of what to fill in requestinformation.
5.2. Response
For all operations, the archive service may return different types of
responses:
o Error - The request is not understood.
o Rejection - The request is rejected. an OperationResponse
describing the error is returned.
o Acceptance - The request is accepted, an OperationResponse
containing and artifact that identifies the transaction is
returned.
o Result - The request is accepted, an OperationResponse containing
the result of the transaction is returned.
The artifact identifying a transaction can be used in a STATUS
operation to poll the outcome of the transaction.
5.3. ARCHIVE operation
The major operation of the archive service is the ARCHIVE operation.
A client prepares the data and associated metadata, and transfers the
request to the archive service
When service returns acknowledgement only as an asynchronous
notification, either the client has to perform a STATUS operation to
determine the final outcome, or service pools client with service
result status
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 29]
Internet-Draft LTAP June 2006
5.3.1. Request
Client builds request with request information including service
policy interpreting service characteristics and service configuration
parameters. Data to be archived and meta data are enclosed.
o the service type is set to "archive"
o The data are filled in with a rawData.
5.3.2. Response
As a result the server responds with acknowledgement including
service identification and data identification (artifact and/or
message imprint is included) or service error. Server may also
include service result.
5.4. STATUS operation
A client can request the status of an operation or a data object.
5.4.1. Request
If the request is for a actual status of a transaction, the client
takes the initial request and replaces the data by the artifact
returned for a previous request. If the request is for a data
object, the request is prepared as follows.
o The service type is set to "status".
o The data are referenced using a data reference or message imprint.
o ...
5.4.2. Response
If the service type was not "status", the server responds with a
response corresponding to the operation. If the service type is
status, the server returns the current metadata of the object.
5.5. EXPORT operation
This operation allows a client to change the archival status of an
object. The new status must be predefined by the server and
represeented by a policy and configuration. Examples are the
transfer to another service provider or to another archival storage
to extend the lifetime, or to return data to the requestor. In case
of a transfer to another server, or when the lifetime is changed, the
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 30]
Internet-Draft LTAP June 2006
server remembers the change until the end of the initial lifetime,
and can redirect a client to the new storage. This operation may
also have asynchronous nature (e.g. data shredding which may require
a timeframe to perform.
5.5.1. Request
Client builds modify request with request information including
service policy, data identification and modify instructions. Data
identification must be a data reference or message imprint.
The service type is set to "export".
5.5.2. Response
Server performs requested operation and returns data and metadata of
the object.
5.6. VERIFY operation
This operation allows a client to verify the authenticity of
information stored in the archive.
5.6.1. Request
Client builds verify request with request information including
service policy and data identification. Data identification may
include data itself or data reference or message imprint.
The service type is set to "verify".
5.6.2. Response
Server performs requested operation and returns service response.
The response may include data structures of supporting services
responses (e.g. signature validation response delivered by DVCS
service.
5.7. DELETE operation
This operation allows a client to delete data or request data
shredding. After a successful operation, the the server does not
maintain any status information about the object. Note that this
does not mean that the server does not maintain a trace record of the
delete operation.
The service type is set to "delete".
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 31]
Internet-Draft LTAP June 2006
The metadata may be set to replace the existing metadata of the
object.
5.7.1. Request
Client builds delete request with request information including
service policy and data identification. Data identification must
include data itself or data reference or message imprint.
5.7.2. Response
Server performs the requested operation and returns a service
response. The response must include data representation (message
imprint at least).
5.7.3. Delete
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 32]
Internet-Draft LTAP June 2006
6. Presentation and Bindings
In the previous chapters we have presented all basic data types as
well as XSD schema as in with ASN.1. This is done in order to allow
implentations work on both data syntaxes and to be able to present
and transform messages in a defined way.
TBD: Complete data structures.
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 33]
Internet-Draft LTAP June 2006
7. Security and Transport
TBD: This chapter needs rework.
TBD: LTAP requests may include security parameters in meta
information section.
TBD: Security may be provided using lower layers, e.g. XML Security
for XML syntax based requests/responses.
The protocol consists of the exchange of data objects encoded as
different CMS content types, i.e. requests and responses. These data
are optionally encapsulated by CMS content types that provide for
authentication and/or confidentiality, e.g. SignedData or
EnvelopedData.
This document describes the usage of a SignedData construct of
[RFC3852], where the content type indicated in the eContentType of
the encapContentInfo is one of the LTAP content types and the
eContent of the encapContentInfo, carried as an octet string
containing an encoded request or response structure.
When using a SignedData structure for authentication, an LTAP request
and response MAY contain one or more SignerInfo structures, each of
which may contain countersignature attributes depending on
operational environments. When an end user client creates a request,
there is one SignerInfo. A relaying LTA MAY add an additional
signature or a countersignature attribute.
Clients and relays MUST ensure authenticity of a server when
submitting data. In order to do so, they MAY add another
encapsulation from [RFC3852] that provides for confidentiality,
and/or MAY use a secure transport layer, e.g., TLS to perform server
authentication and to ensure confidentiality of the transport.
Responses are generally protected in similar way by using a
SignedData encapsulation with one or more SignerInfos, and
CounterSignatures, depending on the number of participating servers.
The number of signatures is not related to the number of
participating servers but rather to the number of entities that may
be used to authenticate a response or part of it.
In some circumstances, a client/server communication may be secured
only by lower layer transport mechanism, e.g. SSL/TLS.
A client MUST NOT trust a response that cannot be authenticated.
Archive clients and servers MUST always create requests and responses
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 34]
Internet-Draft LTAP June 2006
that can be authenticated with the explicit exception of a global
error status, which may be returned as a non-signed response.
There is no mandatory transport mechanism in this document. All
mechanisms are optional. Two examples of transport protocols are
given that allow online exchange of request and a response, and
asynchronous communication between a client and an LTA. A LTA MAY
use a combination of protocols, for example in order to return
additional responses.
Protocol via HTTP or HTTPS: This subsection specifies means for
conveying ASN.1-encoded messages for the LTAP protocol exchanges via
the HyperText Transfer Protocol. The DER encoded LTAP requests and
responses are encapsulated using a simple MIME object with Content-
Type application/ltans (and with the default binary encoding). This
MIME object can be sent and received using common HTTP or HTTPS
processing engines and provides a simple client-server transport for
ltans requests and responses.
A server MUST understand an HTTP 1.1 request together with chunked
input of a POST request. A server SHOULD understand a Content-
Encoding value of gzip. In case of a HTTP 1.0 request and response,
a positive value Content-Length indicating the total size of the data
MUST be used. A clienst SHOULD send a Host header in the request. A
client MUST be able to react to the following status codes: TBC
Protocol using Email: This section specifies a means for conveying
ASN.1-encoded messages for the protocol exchanges described via
Internet mail. The DER encoded LTAP requests and responses are
encapsulated using a simple MIME object with Content-Type
application/ltans with an appropriate Content-Transfer-Encoding.
This MIME object can be sent and received using MIME processing
engines and provides a simple Internet mail transport for LTAP
responses.
In order to be able to associate a possible error response with a
request, the requester SHOULD use the field 'transactionIdentifier'.
The requester SHOULD not make any assumption about the usage of
message header fields by the responding service, in particular the
usage of fields like Subject, Message-ID or References.
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 35]
Internet-Draft LTAP June 2006
8. Security Considerations
This section discusses addition security considerations of the
framework.
When designing an LTA service, the following considerations have been
identified that have an impact upon the validity or "trust" in the
ltans server responses.
The protocol assumes that data is preserved via periodic execution of
VERIFY operations intended to ensure data with demonstrable integrity
is available throughout the lifetime of an archived data object. The
rate of refresh will be driven by a number of factors, some of which
have a direct impact of demonstration of integrity. For example, the
confidence in the strength of cryptographic algorithms is a factor in
determining when a refresh operation should be performed.
Depending on the lifetime and the quality of data, relying on
cryptographic protection of data object may not be a sufficient means
to determine authenticity in time, other means may be required, e.g.
physical protection of data storage material.
It is imperative that keys used to sign responses are guarded with
proper security and controls in order to minimize the possibility of
compromise. Nevertheless, in case the private key does become
compromised, an audit trail of all the response generated by the
service SHOULD be kept as a means to help discriminate between
genuine and false responses. A LTA MAY provide for a service to
validate responses created by this service or another one solely
based on the audit trail.
As already indicated, when confidentiality and server authentication
is required, requests and responses MAY be protected using
appropriate mechanisms (e.g., CMS encapsulation [RFC3369] or TLS
[RFC3546]).
Server authentication is highly recommended for all service which
transfer data to a server.
Client identification and authentication MAY use services defined by
TLS [RFC3546] ) instead of, or in addition to, using a document or
message protection format, e.g. CMS.
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 36]
Internet-Draft LTAP June 2006
9. IPR Patent Information
The material presented in this document was initially drafted in
2005.
The following United States Patents related to data validation and
certification services, listed in chronological order, are known by
the authors to exist at this time. This may not be an exhaustive
list. Other patents may exist or be issued at any time.
Implementers of this protocol and applications using the protocol
SHOULD perform their own patent search and determine whether or not
any encumberences exist on their implementation. The current list is
taken from [RFC3029].
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 37]
Internet-Draft LTAP June 2006
# 4,309,569 Method of Providing Digital Signatures
(issued) January 5, 1982
(inventor) Ralph C. Merkle
(assignee) The Board of Trustees of the Leland Stanford Junior
University
# 5,001,752 Public/Key Date-Time Notary Facility
(issued) March 19, 1991
(inventor) Addison M. Fischer
# 5,022,080 Electronic Notary
(issued) June 4, 1991
(inventors) Robert T. Durst, Kevin D. Hunter
# 5,136,643 Public/Key Date-Time Notary Facility
(issued) August 4, 1992
(inventor) Addison M. Fischer
(Note: This is a continuation of patent # 5,001,752.)
# 5,136,646 Digital Document Time-Stamping with Catenate Certificate
(issued) August 4, 1992
(inventors) Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Bell Communications Research, Inc.,
# 5,136,647 Method for Secure Time-Stamping of Digital Documents
(issued) August 4, 1992
(inventors) Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Bell Communications Research, Inc.,
# 5,373,561 Method of Extending the Validity of a Cryptographic
Certificate
(issued) December 13, 1994
(inventors) Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Bell Communications Research, Inc.,
# 5,422,95 Personal Date/Time Notary Device
(issued) June 6, 1995
(inventor) Addison M. Fischer
# 5,781,629 Digital Document Authentication System
(issued) July 14, 1998
(inventor) Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Surety Technologies, Inc.,
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 38]
Internet-Draft LTAP June 2006
10. ASN.1 module
The following ASN.1 module has been checked using the asn1c tool.
LTANS_LTAP
--OID TBD
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL maybe not --
END
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 39]
Internet-Draft LTAP June 2006
11. XML schema
<!-- to be done -->
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 40]
Internet-Draft LTAP June 2006
12. IANA consideration
None.
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 41]
Internet-Draft LTAP June 2006
13. References
13.1. Normative references
[I-D.ietf-ltans-ers]
Brandner, R., "Evidence Record Syntax (ERS)",
draft-ietf-ltans-ers-07 (work in progress), May 2006.
[I-D.ietf-ltans-reqs]
Wallace, C., "Long-Term Archive Service Requirements",
draft-ietf-ltans-reqs-07 (work in progress), May 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3369] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3369, August 2002.
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.
13.2. Informative references
[RFC3029] Adams, C., Sylvester, P., Zolotarev, M., and R.
Zuccherato, "Internet X.509 Public Key Infrastructure Data
Validation and Certification Server Protocols", RFC 3029,
February 2001.
[RFC4491] Leontiev, S. and D. Shefanovski, "Using the GOST R
34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
Algorithms with the Internet X.509 Public Key
Infrastructure Certificate and CRL Profile", RFC 4491,
May 2006.
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 42]
Internet-Draft LTAP June 2006
Authors' Addresses
Aleksej Jerman Blazic
SETCCE
Jamova 39
Ljubljana SI-1000
SLOVENIA
Fax: +386 1 4773861
Email: aljosa@setcce.org
Peter Sylvester
EdelWeb SAS - Groupe ON-X
15 quai de Dion-Bouton
Puteaux F-92816
FRANCE
Fax: +33 1 40 99 14 14
Email: Peter.Sylvester@edelweb.fr
Carl Wallace
Orion Security Solutions
Suite 300
1489 Chain Bridge Road
McLean, VA 22101
Fax: +1 703 9170260
Email: cwallace@orionsec.com
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 43]
Internet-Draft LTAP June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jerman Blazic & Sylvester & Wallace Expires December 28, 2006 [Page 44]
