Internet Draft Adams, Sylvester, Zolotarev, Zuccherato PKIX Working Group March 7, 2000 expires September 7, 2000 Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols 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-04.txt DVCS Protocols March 7, 2000 as shown) are to be interpreted as described in [RFC2119]. 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-DVCSReqData OBJECT IDENTIFIER ::= { id-ct 5 } id-ct-DVCSResponseData OBJECT IDENTIFIER ::= { id-ct 6 } -- Data validation certificate attribute id-aa-dvcs OBJECT IDENTIFIER ::= { id-aa 15 } -- 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-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 } 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. Adams, Sylvester, Zolotarev, Zuccherato [Page 2] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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. 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. Adams, Sylvester, Zolotarev, Zuccherato [Page 3] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 2.2 Certification of Claim of possession of Data The Certification 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 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 (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. Adams, Sylvester, Zolotarev, Zuccherato [Page 4] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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 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 Adams, Sylvester, Zolotarev, Zuccherato [Page 5] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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 receipt in the form of a data validation certificate to the requester, as defined by policy. 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 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. 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 for DVC's signature. The [TSA] defines additional requirements: If the DVCS protocol is used as a replacement for the services defined in [TSA], any additional requirement of [TSA] apply to that service. Adams, Sylvester, Zolotarev, Zuccherato [Page 6] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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 DVCS protocol elements occur as possible values in other areas, these elements are distinguished by their object identifiers. 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 [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. Adams, Sylvester, Zolotarev, Zuccherato [Page 7] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 id-kp-dvcs OBJECT IDENTIFIER ::= { id-kp 10 } 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 ::= {id-ad 4} 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 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 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: Adams, Sylvester, Zolotarev, Zuccherato [Page 8] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 - 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. 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. Adams, Sylvester, Zolotarev, Zuccherato [Page 9] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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 , dvc [3] ContentInfo , crl [4] IMPLICIT CertificateList, ocspcertstatus [5] IMPLICIT CertStatus, oscpcertid [6] IMPLICIT CertId , oscpresponse [7] IMPLICIT OCSPResponse, extension Extension } Adams, Sylvester, Zolotarev, Zuccherato [Page 10] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 Certificate, PolicyInformation and CertificateList are defined in [RFC2459]. ESSCertId is defined in [RFC2634]. CertiId, OCSPResponse and CertStatus are defined in [RFC2560]. PKIStatusField is defined in [RFC2510]. The choice 'dvc' can contain a data validation certificate, or a timeStamp, or other assertions. The choices 'dvc', '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). 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, 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]. Adams, Sylvester, Zolotarev, Zuccherato [Page 11] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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 ::= { id-ct 5 } 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 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. Adams, Sylvester, Zolotarev, Zuccherato [Page 12] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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 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 Adams, Sylvester, Zolotarev, Zuccherato [Page 13] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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 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 Adams, Sylvester, Zolotarev, Zuccherato [Page 14] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 "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 6 } 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, MUSTS 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: Adams, Sylvester, Zolotarev, Zuccherato [Page 15] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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 } 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' Adams, Sylvester, Zolotarev, Zuccherato [Page 16] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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. 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 Adams, Sylvester, Zolotarev, Zuccherato [Page 17] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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 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. Adams, Sylvester, Zolotarev, Zuccherato [Page 18] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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 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. Adams, Sylvester, Zolotarev, Zuccherato [Page 19] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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. 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. Adams, Sylvester, Zolotarev, Zuccherato [Page 20] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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 (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 Adams, Sylvester, Zolotarev, Zuccherato [Page 21] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 (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. 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 Adams, Sylvester, Zolotarev, Zuccherato [Page 22] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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 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-dvcs-dvc identifies the data valication Adams, Sylvester, Zolotarev, Zuccherato [Page 23] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 certificate attribute type. id-aa-dvcs OBJECT IDENTIFIER ::= { id-aa 15 } 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 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. Adams, Sylvester, Zolotarev, Zuccherato [Page 24] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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 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 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. Adams, Sylvester, Zolotarev, Zuccherato [Page 25] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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 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 Adams, Sylvester, Zolotarev, Zuccherato [Page 26] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 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 Server 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 Intended usage: COMMON Author/Change controller: Peter Sylvester 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(1234567890)} DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- IMPORTS Extensions, AlgorithmIdentifier Adams, Sylvester, Zolotarev, Zuccherato [Page 27] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 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(4711)} -- Currently OCSP has no module name ; -- 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-DVCSReqData OBJECT IDENTIFIER ::= { id-ct 5 } id-ct-DVCSResponseData OBJECT IDENTIFIER ::= { id-ct 6 } -- Data validation certificate attribute id-aa-dvcs OBJECT IDENTIFIER ::= { id-aa 15 } -- using the following bases : Adams, Sylvester, Zolotarev, Zuccherato [Page 28] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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 , esscertid [1] ESSCertId , pkistatus [2] IMPLICIT PKIStatusInfo , dvc [3] ContentInfo , crl [4] IMPLICIT CertificateList, Adams, Sylvester, Zolotarev, Zuccherato [Page 29] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 ocspcertstatus [5] IMPLICIT CertStatus, oscpcertid [6] IMPLICIT CertId , oscpresponse [7] IMPLICIT OCSPResponse, 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, serialNumber Integer, responseTime DVCSTime, nonce Nonce OPTIONAL, dvStatus [0] PKIStatusInfo OPTIONAL, policy [1] PolicyInformation OPTIONAL, Adams, Sylvester, Zolotarev, Zuccherato [Page 30] draft-ietf-pkix-dcs-04.txt DVCS Protocols March 7, 2000 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 - Acknowledgements This text is based on two initial works from Robert Zuccherato and Carlisle Adams, both at Entrust Technologies, and from Denis Pinkas at Bull, 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. Adams, Sylvester, Zolotarev, Zuccherato [Page 31]