这个文档描述了一个通用的数据有效性和验证服务器（Data Validation and Certification Server，DVCS），以及和它通讯时使用的协议。数据有效性和验证服务器是一个可信任的第三方，用来作为构造可靠的不可否认服务的一部分。

PKI中数据有效性和验证服务器的用处在于验证签名文档、公钥证书和数据拥有或存在的有效性。协议产生的验证声明称做数据有效性证书(Data Validation Certificates，DVC) 。

我们给出了如何使用数据有效性和验证服务器的例子，它们不仅扩展了签名的使用范围，使其不局限于密钥的终止或撤消，而且质询了关于公钥证书地位的数据有效性和验证服务器。文档包含一个完整的时间戳事物的例子。

1. 介绍

这个文档是已在IETF PKIX工作组中提议和讨论的工作的结果。作者和组中一些成员认为提升这些还相当新的概念为标准过程还为时尚早。这里表述的概念已经稳定了一段时间，并且有部分已经实现。大家同意发表在诸如实验性RFC刊物是一个合适的方法，以便为其它实现提供稳定的参考文档。

这个文档中的关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY”和“OPTIONAL”(如所见为大写)按照RFC2119的描述进行解释。

数据有效性和验证服务器是可信任的第三方，提供诸如数据有效性服务、声明数据签名文档的正确性、公钥证书和数据拥有及存在的有效性服务。

作为有效性的结果，DVCS产生一个数据有效性证书(DVC)。此证书可用来构建有关一个声称拥有数据的实体的有效性和正确性、一个实体公钥证书有效性和恢复状态和一个数字签名文档的有效性和正确性。

DVCS提供的服务并不能取代在大型开放环境中检查公钥证书撤消使CRLs和OCSP的使用，因为这关系到协议的可量测性。

它更应该应用于支持关于无纸文档环境的不可否认性或对更多传统服务的补充。DVC中通过提供有效的数字签名文档或公钥证书，使数据有效性证书的存在支持不可否认性。

即使在公钥证书到期，没有或很难得到恢复信息的情况下，使公钥证书有效的DVC仍可以使用。例如，确定一个DVC的有效性被认为是一件较为容易的事情，因为拥有DVCS的人数远比拥有公钥证书的人少。

协议的一个重要特性是通过使用同样的协议（不需要使用相同的服务）和有效的签名文档使DVCs生效。对于一个特定的DVC，我们可以不验证签名，也就是说，通过和一个文档比较来确定其有效性。

响应签名文档或公钥证书有效性签名请求的数据有效性证书的产品同时也提供证据，表明验证数据签名或公钥证书有效性的请求者执行了预期的diligence 。

这个文档定义了数据签名的使用，以确保文档和DVCs的真实性，还定义了对应的术语；还定义了提供验证证据的其他方法，尤其是这可能取代SignedData 安全信封。

2. DVCS提供的服务

现有详述定义了四类有效性和证书服务：

- 数据拥有证书 Certification of Possession of Data (cpd),

- 数据拥有声明证书 Certification of Claim of Possession of Data (ccpd),

- 数字签名文档有效性 Validation of Digitally Signed Document (vsd),

- 公钥证书有效性 Validation of Public Key Certificates (vpkc).

DVCS必须至少支持这些服务的一个子集。DVCS可以支持有限的vsd服务，以便确认数据有效性证书。

完成每一步后,DVCS产生一个数据有效性证书－一个包含有效性结果和可信任的时间信息的签名文档.

2.1 数据拥有证书Certification of Possession of Data

数据拥有证书服务提供证据表明，在指定的时间请求者拥有数据以及数据有效性服务器上是真实的数据。

2.2 数据拥有声明证书Certification of Claim of Possession of Data

此服务除了表明请求者用的不是数据而是用消息摘要外，其他和上明的服务是一样的。

2.3数字签名文档有效性Validation of Digitally Signed Documents

此服务用于宣称签名文档的有效性。

DVCS使用一切合适的状态信息和公钥证书来验证所有包含在签名文档中的签名。DVCS验证所有包含在文档中签名，还检验签名实体是否可信，例如验证签名实体的整个证书路径有可信的来源（如，DVCS's CA, 或同层的根CA）。

DVCS可能需要参考相关的CRLs或通过访问CAs更新的状态信息进行补充，例如访问OCSP服务，可信任的目录服务或其他DVCS服务。

DVCS会对所有签名文档中的签名执行验证。一个签名验证的失败不会导致整个有效性验证的失败，相反，如果没有足够的签名数量将可能导致全部失败。

2.4公钥证书有效性Validation of Public Key Certificates

此服务用来验证和声明在指定时间一个或多个公钥证书的有效性(根据[RFC2459])。

验证公钥证书时，DVCS验证请求中包含的证书是有效的，并在指定的时间决定它的撤销状态。DVS从证书的发布者到一个可信任的地方，检验整个证书的路径。而且DVCS可能会依赖于外部信息（CRL,OCSP,DVCS）。

3. 数据证书服务器的使用和Scenarii.

完全描述不同的可操作的DVCS scenarii 或用法超过了本文档的讨论范围。

参见附录B和C，一套基础范例和使用实例。

确认签名文档服务可用来支持不可否认服务，使签名文档不仅可用在公钥证书恢复或超期，还可用在简单地将签名有效性授权给一个可信任地（公司范围）主要服务。

确认公钥证书服务可用在需要关于证书撤销状态的及时信息（如，传输很高价值资金或高度敏感密钥）或用在需要支持不可否认的证据时。

数据有效性证书可用来简化签名证书超期或随之而来的证书撤销后签名的有效性验证：数据有效性证书可用作一个签名中验证属性，包括一个关于在签名时使用的证书可用性的追加声明。为了验证这样的签名，只确认数据有效性证书的有效性就足够了。

DVCS还可能在数据有效性证书中包括附加的密钥交换证书，来确认一个密钥交换证书 ，给应用程序提供一套附加授权接受者，其会话密钥也应当被加密。例如，这可被用来提供公司范围内恢复计划的中央管理。注意，附加证书不仅依靠请求的证书，还依靠请求者的身份。

数据拥有声明证书服务也可称作时间戳。

数据拥有证书服务可用来声明合法的文档存放，或实现作为一个可信任第三方服务的文档归档服务。

数据有效性和证书服务器协议可用在不同的服务范围。例如，全公司内的集中服务（签名验证、公司证书确认）、多组织机构间合作服务、或时间戳或数据文档的通用第三方服务。

DVCS的一个重要应用是在一个所有安全考虑都基于整个公司规范的企业环境中。一个公司的DVCS服务可以授权一个重要管理服务机构来作出所有的技术决定（如，有效路径，确认的配置）。

不论何种情况，数据有效性和证书服务器中PKI实体具有的信任信息都会传递到数据有效性证书的内容中（就像CA的信任信息会传递到其发布的公钥证书中一样）。

DVCS服务可以和归档和日志系统结合使用为不可否认服务提供加强的安全保障服务。从这点考虑，DVCS可被认为是一个Evidence Recording Authority [ISO-NR]。

4. DVCS功能需求

DVCS必须：

1. 按照策略的定义，为请求者提供一个数据有效性证书形式的签名响应，或者一个错误响应。DVCS服务的定义和策略定义了产生响应的DVCS所使用的信息中有多少将包括再数据有效性证书中，例如，公钥证书、CRL、其他OCSP服务器响应、DVCS、或其他。

2. 数据有效性证书显示了签名文档、公钥证书或数据是否有效；如果无效，显示验证失败的原因是什么。

3. 每个数据有效性证书中包括一个严格单调连续增长的数字。

4. 每个数据有效性证书包括一个时间值或一个时间戳标记。

5. 用密钥签署数据证书标记，此密钥被授权用作dvcs签名扩展密钥。还包括证书的说明，作为签名的签署属性。

6. 在分发数据有效性证书前，检查其自己签名密钥和证书的有效性。如果检查没有通过，绝对不能分发证书。

在每个数据有效性证书中，DVCS都应当包含一个策略标识符，以确定DVCS签名的可信度和使用的有效策略。

5. 数据证书服务器事务处理过程Data Certification Server Transactions

DVCS事务处理过程以客户端预备数据有效性和证书请求开始。请求总是包含在需要鉴别有效性、正确性和合法性的数据中。

请求可以用安全信包封装，为请求者和服务器提供证明。请求者的证明可用CMS中描述的集中格式归档，尤其是签名数据signedData。

DVCS客户端选择一个合适传输机制把请求传递到DVCS。还有必要选择一种传输机制，提供机密性，尤其是为请求者提供一种DVCS证明，如TLS、CMS或S/MIME 加密法。

如果请求有效，DVCS执行所有必须的验证步骤，产生数据有效性证书，给请求者发回一个包含DVC的响应消息。

数据有效性证书的形式是一个签名文档(CMS SignedData)。

和请求一样，也必须选择一种传输机制为承载DVC提供机密性。DVCs不一定以和请求同样的方式来传输，比如，它们可以在通过HTTPS接收到一个在线请求后用电子邮件返回。

如果请求有效，DVCS产生一个包含适当错误通告的响应消息。

接收到响应后，请求实体应当验证其有效性，也就是说，检验其是否包含一个可接收的时间、正确的DVCS名字、正确的请求信息和消息印记、有效签名以及令人满意的状态、服务和策略字段。

当验证DVC有效性时，是由请求者的应有程序来检查一个DVCS签名证书是否有效。根据使用环境，可能使用不同的在线或out of band方法，如CRLs、DVCS或OCSP。

通过所有的检查，数据有效性证书就可用来鉴别相应数据的正确性和合法性。

针对一个请求，DVCS可能返回多个DVC。在这种情况下，除了一个请求外，其余的请求都处于全局“等待”状态。

6. DVCS的定义

为了能从dvcs中引入元素，使用以下对象标识符作为ASN.1模块标识符。

id-mod-dvcs OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 15}

使用SignedData为DVC提供验证的DVCS 必须用密钥签署所有数据证书消息。密钥对应的证书必须包含[RFC2459] 4.2.1.14节中定义的扩展的密钥使用字段扩展名，其中KeyPurposeID的值为id-kp-dvcs。这个扩展被标记为关键性的。

数据有效性证书必须包含一个DVCS用来签名的ESSCertID证书鉴别属性。

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

DVCS的证书可能包含一个授权信息访问扩展（Authority Information Access extension [RFC2459] ），用来传送和DVCS联系的方法。扩展中的accessMethod字段必须包含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}

'accessLocation'字段的值定义了用来访问DVCS的传输方式（如，URI）。

7. 普通数据类型

请求和响应数据结构中有几种普通的数据类型。这些数据类型或在本文档中定义，或来自其他地方。本章定义和描述了这些类型，并列举了它们的用法。

7.1 version类：

请求和响应包含一个可选的证书字段，指定数据结构的版本。在协议的这个版本中，两个字段都为1，或者根本没有这个字段。

7.2 DigestInfo类：

这个元素在 [RFC2315]中定义。由于RFC2315是报告文档，所以在这里重复一下其定义：

DigestInfo ::= SEQUENCE {

digestAlgorithmDigestAlgorithmIdentifier,

digestDigest }

Digest ::= OCTET STRING

DigestInfo类各个字段的意思如下：

- 字段'digestAlgorithm'标识数据摘要时使用的消息摘要算法（以及相关参数）。

- 字段'digest'是消息摘要过程的结果。

DigestInfo在两个地方使用：

- 作为ccpd服务的数据部分；

- 在数据有效性证书中保持一个对应请求数据部分的摘要或一个ccpd服务数据字段的拷贝。

7.3. 时间值

时间指示器可在请求和响应中出现。最简单的形式是，时间用格林威治时间表示，后面是秒的分数部分。.

另一种可替换的形式是TSA时间戳标记，或来自其他第三方服务的DVC（或其他记号）。

由策略决定DVCS是解释请求中的时间值，还是确认请求中的时间值。

DVCSTime ::= CHOICE {

genTime GeneralizedTime,

timeStampTokenContentInfo }

协议的未来版本也许包含其他时间格式。

DVCS产生的时间值是渐增的，但并不是唯一的，DVC的顺序由连续的数字定义。

7.4. PKIStatusInfo

这个数据结构在[RFC2510]中定义，作为TargetEtcChain数据结构'chain'字段的组成部分使用。PKIStatusInfo的每一次出现都是由响应的DVCS产生，反映了本地验证的结果。

7.5. TargetEtcChain

TargetEtcChain数据结构包含证书和其它指示器，或描述需要确认的信息（在cpkc服务中的请求），或描述验证的结果，也可能包含策略和策略映射的信息。

关于如何填值和解释这个数据结构的细节在后面每个服务的含义中定义。

'pathProcInput'字段包含在确认时使用的策略和策略映射信息。

在响应中，'pkistatus'和`certstatus' 选项可能只在'chain'序列中出现。如果出现，它们包含的是对最前面元素或目标值的本地验证结果，如果它是'chain'序列里的第一个元素。

如果没有出现'pkistatus'或'certstatus'，DVCS认为'chain'里的所有元素都是可信赖的。注意：此时可能由有效的OCSP响应或DVC来指示有效证书。

TargetEtcChain ::= SEQUENCE {

target CertEtcToken,

chainSEQUENCE SIZE (1..MAX) OF

CertEtcToken OPTIONAL,

pathProcInput [0] PathProcInput OPTIONAL }

PathProcInput ::= SEQUENCE {

acceptablePolicySet SEQUENCE SIZE (1..MAX) OF

PolicyInformation,

inhibitPolicyMappingBOOLEAN DEFAULT FALSE,

explicitPolicyReqd BOOLEAN DEFAULT FALSE }

CertEtcToken ::= CHOICE {

certificate[0] IMPLICIT Certificate ,

esscertid [1] ESSCertId ,

pkistatus [2] IMPLICIT PKIStatusInfo ,

assertion [3] ContentInfo ,

crl [4] IMPLICIT CertificateList,

ocspcertstatus[5] IMPLICIT CertStatus,

oscpcertid [6] IMPLICIT CertId ,

oscpresponse [7] IMPLICIT OCSPResponse,

capabilities [8] SMIMECapabilities,

extension Extension }

证书、策略信息和证书列表在[RFC2459]定义.ESSCertId在 [RFC2634]定义.CertId, OCSPResponse和CertStatus在 [RFC2560]中定义。PKIStatusField 在[RFC2510]定义。

选项'assertion'包含一个数据有效性证书，和时间戳，和其它声明。

选项'assertion', 'ocspresponse' 和'crl' 由外部响应DVCS服务提供的。选项'certStatus'和'pkistatus'反映了由响应DVCS直接作出的决定。

如果用证书标识符就足够执行服务，那么作为证书的替代，证书标识符(ESSCertId, CertId)可以用在请求和响应中，例如，在相应的证书正用于其他请求和响应时（作为SignedData类型的一部分）。

证书授权组织的证书和证书标识符可以任何顺序出现，可以表示几条证书链。

选项'capabilities'可用来指示SMIMECapabilities。它应用于证书，由序列中前面的元素识别的。

7.6. DVCSRequestInformation

DVCSRequestInformation数据结构包含关于数据有效性和证书请求的通用信息。这个数据结构在请求中出现，也包含在相应的数据有效性证书中。

DVCSRequestInformation ::= SEQUENCE {

version INTEGER DEFAULT 1 ,

service ServiceType,

nonceINTEGER OPTIONAL,

requestTimeDVCSTime OPTIONAL,

requester [0] GeneralNames OPTIONAL,

requestPolicy [1] PolicyInformation OPTIONAL,

dvcs [2] GeneralNames OPTIONAL,

dataLocations [3] GeneralNames OPTIONAL,

extensions [4] IMPLICIT Extensions OPTIONAL

}

此服务类型列举了一个请求的DVCS服务类型。

对于此服务的描述参见第二章。

ServiceType ::= ENUMERATED { cpd(1), vsd(2), cpkc(3), ccpd(4) }

7.7. GeneralName 和GeneralNames

有几种GeneralName和GeneralNames 出现的SEQUENCES。这些数据结构从[RFC2459]引入。

8. 数据有效性和证书请求

数据有效性和证书请求是[RFC2630]中定义的ContentInfo。

可由具有内容类型id-ct-DVCSRequestData签名的DVCSRequestData的 [RFC2630]内容组成，

id-ct-DVCSRequestData OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 7}

这些数据有选择的被内容类型contenttypes封装，以提供证明和/或机密性。

本文档描述了[RFC2630]签名数据结构的使用，其中在encapContentInfo 的eContentType中指示的内容类型是id-ct-DVCSRequestData和 id-ct-DVCSRequestData，且encapContentInfo中以字节形式承载的eContent包含DVCSRequestData数据结构。

使用签名数据结构时，数据确认和证书请求可以包含几个SignerInfo数据结构，且签名计数器属性要依赖运行的环境。

当一个终端用户客户端创建请求时，有一个或零个SignerInfo 。后续的DVCS可以增加一个额外的签名和一个连署属性，也可以使用RFC2630封装，提供验证和/或机密性。

请求的内容包含所需服务和其它参数的描述，要确认的数据和请求的可选标识符。

DVCSRequest ::= SEQUENCE {

requestInformationDVCSRequestInformation,

data Data,

transactionIdentifierGeneralName OPTIONAL

}

'DVCSRequest.requestInformation' 元素包含关于请求的通用信息，由以下这些请求者填充：

- 'version' 字段，在本协议的这个版本中设置为1或没有此字段。

- 'service'字段包含请求的服务。

- 'nonce'字段可被用来提供额外的保护，以消除重复运行或内容猜测攻击。

- 'requestTime' 字段可被用来指示请求的服务应执行的时间。对vsd和cpkc服务，特指声明签名文档或证书有效性的时间。对于其它服务，DVCS忽略此字段。如果没有此字段，则假定为目前时间。

- 'requester' 字段的值指示请求实体。此字段的使用和解释由DVCS策略定义。一些使用的范例有：如果此字段存在，且请求被签名，DVCS要求此字段必须和相应签名证书的匹配（subjectName 或 subjectAltName扩展）。

当一个请求被传递到另一个DVCS时，可能已经用另一个DVCS签名过。

传递时，DVCS可在请求中添加自己的特性传递给另一个服务提供者，且会去掉初始值。

- 'requestPolicy' 字段指示请求确认的策略。DVCS必须检查此字段，以验证和它自己策略的一致性。没有此字段指示可接收任何策略。.

- 'dvcs'字段用来指示一列DVCS，它们可为产生响应提供（额外的）信息和执行额外操作 。

由DVCS策略决定是否兑现此字段，定义接受通用名字的哪个选项（如，是URL，还是DN）。

- 'dataLocations'字段可用来指示请求的数据字段的拷贝和补充信息从哪里获得。DVCS不在自己的操作中使用这个字段，这个字段的准确解释由应用程序定义。

- 'requestTime' 字段可用来指示请求服务应执行多长时间。对vsd和cpkc服务来说，它指定声明一个签名文档和证书的时间。对于其它服务，DVCS忽略此字段。如果没有此字段，则假定为目前时间。DVCS服务关于本地策略中指定的目前时间有一个时间限制和一个增量时间限制。

- 'extensions'字段可用来包含其它额外信息。扩展可标记为是否关键，指示是否假设DVCS理解它们。本文档没有定义扩展。

DVCSRequest.data 包含指定的服务内容，由每一个DVCS提供的特殊服务定义。

根据请求的服务类型，这个字段可包含一个签名文档，一个证书列表，一个消息摘要或任意数据。

使用下列的类型：

Data ::= CHOICE {

message OCTET STRING ,

messageImprint DigestInfo,

certs SEQUENCE SIZE (1..MAX) OF

TargetEtcChain

}

填充数据元素的请求信息如下：

- 对vsd服务请求来说，请求者在“消息”选项的字节值中封装一个CMS SignedData对象。

由请求者决定是否以及如何提供验证signedData 对象中签名所需的证书。请求者可以往封装的signedData 对象中添加证书或在请求中添加证书列表。

- 对cpkc服务请求来说，使用'certs'选项。

每个要验证的证书必须包含在单独的TargetEtcChain实例中。TargetEtcChain.chain字段标识一个或多个可用来确认证书的信任链条。DVCS可有选择的挑选证书的子集作为证书路径，或忽略这个字段。

'TargetEtcChain.pathProcInput'字段表示X.509公钥证书路径确认使用的精确策略指示器和抑制策略映射指示器可接受的策略集和初始设置（参见RFC2459）。

请求中，只有TargetEtcChain的证书、ESSCertId、CertId或扩展选项可使用。

请求者负责提供足够的信息给DVCS，来标识相应的证书。

- 对ccpd服务来说，使用'messageImprint'选项。

hashAlgorithm 字段中指明的哈希算法应该是“强壮”的哈希算法（也就是说，应该是单向和避免冲突的）。由数据证书服务器来决定是否给定的哈希算法足够“强壮”（例如，基于目前对密码分析学的知识了解和计算资源技术的状态）。

- 对cpd服务来说，使用'message' 选项。

这个字段包含请求者指定的任何类型内容数据。DVCS不检查、修改或基于“消息”字段特殊内容而采取特殊行动。

'DVCSRequest.transactionIdentifier'字段用来把包含错误消息的DVCS响应和请求关联起来。例如，在基于邮件的环境中，参数可能是messageid的一个拷贝。注意：把请求和有效的数据有效性证书关联起来时，transactionIdentifier 不是必须的。

9. DVCS响应

本章描述了由DVCS创建，用来指示证书请求和有效性结果的数据结构。

DVCS响应结构由DVCS产生，作为数据有效性和证书请求处理的结果。

数据有效性响应包含一个id-ct-DVCSResponseData类RFC2630ContentInfo，这个类用信号表示一个DVCSResponse 结构。

id-ct-DVCSResponseData OBJECT IDENTIFIER ::= { iso(1) member-body(2)

us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 8 }

数据可用RFC2630结构封装，以便提供DVCS的验证和请求的一致性和机密性。本文档指定RFC2630中SignedData结构使用方法。

encapContentInfo 的eContentType 中指示的contenttype属于id-ct-DVCSResponseData类，这个类用信号表示一个DVCSResponse作为encapContentInfo的eContent（载波形式是字节）。DVCS使用一个在extendedKeyUsage中用来验证DVCS签名的相应证书的密钥。

在DVCS不能生成有效签名（假如DVCS的签名密钥被损坏）的关键环境中，产生的包含错误提示的DVCSResponse必须是没有附上signerInfo的signedData。客户端把接收到的未签名的DVCSResponse作为一个重要的和致命的错误，并且消息的内容是完全不可信的。

有效响应可以包含以下内容之一：

1. 数据有效性证书（DVC）,传递由DVCS执行的数据有效性操作所产生的结果。

2. 错误提示。当由于解析错误、请求者验证失败或其它导致DVCS不执行请求的而使请求失败时，就产生错误提示。

使用下面的类：

DVCSResponse ::= CHOICE {

dvCertInfoDVCSCertInfo ,

dvErrorNote [0] DVCSErrorNotice }

9.1. 数据有效性证书

数据有效性证书是包含带有'dvCertInfo'选项的DVCSResponse的signedData 对象类型。

DVCSCertInfo::= SEQUENCE {

version Integer DEFAULT 1 ,

dvReqInfo DVCSRequestInformation,

messageImprintDigestInfo,

serialNumber Integer,

responseTime DVCSTime,

dvStatus[0] PKIStatusInfo OPTIONAL,

policy [1] PolicyInformation OPTIONAL,

reqSignature [2] SignerInfos OPTIONAL,

certs[3] SEQUENCE SIZE (1..MAX) OF

TargetEtcChain OPTIONAL,

extensions Extensions OPTIONAL }

DVCSCertInfo结构的返回值是成功执行数据有效性服务的结果。它包含数据有效性的结果，原始请求的参考和其它参数。请注意“成功执行”不一定意味着它本身的有效性——DVCSCertInfo可以包含“有效”或“无效”结果。

DVCS建立如下的DVCSCertInfo：

- 'version' 字段在协议的这个版本中从不出现。

'dvReqInfo'本质上是相应请求的'requestInformation'字段的一个拷贝。DVCS可以修改ReqInfo结构的'dvcs'、'requester'、'dataLocations'和'nonce' 字段，举例来说，如果请求由一系列DVCS处理，如果请求需要指示DVCS或指示从哪里找到'vpd'请求数据的一个拷贝。对'nonce' 唯一的修改是需要包含一个以前不存在的新字段，或连接其它数据至以存在值的末尾（右边）。

- 'DVCSCertInfo.messageImprint'字段从相应请求的'data'字段计算得来，如下：

对于'certs'选项（'vpkc'服务）来说，摘要是基于DER编码数据值计算得来。对于'message'选项（'vsd'和'vpd'服务）来说，摘要是基于OCTET STRING 字节值（不包括标志和长度字节）计算得来。

由DVCS决定选择合适的摘要算法。

对于'messageImprint'选项（'vcpd'服务）来说，拷贝DVCSRequest 的'messageImprint'作为此字段值。

- 'DVCSCertInfo.serialNumber'字段包含一个唯一的请求标识符。

- 'responseTime'字段指示一个和响应有关的时间值。这个值可以是本地产生的，或者签名的TimeStampToken (TST) ，或者从外部服务获得的DVC。

在使用从外部服务获得的值之前，DVCS必须根据外部服务规则使之有效。

- 'DVCSCertInfo.dvStatus'字段反映了收集到的有效性结果。

如果字段不存在，等同于成功状态。

对于vkpc，如果状态字段存在且置为成功（SUCCESS），表明所有的证书成功确认。如果它存在且置为失败（FAILED），表明所有和一部分证书有效性验证失败，而且应该调查'certs'的特殊状态，'certs'的TargetEtcChain 结构中至少有一个元素具有失败状态。

如果'dvStatus'字段表明没有成功（'granted'或'granted with mods'），那么'failInfo'元素可能指示了失败的原因。注意：'certs'字段可能包含其它关于确认失败的信息。

签名之一确认的失败不一定是确认一个签名文档失败的必然结果。例如，只要成功确认足够数量的签名，就会产生带有状态'grantedWithMods'的 DVC。带有'granted'状态的DVC只有在所有签名都被成功确认后才会产生。

如果不能立刻获得最后的响应，那么此字段必须存在，且状态值要设置为WAITING，我们假定DVCS会在之后提供其它的最终状态。

必要程序的细节是DVCS策略的一部分。

失败时，请求者可以通过查看TargetEtcChain字段进一步调查失败的原因。

'CertEtctoken.pkistatus'字段会指示哪一个条目确认失败或成功以及是什么原因。

- 'DVCSCertInfo.policy'字段指示DVCS操作的策略

-如果'DVCSCertInfo.reqSignature'存在，那么必然和相应请求的signerInfos字段有相同的值，由策略决定它是否包含此字段。

- 'DVCSCertInfo.certs' 字段包含由DVCS进行确认后的结果。对于cpkc服务来说，每个元素包含targetAndChain 子字段中带有可选子集的请求的相应字段的一个拷贝和确认的结果，以及其它来自证书授权组织或附录C.3中描述的证书或证书参考。对于vsd服务来说，每个元素包含一个需确认签名文档的签名的确认结果。

当全程WAITING时，DVCS可以选择是在某些'certs'字段中返回一个唯一的等待状态，或根本不返回这样的一个TargetEtcChain。

'acceptablePolicySet'序列表明在X.509公钥证书路径有效期间处理的策略和映射 。PolicyMappingsSyntax 在RF2459中定义。

- 'extensions'字段可用来向客户端返回其它信息。扩展可标记为是否重要，以便指示客户端是否必须理解它们。本文档不定义扩展。

9.2. DVCS 错误通告

DVCS错误通告是一个包含'dvErrorNote'选项的DVCSResponse的CMS签名数据对象。

DVCSErrorNotice ::= SEQUENCE {

transactionStatus PKIStatusInfo ,

transactionIdentifier GeneralName OPTIONAL }

PKIStatusInfo在[RFC2511]中定义。为了和DVCSErrorNotice通讯，使用以下的PKIFailureInfo值的子集：

PKIFailureInfo ::= BITSTRING {

badRequest (2),

-- 禁止和不支持的事务

badTime (3),

-- 时间消息不很接近由本地策略定义系统时间

badDataFormat (5),

-- 提交的数据格式不正确

wrongAuthority(6),

-- 请求中显示的DVCS和响应令牌创建的不同

incorrectData (7)

--请求的数据（也就是签名）是不正确的)

在DVCSErrorNotice中, PKIStatusInfo的PKIStatus字段必须设置为REJECTED。

PKIStatusInfo 的'statusString'字段可用来提供额外的正文，诸如失败原因，就像“未能获得服务”。DVCS用对应请求的'DVCSRequest.transactionIdentifier'字段的一个拷贝来初始化'DVCSErrorNotice. Transaction Identifier'

在特定的环境中，DVCS可能无法对请求产生一个有效响应（例如，在一段时间内不能计算出签名）。在这种情况下，DVCS会产生一个没有签名的DVCSErrorNotice 响应。

DVCS客户端不信任未签名的响应。DVCS客户端只有在通讯通道提供服务器验证的情况下，才会信任未签名的响应（例如，RFC2246 TLS定义的服务可提供这样的验证）。

10. 传输

本文档中没有强制性的传输机制，所有的机制都是可选的。给出的两个传输协议示例允许联机交换请求和响应，以及客户端和DVCS之间的异步通讯。

DVCS可使用协议的组合，产生多个DVCs。

10.1 通过HTTP或HTTPS实现的DVCS协议

这一段说明了把通过超文本传输协议交换的DVCS协议转换成ASN.1编码消息一种方法。

DER编码的DVCS请求和响应使用一个简单的具有Content-Type应用/dvcs（且具有缺省二进制编码）的MIME对象封装。

这个MIME对象可使用普通的基于WWW连接的HTTP或HTTPS处理引擎进行发送和接收，还可为DVCS消息提供简单的客户端/服务器传输。

10.2 使用电子邮件的DVCS协议

本节说明把第8节中描述的通过Internet邮件来交换的协议转换成ASN.1编码消息的一种方法。

DER编码的DVCS请求和响应使用一个简单的具有适当Content-Transfer-Encoding 的Content-Type应用/dvcs的MIME对象封装。

这个MIME对象可使用MIME处理引擎来接收和发送，并且为DVCS消息提供简单的Internet 邮件传输。

为了把可能的错误响应和请求关联起来，请求者应使用'transactionIdentifier'字段。

请求者不应使用响应服务来假设消息头字段的使用，尤其是在使用象Subject, Message-ID或References等字段时。

11. 需要考虑的安全问题

这一章讨论安全问题。当设计数据有效性和证书服务时，已经考虑了以下这些影响数据有效性证书的有效性或“可信度”的事项。

采取适当的安全和控制措施来保护用于签名DVCs的密钥，这是强制性的，以便将可能的损害减少到最低程度。然而，如果私钥被损坏，则对DVCS产生的所有DVC都应进行审计追踪，这是帮助区分真和假DVCs的一种方法。DVCS可以为vsd服务提供对由这个或另一个单独地基于审核验证DCVS产生的DVCs进行地确认。

当要求机密性和服务器验证时，请求和响应可用适当地机制进行保护（例如RFC2630CMS封装或RFC2246TLS）.

对于vsd和cpd服务来说，我们强烈推荐服务器验证。

客户端标识和验证可使用RFC2246TLS定义地服务，而不是使用CMS格式提供验证。

12. 专利信息

以下是作者所知现存的按年代排列的和数据有效性和证书服务有关的美国专利。这个列表并不完备，随时都将补充存在的其它的专利。

使用此协议的DVCS协议和应用的实现应进行它们各自的专利查询和决定在实现过程中是否存在障碍。

# 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 JuniorUniversity

# 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 CryptographicCertificate(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.,

13. 参考文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2510]Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure, Certificate Management Protocols", RFC 2510, March 1999.

[RFC2459]Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure, Certificate and CRL Profile", RFC 2459, January 1999.

[RFC2630]Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.

[ISONR]ISO/IEC 10181-5: Security Frameworks in Open Systems.Non-Repudiation Framework.

[RFC2119]Bradner, S., "Key works for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2511]Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet X.509 Certificate Request Message Format", RFC 2511, March 1999.

[RFC2246]Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC 2246, January 1999.

[RFC2634]Hoffman P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.

[RFC2560]Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol", RFC 2560, June 1999.

14. 作者地址

Carlisle Adams

Entrust Technologies

1000 Innovation Drive

Ottawa, Ontario

K2K 3E7

CANADA

EMail: cadams@entrust.com

Michael Zolotarev

Baltimore Technologies Pty Limited

5th Floor, 1 James Place

North Sydney, NSW 2060

AUSTRALIA

EMail: mzolotarev@baltimore.com

Peter Sylvester

EdelWeb SA - Groupe ON-X Consulting

15, Quai de Dion Bouton

F-92816 Puteaux Cedex

FRANCE

EMail: peter.sylvester@edelweb.fr

Robert Zuccherato

Entrust Technologies

1000 Innovation Drive

Ottawa, Ontario

K2K 3E7

CANADA

EMail: robert.zuccherato@entrust.com

译者：郭大刚（guodagang guodagang@tyut.edu.cn）

译文发布时间：2001-11-7

版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。