WDIFF

draft-ietf-pkix-dcs-00.txt --> draft-ietf-pkix-dcs-01.txt

PKIX Working Group R. Zuccherato(Entrust Technologies) expires in six months September 23, 1998
July 12, 1999

Internet X.509 Public Key Infrastructure
Data Certification Server Protocols
<draft-ietf-pkix-dcs-00.txt> <draft-ietf-pkix-dcs-01.txt>

Status of this Memo

This document is an Internet-Draft. 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 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."

To learn the current status

The list of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document describes a general data certification service and the
protocols to be used when communicating with it. The Data
Certification Server is a Trusted Third Party (TTP) that can be used
as one component in building reliable non-repudiation services (see
[ISONR]). Useful Data Certification Server responsibilities in a PKI
are to validate signatures and to provide up-to-date information
regarding the status of public key certificates.

We give examples of how to use the Data Certification Server to
extend the lifetime of a signature beyond key expiry or revocation
and to query the Data Certification Server regarding the status of a
public key certificate.

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

Adams, Sylvester, Zuccherato [Page 1]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999

1. Introduction

A Data Certification Server (DCS) is a Trusted Third Party that verifies
provides an assertion of the correctness usability of specific the data submitted transmitted to it.
The assertion may be providing a time stamp, a validation of a public
key certification or a signed document.

The Data Certification Server provides the data certification service
in order that non-repudiation non-repudiability evidence may be constructed relating
to the validity and correctness of an entity's claim to possess data,
the validity and revocation status of an entity's public key
certificate and/or the validity and correctness of another entity's
signature.

When certifying possession of data or another entity's signature, the
DCS

Document Expiration: March 23, 1999 Page 1 verifies the mathematical correctness of the actual signature
value contained in the request and also checks the full certification
path from the signing entity to a trusted point (e.g., the DCS's CA,
or the root CA in a hierarchy). The DCS MAY be able to rely on all
relevant CRLs and ARLs, or the DCS MAY need to supplement this with
access to more current status information from the CA. It then
includes a trusted time and creates a data certification token. (See
Appendix B.)

When certifying a public key certificate, the DCS verifies that the
certificate included in the request is a valid certificate and
determines its revocation status at a specified time.

Again, it checks the full certification path from the certificate
signing entity to a trusted point. The DCS MAY be able to rely on
all relevant CRLs and ARLs, or the DCS MAY need to supplement this
with access to more current status information from the CA. It
includes this information, along with a trusted time, to create a
Data Certification Token. (See Appendix C.)

The presence of a data certification token supports non-repudiation
in two ways. It provides evidence that a signature or public key
certificate was valid at the time indicated in the token. The token
can be used even after the corresponding public key certificate
expires and its revocation information is no longer available on CRLs
(for example). The production of a data certification token in
response to a signed request for certification of another signature
or public key certificate also provides evidence that due diligence
was performed by the requester in validating the signature or public
key certificate.

It is

DCS does not recommended that replace the DCS be used as a substitute usage of CRLs and OCSP for normal public key
certificate revocation checking (e.g. CRLs, OCSP) in large open environments, due to

Adams, Sylvester, Zuccherato [Page 2]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999

concerns about the scalability of this protocol. It should only be
used to support non-repudiation or to supplement more traditional
revocation services when more timely information is required.

An important application of DCS is an enterprise environment where
all security decision are based on company wide rules. A company
wide DCS service can be used to delegate all technical decisions
(e.g., path validation, trust configuration) to a centrally managed
service.

In all cases, the trust that PKI entities have in the Data
Certification Server is transferred to the contents of the data
certification token (just as trust in a CA is transferred to the
public key certificates that it issues). As a particular example, examples, a
data certification token pertaining to a signature may be useful for
extending the life of that signature beyond the expiry or subsequent
revocation of its corresponding verification certificate. certificate; and
including a DCS response as an authenticated attribute in a signature
allows to include an additional attestion about the usability of a
certificate to be used for signing.

It is outside the scope of this document to describe different
operational scenarios, or usages for DCS. This document describes
basic services and protocols.

2. Requirements of the Data Certification Server

The Data Certification Server Protocols can be used in different
service contexts. Examples include company wide centralised data
validation services (verification of signatures, certification of of
company certificates), service to cooperate in a multi-organisation
community, or general third party services for time stamping or data
archival.

The Data Certification Server is REQUIRED to:

1. verify the correctness of the enclosed digital signature
(according to [RFC2459]) using all appropriate status information
and public key certificates and produce a signed data
certification token attesting to certifying the validity of the signature,
if asked by the requester.

2. verify the validity (according to [CCP]) [RFC2459]) of the one or more
enclosed public key certificate certificates and its their revocation status at
the specified time using all appropriate status information information,
and/or other external services (including DCS and OCSP) and public
key certificates and produce a signed data certification token
attesting to
certifying the validity and revocation status of the public

Document Expiration: March 23,

Adams, Sylvester, Zuccherato [Page 3]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999 Page 2

key certificate, if asked by the requester.

3. include a monotonically incrementing value of the increasing time of day value
or a time stamp token into its data certification token.

4. include within each signed data certification token an
identifier to uniquely determine the trust and validation policy
used for this signature.

5. sign each data certification token using a key generated
exclusively for this purpose and have this property of the key
indicated on the corresponding public key certificate.

6. indicate in the token whether or not the signature or public key
certificate
certificate(s) was verified, and if not, the reason the
verification failed.

7. provide a signed receipt (i.e., in the form of an appropriately
defined data certification token) to the requester, where
appropriate, as defined by policy.

3. Data Certification Server Transactions

As The DCS service definition
and the first transaction of this mechanism, policy defines how much information that have been used
by the requesting entity
requests a DCS service to determine the response status, e.g., public
key certificates, OCSP and DCS responses will be included in
a DCS Token.

The [TSA] defines additional requirements: The DCS protocols can be
used as a replacement for the services defined in [TSA], in this case
the requirements of [TSA] apply to that service.

A DCS service may be combined with or use archiving and logging
systems, in order to serve as a strong building block in non-
repudiation services.

3. Data Certification Server Transactions

As the first transaction of this mechanism, the requesting entity
requests a certification by sending a request (which is or includes a data certification request, request as
defined below), below, including the data for which validity and/or
possession is to be certified, to the Data Certification Server.
Upon receiving the request, the Data Certification Server reviews and
checks the validity of the request. A valid request is of the form described
decribed later in Section 5 of this document, can be properly decoded, and is from
a supported Data Certification Server subscriber. subscriber (in case when signed
requests are required).

If the request is valid, the Data Certification Server performs the certification all
necessary validations in order to create a certification, and sends a
response (which is or includes a data certification token, as defined

Adams, Sylvester, Zuccherato [Page 4]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999

below) to the requesting entity. Otherwise, the Data Certification
Server returns an error message (i.e., in the form of an
appropriately defined data certification token).

Upon receiving the token, the requesting entity verifies its
validity. The requester SHOULD verify that it contains the correct
time, the correct name for the DCS, the correct data imprint, a valid
signature, and satisfactory status, service and policy fields. Since the

A DCS's certificate may have been revoked, revoked. It is up to the appropriate status information
SHOULD be checked local
application to verify that the whether or not a DCS certificate is still
valid. Depending on the usage environment (e.g. organisation's
central trust point or global time stamp authority) different methods
(online or out of band, or CRLs) need to be used.

The token can now be used to authenticate the correctness or
possession of the corresponding data.

4. Identification of the DCS

The DCS MUST sign all data certification messages with a key reserved
specifically
explicitely for that purpose. The corresponding certificate MUST
contain the extended key usage field extension as defined in [CCP]
[RFC2459] Section 4.2.1.14 with KeyPurposeID having value id-kp-dcs.
This extension MUST be critical.

id-kp-dcs OBJECT IDENTIFIER ::= {id-kp ??}
-- Certifying the validity of certain information. Key X}

Consistent key usage bits
-- that may be consistent: bits: digitalSignature, nonRepudiation

Document Expiration: March 23, 1999 Page 3

5. Request and Token Formats

The ServiceType type indicates which type

A DCS's certificate MAY contain an Authority Information Access
extension [RFC2459] in order to convey the method of Data Certification Server
service is required.

ServiceType contacting the
DCS. The accessMethod field in this extension MUST contain the OID
id-ad-dcs:

id-ad OBJECT IDENTIFIER ::= INTEGER { cpd(1), cs(2), cpkc(3) id-pkix 48 }
id-ad-dcs OBJECT IDENTIFIER ::= { id-ad X }

The value cpd (Certify Possession of Data) is used when only the
signature on the data certification request (i.e., possession of the
data in accessLocation field defines the request) is transport (e.g. an
URL) used to be verified. In this case access the DCS.

5. Service and Data
Certification Server would be merely providing evidence that the Types

A DCS MAY support any subset of the following services: Certify
Possession of Data, Certify Signature, Certify Public Key Certificate

The Certify Possession of Data service provides evidence that the
requester possessed the data in the request and a valid signature key or that data existed at the time indicated. This is really an extension of the Time Stamp
Authority [TSA] indicated

Adams, Sylvester, Zuccherato [Page 5]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999

in that we are given the additional assurance about the
validity of the signature, as well as the request/response. A time before which it was
applied. stamping services as described in
[TSA] is a subset of this service.

The value cs (Certify Signature) Certify Signature service is used when another entity's signature
is to be validated. The resulting token can then be used to support
non-repudiation services or services, to allow use of the signature beyond public
key certificate revocation or expiry. expiry, or simply to delegate signature
validation to a trusted central service.

The value cpkc (Certify Certify Public Key Certificate) Certificate service is used when the validity and revocation status
of the one or more public key certificates included
in the request are is to be verified. This
service can be used to
supplement the use of CRLs when timely information regarding a certificate's
revocation state is required (e.g. high value funds transfer or the
compromise of a highly sensitive key) or when evidence supporting
non-repudiation is required. A given DCS MAY support any
subset The response of the above services.

Upon receiving validation of a signed request
certificate containing a public key to be used for either encryption may
contain additional certificates to be used as a simple method to
encrypt data or a session key for additional authorised entities
(e.g., company key recovery).

DCS service cs requests MAY be signed or cpkc unsigned depending on the DCS
MUST also verify
configuration and the signature on service that is to be provided.

Some data types occur in several places in a request and/or a
response:

- MessageImprint:

If the request as is done for contains a digest of some data, the cpd
service. Note however, that signed requests Certify Possession
of Data service can be requested for a message imprint.

Reponses include a MessageImprint of the cs or cpkc service
are not required.

A data certification request is as follows. It is encapsulated as received in order to
allow to validate the correspondance to a request.

- Message:

For a CMS SignedData construct [CMS]. The content is of message, either the Certify Signature service or
the Certify Possession of Data service can be requested. For other
known data types, Certify Possession of Data service can be
requested. The DCS may perform additional validation on the content
of data.

- Certificates:

The request contains a list of public key certificates, certificate
validation chains and policy requirements, The Certify Public Key
Certificate service can be requested.

Adams, Sylvester, Zuccherato [Page 6]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999

- Nonce:

A request and a response may include a nonce in order to minimize
some replay attacks.

- CertIds:

As a replacement for certificates, certification identifier MAY be
used. There are actually two types imported from OCSP and from
S/MIME ESS.

Signatures made by the DCS MUST include an ESS signing certificate
attribute.

Requests and responses of the public key certificate validation MAY
contain certificates, OCSP and S/MIME ESS certificate identifiers.

- TimeStamps

Indicators of time occur in requests and responses. In the most
simple form, they are represented as GeneralizedTime. Fractions of
seconds are allowed. The alternate form is a TimeStamping token,
either from [TSA] or as a DCS token.

6. Request and Token Format

A data certification request is a SignedData construct of [CMS] or
[PKCS7]. The contenttype indicated in the eContentType of the
encapContentInfo is of type DCSReqData.

DCSRequest ContentInfo id-ct-DCSReqData signalling a DCSReqData
as eContent of the encapContentInfo (carried as an octet string).

id-ct-DCSReqData OBJECT IDENTIFIER ::= {id-ct ??}

with:

id-ct OBJECT IDENTIFIER ::= SEQUENCE {
contentType id-smime 1 }
id-smime OBJECT IDENTIFIER,
--{pkcs-7 2}, SignedData
content [0] IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

A data certification request MAY contain several SignerInfo
structures, and countersignature attributes depending on operational
environments. In a normal end user situation (or an application that
initially creates a DCS request, there is normally one or zero
occurences of SignerInfo.

DCSReqData ::= SEQUENCE {
version INTEGER,
digestAlgorithms AlgorithmIdentifier,
contentInfo
dcsReqInfo DCSReqInfo,

Adams, Sylvester, Zuccherato [Page 7]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999

data Data ,
requestIdentifier GeneralName OPTIONAL
}

The dcsReqInfo field contains information pertaining to the data
certification request.

DCSReqInfo ::= SEQUENCE {
contentType
version Integer { v1(0) },
service ServiceType,
requester [0] GeneralNames OPTIONAL,
reqPolicy [1] PolicyInformation OPTIONAL,
dcs [2] GeneralNames OPTIONAL,
dataLocator [3] GeneralName OPTIONAL,
nonce Integer,
reqTime DCSTime OPTIONAL,
extensions Extensions OPTIONAL
}

GeneralNames ::= SEQUENCE OF GeneralName

The ServiceType type indicates which type of Data Certification
Server service is required.

ServiceType ::= INTEGER { cpd(1), cs(2), cpkc(3) }

The value of requester indicates the requesting entity. If present,
the requester MUST match the identity (subjectName or subjectAltName
extension) for the corresponding signing certificate, unless the
request is signed by a DCS (relaying a request to another server). A
DCS may include a sequence of identities in the request, indication
the original requester, and one or more other DCS. A DCS indicated
in the list are acting by delegation.

The value of dcs indicates a list a DCS which are to be contacted to
provide (additional) information or to perform additional operations
necessary to produce the response. It is up to the DCS policy
whether to honour this field or not. The DCS MAY use local
information to use additional external services.

dataLocator describes the requester's idea of where the data are
located.

PolicyInformation is defined in Section 4.2.1.5 of [RFC2459]. The
reqPolicy field SHOULD indicate the policy under which the
certification is requested. This field MUST be checked by the DCS to
verify agreement with its own policy. The absence of this field
indicates that any policy is acceptable.

Adams, Sylvester, Zuccherato [Page 8]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999

DCSTime ::= CHOICE {
genTime GeneralizedTime,
timeStampToken SignedData
}

A timeStampToken is either a DCSToken or a TimeStampToken defined in
[TSA]. If a timeStampToken is present, this indicates the time
provided by another DCS or TSA.

In situations where the Data Certification Server will certify the
time included in the request (i.e., when stipulated by the policy of
the Data Certification Server), the data certification request MUST
include the reqTime field in DCSReqInfo. Thus, when verifying a
public key certificate, the presence of this field indicates the time
for which the validity and revocation status of the certificate
SHOULD be reported. If this field is not present, the current time
is assumed.

The Data type is defined to be either the message itself, a hash of
the message (this allows a signature indicating possession of private
data to be certified) or the certificate to be verified.

Data ::= CHOICE {
message [0] Message,
messageimprint [1] MessageImprint,
certs [2] SEQUENCE SIZE (1..MAX) OF
TargetandChain }

In order to specify the format (i.e. the type) of the message so
that it may be parsed and understood by the DCS or any verifying
entity, we define the Message data type.

Message ::= SEQUENCE {
format MESSAGECLASS.&id, --objid
rawdata MESSAGECLASS.&Type --open type
}

MESSAGECLASS ::= CLASS {
&id OBJECT IDENTIFIER,
--OID signalling TSTReqData
content DCSReqData IDENTIFIER UNIQUE,
&Type }
certificate [0] Certificate,
signerInfos SignerInfos
WITH SYNTAX { &Type IDENTIFIED BY &id }

Possible message types include id-data and id-signedData [CMS].

id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)

Adams, Sylvester, Zuccherato [Page 9]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999

us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

The data certification request

In particular, if the message type is id-signedData (or any other
message type that allows more than one signature) and more than one
SignerInfo (or signature) is present under service type cs, the DCS
MUST either be unsigned or contain only verify all signatures present.

A failure of the signature verification of one of the requester.

DCSReqData signatures does not
necessarily result in the failure of the entire certification.

For a Data Possession service, the requester may choose to send a
message or a hash of a message instead using the MessageImprint data
type.

MessageImprint ::= SEQUENCE {
dcsReqInfo DCSReqInfo,
data Data

Document Expiration: March 23, 1999 Page 4

--the data to be certified
--this
hashAlgorithm AlgorithmIdentifier,
hashedMessage OCTET STRING }

The hash algorithm indicated in the hashAlgorithm field MUST SHOULD be of type Message if a
"strong" hash algorithm (that is, it SHOULD be one-way and collision
resistant). It is up to the service type Data Certification Server to decide
whether or not the given hash algorithm is cs
--and sufficiently "strong"
(based on the current state of type SEQUENCE OF Certificate if knowledge in cryptanalysis and the service type is cpkc
}
current state of the art in computational resources, for example).

The dcsReqInfo hashedMessage field contains information pertaining to SHOULD contain the hash of the DER encoding
of the message expressed as a Message data
certification request.

DCSReqInfo type. The hash is
represented as an OCTET STRING.

TargetandChain ::= SEQUENCE {
version Integer { v1(0) },
service ServiceType,
requester GeneralName OPTIONAL,
--MUST be present if the service field is cpd
--MUST match the identity (subjectName or subjectAltName
--extension) for the corresponding signing certificate
reqPolicy PolicyInformation OPTIONAL,
dcs GeneralName,
nonce Integer,
reqTime ReqTime
target CertetcToken,
chain [0] SEQUENCE SIZE (1..MAX) OF
CertetcToken OPTIONAL,
extensions Extensions
pathProcInput [1] PathProcInput OPTIONAL }

ReqTime

PathProcInput ::= SEQUENCE {
acceptablePolicySet CertificatePolicies,
inhibitPolicyMapping BOOLEAN DEFAULT FALSE,
explicitPolicyReqd BOOLEAN DEFAULT FALSE }

CertetcToken ::= CHOICE {
genTime GeneralizedTime,
timeStampToken TimeStampToken
cert [0] Certificate ,
esscertid [1] ESSCertId ,
dcstoken [2] DCSToken ,
oscpresponse [3] OCSPResponse,
pkistatus [4] PKIStatusField ,
extension Extension }

In situations where the Data Certification Server will verify the
identity of the requester (i.e., when the service

Adams, Sylvester, Zuccherato [Page 10]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999

The certs field is cpd), SHOULD contain the
data certification request MUST certificate to be certified. Each
certificate SHALL be signed by the requester using the
signerInfos field.

Similarly, in situations where the Data Certification Server will
certify the time included in the request (i.e., when stipulated by the
policy a separate instance of
TargetandChain. The target field SHALL contain the Data Certification Server), cert to be
verified and the data certification
request chain field, if present, MUST include indicate the reqTime field in DCSReqInfo. Thus, chain of
trust to be used when
verifying a public key certificate, certifying the presence of this field indicates certificate. The pathProcInput
field, if present, SHOULD indicate the time acceptable policy set and
initial settings for which the validity explicit-policy-indicator and revocation status of the certificate
SHOULD inhibit-policy-
mapping indicators to be reported. If this field is not present, the current time is
assumed. TimeStampToken is defined used in Sect 2.4 of [TSA].

PolicyInformation X.509 public key certificate path
validation (see [RFC2459]). CertificatePolicies is defined in
Section 4.2.1.5 of [CCP]. The
reqPolicy field SHOULD indicate the policy under which the certification
is requested. This field [RFC2459].

Only Certificate and ESSCertId MUST be checked by used in the DCS to verify agreement
with its own policy. The absence of this field indicates that any
policy is acceptable.

The Data type request. ESSCertId
is defined to be either only used when the message itself, a hash corresponding certificate is available in one
of the message (this allows a signature indicating possession of private
data to be certified) TargetandChain components, or in the certificate to be verified.

Data ::= CHOICE {
message [0] Message,
messageimprint [1] MessageImprint,
certs [2] SEQUENCE SIZE (1..MAX) OF
TargetandChain }

Document Expiration: March 23, 1999 Page 5

In order to specify list of the format (i.e.
SignerData of the type) DCS request.

Extensions are described in Section 4.2 of [RFC2459]. The
criticality of the message so that
it may extensions MUST be parsed and understood honoured by the DCS or any verifying entity, we
define the Message data type.

Message ::= SEQUENCE {
format MESSAGECLASS.&id, --objid
rawdata MESSAGECLASS.&Type --open type
}

MESSAGECLASS ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type }
WITH SYNTAX { &Type IDENTIFIED BY &id }

Possible message types include id-data conformant DCSs and id-signedData [CMS].

id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

In particular, if the message type is id-signedData (or any other
message type that allows more than one signature)
clients (e.g. requests and more than one
SignerInfo (or signature) is present under service type cs, the DCS responses containing critical extensions
which are not understood MUST verify all signatures present. In be rejected).

requestIdentifier is an identifier that is returned as supplied in a
response. The requester MAY use this case the failure of any
one signature element in order to verify will result associate
requests and responses. For example in a mail transport environment,
the failure of the entire
certification.

If the requester prefers to send request identifier could be a hash copy of a MessageId.

A DCS Response is the message instead, the
MessageImprint following data type SHOULD structure. At least one of the
optional element MUST be used.

MessageImprint present. DCS servers MAY choose produce only
signed responses (DCSResp containing a dcsToken), i.e., not to return
any information when they cannot decode a request or when signing is
not possible.

DCSResp ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashedMessage OCTET STRING
requestIdentifier [0] GeneralName OPTIONAL ,
responseStatus [1] PKIStatusInfo OPTIONAL,
dcsToken DCSToken OPTIONAL
}

The hash algorithm indicated in responseStatus is un unsigned information only message. A client
should not put more trust into element than into the hashAlgorithm field SHOULD be lower level
transport. The reason for having a
"strong" hash algorithm (that is, it SHOULD be one-way and collision
resistant). It SEQUENCE is up to that that the Data Certification Server server
might want to decide whether signal some additional information in a PKIFreeText of
responseStatus.

If the DCS Response contains a dcsToken, the PKIStatus field of the
requestStatus MUST be `granted' (0), or not the given hash algorithm requestStatus MUST be
absent.

Adams, Sylvester, Zuccherato [Page 11]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999

A dcsToken is sufficiently "strong" (based on the
current state a SignedData construct of knowledge [CMS]. The contenttype
indicated in cryptanalysis and the current state eContentType of the
art in computational resources, for example). encapContentInfo is of type id-
ct-DCSInfo signalling a DCSReqData as eContent of the
encapContentInfo (carried as an octet string).

id-ct-DCSInfo OBJECT IDENTIFIER ::= {id-ct ??}

A data certification MAY contain several SignerInfo structures, and
countersignature attributes depending on operational environments.

The hashedMessage field SHOULD data certification token MUST contain only the hash of the DER encoding DCS signatures,
i.e., signatures signed with certificates having KeyPurposeID of
the message expressed as a Message data type. The hash is represented
as an OCTET STRING.

TargetandChain id-
kp-dcs.

DCSInfo ::= SEQUENCE {
infoStatus PKIStatusInfo OPTIONAL,
dcsReqInfo DCSBasicInfo OPTIONAL,
requestIdentifier GeneralName OPTIONAL
}

DCSBasicInfo ::= SEQUENCE {
dcsReqInfo DCSReqInfo,
messageImprint MessageImprint,
dataLocator [0] GeneralName OPTIONAL ,
reqSignature [1] SignerInfos OPTIONAL,
policy PolicyInformation,
time DCSTime,
serialNumber Integer OPTIONAL,
chainCerts [2] SEQUENCE OF TargetandChainInfo OPTIONAL,
crls [3] SEQUENCE OF CertificateList OPTIONAL,
extensions [4] Extensions OPTIONAL
}

TargetandChainInfo ::= SEQUENCE {
target Certificate, CertetcToken,
chain [0] SEQUENCE SIZE (1..MAX) OF Certificate
CertetcToken OPTIONAL,
pathProcInput PathProcInput
policyReturnInfo [1] PolicyReturnInfo OPTIONAL }

PathProcInput

PolicyReturnInfo ::= SEQUENCE {
acceptablePolicySet CertificatePolicies,
inhibitPolicyMapping BOOLEAN DEFAULT FALSE,

Document Expiration: March 23, 1999 Page 6

explicitPolicyReqd BOOLEAN DEFAULT FALSE
policies SEQUENCE OF PolicyInformation,
mappings SEQUENCE OF PolicyMappingsSyntax }

The certs field SHOULD contain the certificate to be certified. Each
certificate SHALL be included

PKIStatusInfo is defined in a separate instance Section 3.2.3 of TargetandChain. [RFC2510]. The target
infoStatus field SHALL contain the cert to be verified and indicates whether or not the chain
field, data certification
request was fulfilled and, if present, MUST indicate not, failInfo indicates the chain of trust to be used when
certifying reason it

Adams, Sylvester, Zuccherato [Page 12]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999

was rejected. A valid data certification token will have a PKIStatus
field with value `granted' (0) or 'grantedWithMods' (1). If the certificate. The pathProcInput field, if present, SHOULD
indicate only
content of the acceptable policy set and initial settings for
explicit-policy-indicator and inhibit-policy-mapping indicators to be
used in X.509 public key certificate path validation (see [CCP]).
CertificatePolicies PKIStatus is defined in Section 4.2.1.5 of [CCP].

Extensions are described in Section 4.2 of [CCP]. The criticality a PKIStatus field with a value of
the extensions MUST be honoured by conformant DCSs and clients (e.g.
requests and responses containing critical extensions which are
'granted', PKIStatusField is not
understood MUST be rejected). generated.

A data certification token is failure of the verification of one of the signatures does not
necessarily result in the production of an error message. For
example, as follows. It is encapsulated long as a
SignedData construct [CMS]. The content is sufficient number of type DCSReqData.

DCSToken ContentInfo ::= SEQUENCE {
contentType OBJECT IDENTIFIER,
--{pkcs-7 2}, SignedData
content [0] SEQUENCE {
version INTEGER,
digestAlgorithms AlgorithmIdentifier,
contentInfo SEQUENCE {
contentType OBJECT IDENTIFIER,
--OID signalling DCSInfo
content DCSInfo }
certificate [0] Certificate,
signerInfos SignerInfos } }

The data certification signature verifications
was successful, a token with status `grantedWithMods` MAY be
produced. A token with status `granted` MUST contain only the signature be produced if all
signatures verified successfully.

Whether a `grantedWithMods` response or an error response will be
produced is a matter of the DCS.

DCSInfo ::= SEQUENCE { local policy.

The dcsReqInfo DCSReqInfo,
--MUST MUST be the same value as the dcsReqInfo field in DCSReqData
messageImprint MessageImprint,
--if
DCSReqData.

If the data field in DCSReqData is MessageImprint, this
--MUST messageImprint
MUST contain that same value, otherwise it contains a hash of
--the the
data field in DCSReqData using the hash algorithm
--specified algorithms specified in the
digestAlgorithm parameter of SignerInfo the signerInfos in
--the the data
certification token
reqSignature SignerInfo OPTIONAL,
--MUST token.

The dataLocator MUST be present if service the same value as the dataLocator field of dcsReqInfo is cpd
--MUST in
the DCSReqInfo.

reqSignature MUST be the same value as the signerInfo signerInfos field in of the data
--certification request
policy PolicyInformation,
status PKIStatusInfo,
time DCSTime,
serialNumber Integer OPTIONAL,
chainCerts [0] SEQUENCE OF
DCSRequest.

For a Signature and Certificate OPTIONAL,
--if present, validation, chainCerts MUST indicate
the chain chains of trust trust, and additional information (OCSP responses,
DCSToken, PKIStatusField) that was used by
--the the DCS to verify the signature or certificate in DCSReqData
crls [2] SEQUENCE OF CertificateList OPTIONAL,

Document Expiration: March 23, 1999 Page 7

policyReturnInfo [3] SEQUENCE OF PolicyReturnInfo OPTIONAL,
extensions Extensions OPTIONAL }

DCSTime ::= CHOICE {
genTime GeneralizedTime,
timeStampToken TimeStampToken }

PolicyReturnInfo ::= SEQUENCE {
policies SEQUENCE OF PolicyInformation,
mappings SEQUENCE OF PolicyMappingsSyntax }

PKIStatusInfo is defined in Section 3.2.3 of [CMP]. If the PKIStatus
field has value `waiting' (3), then this token is a receipt, as defined
in Section 2. Otherwise, verify the status field indicates whether
signature or certificate in DCSReqData. The chain field does not
necessarily contain a single chain of trust, multiple hierarchies are
possible. Furthermore, for example in the
data certification request was fulfilled and, if not, failInfo indicates
the reason it was rejected. A valid data certification token will have case of validation of a PKIStatus field with value `granted' (0).
public key certificate used for encryption purposes, additional
certificates may be included to indicate other encryption
destinations (e.g., for organisation wide key recovery).

For the purposes of the DCS, we define PKIFailureInfo for use in
PKIStatusInfo.

PKIFailureInfo ::= BITSTRING {
badAlg (0),
-- unrecognized or unsupported Algorithm Identifier
badMessageCheck (1),
-- integrity check failed (e.g., signature did not verify)

Adams, Sylvester, Zuccherato [Page 13]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999

badRequest (2),
-- transaction not permitted or supported
badTime (3),
-- messageTime was not sufficiently close to the system time,
-- as defined by local policy
badCertId (4),
-- no certificate could be found matching the provided criteria
badDataFormat (5),
-- the data submitted has the wrong format
wrong
wrongAuthority (6),
-- the DCS indicated in the request is different from the
-- one creating the response token
incorrectData (7),
--the requester's data (i.e. signature) is incorrect
--(i.e.
--(i.e., invalid)
missingTimeStamp (8),
-- when the timestamp is missing but should be there (by policy)
certInvalid (9),
-- the certificate fails to validate against Section 6 of [CCP] [RFC2459]
certRevoked (10),
-- the certificate is revoked
certExpired (11),
-- the certificate has expired
certOnHold (12),
-- the certificate has been operationally suspended
certNotActive (13)
-- the certificate was not active at the given time }

The statusString field of PKIStatusInfo can be used to include reason
text such as "CA's public key revoked".

Document Expiration: March 23, 1999 Page 8

CertId is defined in Section 7.5 of [CRMF].

The crls field (if present) SHOULD contain a sequence of certificate
revocation lists that is sufficient to verify the chain chains of trust
indicated in the chainCerts field.

The policyReturnInfo field indicates the policies and mappings that
were processed during X.509 public key certificate path validation.
PolicyMappingsSyntax is defined in [CCP]. [RFC2459].

The reqSignature, chainCerts, crls and policyReturnInfo policyInfo fields are included
as OPTIONAL. They SHOULD be present, when policy dictates, for use
as supplementary evidence when resolving possible disputes. Dispute
resolution would most likely be handled by one or more humans, in an
off-line environment, and is beyond the scope of this document.

7. Transports

Adams, Sylvester, Zuccherato [Page 14]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999

There is no mandatory transport mechanism in this document. All
mechanisms are optional.

6.1.

7.1 File Based Data Certification Server Protocol

A file containing a data certification message MUST contain only the
DER encoding of one PKI message, i.e. there MUST be no extraneous
header or trailer information in the file.

Such files can be used to transport data certification messages using
for example, FTP.

6.2. Socket Based Data Certification Server Protocol

The socket based protocol for data certification messages is identical
to that used in [CMP] Section 5.2 except that port 309 MUST be used.

6.3.

7.2 Data Certification Server Protocol Using Email

This section specifies a means for conveying ASN.1-encoded messages
for the protocol exchanges described in Section 4 via Internet mail.

The DER encoded DCS requests and responses are encapsulated using a
simple MIME object is specified as follows.

Content-Type: with Content-Type application/dcs
Content-Transfer-Encoding: base64

<<the ASN.1 DER-encoded Data Certification Server message, base64-
encoded>> with an
appropriate Content-Transfer-Encoding.

This MIME object can be sent and received using MIME processing
engines and provides a simple Internet mail transport for Data
Certification Server messages.

6.4. Data Certification Server

7.3 DCS Protocol via HTTP

This subsection specifies a means for conveying ASN.1-encoded
messages for the protocol exchanges described in Section 4 2 and
Appendix C via the HyperText

Document Expiration: March 23, 1999 Page 9 Transfer Protocol.

The DER encoded DCS requests and responses are encapsulated using a
simple MIME object is specified as follows.

Content-Type: application/dcs

<<the ASN.1 DER-encoded Data Certification Server message>> with Content-Type application/dcs.

This MIME object can be sent and received using common HTTP
processing engines over WWW links and provides a simple browser-server browser-
server transport for Data Certification Server DCS messages.

8. Security Considerations

This entire document discusses security considerations.

When designing a data certification service, the following
considerations have been identified that have an impact upon the
validity or "trust" in the data certification token.

1. The enclosed public key certificate is revoked or the signer's

Adams, Sylvester, Zuccherato [Page 15]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999

key is compromised and the corresponding public key certificate
is revoked before the Data Certification Server acts upon the
request. The Data Certification Server is REQUIRED to validate
appropriate information within the request before it
constructs the data certification token. It is therefore
mandated that the DCS have access to current information
regarding public key certificate status before it creates the
token. In this situation, the certification process would
produce an error.

2. The enclosed public key certificate is revoked or the signer's
key is compromised and the corresponding certificate is revoked
after the Data Certification Server acts upon the request. This
is not a concern to the DCS once the Data Certification Server
has constructed the token, as long as the compromise date in the
CRL is not before the time of certification. If it is, this
situation would have to be handled by off-line, possibly human-
aided, means specific to the situation at hand.

3. The Data Certification Server's private key is compromised and
the corresponding certificate is revoked. In this case, any
token signed by the Data Certification Server cannot be trusted.
For this reason, it is imperative that the Data Certification
Server's key be 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 tokens generated by the DCS SHOULD be kept as a means
to help discriminate between genuine and false tokens.

4. The DCS signing key MUST be of a sufficient length to allow for
a sufficiently long lifetime. Even if this is done, the key
will have a finite lifetime. Thus, any token signed by the DCS
SHOULD be time stamped (if authentic copies of old CRLs
are available) or certified again (if they aren't) at a later
date to renew the trust that exists in the DCS's signature.
Data certification tokens could also be kept with an Evidence
Recording Authority [ISONR] to maintain this trust.

5. When there is a reason to believe that the DCS can no longer

Document Expiration: March 23, 1999 Page 10
be trusted, its certificate MUST be revoked and placed on the
appropriate CRL. revoked. Thus, at any future
time the tokens signed with the corresponding key will not be
trusted.

6. In certain circumstances, a DCS may not be able to produce a
valid response to a request (for example, if it is unable to
compute signatures for a period of time). In these situations
the DCS MUST wait until it is again able to produce a valid
response and then respond to the request. Under no
circumstances shall a DCS produce an unsigned response to a
request.
7. A CA shall normally conduct a test for proof of possession for
each user's signing private key (including the DCS signing
private key). However, in some environments, the CA might not
perform a proof-of-possession of the private key when issuing
certificates. time). In these instances, in order to prevent certain
attacks and to properly check the validity of situations
the binding
between an end entity and DCS MAY create a key pair, response that only contain a certificate identifier
of the PKIStatusInfo.

Adams, Sylvester, Zuccherato [Page 16]

draft-ietf-pkix-dcs-01.txt DCS (resp. user) shall be included as Protocols July 12, 1999

7. DCS clients SHOULD NOT trust unsigned responses. A DCS client
may trust unsigned responses, if the communication channel
provides for server authentication (e.g. by services defined
by TLS [RFC2246]).

7. Client identification and authentication may use services defined
by TLS [RFC2246]) instead of using a signed attribute
of the token (resp. request). request.

8. In situations where confidentiality is required, requests
and responses MAY be protected using appropriate mechanisms
(e.g. CMS encapsulation [CMS] or TLS [RFC2246]).

9. Patent Information

The following United States Patents related to data certification
servers (notaries),
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 the DCS
protocol and applications using the protocol SHOULD perform their own
patent search and determine whether or not any encumberences exist on
their implementation.

# 4,309,569 Method of Providing Digital Signatures
(issued) January 5, 1982
(inventor) Ralph C. Merkle
(assignee) The Board of Trustees of the Leland Stanford Junior
University

# 5,001,752 Public/Key Date-Time Notary Facility
(issued) March 19, 1991
(inventor) Addison M. Fischer

# 5,022,080 Electronic Notary
(issued) June 4, 1991
(inventors) Robert T. Durst, Kevin D. Hunter

# 5,136,643 Public/Key Date-Time Notary Facility
(issued) August 4, 1992
(inventor) Addison M. Fischer
(Note: This is a continuation of patent # 5,001,752.)

# 5,136,646 Digital Document Time-Stamping with Catenate Certificate
(issued) August 4, 1992
(inventors) Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Bell Communications Research, Inc.,

Document Expiration: March 23, 1999 Page 11

# 5,136,647 Method for Secure Time-Stamping of Digital Documents

Adams, Sylvester, Zuccherato [Page 17]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999

(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.,

10. References

[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
RFC 2119.

[TSA] C. Adams, P. Cain, D. Pinkas, R. Zuccherato, "Internet X.509
Public Key Infrastructure, Time Stamp Protocols," draft-ietf-pkix-time-
stamp-0X.txt, 1998 draft-ietf-pkix-
time-stamp-02.txt, 1999 (work in progress).

[CMP]

[RFC2510] C. Adams, S. Farrell, "Internet X.509 Public Key
Infrastructure, Certificate Management Protocols," draft-ietf-pkix-ipki3cmp-
0X.txt, 1998 (work in progress).

[CCP] RFC-2510, 1999.

[RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509
Public Key Infrastructure, Certificate and CRL Profile," draft-ietf-pkix-ipki-
part1-0X.txt, 1998 (work in progress). Profile", RFC-2459.
January 1999.

[CMS] R. Housley Housley, "Cryptographic Message Syntax", draft-ietf-smime-cms- draft-ietf-smime-
cms- 0X.txt, 1998 (work in progress).

[ISONR] ISO/IEC 10181-5: Security Frameworks in Open Systems.
Non-Repudiation Non-
Repudiation Framework.

[RFC2119] Key works for use in RFCs to Indicate Requirement Levels,
S. Bradner, RFC 2119, March 1997.

[CRMF]

[RFC2511] M. Myers, C. Adams, D. Solo, D. Kemp "Internet X.509
Certificate Request Message Format," draft-ietf-pkix-crmf-0X.txt, 1998 RFC-2511, March 1999.

Adams, Sylvester, Zuccherato [Page 18]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999

[RFC2246] T. Dierks, C. Allen, "The TLS Protocol, Version 1.0," RFC
2246, January 1999.

[ESS] P. Hoffman, "Enhanced Security Services for S/MIME", draft-
ietf- smime-ess-0X.txt, 1999 (work in progress).

10.

[OCSP] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams,
"X.509 Internet Public Key Infrastructure Online Certificate Status
Protocol", draft-ietf-pkix-ocsp-0X.txt, 1999 (work in progress).

11. Authors' Addresses

Carlisle Adams Robert Zuccherato
Entrust Technologies
Entrust Technologies
750 Heron Road
Ottawa, Ontario
K1V 1A7
CANADA
cadams@entrust.com

Peter Sylvester
EdelWeb SA
33 avenue du Maine
F-75755 Paris Cedex 15
FRANCE
peter.sylvester@edelweb.fr

Robert Zuccherato
Entrust Technologies
750 Heron Road
Ottawa, Ontario Ottawa, Ontario
K1V 1A7
K1V 1A7
CANADA CANADA
cadams@entrust.com
robert.zuccherato@entrust.com

Document Expiration: March 23, 1999 Page 12
;fi

APPENDIX A - Storage of Data and Token

A data certification token is useless without the data to which it
applies. For this reason tokens and their related data MUST be securely
stored together. The change of a single bit in either the data or the
token renders the entire certification process for that data
meaningless. Storage of tokens and data in a secure (e.g., tamper
proof) environment is strongly RECOMMENDED.

When data and data certification tokens are stored together, the
following ASN.1 data type MAY be used.

Adams, Sylvester, Zuccherato [Page 19]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999

DataAndToken ::= SEQUENCE {
message Message,
dcsToken DCSInfo }

Note that this object does not need to be signed, as the data
certification

Furthermore, we define a PKCS #9 [PKCS9] dcs token already verifies the integrity of the data in attribute type.
This attribute type specifies the
message. Any supplementary information whose integrity needs to be
protected SHOULD dcs token, which MAY be part included as
a signed attribute of the message or token. SignedData object. The dcs token attribute
type has ASN.1 type DCSToken (as defined in this document).

The object identifier id-aa-timeStampToken identifies the dcs token
attribute type.

id-aa-timeDCSToken OBJECT IDENTIFIER ::= { id-aa XX }
id-aa OBJECT IDENTIFIER ::= { id-smime 2 }

APPENDIX B - Extending the Life of a Signature

We present an example of a possible use of this data certification
service. It produces a stand-alone token that can be used to extend
the life of a signature. This example assumes that we have total
trust in the Data Certification Server.

Signature algorithms and keys have a definite lifetime. Therefore,
signatures have a definite lifetime. The Data Certification Server
can be used to extend the lifetime of a signature.

In order to extend the lifetime of a signature in this way, the
following technique MAY be used.

A) The signature needs to be certified.

1) The signed message is presented to the Data Certification Server
in the data field of DCSReqInfo under service type cs and an
appropriate policy.

2) The Data Certification Server verifies that the signature and
verification key are valid at that time by checking expiry dates
and status information, and returns a data certification token.

B) The certified signature MUST be verified.

1) The signature of the Data Certification Server in data
certification token SHALL be verified using the Data
Certification Server's valid verification key.

In this situation the signer's signing key (and therefore, its
signature) is only valid until some specified time T1. The DCS's
signing key (and therefore, its signature) is valid until some specified

Document Expiration: March 23,

Adams, Sylvester, Zuccherato [Page 20]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999 Page 13

specified time T2 that is (usually) after time T1. Without
certification, the signer's signature would only be valid until time
T1. With certification, the signer's signature remains valid until
time T2, regardless of subsequent revocation or expiry at time T1.

If the signature of the DCS is valid, the trust we have in the DCS
allows us to conclude that the original signature on the data was
valid at the time included in the dcsInfo field of the data
certification token.

APPENDIX C - Verifying the Status of a Public Key Certificate

We now present an example of how to produce a stand-alone token that
can be used to confirm the revocation status of a public key
certificate.

CRLs and ARLs are updated according to a schedule at regular
intervals. For some purposes, the granularity provided by the CRLs
and ARLs is not fine enough. Up-to-date revocation status may be
needed before the next CRL or ARL update. Since the DCS MUST have
access to current information regarding public key certificate
status, it can also be used to verify the revocation status of a
certificate in this situation.

In order to produce such a token, the following technique MAY be
used.

A) The public key certificate needs to be certified.

1) The certificate is presented to the Data Certification Server in
the data field of DCSReqInfo under service type cpkc and an
appropriate policy.

2) The Data Certification Server verifies that the public key
certificate is valid and that it hasn't been revoked and then
returns a data certification token.

B) The data certification token MUST be verified.

1) The signature of the Data Certification Server in the data
certification token SHALL be verified using the Data
Certification Server's valid verification key.

This data certification token can now be used when verifying
signatures using the key contained in the public key certificate.
This service provided by the DCS can be thought of as a supplement to
the usual method of checking revocation status.

Document Expiration: March 23,

Adams, Sylvester, Zuccherato [Page 21]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999

Appendix D - MIME Registration

To: ietf-types@iana.org Subject: Registration of MIME media type
application/timestamp

MIME media type name: application

MIME subtype name: dcs

Required parameters: None

Optional parameters: None

Encoding considerations: binary or Base64

Security considerations: Carries a request for a data certification
service and the response. A request may be cryptographically signed.
The response will be cryptographically signed.

Interoperability considerations: None

Published specification: IETF PKIX Working Group Draft on Data
Certification Server Protocols

Applications which use this media type: Data Certification clients

Additional information:

Magic number(s): None
File extension(s): .dcs
Macintosh File Type Code(s): none

Person & email address to contact for further information: Peter
Sylvester <peter.sylvester@edelweb.fr>

Intended usage: COMMON

Author/Change controller: Peter Sylvester
<peter.sylvester@edelweb.fr>

Appendix E - Acknowledgements

This text is based on initial work from Robert Zuccerato and Carlisle
Adams, both at Entrust Technologies, and from Denis Pinkas at Bull,
for time stamping, notary and data certification services.

Thanks to Michael Zolotarev from Baltimore for his useful comments.

Adams, Sylvester, Zuccherato [Page 22]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999 Page 14

Appendix F - Full Copyright Statement

Copyright (C) The Internet Society 1999. All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process shall be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS 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.

Adams, Sylvester, Zuccherato [Page 23]

----