WDIFF

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

PKIX Working Group expires in six months
July October 12, 1999 expires April 12, 2000

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

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 obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document describes a general data validation and certification
service and the protocols to be used when communicating with it. The
Data Validation and Certification Server is a Trusted Third Party
(TTP) that can be used as one component in building reliable non-repudiation non-
repudiation services (see [ISONR]).

Useful Data Validation and Certification Server responsibilities in a
PKI are to validate signatures signed documents and to provide up-to-date information
regarding assert the status validity of
public key certificates. certificates at a given time.

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.

<draft>Note: The initial drafts of this protocol used the
abbreviation DCS instead of DVCS.</draft>

Adams, Sylvester, Zolotarev, Zuccherato [Page 1]

draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECO6MMENDED",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
as shown) 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

<draft>A complete list of ASN.1 will be added in an appendix.</draft>

1. Introduction

A Data Certification Validation Server (DCS) (DVCS) is a Trusted Third Party that
provides an assertion of the usability of the data transmitted to it.
The assertion may be (TTP)
providing a time stamp, a data validation services, asserting correctness of
digitally signed documents, validity of a public key certification or certificates, and
possession of data.

As a signed document.

The Data Certification Server provides result of the assertion, a DVCS generates a Data Validation
Certificate (DVC) The data certification service
in order that non-repudiability evidence may validation certificate can be constructed used for
constructing evidence of non-repudiation, 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 and the
validity and correctness of another entity's
signature.

When certifying possession of data or another entity's signature, the
DCS verifies a digitally signed document.

DVCS services do not replace the mathematical correctness usage of the actual signature
value contained in the request CRLs and also checks the full certification
path from the signing entity OCSP for public
key certificate revocation checking in large open environments, due
to a trusted point (e.g., the DCS's CA,
or concerns about the root CA in a hierarchy). The DCS MAY scalability of this protocol. It should be able
rather used to rely on all
relevant CRLs and ARLs, support non-repudiation 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
traditional services concerning paperless document environments. The
presence of 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 validation 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 digitally signed document or
public key certificate was valid at the time indicated in the token. dvc.
The token dvc for a public key certificate can be used even after the corresponding
public key certificate expires and its revocation information is no
longer available on CRLs
(for example). or not easily available; it is assumed that verifying the
validity of a dvc is easier, since the population is smaller. The
production of a data certification token validation certificate in response to a signed
request for certification validation of another signature a signed document or public key
certificate also provides evidence that due diligence was performed
by the requester in validating the a digital signature or public key
certificate.

DCS does not replace the usage

2. DVCS Services

The current specification defines 4 types of CRLs validation and OCSP for public key
certificate revocation checking in large open environments, due to
certification services:

- Certification of Possession of Data (cpd),
- Certification of Claim of Possession of Data (ccpd),
- Validation of Digitally Signed Document (vsd), and
- Validation of Public Key Certificates (vpkc).

Adams, Sylvester, Zolotarev, Zuccherato [Page 2]

draft-ietf-pkix-dcs-01.txt DCS

draft-ietf-pkix-dcs-02.txt DVCS Protocols July October 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) DVCS is REQUIRED to support at least a centrally managed
service.

In all cases, the trust that PKI entities have in the Data
Certification Server is transferred to the contents subset of these services.

On completion of each service, the data
certification token (just as trust in a CA is transferred to the
public key certificates that it issues). As particular examples, DVCS produces a data certification token pertaining to validation
certificate - a signature may be useful for
extending signed document containing the life validation results and
trustworthy time information.

2.1 Certifying Possession of Data

The Certify Possession of Data service provides evidence that signature beyond the expiry or subsequent
revocation of its corresponding verification certificate; and
including a DCS response as an authenticated attribute in a signature
allows to include an additional attestion about
requester possessed data at the usability of a
certificate to be used for signing.

It is outside time indicated and that the scope of this document actual
data where presented to describe different
operational scenarios, or usages for DCS. This document describes
basic services and protocols.

2. Requirements of the Data Validation Server.

2.2 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 Claim of possession of
company certificates), Data

The Certify Claim of Possession service is similar to cooperate in the previous
one, except that the requester does not present the data itself but a multi-organisation
community, or general third party services for
message digest. This service is similar to time stamping or data
archival. services as
described in [TSP].

2.3 Validation of Digitally Signed Documents

The Data Certification Server Validation of Digitally Signed Document service is REQUIRED to:

1. verify the correctness used when
validity of the enclosed digital signature
(according a signed document is to [RFC2459]) be asserted.

The DVCS verifies all signatures the signed document using all
appropriate status information and public key certificates and produce a signed data certificates. The DVCS
verifies the mathematical correctness of all signatures attached to
the document and also checks whether the signing entities can be
trusted, for example by validating the full certification token certifying path from
the validity signing entities to a trusted point (e.g., the DVCS's CA, or the
root CA in a hierarchy).

The DVCS MAY be able to rely on relevant CRLs or MAY need to
supplement this with access to more current status information from
the CAs for example by accessing to an OCSP service, a trusted
directory service, or other DVS services.

The DVCS will perform verification of all signatures attached to the signature,
signed document. A failure of the verification of one of the
signatures does not necessarily result in the failure of the entire
certification, and vice versa, a global failure may occur if asked by the requester.

2.
document has an insufficient number of signatures.

2.4 Certifying Public Key Certificate

The Certify Public Key Certificate service is used to verify the
validity (according to [RFC2459]) of one or more
enclosed public key
certificates and their revocation status at the specified time using all appropriate status information,
and/or other external services (including DCS and OCSP) and public
key certificates and produce a signed data certification token
certifying the validity and revocation status of the public time.

Adams, Sylvester, Zolotarev, Zuccherato [Page 3]

draft-ietf-pkix-dcs-01.txt DCS

draft-ietf-pkix-dcs-02.txt DVCS Protocols July October 12, 1999

When certifying a public key certificate, if asked by the requester.

3. include a monotonically increasing time of day value
or DVS verifies that the
certificate included in the request is a time stamp token into valid certificate and
determines its data certification token.

4. include within each signed data revocation status at a specified time. DVS checks the
full certification token an
identifier path from the certificate's issuer to determine a trusted
point. Again 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 DVCS MAY be able to rely on external information
(CRL, OCSP, DVCS).

3. Data Certification Server usage and scenarios.

It is outside the corresponding public key certificate.

6. indicate in the token whether or not the signature scope of this document to completely describe
different operational scenarios, or public key
certificate(s) was verified, usages for DVCS.

See Appendix B and if not, the reason the
verification failed.

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

The DCS Validate Signed Document service definition
and the policy defines how much information that have been can be used
by the DCS service to determine support non-
repudiation services, to allow use of the response status, e.g., signed document beyond
public key certificates, OCSP and DCS responses will be included in certificate revocation or expiry, or simply to delegate
signature validation to a DCS Token.

The [TSA] defines additional requirements: trusted central (company wide) service.

The DCS protocols Validate Public Key Certificate service can be used as when timely
information regarding a replacement for the services defined in [TSA], in this case certificate's revocation status is required
(e.g. high value funds transfer or the requirements compromise of [TSA] apply to that service. a highly
sensitive key) or when evidence supporting non-repudiation is
required.

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

3. Data Certification Server Transactions

As signature beyond the first transaction expiry or subsequent revocation of this mechanism, the requesting entity
requests a certification by sending
signing certificate: a data certification request Data validation certificate used as
defined below, including an
authenticated attribute in a signature includes an additional
assertion about the data usability of a certificate that was used for which validity and/or
possession is
signing. In order to validate such a signature it may be certified, sufficient
to only validate the Data Certification Server.
Upon receiving the request, the Data Certification Server reviews and
checks the validity of the request. data validation certificate.

A valid request is data validation certificate for a key exchange certificate may
contain additional certificates to be used as a simple method to
indicate to a client to encrypt a session key for additional
authorised entities (e.g., to support company wide recovery).

The Certify Claim of Possession of Data is equivalent to the form
decribed later services
described in this document, [TSP].

The Certify Possession of data service can be properly decoded, and is from used to assert legal
deposit of documents, or to implement archival services as a supported Data Certification Server subscriber (in case when signed
requests are required).

If the request is valid, the trusted
third party service.

The Data Validation and Certification Server performs all
necessary validations Protocols can be used in order to create a certification, and sends a
response (which is or includes a data
different service contexts. Examples include company-wide centralised
services (verification of signatures, certification token, as defined of company

Adams, Sylvester, Zolotarev, Zuccherato [Page 4]

draft-ietf-pkix-dcs-01.txt DCS

draft-ietf-pkix-dcs-02.txt DVCS Protocols July October 12, 1999

below)

certificates), service to the requesting entity. Otherwise, the Data Certification
Server returns an error message (i.e., cooperate in the form a multi-organisation
community, or general third party services for time stamping or data
archival.

An important application of DVCS is 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 enterprise environment where
all security decision are based on company wide rules. A company
wide DVCS 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 Validation
and Certification Server is transferred to the contents of the Data
Validation Certificate (just as trust in a CA is transferred to the
public key certificates that it issues).

4. Functional Requirements for DVCS

The DVCS MUST

1. provide a signed receipt in the form of a data validation
certificate to the requester, as defined by policy. The DVCS
service definition and the policy defines how much information
that has been used by the DVCS service to determine the response
status will be included in a data validation certificate, e.g.,
public key certificates, CRLs, OCSP, TSA and DVCS responses.

2. indicate in the data validation certificate whether or not the
signed document, the public key certificate(s), or the data were
validated, and, if not, the reason why the verification failed.

3. include a strictly monotonously increasing serial number in each
of its certificates.

4. include a monotonically increasing time of day value or a time
stamp token into each data validation certificate.

5. include within each signed data validation certificate a policy
identifier to determine the trust and validation policy used for
this signature.

6. sign each data certification token using a key generated
exclusively for this purpose, have this property of the key
indicated in the corresponding public key certificate, and include
a reference to this certificate as a signed attributes in the
signature.

The [TSA] defines additional requirements: The DVCS protocols can be
used as a replacement for the services defined in [TSA], in this case

Adams, Sylvester, Zolotarev, Zuccherato [Page 5]

draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999

the requirements of [TSA] apply to that service.

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

5. Data Certification Server Transactions

A DVCS client prepares a Data Certification Request. The request
always contains data for which validity, correctness or possession is
to be certified. It may be required that a requestor signs a
request, to prove that it came from a valid DVCS service's
subscriber. The DVCS client chooses an appropriate transport
mechanism to convey the requests to a DVCS. It may be necessary to
choose a transport mechanism providing confidentiality and, in
particular, allowing authentication of the DVCS by the requestor,
e.g. TLS or encryption.

The DVCS authenticates the request if necessary.

If the request is valid, the DVCS performs all necessary
verifications steps, and generates a Data Validation Certificate
(DVC), and sends a response message containing the DVC back to the
requestor. The Data Validation Certificate is a signed document (CMS
SignedData).

If the request was invalid, a response message will contain an
appropriate error notification.

Upon receiving the token, the requesting entity SHOULD verify its
validity, i.e. it contains the correct time, the correct name for the DCS,
DVCS, the correct data request information and message imprint, a valid
signature, and satisfactory status, service and policy fields.

A DCS's certificate may have been revoked. It

When verifying validity of a DVC, it is up to the local requestor's
application to verify check whether or not a DCS DVCS's signing certificate is still DVCS was
valid. Depending on the usage environment (e.g. organisation's
central trust point or global time stamp authority) environment, different methods (online
or out of band, or CRLs) need CRLs, DVCS, OCSP...) may have to be used.

The token

After all checks passed, the data validation certificate can now be used
to authenticate the correctness or possession of the corresponding
data.

6. Identification of the DCS DVCS

The DCS DVCS MUST sign all data certification messages with a key
reserved
explicitely explicitly for that purpose. The corresponding certificate
MUST contain the extended key usage field extension as defined in

Adams, Sylvester, Zolotarev, Zuccherato [Page 6]

draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999

[RFC2459] Section 4.2.1.14 with KeyPurposeID having value id-kp-dcs. id-kp-DVCS.
This extension MUST be marked as critical.

id-kp-dcs The Data Validation
Certificate MUST contain an ESSCertID authenticated attribute for the
certificate used by the DVCS for signing.

id-kp-DVCS OBJECT IDENTIFIER ::= {id-kp X} { <draft>tbd</draft> }

Consistent key usage bits: digitalSignature, nonRepudiation

A DCS's DVCS's certificate MAY contain an Authority Information Access
extension [RFC2459] in order to convey the method of contacting the
DCS.
DVCS. The accessMethod field in this extension MUST contain the OID
id-ad-dcs:

id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad-dcs
id-ad-DVCS:

id-ad-DVCS OBJECT IDENTIFIER ::= { id-ad X <draft>tbd</draft> }

The value of the accessLocation field 'accessLocation' field defines the transport
(e.g. an URL) used to access the DCS.

5. Service and DVCS.

7. Common Data Types

A DCS MAY support any subset

There are several common data types that occur in the request and the
response data structures. These data types are either defined by this
document or imported from other sources. This chapter defines of
these types and lists their usages.

7.1 DigestInfo:

This element is defind in [RFC2315]. Since the following services: Certify
Possession status of Data, Certify Signature, Certify Public Key Certificate that
document the definition is repeated here:

DigestInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
digest Digest
}

Digest ::= OCTET STRING

The Certify Possession fields of Data service provides evidence that type DigestInfo have the following meanings:

- The field 'digestAlgorithm' identifies the message-digest algorithm
(and any associated parameters) under which data are digested.

- The field 'digest' is the result of the message-digesting process.

A DigestInfo occurs in two places:

- as a data portion for the ccpd service, and

Adams, Sylvester, Zolotarev, Zuccherato [Page 7]

draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999

- in all a data validation certificates to hold a digest of the data
portion of the corresponding request or a copy of the data field
for a ccpd service.

7.2. Nonce

Requests and responses may include INTEGER values as nonce fields. A
nonce field in the
requester possessed data or that data existed at request is returned as is in the time indicated

Adams, Sylvester, Zuccherato [Page 5]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999 response, the
DVCS may create an addition nonce in the request/response. A response.

7.3. Time Values

Indicators of time stamping services as described occur in
[TSA] is requests and responses. In the most
simple form, and genrated localloy either by a subset requester or a DVCS,
they are represented as GeneralizedTime where fractions of this service.

The Certify Signature service seconds
are allowed.

An alternate form is used when a timeStampToken from a [TSA] or as a DVC, or as
token from another entity's signature third party service. When using third party
tokens, it is to be validated. The resulting token can then be used to support
non-repudiation services, to allow use a matter of the signature beyond public
key certificate revocation or expiry, or simply to delegate signature
validation policy whether a DVCS tries to interprete
or validate a trusted central service.

The Certify Public Key Certificate service timeStampToken.

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

Future versions of the protocol MAY include additional time formats.

Time values generated by the DVCS are increasing but not necessarily
unique using the order defined by serial numbers.

7.4. PKIStatusInfo

This structure is defined in [RFC2510]. It is used when as component of
the validity 'chain' field of one or more public key certificates is to be verified. This
service can be used when timely information regarding a certificate's
revocation state is required (e.g. high value funds transfer or TargetEtcChain structure, and as a global
status indicator in the
compromise DVCSResponse structure. Every occurence of a highly sensitive key) or when evidence supporting
non-repudiation
PKIStatusInfo is required. The response of generated by the validation responding DVCS to reflect the
result of some local verification.

7.5. TargetEtcChain

A TargetEtcChain structure contains certificates and other indicators
to describe either (in a
certificate containing a public key request) information to be used for encryption validated (in a
cpkc service) or the result of the verifications. The structure may
also contain additional certificates information about policies and policy mappings.

The details about how to be used as a simple method fill in and to
encrypt data or a session key interpret the structure are

Adams, Sylvester, Zolotarev, Zuccherato [Page 8]

draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999

defined later for additional authorised entities
(e.g., company key recovery).

DCS service requests MAY be signed or unsigned depending on each service.

the
configuration 'pathProcinput' field contains information about policies and the service that is
policy mapping to be provided.

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

- MessageImprint: validation.

If the request present, it contains a digest of some data, the Certify Possession result of Data service can be requested for a message imprint.

Reponses include a MessageImprint local verification of the data received in order to
allow to validate
immediately preceeding element, or of the correspondance to a request.

- Message:

For a CMS SignedData message, either target value, if it is the Certify Signature service
first element in the 'chain' sequence. If no 'pkistatus' or
'certstatus' is present, the Certify Possession of Data service DVCS considers all elements in the
'chain' as trustworthy. Note, that there may be for example an OCSP
response or DVC indicating an invalid certificate.

TargetEtcChain ::= SEQUENCE {
target CertEtcToken,
chain [0] SEQUENCE SIZE (1..MAX) OF
CertEtcToken OPTIONAL,
pathProcInput [1] PathProcInput OPTIONAL
}

PathProcInput ::= SEQUENCE {
acceptablePolicySet SEQUENCE SIZE (1..MAX) OF
PolicyInformation,
inhibitPolicyMapping BOOLEAN DEFAULT FALSE,
explicitPolicyReqd BOOLEAN DEFAULT FALSE
}

CertEtcToken ::= CHOICE {
certificate [0] Certificate ,
oscpcertid [1] CertId ,
esscertid [2] ESSCertId ,
datacert [3] SignedData ,
oscpresponse [4] OCSPResponse,
crl [5] CertificateList,
certstatus [6] CertStatus,
pkistatus [7] PKIStatusField ,
extension Extension
}

Certificate, PolicyInformation and CertificateListare are defined in
[RFC2459]. ESSCertId is defined in [RFC2634]. CertiId, OCSPResponse
and CertStatus are defined in [RFC2560]. PKIStatusField is defined in
[RFC2510].

The choice 'datacert' can be requested. For other
known contain a 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 certificate, or a list of public key certificates, certificate
validation chains
timeStamp, or other assertions.

The choices 'datacert', 'ocspresponse' and policy requirements, 'crl' are provided by
services external to the responding DVCS. The Certify Public Key
Certificate service can be requested. choices 'certStatus'

Adams, Sylvester, Zolotarev, Zuccherato [Page 6]

draft-ietf-pkix-dcs-01.txt DCS 9]

draft-ietf-pkix-dcs-02.txt DVCS Protocols July October 12, 1999

- Nonce:

A request

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

- CertIds: 'pkistatus' reflect decisions made directly by the responding
DVCS.

As a replacement for certificates, certification identifier identifiers
(ESSCertId, CertId) MAY be
used. There are actually two types imported from OCSP used in requests and from
S/MIME ESS.

Signatures made by responses, if this is
sufficient to perform the DCS MUST include an ESS signing certificate
attribute.

Requests and responses service, e.g., when the corresponding
certificates are provided elsewhere in a request or response (as part
of the public key certificate SignedData type).

7.6. DVCSReqInfo

A DVCSReqInfo data structure contains general information about the
data validation MAY
contain certificates, OCSP and S/MIME ESS certificate identifiers.

- TimeStamps

Indicators of time occur certification request. This structure occurs in requests a
request, and responses. In included in a corresponding data validation certificate.

DVCSReqInfo ::= SEQUENCE {
service ServiceType,
requester [0] GeneralNames OPTIONAL,
reqPolicy [1] PolicyInformation OPTIONAL,
DVCS [2] GeneralNames OPTIONAL,
dataLocator [3] GeneralName OPTIONAL,
nonce Integer,
reqTime DVCSTime OPTIONAL,
extensions Extensions OPTIONAL
}

The ServiceType type indicates the most
simple form, they are represented as GeneralizedTime. Fractions DVCS service type of
seconds a request.
See chapter 2 for a description of the services.

ServiceType ::= INTEGER { cpd(1), vsd(2), cpkc(3), ccpd(4) }

7.7. GeneralNames

There are allowed. The alternate form several occurences of sequences of GeneralName. For
syntactical conveniance the following type is a TimeStamping token,
either defined here:

GeneralNames ::= SEQUENCE OF GeneralName

GeneralName is imported from [TSA] or as a DCS token.

6. Request [RFC2459].

8. Data Validation and Token Format Certification Requests

A data certification request is a SignedData construct of [CMS] or
[PKCS7]. [RFC2630].
The contenttype indicated in the eContentType of the encapContentInfo
is of type id-ct-DCSReqData id-ct-DVCSReqData signalling a DCSReqData DVCSReqData as eContent of
the encapContentInfo (carried as an octet string).

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

with:

id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-smime

id-ct-DVCSReqData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 <draft>tbd</draft> }

Adams, Sylvester, Zolotarev, Zuccherato [Page 10]

draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999

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

DCSReqData A relaying DVCS MAY add an additional
signature or a countersignature attribute.

The content of a request consists of a description of the desired
service and additional parameters, the data to be validated, and an
optional identifier of the request.

DVCSRequest ::= SEQUENCE {
dcsReqInfo DCSReqInfo,

Adams, Sylvester, Zuccherato [Page 7]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999
reqInfo DVCSReqInfo,
data Data ,
requestIdentifier Data,
transactionIdentifier GeneralName OPTIONAL
}

The dcsReqInfo field 'reqInfo' element contains general information pertaining to about the data
certification request.

DCSReqInfo ::= SEQUENCE {
version Integer { v1(0) },
service ServiceType,
It is filled in by the 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 as follows:

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

ServiceType ::= INTEGER { cpd(1), cs(2), cpkc(3) } field 'service' contains the requested service.

- The value of requester the 'requester' field indicates the requesting entity.
If the field is present, and the requester request is signed, it MUST match
the identity (subjectName or subjectAltName extension) for of the
corresponding signing signature certificate, unless the request is signed
by a DCS DVCS (relaying a request to another server). A
DCS may include

When acting as a sequence of identities relay to DVCS MAY its own identity in the request, indication
the original requester, request
relayed to another service provider, and one or more other DCS. A DCS indicated
in it MAY remove the list are acting initial
value.

- The 'reqPolicy' field SHOULD indicate the policy under which the
certification is requested. This field MUST be checked by delegation. the DVCS
to verify agreement with its own policy. The value absence of dcs this field
indicates that any policy is acceptable.

- The 'dvcs' field MAY indicate a list a DCS DVCS 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 DVCS policy whether to honour honor this field or not. not, and to
define which choice of a general name is acceptable (e.g. an URL or
a DN). The DCS DVCS 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 'dataLocator' field SHOULD MAY indicate where a copy of the policy under which the
certification is requested. This 'data'
field MUST be checked by of the DCS to
verify agreement with request or supplementary information can be obtained.
The DVCS does not use this field for its own policy. The absence operation, the exact
interpretation of this field
indicates that any policy is acceptable. defined by applications.

Adams, Sylvester, Zolotarev, Zuccherato [Page 8]

draft-ietf-pkix-dcs-01.txt DCS 11]

draft-ietf-pkix-dcs-02.txt DVCS Protocols July October 12, 1999

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

A timeStampToken is either a DCSToken

- The 'nonce' field MAY be used to provide additional protection
against replay or content guessing attacks.

- The 'reqTime' field MAY be used to indicate the time for which the
requested service should be performed. For a TimeStampToken defined in
[TSA]. If a timeStampToken is present, this vsd and cpkc service,
it indicates to check whether the time
provided by another DCS signed document or TSA.

In situations certicates
where valid at the Data Certification Server will certify given time. For the
time included in other service, the request (i.e., when stipulated field is
ignored 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, DVCS. If the presence of this field indicates is absent, the current time
for which the validity and revocation status of
the certificate
SHOULD be reported. If this field DVCS is assumed.

- The 'extensions' field MAY be used to include additional
information. Extensions may be marked critical or not present, in order to
indicate whether the current time DVCS is assumed. supposed to understand them. This
document does not define extensions.

The Data type is defined to be either as a placeholder for service-specific
content, defined by each particular service provided by the message itself, a hash of DVCS.

Depending on the message (this allows requested service type, the field may contain
requester-specific data, a signature indicating possession signed document, a list of private
data to be certified) certificates, a
message digest or the certificate to be verified. arbitrary data.

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

In order to specify

The requester fills the format (i.e. 'data' element as follows:

- For a vsd service request, the requestor encapsulates a CMS
SignedData object in the type) value octets of the message so 'message' choice.

It is up to the requester to provide any certificate that it may be parsed and understood by
needed to verify the DCS or any verifying
entity, we define signature(s) in 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 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 }

In particular, if signedData object. The
requester MAY choose to remove all certificates from the message type is id-signedData (or any other
message type that allows more than one signature) signedData
(since they are not part of the signed part anyway, and more than one
SignerInfo (or signature) is present under transfer
them in the certificate list of the signedData structure containing
the DVCSRequest.

- For a cpkc service type cs, request the DCS certs choice is used.

Each certificate to be verified MUST verify all signatures present.

A failure be included in a separate
instance of TargetEtcChain. The target field SHALL contain the verification of one
cert to be verified and the chain field, if present, MUST indicate
the chain of trust to be used when certifying the signatures does not
necessarily result certificate. The
pathProcInput field, if present, SHOULD indicate the acceptable

Adams, Sylvester, Zolotarev, Zuccherato [Page 12]

draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999

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 [RFC2459]).

Only the failure Certificate, ESSCertId, CertId or Extension fields of the entire certification.

For a Data Possession service,
TargetEtcChain can be used in the request.

The requester may choose is responsible to send a
message or a hash of provide sufficient information to
the DVCS to identify the corresponding certificates.

- For a message instead using ccpd service the MessageImprint data
type.

MessageImprint ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
hashedMessage OCTET STRING } messageImprint choice is used.

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

- For a cpd service the message choice is used.

The hashedMessage field SHOULD 'message' contain requester-specific data with any type
of content. The DVCS does not inspect, modify, or take any
particular action based on the hash particular content of the DER encoding 'message'
field.

The element 'transactionIdentifier' MAY be used in order to permit to
associate DVCS responses containg error messages, to requests. For
example, in a mail based environment, the parameter could be a copy
of a messageid. Note, that the message expressed transactionIdentifier is not
necessary for associating a request with a data validation
certificate.

9. DVCS Responses

This chapters describes the data structures that are created by a
DVCS to indicate the results of validation and certification
requests.

A DVCS Response structure is generated by the DVCS as a Message result of
processing of the data type. certification validation request.

A Data Validation response is a SignedData construct of [RFC2630].
The hash contenttype indicated in the eContentType of the encapContentInfo
is
represented as an OCTET STRING.

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

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

CertetcToken ::= CHOICE {
cert [0] Certificate ,
esscertid [1] ESSCertId ,
dcstoken [2] DCSToken ,
oscpresponse [3] OCSPResponse,
pkistatus [4] PKIStatusField ,
extension Extension } of type id-ct-DVCSResponseData, signalling a DVCSResponse as
eContent of the encapContentInfo (carried as an octet string).

Adams, Sylvester, Zolotarev, Zuccherato [Page 10]

draft-ietf-pkix-dcs-01.txt DCS 13]

draft-ietf-pkix-dcs-02.txt DVCS Protocols July October 12, 1999

id-ct-DVCSResponseData OBJECT IDENTIFIER ::= { <draft>tbd</draft> }

The certs field SHOULD contain DVCS MUST use a key, specifically allocated for the certificate to be certified. Each
certificate SHALL be included purpose of
DVCS signing, with a proper extendedKeyUsage set in a separate instance of
TargetandChain. The target field SHALL contain corresponding
certificate.

In a critical situation when a DVCS can not produce a valid signature
(if the cert DVCS's signing key is known to be
verified and the chain field, if present, MUST indicate compromised, for example),
the chain of
trust to DVCSResponse must be used when certifying the certificate. The pathProcInput
field, if present, SHOULD indicate generated as a signedData with no signerInfo
attached. In this case, 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 [RFC2459]). CertificatePolicies is defined in
Section 4.2.1.5 of [RFC2459].

Only Certificate and ESSCertId response MUST be used in the request. ESSCertId
is only used when the corresponding certificate is available in one
of the TargetandChain components, or in the certificate list of the
SignerData of the DCS request.

Extensions are described in Section 4.2 of [RFC2459]. The
criticality of contain the extensions error
notification. Receiving unsigned DVCSResponse MUST be honoured treated by conformant DCSs and the
clients (e.g. requests and responses containing critical extensions
which are not understood MUST be rejected).

requestIdentifier is an identifier that is returned as supplied in a
response. The requester MAY use this element in order to associate
requests critical and fatal error, and responses. For example in a mail transport environment, the request identifier could be a copy content of a MessageId.

A DCS Response is the following data structure. At least message
should not be implicitly trusted.

A valid response can contain one of the
optional element MUST be present. DCS servers MAY choose produce only
signed responses (DCSResp containing a dcsToken), i.e., not to return
any information following:

1. A Data Validation Certificate (DVC), containing the results of
data validation operations, performed by the DVCS.

2. An error notification. This may happen when they cannot decode a request fails due to
a parsing error, requester authentication failure, or when signing anything
else that prevented the server from executing the request.

The following type is
not possible.

DCSResp used:

DVCSResponse ::= SEQUENCE CHOICE
{
requestIdentifier
dvcErrorNote [0] GeneralName OPTIONAL ,
responseStatus DVErrorNote,
dvCertInfo [1] PKIStatusInfo OPTIONAL,
dcsToken DCSToken OPTIONAL DVCertInfo
}

The responseStatus is un unsigned information only message.

9.1. DVCS Error Notification

A client
should not put more trust into element than into the lower level
transport. The reason for having DVCS Error Notification is a CMS signedData object (maybe with
signature) containing a DVCSResponse with a dvErrorNote choice.

DVErrorNote ::= SEQUENCE {
DVTransStatus PKIStatusInfo ,
transactionIdentifier GeneralName OPTIONAL }

The PKIStatusInfo is that that the server
might want to signal some additional information defined in a PKIFreeText of
responseStatus.

If the DCS Response contains a dcsToken, [RFC2511]. For the PKIStatus field purposes of
communicating the
requestStatus MUST be `granted' (0), or DVErrorNote, the requestStatus MUST be
absent. following subset PKIFailureInfo
for use in PKIStatusInfo is used:

PKIFailureInfo ::= BITSTRING {

badRequest (2),
-- transaction not permitted or supported

Adams, Sylvester, Zolotarev, Zuccherato [Page 11]

draft-ietf-pkix-dcs-01.txt DCS 14]

draft-ietf-pkix-dcs-02.txt DVCS Protocols July October 12, 1999

A dcsToken is a SignedData construct of [CMS]. The contenttype

badTime (3),
-- messageTime was not sufficiently close to the system time,
-- as defined by local policy
badDataFormat (5),
-- the data submitted has the wrong format
wrongAuthority (6),
-- the DVCS indicated in the eContentType of request is different from the encapContentInfo
-- one creating the response token
incorrectData (7),
--the requester's data (i.e. signature) is of type id-
ct-DCSInfo signalling a DCSReqData as eContent incorrect
)

In the DVError, the PKIStatus field 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. PKIStatusInfo must be set
to REJECTED.

The 'statusString' field of PKIStatusInfo can be used to include
reason text such as for example "Invalid request format". The data certification token MUST contain only DVCS
fills the DCS signatures,
i.e., signatures signed 'transactionIdentifier' with certificates having KeyPurposeID a copy of id-
kp-dcs.

DCSInfo ::= the
'transactionIdentifier' field of the corresponding DVCSRequest.

9.2. Data Validation Certificate

A Data Validation Certificate is a signedData object containing a
DVCSResponse with a dvCertInfo choice.

DVCertInfo::= SEQUENCE {
infoStatus PKIStatusInfo OPTIONAL,
dcsReqInfo DCSBasicInfo
nonce INTEGER OPTIONAL,
requestIdentifier GeneralName OPTIONAL
}

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

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

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

PKIStatusInfo

The DVCertInfo structure is defined in Section 3.2.3 returned as a result of successful
execution of data validation service. It contains the results of [RFC2510]. The
infoStatus field indicates whether or not the
data certification
request validation, a reference to the original request, and other
parameters. Please note that 'successful execution' does not
necessarily mean that the validation itself was fulfilled and, if not, failInfo indicates successful, a
DVCertInfo may contain both the reason it 'valid' and 'invalid' results.

The DVCS fille a DVCertInfo as follows:

Adams, Sylvester, Zolotarev, Zuccherato [Page 12]

draft-ietf-pkix-dcs-01.txt DCS 15]

draft-ietf-pkix-dcs-02.txt DVCS Protocols July October 12, 1999

was rejected. A valid

- The field 'nonce' MAY be used to protect against replay attacks.

- The dvReqInfo is essentially a copy of the 'reqInfo' field of the
corresponding request. The DVCS MAY modify the fields 'dvcs' and
'requester' of the ReqInfo structure, to indicate DVCS that
participated in the verification and certification.

- The field 'messageImprint' is a computed from the 'data' field of
the corresponding request as follows:

For the 'certs' choice, the digest is computed over the DER encoded
data certification token will have value. For a 'message' choice the digest is computed over the
value octets (not including tag and length octets) of the OCTET
STRING. It is up to the DVCS to choose an appropriate digest
algorithm.

For a 'messageImprint' choice, the 'messageImprint' of the
DVCSRequest is copied as is.

- The field 'serialNumber' contains a PKIStatus unique identifier of the
request.

- The field with 'respTime' indicates a time value associated to the
response. The value `granted' (0) MAY be a locally generated one, or 'grantedWithMods' (1). If a signed
TimeStampToken (TST) or DVC obtained from an external service.

- The field 'dvStatus' reflects a collective status of the only
content
validation.

An omitted 'dvStatus' field implies SUCCESS, except in case of a
cpkc service, where each element of the PKIStatus 'certs' field have their
own independant status. If the 'dvStatus' is set for a PKIStatus cpkc service
response, this is equivalent to putting an identical one into each
element of 'certs' field with as a value of
'granted', PKIStatusField is last element in the 'chain' field.

If the field 'dvStatus' does not generated. indicate success ('granted' or
'granted with mods') the element 'failInfo' MAY indicate the reason
for the failure. Note that the field 'certs' MAY contain
additional information about verification failures.

A failure of the verification of one of the signatures does not
necessarily result in the production of an error message. For
example, as long as a sufficient number of signature verifications
was successful, a token DVC with status `grantedWithMods` MAY is be produced.
A token DVC with status `granted` MUST only be produced if all signatures
verified successfully.

Whether a `grantedWithMods` response or an error response will be
produced is a matter of local policy.

The dcsReqInfo MUST be the same value as the dcsReqInfo field in
DCSReqData.

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

The dataLocator MUST be the same value as the dataLocator field in
the DCSReqInfo.

reqSignature MUST be the same value as the signerInfos field of the
DCSRequest.

For a Signature and Certificate validation, chainCerts MUST indicate
the chains of trust, present, and additional information (OCSP responses,
DCSToken, PKIStatusField) that was used by the DCS to verify the
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 case of validation of a
public key certificate used for encryption purposes, additional
certificates may status MUST be included set 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) FAILED, if

Adams, Sylvester, Zolotarev, Zuccherato [Page 13]

draft-ietf-pkix-dcs-01.txt DCS 16]

draft-ietf-pkix-dcs-02.txt DVCS Protocols July October 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 validation has failed to successfully verify all or some
of the wrong format
wrongAuthority (6),
-- the DCS indicated in data. The field MUST be present, and the request status must be set
to WAITING, if there is different from no or only an incomplete response
immediately available.

In the
-- one creating situation when the response token
incorrectData (7),
--the requester's data (i.e. signature) is incorrect
--(i.e., invalid)
missingTimeStamp (8),
-- when validation fails, the timestamp is missing but should be there (by policy)
certInvalid (9),
-- requestor can
further investigate the certificate fails to validate against Section 6 cause of [RFC2459]
certRevoked (10),
-- the certificate is revoked
certExpired (11),
-- failure, by looking into the certificate has expired
certOnHold (12),
--
TargetEtcChain fields. 'pkistatus' fields in the certificate TargetEtcChain
will indicate which item(s) has been operationally suspended
certNotActive (13)
-- the certificate was not active at failed the given time } validation and for what
reason.

- The statusString 'policy' field of PKIStatusInfo can indicates the policy under which the DVCS
operates.

- If present, 'reqSignature' MUST be used the same value as the
signerInfos field of the corresponding request. It is a policy
decision whether to include reason
text such as "CA's public key revoked". this field.

- The crls 'certs' field (if present) SHOULD contain contains the results is the verifications made by
the DVCS. For the cpkc service each element contains a copy of a
corresponding field of the request plus the result of the
verfications or external certification. For a sequence vsd service each
element contains the result of certificate
revocation lists that is sufficient to verify the chains validation of one signature of trust
indicated in
the chainCerts field. signed document to be validated.

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

- The reqSignature, chainCerts, crls and policyInfo fields are included
as OPTIONAL. They SHOULD 'extensions' field MAY be present, when policy dictates, for use
as supplementary evidence when resolving possible disputes. Dispute
resolution would most likely used to return additional information
to the client. Extensions MAY be handled by one marked critical or more humans, not in an
off-line environment, and is beyond order to
indicate whether the scope of this document.

7. client is supposed to understand them. This
document does not define extensions.

10. 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.

7.1

10.1 DVCS Protocol via HTTP or HTTPS

This subsection specifies a means for conveying ASN.1-encoded
messages for the DVCS protocol exchanges via the HyperText Transfer
Protocol.

The DER encoded DVCS requests and responses are encapsulated using a

Adams, Sylvester, Zolotarev, Zuccherato [Page 17]

draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999

simple MIME object with Content-Type application/dvcs and an
appropriate Content-Transfer-Encoding.

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

10.2 File Based Data Certification Server Protocol

A file containing a data validation and 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.

7.2

10.3 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 DVCS requests and responses are encapsulated using a
simple MIME object with Content-Type application/dcs application/dvcs 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.

7.3 DCS Protocol via HTTP

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

The DER encoded DCS requests and responses are encapsulated using a
simple MIME object 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 mail transport for DCS Data
Validation and Certification Server messages.

11. Security Considerations

This entire document chapter discusses security considerations.

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

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 DVCS acts upon the request. The Data Certification Server DVCS is
REQUIRED to validate appropriate information within the request
before it constructs the data certification token. It is therefore
mandated that the DCS DVCS 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

Adams, Sylvester, Zolotarev, Zuccherato [Page 18]

draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999

is compromised and the corresponding certificate is revoked after
the Data Certification Server DVCS acts upon the request. This is not a concern to the DCS DVCS,
once the Data Certification Server DVCS has constructed the token, DVC, 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,
human-aided, means specific to the situation at hand.

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

4. The DCS DVCS 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 DVCs signed by the DCS DVCS 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 DVC's signature. Data certification tokens validation
certificates 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 DVCS can no longer be
trusted, its certificate MUST be revoked. Thus, at any future time
the tokens DVCs signed with the corresponding key will not be trusted.

6. In certain circumstances, a DCS DVCS 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
DVCS MAY create a response that only contain a PKIStatusInfo.

Adams, Sylvester, Zuccherato [Page 16]

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

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

8. Client identification and authentication may MAY use services defined
by TLS [RFC2246]) instead of using a signed request.

8. In situations where

9. When confidentiality and server authentication is required,
requests and responses MAY be protected using appropriate
mechanisms (e.g. CMS encapsulation [CMS] [RFC 2630] or TLS [RFC2246]).

12. Patent Information

Adams, Sylvester, Zolotarev, Zuccherato [Page 19]

draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999

The following United States Patents related to data validation and
certification services, listed in chronological order, are known by
the authors to exist at this time. This may not be an exhaustive
list. Other patents may exist or be issued at any time. Implementers
of the DCS DVCS 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.,

# 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

Adams, Sylvester, Zolotarev, Zuccherato [Page 20]

draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999

(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-02.txt, 1999 (work in progress).

[RFC2510] C. Adams, S. Farrell, "Internet X.509 Public Key
Infrastructure, Certificate Management Protocols," RFC-2510, 1999.

[RFC2459] R. Housley, W. Ford, W. Polk, D. Solo, "Internet X.509
Public Key Infrastructure, Certificate and CRL Profile", RFC-2459.
January 1999.

[CMS]

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

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

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

[RFC2511] M. Myers, C. Adams, D. Solo, D. Kemp "Internet X.509
Certificate Request Message Format," 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]

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

[OCSP]

[RFC2560] 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). RFC 2560, June 1999.

11. Authors' Addresses

Carlisle Adams
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
K1V 1A7
CANADA
robert.zuccherato@entrust.com
;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. Addresses

Carlisle Adams
Entrust Technologies
750 Heron Road

Adams, Sylvester, Zolotarev, Zuccherato [Page 19]

draft-ietf-pkix-dcs-01.txt DCS 21]

draft-ietf-pkix-dcs-02.txt DVCS Protocols July October 12, 1999

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

Furthermore, we

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

Michael Zolotarev
Baltimore Technologies Pty Limited,
5th Floor, 1 James Place,
North Sydney, NSW 2060.
AUSTRALIA
mzolotarev@baltimore.com

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

APPENDIX A - PKCS #9 Attrubute

We define a PKCS #9 [PKCS9] dcs token attribute type. This attribute type specifies the dcs token, which MAY
be included as a signed attribute of the SignedData object. The dcs token
attribute type has ASN.1 type DCSToken SignedData and contains a dvc (as
defined in this document).

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

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

id-DVCS-dvc OBJECT IDENTIFIER ::= { id-smime 2 <draft>tbd</draft> }

The attribute may be used as a authenticated or unauthenticated
attribute in CMS SignedData documents.

APPENDIX B - Extending the Life of a Signature Signed document validation.

We present an example some examples of a possible use of this data certification
service. DVCS in the context of
validation signed documents.

Adams, Sylvester, Zolotarev, Zuccherato [Page 22]

draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999

B.1 Signed document validation

The example covers the case where a DVCS is used by a signer to
obtain a proof that a document's structure, including one or more
attached signatures, is/was correct, after the document was signed.

The certificate can be provided either by a DVCS that is trusted by
the signer, or by a DVCS that is trusted by an intened verifier of
the document.

The signer get's an evidence that its intentions were good and it
produced a signed document using the environment(keys, algorithms,
etc) that was known to be OK.

It produces a stand-alone token document that can be used to extend the
life of a signature. This example assumes that we have total trust
in the Data Validation and 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 Validation and
Certification Server in the data field of DCSReqInfo DVCSReqInfo under
service type cs and an appropriate policy.

2) The Data Validation and 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 Validation and 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 DVCS's
signing key (and therefore, its signature) is valid until some

Adams, Sylvester, Zuccherato [Page 20]

draft-ietf-pkix-dcs-01.txt DCS Protocols July 12, 1999
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

Adams, Sylvester, Zolotarev, Zuccherato [Page 23]

draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999

time T2, regardless of subsequent revocation or expiry at time T1.

If the signature of the DCS DVCS is valid, the trust we have in the DCS DVCS
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 two examples of how to produce a stand-alone token data validation
certificate that can be used to confirm the revocation status of assert that a public key
certificate.

CRLs certificate
is valid, trusted, and ARLs are updated according can be used for a particular purpose.

A client wants to use a given public key certificate either to use it
in 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 signature or ARL update. Since the DCS to use it it for document encryption.

A DVCS MUST have access to current information regarding public key
certificate status, it can also therefore be used to verify the revocation
status of a certificate in this situation.

In order to produce such a token, at the current time.

The following technique MAY be
used. is used:

A) The public key certificate needs to be validated and certified.

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

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

B) The data certification token validation certificate MUST be verified.

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

This

C) The public key certificate is used.

1) A clients's own public key certificate (i.e., the corresponding
private key) can be used to add a signature to a document. The
signing certificate and the data certification token validation certificate are
added as signed attributes to the signature.

A data validation certificate can now be used when verifying
signatures using the key contained in the public key
certificate. This service provided by the DCS DVCS can be thought of

Adams, Sylvester, Zolotarev, Zuccherato [Page 24]

draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999

as a supplement to the usual method of checking revocation
status.

Adams, Sylvester, Zuccherato [Page 21]

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

In other words, signature validation at a later time does not
necessarily require access to the revocaton status of the user's
signing certificate, access to a DVCS service and validation of
the DVC is sufficient to validate the signed document.

2) A public key certificate for for key exchange can be used after
having obtained a data validation certification certificate to
encrypt data. The DVC can be stored with the data and/or stored
by the creator of the encrypted document.

If an intended recipient of the document claims that the creator
did not use an appropriate encryption key, the DVC (obtained by
a recipient's DVCS) can be used as evidence that the recipient's
DVCS has authorized the usage of the public key.

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 dvcs

Required parameters: None

Optional parameters: None

Encoding considerations: binary or Base64

Security considerations: Carries a request for a data validation and
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
Validation and Certification Server Protocols

Applications which use this media type: Data Validation and
Certification Server clients

Additional information:

Adams, Sylvester, Zolotarev, Zuccherato [Page 25]

draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999

Magic number(s): None
File extension(s): .dcs .dvc
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

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, Zolotarev, Zuccherato [Page 23] 26]

----