Data Validation and Certification Server
Lua error in package.lua at line 80: module 'strict' not found. Data Validation and Certification Server (DVCS) is a public key infrastructure or PKI service providing data validation services, asserting correctness of digitally signed documents, validity of public key certificates and possession or existence of data.
In practical applications DVCS also helps solve problems with interoperability (numerous digital signature formats) and security of typical office environments as well as financial data and transactions.
Contents
Overview of DVCS
A Data Validation and Certification 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 or existence of data.
As a result of the validation, 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.
Services provided by a DVCS 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 the 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 by providing evidence that a digitally signed document or public key certificate was valid at the time indicated in the DVC.
A DVC validating a public key certificate can for example be used even after the public key certificate expires and its revocation information is no longer or not easily available. Determining the validity of a DVC is assumed to be a simpler task, for example, if the population of DVCS is significantly smaller than the population of public key certificate owners.
An important feature of the protocol is that DVCs can be validated by using the same protocol (not necessarily using the same service), and the validity of a signed document, in particular a DVC, can also be determined by means other than by verifying its signature(s), e.g. by comparing against an archive.
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.
Services provided by DVCS
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 MUST support at least a subset of these services. A DVCS may support a restricted vsd service allowing to validate data validation certificates. On completion of each service, the DVCS produces a data validation certificate - a signed document containing the validation results and trustworthy time information.
Certification of 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 were presented to the Data Validation Server.
Certification of Claim of Possession of Data
The Certification of 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.
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 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 validation, and vice versa, a global failure may occur if the document has an insufficient number of signatures.
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(CRL, OCSP, DVCS).
Functional Requirements for DVCS
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 to generate the response will be included in a data validation certificate, e.g. public key certificates, CRLs, and responses from other OCSP servers, DVCS, or others.
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 monotonically 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 attribute 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 user for DVCS's signature.
How it works
A DVCS transaction begins with a client preparing a Data Validation and Certification Request. The request always contains data for which validity, correctness or possession is to be certified. The request MAY be encapsulated using a security envelope to provide for authentication of both requester and server. Requester authentication can be achieved by several of the formats described in CMS(), in particular, signed Data.
The DVCS client chooses an appropriate transport mechanism to convey the requests to a DVCS. It may also be necessary to choose a transport mechanism providing confidentiality and, in particular, allowing authentication of the DVCS by the requestor, e.g., TLS or CMS or S/MIME encryption.
If the request is valid, the DVCS performs all necessary verification 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 Signed Data).
As with the request, it may be necessary to choose a transport mechanism that provides for confidentiality to carry the DVC. DVCs are not necessarily transported the same way as requests, e.g., they can be returned using e-mail after an online request received via HTTPS.
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., whether it contains an acceptable 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 the validity of a DVC, it is up to the requester's application to check whether a DVCS's signing certificate is valid. Depending on the usage environment, different methods, online or out of band, e.g., CRLs, DVCS, or OCSP, may have to be used.
After all checks have passed, the data validation certificate can be used to authenticate the correctness or possession of the corresponding data.
A DVCS may return more than one DVC corresponding to one request. In this case, all but one request have a global status of 'WAITING'.
Identification of the DVCS
In order to be able to import elements from dvcs the following object identifier is used as an ASN.1 module identifier.
id-mod-dvcs OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 15}
The DVCS that use SignedData to provide authentication for DVCs MUST sign all data certification messages with a key whose corresponding certificate MUST contain the extended key usage field 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 ::= {iso(1) identified-organization(3)dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) 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 ::= {iso(1) identified-organization(3)dod(6) internet(1) security(5) mechanisms(5) pkix(7) ad(48) 4}
The value of the 'accessLocation' field defines the transport (e.g. an URI) used to access the DVCS.
Data Validation and Certification Requests
Using a SignedData structure, a Data Validation and 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, or MAY use another encapsulation from RFC2630 that provides for authentication and/or confidentiality.
Data Validation and Certification Response
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 DVCS from executing the request.
Transports
There is no mandatory transport mechanism in this document. All mechanisms are optional. Two examples of transport protocols are given which allow online exchange of request and a response, and asynchronous communication between a client and a DVCS.
A DVCS MAY use a combination of protocols, for example in order to return additional DVCs.
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 with the default binary 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.
DVCS Protocol Using Email
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 DVCS messages.
In order to be able to associate a possible error response with 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 or References.
References
http://rfc-ref.org/RFC-TEXTS/3029/chapter1.html
