Internet Draft Adams, Sylvester, Zolotarev, Zuccherato
PKIX Working Group October 12, 1999 expires April 12, 2000
Internet X.509 Public Key Infrastructure
Data Validation and Certification Server Protocols
<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 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.
<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", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
as shown) are to be interpreted as described in [RFC2119].
<draft>A complete list of ASN.1 will be added in an appendix.</draft>
1. Introduction
A Data Validation Server (DVCS) is a Trusted Third Party (TTP)
providing data validation services, asserting correctness of
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).
Adams, Sylvester, Zolotarev, Zuccherato [Page 2]
draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999
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.
2.1 Certifying Possession of Data
The Certify 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 Certify Claim of Possession 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 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 DVS 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 Certifying Public Key Certificate
The Certify Public Key Certificate service is used to verify the
validity (according to [RFC2459]) of one or more public key
certificates at the specified time.
Adams, Sylvester, Zolotarev, Zuccherato [Page 3]
draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999
When certifying a public key certificate, the DVS 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
(CRL, OCSP, DVCS).
3. Data Certification Server usage and scenarios.
It is outside the scope of this document to completely describe
different operational scenarios, or usages for DVCS.
See Appendix B and C for a set of 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 Certify Claim of Possession of Data is equivalent to the services
described in [TSP].
The Certify 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
Adams, Sylvester, Zolotarev, Zuccherato [Page 4]
draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999
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
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
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 DVCS 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
The DVCS MUST sign all data certification messages with a key
reserved 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-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 ::= { <draft>tbd</draft> }
Consistent key usage bits: digitalSignature, nonRepudiation
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 ::= { <draft>tbd</draft> }
The value of the field 'accessLocation' field defines the transport
(e.g. an URL) 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 of
these types and lists their usages.
7.1 DigestInfo:
This element is defind in [RFC2315]. Since the status of that
document the definition is repeated here:
DigestInfo ::= SEQUENCE {
digestAlgorithm DigestAlgorithmIdentifier,
digest Digest
}
Digest ::= OCTET STRING
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 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 request is returned as is in the response, the
DVCS may create an addition nonce in the response.
7.3. Time Values
Indicators of time occur in requests and responses. In the most
simple form, and genrated localloy either by a requester or a DVCS,
they are represented as GeneralizedTime where fractions of seconds
are allowed.
An alternate form is a timeStampToken from a [TSA] or as a DVC, or as
token from another third party service. When using third party
tokens, it is a matter of policy whether a DVCS tries to interprete
or validate a 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 as component of
the 'chain' field of a TargetEtcChain structure, and as a global
status indicator in the DVCSResponse structure. Every occurence of
PKIStatusInfo is generated by the 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 request) information to be validated (in a
cpkc service) 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
Adams, Sylvester, Zolotarev, Zuccherato [Page 8]
draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999
defined later for each service.
the 'pathProcinput' field contains information about policies and
policy mapping to be used or used a validation.
If present, it contains the result of a local verification of the
immediately preceeding 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 [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 contain a data validation certificate, or a
timeStamp, or other assertions.
The choices 'datacert', 'ocspresponse' and 'crl' are provided by
services external to the responding DVCS. The choices 'certStatus'
Adams, Sylvester, Zolotarev, Zuccherato [Page 9]
draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999
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).
7.6. DVCSReqInfo
A DVCSReqInfo data structure contains general information about the
data validation and certification request. This structure occurs in a
request, and 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 DVCS service type of 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 several occurences of sequences of GeneralName. For
syntactical conveniance the following type is defined here:
GeneralNames ::= SEQUENCE OF GeneralName
GeneralName is 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-DVCSReqData signalling a DVCSReqData as eContent of
the encapContentInfo (carried as an octet string).
id-ct-DVCSReqData OBJECT IDENTIFIER ::= { <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. 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 {
reqInfo DVCSReqInfo,
data Data,
transactionIdentifier GeneralName OPTIONAL
}
The 'reqInfo' element contains general information about the request.
It is filled in by the requester as follows:
- The field 'service' contains the requested service.
- The value of the 'requester' field indicates the requesting entity.
If the field is present, and the request is signed, it MUST match
the identity (subjectName or subjectAltName extension) of the
corresponding signature certificate, unless the request is signed
by a DVCS (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 'reqPolicy' field SHOULD indicate the policy under which the
certification 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 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 'dataLocator' field MAY 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.
Adams, Sylvester, Zolotarev, Zuccherato [Page 11]
draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999
- 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 vsd and cpkc service,
it indicates to check whether the signed document or certicates
where valid at the given time. For the other service, the field is
ignored by the DVCS. If the field is absent, the current time of
the DVCS 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 Data type is defined as a placeholder for service-specific
content, defined by each particular service provided by the DVCS.
Depending on the requested service type, the field may contain
requester-specific data, a signed document, a list of certificates, a
message digest or arbitrary data.
Data ::= CHOICE {
message [0] OCTET STRING ,
messageImprint [1] DigestInfo,
certs [2] 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 provide any certificate that may be
needed to verify the signature(s) in the signedData object. The
requester MAY choose to remove all certificates from the signedData
(since they are not part of the signed part anyway, and transfer
them in the certificate list of the signedData structure containing
the DVCSRequest.
- 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 target field SHALL contain the
cert to be verified and the chain field, if present, MUST indicate
the chain of trust to be used when certifying the 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 Certificate, ESSCertId, CertId or Extension fields of the
TargetEtcChain can be used in the request.
The requester is responsible to provide 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 'message' contain 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 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 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 result of
processing of the data certification validation 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).
Adams, Sylvester, Zolotarev, Zuccherato [Page 13]
draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999
id-ct-DVCSResponseData OBJECT IDENTIFIER ::= { <draft>tbd</draft> }
The DVCS MUST use a key, specifically allocated for the purpose of
DVCS signing, with a proper extendedKeyUsage set in a corresponding
certificate.
In a critical situation when a DVCS can not produce a valid signature
(if the DVCS's signing key is known to be compromised, for example),
the DVCSResponse must be generated as a signedData with no signerInfo
attached. In this case, the response MUST only contain the error
notification. 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), containing 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
{
dvcErrorNote [0] DVErrorNote,
dvCertInfo [1] DVCertInfo
}
9.1. DVCS Error Notification
A 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 defined in the [RFC2511]. For the purposes of
communicating the DVErrorNote, the following subset PKIFailureInfo
for use in PKIStatusInfo is used:
PKIFailureInfo ::= BITSTRING {
badRequest (2),
-- transaction not permitted or supported
Adams, Sylvester, Zolotarev, Zuccherato [Page 14]
draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999
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 DVError, the PKIStatus field of the 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 DVCS
fills the 'transactionIdentifier' with a copy of 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 {
nonce INTEGER OPTIONAL,
dvReqInfo DVCSReqInfo,
messageImprint DigestInfo,
serialNumber Integer,
respTime DVCSTime,
dvStatus [0] PKIStatusInfo OPTIONAL,
policy [1] PolicyInformation OPTIONAL,
reqSignature [2] SignerInfos OPTIONAL,
certs [3] SEQUENCE OF TargetEtcChain
OPTIONAL,
extensions [4] Extensions OPTIONAL }
The DVCertInfo 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
DVCertInfo may contain both the 'valid' and 'invalid' results.
The DVCS fille a DVCertInfo as follows:
Adams, Sylvester, Zolotarev, Zuccherato [Page 15]
draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999
- 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 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 unique identifier of the
request.
- The field 'respTime' 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 field 'dvStatus' reflects a collective status of the
validation.
An omitted 'dvStatus' field implies SUCCESS, except in case of a
cpkc service, where each element of the 'certs' field have their
own independant status. If the 'dvStatus' is set for a cpkc service
response, this is equivalent to putting an identical one into each
element of 'certs' field as a last element in the 'chain' field.
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 the production of an error message. For
example, as long as a sufficient number of signature verifications
was successful, a DVC with status `grantedWithMods` is 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 FAILED, if
Adams, Sylvester, Zolotarev, Zuccherato [Page 16]
draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999
the data validation has failed to successfully verify all or some
of the data. The field MUST be present, and the status must be set
to WAITING, if there is no or only an incomplete response
immediately available.
In the situation when the data validation fails, the requestor can
further investigate the cause of the failure, by looking into the
TargetEtcChain fields. 'pkistatus' fields in the TargetEtcChain
will indicate which item(s) has failed the validation and for what
reason.
- The 'policy' field indicates the policy under which the DVCS
operates.
- If present, '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 '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.
The 'policyReturnInfo' fields indicate the policies and mappings
that were processed during X.509 public key certificate 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.
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
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 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.
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 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.
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.
1. The enclosed public key certificate is revoked or the signer's key
is compromised and the corresponding public key certificate is
revoked before the DVCS acts upon the request. The DVCS is
REQUIRED to validate appropriate information within the request
before it constructs the data certification token. It is therefore
mandated that the 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 DVCS acts upon the request. This is not a concern to the DVCS,
once the DVCS has constructed the 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, means specific to the situation at hand.
3. The DVCS's private key is compromised and the corresponding
certificate is revoked. In this case, any DVC signed by the 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 DVC generated by the DVCS SHOULD be kept as
a means to help discriminate between genuine and false DVCs.
4. 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. Thus, any DVCs signed by the 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 DVC's signature. Data 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 DVCS can no longer be
trusted, its certificate MUST be revoked. Thus, at any future time
the DVCs signed with the corresponding key will not be trusted.
6. In certain circumstances, a 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
DVCS MAY create a response that only contain a PKIStatusInfo.
7. 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]).
8. Client identification and authentication MAY use services defined
by TLS [RFC2246]) instead of using a signed request.
9. 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]).
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 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
(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.
[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
Adams, Sylvester, Zolotarev, Zuccherato [Page 21]
draft-ietf-pkix-dcs-02.txt DVCS Protocols October 12, 1999
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] attribute type. This attribute type MAY
be included as a signed attribute of the SignedData object. The
attribute type has ASN.1 type SignedData and contains a dvc (as
defined in this document).
The object identifier id-DVCS-dvc identifies the dcs token attribute
type.
id-DVCS-dvc OBJECT IDENTIFIER ::= { <draft>tbd</draft> }
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 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 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 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 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
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 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 dcsInfo field of the data
certification token.
APPENDIX C - Verifying the Status of a Public Key Certificate
We now present two examples of how to produce a data validation
certificate that can be used to assert that a public key certificate
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
in a signature or to use it 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 in at the current time.
The following technique 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 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 validation certificate.
B) The data 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.
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 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 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.
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: 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): .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.
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 26]
