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.
Read more about this topic: Data Validation And Certification Server
Famous quotes containing the word functional:
“In short, the building becomes a theatrical demonstration of its functional ideal. In this romanticism, High-Tech architecture is, of course, no different in spirit—if totally different in form—from all the romantic architecture of the past.”
—Dan Cruickshank (b. 1949)