LTANS A. Jerman-Blazic
Internet-Draft Setcce
Expires: January 18, 2006 P. Sylvester
EdelWeb SA - Groupe ON-X
C. Wallace
Orion Security Solutions
July 17, 2005
Long-term Archive Protocol (LTAP)
draft-ietf-ltans-ltap-00.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 January 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a service operated as a trusted third party
to securely archive electronic document called Trusted Archive
Authority. We describe a 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, et al. Expires January 18, 2006 [Page 1]
Internet-Draft LTAP July 2005
Attention: This version 0 document has been submitted in order to
meet IETF deadlines. An updated is expected very soon.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Operation of TAA . . . . . . . . . . . . . . . . . . . . . . . 8
4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Functional Overview . . . . . . . . . . . . . . . . . . . 9
4.2 Transactions . . . . . . . . . . . . . . . . . . . . . . . 9
4.3 Roles, Service Types, Policies and Configurations . . . . 10
4.4 Entities . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4.1 Entity Identifiers . . . . . . . . . . . . . . . . . . 12
4.4.2 Attributes . . . . . . . . . . . . . . . . . . . . . . 13
4.5 Data Model . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5.1 Data objects . . . . . . . . . . . . . . . . . . . . . 13
4.5.2 Collection objects . . . . . . . . . . . . . . . . . . 14
4.5.3 MetaData . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.4 Binding Information . . . . . . . . . . . . . . . . . 14
4.5.5 Evidence Data . . . . . . . . . . . . . . . . . . . . 14
5. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1 Artifacts . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2 Message Imprint . . . . . . . . . . . . . . . . . . . . . 15
5.3 MetaData . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4 Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.5 Artifact . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.6 RawData . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.7 SerialNumber . . . . . . . . . . . . . . . . . . . . . . . 17
5.8 Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.9 Version . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.10 EntityIdentifier . . . . . . . . . . . . . . . . . . . . . 19
5.11 ServiceType . . . . . . . . . . . . . . . . . . . . . . . 20
5.12 StatusInfo . . . . . . . . . . . . . . . . . . . . . . . . 20
5.13 RequestInformation . . . . . . . . . . . . . . . . . . . . 21
5.14 Request . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.15 ErrorNotice . . . . . . . . . . . . . . . . . . . . . . . 22
5.16 Response . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Archive Operations . . . . . . . . . . . . . . . . . . . . . . 24
6.1 SUBMIT operation . . . . . . . . . . . . . . . . . . . . . 24
6.1.1 Request . . . . . . . . . . . . . . . . . . . . . . . 24
6.2 STATUS operation . . . . . . . . . . . . . . . . . . . . . 24
6.2.1 Request . . . . . . . . . . . . . . . . . . . . . . . 24
6.3 MODIFY operation . . . . . . . . . . . . . . . . . . . . . 24
6.3.1 Request . . . . . . . . . . . . . . . . . . . . . . . 24
6.4 VERIFY operation . . . . . . . . . . . . . . . . . . . . . 24
6.4.1 Request . . . . . . . . . . . . . . . . . . . . . . . 24
6.5 DELETE operation . . . . . . . . . . . . . . . . . . . . . 24
Jerman-Blazic, et al. Expires January 18, 2006 [Page 2]
Internet-Draft LTAP July 2005
6.5.1 Request . . . . . . . . . . . . . . . . . . . . . . . 25
7. Presentation and Bindings . . . . . . . . . . . . . . . . . . 26
8. Security and Transport . . . . . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10. Patent Information . . . . . . . . . . . . . . . . . . . . . 30
11. ASN.1 module . . . . . . . . . . . . . . . . . . . . . . . . 32
12. XML schema . . . . . . . . . . . . . . . . . . . . . . . . . 33
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . 35
Jerman-Blazic, et al. Expires January 18, 2006 [Page 3]
Internet-Draft LTAP July 2005
1. Introduction
In all contexts of documents, conservation plays an important role,
or the definition of the word document itself is strongly related to
its conservation. Conservation has several aspect, e.g. duration or
accessibility, i.e. as a function of the nature of the document, it
must be conserved for a certain time (and maybe must be destroyed
after that), or, the access to a document is public or restricted to
a small set of potentially interested or authorized entities.
This document is based on concept of specialized service for
conservation of electronic documents. The service creates and
delivers enough information for demonstration of electronic document
existence, integrity and authenticity over any period of time. Or in
other words, the service assures the responsibility to create and
store evidence and/or receive and store data, to guarantee their
integrity and completeness, and to maintain accessibility of data and
evidence created.
This document describes a protocol for interacting with a Trusted
Archive Authority (TAA). The document contains only description of a
general request and response structure, and a detailed protocol
description concerning access to a TAA. Other specifications and
descriptions, e.g. a framework protocol containing mappings to
transport and security services, are taken out of the document. The
protocol is intended to be used in client-server architecture, where
client is simply presented as an end user (a physical user or another
service) and server as a TAA.
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 (TAA) acts as a
trusted third party for those two entities. The main role of a TAA
is to generate and provide enough information for archived data
existence in time, integrity and authenticity demonstration over long
periods of time. Provision of data storage services is optional and
assured by supportive infrastructure (e.g. database or document
Jerman-Blazic, et al. Expires January 18, 2006 [Page 4]
Internet-Draft LTAP July 2005
storage/management system).
Temporary note: This document does not (yet) contain a concrete
binding to lower layers. The authors have not decided whether this
should better go into at least on separate document. Nevertheless,
there are some general guidelines. Data should be codable in various
forms, a description should be available in XSD and ASN1 (this is
almost an automatic process). Different signature formats should be
possible, XML-DSIG, CMS). Transport should be possible over http/
soap and others.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED" and "MAY" in this document are to be interpreted as
described in [RFC2119].
Jerman-Blazic, et al. Expires January 18, 2006 [Page 5]
Internet-Draft LTAP July 2005
2. Background
The conservation service (TAA) consists of several functional/
technology blocks. Some of these blocks are not considered by LTANS
as they present the basic infrastructure, like communication network,
storage device, etc. Instead, the TAA implements archive interaction
protocol as defined by this specification (LTAP), archive objects
(logically interpreted as packages of archive data and conservation
attributes) and evidence syntax (defined within ERS specification).
Archive objects are the central logical structures defined by the TAA
and maintained on the long-term basis. They are atomic elements of
the TAA service consisting of three elements. The logical structure
of archive objects defines:
o Archive data entering the TAA using interaction protocol,
o Archive process related meta or binding information and
o Evidence information
The archive data may contain any data type, namely raw data, signed
data, encrypted data or time stamped data as defined by LTANS
requirements. Archive data may be associated with some additional
data or bindings (attributes). Such attributes may come as e.g. meta
information or digital signatures.
Data generated or collected by the TAA are mainly archive process
related meta or binding information. Such information is needed to
provide enough information for e.g. special (legal) purposes or (e.g.
digital signature) validity demonstration purposes. The TAA collects
meta or binding information directly form a user or an archive data
or some other resource. Such information may contain author 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 TAA may use external resources to collect such
information usually without user intervention. Evidence data is
generated by the TAA or collected form external resource, e.g. time
stamping authority. Evidence information is provided for all data:
archive data submitted by a client and archive process related data
collected by the TAA from the client or alternative resource.
The TAA maintains 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.
Jerman-Blazic, et al. Expires January 18, 2006 [Page 6]
Internet-Draft LTAP July 2005
Archive objects may be part of another archive objects and are
periodically processed to provide long term stability (e.g. time
stamp renewal).
The LTAP protocol holds interprets the logical data structure to hold
all needed information (including references) to build an archive
project including archive data itself (or reference to archive data).
Logical structure of the LTAP messages includes archive data,
archiving process related data and references together with request
and processing information. Using LTAP protocol the TAA should have
enough information to build and perform operations on an archive
object(s).
Jerman-Blazic, et al. Expires January 18, 2006 [Page 7]
Internet-Draft LTAP July 2005
3. Operation of TAA
A TAA, 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.
The TAA interface must therefore enable clients to:
o submit data to the TAA (and request creation of evidence records
for data) - the ARCHIVE service
o check status of submitted data - the STATUS function
o extract, transfer or simply retrieve data (archive data and
evidence data) from the TAA - the EXPORT service
o delete data and/or evidence records from a TAA - the DELETE
function
o verify the integrity and authenticity of data archived by TAA -
the VERIFY function
The primary aim of this protocol is to enable a formal interaction
between a user and a TAA. Result of the interaction is the
attestation of procedures performed by TAA (e.g. archive data). 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 document also doesn't deal with
data structures of archive objects (AO). However, it includes
elements, which are introduced in AO (e.g. message imprints).
Jerman-Blazic, et al. Expires January 18, 2006 [Page 8]
Internet-Draft LTAP July 2005
4. Framework
This chapter describes a general framework for secure exchange of
request and response messages between an archive client and archive
server, e.g. a TAA. It provides a high level outline and identifies
common and external aspects from the concrete protocol data units.
4.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 a TAA ensures the long term availability of stored
data, and uses an appropriately manages data and access rights.
These important features of a TAA 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 data, request information,
metainformation, identification information and attestations.
Requests and responses are exchanged between 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 TAA is not a method to implement something like a secure file
system. In general, archived data are rarely accessed, restored or
transferred. Thus, the archive operation is is the most important
one and performance is a important concern.
4.2 Transactions
The model for the exchange of LTAP requests and responses is borrowed
from ebXML. (referece to add.) The exchanges for LTAP are
concepually asynchronous. An LTAP exchange consists of sending a
request and two different types of responses. The first response is
a technical acknowledge from the TAA that the request has been
received. The second is a statement from a TAA 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 TAA.
Jerman-Blazic, et al. Expires January 18, 2006 [Page 9]
Internet-Draft LTAP July 2005
A TAA is assumed to perform an operation with a best effort.
Nevertheless, it is allowed that an operation can fail or totally
lost. The possibility to delever the result attestation in a
asynchronous way is to allow cost effective implementations of the
TAA. A client SHOULD be able to recover from lost requests, i.e.,
not delete data before having received the attestation.
Until the receipt of the technical acknowledge, a client can repeat
an operation, since the request or the response might have been lost.
The client can provide a unqiue identification for the request in a
which SHOULD be used by the TAA to ensure idempotence of
transactions.
After receipt of the technical acknowledge, the client can use a
IDENTIFY operation to determine 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.
4.3 Roles, Service Types, Policies and Configurations
The protocol assumes a number of different actors playing different
roles. The basic roles used 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 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, and an entity that accepts data and assures
responsibility of archived data. Other entities serving as a lower
layer transport 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 TAA interface must therefore enable clients to perform the
following service types.
o submit data to the TAA (and request creation of evidence records
for data) - the ARCHIVE operation
o check status of submitted data - the IDENTIFY operation
Jerman-Blazic, et al. Expires January 18, 2006 [Page 10]
Internet-Draft LTAP July 2005
o extract, transfer, or modify lifetime data (archive data and
evidence data) from the TAA - the MODIFY operation
o verify the integrity and authenticity of data archived by TAA -
the VERIFY operation
o delete data and/or evidence records from a TAA - the DELETE
operation
A client implementations 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 invloked by different
entities in totally different environments.
As already mentioned above, depending on the lower layer transport
bindings, a client may be required to have implemented the IDENTIFY
service type in order to retrieve the outcome of another operation.
The way how a particular operation is performed is only defined at
the TAA server side implementation and can be influenced by policy
information parametres. 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 TAA. The goal of policy
identifiers is to have client configurations simple.
TAA service may provide additional features (categories) of how a
service type is performed, which are identified by clients. Features
define the nature of e.g. archiving proceduresn. TAA might offer a
series of features based on quality characteristics, e.g. number of
timestamps used. Protocol specification builds on assumption that
features are clearly identifiable and therefore included in the
protocol elements. Examples are quality of service features like a
premium type that assures prompt and instant archive procedure or
less advanced (e.g. standard) service that handles queues and
generates evidence data periodically based on data grouping (one
timestamp per 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.
The operation of a TAA may use be external services, like validation
and evidence creation services. Another service is provision of
physical infrastructure or storage systems. Such entities can also
be referenced by service policy identifiers.
A server may also operate different configurations. In general, for
each client, in particular those that are archiving, a default or
Jerman-Blazic, et al. Expires January 18, 2006 [Page 11]
Internet-Draft LTAP July 2005
single possible configuration is defined at the server in order to
group features and policies into defined sets. From the protocol
standpoint, configurations and
As a last mechanism to provide parameters to the archive server are
configuration parameters which allow to transfere arbitary key/value
pairs from the client to the server.
In, principle a single sequence of policy information, would be
sufficient to also both indicate the service type and configuration.
But we have chosen to use a multi-dimensional approach with
configuration and service types.
This document defines no particular policy or configuration.
4.4 Entities
Entities that participate 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.
To be discussed: We do not explicitely distinguish between technical
roles like 'client, 'server', 'relay', 'proxy', 'authorized agent' or
else.
The explicit usage of identifiers and attributes allows to make the
decisions more 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.T hese information can be
added to protocol elements as trace attributes.
4.4.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
Jerman-Blazic, et al. Expires January 18, 2006 [Page 12]
Internet-Draft LTAP July 2005
community space and time to live of the treated data objects.
Identifiers are labeled in some way, i.e. string represenations are
typed. can be derived from various external layers, an appropriate
structure the ASN.1 definition of GeneralName.
4.4.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.
4.5 Data Model
The data fields of a LTAP request are as follows:
o request information or status information
o raw data or references
o metadata providing additional information about the raw data
o authorisation and authentication information of the entities
paticipating in the procedure
o other information, required for supporting function like billing
or changing
4.5.1 Data objects
The data to be archived are arbitrary binary data and at least an
associated type which must be either available as part of a server
configuration policy or explicitely 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., like an EAN with a checksum, in
order to avoid 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.
Jerman-Blazic, et al. Expires January 18, 2006 [Page 13]
Internet-Draft LTAP July 2005
Servers MUST create a (server wide) unique identifier for each stored
object that MUST be global during the intended lifetime of an object
(which may be extendable).
Clients may provide their own identifiers in requests. Whether the
client provided identifiers are unique, is outside the scope of the
protocol, the servers treat these identifiers as opaque information.
In order to identify data for the short lifespan of a transaction,
artificats can be use to reference data or transactions.
4.5.2 Collection objects
Collections of data can be defined explicitely or implicitely. A
document is added to a collection by adding a collection identifier.
A collection identifier is initialliy local to an object. Adding
another object to a collection requires the identification of the
initial object and the identification of one object in the
collection.
temporary note: This section needs work. Some items to be covered:
grouping of items by time, location, or customers, referencing of
groups in operations instead of individual objects
4.5.3 MetaData
To be done
4.5.4 Binding Information
To be done
4.5.5 Evidence Data
To be done
Jerman-Blazic, et al. Expires January 18, 2006 [Page 14]
Internet-Draft LTAP July 2005
5. 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
5.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 or
progress of a transaction later by the initial client or another
authorised entity.
Artifacts are represented by artifacts from SAML.
5.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 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.
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 Schema
Jerman-Blazic, et al. Expires January 18, 2006 [Page 15]
Internet-Draft LTAP July 2005
ASN.1 Definition
5.3 MetaData
Metadata are key/value pairs giving addtional information about
entities or data.
To be done: To discuss whether metadata are defined via xml
constructs and oid/value pairs, or as as simple data type using a key
and a string value. The ASN.1 needs to be adjusted.
XML Schema
<complexType name="Metadata">
<choice minOccurs="1" maxOccurs="1">
<element name="value" type="string" />
</choice>
<attribute name="type" type="string" use="required" />
</complexType>
ASN.1 Definition
Metadata ::= SEQUENCE {
type UTF8String ,
value UTF8String OPTIONAL
}
5.4 Nonce
A Nonce is an octetstring used in security information to protect
against replays.
XML Schema
<simpleType name="Nonce">
<restriction base="hexBinary">
</restriction>
</simpleType>
Jerman-Blazic, et al. Expires January 18, 2006 [Page 16]
Internet-Draft LTAP July 2005
ASN.1 Definition
Nonce ::= OCTET STRING
5.5 Artifact
An artifact is an octetstring used in security information to protect
against replays.
XML Schema
<simpleType name="Nonce">
<restriction base="hexBinary">
</restriction>
</simpleType>
ASN.1 Definition
Nonce ::= OCTET STRING
5.6 RawData
This data structure carries binary data to be archived, verified or
returned.
XML Schema
<simpleType name="RawData">
<restriction base="base64Binary">
</restriction>
</simpleType>
ASN.1 Definition
RawData ::= [BASE64] OCTET STRING
5.7 SerialNumber
Serial numbers are used to identify requests and responses. They are
represen ted as integers. Servers MAY add an additional verifyable
Jerman-Blazic, et al. Expires January 18, 2006 [Page 17]
Internet-Draft LTAP July 2005
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
5.8 Time
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="Time">
<restriction base="normalizedString">
<pattern value="a pattern for generalizeddtime constraints" />
</restriction>
</simpleType>
ASN.1 Definition
Time ::= GENERALIZEDTIME
5.9 Version
Version are used in requests and responses to indicate the protocol
version used. This specifications provided for two values:
o v0 - This version should be used by implementation that want to
experiment with draft version of this specification
Jerman-Blazic, et al. Expires January 18, 2006 [Page 18]
Internet-Draft LTAP July 2005
o v1 - this version is used to indicate that the request and
response corresponds to this specification.
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), ... };
5.10 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 the ASN.1 definition of GeneralName.
To be done: decide on which representations is better.
XML Schema
<simpleType name="EntityIdentifier">
<restriction base="string">
</restriction>
</simpleType>
Jerman-Blazic, et al. Expires January 18, 2006 [Page 19]
Internet-Draft LTAP July 2005
ASN.1 Definition
Entityidentifier ::= GeneralName
5.11 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 available otherwise with policy information.
XML Schema
<simpleType name="Version">
<restriction base="NMTOKEN">
<enumeration value="archive" />
<enumeration value="status" />
<enumeration value="verify" />
<enumeration value="modify" />
<enumeration value="delete" />
</restriction>
</simpleType>
ASN.1 Definition
Version ::= ENUMERATED {archive, status, verify, modify, delete };
5.12 StatusInfo
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.
Jerman-Blazic, et al. Expires January 18, 2006 [Page 20]
Internet-Draft LTAP July 2005
The protocol actually only use the values granted, grantedWithMods,
rejection, waiting in a status field of a PKIStatusInfo.
XML Schema
ASN.1 Definition
5.13 RequestInformation
This data structure comprises information about the request others
that the raw data and metadata.
XML Schema
<complexType name="RequestInformation">
<sequence>
<!-- to be filled in -->
<sequence />
</complexType>
ASN.1 Definition
RequestInformation ::= SEQUENCE {
version Version DEFAULT v1 ,
service ServiceType ,
nonce Nonce OPTIONAL,
serialNumber OPTIONAL,
requestTime Time OPTIONAL,
requester SEQUENCE OF RequestEntityIdentifier
SIZE[1..MAX] OPTIONAL,
server SEQUENCE OF RequestEntityIdentifier
SIZE[1..MAX] OPTIONAL,
policies SEQUENCE OF PolicyIdentifier
SIZE[1..MAX] OPTIONAL
5.14 Request
This data structure describes a request made by a client. It
contains a RequestInformation data structure, as well as data or data
references.
Jerman-Blazic, et al. Expires January 18, 2006 [Page 21]
Internet-Draft LTAP July 2005
XML Schema
<complexType name="Request">
<sequence>
<!-- to be filled in -->
<sequence />
</complexType>
ASN.1 Definition
Request ::= SEQUENCE {
requestInfo RequestInformation ,
dataspecification CHOICE {
data Rawdata,
messageImprint MessageImprint,
artifact [0] Artificat
} ,
metaData SEQUENCE OF MetaData
SIZE[1..MAX] OPTIONAL
5.15 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
ASN.1 Definition
ErrorNotice ::= StatusInformation
5.16 Response
This structure is returned on a successful operation of the service.
It references the initial request as well as the data that had been
submitted.
Jerman-Blazic, et al. Expires January 18, 2006 [Page 22]
Internet-Draft LTAP July 2005
XML Schema
ASN.1 Definition
Response ::= SEQUENCE {
version Version DEFAULT v1 ,
status Statusinformation OPTIONAL,
requestInformation Requestinformation ,
serialNumber INTEGER,
data Data,
etaData SEQUENCE OF MetaData
SIZE[1..MAX] OPTIONAL
}
Jerman-Blazic, et al. Expires January 18, 2006 [Page 23]
Internet-Draft LTAP July 2005
6. Archive Operations
This section describes in detail the different oerations that a
client can initiate with a request and their outcomes. All
operations
6.1 SUBMIT operation
The major operation of the archive service is the SUBMIT operation.
A client prepares the data and associated metadata, adds
authentication information and transfers the request to the archive
service. The archive service acknowledges the receipt of the
request. Depending on the binding and the disponibility of an
asynchronous notification channel, either the client has to perform a
STATUS operation to determine the final outcome, or
6.1.1 Request
6.2 STATUS operation
A client can request the status of an operation or a data object.
6.2.1 Request
6.3 MODIFY 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 shortened,
the server remembers the change until the end of the initial
lifetime, and can redirect a client to the new storage.
6.3.1 Request
6.4 VERIFY operation
This operation allows a client to verify the authenticity of
information stored in the archive.
6.4.1 Request
6.5 DELETE operation
This operation allows a client to delete data. After a successful
operation, the the server does not maintain any status information
Jerman-Blazic, et al. Expires January 18, 2006 [Page 24]
Internet-Draft LTAP July 2005
about the object. Note that this does not mean that the server does
not maintain a trace record of the delete operation.
6.5.1 Request
Jerman-Blazic, et al. Expires January 18, 2006 [Page 25]
Internet-Draft LTAP July 2005
7. 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.
To BE done: There is a lot more to say here about the goal.
Jerman-Blazic, et al. Expires January 18, 2006 [Page 26]
Internet-Draft LTAP July 2005
8. Security and Transport
TBD: This chapter needs rework.
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
[RFC3369], 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 TAA 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 [RFC3369] 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
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
Jerman-Blazic, et al. Expires January 18, 2006 [Page 27]
Internet-Draft LTAP July 2005
asynchronous communication between a client and a TAA. A TAA MAY use
a combination of protocols, for example in order to return additional
responses.
Protocol via HTTP or HTTPS: This subsection specifies a 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 over WWW links 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, et al. Expires January 18, 2006 [Page 28]
Internet-Draft LTAP July 2005
9. Security Considerations
This section discusses addition security considerations of the
framework.
When designing an ltans 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
operations, i.e. timestamp refresh, 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 may be required, e.g. physical
protection of dated staorage 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. An ltans 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 [RFC 2630] or TLS
[RFC2246]).
Server authentication is highly recommended for all service which
transfer data to a server.
Client identification and authentication MAY use services defined by
TLS [RFC2246]) instead of, or in addition to, using a document or
message protection format, e.g. CMS.
Jerman-Blazic, et al. Expires January 18, 2006 [Page 29]
Internet-Draft LTAP July 2005
10. Patent Information
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.
Note from Peter: Instead of listing these, I prefer to say that we
have been aware that all US patents starting with number 4,000,000 or
so ..., the current list is takenb from RFC3029.
Jerman-Blazic, et al. Expires January 18, 2006 [Page 30]
Internet-Draft LTAP July 2005
# 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, et al. Expires January 18, 2006 [Page 31]
Internet-Draft LTAP July 2005
11. 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, et al. Expires January 18, 2006 [Page 32]
Internet-Draft LTAP July 2005
12. XML schema
<!-- to be done -->
13. References
[I-D.ietf-ltans-ers]
Brandner, R., "Evidence Record Syntax (ERS)",
draft-ietf-ltans-ers-02 (work in progress), April 2005.
[I-D.ietf-ltans-reqs]
Wallace, C., "Long-Term Archive Service Requirements",
draft-ietf-ltans-reqs-03 (work in progress), October 2004.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028,
October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, August 2001.
[RFC3369] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3369, August 2002.
Jerman-Blazic, et al. Expires January 18, 2006 [Page 33]
Internet-Draft LTAP July 2005
Authors' Addresses
Aleksej Jerman-Blazic
Setcce
Jamova 39
Ljubljana SI-1000
SLOVENIA
Fax: +386 1 477 3861
Email: aljosa@setcce.org
Peter Sylvester
EdelWeb SA - Groupe ON-X
15, Quai de Dion-Bouton
Puteaux Cedex F-92816
FRANCE
Fax: +33 1 40 99 03 30
Email: Peter.Sylvester@edelweb.fr
Carl Wallace
Orion Security Solutions
Suite 300
1489 Chain Bridge Road
McLean, VA 22101
Fax: +1(703)917-0260
Email: cwallace@orionsec.com
Jerman-Blazic, et al. Expires January 18, 2006 [Page 34]
Internet-Draft LTAP July 2005
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 (2005). 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, et al. Expires January 18, 2006 [Page 35]
