Internet Draft C. Wallace
draft-ietf-pkix-tap-00.txt CygnaCom Solutions
February 2003 S. Chokhani
Expires August 2003 Orion Security
Trusted Archive Protocol (TAP)
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026].
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 made obsolete 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.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
A Trusted Archive Authority (TAA) is a service that supports long-
term non-repudiation by maintaining secure storage of
cryptographically refreshed information. This document defines a set
of transactions for interacting with a Trusted Archive Authority
(TAA) and establishes a means of representing archived information.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Trusted Archive Protocol (TAP) February 2003
Table of Contents
1. Introduction...................................................3
1.1 Terminology................................................3
1.2 Data.......................................................4
1.3 Entities...................................................4
1.4 Services...................................................4
1.5 Applications...............................................5
2. Trusted Archive Protocol.......................................5
2.1 Archive submission request format..........................7
2.2 Archive submission response format.........................9
2.3 Archive retrieval request format..........................11
2.4 Archive retrieval response................................13
2.5 Archive deletion request..................................15
2.6 Archive deletion response.................................16
3. Validation....................................................17
3.1 Submission................................................17
3.2 Retrieval.................................................18
3.3 Deletion..................................................19
4. Transports....................................................19
4.1 TAP over HTTP.............................................19
5. ArchiveControls, TrackingInfos and CryptoInfos................21
5.1 Archive Controls..........................................21
5.2 TrackingInfos.............................................22
5.3 CryptoInfos...............................................22
6. TAP ASN.1 Module..............................................23
7. Security Considerations.......................................28
7.1 Trust Anchors for Timestamp and Other Signature Verification
on Archive Retrieval..........................................28
7.2 Algorithm and Technology Advances.........................29
7.3 Authorizations............................................29
7.4 TSA Policy................................................30
7.5 Other.....................................................30
8. Intellectual Property.........................................30
Normative References.............................................32
Informative References...........................................32
Authors' Addresses...............................................33
Appendix A: Support for non-TAP aware clients and alternative
submission request formats.......................................34
Wallace & Chokhani Expires August 2003 [Page 2]
Trusted Archive Protocol (TAP) February 2003
1. Introduction
A Trusted Archive Authority (TAA) is a service that supports long-
term non-repudiation by maintaining secure storage of
cryptographically refreshed information. This document defines a
trusted archive protocol (TAP) that provides a set of transactions
for interactions with a TAA (i.e. submission, retrieval and deletion
of information).
1.1 Terminology
A TAA generates and maintains various data as part of the archive
process. Throughout this document, entities submitting data to the
TAA for archival are referred to as submitters and entities
requesting retrieval or deletion of data are referred to as
requestors. This document uses the following terms to describe the
artifacts of the archive process:
Archived data: archived data is the data presented to the TAA by the
submitter.
Archive token: an archive token is an object generated by the TAA
when data is submitted and accepted for archiving. The archive token
is returned to the submitter and may be used to request retrieval or
deletion of the archived data and associated cryptographic
information. For purposes of future retrieval or deletion,
applications may treat the archive token as an opaque blob. The
archive token includes: submitter DN, timestamp token, TAA date and
time upon submission and, optionally, tracking information. To
verify the accuracy of information archived by the TAA, submitters
MUST verify the contents of the archive token as described below in
section 3.
Archive record: an archive record contains the cryptographic refresh
history compiled by the TAA. The initial archive record is the
timestamp token obtained for the submitted data. The timestamp token
format is defined in [RFC3161] and consists of a ContentInfo object
containing a TSTInfo object. Upon each refresh, the most recent
archive record becomes the prevArchRecord field of a new
TimeStampedData object, a timestamp is obtained for the
TimeStampedData object and is placed in the timestamp field of a new
ArchiveRecordData and the entire ArchiveRecordData structure placed
in a ContentInfo object. The ContentInfo object serves as the new
archive record. When verifying an archive record, verification
terminates when the original timestamp token is verified against the
archived data.
Wallace & Chokhani Expires August 2003 [Page 3]
Trusted Archive Protocol (TAP) February 2003
Archive package: an archive package is an object containing,
minimally, the archive token, archive record and archived data. The
archive package MAY include additional cryptographic information.
1.2 Data
A TAA may be able to archive any data format or a TAA MAY implement
features that limit the types of data that will be accepted for
archiving. A TAA MAY implement additional support for some data
formats, e.g. a TAA could implement a CMS message verification
feature. Additional features SHOULD be implemented using an archive
control.
Data submitted to a TAA MAY include all, some or none of the
cryptographic information necessary for long-term dispute resolution.
Archived data MAY be submitted with or without type information
and/or instructions that request the TAA to act upon the data prior
to archival, i.e. an archive control. A TAA MAY implement features
that assist in the collection and/or validation of cryptographic
information or otherwise act upon the submitted data. Submitters MAY
submit data that is thought to be cryptographically valid or invalid.
Retrieval clients MAY submit information sufficient to identify 0 or
more archive records for retrieval.
1.3 Entities
This specification identifies four entities involved in TAP: TAA,
timestamp authority (TSA), submission client and retrieval/deletion
client. The TAA MAY be aware of the archived data format or not
aware. The submission client MAY be TAP-aware or non-TAP-aware. The
retrieval/deletion client MUST be TAP-aware and MAY be aware of the
archived data format or not aware. The TSA MAY be independent of the
TAA (i.e. the TAA acts as a timestamp client) or the TAA MAY be a
TSA.
The provision for non-TAP-aware submission clients is intended to
support simple, existing clients, such as a FTP client. In such
cases a TAP-aware client should be used to process the TAA response,
which may be delivered via a different transport.
TAA certificates MUST include an instance of the extendedKeyUsage
extension permitting operation as a TAA. The value must be set to
id-kp-trustedArchive.
1.4 Services
A TAA MUST provide the following services:
- Archived data preservation
Wallace & Chokhani Expires August 2003 [Page 4]
Trusted Archive Protocol (TAP) February 2003
- Archive token generation (including acquisition of a timestamp
for the archived data)
- Periodic refresh of archive record
- Trusted cryptographic information preservation for verification
of an archive record (i.e. trust anchors, certificates, CRLs,
OCSP responses, OCSP responder certificates, etc.)
- Archive package retrieval and deletion
A TAA MAY provide additional, optional services, for example:
- Historical trust anchor preservation
- PKI information collection and/or validation
- Cryptographic message validation
Like the RFC on Electronic Signature Formats for long-term electronic
signatures [RFC3126], this draft relies on CMS [RFC3369] and the Time
Stamp Protocol [RFC3161]. This specification defines the following:
- A data transfer protocol between TAAs and clients
- Artifacts that can be used to archive and preserve any
cryptographic service, such as digital signatures, and to archive
any non-cryptographic data.
TAP uses a timestamp refresh approach that greatly reduces (and can
be used to eliminate) the need to trust the TAA for the integrity of
the archive data. In other words, data modifications made to the
archive records by the TAA can be detected.
1.5 Applications
The TAA can be unaware of the data being archived and can be used to
archive cryptographic data or non-cryptographic data. Cryptographic
data can be signed, encrypted or both.
In support of long-term preservation of digital signatures,
submitters can package all the certificates, revocation information
(CRLs and OCSP responses) and, optionally, trust anchors in the
submitted data to facilitate signature verification at any time in
the future without needing the services of a repository or other
source for certificates and revocation information. If the retrieval
client uses another trusted source for trust anchors for signature
verification and for trusted timestamp verification, then the TAA
need not be trusted for the integrity of the data. The TSA MUST be
trusted in all cases.
2. Trusted Archive Protocol
The following sections describe the transaction formats that comprise
the TAP. Submission and retrieval requests sent to a TAA MAY be
signed, not authenticated or authenticated using other means such as
Wallace & Chokhani Expires August 2003 [Page 5]
Trusted Archive Protocol (TAP) February 2003
client-authenticated SSL/TLS. Deletion requests MUST be
authenticated. Messages sent from a TAA are always signed using the
CMS SignedData ([RFC3369]) format with a TAP response payload. All
response messages from a TAA MUST be signed and MUST NOT contain any
signatures other than the signature of the TAA.
Unsigned requests consist of an ArchiveSubmissionReq,
ArchiveRetrievalReq or ArchiveDeletionReq encapsulated in a
ContentInfo object. An overview of this structure is provided below.
Many details are not shown, but the way that TAP makes use of CMS is
clearly illustrated.
ContentInfo {
contentType, -- id-tap-archiveReq, id-tap-archiveRetrievalReq
-- or id-tap-archiveDeletionReq
content -- ArchiveSubmissionReq, ArchiveRetrievalReq
-- or ArchiveDeletionReq
}
Signed requests and signed responses consist of an
ArchiveSubmissionReq, ArchiveRetrievalReq, ArchiveDeletionReq,
ArchiveSubOrDelResp or ArchiveRetrievalResp encapsulated in a
SignedData, which is in turn encapsulated in a ContentInfo. An
overview of this structure is provided below. Again, many details are
not shown, but the way that TAP makes use of CMS is clearly
illustrated.
ContentInfo {
contentType, -- id-signedData (1.2.840.113549.1.7.2)
content -- SignedData
}
SignedData {
version,
digestAlgorithms,
encapContentInfo, -- contents as described below
certificates, -- (Optional)
crls, -- (Optional)
signerInfos -- (only one in TAP)
}
SignerInfo {
version,
sid,
digestAlgorithm,
signedAttrs, -- (Required)
signatureAlgorithm,
signature,
unsignedAttrs
Wallace & Chokhani Expires August 2003 [Page 6]
Trusted Archive Protocol (TAP) February 2003
}
EncapsulatedContentInfo {
eContentType, -- id-tap-archiveReq,
-- id-tap-archiveRetrievalReq,
-- id-tap-archiveDeletionReq,
-- id-tap-archiveSubOrDelResp or
-- id-tap-archiveRetrievalResp
eContent -- OCTET STRING containing
-- ArchiveSubmissionReq, ArchiveRetrievalReq,
-- ArchiveDeletionReq, ArchiveSubOrDelResp or
-- ArchiveRetrievalResp
}
The syntaxes for SignedData and ContentInfo are defined in [RFC3369].
The syntaxes for all request and response types are defined below.
For all response messages, the TAA server MUST include its own
certificate in the certificates field within SignedData. Other
certificates MAY be included. The TAA server MAY provide one or more
CRLs in the crls field within SignedData. The signedAttrs within
SignerInfo MUST include the content-type and message-digest
attributes defined in [RFC3369] (because the content type of the
EncapsulatedContentInfo value is not id-data).
2.1 Archive submission request format
Archive submission requests are defined as follows:
ArchiveSubmissionReq ::= SEQUENCE
{
version TAPVersion DEFAULT v1,
submitterName GeneralName,
policy OBJECT IDENTIFIER OPTIONAL,
archiveControls [0] ArchiveControls OPTIONAL,
archivedData ArchivedData
}
TAA implementations MAY require authentication via CMS, SSL/TLS, or
other means. TAA implementations MAY support alternative submission
formats in addition to ArchiveSubmissionReq.
2.1.1 version
The version field (currently v1) describes the version of the archive
submission request.
Wallace & Chokhani Expires August 2003 [Page 7]
Trusted Archive Protocol (TAP) February 2003
TAPVersion ::= INTEGER { v1(0) }
2.1.2 submitterName
The submitterName field identifies the entity submitting the
associated data for archiving. If authentication is performed, TAA
implementations SHOULD confirm that the value in the submitterName
field is consistent with authenticated information. For successful
requests, TAAs MUST include the submitterName contained in a request
in the resulting archive token.
2.1.3 policy
The policy field, if present, indicates the policy under which the
archive service SHOULD operate with regard to the data submitted as
part of the request.
2.1.4 archiveControls
The archiveControls field may be used to request the TAA to perform
additional actions, for example, server-side validation of the data
field of archiveData or inclusion of a nonce in the response.
TAAs MUST reject requests containing unrecognized or unsupported
archive controls. Archive controls SHOULD be defined such that for
each control included in a request a corresponding control is
included in the response.
ArchiveControls ::= SEQUENCE SIZE (1..MAX) OF ArchiveControl
ArchiveControl ::= SEQUENCE
{
archiveControlType OBJECT IDENTIFIER
archiveControlValue ANY DEFINED BY archiveControlType OPTIONAL
}
2.1.5 archivedData
The archivedData field contains the data to be archived and,
optionally, type information. The type field of archivedData is
advisory and is for use when processing archiveControls and/or for
use by retrieval/deletion clients. The data field of archivedData
contains the data to archive.
ArchivedData ::= SEQUENCE
{
type ArchivedDataType OPTIONAL,
Wallace & Chokhani Expires August 2003 [Page 8]
Trusted Archive Protocol (TAP) February 2003
data OCTET STRING
}
ArchivedDataType ::= CHOICE
{
oid OBJECT IDENTIFIER,
mimeType UTF8String
}
When type information is included in a submission request, TAAs
SHOULD return type information in future retrieval responses
containing the associated archived data.
2.2 Archive submission response format
Archive submission responses are defined as follows:
ArchiveSubOrDelResp ::= SEQUENCE
{
version TAPVersion DEFAULT v1,
status ArchiveStatus,
archiveToken ArchiveToken OPTIONAL,
archiveControls [0] ArchiveControls OPTIONAL
}
ArchiveSubOrDelResp objects MUST be returned in the eContent field of
a CMS SignedData message.
2.2.1 version
The version field (currently v1) describes the version of the archive
submission response.
2.2.2 status
The status field indicates the outcome of request processing and is
comprised of a status code and an optional status string.
ArchiveStatus ::= SEQUENCE
{
code ArchiveStatusCode,
statusString UTF8String OPTIONAL
}
ArchiveStatusCode ::= ENUMERATED
{
success (0), -- success
genericFailure (1), -- misc. unspecified failure
Wallace & Chokhani Expires August 2003 [Page 9]
Trusted Archive Protocol (TAP) February 2003
authenticationFailed (2), -- authentication failed (or absent)
unauthorizedRequest (3), -- submitter(or request) not authorized
unrecognizedControl (4), -- unrecognized or disallowed control
controlFailure (5), -- control processing failed
policyFailure (6), -- policy not supported
timestampFailure (7), -- timestamp could not be obtained
retrievalDelayed (8),-- retrieval may require manual action
unsupportedDataFormat(9) -- format of submitted data not supported
-- add more status codes
}
2.2.3 archiveToken
The archiveToken field contains information that can be used to
request retrieval or deletion of the archived data in the future. An
archiveToken MUST be included in all successful submission responses.
Submitters MUST verify archive tokens as described in section 3 to
ensure that the archive token accurately reflects the submitted data,
i.e. the values in the submitterName, curTime and timestamp fields
are consistent with request.
ArchiveToken ::= ContentInfo
-- content type: id-tap-archiveToken
-- content: ArchiveTokenData
ArchiveTokenData ::= SEQUENCE
{
submitterName GeneralName,
timestamp TimeStampToken,
curTime GeneralizedTime,
trackingInfo TrackingInfos OPTIONAL
}
TrackingInfos ::= SEQUENCE SIZE (1..MAX) OF TrackingInfo
TrackingInfo ::= ContentInfo
The submitterName field contains the value from the submitterName
field in the request.
The timestamp field contains a timestamp generated for the archived
data.
The curTime field contains the TAA time when the archive token was
created.
The trackingInfo field, if present, MAY contain information relevant
only to the TAA and/or MAY contain information that identifies the
TAA, i.e. a URL. Submission clients and retrieval/deletion clients
Wallace & Chokhani Expires August 2003 [Page 10]
Trusted Archive Protocol (TAP) February 2003
are not required to process the contents of the trackingInfo field
but SHOULD be capable of processing the TAALocation TrackingInfo.
2.2.4 archiveControls
The archiveControls field is used to return information associated
with a control included in the request, for example, the outcome of
server-side validation or a nonce from the request. TAAs MUST NOT
include controls in a response that are not associated with controls
in a request. Submission clients SHOULD be able to process controls
in accordance with the control definition.
2.3 Archive retrieval request format
Archive retrieval requests are defined as follows:
ArchiveRetrievalReq ::= SEQUENCE
{
version TAPVersion DEFAULT v1,
requestorName GeneralName,
retrievalRequest ArchiveRetrievalInfo OPTIONAL,
archiveControls [0] ArchiveControls OPTIONAL
}
The request includes information identifying the archived data to
retrieve or to initiate a search.
TAA implementations MAY require authentication via CMS, SSL/TLS, or
other means.
2.3.1 version
The version field (currently v1) describes the version of the archive
retrieval request.
2.3.2 requestorName
The requestorName field identifies the entity requesting retrieval of
an archive package. If authentication is performed, TAA
implementations SHOULD confirm that the value in the requestorName
field is consistent with authenticated information.
2.3.3 retrievalRequest
Wallace & Chokhani Expires August 2003 [Page 11]
Trusted Archive Protocol (TAP) February 2003
The ArchiveRetrievalInfo structure permits clients to fully identify
an archive using an archive token, to initiate a search using a
partial set of information or to complete a delayed request using a
poll reference. The retrievalRequest field may be omitted when the
archiveControls field contains all necessary information, such as
when requesting only trust anchor information via a
TrustAnchorRequest control.
ArchiveRetrievalInfo ::= CHOICE
{
archiveToken [0] ArchiveToken,
archiveInfo [1] ArchiveInfo,
pollReference [2] OCTET STRING
}
The archiveToken field can be used to identify a specific archive
package for retrieval. ArchiveRetrievalResps associated with
ArchiveRetrievalReqs containing an archive token MUST contain a
single ArchivePackage. The archiveInfo field can be used to retrieve
a collection of tokens or archive packages. The pollReference field
can be used to complete a delayed request. The value included in
pollReference is the value returned by the TAA in an
ArchiveRetrievalResp with status set to retrievalDelayed.
ArchiveInfo::= SEQUENCE
{
tokensOnly BOOLEAN DEFAULT TRUE,
submitterName [0] GeneralName OPTIONAL,
timestamp [1] TimeStampToken OPTIONAL,
timeInfo [2] ArchiveTimeInfo OPTIONAL,
}
ArchiveTimeInfo ::= SEQUENCE
{
time GeneralizedTime,
accuracy Accuracy OPTIONAL
}
The tokensOnly field of ArchiveInfo can be used to avoid retrieving
data and cryptographic information for each archive that matches the
query. The fields of ArchiveInfo can be used to query for archive
tokens or archive packages that match the specified search
parameters.
The accuracy field in ArchiveTimeInfo is applied to the time field to
define a range of time used when searching. Accuracy is defined in
[RFC3161].
Wallace & Chokhani Expires August 2003 [Page 12]
Trusted Archive Protocol (TAP) February 2003
2.3.4 archiveControls
The archiveControls field may be used to request additional, optional
services from a TAA, such as a limit on the number of returned
results, a nonce or an indication to return trust anchors known to
the TAA at the time an archive was created.
TAAs MUST reject requests containing unrecognized or unsupported
archive controls.
2.4 Archive retrieval response
Archive retrieval responses are defined as follows:
ArchiveRetrievalResp ::= SEQUENCE
{
version TAPVersion DEFAULT v1,
status ArchiveStatus,
archiveControls [0] ArchiveControls OPTIONAL,
results ArchiveRetrievalResults OPTIONAL
}
ArchiveRetrievalResp objects MUST be returned as the eContent field
of a CMS SignedData message.
2.4.1 version
The version field (currently v1) describes the version of the archive
retrieval response.
2.4.2 status
The status field indicates that outcome of the request processing and
is comprised of a status code and an optional status string.
2.4.3 archiveControls
The archiveControls field is used to return information associated
with a control included in the request. TAAs MUST NOT include
controls in a response that are not associated with controls in a
request. Retrieval/deletion clients SHOULD be able to process
controls in accordance with the control definition.
Wallace & Chokhani Expires August 2003 [Page 13]
Trusted Archive Protocol (TAP) February 2003
2.4.4 results
The results of a successful retrieval request are returned as a
sequence of at least one ArchivePackage, which contains the archive
token and (optionally) the archive package data. A pollReference MAY
be returned in cases where the archive package is not immediately
available, for example, when manual intervention is required to
retrieve an archive.
ArchiveRetrievalResults ::= SEQUENCE SIZE (1..MAX) OF ArchivePackage
ArchivePackage ::= SEQUENCE
{
archiveToken ArchiveToken,
packageData [0] ArchivePackageData OPTIONAL,
pollReference [1] OCTET STRING OPTIONAL
}
ArchivePackageData ::= SEQUENCE
{
digestAlgorithms DigestAlgorithmIdentifiers,
policy OBJECT IDENTIFIER OPTIONAL,
archiveRecord ArchiveRecord,
cryptoInfos [0] CryptoInfos OPTIONAL,
archivedData ArchivedData
}
The digestAlgorithms field identifies all digest algorithms that were
applied to the archived data over the lifetime of the archive record.
To successfully verify all archive record components, the archived
data MUST be hashed using each of the algorithms identified in the
digestAlgorithms field.
The archiveRecord field contains a nested structure with the complete
refresh history for the archived data. TAAs SHOULD store all
cryptographic information necessary to verify each layer of the
archive record in the certificates, crls and unsignedAttrs fields of
the timestamp token, i.e. each timestamp token in the history SHOULD
be self-contained for validation purposes under protection of the
next layer in the archive record. A CryptoInfos unsignedAttrs field
MAY be used to convey OCSP responses and/or trust anchor information.
The object identifier id-tap-cryptoInfos identifies the CryptoInfos
attribute. CryptoInfos attribute values have the ASN.1 type
CryptoInfos.
ArchiveRecord ::= ContentInfo
-- content type: id-tap-archiveRecordData
-- content: ArchiveRecordData
Wallace & Chokhani Expires August 2003 [Page 14]
Trusted Archive Protocol (TAP) February 2003
ArchiveRecordData ::= SEQUENCE
{
timestampedData TimeStampedData, -- covered by timestamp
timestamp TimeStampToken
}
TimeStampedData ::= SEQUENCE
{
prevArchRecord ContentInfo, -- previous record
messageImprint MessageImprint -- hash of archived data
}
The cryptoInfos field contains additional information that may be
useful when verifying the archived data. This information may be
included as a service by a TAA or due to collection of information
requested via an archive control, etc. Retrieval/deletion clients
are free to ignore any or all CryptoInfos contained in an archive
package.
CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF CryptoInfo
CryptoInfo ::= SEQUENCE
{
cryptoInfoType OBJECT IDENTIFIER
cryptoInfoValue ANY DEFINED BY cryptoInfoType
}
The archivedData field contains the data that was submitted to the
TAA and, optionally, type information. The data field within the
ArchivedData structure contains the data to hash using the algorithms
identified in the digestAlgorithms field of ArchivePackageData.
2.5 Archive deletion request
Archive deletion requests are defined as follows:
ArchiveDeletionReq ::= SEQUENCE
{
version TAPVersion DEFAULT v1,
requestorName GeneralName,
archiveToken ArchiveToken,
archiveControls [0] ArchiveControls OPTIONAL
}
The request includes information identifying the archived data to
delete. Deletion requests MUST be authenticated.
2.5.1 version
Wallace & Chokhani Expires August 2003 [Page 15]
Trusted Archive Protocol (TAP) February 2003
The version field (currently v1) describes the version of the archive
deletion request.
2.5.2 requestorName
The requestorName field identifies the entity requesting retrieval of
an archive package. If authentication is performed, TAA
implementations SHOULD confirm that the value in the requestorName
field is consistent with authenticated information.
2.5.3 archiveToken
The archive token field identifies the archived data to delete.
2.5.4 archiveControls
The archiveControls field may be used to request additional, optional
services from a TAA.
TAAs MUST reject requests containing unrecognized or unsupported
archive controls.
2.6 Archive deletion response
Archive deletion responses are of type ArchiveSubOrDelResp as defined
above. The meaning of each field in the context of a deletion
response is described below.
ArchiveSubOrDelResp objects MUST be returned in the eContent field of
a CMS SignedData message.
2.6.1 version
The version field (currently v1) describes the version of the archive
deletion response.
2.6.2 status
The status field indicates that outcome of the request processing and
is comprised of a status code and an optional status string.
Wallace & Chokhani Expires August 2003 [Page 16]
Trusted Archive Protocol (TAP) February 2003
2.6.3 archiveToken
The archiveToken field contains information identifying the deleted
archive data. Successful responses MUST include an archiveToken
identifying the archive that was deleted. The archiveToken MUST
match the archiveToken contained in the deletion request.
2.6.4 archiveControls
The archiveControls field is used to return information associated
with a control included in the request. TAAs MUST NOT include
controls in a response that are not associated with controls in a
request. Retrieval/deletion clients SHOULD be able to process
controls in accordance with the control definition.
3. Validation
The signature on all TAA responses MUST be verified. TAA signatures
on protocol transactions should be verified using current trust
anchors known to the client. This section discusses additional
validation steps for each type of transaction.
3.1 Submission
After verifying the signature of a successful ArchiveSubOrDelResp,
compliant submission clients MUST perform the following processing of
the submission response contents:
- Process each archive control per definition of control;
- Verify the signature of the Time Stamp Authority (TSA) on the
timestamp token contained in the archive token;
- Verify that the hash contained in the timestamp token
represents the hash of the data submitted by the client to the
TAA; and
- Verify that the time on the timestamp token is reasonably close
to the current time.
Verification that the curTime in the archive token is reasonably
close to the current time is RECOMMENDED and confirmation that the
submitterName is correct is RECOMMENDED.
For the signature verification of the TSA, the submitter can choose
to use the trust anchors returned by the TAA, if present, or rely on
its own list of trust anchors.
Controls that involve TAA-alteration of submitted data, i.e.
collection and inclusion of relevant cryptographic information in the
submitted data, may impact the verification of the timestamp field.
Wallace & Chokhani Expires August 2003 [Page 17]
Trusted Archive Protocol (TAP) February 2003
3.2 Retrieval
After verifying the signature of a successful ArchiveRetrievalResp,
compliant retrieval/deletion clients MUST perform the following
processing of the retrieval response contents:
- If an archive token was included in the request, the archive
token the ArchivePackage should be compared with the requested
archive token;
- Process each archive control per definition of control;
- Hash the data field of the archived data using each of the
algorithms identified in the digestAlgorithms field of the
ArchivePackage data structure;
- Verify the outermost timestamp token;
- Verify that the timestamp on the outermost token is current;
- Verify all remaining timestamp tokens; and
- Verify that in each instance a new timestamp token was applied
prior to the preceding timestamp token expiry.
See the security considerations section for additional information
regarding selection of the trust anchors to be used for timestamp
token verification.
The verification of the archived data is beyond the scope of this
specification. This specification provides mechanism to carry all
the data required to make such verification possible, but the TAA
need not be aware of the data format. For example, if a submitter
submits a signed CMS message with all the certificates, revocation
information (CRLs and OCSP responses), and trust anchors required to
verify the message, that message could be verified upon retrieval to
prove that the signature was valid at the time of the inner most
timestamp on the retrieved data.
The archiveRecord MUST be verified as described above by verifying
the timestamp present in each layer of the ArchiveRecord structure.
Layers should be validated in turn beginning with the outermost layer
and ending with the innermost layer. The innermost layer is simply
the timestamp obtained for the archived data; outer layers are
ArchiveRecord structures, which contain the previous record, a hash
of the archived data and a timestamp. When verifying the innermost
timestamp, verify that the hash contained in the timestamp token
represents the hash of the archived data. When verifying outer
timestamps, verify that the hash contained in the timestamp token
matches the hash of the corresponding TimeStampedData structure and
that the hash contained in the TimeStampedData structure represents a
hash of the archived data.
Timestamp token signatures MAY be verified using client-obtained
trust anchor and revocation information or using information provided
Wallace & Chokhani Expires August 2003 [Page 18]
Trusted Archive Protocol (TAP) February 2003
by the TAA. TAAs MAY provide relevant cryptographic information in
the CryptoInfos unsigned attribute of the SignerInfo structure and
the certificates and crls fields of the SignedData structure of each
timestamp token.
ArchiveRecord verification terminates when the innermost ContentInfo
object containing a timestamp token (covering the archived data) is
verified.
*---------------------------------------------------------------*
* ContentType: id-tap-archiveRecordData *
* Content: ArchiveRecordData w/ previous archive record *
* *-------------------------------------------------------* *
* * ContentType: id-tap-archiveRecordData * *
* * Content: ArchiveRecordData w/ previous archive record * *
* * *------------------------------------------* * *
* * * ContentType: id-ct-TSTInfo * * *
* * * Content: TSTInfo covering archived data * * *
* * *------------------------------------------* * *
* *-------------------------------------------------------* *
*---------------------------------------------------------------*
Figure 1: ArchiveRecord following two refresh operations
3.3 Deletion
Following receipt and verification of a successful
ArchiveSubOrDelResp no further validation steps need be performed.
However, inspection of the ArchiveControls and/or ArchiveToken
returned in the response SHOULD be performed.
Deletion requests MUST be authenticated; it is RECOMMENDED that
deletion requests be digitally signed in order to protect against
unauthorized parties from issuing or modifying deletion requests.
The deletion request client MUST perform the following processing of
the deletion response in order to be compliant with this
specification:
- Process each archive control per definition of control;
- Verify the signature of the TAA on the response; and
- Match the archive token returned with archive token requested.
4. Transports
There are no mandatory transport mechanisms for TAP messages. The
mechanisms described below are optional.
4.1 TAP over HTTP
Wallace & Chokhani Expires August 2003 [Page 19]
Trusted Archive Protocol (TAP) February 2003
This section describes the formatting conventions for TAP requests
and responses when carried by HTTP.
4.1.1 TAP Requests
HTTP-based TAP requests can use the POST method to submit their
requests. Where confidentiality is a requirement, TAP transactions
exchanged using HTTP MAY be protected using either TLS/SSL or some
other lower layer protocol.
When authentication is a requirement, the request could be signed or
the TAP transactions exchanged using HTTP MAY be protected using
client authenticated TLS/SSL or some other lower layer protocol.
A TAP request using the POST method is constructed as follows:
The Content-Type header MUST have the value "application/tap-
request".
The Content-Length header MUST be present and have the exact
length of the request.
The body of the message is the binary value of the DER encoding
of the request. Other HTTP headers MAY be present and MAY be
ignored if not understood by the requestor.
Sample Content-Type header:
Content-Type: application/tap-request
4.1.2 TAP Response
An HTTP-based TAP response is composed of the appropriate HTTP
headers, followed by the binary value of the DER encoding of the
response.
The Content-Type header MUST have the value "application/tap-
response".
The Content-Length header MUST be present and specify the
length of the response.
Other HTTP headers MAY be present and MAY be ignored if not
understood by the requestor.
Wallace & Chokhani Expires August 2003 [Page 20]
Trusted Archive Protocol (TAP) February 2003
5. ArchiveControls, TrackingInfos and CryptoInfos
5.1 Archive Controls
This document defines several ArchiveControls that MAY be supported
by TAA implementations. Additional controls MAY also be supported.
When a TAA receives a request with an unrecognized or unsupported
control a response indicating failure MUST be generated and returned
to the submitter of the request. Archive controls typically work in
a request/response fashion, i.e. when a client includes an
ArchiveControl in a request a corresponding control is expected in
the response.
5.1.1 Nonce
A nonce may be included in an ArchiveControls structure using the id-
tap-nonce object identifier and following ASN.1 structure:
Nonce ::= OCTET STRING
A successful, associated response message MUST include an archive
control with the archiveControlType field set to id-tap-nonce and the
nonce from the request in the archiveControlValue field.
5.1.2 TrustAnchorRequest
As part of an ArchiveRetrievalRequest, requestors may request the set
of trust anchors known to the TAA at a specific time using the id-
tap-trustAnchorRequest object identifier and following ASN.1
structure:
TrustAnchorRequest ::= GeneralizedTime
A successful, associated ArchiveRetrievalResponse MUST include an
archive control with the archiveControlType field set to id-tap-
trustAnchorResponse and a TrustAnchorResponse in the
archiveControlValue field. TrustAnchorResponse contains information
about the trust anchors that were known to the TAA at the specified
time. This information may be useful when verifying signatures
applied to archived data.
TrustAnchorResponse::= SEQUENCE SIZE (0..MAX) OF TrustAnchorInfo
TrustAnchorInfo ::= CHOICE
{
cert Certificate,
rawInfo [0] RawTrustAnchorInfo
}
Wallace & Chokhani Expires August 2003 [Page 21]
Trusted Archive Protocol (TAP) February 2003
RawTrustAnchorInfo ::= SEQUENCE
{
name Name,
algorithm AlgorithmIdentifier,
pubKey BIT STRING
}
5.1.3 TSA Policy
The TSAPolicy archive control can be used to request that the initial
timestamp obtained for an archived data submission be issued under a
specific policy. A policy may be included in an ArchiveControls
structure using the id-tap-tsaPolicy object identifier and following
ASN.1 structure:
TSAPolicy ::= OBJECT IDENTIFIER
The TSAPolicy ArchiveControl has no response component.
5.2 TrackingInfos
This specification defines a TrackingInfo. TAA implementations are
free to define tracking information objects as necessary. Clients
are not required to process tracking information but SHOULD be
capable of processing the TAALocation TrackingInfo.
5.2.1 TAALocation
Long-term identification of a TAA may not be practical. TAAs MAY
include a TAALocation TrackingInfo to assist bearers of an archive
token to locate a TAA for retrieval or deletion purposes.
TAALocations may be included in a TrackingInfos structure using the
id-tap-taaLocation object identifier and following ASN.1 structure:
TAALocation ::= GeneralName
5.3 CryptoInfos
Clients are not required to process CryptoInfos. This document
defines several CryptoInfos that MAY be supported by client or TAA
implementations.
5.3.1 Certificates
Wallace & Chokhani Expires August 2003 [Page 22]
Trusted Archive Protocol (TAP) February 2003
Certificates may be included in a CryptoInfos structure using the id-
tap-certificates object identifier and following ASN.1 structure:
Certificates ::= SEQUENCE SIZE (1..MAX) OF Certificate
5.3.2 OCSPResponses
OCSPResponses may be included in a CryptoInfos structure using the
id-tap-ocspResponses object identifier and following ASN.1 structure:
OCSPResponses ::= SEQUENCE SIZE (1..MAX) OF OCSPResponse
5.3.3 CRLs
CRLs may be included in a CryptoInfos structure using the id-tap-crls
object identifier and following ASN.1 structure:
CRLs ::= SEQUENCE SIZE (1..MAX) OF CertificateList
6. TAP ASN.1 Module
PKIXTAP
-- {iso(1) identified-organization(3) dod(6) internet(1)
-- security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tap(TBD) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
TimeStampToken, Accuracy
FROM
PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13) }
Name
FROM
InformationFramework { joint-iso-itu-t ds(5) module(1)
informationFramework(1) 3 }
ContentInfo
FROM
CryptographicMessageSyntax {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}
Wallace & Chokhani Expires August 2003 [Page 23]
Trusted Archive Protocol (TAP) February 2003
Certificate, CertificateList, AlgorithmIdentifier
FROM
AuthenticationFramework {joint-iso-itu-t ds(5) module(1)
usefulDefinitions(0) 4}
GeneralName
FROM
CertificateExtensions {joint-iso-itu-t ds(5) module(1)
certificateExtensions(26) 4}
OCSPResponse
FROM
OCSP;
--Submission transactions
ArchiveSubmissionReq ::= SEQUENCE
{
version TAPVersion DEFAULT v1,
submitterName GeneralName,
policy OBJECT IDENTIFIER OPTIONAL,
archiveControls [0] ArchiveControls OPTIONAL,
archivedData ArchivedData
}
TAPVersion ::= INTEGER { v1(0) }
ArchiveControls ::= SEQUENCE SIZE (1..MAX) OF ArchiveControl
ArchiveControl ::= SEQUENCE
{
archiveControlType OBJECT IDENTIFIER,
archiveControlValue ANY DEFINED BY archiveControlType OPTIONAL
}
ArchivedData ::= SEQUENCE
{
type ArchivedDataType OPTIONAL,
data OCTET STRING
}
ArchivedDataType ::= CHOICE
{
oid OBJECT IDENTIFIER,
mimeType UTF8String
}
ArchiveSubOrDelResp ::= SEQUENCE
{
version TAPVersion DEFAULT v1,
status ArchiveStatus,
Wallace & Chokhani Expires August 2003 [Page 24]
Trusted Archive Protocol (TAP) February 2003
archiveToken ArchiveToken OPTIONAL,
archiveControls [0] ArchiveControls OPTIONAL
}
ArchiveStatus ::= SEQUENCE
{
code ArchiveStatusCode,
statusString UTF8String OPTIONAL
}
ArchiveStatusCode ::= ENUMERATED
{
success (0),-- success
genericFailure (1),-- misc. unspecified failure
authenticationFailed (2),-- authentication failed (or absent)
unauthorizedRequest (3),-- submitter(or requestor) not authorized
unrecognizedControl (4),-- unrecognized or disallowed control
controlFailure (5),-- control processing failed
policyFailure (6),-- policy not supported
timestampFailure (7),-- timestamp could not be obtained
retrievalDelayed (8),-- retrieval may require manual action
unsupportedDataFormat(9) -- format of submitted data not supported
-- add more status codes
}
ArchiveToken ::= ContentInfo
-- content type: id-tap-archiveToken
-- content: ArchiveTokenData
ArchiveTokenData ::= SEQUENCE
{
submitterName GeneralName,
timestamp TimeStampToken,
curTime GeneralizedTime,
trackingInfo TrackingInfos OPTIONAL
}
TrackingInfos ::= SEQUENCE SIZE (1..MAX) OF TrackingInfo
TrackingInfo ::= ContentInfo
--Retrieval transactions
ArchiveRetrievalReq ::= SEQUENCE
{
version TAPVersion DEFAULT v1,
requestorName GeneralName,
retrievalRequest ArchiveRetrievalInfo OPTIONAL,
archiveControls [0] ArchiveControls OPTIONAL
}
ArchiveRetrievalInfo ::= CHOICE
Wallace & Chokhani Expires August 2003 [Page 25]
Trusted Archive Protocol (TAP) February 2003
{
archiveToken [0] ArchiveToken,
archiveInfo [1] ArchiveInfo,
pollReference [2] OCTET STRING
}
ArchiveInfo::= SEQUENCE
{
tokensOnly BOOLEAN DEFAULT TRUE,
submitterName [0] GeneralName OPTIONAL,
timestamp [1] TimeStampToken OPTIONAL,
timeInfo [2] ArchiveTimeInfo OPTIONAL
}
ArchiveTimeInfo ::= SEQUENCE
{
time GeneralizedTime,
accuracy Accuracy OPTIONAL
}
ArchiveRetrievalResp ::= SEQUENCE
{
version TAPVersion DEFAULT v1,
status ArchiveStatus,
archiveControls [0] ArchiveControls OPTIONAL,
results ArchiveRetrievalResults OPTIONAL
}
ArchiveRetrievalResults ::= SEQUENCE SIZE (1..MAX) OF ArchivePackage
ArchivePackage ::= SEQUENCE
{
archiveToken ArchiveToken,
packageData [0] ArchivePackageData OPTIONAL,
pollReference [1] OCTET STRING OPTIONAL
}
ArchivePackageData ::= SEQUENCE
{
digestAlgorithms DigestAlgorithmIdentifiers,
policy OBJECT IDENTIFIER OPTIONAL,
archiveRecord ArchiveRecord,
cryptoInfos [0] CryptoInfos OPTIONAL,
archivedData ArchivedData
}
ArchiveRecord ::= ContentInfo
-- content type: id-tap-archiveRecordData
-- content: ArchiveRecordData
Wallace & Chokhani Expires August 2003 [Page 26]
Trusted Archive Protocol (TAP) February 2003
CryptoInfos ::= SEQUENCE SIZE (1..MAX) OF CryptoInfo
CryptoInfo ::= ContentInfo
ArchiveRecordData ::= SEQUENCE
{
timestampedData TimeStampedData, -- covered by timestamp
timestamp TimeStampToken
}
TimeStampedData ::= SEQUENCE
{
prevArchRecord ContentInfo, -- previous record
messageImprint MessageImprint -- hash of archived data
}
--Deletion transactions
ArchiveDeletionReq ::= SEQUENCE
{
version TAPVersion DEFAULT v1,
requestorName GeneralName,
archiveToken ArchiveToken,
archiveControls [0] ArchiveControls OPTIONAL
}
-- ArchiveControls, TrackingInfos and CryptoInfos
Nonce ::= OCTET STRING
TSAPolicy ::= OBJECT IDENTIFIER
TrustAnchorRequest ::= GeneralizedTime
TrustAnchorResponse::= SEQUENCE SIZE (0..MAX) OF TrustAnchorInfo
TrustAnchorInfo ::= CHOICE
{
cert Certificate,
rawInfo [0] RawTrustAnchorInfo
}
RawTrustAnchorInfo ::= SEQUENCE
{
name Name,
algorithm AlgorithmIdentifier,
pubKey BIT STRING
}
-- tracking infos
TAALocation ::= GeneralName
-- crypto infos
Certificates ::= SEQUENCE SIZE (1..MAX) OF Certificate
Wallace & Chokhani Expires August 2003 [Page 27]
Trusted Archive Protocol (TAP) February 2003
CRLs ::= SEQUENCE SIZE (1..MAX) OF CertificateList
OCSPResponses ::= SEQUENCE SIZE (1..MAX) OF OCSPResponse
TrustAnchorInfos::= SEQUENCE SIZE (1..MAX) OF TrustAnchorInfo
-- oid categories
-- id-tap OBJECT IDENTIFIER ::= {id-pkix 22}
-- id-tap-msgs OBJECT IDENTIFIER ::= {id-tap 1}
-- id-tap-types OBJECT IDENTIFIER ::= {id-tap 2}
-- id-tap-cryptoInfos OBJECT IDENTIFIER ::= {id-tap 3}
-- id-tap-controls OBJECT IDENTIFIER ::= {id-tap 4}
-- id-tap-trackingInfos OBJECT IDENTIFIER ::= {id-tap 5}
-- oids related to protocol messages
-- id-tap-archiveReq OBJECT IDENTIFIER ::={id-tap-msgs 1}
-- id-tap-archiveSubOrDelResp OBJECT IDENTIFIER ::={id-tap-msgs 2}
-- id-tap-archiveRetrievalReq OBJECT IDENTIFIER ::={id-tap-msgs 3}
-- id-tap-archiveRetrievalResp OBJECT IDENTIFIER ::={id-tap-msgs 4}
-- id-tap-archiveDeletionReq OBJECT IDENTIFIER ::={id-tap-msgs 5}
-- extended key usage oid
-- id-kp-trustedArchive OBJECT IDENTIFIER ::= {id-kp 15}
-- oids for content info or attribute types
-- id-tap-archiveRecordData OBJECT IDENTIFIER::={id-tap-types 1}
-- id-tap-cryptoInfos OBJECT IDENTIFIER::={id-tap-types 2}
-- id-tap-archiveToken OBJECT IDENTIFIER::={id-tap-types 3}
-- oids for crypto info types
-- id-tap-certificates OBJECT IDENTIFIER ::={id-tap-cryptoInfos 1}
-- id-tap-crls OBJECT IDENTIFIER ::={id-tap-cryptoInfos 2}
-- id-tap-ocspResponses OBJECT IDENTIFIER ::={id-tap-cryptoInfos 3}
-- id-tap-TAInfos OBJECT IDENTIFIER ::={id-tap-cryptoInfos 4}
-- oids for archive controls
-- id-tap-nonce OBJECT IDENTIFIER::={id-tap-controls 1}
-- id-tap-trustAnchorRequest OBJECT IDENTIFIER::={id-tap-controls 2}
-- id-tap-tsaPolicy OBJECT IDENTIFIER::={id-tap-controls 3}
-- oids for tracking infos
-- id-tap-taaLocation OBJECT IDENTIFIER ::= {id-tap-trackingInfos 1}
END
7. Security Considerations
7.1 Trust Anchors for Timestamp and Other Signature Verification on
Archive Retrieval
Wallace & Chokhani Expires August 2003 [Page 28]
Trusted Archive Protocol (TAP) February 2003
TAAs can provide all or some of the trust anchors upon retrieval.
These include all the trust anchors required to verify the various
timestamps in the archive record and/or all the trust anchors known
to the TAA at the time of the archive submission (i.e., the timestamp
on the archived data). The latter set of trust anchors may be useful
in digital signature verification on the archived data, if the data
was signed.
Trust anchors provided by the TAA upon archive retrieval are
transmitted securely since they are included in the signed envelope
of the retrieval response. The relying party (i.e., the retrieval
client) MUST use a trust anchor it trusts independent of the trust
anchors provided by the TAA to verify the TAA signature on the
retrieval response.
The relying party (i.e., the retrieval client) can trust the TAA
provided trust anchors or can ignore them. In the latter case, only
the TSA (and not the TAA) needs to be trusted for the integrity of
the archived data. In other words, the relying party will be able to
detect the modifications made to the archived data by the TAA.
Refreshing the timestamp on the archived data before the latest
(i.e., most current or outermost) timestamp expires ensures this.
7.2 Algorithm and Technology Advances
In order to protect against algorithm (i.e., hashing and digital
signature) compromise and/or computing technology advances,
timestamps are periodically refreshed. For each timestamp token
refresh, the archived data is hashed using the latest secure hashing
algorithm and a timestamp token generated using a current, secure
digital signature algorithm.
7.3 Authorizations
Who is "authorized" to use the TAA is the matter of local policy. If
an authorization model is implemented for any of the archive services
(i.e., submission, deletion, and retrieval), the corresponding
service request MUST be authenticated by the TAA in order to validate
the requestor authorization.
This specification does not mandate any authorization requirements.
To claim compliance with this specification, the deletion request
MUST be authenticated.
It is RECOMMENDED that a prudent local policy be established to check
the authorizations for deletion requests. For example, only the
submitter or authorized requestors from submitting organizations
should be able to delete the data.
Wallace & Chokhani Expires August 2003 [Page 29]
Trusted Archive Protocol (TAP) February 2003
7.4 TSA Policy
This specification does not mandate how a timestamp under a specific
TSA policy is requested. It is left as a matter of local policy.
Some of the examples for requesting specific TSA policy are:
- Use of archive control (control identified by id-tap-tsaPolicy
serves this purpose)
- TAA not requesting any policy
- TAA requesting specific policy based on its own requirements
- TAA mapping the TAA policy to TSA policy
7.5 Other
Data formats archived by a TAA may have requirements that relate to
long-term non-repudiation beyond those identified in this
specification.
TAAs should be operated with appropriate physical, procedural and
personnel security controls.
TAAs must be able to obtain a trusted timestamp (either by
implementing timestamp functionality or by access to a timestamp
service). Timestamp-related security considerations apply (see
[RFC3161]).
In support of dispute resolution, it may be desirable for TAAs to
archive Certificate Policy and Certification Practice Statement
documents.
It may be desirable to maintain archive data on Write Once/Read Many
(WORM) media.
ArchiveControls that request server-side alteration of data, i.e.
collection of certificates and CRLs, should use a response format
that permits submitters to verify the timestamp contained in the
archive token.
8. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in [RFC2028]. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
Wallace & Chokhani Expires August 2003 [Page 30]
Trusted Archive Protocol (TAP) February 2003
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 Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights, which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
[RFC3161] identifies the following eight (8) United States Patents
related to time stamping, listed in chronological order. This may
not be an exhaustive list. Other patents MAY exist or be issued at
any time. This list is provided for informational purposes; to date,
the IETF has not been notified of intellectual property rights
claimed in regard to any of the specification contained in this
document. Should this situation change, the current status may be
found at the online list of claimed rights (IETF Page of Intellectual
Property Rights Notices).
Implementers of this protocol SHOULD perform their own patent search
and determine whether or not any encumbrances exist on their
implementation.
Users of this protocol SHOULD perform their own patent search and
determine whether or not any encumbrances exist on the use of this
standard.
# 5,001,752 Public/Key Date-Time Notary Facility
Filing date: October 13, 1989
Issued: March 19, 1991
Inventor: Addison M. Fischer
# 5,022,080 Electronic Notary
Filing date: April 16, 1989
Issued: June 4, 1991
Inventors: Robert T. Durst, Kevin D. Hunter
# 5,136,643 Public/Key Date-Time Notary Facility
Filing date: December 20, 1990
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
Filing date: August 2, 1990
Issued: August 4, 1992
Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Bell Communications Research, Inc.,
Wallace & Chokhani Expires August 2003 [Page 31]
Trusted Archive Protocol (TAP) February 2003
# 5,136,647 Method for Secure Time-Stamping of Digital Documents
Filing date: August 2, 1990
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
Filing date: December 21, 1992
Issued: December 13, 1994
Inventors: Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Bell Communications Research, Inc.,
# 5,422,953 Personal Date/Time Notary Device
Filing date: May 5, 1993
Issued: June 6, 1995
Inventor: Addison M. Fischer
# 5,781,629 Digital Document Authentication System
Filing date: February 21, 1997
Issued: July 14, 1998
Inventor: Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Surety Technologies, Inc.,
Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2028] Bradner, S. and R. Hovey, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028, October
1996.
[RFC2119] Bradner, S. and , "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3161] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, August 2001.
[RFC3369] Housley, R., "Cryptographic Message Syntax", RFC 3369,
August 2002.
Informative References
[RFC3126] Pinkas, D., Ross, J., and N. Pope, "Electronic Signature
Formats for long term electronic signatures", RFC 3126,
September 2001.
Wallace & Chokhani Expires August 2003 [Page 32]
Trusted Archive Protocol (TAP) February 2003
Authors' Addresses
Carl Wallace
Cygnacom Solutions
7927 Jones Branch Dr. Suite 100 West
McLean, VA 22102-3305
Email: cwallace@cygnacom.com
Santosh Chokhani
Orion Security Solutions
3410 N. Buchanan Street
Arlington, VA 22207
Email: chokhani@orionsec.com
Wallace & Chokhani Expires August 2003 [Page 33]
Trusted Archive Protocol (TAP) February 2003
Appendix A: Support for non-TAP aware clients and alternative submission
request formats
In some cases it may be desirable to accept archive submissions from
clients that are not TAP-aware. The following table describes the
submission alternatives.
Client Auth. Message format Archive target
software method
TAP-aware Transport ContentInfo containing Contents of
and/or CMS SignedData w/ data field in
ArchiveSubmissionReq in ArchivedData
encapContentInfo field structure
TAP-aware Transport ContentInfo containing Contents of
ArchiveSubmissionReq data field in
ArchivedData
structure
Non-TAP- Transport Any other format Entire message
aware and/or (possibly unknown or
message determined from
format transport, i.e. mime
type, file extension,
etc.)
Retrieval and deletion requests are likely to be relatively rare
compared to submission requests. In the interest of supporting a
broad range of submission clients, it may be desirable to support
alternative archive submission formats, for example, an XML
submission request. Non-TAP-compliant submission formats MUST NOT
use TAP-defined transport layer type information. TAA
implementations could support alternative submission types via a
plug-in architecture. Regardless of submission means, archive
information MUST be represented using TAP-defined archive tokens,
records and packages for retrieval and deletion requests.
Wallace & Chokhani Expires August 2003 [Page 34]
