LTANS A. Jerman Blazic
Internet-Draft SETCCE
Expires: January 9, 2008 P. Sylvester
EdelWeb
C. Wallace
Cygnacom Solutions
July 8, 2007
Long-term Archive Protocol (LTAP)
draft-ietf-ltans-ltap-05
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 9, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes a service operated as a trusted third party
to securely archive electronic documents 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, et al. Expires January 9, 2008 [Page 1]
Internet-Draft LTAP July 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 5
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Functional Overview . . . . . . . . . . . . . . . . . . . 7
3.2. Service functions of an LTA . . . . . . . . . . . . . . . 8
3.3. Transactions . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Life cycles of objects . . . . . . . . . . . . . . . . . . 11
3.5. Roles, Service Types, Policies and Configurations . . . . 12
3.6. Identification . . . . . . . . . . . . . . . . . . . . . . 14
3.7. External definitions . . . . . . . . . . . . . . . . . . . 15
3.8. Entities . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.9. Data Model . . . . . . . . . . . . . . . . . . . . . . . . 19
4. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2. MessageDigest . . . . . . . . . . . . . . . . . . . . . . 22
4.3. MetaData . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5. RawData . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6. DataOrTransaction . . . . . . . . . . . . . . . . . . . . 27
4.7. Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.8. SerialNumber . . . . . . . . . . . . . . . . . . . . . . . 28
4.9. LtapTime . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.10. Version . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.11. EntityIdentifier . . . . . . . . . . . . . . . . . . . . . 29
4.12. ServiceType . . . . . . . . . . . . . . . . . . . . . . . 30
4.13. StatusInformation . . . . . . . . . . . . . . . . . . . . 31
4.14. RequestInformation . . . . . . . . . . . . . . . . . . . . 32
5. Top level protocol elements . . . . . . . . . . . . . . . . . 34
5.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2. StatusNotice . . . . . . . . . . . . . . . . . . . . . . . 35
5.3. OperationResponse . . . . . . . . . . . . . . . . . . . . 35
5.4. Response . . . . . . . . . . . . . . . . . . . . . . . . . 36
6. Service Operations . . . . . . . . . . . . . . . . . . . . . . 36
6.1. ARCHIVE operation . . . . . . . . . . . . . . . . . . . . 37
6.2. EXPORT operation . . . . . . . . . . . . . . . . . . . . . 38
6.3. DELETE operation . . . . . . . . . . . . . . . . . . . . . 38
6.4. VERIFY operation . . . . . . . . . . . . . . . . . . . . . 39
6.5. STATUS operation . . . . . . . . . . . . . . . . . . . . . 39
6.6. LISTIDS operation . . . . . . . . . . . . . . . . . . . . 39
7. Presentation and Bindings . . . . . . . . . . . . . . . . . . 40
7.1. Common parameters and encoding requirements . . . . . . . 41
7.2. e-mail bindings . . . . . . . . . . . . . . . . . . . . . 43
7.3. HTTP Bindings . . . . . . . . . . . . . . . . . . . . . . 43
7.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 44
8. Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Jerman Blazic, et al. Expires January 9, 2008 [Page 2]
Internet-Draft LTAP July 2007
9. Security Considerations . . . . . . . . . . . . . . . . . . . 45
10. IPR Patent Information . . . . . . . . . . . . . . . . . . . . 46
11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 47
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
12.1. Normative references . . . . . . . . . . . . . . . . . . . 48
12.2. Informative references . . . . . . . . . . . . . . . . . . 48
Appendix A. ASN.1 module in current syntax . . . . . . . . . . . 49
Appendix B. ASN.1 module in 1988 syntax . . . . . . . . . . . . . 52
Appendix C. Additional XML definitions . . . . . . . . . . . . . 55
Appendix D. XML schema for LTAP . . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69
Intellectual Property and Copyright Statements . . . . . . . . . . 71
Jerman Blazic, et al. Expires January 9, 2008 [Page 3]
Internet-Draft LTAP July 2007
1. Introduction
Conservation of documents is important, one can even say that
appropriate conservation rules are a prerequisite for data to become
a document. Conservation has several aspects, e.g., duration or
accessibility, which 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, or its lifetime may be extended when the
document becomes part of a conflict. Also, documents may become part
of historical archives. 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 makes available 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 an 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
Jerman Blazic, et al. Expires January 9, 2008 [Page 4]
Internet-Draft LTAP July 2007
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
may be assured by supportive infrastructure (e.g. database or
document storage/management system).
Conservation is more that just storing a document. Not only, but in
particular when the life time is very long, appropriate measures to
ensure the integrity of the document must be used. This aspect is
handled by this specification. Sometimes, complete transfer of the
document information to a new physical support has to be done like
transformations from marble to paper or paper to microfilm. The need
for such transformation makes the definition of what constitutes the
actual document somewhat difficult, in particular it should be done
independantly of the support, and even independantly of a current
format of the document information. Transformation of documents are
largely the scope of this specification besides the obvious
possibility of storing all formats of a document and assertions about
the transformations.
Defined data structures are presented in XSD and ASN1 forms. The XSD
form has been automatically generated from the ASN.1. When the ASN.1
defined data structured are encoded using XER encoding rules, they
are compatible with data structures encoded according to the XSD.
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].
2. Background
A conservation service or long-term archive (LTA) consists of several
functional blocks. Some of these blocks are not considered 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.
Jerman Blazic, et al. Expires January 9, 2008 [Page 5]
Internet-Draft LTAP July 2007
[RFC4810] 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. An LTA may accept and store
data for which it generates (or acquires from another service) and
maintains evidence inforamtion. Alternatively, it may simply act as
an evidence and demonstration information servce without data storage
capabilities (it relies upon other services for storage of the
archived data). 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 metadata 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 [RFC4810].
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 metadata is needed to provide enough
information for e.g. special (i.e., legal) purposes or validity
demonstration purposes (e.g. complementary information to digital
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 using the LTAP.
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 archive objects and
Jerman Blazic, et al. Expires January 9, 2008 [Page 6]
Internet-Draft LTAP July 2007
associated metadata 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 or group of archive objects.
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
An LTA, as defined by [RFC4810], is a service that is responsible for
preserving evidence data and/or data for long periods of time. The
service is accessible using the protocol defined in this document.
The protocol is intended to be used as well as basic functionality
available to customers of a service provider, as well as an internal
protocol inside the LTA to access basic building blocks as a black
box in a standardised way. The latter usage is intended to permit
the creating of security zones and auditable implementations.
Therefore, some functions defined in the protocol may not be
available to all external customers of an LTA.
The protocol consists of two layers, the higher layer defines the
available service functions and their mapping to encodings, the lower
layer defines the rules for the exchange of protocol messages common
for all all functions.
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. The details of
these important features of an LTA are outside the scope of this
specification.
Jerman Blazic, et al. Expires January 9, 2008 [Page 7]
Internet-Draft LTAP July 2007
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 frequent 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. Service functions of an LTA
The primary aim of this protocol is to enable a formal interaction
between a client 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).
The LTA interface enables clients to perform at least the following
operations in cooperation with an LTA:
ARCHIVE: Submit data to an LTA and request creation of evidence
information for data
EXPORT: Retrieve data (including archive data, meta information and
evidence information) from an LTA
Jerman Blazic, et al. Expires January 9, 2008 [Page 8]
Internet-Draft LTAP July 2007
DELETE: Remove data and/or evidence information from an LTA.
VERIFY: Determine the integrity and validity of LTA archived data.
STATUS: Inform about the status of data.
LISTIDS: Return a list of references to archived objects.
These operations form the minimal set that MUST be implemented by an
LTA service although they may not be available to all clients.
Furthermore, there is a minimal profile for the parameter structures
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 operations are intended for different types of clients, including
archive data owners but also entities that want to audit the service
or are authorised to access to data. Thus, clients do not need to
implement all functions, e.g., a client may only implement the
ARCHIVE operation.
An LTA may propose additional services either by extending the
operations by the means of additional parameters or by defining new
operations.
For example, often an extension of the initial lifetime of an object
must be possible. To extend the lifetime of an object, an EXPORT
operation followed by an ARCHIVE operation has be used to transfer or
copy the object to an LTA service having the required lifetime
policy/configuration. At last, the initial object may be deleted or
not. The combination of such a sequence of operations into single
one is an example of an extended service provided to clients.
The LISTIDS operation was originally part of the STATUS function
where no reference to data is given. It has been separated for the
following reasons. The result of the two modes of the function is
very different. A small programming error, i.e., omission of the
reference to data has dramatic consequences. This probably means
that implementation will provide an appropriate API separating the
two functionalities. It seems useful to map this directly to the
protocol layer. The LTA MUST maintain a chronological order for
references to archived data.
3.3. Transactions
The model for the exchange of LTAP requests and responses is borrowed
from other environments and technologies like EDI, X.400 or ebXML.
Jerman Blazic, et al. Expires January 9, 2008 [Page 9]
Internet-Draft LTAP July 2007
It's main characteristic is that exchanges for LTAP are conceptually
asynchronous. As a consequence, it is necessary to provide a
mechanism to allow a client to determime that the LTA has received
and processed a request. An LTAP exchange consists of sending a
request and retrieving at least 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 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 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.
The possibility to deliver the result attestation in a asynchronous
way permits cost effective implementations of the LTA.
An LTA may deliver immediately a second type response. This occurs
for example for a STATUS or LISTIDS function or when an operation is
retried and the final result is available.
A client can repeat an operation, since the request or the response
might have been lost.
For an ARCHIVE operation, the client MAY provide a unique
identification for the request that to be used by the LTA to ensure
idempotence of the operation. When retrying an ARCHIVE operation, a
client MAY replace the raw data to be archived by a MessageDigest
representing the data in order to reduce the payload size.
For the ARCHIVE, DELETE, VERIFY operations, after receipt of the
technical acknowledgement (first type response), the client can also
use a STATUS operation for the object in order to indirectly
determine the outcome of a transaction. Depending on the lower layer
bindings, sending a STATUS request or retrying another operation may
be the only way to determine the outcome of an archive operation.
Jerman Blazic, et al. Expires January 9, 2008 [Page 10]
Internet-Draft LTAP July 2007
3.4. Life cycles of objects
Using the defined transactions and the operations on objects, two
levels of life cycles are defined. One is directly derived from the
operation of a single transaction. The other is related to the long-
term situation of an object.
3.4.1. Transaction Level Life Cycle
When a client initiates an archive operation, client and server have
some knowledge of the progress of the operation. The following list
explains the different states of a transaction seen by both the
client and the service, and decribes actions and events changing the
state of the transaction.
T0: The client has not initiated an archive operation. The LTA does
not know anything about an object.
T1: The client has initiated an archive operation. The LTA may have
received the object or not; the client cannot assume that the LTA
has received the request. Client may retry the operation after a
timeout.
T2: The LTA has received the request and has generated a first type
response. The server ensures idempotence of at least the ARCHIVE
operation, i.e. on multiple occurrences of an identical request,
the LTA sends the same response and transaction identification.
The LTA may still lose the state, e.g., in case of a power
failure.
T3: The client has received the initial response. The client can
retry the initial operation using the transaction identification
at the place of the data in order to receive a final answer. In
case of negative response, i.e. LTA in state T0, client can fall
back to T1.
T4: The LTA has send a definitive answer for an operation and has
assumed the responsibility of operation.
T5: The client has received a definitive answer and can consider the
operation as terminated.
In case of negative reponses to a transaction, the LTA keeps the
result for a certain time in order to provide a reasonable answer to
a client that retries an operation.
Jerman Blazic, et al. Expires January 9, 2008 [Page 11]
Internet-Draft LTAP July 2007
3.4.2. Long term life cycle.
When an LTA has archived an object, it keeps a certain number of
metadata, which gives information about the current status of the
object. Metadata may remain available even after deleting the
object. Among the remaining metadata there may be the date of
deletion or a reference to where the information can actually be
received.
We can distinguish the following phases in the lifetimes of an
archived object:
L0: The LTA has no knowledge about an object.
L1: An LTA has received an archive object and is proceeding the
request. The LTA may accept or reject the request, or may lose
knowledge about it.
L2: An LTA has archived an object. An LTA can accept other
operations, i.e., EXPORT, DELETE or VERIFY operations. When
receiving an EXPORT or VERIFY operation, some metadata may be
updated, e.g., last time of access, last verification operation
etc.
L3: After a DELETE operation prior to the initially defined lifetime
of the operation, the LTA MAY keep an information about the actual
status of the object (e.g. deleted) until the end of the lifetime.
If available, the LTA MAY returns other remaining metadata
containing for example a new location of the data.
L4: After the lifetime of an object, an object or the reference to
is being deleted. At the end of this internal operation, the LTA
is in state L0.
With the basic operations it is not possible to extend directly the
lifetime of an object. In order to do so, a client has to read the
object and store it under a different service.
A change from state L2 can also occur when an LTA determines loss of
integrity or loss of data.
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
Jerman Blazic, et al. Expires January 9, 2008 [Page 12]
Internet-Draft LTAP July 2007
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 distinguishs
such roles by the definition of the following service types and
service policy information.
The LTA interface implementation MUST enable clients to perform all
the service operations.
A client implementation MAY only support a subset of the service
types in order to have a small footprint. This is motivated by 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.
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 keep 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.
Jerman Blazic, et al. Expires January 9, 2008 [Page 13]
Internet-Draft LTAP July 2007
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.
A multi-dimensional approach with configuration and service types
rounds up the requirements for LTA and scenarios of archiving
processes.
This specification defines no particular policy or configuration.
3.6. Identification
This text defines two ASN.1 modules. One module uses current ASN.1
syntax, the other provides limited support in 88 syntax both
providing the same BER/DER encodings. The modules export all their
definitions. Depending on the ASN.1 syntax version, identifiers are
imported from different other ASN.1 modules. A version number is
added as the last component of the module object identifier. A
version of 0 indicates modules of any draft of this memo.
Definitions of data are made as well in XML schema notation XSD as
well as in ASN.1. The XSD schema has been generated automatically
using the asn1xsd tool from OSS Nokalva. The ASN.1 has been
validated using the asn1c compiler from OSS Nokalva.
The module with current (2005) syntax is defined with the following
syntax:
Jerman Blazic, et al. Expires January 9, 2008 [Page 14]
Internet-Draft LTAP July 2007
Current ASN.1 Module start
LTAP {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-mod(0) id-mod-ltap(4) 0}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
The module in 88 ASN.1 syntax is identified by the following
definitions
ASN.1 Module in 88 syntax start
LTAP {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-mod(0) id-mod-ltap88(3) 0}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
The following XSD schema is generated:
XML Schema Identification
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
targetNamespace="http://www.setcce.org/schemas/ltap"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<annotation><documentation xml:lang="en">
XML Schema for LTAP
</documentation></annotation>
3.7. External definitions
The modules export all their definitions, and import several
definitions from other modules. The modules differ depending of the
ASN.1 syntax but generate identical encodings.
Jerman Blazic, et al. Expires January 9, 2008 [Page 15]
Internet-Draft LTAP July 2007
Current ASN.1 Module external definition
-- EXPORTS ALL
IMPORTS
certificateExtensions
FROM UsefulDefinitions {joint-iso-itu-t ds(5) module(1)
usefulDefinitions(0) 5}
PolicyInformation, GeneralNames
FROM CertificateExtensions certificateExtensions
PKCS7-CONTENT-TYPE
FROM PKCS7
{iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-7(7) modules(0) pkcs-7(1)}
;
The module in 88 syntax form imports from modules which are also in
88 syntax. If the type UTF8String is supported by a particular
compiler, the definitions in PKIX1Explicit88 must be commented out
and the type not imported.
ASN.1 Module in 88 syntax start
-- EXPORTS ALL --
IMPORTS UTF8String, PolicyInformation,
GeneralNames
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) }
;
The id-ct object identifier arc is redefined locally.
SMIME ContentType arc root
id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) 1 }
These are corresponding XML definitions for the imported structures.
XML Schema for imported data structures
<xsd:complexType name="Name">
Jerman Blazic, et al. Expires January 9, 2008 [Page 16]
Internet-Draft LTAP July 2007
<xsd:choice>
<xsd:element name="rdnSequence" type="RDNSequence"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="RDNSequence">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:element name="RelativeDistinguishedName"
type="RelativeDistinguishedName"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="RelativeDistinguishedName">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:element name="AttributeTypeAndDistinguishedValue"
type="AttributeTypeAndDistinguishedValue"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="AttributeTypeAndDistinguishedValue">
<xsd:sequence>
<xsd:element name="type">
<xsd:simpleType>
<xsd:restriction base="OBJECT_IDENTIFIER"/>
</xsd:simpleType>
</xsd:element>
<xsd:element name="value">
<xsd:complexType mixed="true">
<xsd:choice>
<xsd:any processContents="lax"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PolicyInformation">
<xsd:sequence>
<xsd:element name="policyIdentifier"
type="CertPolicyId"/>
<xsd:element name="policyQualifiers" minOccurs="0">
<xsd:complexType>
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:element name="PolicyQualifierInfo"
type="PolicyQualifierInfo"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Jerman Blazic, et al. Expires January 9, 2008 [Page 17]
Internet-Draft LTAP July 2007
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PolicyQualifierInfo">
<xsd:sequence>
<xsd:element name="policyQualifierId">
<xsd:simpleType>
<xsd:restriction base="OBJECT_IDENTIFIER"/>
</xsd:simpleType>
</xsd:element>
<xsd:element name="qualifier" minOccurs="0">
<xsd:complexType mixed="true">
<xsd:choice>
<xsd:any processContents="lax"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="CertPolicyId">
<xsd:restriction base="OBJECT_IDENTIFIER"/>
</xsd:simpleType>
3.8. 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.
Jerman Blazic, et al. Expires January 9, 2008 [Page 18]
Internet-Draft LTAP July 2007
3.8.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
SHOULD use an appropriate structure such as ASN.1 definition of
GeneralName.
3.8.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.9. 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
Jerman Blazic, et al. Expires January 9, 2008 [Page 19]
Internet-Draft LTAP July 2007
3.9.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.
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.9.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.
An LTA may implement indexes of metadata accessible by extended
operations.
Jerman Blazic, et al. Expires January 9, 2008 [Page 20]
Internet-Draft LTAP July 2007
3.9.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 metadata 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
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.9.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, e.g. end-point addresses. 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.
3.9.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 the case where LTA accepts data only for the purpose of generating
evidence information (without storage capabilites to avoid, e.g.
Jerman Blazic, et al. Expires January 9, 2008 [Page 21]
Internet-Draft LTAP July 2007
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.
4. Data Types
A number of data types are common to both requests and responses.
4.1. Artifacts
Artifacts are identifiers used to reference a transaction, or a
result of a transaction. They can be returned as a protocol answer
in an initial response, to allow retrieval of a response or progress
of a transaction later by the initial client or another authorised
entity.
ASN.1 definition
Artifact ::= PrintableString
The corresponding XML type is:
XML Schema element
<xsd:simpleType name="Artifact">
<xsd:restriction base="PrintableString"/>
</xsd:simpleType>
4.2. MessageDigest
A MessageDigest 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.
It is not assumed that a MessageDigest will always identify some data
in a unique way (which is not the case by definition of a hash
function), neither it is assumed that collisions may not exist now or
in the future. It is only assumed that within a bounded collection
of data objects (in time and number), which are stored phyically
safe, a MessageDigest uniquely designate other data.
Nevertheless, it is assumed that for the lifetime of protocol
exchanges, a hash function used to create a MessageDigest is
Jerman Blazic, et al. Expires January 9, 2008 [Page 22]
Internet-Draft LTAP July 2007
crytographically safe.
The structure of a MessageDigest 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.
XML Schema element
<xsd:complexType name="MessageDigest">
<xsd:sequence>
<xsd:element name="digestAlgorithm"
type="DigestMethodType"/>
<xsd:element name="digestValue"
type="DigestValueType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="DigestValueType">
<xsd:restriction base="OCTET_STRING"/>
</xsd:simpleType>
<xsd:simpleType name="DigestMethodType">
<xsd:restriction base="OBJECT_IDENTIFIER"/>
</xsd:simpleType>
ASN.1 Definition
MessageDigest ::= SEQUENCE {
digestAlgorithm DigestMethodType,
digestValue DigestValueType
}
DigestMethodType ::= OBJECT IDENTIFIER
DigestValueType ::= OCTET STRING
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 or which
are related to the preservation process.
The following ASN.1 definition allows to have hierarchical metadata
structures that can be decoded and encoded without the need to modify
the ASN.1 definition. It is left to the application layers or other
metadata defnitions to define restrictions and semantics.
The 'type' identfies in a globally unique way the semantics of the
Jerman Blazic, et al. Expires January 9, 2008 [Page 23]
Internet-Draft LTAP July 2007
value. The 'oid' choice can be used in a similar way as withe MIBs
in SNMP. The 'uri' choce allows to reference metadata defined by
URIs. The semantics 'attribute' choice normally depends on the
semantics of a surrounding definition. Global values for 'attribute'
may exist, i.e. the choice can be used in the outermost MetaData
sequence.
This specification defines one global 'attribute' "datatype". The
'values' item MUST contain one occurence of either a 'stringValue'
which indicates a mime-type, or an 'oidValue' or 'uriValue'
indicating an FTAM document type.
TO BE DISCUSSED: Some global metadata are essential for the LTA
service and require a standardised interpretation. Although it is
possible to recur to some other existing metedata specification,
e.g., the Dublin Core, we do not want to depend on external semantics
here. An LTA is free to map metadata.
ASN.1 Definition
MetaData ::= SEQUENCE OF MetaItem
MetaItem ::= SEQUENCE {
type CHOICE {oid OBJECT IDENTIFIER,
attribute UTF8String,
uri IA5String } ,
values SEQUENCE OF
value CHOICE {
oidValue OBJECT IDENTIFIER,
stringValue UTF8String,
uriValue IA5String,
integerValue INTEGER,
opaqueValue OCTET STRING,
composedValue MetaItem
}
}
Jerman Blazic, et al. Expires January 9, 2008 [Page 24]
Internet-Draft LTAP July 2007
XML Schema element
<xsd:complexType name="MetaData">
<xsd:sequence minOccurs="0"
maxOccurs="unbounded">
<xsd:element name="MetaItem"
type="MetaItem"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="MetaItem">
<xsd:sequence>
<xsd:element name="type">
<xsd:complexType>
<xsd:choice>
<xsd:element name="oid"
type="OBJECT_IDENTIFIER"/>
<xsd:element name="attribute"
type="UTF8String"/>
<xsd:element name="uri"
type="IA5String"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="values">
<xsd:complexType>
<xsd:sequence minOccurs="0"
maxOccurs="unbounded">
<xsd:choice>
<xsd:element name="oidValue"
type="OBJECT_IDENTIFIER"/>
<xsd:element name="stringValue"
type="UTF8String"/>
<xsd:element name="uriValue"
type="IA5String"/>
<xsd:element name="integerValue"
type="INTEGER"/>
<xsd:element name="opaqueValue"
type="OCTET_STRING"/>
<xsd:element name="composedValue"
type="MetaItem"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
Jerman Blazic, et al. Expires January 9, 2008 [Page 25]
Internet-Draft LTAP July 2007
4.4. Nonce
A Nonce is an octetstring usable to prevent replays of responses for
the STATUS operation. If present in a request, a server MUST respond
with a response containing the Nonce value. It does not indicate
that the server must determine in a back-end operation the actual
status.
XML Schema element
<xsd:simpleType name="Nonce">
<xsd:restriction base="OCTET_STRING"/>
</xsd:simpleType>
ASN.1 Definition
Nonce ::= OCTET STRING
4.5. RawData
This type carries data to be verified, archived or returned. A
client MAY select a metadata type to indicate the type of the data.
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 retrieved must be processed as binary string (e.g
signatures are not verifed.).
XML Schema element
<xsd:complexType name="RawData">
<xsd:choice>
<xsd:element name="opaque" type="OCTET_STRING"/>
<xsd:element name="string" type="UTF8String"/>
<xsd:element name="structured" type="MetaData"/>
</xsd:choice>
</xsd:complexType>
TBD? fix the above to allow text and well formed xml alternatively
ASN.1 Definition
RawData ::= CHOICE {
opaque OCTET STRING,
string UTF8String,
structured MetaData
}
Jerman Blazic, et al. Expires January 9, 2008 [Page 26]
Internet-Draft LTAP July 2007
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 element
<xsd:complexType name="DataOrTransaction">
<xsd:choice>
<xsd:element name="data" type="RawData"/>
<xsd:element name="artifact" type="Artifact"/>
<xsd:element name="reference" type="IA5String"/>
</xsd:choice>
</xsd:complexType>
ASN.1 Definition
DataOrTransaction ::= CHOICE {
data RawData,
artifact Artifact,
reference IA5String
}
4.7. Data
This type is used to describe data together with metadata.
XML Schema element
<xsd:complexType name="Data">
<xsd:sequence>
<xsd:element name="dataReference" type="DataOrTransaction"/>
<xsd:element name="metaData" type="MetaData"/>
<xsd:element name="messageImprint" type="MessageDigest"/>
</xsd:sequence>
</xsd:complexType>
Jerman Blazic, et al. Expires January 9, 2008 [Page 27]
Internet-Draft LTAP July 2007
ASN.1 Definition
Data ::= SEQUENCE {
dataReference DataOrTransaction,
metaData MetaData,
messageImprint MessageDigest
}
4.8. SerialNumber
A SerialNumber is an integer value used to identify a request and its
response. Servers MAY add an additional verifyable structure to such
a number, e.g. checksum digits, in order to avoid copying errors in
long-term applications with potential media break.
XML Schema element
<xsd:simpleType name="SerialNumber">
<xsd:restriction base="INTEGER"/>
</xsd:simpleType>
ASN.1 Definition
SerialNumber ::= INTEGER
4.9. LtapTime
Clients and servers can add an indication of (its idea of) the time
when a request or response was created, search intervals etc. The
LtapTime type is used. The encoding of the string content MUST be
according to the distinguished encoding rules (DER).
XML Schema element
<xsd:simpleType name="LtapTime">
<xsd:restriction base="GeneralizedTime"/>
</xsd:simpleType>
ASN.1 Definition
LtapTime ::= GeneralizedTime
4.10. Version
Version is used in requests and responses to indicate the protocol
version used. This specification is provided for two values:
Jerman Blazic, et al. Expires January 9, 2008 [Page 28]
Internet-Draft LTAP July 2007
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.
This memo does not define an extension mechanism.
XML Schema element
<xsd:complexType name="Version">
<xsd:choice>
<xsd:element name="v0" type="NULL"/>
<xsd:element name="v1" type="NULL"/>
</xsd:choice>
</xsd:complexType>
ASN.1 Definition
Version ::= ENUMERATED {
v0,
v1
}
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.
A client MAY also indicate an address to who a response is to be
return in case of an asynchronous reponse, e.g. an e-mail address.
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 defined as GeneralNames imported from
InformationFramework.
Jerman Blazic, et al. Expires January 9, 2008 [Page 29]
Internet-Draft LTAP July 2007
XML Schema element
<xsd:complexType name="EntityIdentifier">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:choice>
<xsd:element name="rfc822Name" type="IA5String"/>
<xsd:element name="dNSName" type="IA5String"/>
<xsd:element name="directoryName" type="Name"/>
<xsd:element name="uniformResourceIdentifier"
type="IA5String"/>
<xsd:element name="iPAddress" type="OCTET_STRING"/>
<xsd:element name="registeredID"
type="OBJECT_IDENTIFIER"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
ASN.1 Definition
EntityIdentifier ::= GeneralNames
4.12. ServiceType
This type is either enumeration of basic services defined in this
memo of an object identifier defined by a service provider. It
indicates operations accessible by the protocol.
XML Schema element
<xsd:complexType name="ServiceType">
<xsd:choice>
<xsd:element name="ltapbasicservice">
<xsd:complexType>
<xsd:choice>
<xsd:element name="archive" type="NULL"/>
<xsd:element name="delete" type="NULL"/>
<xsd:element name="export" type="NULL"/>
<xsd:element name="status" type="NULL"/>
<xsd:element name="verify" type="NULL"/>
<xsd:element name="listids" type="NULL"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="ltapextendedservice"
type="OBJECT_IDENTIFIER"/>
</xsd:choice>
</xsd:complexType>
Jerman Blazic, et al. Expires January 9, 2008 [Page 30]
Internet-Draft LTAP July 2007
ASN.1 Definition
ServiceType ::= CHOICE {
ltapbasicservice ENUMERATED {
archive,
delete,
export,
status,
verify,
listids
},
ltapextendedservice OBJECT IDENTIFIER
}
4.13. StatusInformation
The LTA indicates the global status of a transaction using this
enumeration type. The semantics of the values is as follows:
The response is an initial first type reponse. The request has
been technically accepted by the LTA.
The response is an second type final response from the LTA.
The response is an second type final response from the LTA. The
operation performed by the LTA but only with some modifications.
The operation has not been accepted.
In case of modifications or error, the LTA MUST also return details
using the following GeneralErrorNotice
XML Schema element
<xsd:complexType name="StatusInformation">
<xsd:choice>
<xsd:element name="granted" type="NULL"/>
<xsd:element name="grantedWithMods" type="NULL"/>
<xsd:element name="rejection" type="NULL"/>
<xsd:element name="waiting" type="NULL"/>
<xsd:element name="more" type="NULL"/>
</xsd:choice>
</xsd:complexType>
Jerman Blazic, et al. Expires January 9, 2008 [Page 31]
Internet-Draft LTAP July 2007
ASN.1 Definition
StatusInformation ::= ENUMERATED {
granted,
grantedWithMods,
rejection,
waiting,
more
}
4.14. RequestInformation
This data structure comprises information about the request others
that the raw data and metadata. The structure is filled in partially
by a requestor and augmented or modified by the responder. It
resumes the operation that has been performed.
ASN.1 Definition
RequestInformation ::= SEQUENCE {
version Version DEFAULT v1,
servicePolicyInfo PolicyInformation,
serviceType ServiceType,
requestorID EntityIdentifier,
serviceID EntityIdentifier,
returnID EntityIdentifier OPTIONAL,
serial SerialNumber OPTIONAL,
nonce Nonce OPTIONAL,
requestTime LtapTime OPTIONAL,
startTime [0] LtapTime OPTIONAL,
nextTime [1] LtapTime OPTIONAL,
bindingInfo [2] MetaData OPTIONAL
}
Jerman Blazic, et al. Expires January 9, 2008 [Page 32]
Internet-Draft LTAP July 2007
XML Schema element
<xsd:complexType name="RequestInformation">
<xsd:sequence>
<xsd:element name="version"
type="Version" minOccurs="0"/>
<xsd:element name="servicePolicyInfo"
type="PolicyInformation"/>
<xsd:element name="serviceType"
type="ServiceType"/>
<xsd:element name="requestorID"
type="EntityIdentifier"/>
<xsd:element name="serviceID"
type="EntityIdentifier"/>
<xsd:element name="returnID"
type="EntityIdentifier" minOccurs="0"/>
<xsd:element name="serial"
type="SerialNumber" minOccurs="0"/>
<xsd:element name="nonce"
type="Nonce" minOccurs="0"/>
<xsd:element name="requestTime"
type="LtapTime" minOccurs="0"/>
<xsd:element name="startTime"
type="LtapTime" minOccurs="0"/>
<xsd:element name="nextTime"
type="LtapTime" minOccurs="0"/>
<xsd:element name="bindingInfo"
type="MetaData" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
The version item indicates the version of the protocol to be used.
The item serviceType indicate the operation to be performed. The
value can be one of the enumeration values defined in this memo or an
object identifier defining another operation. Additional operation
MUST not modify the ASN.1 but use metadata for additional parameters.
The serviceID item identifies the LTA service provider(s)
The servicePolicyInfo item defines the service policy.
If a client specifies a nonce item, the server MUST return either the
same value, or a value that has the client value as a prefix.
The meaning of the startTime and nextTime items depend on the value
of the serviceType item and is described later.
Jerman Blazic, et al. Expires January 9, 2008 [Page 33]
Internet-Draft LTAP July 2007
The serial item indicates a serial number of a request has been
received, the field MUST NOT be set by the requestor and MUST be set
by the responder in order to uniquely identify the request.
The requestTime item indicates the time when the request has been
received, the field MAY be set by the requestor in case of a proxy
and it SHOULD be set in any response.
The bindingInfo item contains additional information required by the
LTA or returned to the client. These metadata are associated with
the request and not with the archived data.
The semantics of the items startTime and nextTime depend on the
serviceType.
5. Top level protocol elements
On the top level, there are three protocol elements, one is used in
requests, and the two other are either describing the successful
outcome of an operation or an error notice.
5.1. 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 element
<xsd:complexType name="Request">
<xsd:sequence>
<xsd:element name="information" type="RequestInformation"/>
<xsd:element name="data" type="Data"/>
<xsd:element name="transactionIdentifier"
type="IA5String" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
ASN.1 Definition
Request ::= SEQUENCE {
information RequestInformation,
data Data,
transactionIdentifier IA5String OPTIONAL
}
Jerman Blazic, et al. Expires January 9, 2008 [Page 34]
Internet-Draft LTAP July 2007
5.2. StatusNotice
A server may return a general error notice indicating an important
failure with referencing the request. The element can be created
either by the service, e.g., when a request cannot be decoded, but
also by a client lower layer, e.g. when a connection cannot be
established.
XML Schema element
<xsd:complexType name="StatusNotice">
<xsd:sequence>
<xsd:element name="status"
type="StatusInformation"/>
<xsd:element name="errorInformation">
<xsd:complexType mixed="true">
<xsd:complexContent mixed="true">
<xsd:extension base="UTF8String"/>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="lastValid"
type="LtapTime" minOccurs="0"/>
<xsd:element name="transactionIdentifier"
type="IA5String" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
ASN.1 Definition
StatusNotice ::= SEQUENCE {
status StatusInformation,
errorInformation UTF8String (SIZE(0..8192)),
lastValid LtapTime OPTIONAL,
transactionIdentifier IA5String OPTIONAL
}
5.3. 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.
Jerman Blazic, et al. Expires January 9, 2008 [Page 35]
Internet-Draft LTAP July 2007
XML Schema element
<xsd:complexType name="OperationResponse">
<xsd:sequence>
<xsd:element name="information"
type="RequestInformation"/>
<xsd:element name="status" type="StatusNotice"/>
<xsd:element name="data" type="Data"/>
</xsd:sequence>
</xsd:complexType>
ASN.1 Definition
OperationResponse ::= SEQUENCE {
information RequestInformation,
status StatusNotice,
data Data
}
5.4. Response
This structure is returned on a successful or unsuccessful operation
of the service.
XML Schema element
<xsd:complexType name="Response">
<xsd:choice>
<xsd:element name="operationResponse"
type="OperationResponse"/>
<xsd:element name="errorNotice"
type="StatusNotice"/>
</xsd:choice>
</xsd:complexType>
ASN.1 Definition
Response ::= CHOICE {
operationResponse OperationResponse,
errorNotice [0] StatusNotice
}
6. 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
Jerman Blazic, et al. Expires January 9, 2008 [Page 36]
Internet-Draft LTAP July 2007
choices are filled in differently.
For all operations, the archive service may react in the following
ways:
The request is not understood or cannot be transmitted, an
ErrorNotice is returned.
The request is accepted, an OperationResponse indicating that the
transaction is 'waiting'. The item nextTime in the
requestInformation SHOULD be set by the responder in case when the
client needs to poll for the final response to indicate to the
client not poll before that date.
The request is rejected. an OperationResponse describing the error
is returned.
This a final response, an OperationResponse containing the result
of the transaction is returned.
When the transport layer is asynchronous, the protocol is the
following: The client MUST fill the item returnID in the
requestInformation. A server MAY respond either with the final
result or with two messages indicating acceptance and result. The
client MAY retry the operation (slightly modified) after that date.
Since any operation can be lost, a client has to set an appropriate
value for initial retry timeout.
When the transport layer is synchronous, e.g. if HTTP is used, the
server immediately returns either an error or acceptance, and the
client MUST retry the operation (slightly modified) in order to get
the final result.
A server may offer a mixed environment where the initial response is
obtained in a synchronous way, and the final response can be
transferred in an asynchronous way. In this case, the client MAY be
required to set a returnID.
6.1. 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. The client builds a Request with an
information item including service policy interpreting service
characteristics and service configuration parameters. Data to be
archived and metadata are enclosed.
Jerman Blazic, et al. Expires January 9, 2008 [Page 37]
Internet-Draft LTAP July 2007
o the service type is set to "archive"
o If this is an initial request, the data are filled in with a
rawData and a messageDigest.
o If this a retry of a previous operation, the client MAY choose
either to simply repeat an identical operation, or remove the
rawData and send the messageDigest and, if provided, an artifact.
The server SHOULD use an artifact when the StatusInformation is
'waiting', in order to simplify its processing when the client
retries the operation. When an operation is retried, the client
SHOULD use the returned artifact instead of the data.
The final response contains a data reference to be usable in other
operations concerning the same data object.
When a client archives may objects in parallel operations, it may be
unreasonable to poll for each outstanding result individually. An
LTA MAY support a LISTIDS function returning artifacts for finished
archive operations.
6.2. EXPORT operation
This operation allows a client to retrieve data.
o Data identification must be a data reference and/or a message
imprint.
o The service type is set to "export".
In the final result, the LTA returns data and metadata of the object.
6.3. 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.
o Data identification must include data itself or data reference or
message imprint.
o The metadata MAY be set to replace the existing metadata of the
object.
o The service type is set to "delete".
The LTA MAY either return a result with updated metadata or nothing.
Jerman Blazic, et al. Expires January 9, 2008 [Page 38]
Internet-Draft LTAP July 2007
If the client retries a delete operation, it may happen that the LTA
has already deleted all traces of the operation. In this case, the
server always pretends having deleted the referenced data. The
client cannot distinguish whether the data have ever existed.
6.4. VERIFY operation
This operation allows a client to verify the authenticity of
information stored in the archive. Depending on the actual status of
the object and on the policy of the LTA, the LTA initiates an
internal procedure to determine the validity of the data. An LTA may
perform the similar steps as for the initial archiving operation.
The LTA MAY choose not to perform the operation if the actual status
is sufficiently recent. In this case, the operation is identical to
STATUS operation.
o Data identification must be a data reference and/or a message
imprint.
o The service type is set to "verify".
The LTA returns updated metadata of the object.
6.5. STATUS operation
A client can request the status of a data object.
Client builds a Request with request information including service
policy interpreting service characteristics and service configuration
parameters.
o The service type is set to "status".
o Data identification must be a data reference and/or a message
imprint.
In the final response, the LTA returns the current status and the
metadata for the object.
6.6. LISTIDS operation
A client can request a list of reference of objects archived. The
client builds a Request with request information including service
policy interpreting service characteristics and service configuration
parameters.
Jerman Blazic, et al. Expires January 9, 2008 [Page 39]
Internet-Draft LTAP July 2007
o The service type is set to "LISTIDS".
o Data identification MUST be a data reference, an artifact and/or a
message imprint. If present, the LTA returns references to
objects starting with this reference in the chronological order
defined by the LTA. The reference or artifact MUST be known to
the LTA.
o The startDate and endDate MAY be set to indidate a range. The
exact definition of when an object belongs to that range is
defined by the LTA.
The LTA returns a list of references as a sequence of
DataOrTransaction items. The artifact and dataReference choices are
allowed. If the request contains an artifact, the LTA MUST return
the artifacts that correspond to terminated transactions.
The number of references returned is defined by the LTA and may not
be the complete set. If the LTA has more data to provide, it sets
the StatusInformation to 'more'. The client has to repeat the
operation using the last returned reference as data identification.
A client can distinguish this case from the initial acknowledge which
has the same value for StatusInformation. For the Acceptance
response no references are returned. There may be a final response
with no references incase when no data exist for the specified
criteria.
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.
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. An LTA MAY
use a combination of protocols, for example in order to return
additional responses.
This memo defines bindings for the transfer of requests and/or
responses, one using HTTP and another using e-mail.
Jerman Blazic, et al. Expires January 9, 2008 [Page 40]
Internet-Draft LTAP July 2007
7.1. Common parameters and encoding requirements
This memo defines are two basic ways how requests and responses are
encoded, either using a restricted BER encoding or XML. An LTA MUST
provide at least one of them. Furthermore, we define optional
enveloping protection mechanisms which depend on the encoding. CMS
protection of signedData and envelopedData can be used independantly
of the encoding of the request or response. XML-DSIG and XML-ENC can
only be used for XML encoded requesta nd responses.
For requests encoded in XML either based on XER or on XSD, the
associated MIME type is application/ltap-request+xml. For request
not encoded in XML, the associated MIME type is application/
ltap-request.
Similarly, for responses have an associated MIME types application/
ltap-response and application/ltap-response+xml.
When request and responses are exchanged using an XML encoding, the
XSD top level elements LTAPRequest or LTAPResponse are used, an not
an XER version of ContentInfo.
When a XML Signature is used, an enveloping signature for a Request
or Response or enc:EncryptedData MUST be used
EncryptedData MUST decrypt to a Request or Response or ds:Signature
When the request is presented with the application/ltap-request type,
the client MAY encode it using BER with strings nested at most one
level. Similarily, a response presented with the application/
ltap-response type may have BER with strings nested at most one
level.
The Request and Response items can be encapsulated inside CMS
signedData and/or CMS envelopedData, or, If not protected, the
Request is encapsulated in a ContentInfo using id-ct-LTAPRequest as
identification, and the Response is encapsulated in a ContentInfo
structure using id-ct-LTAPResponse for identification.
If the Request and Response which are not encoded in XML are
encapsulated inside SignedData and/or EnvelopedData, the contenttype
of the innermost encapsulatedContent is set to using id-ct-
LTAPRequest or id-ct-LTAPResponse respectively.
Any of the four MIME parts can be encapsulated inside CMS using an
id-data content-type.
Jerman Blazic, et al. Expires January 9, 2008 [Page 41]
Internet-Draft LTAP July 2007
CMS ContentTypes identifiers
id-ct-LTAPRequest OBJECT IDENTIFIER ::=
{ id-ct 4711 }
id-ct-LTAPResponse OBJECT IDENTIFIER ::=
{ id-ct 4711 }
In current ASN.1 we have the following ContentType definitions.
CMS ContentTypes
ltap-Request PKCS7-CONTENT-TYPE ::= {Request
IDENTIFIED BY id-ct-LTAPRequest }
ltap-Response PKCS7-CONTENT-TYPE ::= {Request
IDENTIFIED BY id-ct-LTAPResponse }
LTAPRequest ::= ContentInfo
LTAPResponse ::= ContentInfo
XML top level definitions
<xsd:element name="Request" type="Request"/>
<xsd:element name="Response" type="Response"/>
<xsd:element name="LTAPRequest" type="LTAPRequest"/>
<xsd:element name="LTAPResponse" type="LTAPResponse"/>
<xsd:complexType name="LTAPResponse">
<xsd:choice>
<xsd:element name="response" type="Request"/>
<xsd:element name="signedResponse" type="ds:Signature"/>
<xsd:element name="encryptedResponse" type="enc:EncryptedData"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="LTAPRequest">
<xsd:choice>
<xsd:element name="request" type="Request"/>
<xsd:element name="signedRequest" type="xd:Signature"/>
<xsd:element name="encryptedRequest" type="enc:EncryptedData"/>
</xsd:choice>
</xsd:complexType>
Jerman Blazic, et al. Expires January 9, 2008 [Page 42]
Internet-Draft LTAP July 2007
7.2. e-mail bindings
In a request, the last element of item requestorID corresponds to the
From header, the last element of the item serviceID to the To header
and the last element of the returnID to reply-to header. The e-mail
header is not used by the LTA, but rather the items in the
requestInformation. When a server acts as a relay, it MAY add
appropriate values to these items.
For the response, an LTA normally sets the From and To header fields
to either the last items of serviceID and returnID (or requestorID).
In case of a relaying LTA, when the LTA receives a response from
another LTA, it first determines its own identity in
requestInformation, sets the From: header to its own identity and the
To: header to the identity of its client.
7.3. HTTP Bindings
Servers MUST understand HTTP 1.1 requests at least for the ARCHIVE,
EXPORT and LISTIDS functions allowing chunked input of a POST request
and 'Continue' responses. 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 client MUST send a Host header in the request.
The Request URI may be used to indicate a particular service
endpoint. When using HTTPS, TLS MUST be supported by clients and
servers. Clients SHOULD send a TLS servername extension in the
ClientHello.
The Content-Type header MUST be set to "application/ltap-request" or
"application/ltap-request+xml". The LTAPrequest message MUST be sent
in the body of the HTTP Request.
The Content-Type header MUST be set to either "application/
ltap-response"or application/ltap-response+xml." The LTAP response
message MUST be sent in the body of the HTTP Response.
The HTTP status code MUST be set to 200 if a LTAP response message is
returned. Otherwise, the status code can be set to 3xx to indicate a
redirection, 4xx to indicate a low-level client error (such as a
malformed request), or 5xx to indicate a low-level server error.
Clients SHOULD react automatically to redirections.
When using HTTPS, TLS 1.0 MUST be supported. SSL 3.0 MAY be
supported by servers. Future versions of TLS MAY be supported.
Clients SHOULD send a TLS servername extension in the ClientHello.
Jerman Blazic, et al. Expires January 9, 2008 [Page 43]
Internet-Draft LTAP July 2007
RSA ciphersuites MUST be supported. Diffie-Hellman and DSS
ciphersuites MAY be supported. TripleDES ciphersuites MUST be
supported. AES ciphersuites SHOULD be supported.
7.4. Security
A request and a response MAY be encapsulated in an [RFC3852]
signedData or envelopedData 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, LTAP requests
and responses 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 are only one signerInfo. A relaying LTA MAY add an additional
signature or a countersignature attribute or remove the encapsulation
and create a new one depending on the requirements of the next LTA.
For the XML encoded structures, alternatively, security mechanisme
from [W3C.xmldsig-core] and [W3C.xmlenc-core] may be used. An LTA
MAY impose restrictions on the usage of these features.
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
that can be authenticated with the explicit exception of a global
error status, which may be returned as a non-signed response.
In order to be able to associate a possible error response with a
request, the requester SHOULD use the field 'transactionIdentifier'.
Jerman Blazic, et al. Expires January 9, 2008 [Page 44]
Internet-Draft LTAP July 2007
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.
8. Credits
This document has been created using XML2RFC ([RFC2629]).
The XSD schema has been generated automatically using the asn1xsd
tool from OSS Nokalva.
The ASN.1 has been validated using the asn1c compiler from OSS
Nokalva.
9. 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.
An LTA is assumed to operate with best effort. Nevertheless, an
operation can fail or get totally lost. A client SHOULD be able to
recover from lost requests, i.e., avoid deleting data until an
attestation has been received.
It is possible for an LTA to report loss of integrity for archived
data, or simply non-existence of data which is equivalent to loss of
data. Depending on the value of the data, appropriate measures to
address these catastrophic scenarios need to be provided outside the
basic service, e.g., by using redundant copies managed either by a
client of internally of a broker type service.
The validity of data should be checked by periodic execution of
VERIFY operations intended to ensure data with demonstratable
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 or the quality of storage devices are factors determining
the verification intervals.
Depending on the lifetime and the quality of data, relying on
cryptographic protection of data object may not be a sufficient means
Jerman Blazic, et al. Expires January 9, 2008 [Page 45]
Internet-Draft LTAP July 2007
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. Aa 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 [RFC3852] or TLS
[RFC4366]).
Server authentication is highly recommended for all service which
transfer data to a server.
Client identification and authentication MAY use services defined by
TLS ([RFC4366]) instead of, or in addition to, using a document or
message protection format, e.g. CMS.
It is possible for an LTA to report loss of integrity for archived
data, or simply non-existence of data which is equivalent to loss of
data. Depending on the value of the data, appropriate measures to
address these catastrophic scenarios need to be provided outside the
basic service, e.g., by using redundant copies managed either by a
client of internally of a broker type service.
10. 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 list is
intitially taken from [RFC3029].
# 4,309,569 Method of Providing Digital Signatures
(issued) January 5, 1982
Jerman Blazic, et al. Expires January 9, 2008 [Page 46]
Internet-Draft LTAP July 2007
(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.
11. IANA considerations
LTAP request and response messages are identified using Object
Identifiers (OIDs), which are defined in an arc delegated by IANA to
Jerman Blazic, et al. Expires January 9, 2008 [Page 47]
Internet-Draft LTAP July 2007
the LTANS Working Group. This document also includes four MIME type
registrations in section 7.1. No further action by IANA is necessary
for this document.
12. References
12.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
12.2. Informative references
[I-D.ietf-ltans-ers]
Brandner, R., "Evidence Record Syntax (ERS)",
draft-ietf-ltans-ers-15 (work in progress), June 2007.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[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.
[RFC4810] Wallace, C., Pordesch, U., and R. Brandner, "Long-Term
Archive Service Requirements", RFC 4810, March 2007.
[W3C.xmldsig-core]
Eastlake, D., Reagle , J., and D. Solo, "XML-Signature
Syntax and Processing", W3C Recommendation xmldsig-core,
October 2000, <http://www.w3.org/TR/xmldsig-core/>.
[W3C.xmlenc-core]
Eastlake, D. and J. Reagle , "XML Encryption Syntax and
Processing", W3C Candidate Recommendation xmlenc-core,
August 2002, <http://www.w3.org/TR/xmlenc-core/>.
Jerman Blazic, et al. Expires January 9, 2008 [Page 48]
Internet-Draft LTAP July 2007
Appendix A. ASN.1 module in current syntax
The following ASN.1 module has been checked using the asn1c tool.
LTAP {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-mod(0) id-mod-ltap(4) 0}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL
IMPORTS
certificateExtensions
FROM UsefulDefinitions {joint-iso-itu-t ds(5) module(1)
usefulDefinitions(0) 5}
PolicyInformation, GeneralNames
FROM CertificateExtensions certificateExtensions
PKCS7-CONTENT-TYPE
FROM PKCS7
{iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-7(7) modules(0) pkcs-7(1)}
;
id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) 1 }
Artifact ::= PrintableString
MessageDigest ::= SEQUENCE {
digestAlgorithm DigestMethodType,
digestValue DigestValueType
}
DigestMethodType ::= OBJECT IDENTIFIER
DigestValueType ::= OCTET STRING
MetaData ::= SEQUENCE OF MetaItem
MetaItem ::= SEQUENCE {
type CHOICE {oid OBJECT IDENTIFIER,
attribute UTF8String,
uri IA5String } ,
Jerman Blazic, et al. Expires January 9, 2008 [Page 49]
Internet-Draft LTAP July 2007
values SEQUENCE OF
value CHOICE {
oidValue OBJECT IDENTIFIER,
stringValue UTF8String,
uriValue IA5String,
integerValue INTEGER,
opaqueValue OCTET STRING,
composedValue MetaItem
}
}
Nonce ::= OCTET STRING
RawData ::= CHOICE {
opaque OCTET STRING,
string UTF8String,
structured MetaData
}
DataOrTransaction ::= CHOICE {
data RawData,
artifact Artifact,
reference IA5String
}
Data ::= SEQUENCE {
dataReference DataOrTransaction,
metaData MetaData,
messageImprint MessageDigest
}
SerialNumber ::= INTEGER
LtapTime ::= GeneralizedTime
Version ::= ENUMERATED {
v0,
v1
}
EntityIdentifier ::= GeneralNames
ServiceType ::= CHOICE {
ltapbasicservice ENUMERATED {
archive,
delete,
export,
status,
Jerman Blazic, et al. Expires January 9, 2008 [Page 50]
Internet-Draft LTAP July 2007
verify,
listids
},
ltapextendedservice OBJECT IDENTIFIER
}
StatusInformation ::= ENUMERATED {
granted,
grantedWithMods,
rejection,
waiting,
more
}
RequestInformation ::= SEQUENCE {
version Version DEFAULT v1,
servicePolicyInfo PolicyInformation,
serviceType ServiceType,
requestorID EntityIdentifier,
serviceID EntityIdentifier,
returnID EntityIdentifier OPTIONAL,
serial SerialNumber OPTIONAL,
nonce Nonce OPTIONAL,
requestTime LtapTime OPTIONAL,
startTime [0] LtapTime OPTIONAL,
nextTime [1] LtapTime OPTIONAL,
bindingInfo [2] MetaData OPTIONAL
}
Request ::= SEQUENCE {
information RequestInformation,
data Data,
transactionIdentifier IA5String OPTIONAL
}
StatusNotice ::= SEQUENCE {
status StatusInformation,
errorInformation UTF8String (SIZE(0..8192)),
lastValid LtapTime OPTIONAL,
transactionIdentifier IA5String OPTIONAL
}
OperationResponse ::= SEQUENCE {
information RequestInformation,
status StatusNotice,
Jerman Blazic, et al. Expires January 9, 2008 [Page 51]
Internet-Draft LTAP July 2007
data Data
}
Response ::= CHOICE {
operationResponse OperationResponse,
errorNotice [0] StatusNotice
}
id-ct-LTAPRequest OBJECT IDENTIFIER ::=
{ id-ct 4711 }
id-ct-LTAPResponse OBJECT IDENTIFIER ::=
{ id-ct 4711 }
ltap-Request PKCS7-CONTENT-TYPE ::= {Request
IDENTIFIED BY id-ct-LTAPRequest }
ltap-Response PKCS7-CONTENT-TYPE ::= {Request
IDENTIFIED BY id-ct-LTAPResponse }
LTAPRequest ::= ContentInfo
LTAPResponse ::= ContentInfo
END
Appendix B. ASN.1 module in 1988 syntax
The following ASN.1 module has been checked using the asn1c tool.
LTAP {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5)
ltans(11) id-mod(0) id-mod-ltap88(3) 0}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS UTF8String, PolicyInformation,
GeneralNames
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) }
;
id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9)
Jerman Blazic, et al. Expires January 9, 2008 [Page 52]
Internet-Draft LTAP July 2007
id-smime(16) 1 }
Artifact ::= PrintableString
MessageDigest ::= SEQUENCE {
digestAlgorithm DigestMethodType,
digestValue DigestValueType
}
DigestMethodType ::= OBJECT IDENTIFIER
DigestValueType ::= OCTET STRING
MetaData ::= SEQUENCE OF MetaItem
MetaItem ::= SEQUENCE {
type CHOICE {oid OBJECT IDENTIFIER,
attribute UTF8String,
uri IA5String } ,
values SEQUENCE OF
value CHOICE {
oidValue OBJECT IDENTIFIER,
stringValue UTF8String,
uriValue IA5String,
integerValue INTEGER,
opaqueValue OCTET STRING,
composedValue MetaItem
}
}
Nonce ::= OCTET STRING
RawData ::= CHOICE {
opaque OCTET STRING,
string UTF8String,
structured MetaData
}
DataOrTransaction ::= CHOICE {
data RawData,
artifact Artifact,
reference IA5String
}
Data ::= SEQUENCE {
dataReference DataOrTransaction,
metaData MetaData,
messageImprint MessageDigest
Jerman Blazic, et al. Expires January 9, 2008 [Page 53]
Internet-Draft LTAP July 2007
}
SerialNumber ::= INTEGER
LtapTime ::= GeneralizedTime
Version ::= ENUMERATED {
v0,
v1
}
EntityIdentifier ::= GeneralNames
ServiceType ::= CHOICE {
ltapbasicservice ENUMERATED {
archive,
delete,
export,
status,
verify,
listids
},
ltapextendedservice OBJECT IDENTIFIER
}
StatusInformation ::= ENUMERATED {
granted,
grantedWithMods,
rejection,
waiting,
more
}
RequestInformation ::= SEQUENCE {
version Version DEFAULT v1,
servicePolicyInfo PolicyInformation,
serviceType ServiceType,
requestorID EntityIdentifier,
serviceID EntityIdentifier,
returnID EntityIdentifier OPTIONAL,
serial SerialNumber OPTIONAL,
nonce Nonce OPTIONAL,
requestTime LtapTime OPTIONAL,
startTime [0] LtapTime OPTIONAL,
nextTime [1] LtapTime OPTIONAL,
bindingInfo [2] MetaData OPTIONAL
Jerman Blazic, et al. Expires January 9, 2008 [Page 54]
Internet-Draft LTAP July 2007
}
Request ::= SEQUENCE {
information RequestInformation,
data Data,
transactionIdentifier IA5String OPTIONAL
}
StatusNotice ::= SEQUENCE {
status StatusInformation,
errorInformation UTF8String (SIZE(0..8192)),
lastValid LtapTime OPTIONAL,
transactionIdentifier IA5String OPTIONAL
}
OperationResponse ::= SEQUENCE {
information RequestInformation,
status StatusNotice,
data Data
}
Response ::= CHOICE {
operationResponse OperationResponse,
errorNotice [0] StatusNotice
}
id-ct-LTAPRequest OBJECT IDENTIFIER ::=
{ id-ct 4711 }
id-ct-LTAPResponse OBJECT IDENTIFIER ::=
{ id-ct 4711 }
END
Appendix C. Additional XML definitions
A number of additional XML definitions are necessary. They
correspond to universal ASN.1 types.
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
targetNamespace="http://www.setcce.org/schemas/ltap"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<annotation><documentation xml:lang="en">
XML Schema for LTAP
Jerman Blazic, et al. Expires January 9, 2008 [Page 55]
Internet-Draft LTAP July 2007
</documentation></annotation>
<xsd:complexType name="Name">
<xsd:choice>
<xsd:element name="rdnSequence" type="RDNSequence"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="RDNSequence">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:element name="RelativeDistinguishedName"
type="RelativeDistinguishedName"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="RelativeDistinguishedName">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:element name="AttributeTypeAndDistinguishedValue"
type="AttributeTypeAndDistinguishedValue"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="AttributeTypeAndDistinguishedValue">
<xsd:sequence>
<xsd:element name="type">
<xsd:simpleType>
<xsd:restriction base="OBJECT_IDENTIFIER"/>
</xsd:simpleType>
</xsd:element>
<xsd:element name="value">
<xsd:complexType mixed="true">
<xsd:choice>
<xsd:any processContents="lax"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PolicyInformation">
<xsd:sequence>
<xsd:element name="policyIdentifier"
type="CertPolicyId"/>
<xsd:element name="policyQualifiers" minOccurs="0">
<xsd:complexType>
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:element name="PolicyQualifierInfo"
Jerman Blazic, et al. Expires January 9, 2008 [Page 56]
Internet-Draft LTAP July 2007
type="PolicyQualifierInfo"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PolicyQualifierInfo">
<xsd:sequence>
<xsd:element name="policyQualifierId">
<xsd:simpleType>
<xsd:restriction base="OBJECT_IDENTIFIER"/>
</xsd:simpleType>
</xsd:element>
<xsd:element name="qualifier" minOccurs="0">
<xsd:complexType mixed="true">
<xsd:choice>
<xsd:any processContents="lax"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="CertPolicyId">
<xsd:restriction base="OBJECT_IDENTIFIER"/>
</xsd:simpleType>
<xsd:simpleType name="Artifact">
<xsd:restriction base="PrintableString"/>
</xsd:simpleType>
<xsd:complexType name="MessageDigest">
<xsd:sequence>
<xsd:element name="digestAlgorithm"
type="DigestMethodType"/>
<xsd:element name="digestValue"
type="DigestValueType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="DigestValueType">
<xsd:restriction base="OCTET_STRING"/>
</xsd:simpleType>
<xsd:simpleType name="DigestMethodType">
<xsd:restriction base="OBJECT_IDENTIFIER"/>
Jerman Blazic, et al. Expires January 9, 2008 [Page 57]
Internet-Draft LTAP July 2007
</xsd:simpleType>
<xsd:complexType name="MetaData">
<xsd:sequence minOccurs="0"
maxOccurs="unbounded">
<xsd:element name="MetaItem"
type="MetaItem"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="MetaItem">
<xsd:sequence>
<xsd:element name="type">
<xsd:complexType>
<xsd:choice>
<xsd:element name="oid"
type="OBJECT_IDENTIFIER"/>
<xsd:element name="attribute"
type="UTF8String"/>
<xsd:element name="uri"
type="IA5String"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="values">
<xsd:complexType>
<xsd:sequence minOccurs="0"
maxOccurs="unbounded">
<xsd:choice>
<xsd:element name="oidValue"
type="OBJECT_IDENTIFIER"/>
<xsd:element name="stringValue"
type="UTF8String"/>
<xsd:element name="uriValue"
type="IA5String"/>
<xsd:element name="integerValue"
type="INTEGER"/>
<xsd:element name="opaqueValue"
type="OCTET_STRING"/>
<xsd:element name="composedValue"
type="MetaItem"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
Jerman Blazic, et al. Expires January 9, 2008 [Page 58]
Internet-Draft LTAP July 2007
<xsd:simpleType name="Nonce">
<xsd:restriction base="OCTET_STRING"/>
</xsd:simpleType>
<xsd:complexType name="RawData">
<xsd:choice>
<xsd:element name="opaque" type="OCTET_STRING"/>
<xsd:element name="string" type="UTF8String"/>
<xsd:element name="structured" type="MetaData"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="DataOrTransaction">
<xsd:choice>
<xsd:element name="data" type="RawData"/>
<xsd:element name="artifact" type="Artifact"/>
<xsd:element name="reference" type="IA5String"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="Data">
<xsd:sequence>
<xsd:element name="dataReference" type="DataOrTransaction"/>
<xsd:element name="metaData" type="MetaData"/>
<xsd:element name="messageImprint" type="MessageDigest"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="SerialNumber">
<xsd:restriction base="INTEGER"/>
</xsd:simpleType>
<xsd:simpleType name="LtapTime">
<xsd:restriction base="GeneralizedTime"/>
</xsd:simpleType>
<xsd:complexType name="Version">
<xsd:choice>
<xsd:element name="v0" type="NULL"/>
<xsd:element name="v1" type="NULL"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="EntityIdentifier">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:choice>
<xsd:element name="rfc822Name" type="IA5String"/>
<xsd:element name="dNSName" type="IA5String"/>
Jerman Blazic, et al. Expires January 9, 2008 [Page 59]
Internet-Draft LTAP July 2007
<xsd:element name="directoryName" type="Name"/>
<xsd:element name="uniformResourceIdentifier"
type="IA5String"/>
<xsd:element name="iPAddress" type="OCTET_STRING"/>
<xsd:element name="registeredID"
type="OBJECT_IDENTIFIER"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ServiceType">
<xsd:choice>
<xsd:element name="ltapbasicservice">
<xsd:complexType>
<xsd:choice>
<xsd:element name="archive" type="NULL"/>
<xsd:element name="delete" type="NULL"/>
<xsd:element name="export" type="NULL"/>
<xsd:element name="status" type="NULL"/>
<xsd:element name="verify" type="NULL"/>
<xsd:element name="listids" type="NULL"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="ltapextendedservice"
type="OBJECT_IDENTIFIER"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="StatusInformation">
<xsd:choice>
<xsd:element name="granted" type="NULL"/>
<xsd:element name="grantedWithMods" type="NULL"/>
<xsd:element name="rejection" type="NULL"/>
<xsd:element name="waiting" type="NULL"/>
<xsd:element name="more" type="NULL"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="RequestInformation">
<xsd:sequence>
<xsd:element name="version"
type="Version" minOccurs="0"/>
<xsd:element name="servicePolicyInfo"
type="PolicyInformation"/>
<xsd:element name="serviceType"
type="ServiceType"/>
<xsd:element name="requestorID"
Jerman Blazic, et al. Expires January 9, 2008 [Page 60]
Internet-Draft LTAP July 2007
type="EntityIdentifier"/>
<xsd:element name="serviceID"
type="EntityIdentifier"/>
<xsd:element name="returnID"
type="EntityIdentifier" minOccurs="0"/>
<xsd:element name="serial"
type="SerialNumber" minOccurs="0"/>
<xsd:element name="nonce"
type="Nonce" minOccurs="0"/>
<xsd:element name="requestTime"
type="LtapTime" minOccurs="0"/>
<xsd:element name="startTime"
type="LtapTime" minOccurs="0"/>
<xsd:element name="nextTime"
type="LtapTime" minOccurs="0"/>
<xsd:element name="bindingInfo"
type="MetaData" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Request">
<xsd:sequence>
<xsd:element name="information" type="RequestInformation"/>
<xsd:element name="data" type="Data"/>
<xsd:element name="transactionIdentifier"
type="IA5String" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="StatusNotice">
<xsd:sequence>
<xsd:element name="status"
type="StatusInformation"/>
<xsd:element name="errorInformation">
<xsd:complexType mixed="true">
<xsd:complexContent mixed="true">
<xsd:extension base="UTF8String"/>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="lastValid"
type="LtapTime" minOccurs="0"/>
<xsd:element name="transactionIdentifier"
type="IA5String" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="OperationResponse">
Jerman Blazic, et al. Expires January 9, 2008 [Page 61]
Internet-Draft LTAP July 2007
<xsd:sequence>
<xsd:element name="information"
type="RequestInformation"/>
<xsd:element name="status" type="StatusNotice"/>
<xsd:element name="data" type="Data"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Response">
<xsd:choice>
<xsd:element name="operationResponse"
type="OperationResponse"/>
<xsd:element name="errorNotice"
type="StatusNotice"/>
</xsd:choice>
</xsd:complexType>
<xsd:element name="Request" type="Request"/>
<xsd:element name="Response" type="Response"/>
<xsd:element name="LTAPRequest" type="LTAPRequest"/>
<xsd:element name="LTAPResponse" type="LTAPResponse"/>
<xsd:complexType name="LTAPResponse">
<xsd:choice>
<xsd:element name="response" type="Request"/>
<xsd:element name="signedResponse" type="ds:Signature"/>
<xsd:element name="encryptedResponse" type="enc:EncryptedData"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="LTAPRequest">
<xsd:choice>
<xsd:element name="request" type="Request"/>
<xsd:element name="signedRequest" type="xd:Signature"/>
<xsd:element name="encryptedRequest" type="enc:EncryptedData"/>
</xsd:choice>
</xsd:complexType>
</schema>
Appendix D. XML schema for LTAP
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
targetNamespace="http://www.setcce.org/schemas/ltap"
elementFormDefault="qualified"
Jerman Blazic, et al. Expires January 9, 2008 [Page 62]
Internet-Draft LTAP July 2007
attributeFormDefault="unqualified">
<annotation><documentation xml:lang="en">
XML Schema for LTAP
</documentation></annotation>
<xsd:complexType name="Name">
<xsd:choice>
<xsd:element name="rdnSequence" type="RDNSequence"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="RDNSequence">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:element name="RelativeDistinguishedName"
type="RelativeDistinguishedName"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="RelativeDistinguishedName">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:element name="AttributeTypeAndDistinguishedValue"
type="AttributeTypeAndDistinguishedValue"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="AttributeTypeAndDistinguishedValue">
<xsd:sequence>
<xsd:element name="type">
<xsd:simpleType>
<xsd:restriction base="OBJECT_IDENTIFIER"/>
</xsd:simpleType>
</xsd:element>
<xsd:element name="value">
<xsd:complexType mixed="true">
<xsd:choice>
<xsd:any processContents="lax"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PolicyInformation">
<xsd:sequence>
<xsd:element name="policyIdentifier"
type="CertPolicyId"/>
<xsd:element name="policyQualifiers" minOccurs="0">
Jerman Blazic, et al. Expires January 9, 2008 [Page 63]
Internet-Draft LTAP July 2007
<xsd:complexType>
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:element name="PolicyQualifierInfo"
type="PolicyQualifierInfo"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PolicyQualifierInfo">
<xsd:sequence>
<xsd:element name="policyQualifierId">
<xsd:simpleType>
<xsd:restriction base="OBJECT_IDENTIFIER"/>
</xsd:simpleType>
</xsd:element>
<xsd:element name="qualifier" minOccurs="0">
<xsd:complexType mixed="true">
<xsd:choice>
<xsd:any processContents="lax"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="CertPolicyId">
<xsd:restriction base="OBJECT_IDENTIFIER"/>
</xsd:simpleType>
<xsd:simpleType name="Artifact">
<xsd:restriction base="PrintableString"/>
</xsd:simpleType>
<xsd:complexType name="MessageDigest">
<xsd:sequence>
<xsd:element name="digestAlgorithm"
type="DigestMethodType"/>
<xsd:element name="digestValue"
type="DigestValueType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="DigestValueType">
<xsd:restriction base="OCTET_STRING"/>
</xsd:simpleType>
Jerman Blazic, et al. Expires January 9, 2008 [Page 64]
Internet-Draft LTAP July 2007
<xsd:simpleType name="DigestMethodType">
<xsd:restriction base="OBJECT_IDENTIFIER"/>
</xsd:simpleType>
<xsd:complexType name="MetaData">
<xsd:sequence minOccurs="0"
maxOccurs="unbounded">
<xsd:element name="MetaItem"
type="MetaItem"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="MetaItem">
<xsd:sequence>
<xsd:element name="type">
<xsd:complexType>
<xsd:choice>
<xsd:element name="oid"
type="OBJECT_IDENTIFIER"/>
<xsd:element name="attribute"
type="UTF8String"/>
<xsd:element name="uri"
type="IA5String"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="values">
<xsd:complexType>
<xsd:sequence minOccurs="0"
maxOccurs="unbounded">
<xsd:choice>
<xsd:element name="oidValue"
type="OBJECT_IDENTIFIER"/>
<xsd:element name="stringValue"
type="UTF8String"/>
<xsd:element name="uriValue"
type="IA5String"/>
<xsd:element name="integerValue"
type="INTEGER"/>
<xsd:element name="opaqueValue"
type="OCTET_STRING"/>
<xsd:element name="composedValue"
type="MetaItem"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
Jerman Blazic, et al. Expires January 9, 2008 [Page 65]
Internet-Draft LTAP July 2007
</xsd:complexType>
<xsd:simpleType name="Nonce">
<xsd:restriction base="OCTET_STRING"/>
</xsd:simpleType>
<xsd:complexType name="RawData">
<xsd:choice>
<xsd:element name="opaque" type="OCTET_STRING"/>
<xsd:element name="string" type="UTF8String"/>
<xsd:element name="structured" type="MetaData"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="DataOrTransaction">
<xsd:choice>
<xsd:element name="data" type="RawData"/>
<xsd:element name="artifact" type="Artifact"/>
<xsd:element name="reference" type="IA5String"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="Data">
<xsd:sequence>
<xsd:element name="dataReference" type="DataOrTransaction"/>
<xsd:element name="metaData" type="MetaData"/>
<xsd:element name="messageImprint" type="MessageDigest"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="SerialNumber">
<xsd:restriction base="INTEGER"/>
</xsd:simpleType>
<xsd:simpleType name="LtapTime">
<xsd:restriction base="GeneralizedTime"/>
</xsd:simpleType>
<xsd:complexType name="Version">
<xsd:choice>
<xsd:element name="v0" type="NULL"/>
<xsd:element name="v1" type="NULL"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="EntityIdentifier">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:choice>
Jerman Blazic, et al. Expires January 9, 2008 [Page 66]
Internet-Draft LTAP July 2007
<xsd:element name="rfc822Name" type="IA5String"/>
<xsd:element name="dNSName" type="IA5String"/>
<xsd:element name="directoryName" type="Name"/>
<xsd:element name="uniformResourceIdentifier"
type="IA5String"/>
<xsd:element name="iPAddress" type="OCTET_STRING"/>
<xsd:element name="registeredID"
type="OBJECT_IDENTIFIER"/>
</xsd:choice>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ServiceType">
<xsd:choice>
<xsd:element name="ltapbasicservice">
<xsd:complexType>
<xsd:choice>
<xsd:element name="archive" type="NULL"/>
<xsd:element name="delete" type="NULL"/>
<xsd:element name="export" type="NULL"/>
<xsd:element name="status" type="NULL"/>
<xsd:element name="verify" type="NULL"/>
<xsd:element name="listids" type="NULL"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="ltapextendedservice"
type="OBJECT_IDENTIFIER"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="StatusInformation">
<xsd:choice>
<xsd:element name="granted" type="NULL"/>
<xsd:element name="grantedWithMods" type="NULL"/>
<xsd:element name="rejection" type="NULL"/>
<xsd:element name="waiting" type="NULL"/>
<xsd:element name="more" type="NULL"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="RequestInformation">
<xsd:sequence>
<xsd:element name="version"
type="Version" minOccurs="0"/>
<xsd:element name="servicePolicyInfo"
type="PolicyInformation"/>
<xsd:element name="serviceType"
Jerman Blazic, et al. Expires January 9, 2008 [Page 67]
Internet-Draft LTAP July 2007
type="ServiceType"/>
<xsd:element name="requestorID"
type="EntityIdentifier"/>
<xsd:element name="serviceID"
type="EntityIdentifier"/>
<xsd:element name="returnID"
type="EntityIdentifier" minOccurs="0"/>
<xsd:element name="serial"
type="SerialNumber" minOccurs="0"/>
<xsd:element name="nonce"
type="Nonce" minOccurs="0"/>
<xsd:element name="requestTime"
type="LtapTime" minOccurs="0"/>
<xsd:element name="startTime"
type="LtapTime" minOccurs="0"/>
<xsd:element name="nextTime"
type="LtapTime" minOccurs="0"/>
<xsd:element name="bindingInfo"
type="MetaData" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Request">
<xsd:sequence>
<xsd:element name="information" type="RequestInformation"/>
<xsd:element name="data" type="Data"/>
<xsd:element name="transactionIdentifier"
type="IA5String" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="StatusNotice">
<xsd:sequence>
<xsd:element name="status"
type="StatusInformation"/>
<xsd:element name="errorInformation">
<xsd:complexType mixed="true">
<xsd:complexContent mixed="true">
<xsd:extension base="UTF8String"/>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="lastValid"
type="LtapTime" minOccurs="0"/>
<xsd:element name="transactionIdentifier"
type="IA5String" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
Jerman Blazic, et al. Expires January 9, 2008 [Page 68]
Internet-Draft LTAP July 2007
<xsd:complexType name="OperationResponse">
<xsd:sequence>
<xsd:element name="information"
type="RequestInformation"/>
<xsd:element name="status" type="StatusNotice"/>
<xsd:element name="data" type="Data"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Response">
<xsd:choice>
<xsd:element name="operationResponse"
type="OperationResponse"/>
<xsd:element name="errorNotice"
type="StatusNotice"/>
</xsd:choice>
</xsd:complexType>
<xsd:element name="Request" type="Request"/>
<xsd:element name="Response" type="Response"/>
<xsd:element name="LTAPRequest" type="LTAPRequest"/>
<xsd:element name="LTAPResponse" type="LTAPResponse"/>
<xsd:complexType name="LTAPResponse">
<xsd:choice>
<xsd:element name="response" type="Request"/>
<xsd:element name="signedResponse" type="ds:Signature"/>
<xsd:element name="encryptedResponse" type="enc:EncryptedData"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="LTAPRequest">
<xsd:choice>
<xsd:element name="request" type="Request"/>
<xsd:element name="signedRequest" type="xd:Signature"/>
<xsd:element name="encryptedRequest" type="enc:EncryptedData"/>
</xsd:choice>
</xsd:complexType>
</schema>
Jerman Blazic, et al. Expires January 9, 2008 [Page 69]
Internet-Draft LTAP July 2007
Authors' Addresses
Aleksej Jerman Blazic
SETCCE
Jamova 39
Ljubljana SI-1000
SLOVENIA
Fax: +386 1 4773861
Email: aljosa@setcce.org
Peter Sylvester
EdelWeb
15 quai de Dion-Bouton
Puteaux F-92816
FRANCE
Fax: +33 1 40 99 14 14
Email: Peter.Sylvester@edelweb.fr
Carl Wallace
Cygnacom Solutions
Suite 5200
7925 Jones Branch Drive
McLean, VA 22102
Email: cwallace@cygnacom.com
Jerman Blazic, et al. Expires January 9, 2008 [Page 70]
Internet-Draft LTAP July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Jerman Blazic, et al. Expires January 9, 2008 [Page 71]
