Internet Draft Adams, Sylvester, Zolotarev, Zuccherato
PKIX Working Group July 14, 2000 expires January 14, 2001
Internet X.509 Public Key Infrastructure
Data Validation and Certification Server Protocols
<draft-ietf-pkix-dcs-05.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 services (see [ISONR]).
Useful Data Validation and Certification Server responsibilities in a
PKI are to validate signed documents and to assert the validity of
public key 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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
Adams, Sylvester, Zolotarev, Zuccherato [Page 1]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
as shown) are to be interpreted as described in [RFC2119].
<draft> This version contains object some object identifiers that
need to be confirmed (or changed):
-- Authority Information Access for DVCS
id-ad-dvcs OBJECT IDENTIFIER ::= {id-ad 4}
-- Key Purpose for DVCS
id-kp-dvcs OBJECT IDENTIFIER ::= {id-kp 10}
-- eContentType for a dvcs requests and responses
id-ct-DVCSRequestData OBJECT IDENTIFIER ::= { id-ct 7 }
id-ct-DVCSResponseData OBJECT IDENTIFIER ::= { id-ct 8 }
-- Data validation certificate attribute
id-aa-dvcs-dvc OBJECT IDENTIFIER ::= { id-aa 29 }
-- the previous could actually be pkcs9-at-pkcs7PDU of pkcs9 v2
using the following bases :
id-pkix OBJECT IDENTIFIER ::= {iso(1)
identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)}
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
id-mod OBJECT IDENTIFIER ::= {id-pkix 0 }
id-kp OBJECT IDENTIFIER ::= {id-pkix 3 }
id-ad OBJECT IDENTIFIER ::= {id-pkix 48}
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-aa OBJECT IDENTIFIER ::= { id-smime 2 }
id-mod-dvcs OBJECT IDENTIFIER ::= {id-mod 15}
</draft>
1. Introduction
A Data Validation Server (DVCS) is a Trusted Third Party (TTP)
providing data validation services, asserting correctness of
Adams, Sylvester, Zolotarev, Zuccherato [Page 2]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
digitally signed documents, validity of public key certificates, and
possession of data.
As a result of the assertion, a DVCS generates a Data Validation
Certificate (DVC) The data validation certificate can be 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 the
validity and correctness of a digitally signed document.
DVCS services do not replace the usage of CRLs and OCSP for public
key certificate revocation checking in large open environments, due
to concerns about the scalability of this protocol.
It should be rather used to support non-repudiation or to supplement
more traditional services concerning paperless document environments.
The presence of a data validation certificate supports non-
repudiation in two ways. It provides evidence that a digitally signed
document or public key certificate was valid at the time indicated in
the dvc. The dvc for a public key certificate can be used even after
the public key certificate expires and its revocation information is
no longer 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 validation certificate in response to a
signed request for validation of a signed document or public key
certificate also provides evidence that due diligence was performed
by the requester in validating a digital signature or public key
certificate.
2. DVCS Services
The current specification defines 4 types of validation and
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).
A DVCS is REQUIRED to support at least a subset of these services.
On completion of each service, the DVCS produces a data validation
certificate - a signed document containing the validation results and
trustworthy time information.
Adams, Sylvester, Zolotarev, Zuccherato [Page 3]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
2.1 Certification Possession of Data
The Certification of Possession of Data service provides evidence
that the requester possessed data at the time indicated and that the
actual data where presented to the Data Validation Server.
2.2 Certification of Claim of Possession of Data
The Certification Claim of Possession of Data service is similar to
the previous one, except that the requester does not present the data
itself but a message digest. This service is similar to time stamping
services as described in [TSP].
2.3 Validation of Digitally Signed Documents
The Validation of Digitally Signed Document service is used when
validity of a signed document is to be asserted.
The DVCS verifies all signatures attached to the signed document
using all appropriate status information and public key 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 path
from the 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 DVCS services.
The DVCS will perform verification of all signatures attached to the
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 the
document has an insufficient number of signatures.
2.4 Validation of Public Key Certificates
The Validation of Public Key Certificates service is used to verify
and assert the validity (according to [RFC2459]) of one or more
public key certificates at the specified time.
When verifying a public key certificate, the DVCS verifies that the
certificate included in the request is a valid certificate and
determines its revocation status at a specified time. DVS checks the
full certification path from the certificate's issuer to a trusted
point. Again the DVCS MAY be able to rely on external information
Adams, Sylvester, Zolotarev, Zuccherato [Page 4]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
(CRL, OCSP, DVCS).
3. Data Certification Server usage and scenarii.
It is outside the scope of this document to completely describe
different operational scenarii, or usages for DVCS.
See Appendix B and C for a set of some basic examples and use cases.
The Validate Signed Document service can be used to support non-
repudiation services, to allow use of the signed document beyond
public key certificate revocation or expiry, or simply to delegate
signature validation to a trusted central (company wide) service.
The Validate Public Key Certificate service can be used when timely
information regarding a certificate's revocation status 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 data validation certificate may be used to simplify the validation
of a signature beyond the expiry or subsequent revocation of the
signing certificate: a Data validation certificate used as an
authenticated attribute in a signature includes an additional
assertion about the usability of a certificate that was used for
signing. In order to validate such a signature it may be sufficient
to only validate the data validation certificate.
A 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 Certification of Claim of Possession of Dataservice is equivalent
to the services described in [TSP].
The Certification of Possession of Data service can be used to assert
legal deposit of documents, or to implement archival services as a
trusted third party service.
The Data Validation and Certification Server Protocols can be used in
different service contexts. Examples include company-wide centralised
services (verification of signatures, certification of company
certificates), service to cooperate in a multi-organisation
community, or general third party services for time stamping or data
archival.
An important application of DVCS is an enterprise environment where
Adams, Sylvester, Zolotarev, Zuccherato [Page 5]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
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).
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. In this sense it can be regarded as an Evidence
Recording Authority [ISO-NR].
4. Functional Requirements for DVCS
The DVCS MUST
1. provide a signed response in the form of a data validation
certificate to the requester, as defined by policy, or an error
response. The DVCS service definition and the policy define how
much information that has been used by the DVCS service to
generate the response will be included in a data validation
certificate, e.g., public key certificates, CRLs, and responses
from other OCSP servers, TSA and DVCS.
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
data validation certificate.
4. include a time of day value or a time stamp token into each data
validation certificate.
5. sign each data certification token using a key that has been
certified with a dvcs signing extended key purpose, and include a
reference to this certificate as a signed attributes in the
signature.
6. check the validity of its own signing key and certificate before
delivering data validation certificates and MUST not deliver data
validation certificate in case of failure.
A DVCS SHOULD include within each data validation certificate a
policy identifier to determine the trust and validation policy used
Adams, Sylvester, Zolotarev, Zuccherato [Page 6]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
for DVC's signature.
5. Data Certification Server Transactions
A DVCS transaction begins with a client preparing 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.
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 formed as a signed
document (CMS SignedData).
If the request was invalid, the DVCS generates a response message
containing an appropriate error notification.
Upon receiving the response, the requesting entity SHOULD verify its
validity, i.e. it contains the correct time, the correct name for the
DVCS, the correct request information and message imprint, a valid
signature, and satisfactory status, service and policy fields.
When verifying validity of a DVC, it is up to the requestor's
application to check whether a DVCS's signing certificate was valid.
Depending on the usage environment, different methods (online or out
of band, CRLs, DVCS, OCSP...) may have to be used.
After all checks passed, the data validation certificate can be used
to authenticate the correctness or possession of the corresponding
data.
6. Identification of the DVCS
In order to be able to import elements from dvcs the following object
identifier is used as a ASN.1 module identifier.
id-mod-dvcs OBJECT IDENTIFIER ::= {id-mod 15}
id-mod OBJECT IDENTIFIER ::= {id-pkix 0 }
The DVCS MUST sign all data certification messages with a key whose
corresponding certificate MUST contain the extended key usage field
Adams, Sylvester, Zolotarev, Zuccherato [Page 7]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
extension as defined in [RFC2459] Section 4.2.1.14 with KeyPurposeID
having value id-kp-dvcs. This extension MUST be marked as critical.
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 10 }
Consistent KeyUsage bits:
digitalSignature, nonRepudiation, keyCertSign, cRLSign
A DVCS's certificate MAY contain an Authority Information Access
extension [RFC2459] in order to convey the method of contacting the
DVCS. The accessMethod field in this extension MUST contain the OID
id-ad-dvcs:
id-ad-dvcs OBJECT IDENTIFIER ::= {id-ad 4}
The value of the field 'accessLocation' field defines the transport
(e.g., an URI) used to access the DVCS.
7. Common Data Types
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 and
describes these types and lists their usages.
7.1 Version:
The request and the response include an optional integer field
specifying the version of the data structure. For both fields the
default value is 1, thus not present at all in this version of the
protocol.
7.2 DigestInfo:
This element is defined in [RFC2315]. Since the status of that
document is informational, the definition is repeated here:
DigestInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
digest Digest
}
Digest ::= OCTET STRING
Adams, Sylvester, Zolotarev, Zuccherato [Page 8]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
The fields of 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 is used in two places:
- as a data portion for the ccpd service, and
- 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.3. Nonce
Requests and responses may include Nonce values. A Nonce in the
request is returned as is in the response. The DVCS may create an
additional Nonce in the response.
The following definition is used:
Nonce ::= INTEGER
7.4. Time Values
Indicators of time can be present in requests and responses. In the
most simple form, the time is represented as GeneralizedTime where
fractions of seconds are allowed.
An alternate form is a timeStampToken from a TSA, or as a DVC (or
some other token) from another third party service. When using third
party tokens, it is a matter of policy whether a DVCS tries to
interpret or validate a timeStampToken.
DVCSTime ::= CHOICE {
genTime GeneralizedTime,
timeStampToken ContentInfo
}
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.
Adams, Sylvester, Zolotarev, Zuccherato [Page 9]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
7.5. PKIStatusInfo
This structure is defined in [RFC2510]. It is used as component of
the 'chain' field of a TargetEtcChain structure, and as a global
status indicator in the DVCSResponse structure. Every occurrence of
PKIStatusInfo is generated by the responding DVCS to reflect the
result of some local verification.
7.6. TargetEtcChain
A TargetEtcChain structure contains certificates and other indicators
to describe either (in a request for a cpkc service) information to
be validated, or the result of the verifications. The structure may
also contain information about policies and policy mappings.
The details about how to fill in and to interpret the structure are
defined later for each service.
The 'pathProcInput' field contains information about policies and
policy mapping to be used or used during a validation.
In a response, the 'pkistatus' and 'certstatus' choices can only
occur in in the 'chain' sequence. If present, they contain the
result of a local verification of the immediately preceding element,
or of the target value, if it is the first element in the 'chain'
sequence. If no 'pkistatus' or 'certstatus' is present, the 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 SEQUENCE SIZE (1..MAX) OF
CertEtcToken OPTIONAL,
pathProcInput [0] PathProcInput OPTIONAL
}
PathProcInput ::= SEQUENCE {
acceptablePolicySet SEQUENCE SIZE (1..MAX) OF
PolicyInformation,
inhibitPolicyMapping BOOLEAN DEFAULT FALSE,
explicitPolicyReqd BOOLEAN DEFAULT FALSE
}
CertEtcToken ::= CHOICE {
certificate [0] IMPLICIT Certificate ,
esscertid [1] ESSCertId ,
pkistatus [2] IMPLICIT PKIStatusInfo ,
Adams, Sylvester, Zolotarev, Zuccherato [Page 10]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
assertion [3] ContentInfo ,
crl [4] IMPLICIT CertificateList,
ocspcertstatus [5] IMPLICIT CertStatus,
oscpcertid [6] IMPLICIT CertId ,
oscpresponse [7] IMPLICIT OCSPResponse,
capabilities [8] SMIMECapabilities,
extension Extension
}
Certificate, PolicyInformation and CertificateList are defined in
[RFC2459]. ESSCertId is defined in [RFC2634]. CertId, OCSPResponse
and CertStatus are defined in [RFC2560]. PKIStatusField is defined in
[RFC2510].
The choice 'assertion' can contain a data validation certificate, or
a timeStamp, or other assertions.
The choices 'assertion', 'ocspresponse' and 'crl' are provided by
services external to the responding DVCS. The choices 'certStatus'
and 'pkistatus' reflect decisions made directly by the responding
DVCS.
As a replacement for certificates, certification identifiers
(ESSCertId, CertId) MAY be used in requests and responses, if this
is sufficient to perform the service, e.g., when the corresponding
certificates are provided elsewhere in a request or response (as part
of the SignedData type).
The choice 'capablities' can be used to indicate SMIMECapabilities.
It applies to the certificate identified by the preceding element in
the sequence.
7.7. DVCSRequestInformation
A DVCSRequestInformation data structure contains general information
about the data validation and certification request. This structure
occurs in a request, and is also included in a corresponding data
validation certificate.
DVCSRequestInformation ::= SEQUENCE {
version INTEGER DEFAULT 1 ,
service ServiceType,
nonce Nonce OPTIONAL,
requestTime DVCSTime OPTIONAL,
requester [0] GeneralNames OPTIONAL,
requestPolicy [1] PolicyInformation OPTIONAL,
dvcs [2] GeneralNames OPTIONAL,
dataLocations [3] GeneralNames OPTIONAL,
Adams, Sylvester, Zolotarev, Zuccherato [Page 11]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
extensions [4] IMPLICIT Extensions OPTIONAL
}
The ServiceType type enumerates the DVCS service type of a request.
See chapter 2 for the description of the services.
ServiceType ::= ENUMERATED { cpd(1), vsd(2), cpkc(3), ccpd(4) }
7.8. GeneralName and GeneralNames
There are several occurences of sequences of GeneralName and
GeneralNames These structures are imported from [RFC2459].
8. Data Validation and Certification Requests
A data certification request is a SignedData construct of [RFC2630].
The contenttype indicated in the eContentType of the encapContentInfo
is of type id-ct-DVCSRequestData signalling a DVCSRequestData as
eContent of the encapContentInfo (carried as an octet string).
id-ct-DVCSRequestData OBJECT IDENTIFIER ::= { id-ct 7 }
A data certification request MAY contain several SignerInfo
structures, and countersignature attributes depending on operational
environments. When an end user client creates the request, there is
one or zero SignerInfo. 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 {
requestInformation DVCSRequestInformation,
data Data,
transactionIdentifier GeneralName OPTIONAL
}
The 'DVCSRequest.requestInformation' element contains general
information about the request. It is filled in by the requester as
follows:
- The 'version' field is never present in this version of the
protocol.
The field 'service' contains the requested service.
- The 'nonce' field MAY be used to provide additional protection
Adams, Sylvester, Zolotarev, Zuccherato [Page 12]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
against replay or content guessing attacks.
- The 'requestTime' field MAY be used to indicate the time for which
the requested service should be performed. For a vsd and cpkc
service, it specifies the time for which the validity of a signed
document or certicates is to be asserted. For the other service,
the field is ignored by the DVCS. If the field is absent, the
current time is assumed.
- The value of the 'requester' field indicates the requesting entity.
The interpreation and usage of this field MUST be defined by the
DVCS policy.
Some usage example are:
If the field is present, and the request is signed, a DVCS MAY for
example require that the field MUST match the identity
(subjectName or subjectAltName extension) of the corresponding
signature certificate,
A the request MAY be signed by a DVCS when relaying a request to
another server.
When acting as a relay to DVCS MAY its own identity in the request
relayed to another service provider, and it MAY remove the initial
value.
- The 'requestPolicy' field SHOULD indicate the policy under which
the validation is requested. This field MUST be checked by the DVCS
to verify agreement with its own policy. The absence of this field
indicates that any policy is acceptable.
- The 'dvcs' field MAY be used to indicate a list a 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 DVCS policy whether to honor this field or not, and to
define which choice of a general name is acceptable (e.g. an URL or
a DN). The DVCS MAY use local information to use additional
external services.
- The 'dataLocations' field MAY be used to indicate where a copy of
the 'data' field of the request or supplementary information can be
obtained. The DVCS does not use this field for its own operation,
the exact interpretation of this field is defined by applications.
- The 'requestTime' field MAY be used to indicate the time for which
the requested service should be performed. For a vsd and cpkc
Adams, Sylvester, Zolotarev, Zuccherato [Page 13]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
service, it specifies the time for which the validity of a signed
document or certicates is to be asserted. For the other service,
the field is ignored by the DVCS. If the field is absent, the
current time is assumed.
- The 'extensions' field MAY be used to include additional
information. Extensions may be marked critical or not in order to
indicate whether the DVCS is supposed to understand them. This
document does not define extensions.
The DVCSRequest.data contains service-specific content, defined by
each particular service provided by the DVCS.
Depending on the requested service type, the field may contain a
signed document, a list of certificates, a message digest or
arbitrary data.
The following type is used:
Data ::= CHOICE {
message OCTET STRING ,
messageImprint DigestInfo,
certs SEQUENCE SIZE (1..MAX) OF
TargetEtcChain
}
The requester fills the 'data' element as follows:
- For a vsd service request, the requestor encapsulates a CMS
SignedData object in the value octets of the 'message' choice.
It is up to the requester to decide whether and how to provide any
certificate that may be needed to verify the signature(s) in the
signedData object. A requester MAY add certificates to the
encapsulated signedData object or in the certificate list of the
request.
- For a cpkc service request the 'certs' choice is used.
Each certificate to be verified MUST be included in a separate
instance of TargetEtcChain. The 'TargetEtcChain.target' field
SHALL contain the certificate to be verified. The
'TargetEtcChain.chain' field, if present, MUST indicate the chain
of trust to be used when certifying the certificate. The
'TargetEtcChain.pathProcInput' field, if present, indicates the
acceptable policy set and initial settings for explicit-policy-
indicator and inhibit-policy-mapping indicators to be used in X.509
Adams, Sylvester, Zolotarev, Zuccherato [Page 14]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
public key certificate path validation (see [RFC2459]).
Only the Certificate, ESSCertId, CertId or Extension choices of the
TargetEtcChain can be used in the request.
The requester is responsible for providing sufficient information
to the DVCS to identify the corresponding certificates.
- For a ccpd service the '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 field contains requester-specific data with any type of
content. The DVCS does not inspect, modify, or take any particular
action based on the particular content of the 'message' field.
The field 'DVCSRequest.transactionIdentifier' MAY be used in order to
associate DVCS responses containing error messages, to requests. For
example, in a mail based environment, the parameter could be a copy
of a messageid. Note, that the transactionIdentifier is not
necessary for associating a request with a valid 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 result of
processing of the data validation and certification request.
A Data Validation response is a SignedData construct of [RFC2630].
The contenttype indicated in the eContentType of the encapContentInfo
is of type id-ct-DVCSResponseData, signalling a DVCSResponse as
eContent of the encapContentInfo (carried as an octet string).
id-ct-DVCSResponseData OBJECT IDENTIFIER ::= { id-ct 8 }
Adams, Sylvester, Zolotarev, Zuccherato [Page 15]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
The DVCS MUST use a key, which is specifically allocated for the
purpose of DVCS signing, with a proper extendedKeyUsage set in a
corresponding certificate.
In a critical situation when a DVCS cannot produce a valid signature
(if the DVCS's signing key is known to be compromised, for example),
the DVCSResponse, containing the error notification, MUST be
generated as a signedData with no signerInfo attached. Receiving
unsigned DVCSResponse MUST be treated by the clients as critical and
fatal error, and the content of the message should not be implicitly
trusted.
A valid response can contain one of the following:
1. A Data Validation Certificate (DVC), delivering the results of
data validation operations, performed by the DVCS.
2. An error notification. This may happen when a request fails due to
a parsing error, requester authentication failure, or anything
else that prevented the server from executing the request.
The following type is used:
DVCSResponse ::= CHOICE
{
dvCertInfo DVCSCertInfo ,
dvErrorNote [0] DVCSErrorNotice
}
9.1. Data Validation Certificate
A Data Validation Certificate is a signedData object containing a
DVCSResponse with a 'dvCertInfo' choice.
DVCSCertInfo::= SEQUENCE {
version Integer DEFAULT 1 ,
dvReqInfo DVCSRequestInformation,
messageImprint DigestInfo,
serialNumber Integer,
responseTime DVCSTime,
nonce Nonce OPTIONAL,
dvStatus [0] PKIStatusInfo OPTIONAL,
policy [1] PolicyInformation OPTIONAL,
reqSignature [2] SignerInfos OPTIONAL,
certs [3] SEQUENCE SIZE (1..MAX) OF
TargetEtcChain OPTIONAL,
extensions Extensions OPTIONAL }
Adams, Sylvester, Zolotarev, Zuccherato [Page 16]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
The DVCSCertInfo structure is returned as a result of successful
execution of data validation service. It contains the results of the
data validation, a reference to the original request, and other
parameters. Please note that 'successful execution' does not
necessarily mean that the validation itself was successful - a
DVCSCertInfo may contain both the 'valid' and 'invalid' results.
The DVCS creates a DVCSCertInfo as follows:
- The 'version' field is never present in this version of the
protocol.
The 'dvReqInfo' is essentially a copy of the 'requestInformation'
field of the corresponding request. The DVCS MAY modify the fields
'dvcs', 'requester' and 'dataLocations' of the ReqInfo structure,
e.g., if the request was processed by a chain of DVCS, if the
request to indicate DVCS, or to indicate where to find a copy of
the data from a 'vpd' request.
- The 'DVCSCertInfo.messageImprint' field is computed from the 'data'
field of the corresponding request as follows:
For the 'certs' choice (the 'vpkc' service), the digest is computed
over the DER encoded data value. For a 'message' choice (the 'vsd'
and the 'vpd' services) 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 'vcpd' service), the
'messageImprint'
of the DVCSRequest is copied as is.
- The 'DVCSCertInfo.serialNumber' field contains a unique identifier
of the request.
- The field 'responseTime' indicates a time value associated to the
response. The value MAY be a locally generated one, or a signed
TimeStampToken (TST) or DVC obtained from an external service.
- The 'DVCSCertInfo.nonce' field MAY be used to protect against
replay attacks.
- The field 'DVCSCertInfo.dvStatus' reflects a collective result of
the validation.
If the field is missing, it is an equvivalent of the SUCCESS
status.
Adams, Sylvester, Zolotarev, Zuccherato [Page 17]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
For a vkpc, if the status field is present and set to SUCCESS, it
indicates that all certificates were successfully validated. If it
is present and set to FAILED, it indicates that all or some of the
certificates failed validation, and the specific status of the
'certs' should be investigated, at least of the elements of the
'certs' TargetEtcChain structures MUST have a failure status.
If the field 'dvStatus' does not 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 failing to validate a signed document. For
example, as long as a sufficient number of signature was
successfully verified, a DVC with status `grantedWithMods` may be
produced. A DVC with status `granted` MUST only be produced if all
signatures verified successfully.
The field MUST be present, and the status must be set to WAITING,
if no final response can be immediately available.
In case of failure, the requester can further investigate the cause
of the failure, by looking into the TargetEtcChain fields.
'CertEtctoken.pkistatus' fields will indicate which item(s) has
failed or succeeded the validation and for what reason.
- The 'DVCSCertInfo.policy' field indicates the policy under which
the DVCS operates.
- If present, 'DVCSCertInfo.reqSignature' MUST be the same value as
the signerInfos field of the corresponding request. It is a policy
decision whether to include this field.
- The 'DVCSCertInfo.certs' field 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 vsd
service each element contains the result of the validation of one
signature of the signed document to be validated.
In case of a global status of waiting, the DVCS MAY choose to
return an invidual status of waiting in some of the 'certs' field,
or not to return such a TargetEtcChain at all.
The 'acceptablePolicySet' sequence indicate the policies and
mappings that were processed during X.509 public key certificate
Adams, Sylvester, Zolotarev, Zuccherato [Page 18]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
path validation. PolicyMappingsSyntax is defined in [RFC2459].
- The 'extensions' field MAY be used to return additional information
to the client. Extensions MAY be marked critical or not in order to
indicate whether the client is supposed to understand them. This
document does not define extensions.
9.2. DVCS Error Notification
A DVCS Error Notification is a CMS signedData object containing a
DVCSResponse with a 'dvErrorNote' choice.
DVCSErrorNotice ::= SEQUENCE {
transactionStatus PKIStatusInfo ,
transactionIdentifier GeneralName OPTIONAL }
The PKIStatusInfo is defined in the [RFC2511]. For the purposes of
communicating the DVCSErrorNotice, the following subset of
PKIFailureInfo values is used:
PKIFailureInfo ::= BITSTRING {
badRequest (2),
-- transaction not permitted or supported
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 request is different from the
-- one creating the response token
incorrectData (7)
--the requester's data (i.e. signature) is incorrect
)
In the DVCSErrorNotice, the PKIStatus field of the PKIStatusInfo must
be set to REJECTED.
The 'statusString' field of PKIStatusInfo can be used to accommodate
extra text, such as a reason for the failure, for example "I have
gone out of service". The DVCS initialises the
'DVCSErrorNotice.transactionIdentifier' with a copy of the
'DVCSRequest.transactionIdentifier' field of the corresponding
request.
In certain circumstances, a DVCS may not be able to produce a valid
Adams, Sylvester, Zolotarev, Zuccherato [Page 19]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
response to a request (for example, if it is unable to compute
signatures for a period of time). In these situations the DVCS MAY
create a response with an DVCSErrorNotice but no signature.
DVCS clients SHOULD NOT trust unsigned responses. A DVCS client MAY
trust unsigned responses, if the communication channel provides for
server authentication (e.g. by services defined by TLS [RFC2246]).
10. Transports
There is no mandatory transport mechanism in this document. All
mechanisms are optional.
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
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 or HTTPS
processing engines over WWW links and provides a simple client-server
transport for DVCS messages.
10.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 DVCS requests and responses are encapsulated using a
simple MIME object with Content-Type 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
Validation and Certification Server messages.
In order to be able to associate a possible error response to a
request, the requester SHOULD use the field 'transactionIdentifier'.
The requester SHOULD not make any assumption about the usage of
message header fields by the responding service, in particular the
usage of fields like Subject, Message-ID, References.
Adams, Sylvester, Zolotarev, Zuccherato [Page 20]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
11. Security Considerations
This entire 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 validation certificate.
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 DVC generated by
the DVCS SHOULD be kept as a means to help discriminate between
genuine and false DVCs.
When confidentiality and server authentication is required, requests
and responses MAY be protected using appropriate mechanisms (e.g. CMS
encapsulation [RFC 2630] or TLS [RFC2246]).
Server authentication is highly recommended for the vsd and cpd
service.
Client identification and authentication MAY use services defined by
TLS [RFC2246]) instead of or in addition to using a signed request if
either the client identity is not confidential information, or
protected by lower layer means.
12. Patent Information
The following United States Patents related to data validation and
certification services, listed in chronological order, are known by
the authors to exist at this time. This may not be an exhaustive
list. Other patents may exist or be issued at any time. Implementers
of the 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
Adams, Sylvester, Zolotarev, Zuccherato [Page 21]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
(issued) June 4, 1991
(inventors) Robert T. Durst, Kevin D. Hunter
# 5,136,643 Public/Key Date-Time Notary Facility
(issued) August 4, 1992
(inventor) Addison M. Fischer
(Note: This is a continuation of patent # 5,001,752.)
# 5,136,646 Digital Document Time-Stamping with Catenate Certificate
(issued) August 4, 1992
(inventors) Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Bell Communications Research, Inc.,
# 5,136,647 Method for Secure Time-Stamping of Digital Documents
(issued) August 4, 1992
(inventors) Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Bell Communications Research, Inc.,
# 5,373,561 Method of Extending the Validity of a Cryptographic
Certificate
(issued) December 13, 1994
(inventors) Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Bell Communications Research, Inc.,
# 5,422,95 Personal Date/Time Notary Device
(issued) June 6, 1995
(inventor) Addison M. Fischer
# 5,781,629 Digital Document Authentication System
(issued) July 14, 1998
(inventor) Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Surety Technologies, Inc.,
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-06.txt, 2000 (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.
Adams, Sylvester, Zolotarev, Zuccherato [Page 22]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
January 1999.
[RFC2630] R. Housley, "Cryptographic Message Syntax", 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.
[RFC2246] T. Dierks, C. Allen, "The TLS Protocol, Version 1.0," RFC
2246, January 1999.
[RFC2634] P. Hoffman, "Enhanced Security Services for S/MIME", RFC
2634, June 1999
[RFC2560] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams,
"X.509 Internet Public Key Infrastructure Online Certificate Status
Protocol", 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
Michael Zolotarev
Baltimore Technologies Pty Limited,
5th Floor, 1 James Place,
North Sydney, NSW 2060.
AUSTRALIA
mzolotarev@baltimore.com
Adams, Sylvester, Zolotarev, Zuccherato [Page 23]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
Robert Zuccherato
Entrust Technologies
750 Heron Road
Ottawa, Ontario
K1V 1A7
CANADA
robert.zuccherato@entrust.com
APPENDIX A - PKCS #9 Attribute
We define a PKCS #9 [PKCS9] attribute type. The attribute type has
ASN.1 type SignedData and contains a data validation certificate.
The object identifier id-aa-dvcs-dvc identifies the data valication
certificate attribute type.
id-aa-dvcs-dvc OBJECT IDENTIFIER ::= { id-aa 29 }
using the following branches:
id-aa OBJECT IDENTIFIER ::= { id-smime 2 }
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
The attribute may be used as a authenticated or unauthenticated
attribute in CMS SignedData documents.
APPENDIX B - Signed document validation.
We present some examples of a possible use of DVCS in the context of
validation of signed documents.
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 DVC can be produced either by a DVCS that is trusted by the
signer, or by a DVCS that is trusted by an intended verifier of the
document.
The signer uses the obtained DVC as 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 document that can be used to extend the
Adams, Sylvester, Zolotarev, Zuccherato [Page 24]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
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 finite lifetime. Therefore,
signatures have a finite 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 can be used:
1) The signature needs to be certified:
The signed message is presented to the Data Validation and
Certification Server in a 'vsd' service request.
The DVCS verifies that the signature and certificates are valid at
that time by checking expiry dates, status information, or DVCs,
and returns a DVC.
2) The DVC SHOULD be verified.
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.
A signer's signing key (and therefore, its signature) is only valid
until some specified time T1. The DVCS's signing key (and therefore,
its signature) is valid until some 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 DVCS is valid, the trust we have in the DVCS
allows us to conclude that the original signature on the data was
valid at the time included in the DVC.
The 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. Since data validation certificates are just
another type of signed documents, they can be validated using
(another) DVCS.
APPENDIX C - Verifying the Status of a Public Key Certificate
We now present three examples of how to produce a data validation
certificate that can be used to assert that a public key certificate
Adams, Sylvester, Zolotarev, Zuccherato [Page 25]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
is valid, trusted, and can be used for a particular purpose.
A client wants to use a given public key certificate either to use it
to sign a document or to use it for document encryption.
A DVCS MUST have access to current information regarding public
certificate status, it can therefore be used to verify the revocation
status of a certificate at the current time.
The following technique can be used:
A) The public key certificate needs to be validated.
The certificate is presented to the Data Certification Server
using a 'vpkc' service.
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 validation certificate.
B) The data validation certificate MUST be verified.
The signature of the Data Certification Server in the data
certification token SHALL be verified using the Data Validation
and Certification Server's valid certificate.
C) The public key certificate is used:
C.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 validation certificate can be
added as signed attributes to the signature.
A data validation certificate can now be used during the
validation signatures using the key contained in the public key
certificate. This service provided by the DVCS can be thought of
as a supplement to the usual method of checking revocation
status.
In other words, signature validation at a later time does not
necessarily require access to the revocation status of the
user's signing certificate, access to a DVCS service and
validation of the DVC is sufficient to verify a signature. Note
that the DVC does not tell when the signature had been created,
it only indicates when the signing certificate was valid.
C.2) A public key certificate for key exchange can be used after
Adams, Sylvester, Zolotarev, Zuccherato [Page 26]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
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.
C.3) The procedure described in the previous paragraph can be
enhanced to provide domain encryption in several ways.
Organisations require that encrypted documents need to be
recoverable. One simple way is to always encryt documents with
additional recipients that acts as 'domain encryption centers'
or 'recovery centers'. This is technically not a difficult
problem, but may require complicated and difficult interactions
with the end user, in particular when the document's recipients
are in several different organisations.
One possible solution consists of adding additional certificates
to the dvc that validates the usage of a particular public key
certificate used for encryption. In an environment of several
organisation, one of the possible procedures may be:
The client asks its local dvcs to validate the public key
certificate. The dvcs forwards the request to a dvcs of a
remote organisation. The remotes organisation's dvcs verifies
the certificate and provides a dvc assertion validating the
certificate. It adds additional certificates usable for key
exchange to the certEtcChain structure indication additional
required recipients. The local dvc creates a dvc containing the
dvc of the remote dvcs. It may add additional certificates or
references to the dvc. The clients uses all validated
certificates to be usable for key exchange to enhance its list
of recipients.
In the local dvcs may as well use local information about the
remote organisation's need for additional recipients.
Appendix D - MIME Registration
To: ietf-types@iana.org Subject: Registration of MIME media type
application/timestamp
MIME media type name: application
Adams, Sylvester, Zolotarev, Zuccherato [Page 27]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
MIME subtype name: 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 Servers and Clients
Additional information:
Magic number(s): None
File extension(s): .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 - ASN.1 Module using 1988 Syntax
PKIXDVCS {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-dvcs(15)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
Extensions, AlgorithmIdentifier
Adams, Sylvester, Zolotarev, Zuccherato [Page 28]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(1)}
GeneralName, PolicyInformation
FROM PKIX1Implicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit-88(2)}
PKIStatusInfo, PKIStatusField FROM PKIXCMP {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-cmp(9)}
ContentInfo FROM CryptographicMessageSyntax {iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms(1)}
ESSCertID FROM ExtendedSecurityServices
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
CertId, OCSPResponse, CertStatus
FROM OCSP
{iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-ocsp(14)}
SMIMECapabilities FROM SecureMimeMessageV3
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) smime(4) }
;
-- Authority Information Access for DVCS
id-ad-dvcs OBJECT IDENTIFIER ::= {id-ad 4}
-- Key Purpose for DVCS
id-kp-dvcs OBJECT IDENTIFIER ::= {id-kp 10}
-- eContentType for a dvcs requests and responses
id-ct-DVCSRequestData OBJECT IDENTIFIER ::= { id-ct 7 }
id-ct-DVCSResponseData OBJECT IDENTIFIER ::= { id-ct 8 }
-- Data validation certificate attribute
Adams, Sylvester, Zolotarev, Zuccherato [Page 29]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
id-aa-dvcs-dvc OBJECT IDENTIFIER ::= { id-aa 29 }
-- using the following bases :
id-pkix OBJECT IDENTIFIER ::= {iso(1)
identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)}
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }
id-kp OBJECT IDENTIFIER ::= {id-pkix 3 }
id-ad OBJECT IDENTIFIER ::= {id-pkix 48}
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-aa OBJECT IDENTIFIER ::= { id-smime 2 }
Version ::= Integer
DigestInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
digest Digest
}
Digest ::= OCTET STRING
Nonce ::= Integer
DVCSTime ::= CHOICE {
genTime GeneralizedTime,
timeStampToken ContentInfo
}
TargetEtcChain ::= SEQUENCE {
target CertEtcToken,
chain SEQUENCE SIZE (1..MAX) OF
CertEtcToken OPTIONAL,
pathProcInput [0] PathProcInput OPTIONAL
}
PathProcInput ::= SEQUENCE {
acceptablePolicySet SEQUENCE SIZE (1..MAX) OF
PolicyInformation,
inhibitPolicyMapping BOOLEAN DEFAULT FALSE,
explicitPolicyReqd BOOLEAN DEFAULT FALSE
}
CertEtcToken ::= CHOICE {
certificate [0] IMPLICIT Certificate ,
Adams, Sylvester, Zolotarev, Zuccherato [Page 30]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
esscertid [1] ESSCertId ,
pkistatus [2] IMPLICIT PKIStatusInfo ,
assertion [3] ContentInfo ,
crl [4] IMPLICIT CertificateList,
ocspcertstatus [5] IMPLICIT CertStatus,
oscpcertid [6] IMPLICIT CertId ,
oscpresponse [7] IMPLICIT OCSPResponse,
capabilities [8] SMIMECapabilities,
extension Extension
}
DVCSRequestInformation ::= SEQUENCE {
version INTEGER DEFAULT 1 ,
service ServiceType,
nonce Nonce OPTIONAL,
requestTime DVCSTime OPTIONAL,
requester [0] GeneralNames OPTIONAL,
requestPolicy [1] PolicyInformation OPTIONAL,
dvcs [2] GeneralNames OPTIONAL,
dataLocations [3] GeneralNames OPTIONAL,
extensions [4] IMPLICIT Extensions OPTIONAL
}
ServiceType ::= ENUMERATED { cpd(1), vsd(2), cpkc(3), ccpd(4) }
DVCSRequest ::= SEQUENCE {
requestInformation DVCSRequestInformation,
data Data,
transactionIdentifier GeneralName OPTIONAL
}
Data ::= CHOICE {
message OCTET STRING ,
messageImprint DigestInfo,
certs SEQUENCE SIZE (1..MAX) OF
TargetEtcChain
}
DVCSResponse ::= CHOICE
{
dvCertInfo DVCSCertInfo ,
dvErrorNote [0] DVCSErrorNotice
}
DVCSCertInfo::= SEQUENCE {
version Integer DEFAULT 1 ,
dvReqInfo DVCSRequestInformation,
messageImprint DigestInfo,
Adams, Sylvester, Zolotarev, Zuccherato [Page 31]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
serialNumber Integer,
responseTime DVCSTime,
nonce Nonce OPTIONAL,
dvStatus [0] PKIStatusInfo OPTIONAL,
policy [1] PolicyInformation OPTIONAL,
reqSignature [2] SignerInfos OPTIONAL,
certs [3] SEQUENCE SIZE (1..MAX) OF
TargetEtcChain OPTIONAL,
extensions Extensions OPTIONAL
}
DVCSErrorNotice ::= SEQUENCE {
transactionStatus PKIStatusInfo ,
transactionIdentifier GeneralName OPTIONAL
}
END
Appendix F - Examples
This chapter contains an example of a request and a response of a
'Certify Claim of Possession of Data' transaction of the Clepsydre
Demonstration Project.
The information has been formatted with Peter Gutmann's dumpasn1
program.
The response Data Validation Certificate contains the signing
certificate.
The data that are time stamped is the binary of the client program
used to make the request.
Request:
0 30 NDEF: SEQUENCE {
2 06 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
13 A0 NDEF: [0] {
15 30 565: SEQUENCE {
19 02 1: INTEGER 3
22 31 11: SET {
24 30 9: SEQUENCE {
26 06 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
33 05 0: NULL
: }
: }
35 30 NDEF: SEQUENCE {
37 06 11: OBJECT IDENTIFIER
Adams, Sylvester, Zolotarev, Zuccherato [Page 32]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
: id-ct-DVCSRequestData (1 2 840 113549 1 9 16 1 7)
50 A0 NDEF: [0] {
52 04 134: OCTET STRING, encapsulates {
55 30 131: SEQUENCE {
58 30 96: SEQUENCE {
60 0A 1: ENUMERATED CCPD (4)
63 A0 77: [0] {
65 A4 75: [4] {
67 30 73: SEQUENCE {
69 31 11: SET {
71 30 9: SEQUENCE {
73 06 3: OBJECT IDENTIFIER
: countryName (2 5 4 6)
78 13 2: PrintableString 'FR'
: }
: }
82 31 14: SET {
84 30 12: SEQUENCE {
86 06 3: OBJECT IDENTIFIER
: localityName (2 5 4 7)
91 13 5: PrintableString 'Paris'
: }
: }
98 31 16: SET {
100 30 14: SEQUENCE {
102 06 3: OBJECT IDENTIFIER
: organizationName (2 5 4 10)
107 13 7: PrintableString 'EdelWeb'
: }
: }
116 31 24: SET {
118 30 22: SEQUENCE {
120 06 3: OBJECT IDENTIFIER
: commonName (2 5 4 3)
125 13 15: PrintableString 'Peter Sylvester'
: }
: }
: }
: }
: }
142 A1 12: [1] {
144 06 10: OBJECT IDENTIFIER '1 3 6 1 4 1 5309 1 2 1'
: }
: }
156 30 31: SEQUENCE {
158 30 7: SEQUENCE {
160 06 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
: }
Adams, Sylvester, Zolotarev, Zuccherato [Page 33]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
167 04 20: OCTET STRING
: 75 B6 85 AF 6F 89 46 7D E8 07 15 25 1E 45 97 8F
: CD 1F A5 66
: }
: }
: }
: }
: }
193 31 387: SET {
197 30 383: SEQUENCE {
201 02 1: INTEGER 1
204 30 124: SEQUENCE {
206 30 112: SEQUENCE {
208 31 11: SET {
210 30 9: SEQUENCE {
212 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
217 13 2: PrintableString 'FR'
: }
: }
221 31 21: SET {
223 30 19: SEQUENCE {
225 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
230 13 12: PrintableString 'EdelWeb S.A.'
: }
: }
244 31 40: SET {
246 30 38: SEQUENCE {
248 06 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
253 13 31: PrintableString 'Clepsydre Demonstration Service'
: }
: }
286 31 32: SET {
288 30 30: SEQUENCE {
290 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
295 13 23: PrintableString 'Time Stamping Authority'
: }
: }
: }
320 02 8: INTEGER
: 00 94 88 17 21 34 37 76
: }
330 30 9: SEQUENCE {
332 06 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
339 05 0: NULL
: }
341 A0 95: [0] {
343 30 26: SEQUENCE {
Adams, Sylvester, Zolotarev, Zuccherato [Page 34]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
345 06 9: OBJECT IDENTIFIER
: contentType (1 2 840 113549 1 9 3)
356 31 13: SET {
358 06 11: OBJECT IDENTIFIER
: id-ct-dvcsrequest (1 2 840 113549 1 9 16 1 7)
: }
: }
371 30 28: SEQUENCE {
373 06 9: OBJECT IDENTIFIER
: signingTime (1 2 840 113549 1 9 5)
384 31 15: SET {
386 17 13: UTCTime '000417171457Z'
: }
: }
401 30 35: SEQUENCE {
403 06 9: OBJECT IDENTIFIER
: messageDigest (1 2 840 113549 1 9 4)
414 31 22: SET {
416 04 20: OCTET STRING
: 4D A8 C2 D2 CE 7C 0D 04 41 2F 44 13 33 75 DB 2F
: 5B 2D F9 DC
: }
: }
: }
438 30 13: SEQUENCE {
440 06 9: OBJECT IDENTIFIER
: rsaEncryption (1 2 840 113549 1 1 1)
451 05 0: NULL
: }
453 04 128: OCTET STRING
: 6E 7B 0E 36 F5 08 5F 16 3C 31 7B 28 BB 0B C2 C6
: 17 67 A6 B5 54 F1 98 E2 6F 89 96 0E 0C 99 E6 CB
: 40 C1 9B 8D D8 D7 8E D3 2B 41 F7 16 26 5B B7 08
: BF E6 95 B2 D9 01 6C FE B1 2C 52 C1 5A D2 31 F3
: 8E CA DD 11 A1 72 05 29 41 6A DD 28 40 AA 5C 77
: C6 9D 1D 80 53 DB 6F 9C 4C A5 A3 8F 92 8B 18 3F
: D5 3A AD 01 87 69 C3 FD D3 D8 C3 D0 CA 6B E6 0D
: 4E 53 6E 50 20 99 7C 94 C2 44 25 1B 06 C0 99 96
: }
: }
: }
: }
: }
The corresponding data in PEM format are:
-----BEGIN PKCS7-----
MIAGCSqGSIb3DQEHAqCAMIICNQIBAzELMAkGBSsOAwIaBQAwgAYLKoZIhvcNAQkQ
Adams, Sylvester, Zolotarev, Zuccherato [Page 35]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
AQeggASBhjCBgzBgCgEEoE2kSzBJMQswCQYDVQQGEwJGUjEOMAwGA1UEBxMFUGFy
aXMxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAMTD1BldGVyIFN5bHZlc3RlcqEM
BgorBgEEAak9AQIBMB8wBwYFKw4DAhoEFHW2ha9viUZ96AcVJR5Fl4/NH6VmAAAA
ADGCAYMwggF/AgEBMHwwcDELMAkGA1UEBhMCRlIxFTATBgNVBAoTDEVkZWxXZWIg
Uy5BLjEoMCYGA1UECxMfQ2xlcHN5ZHJlIERlbW9uc3RyYXRpb24gU2VydmljZTEg
MB4GA1UEAxMXVGltZSBTdGFtcGluZyBBdXRob3JpdHkCCACUiBchNDd2MAkGBSsO
AwIaBQCgXzAaBgkqhkiG9w0BCQMxDQYLKoZIhvcNAQkQAQcwHAYJKoZIhvcNAQkF
MQ8XDTAwMDQxNzE3MTQ1N1owIwYJKoZIhvcNAQkEMRYEFE2owtLOfA0EQS9EEzN1
2y9bLfncMA0GCSqGSIb3DQEBAQUABIGAbnsONvUIXxY8MXsouwvCxhdnprVU8Zji
b4mWDgyZ5stAwZuN2NeO0ytB9xYmW7cIv+aVstkBbP6xLFLBWtIx847K3RGhcgUp
QWrdKECqXHfGnR2AU9tvnEylo4+Sixg/1TqtAYdpw/3T2MPQymvmDU5TblAgmXyU
wkQlGwbAmZYAAAAA
-----END PKCS7-----
Response:
0 30 NDEF: SEQUENCE {
2 06 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
13 A0 NDEF: [0] {
15 30 2020: SEQUENCE {
19 02 1: INTEGER 3
22 31 11: SET {
24 30 9: SEQUENCE {
26 06 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
33 05 0: NULL
: }
: }
35 30 NDEF: SEQUENCE {
37 06 11: OBJECT IDENTIFIER
: id-ct-DVCSResponseData (1 2 840 113549 1 9 16 1 8)
50 A0 NDEF: [0] {
52 04 280: OCTET STRING, encapsulates {
56 30 276: SEQUENCE {
60 30 214: SEQUENCE {
63 0A 1: ENUMERATED CCPD (4)
66 A0 77: [0] {
68 A4 75: [4] {
70 30 73: SEQUENCE {
72 31 11: SET {
74 30 9: SEQUENCE {
76 06 3: OBJECT IDENTIFIER
: countryName (2 5 4 6)
81 13 2: PrintableString 'FR'
: }
: }
85 31 14: SET {
87 30 12: SEQUENCE {
Adams, Sylvester, Zolotarev, Zuccherato [Page 36]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
89 06 3: OBJECT IDENTIFIER
: localityName (2 5 4 7)
94 13 5: PrintableString 'Paris'
: }
: }
101 31 16: SET {
103 30 14: SEQUENCE {
105 06 3: OBJECT IDENTIFIER
: organizationName (2 5 4 10)
110 13 7: PrintableString 'EdelWeb'
: }
: }
119 31 24: SET {
121 30 22: SEQUENCE {
123 06 3: OBJECT IDENTIFIER
: commonName (2 5 4 3)
128 13 15: PrintableString 'Peter Sylvester'
: }
: }
: }
: }
: }
145 A1 12: [1] {
147 06 10: OBJECT IDENTIFIER '1 3 6 1 4 1 5309 1 2 1'
: }
159 A2 116: [2] {
161 A4 114: [4] {
163 30 112: SEQUENCE {
165 31 11: SET {
167 30 9: SEQUENCE {
169 06 3: OBJECT IDENTIFIER
: countryName (2 5 4 6)
174 13 2: PrintableString 'FR'
: }
: }
178 31 21: SET {
180 30 19: SEQUENCE {
182 06 3: OBJECT IDENTIFIER
: organizationName (2 5 4 10)
187 13 12: PrintableString 'EdelWeb S.A.'
: }
: }
201 31 40: SET {
203 30 38: SEQUENCE {
205 06 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
210 13 31: PrintableString 'Clepsydre Demonstration Service'
: }
Adams, Sylvester, Zolotarev, Zuccherato [Page 37]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
: }
243 31 32: SET {
245 30 30: SEQUENCE {
247 06 3: OBJECT IDENTIFIER
: commonName (2 5 4 3)
252 13 23: PrintableString 'Time Stamping Authority'
: }
: }
: }
: }
: }
: }
277 30 31: SEQUENCE {
279 30 7: SEQUENCE {
281 06 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
: }
288 04 20: OCTET STRING
: 75 B6 85 AF 6F 89 46 7D E8 07 15 25 1E 45 97 8F
: CD 1F A5 66
: }
310 02 7: INTEGER
: 01 78 0A 1E CA 88 23
319 18 15: GeneralizedTime '20000417171617Z'
: }
: }
: }
: }
340 A0 992: [0] {
344 30 988: SEQUENCE {
348 30 708: SEQUENCE {
352 A0 3: [0] {
354 02 1: INTEGER 2
: }
357 02 8: INTEGER
: 00 94 88 17 17 64 37 32
367 30 13: SEQUENCE {
369 06 9: OBJECT IDENTIFIER
: md5withRSAEncryption (1 2 840 113549 1 1 4)
380 05 0: NULL
: }
382 30 112: SEQUENCE {
384 31 11: SET {
386 30 9: SEQUENCE {
388 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
393 13 2: PrintableString 'FR'
: }
: }
397 31 21: SET {
Adams, Sylvester, Zolotarev, Zuccherato [Page 38]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
399 30 19: SEQUENCE {
401 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
406 13 12: PrintableString 'EdelWeb S.A.'
: }
: }
420 31 40: SET {
422 30 38: SEQUENCE {
424 06 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
429 13 31: PrintableString 'Clepsydre Demonstration Service'
: }
: }
462 31 32: SET {
464 30 30: SEQUENCE {
466 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
471 13 23: PrintableString 'Time Stamping Authority'
: }
: }
: }
496 30 30: SEQUENCE {
498 17 13: UTCTime '000125161938Z'
513 17 13: UTCTime '200120161938Z'
: }
528 30 112: SEQUENCE {
530 31 11: SET {
532 30 9: SEQUENCE {
534 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
539 13 2: PrintableString 'FR'
: }
: }
543 31 21: SET {
545 30 19: SEQUENCE {
547 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
552 13 12: PrintableString 'EdelWeb S.A.'
: }
: }
566 31 40: SET {
568 30 38: SEQUENCE {
570 06 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
575 13 31: PrintableString 'Clepsydre Demonstration Service'
: }
: }
608 31 32: SET {
610 30 30: SEQUENCE {
612 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
617 13 23: PrintableString 'Time Stamping Authority'
: }
Adams, Sylvester, Zolotarev, Zuccherato [Page 39]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
: }
: }
642 30 290: SEQUENCE {
646 30 13: SEQUENCE {
648 06 9: OBJECT IDENTIFIER
: rsaEncryption (1 2 840 113549 1 1 1)
659 05 0: NULL
: }
661 03 271: BIT STRING 0 unused bits
: 30 82 01 0A 02 82 01 01 00 FA C3 17 AE EB B7 9D
: EB AB BD 05 7E 39 43 6D 04 45 58 74 05 A5 CC F3
: 6C 2F 8C 8E 77 7E C2 9F 12 11 5C 7D DB BE 23 28
: 9A 90 D2 AB C6 A2 BA BD A3 7E 99 A6 99 21 A5 D8
: 90 B9 CF A7 23 4E A0 56 A0 C1 0A 46 89 8E 3C 91
: 67 37 FD 9B AB 49 17 FC 4A A5 F2 E4 4C 6E E3 6A
: 1C 92 97 04 6F 7F 0C 5C FB 74 CB 95 7E 4C C3 58
: 12 E8 A9 D6 F0 DD 12 44 15 E7 8B 2E AF 51 C0 0C
: [ Another 142 bytes skipped ]
: }
936 A3 122: [3] {
938 30 120: SEQUENCE {
940 30 15: SEQUENCE {
942 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19)
947 04 8: OCTET STRING, encapsulates {
949 30 6: SEQUENCE {
951 01 1: BOOLEAN TRUE
954 02 1: INTEGER 0
: }
: }
: }
957 30 22: SEQUENCE {
959 06 3: OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
964 01 1: BOOLEAN TRUE
967 04 12: OCTET STRING, encapsulates {
969 30 10: SEQUENCE {
971 06 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 3 10'
: }
: }
: }
981 30 77: SEQUENCE {
983 06 8: OBJECT IDENTIFIER
: authorityInfoAccess (1 3 6 1 5 5 7 1 1)
993 01 1: BOOLEAN TRUE
996 04 62: OCTET STRING, encapsulates {
998 30 60: SEQUENCE {
1000 30 58: SEQUENCE {
1002 06 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 48 4'
1012 86 46: [6]
Adams, Sylvester, Zolotarev, Zuccherato [Page 40]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
: 'https://clepsydre.edelweb.fr/dvcs/service-ccpd'
: }
: }
: }
: }
: }
: }
: }
1060 30 13: SEQUENCE {
1062 06 9: OBJECT IDENTIFIER
: md5withRSAEncryption (1 2 840 113549 1 1 4)
1073 05 0: NULL
: }
1075 03 257: BIT STRING 0 unused bits
: 08 DA AF 5B 09 39 66 D3 BE 80 1D D7 72 B5 2C A3
: 04 FB 46 F8 05 F5 BF 83 F3 6D 6D 32 28 1C 46 EE
: 0F EA 30 61 8A 1E 8A 03 4E 98 81 60 1F 97 17 53
: D1 54 73 3F 72 98 45 D3 10 9A D3 77 B8 74 0E 9A
: 90 29 8E AC A4 EB D2 24 6D F6 21 1D 3F 52 8B 2C
: E6 92 E7 52 C6 54 93 91 BC 57 74 21 38 39 75 CD
: 30 49 54 13 94 6C FE F1 64 38 1F 5F 7D BB E0 3E
: A8 F1 28 1C F1 D9 28 FA 32 1E 3B 48 BF 5C 70 21
: [ Another 128 bytes skipped ]
: }
: }
1336 31 699: SET {
1340 30 695: SEQUENCE {
1344 02 1: INTEGER 1
1347 30 124: SEQUENCE {
1349 30 112: SEQUENCE {
1351 31 11: SET {
1353 30 9: SEQUENCE {
1355 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
1360 13 2: PrintableString 'FR'
: }
: }
1364 31 21: SET {
1366 30 19: SEQUENCE {
1368 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
1373 13 12: PrintableString 'EdelWeb S.A.'
: }
: }
1387 31 40: SET {
1389 30 38: SEQUENCE {
1391 06 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
1396 13 31: PrintableString 'Clepsydre Demonstration Service'
: }
Adams, Sylvester, Zolotarev, Zuccherato [Page 41]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
: }
1429 31 32: SET {
1431 30 30: SEQUENCE {
1433 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
1438 13 23: PrintableString 'Time Stamping Authority'
: }
: }
: }
1463 02 8: INTEGER
: 00 94 88 25 72 35 27 50
: }
1473 30 9: SEQUENCE {
1475 06 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
1482 05 0: NULL
: }
1484 A0 276: [0] {
1488 30 26: SEQUENCE {
1490 06 9: OBJECT IDENTIFIER
: contentType (1 2 840 113549 1 9 3)
1501 31 13: SET {
1503 06 11: OBJECT IDENTIFIER
: id-ct-dvcsresponse (1 2 840 113549 1 9 16 1 8)
: }
: }
1516 30 28: SEQUENCE {
1518 06 9: OBJECT IDENTIFIER
: signingTime (1 2 840 113549 1 9 5)
1529 31 15: SET {
1531 17 13: UTCTime '000417171619Z'
: }
: }
1546 30 35: SEQUENCE {
1548 06 9: OBJECT IDENTIFIER
: messageDigest (1 2 840 113549 1 9 4)
1559 31 22: SET {
1561 04 20: OCTET STRING
: 68 50 DC 90 20 2E C2 F0 55 15 7F 77 A9 A6 0C 34
: CC 13 06 FA
: }
: }
1583 30 178: SEQUENCE {
1586 06 11: OBJECT IDENTIFIER
: id-aa-signingCertificate (1 2 840 113549 1 9 16 2 12)
1599 31 162: SET {
1602 30 159: SEQUENCE {
1605 30 156: SEQUENCE {
1608 30 153: SEQUENCE {
1611 04 20: OCTET STRING
Adams, Sylvester, Zolotarev, Zuccherato [Page 42]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
: 5C F1 18 F3 4A CA B4 67 D6 D8 E7 F8 3B 4A D9 7A
: 32 A5 43 A5
1633 30 128: SEQUENCE {
1636 30 116: SEQUENCE {
1638 A4 114: [4] {
1640 30 112: SEQUENCE {
1642 31 11: SET {
1644 30 9: SEQUENCE {
1646 06 3: OBJECT IDENTIFIER
: countryName (2 5 4 6)
1651 13 2: PrintableString 'FR'
: }
: }
1655 31 21: SET {
1657 30 19: SEQUENCE {
1659 06 3: OBJECT IDENTIFIER
: organizationName (2 5 4 10)
1664 13 12: PrintableString 'EdelWeb S.A.'
: }
: }
1678 31 40: SET {
1680 30 38: SEQUENCE {
1682 06 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
1687 13 31: PrintableString 'Clepsydre Demonstration Service'
: }
: }
1720 31 32: SET {
1722 30 30: SEQUENCE {
1724 06 3: OBJECT IDENTIFIER
: commonName (2 5 4 3)
1729 13 23: PrintableString 'Time Stamping Authority'
: }
: }
: }
: }
: }
1754 02 8: INTEGER
: 00 94 88 25 72 35 27 50
: }
: }
: }
: }
: }
: }
: }
1764 30 13: SEQUENCE {
1766 06 9: OBJECT IDENTIFIER
Adams, Sylvester, Zolotarev, Zuccherato [Page 43]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
: rsaEncryption (1 2 840 113549 1 1 1)
1777 05 0: NULL
: }
1779 04 256: OCTET STRING
: 2E 70 9F 56 5E 01 56 A9 E1 47 81 12 35 21 29 09
: 16 7A ED 45 F9 5A A2 ED E4 FE 9D 2C E4 DA 12 66
: 62 14 59 61 8B 50 7B 01 82 3D BD 7E E6 38 D0 A8
: A0 37 98 79 13 26 39 29 C6 72 20 A9 95 71 E7 53
: 7F 79 77 98 EF 23 02 4E B9 BD 90 9B AC 05 A2 70
: 8F 3A 42 36 9C 2C B0 94 B1 2B 0B 36 94 0E 78 0E
: B0 D1 09 20 63 BC FF CD 32 F1 5A D3 AB 9F 93 9C
: 5A A3 58 99 A0 28 11 E0 80 4D 4D 1E 77 04 F4 50
: [ Another 128 bytes skipped ]
: }
: }
: }
: }
: }
The corresponding data in PEM format (together with a technical
textual description) are:
Data Validation Certificate:
Request Information:
Service: Certify Claim of Possession of Data - ccpd(4)
Policy: EdelWeb Customer Policy Clepsydre
Requester:
DirName:/C=FR/L=Paris/O=EdelWeb/CN=Peter Sylvester
DVCS:
DirName:/C=FR/O=EdelWeb S.A./OU=Clepsydre Demonstration Service/CN=Time Stamping Authority
SerialNumber: 01780a1eca8823
MessageDigest:
Algorithm: sha1
Data : 75B685AF6F89467DE80715251E45978FCD1FA566
Asserted Time:
Generalized Time: 17-Apr-2000 19:16:17 (Apr 17 17:16:17 2000 GMT)
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
94:88:17:17:64:37:32
Signature Algorithm: md5WithRSAEncryption
Issuer: C=FR, O=EdelWeb S.A., OU=Clepsydre Demonstration Service, CN=Time Stamping Authority
Validity
Not Before: Jan 25 16:19:38 2000 GMT
Not After : Jan 20 16:19:38 2020 GMT
Subject: C=FR, O=EdelWeb S.A., OU=Clepsydre Demonstration Service, CN=Time Stamping Authority
Adams, Sylvester, Zolotarev, Zuccherato [Page 44]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:fa:c3:17:ae:eb:b7:9d:eb:ab:bd:05:7e:39:43:
6d:04:45:58:74:05:a5:cc:f3:6c:2f:8c:8e:77:7e:
c2:9f:12:11:5c:7d:db:be:23:28:9a:90:d2:ab:c6:
a2:ba:bd:a3:7e:99:a6:99:21:a5:d8:90:b9:cf:a7:
23:4e:a0:56:a0:c1:0a:46:89:8e:3c:91:67:37:fd:
9b:ab:49:17:fc:4a:a5:f2:e4:4c:6e:e3:6a:1c:92:
97:04:6f:7f:0c:5c:fb:74:cb:95:7e:4c:c3:58:12:
e8:a9:d6:f0:dd:12:44:15:e7:8b:2e:af:51:c0:0c:
5f:a8:65:fc:47:a1:c9:98:1f:d4:e1:ea:bc:1c:1a:
27:bb:8b:56:f1:12:55:10:f4:8e:d8:9f:19:9c:1e:
81:f7:db:63:dd:88:37:3f:71:79:5b:96:e2:5f:82:
d5:12:19:05:0d:e1:3d:a5:6d:66:e4:2c:1e:ed:c7:
4c:b8:df:aa:38:c8:15:6a:ae:25:7d:46:2a:07:f9:
83:77:c4:51:ee:90:dc:05:d0:c3:f0:f1:5f:e8:d4:
ed:5d:34:70:91:9d:9f:08:55:7d:5b:e5:8d:5f:35:
59:83:4e:72:19:bb:9c:88:d1:7a:fc:23:a5:84:99:
b4:17:8a:4d:6c:9d:d0:a6:35:80:5f:ca:fb:24:8b:
54:1d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:TRUE, pathlen:0
X509v3 Extended Key Usage: critical
DVCS Signing
Authority Information Access: critical
DVCS - URI:https://clepsydre.edelweb.fr/dvcs/service-ccpd
Signature Algorithm: md5WithRSAEncryption
08:da:af:5b:09:39:66:d3:be:80:1d:d7:72:b5:2c:a3:04:fb:
46:f8:05:f5:bf:83:f3:6d:6d:32:28:1c:46:ee:0f:ea:30:61:
8a:1e:8a:03:4e:98:81:60:1f:97:17:53:d1:54:73:3f:72:98:
45:d3:10:9a:d3:77:b8:74:0e:9a:90:29:8e:ac:a4:eb:d2:24:
6d:f6:21:1d:3f:52:8b:2c:e6:92:e7:52:c6:54:93:91:bc:57:
74:21:38:39:75:cd:30:49:54:13:94:6c:fe:f1:64:38:1f:5f:
7d:bb:e0:3e:a8:f1:28:1c:f1:d9:28:fa:32:1e:3b:48:bf:5c:
70:21:29:ef:be:72:24:da:0d:f9:51:7a:fe:d7:f5:ff:e8:c2:
ea:c6:4c:45:14:51:53:fd:00:d5:5b:cc:67:2a:23:94:31:9e:
c2:90:38:9b:b0:df:f9:de:67:0c:57:5c:d7:b0:fc:f2:72:96:
c4:d1:7a:9d:a0:e6:51:24:99:9e:89:c6:39:f9:72:7a:44:fd:
2d:3f:bc:df:c7:25:27:94:a1:b5:7d:ba:06:75:67:1c:95:6c:
bd:2c:74:41:3e:cd:cd:39:5c:2e:9c:c3:c3:09:e3:79:d5:eb:
85:e8:f1:72:29:80:f6:c6:6e:61:1b:58:fc:87:3e:d9:e1:53:
10:e0:b1:05
Adams, Sylvester, Zolotarev, Zuccherato [Page 45]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
-----BEGIN PKCS7-----
MIAGCSqGSIb3DQEHAqCAMIIH5AIBAzELMAkGBSsOAwIaBQAwgAYLKoZIhvcNAQkQ
AQiggASCARgwggEUMIHWCgEEoE2kSzBJMQswCQYDVQQGEwJGUjEOMAwGA1UEBxMF
UGFyaXMxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAMTD1BldGVyIFN5bHZlc3Rl
cqEMBgorBgEEAak9AQIBonSkcjBwMQswCQYDVQQGEwJGUjEVMBMGA1UEChMMRWRl
bFdlYiBTLkEuMSgwJgYDVQQLEx9DbGVwc3lkcmUgRGVtb25zdHJhdGlvbiBTZXJ2
aWNlMSAwHgYDVQQDExdUaW1lIFN0YW1waW5nIEF1dGhvcml0eTAfMAcGBSsOAwIa
BBR1toWvb4lGfegHFSUeRZePzR+lZgIHAXgKHsqIIxgPMjAwMDA0MTcxNzE2MTda
AAAAAKCCA+AwggPcMIICxKADAgECAggAlIgXF2Q3MjANBgkqhkiG9w0BAQQFADBw
MQswCQYDVQQGEwJGUjEVMBMGA1UEChMMRWRlbFdlYiBTLkEuMSgwJgYDVQQLEx9D
bGVwc3lkcmUgRGVtb25zdHJhdGlvbiBTZXJ2aWNlMSAwHgYDVQQDExdUaW1lIFN0
YW1waW5nIEF1dGhvcml0eTAeFw0wMDAxMjUxNjE5MzhaFw0yMDAxMjAxNjE5Mzha
MHAxCzAJBgNVBAYTAkZSMRUwEwYDVQQKEwxFZGVsV2ViIFMuQS4xKDAmBgNVBAsT
H0NsZXBzeWRyZSBEZW1vbnN0cmF0aW9uIFNlcnZpY2UxIDAeBgNVBAMTF1RpbWUg
U3RhbXBpbmcgQXV0aG9yaXR5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEA+sMXruu3neurvQV+OUNtBEVYdAWlzPNsL4yOd37CnxIRXH3bviMompDSq8ai
ur2jfpmmmSGl2JC5z6cjTqBWoMEKRomOPJFnN/2bq0kX/Eql8uRMbuNqHJKXBG9/
DFz7dMuVfkzDWBLoqdbw3RJEFeeLLq9RwAxfqGX8R6HJmB/U4eq8HBonu4tW8RJV
EPSO2J8ZnB6B99tj3Yg3P3F5W5biX4LVEhkFDeE9pW1m5Cwe7cdMuN+qOMgVaq4l
fUYqB/mDd8RR7pDcBdDD8PFf6NTtXTRwkZ2fCFV9W+WNXzVZg05yGbuciNF6/COl
hJm0F4pNbJ3QpjWAX8r7JItUHQIDAQABo3oweDAPBgNVHRMECDAGAQH/AgEAMBYG
A1UdJQEB/wQMMAoGCCsGAQUFBwMKME0GCCsGAQUFBwEBAQH/BD4wPDA6BggrBgEF
BQcwBIYuaHR0cHM6Ly9jbGVwc3lkcmUuZWRlbHdlYi5mci9kdmNzL3NlcnZpY2Ut
Y2NwZDANBgkqhkiG9w0BAQQFAAOCAQEACNqvWwk5ZtO+gB3XcrUsowT7RvgF9b+D
821tMigcRu4P6jBhih6KA06YgWAflxdT0VRzP3KYRdMQmtN3uHQOmpApjqyk69Ik
bfYhHT9SiyzmkudSxlSTkbxXdCE4OXXNMElUE5Rs/vFkOB9ffbvgPqjxKBzx2Sj6
Mh47SL9ccCEp775yJNoN+VF6/tf1/+jC6sZMRRRRU/0A1VvMZyojlDGewpA4m7Df
+d5nDFdc17D88nKWxNF6naDmUSSZnonGOflyekT9LT+838clJ5ShtX26BnVnHJVs
vSx0QT7NzTlcLpzDwwnjedXrhejxcimA9sZuYRtY/Ic+2eFTEOCxBTGCArswggK3
AgEBMHwwcDELMAkGA1UEBhMCRlIxFTATBgNVBAoTDEVkZWxXZWIgUy5BLjEoMCYG
A1UECxMfQ2xlcHN5ZHJlIERlbW9uc3RyYXRpb24gU2VydmljZTEgMB4GA1UEAxMX
VGltZSBTdGFtcGluZyBBdXRob3JpdHkCCACUiCVyNSdQMAkGBSsOAwIaBQCgggEU
MBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABCDAcBgkqhkiG9w0BCQUxDxcNMDAw
NDE3MTcxNjE5WjAjBgkqhkiG9w0BCQQxFgQUaFDckCAuwvBVFX93qaYMNMwTBvow
gbIGCyqGSIb3DQEJEAIMMYGiMIGfMIGcMIGZBBRc8RjzSsq0Z9bY5/g7Stl6MqVD
pTCBgDB0pHIwcDELMAkGA1UEBhMCRlIxFTATBgNVBAoTDEVkZWxXZWIgUy5BLjEo
MCYGA1UECxMfQ2xlcHN5ZHJlIERlbW9uc3RyYXRpb24gU2VydmljZTEgMB4GA1UE
AxMXVGltZSBTdGFtcGluZyBBdXRob3JpdHkCCACUiCVyNSdQMA0GCSqGSIb3DQEB
AQUABIIBAC5wn1ZeAVap4UeBEjUhKQkWeu1F+Vqi7eT+nSzk2hJmYhRZYYtQewGC
Pb1+5jjQqKA3mHkTJjkpxnIgqZVx51N/eXeY7yMCTrm9kJusBaJwjzpCNpwssJSx
Kws2lA54DrDRCSBjvP/NMvFa06ufk5xao1iZoCgR4IBNTR53BPRQB9WLVKAjMv+m
nOK6uNtVR8nIugfvkBRIqLbFfNWpIHQcVu+PG7P8h22B8dRvGocwkkdp4HngvBCZ
z002TDYDUXLRW6YeLYbxHwrov+s4+c4a7LCPUa4qO0aEv02Mn+4f78U1o2O+OMAD
fDpeuM87GBCI27tPePb75ByN1Pj761AAAAAA
-----END PKCS7-----
Adams, Sylvester, Zolotarev, Zuccherato [Page 46]
draft-ietf-pkix-dcs-05.txt DVCS Protocols July 14, 2000
Appendix G - Acknowledgements
This document is based on two initial works from Robert Zuccherato
and Carlisle Adams, both at Entrust Technologies, for time stamping
and for notary and data certification services.
Appendix G - 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.
This document expires expires January 14, 2001.
Adams, Sylvester, Zolotarev, Zuccherato [Page 47]
