CN1244936A - 用于电子事务系统和信赖服务器 - Google Patents

Abstract

电子事务系统中的信赖管理包括由认证机构向客户发出一证明把该客户的至少一个公用密钥与至少一个属性连接起来,以及向信赖方传送关于所发出证明的信息。信赖服务器保持被传送的关于所发出证明的信息。客户构成一个事务然后把该事务提供给信赖方。该事务包括该证明或对它的参考。信赖方根据从客户那里收到的事务向信赖服务器发出一个请求以请求保证。信赖服务器根据关于所发出证明的信息和所请求的保证,确定是否提供所请求的保证。根据这一确定,信赖服务器向信赖方发出一个向信赖方提供保证的授权消息。

Description

用于电子事务系统的信赖服务器

1.发明领域

本发明是关于电子事务，更具体而言，是在一个电子事务系统中服务于支持对数字签字证件的信赖和对这种证件风险的处理。

2.发明背景

实现电子商务的系统正在变得越来越广泛，这部分地由于象因特网之类全球计算机网络的出现，部分地由于公用密钥密码术的发展与成熟，它提高了这种商业活动的安全性。于是，在一些报告中已经预见了公用密钥密码术对电子商务的应用，这些报告诸如：国际通信联盟(ITU，前身是CCITT)的建议X.509(以下称“标准X.509”)，美国酒巴协会信息安全委员会的数字签字指导方针(1995年12月版，以下称“ABA指南”)，以及例如犹他州数字签字法案，犹他法规年鉴标题46，第3章(1996)(以下称“犹他法案”)等法令和法规。

这些报告和其他报告中建立的主张解决了某些问题，但又留下了许多没有解答和没有解决的问题。

2.1数字签字认证的传统途径

为使用安全电子商务，根据传统方法，每个用户有一对相关密钥，即一个私人密钥(由该用户保持秘密)和一个公用密钥(它能为不会危害相应私人密钥的任何人所知)。使用公用密钥，一种算法能确定是否相应的私人密钥被用于签署或认证一个给定的消息。例如，如果A希望向B发一个消息，并向B高度肯定该消息真正是A的，那么A可以用A的私人密钥数字签署该消息，然后B能用A的公用密钥来核实该消息真正是A的。

公用密钥只是一个值(通常是一个数)，它与任何人(包括要认证其消息的人)没有任何内在关联。数字签字的广泛商业应用要求有可靠的信息把公用密钥与识别出的人们关联起来。然后，那些被识别出的人们的消息能通过使用这些密钥加以认证。

数字签字证件(有时称作公用密钥证件或简称证件)满足这种要求。这些证件一般由可信任的第三方发出，这些第三方被称作认证机构(CA)，它们证明(1)发出证件的认证机构已经识别出证件的主体(往往是根据证件实践声明中界定的说明)，(2)(在证件中)指定的公用密钥对应于由证件主体掌握的私人密钥。公用密钥证件的一种结构被包括在前文引述的X.509标准中。证件的内容往往在法规或规则中指定。典型的X.509证件有图1所示格式。

为了保证其后能核实一证件的可信性，其认证机构在发出证件时对其数字签字。通过参考一公用密钥(认证机构的公用密钥)能核实发出证件的认证机构的数字签字，该公用密钥与一第二认证机构向这第一认证机构发出的另一证件中的认证机构相关联。这另一认证机构的数字签字能由又一个证件中所列的一个公用密钥来核实，如此下去，沿着一个证件链，直至达到所谓根的或原始的认证机构，它的公用密钥被广泛而且可靠地分发出去。为了最大限度地保证在一个事务中所信赖的证件的可信性，信赖方必须使用传统方法核实这链中的每个证件。这认证链的一例示于图2，这里的根认证机构向认证机构CA-1发出一个证件，认证机构CA-1依次证明认证机构CA-2和CA-5。认证机构CA-2证明CA-3，CA-3证明CA-4，CA-4证明客户1。认证机构CA-5证明客户2。

大多数合法系统把一证件看作是按照发证件的认证机构与客户之间的合同所造成的表现、发现或结论，该客户即是在该证件中标识出的持有证件中所列公用密钥所对应的私人密钥的那个人。客户之外的其他人可以信赖该证件。该认证机构的那些与信赖方有关的职责可以来源于管制那些体现或不实声明的规则、把信赖方作为认证机构和客户之间合同的第三受益方对待的规则、管制数字签字的法规、或者上述所有规则的混合，或许还有其他法定原则。

一方信赖于一证件的权利往往是有限的。例如，在适用于该体现的法律中，通常要求信赖是合理的。再有，对某些证件的信赖本身被指定为不可靠的。一条亮线把某些类显然不可靠的证件与其他证件区分开，而信赖方要自己承担信赖它们的危险，不能因证件的缺陷而归因于发证件的认证机构或客户。本身不可靠的证件通常称作无效证件，可能包括具有下列情况的任何证件：

(1)已经过期(即信赖时间迟于证件中规定的过期日期)；

(2)已被吊销(即已报发此证件的认证机构声明为永久无效的)；以及

(3)在信赖时已被暂停的(即已被发此证件的认证机构声明为暂时无效的)。

此外，当未被其客户接受或尚未被一认证机构发出的证件不应被认为已经生效，而是可以或许不那么确切地认为是无效的。

吊销和/或暂停证件是最大限度减小由于认证机构或客户造成的错误后果的重要手段。根据可应用的法律规则，认证机构可以通过吊销证件来避免由于证件中的不准确性造成的进一步损失。客户可以吊销一个证件来防止信赖使用受危害的私人密钥(例如丢失的或被偷的私人密钥)造成的伪造数字签字。根据ITU X.509，那些由于吊销而变为无效的证件一般被列入证件吊销清单(CRL)。在ITUX.509中未考虑暂停或暂时无效，所以暂停或暂时无效的情况可能被包括在CRL中也可能未被包括。由于时效使其变为无效的证件无需列入CRL，因为每个证件包含它自己的过期日期。

在实践中，传统的基于CRL的系统按如下方式工作：在一客户能造成一个可核实的数字签字之前，该客户必须作出安排，使一个认证机构发出一个能以客户的公用密钥来标识该客户的证件。该客户收回并接受这被发出的证件，然后造成数字签字，并把该证件的拷贝附着在每个数字签字上。当一个事务的另一方收到这种数字签字时，这另一方必须与认证机构核对，一般是通过在线数据库，以确定该证件当前是否有效。如果有效，而且该数字签字能被证件中的公用密钥核实，则这另一方通常能以强有力的位置信赖这数字签字。

2.2数字签字认证传统途径的问题

前文概述的并在标准X.509、ABA指南、犹他法案及类似报告中预见的系统有若干缺陷，包括：

对风险管理的支持甚少：传统系统提供很少的便利条件和机会使认证机构能管理认证风险，认证机构得不到关于何时有任何人信赖该认证机构已发出的一个证件或任何人对它已发出的任何证件信赖程度的信息。认证机构还没有办法监视未完成的证件、查明是否发生了问题、评估影响错误认证风险的因素或证件机构应谨慎承担的风险的影响范围。再有，传统系统提供很少的便利条件帮助客户和信赖方处置它们的风险，包括保持私人密钥安全性的风险。

对信赖方的服务不够：在很大程度上，是信赖方，而不是客户，要承受事务中的欺诈和伪造的风险。如果一个文件是伪造的，或被欺诈性地改换了，那么信赖方将承受后果，根据大多数州(state)的法律，该消息是作为无效消息对待的。虽然信赖方对事务中信息安全性有最急切的兴趣，但认证机构的服务合同完全是针对客户的。在欺诈或伪造的情况中，客户甚至可以是犯罪人。这样，在发生问题时传统系统让认证机构去对付比较不重要的各方或者甚至是犯罪者，但却与主要承受损失的一方无任何接触。事情的这种状态使认证机构面对与信赖方有关的信任风险，并使认证机构放弃服务于信赖方的商业机会。除了只针对客户，数字签字基础结构还需要一种方式去针对信赖方。

将费用在前端加于客户：由于认证机构的合同只是与客户而不与信赖方，所以认证机构别无选择地要从客户那里收回全部费用和利润，尽管如前所述，信赖方对签字信息的安全性有主要兴趣。

缺乏耐用性：因为传统系统不能解决风险管理问题和满足信赖方的需求，所以认证机构一直是要狭窄地解释他们的作用。例如，一个认证机构可能承诺机械地查看表面看来是驾驶员的人的执照，或者按面值接受一个公证过的认证申请，但没有有目的地努力去为真正的商务需求提供认证服务，这种服务是要保证各方对事务的期望。对于认证的这种机械的途径限制了CA对电子商业事务进一步增大价值的潜力。一个更耐用的系统需要能服务于例如对授权、任命、法律实体的合法状态、以及信用等的证实。

发明概要

本发明通过在电子事务系统中提供一个信赖服务器来解决上述和其他问题，该信赖服务器是一个信息处理系统，它包括下列特点中的一些或全部：

(1)与信赖方的合同，这信赖方是接收和可能信赖客户数字签字的一方，该合同要按信赖方的要求完成服务。

(2)自动按信赖方的要求完成服务，这些服务可以包括证明客户证件的有效性和可信性，和以按信赖方需求特别的次级证件形式提供那个证件准确性和可信性的附加保证。次级证件是以另一证件以及或许由信赖服务器收集和维持的其他信息为依据自动发出的一个证件。

(3)监视系统本身及认证机构面对有效证件的范围，其作法是保持应信赖方请求所完成服务的记录。

(4)限制和处置系统本身及认证机构遭致的认证风险，其作法是按照与认证机构合作建立的某些判据来评估信赖方的请求。

(5)向客户通告对客户证件的信赖情况以及这种信赖的范围和由信赖服务器发出的保证的数量。经常向客户报告使客户能发现问题，从而分担及时采取补救行动的责任。

(6)向保险商通告其担保承诺的范围，作法是把该保险商包括在响应信赖方请求的信息管道中。

如这里所使用的那样，术语“方”一般是指一个电子装置或机制，而术语“消息”一般是指代表一数字化消息的电子信号。术语“方”和“消息”用于简化对本发明的描述和解释。术语“机制”在这里用于代表硬件、软件或它们的任何组合。这里所描述的机制和服务器可在标准的通用计算机上实现，或者它们可作为专用设备实现。

本发明是在电子事务系统中管理信赖的方法。本方法包括一个认证机构向客户发出原始证件，并从认证机构向信赖服务器传送关于所发出的原始证件的信息。信赖服务器保持被传送的关于所发出的原始证件的信息。客户造成一个事务，然后把该事务提供给信赖方，该事务包括由认证机构发出的原始证件或该证件的一个标识。信赖方评估由客户发送的事务，并确定是否需要对原始证件可信性的某种保证，以便“安全地”继续该事务。如果信赖方确定需要保证，它向信赖服务器发出一个请求，请求根据从签字方收到的事务提供特定量的保证。然后，信赖服务器确定是否提供所请求的保证。信赖服务器根据下列信息作出它的决定：所请求的保证，关于从认证机构收到的所发出的原始证件的保证参数，已经向请求信赖方发出的关于为这一证件及其他证件保证的历史信息，以及任何其他可能得到的信息。信赖服务器根据其决定，向信赖方发出次级证件，向信赖方提供保证。

在最佳实施例中，原始证件是一个有预定格式的数字签字电子文件，在该文件中，认证机构为客户在事务中将与之交往的信赖方作出所要的说明。这一原始证件可以是而且在许多场合是在先前引述的标准中定义的X.509证件。或者，该原始证件可以是这样的证件，它作出对该代理机构或对一特定个人或组织或提供付款承诺之人的任命的表现。

在某些情况下，原始证件指定信赖限度，而从认证机构向信赖方传送的信息包括保证参数，这些保证参数控制信赖服务器是否能根据原始文件提供保证。

在某些情况下，保证参数包括超出原始证件中指定信赖限度之外的可接受的信赖限度。而保证请求是请求对超出指定信赖限度的一个值的信赖。在那些情况下，信赖服务器通过确定所请求的信赖是否超出可接受信赖限度来决定是否提供所请求的保证。

在最佳实施例中，该方法还包括信赖服务器追踪与原始证件相关联的累积义务并确定所请求的保证是否会造成累积义务超出可接受的信赖限度。

在某些情况下，所请求的保证是关于另一证件的准确性，在这种情况下，该方法包括由信赖服务器检验其他证件的当前有效性和可信性，然后发出次级证件以证明其他证件的准确性。有效性检验包括沿证件链核实这其他证件的数字签字，并检验所请求的保证是否在保证参数中。

在某些情况下，所请求的保证是关于另一证件的可信性，在这种情况下，该方法包括由信赖服务器检验这其他证件的可信性，并发出次级证件保证这其他证件的可信性。这种检验包括沿证件链核实这其他证件的数字签字，并检验所请求的保证是否在保证参数中。

在某些情况下，所请求的保证是关于另一证件的有效性，此时信赖服务器检验该其他证件的当前有效性；并发出次级证件保证这其他证件的有效性。这种检验包括确定这其他证件是否已被暂停、吊销或已经过期，并检验所请求的保证是否在保持参数中。

在某些情况下，所请求的保证是关于一代理人机构的保证，在这种情况下，该方法包括由信赖服务器返回一个封有保证可信性的次级证明的代理机构文件。该代理机构文件包括一份委托书。

在某些情况下，所请求的保证是关于某人任命的保证，在这种情况下，信赖服务器返回一个由关于此人任命的持证单位或专业单位提供的声明，并带有封装用次级证件以证明该声明的可信性。

在某些情况下，所请求的保证是关于实体的存在和/或良好状态的保证，在这种情况下，信赖服务器返回一个接纳该实体的公共办公室提供的指明该实体存在、处于良好状态、并证明有资格从事业务的声明，这里的声明被封装到保证声明可信性的次级证件中。

在某些情况下，所请求的保证是关于一项契约的效能的保证，在这种情况下，信赖服务器发出一个效能保证声明，这里的声明被封装到保证声明可信性的次级证件中。

最好在信赖服务器发出次级证件之前信赖服务器和信赖方进入一个合同之中。这可以在信赖方作出请求之后进入该合同。

该事务可包括一个数字签字。

从认证机构向信赖服务器传送的保证参数可包括对一特定数字签字所能发出的最大限度补充保证。在某些情况下，保证参数包括至少下列各项之一：

1.在一个单一次级证件中能发出的最大限度补充保证；

2.能向任何特定信赖方发出的最大限度补充保证；

3.在一个或多个指定时间间隔期间能发出的最大限度补充保证；

4.对于该原始证件能发出的次级证件数量最大值；

5.一个次级证件可保持有效的最长时间段；

6.对于一指定事务类型有效的次级证件中所能列举的最大信赖限度；

7.为了对补充保证提供依据，由信赖方随其请求必须提交的特定信息；

8.由客户已预付款的补充保证量以及关于如何在次级证件中发出该预付款保证的约束条件；

9.对于要向信赖方发出的一个次级证件，在信赖方对次级证件的请求能被允许之前，要求客户同意由信赖服务器发出补充保证；

10.使信赖服务器向认证机构发送一报告的触发阈值；

11.每经过多长时间该信赖服务器应向认证机构报告对该原始证件发出的补充证明的范围；

12.限制向指定各方公开或访问该原始证件的约束条件；

13.该事务应由客户以外的附加方签字的要求，并可选地指定这些附加方是谁以及他们有多少必须签字；

14.基于签字的附加方数量及标识，所能发出的补充保证的量标度；

15.关于该原始证件有效性的信息。

任何保证参数都能被限定在一特定时间段内，包括原始证件有效的整个时间段。

在另一方面，本发明是一个电子事务系统，它包括一个认证机构和一个能与该认证机构相连的信赖服务器。认证机构向该系统的客户们发出原始证件。信赖服务器从认证机构得到关于该认证机构所发原始证件的信息。该信赖服务器根据来自信赖方的请求向信赖方发出次级证件，该发送是根据认证机构提供的信息以及由信赖方提供的信息。

在一些实施例中，至少一个其他方可与该信赖服务器连接，而信赖服务器在向信赖方发出次级证件之前先把该次级证件提供给这其他方。

最好是信赖服务器在把次级证件发给信赖方之前先对该次级证件签字。

在又一方面中，本发明是在一电子事务系统中自动替换一客户证件的方法，在该系统中一认证机构向客户发出数字证件。该方法包括：客户造成一个认证一对新密钥的备用申请，用一私人密钥对该备用申请数字签字，然后毁掉该私人密钥。然后客户把对应于该私人密钥的公用密钥包括在只对这备用申请有效的一个事务证件中，并把该事务证件发送到该认证机构。该认证机构保持这事务证件。其后，客户把这备用申请发给该认证机构，该认证机构参考事务证件以核实申请上的数字签字，然后发出一个新的基于时间的证件，其中列出在备用申请中指出的公用密钥。

如本发明的另一实施例中所预见的那样，希望核实一基于证明的数字事务的人产生一个信赖检验消息，其中包括与该事务关联的证件和该事务相关部分的副本(至少包括该事务中被编码的货币值)。然后这信赖检验消息被发送给信赖服务器。信赖服务器一收到信赖检验消息便检验证件的有效性，并检验那些可能会指出受损害的信任装置的各种一致性问题。依赖服务器还能追踪每个认证机构而对风险的累积结果。如果信赖服务器确定该风险是可以接受的(根据信赖检验消息中的信息以及它已存储或得到的其他信息)，它便向信赖方返回一个数字签字的信赖服务器响应消息。

在另一实施例中，本发明是在一电子事务系统中处置信赖的方法，在该系统中客户有由认证机构发出的基于时间的数字证件。该方法包括：通过信赖方接收来自客户的事务，该事务包括关于该客户的至少一个基于时间的证件。信赖方根据来自该事务的证件信息造成一个消息，该消息指定信赖方欲信赖的事务量。然后，信赖方把该消息发送给一信赖服务器，请求对信赖方欲信赖的事务量的担保。然后，信赖方从信赖服务器收到一个响应该发送消息的凭证，然后根据该凭证中的信息继续与客户进行该事务。

在本发明的另一方面中，该方法包括：一信赖服务器接收来自一方的信赖请求消息，该消息指定该方欲信赖的事务量并请求对该事务量的保证，该消息包括从该事务中提取出的证件信息。信赖服务器决定是否为该事务量提供保证并向信赖方发送一个凭证，该凭证包括信赖服务器是否保证该事务量的指示。该决定包括确定该事务伴随的证件是否已被吊销或暂停。

该方法包括：从认证机构接收一个证件的实际信赖限度；存储这实际信赖限度；并确定所请求的量是否超过实际信赖限度。最好是该信赖服务器为认证机构保持一个累积可信度。

在另一方面，本发明包括：由认证机构向客户发出一个基于时间的证件，该证件指定一个已声明的信赖限度并向信赖服务器传送该证件的实际信赖限度，该实际信赖限度不同于所声明的信赖限度。

在另一一般方面，本发明是在电子事务系统中管理信赖的方法，在该系统中客户有数字证件。信赖方从客户那里收到一个事务，该事务包括关于该客户的至少一个证件。该信赖方根据来自该事务的证件信息创建一个消息，该消息指定事务的一个方面，即信赖方欲信赖的那个方面；然后，把该消息发送给一个信赖服务器，请求对信赖方欲信赖的事务方面提供保证。其后，信赖方收到一个来自信赖服务器的响应这发送消息步骤的回答收据；并根据回答收据中的信息继续与客户进行事务。

在一些情况中，客户证件有相关联的费用，而信赖服务器根据伴随该事务的证件费用定出它的服务费。这些费用包括使用费、担保费和查询费。

在一些情况中，当消息请求检验证件状态时，回答收据指出是否可接受这种证件状态检验。通常，收据指出信赖服务器是否保证信赖方欲信赖的事务方面。

在一些情况中，信赖方欲信赖的事务方面指定一个货币值，而收据指出信赖服务器是否担保那个货币值的事务。最好是信赖服务器使它的担保建立在该事务相关证件中指定的信息基础上。

在另一方面，本发明包括：由信赖服务器接收一个来自一方的消息，以此消息请求对事务一个方面的担保，该消息包括从这一事务中得出的证件信息；判定消息中信息的有效性，以确定是否提供对这一事务方面的担保；并向信赖方发出回答收据，该回答收据包括关于信赖服务器是否保证这一事务方面的指示。有效性判定包括确定该事务相关证件是否已被吊销或暂停。有时，在该消息中包括的证件信息包括该事务相关证件的唯一标识，而这种确定包括：在证件吊销清单上查找唯一证件标识。最好是根据先前得到的关于证件的信息来完成这一确定。

在某种情况中，请求担保的事务方面是一个货币信赖值，而且与该事务相关的至少一个证件指定一个货币限度，这种情况下的有效性判定包括：确定这一货币信赖值是否在该证件指定的货币限内。

这种确定还可以包括对该证件得到一个当前累积货币义务，然后确定货币信赖值和当前累积货币义务之和是否超过了指定的货币限度。根据这一确定，当前累积货币义务值被更新。

考虑下文中结合附图所作的详细描述，本发明的上述及其他目的和优点将是显而易见的，在这些附图中，参考字符在各图中代表相似部件，这些附图是：

图1显示典型X.509证件的格式；

图2显示典型的认证体系；

图3显示根据本发明第一实施例的电子事务系统的全貌；

图4和图5是根据图3的系统所用的数据结构；

图6显示根据本发明第二实施例的电子事务系统的全貌；

图7描述向图6所示系统的一个用户发出证件；

图8描述根据本发明由用户产生数字签字事务；

图9和图10是流程图，描述根据本发明的电子事务系统各方面的操作；

图11显示一X.509证件的格式，该证件包括一个信赖说明；以及

图12以图说明各种风险、时间和费用考虑。

当前最佳实施例详述

如前所述，这里术语“方”一般是指一个电子装置或机制，而术语“消息”一般是指代表一数字消息的电子信号。术语“方”和“消息”用于简化对本发明的描述和解释。如这里所用的那样，这里术语“机制”是用于代表硬件、软件或它们的任何组合。这里所描述的机制和服务器能在标准的通用计算机上实现，或者它们能作为专用设备实现。

1.最佳实施例

1.A  最佳实施例概述

参考图3描述根据本发明的一个最佳实施例的电子事务系统100。系统100包括一个认证机构机制102和信赖服务器104。客户机制106和信赖方机制108登记系统100(通过分别与认证机构机制102和信赖服务器104登记一起)，以便参加到该系统中。一旦进入系统100，便由认证机构机制102向客户机制106发出一个电子原始证件110。这个原始证件110识别出一个信赖服务器，而关于这一证件的信息被提供给证件110中识别出的信赖服务器。

一旦进入了，客户机制106便通过向一特定信赖方机制108发送包括签字信息114的电子事务112来与该信赖方进行事务处理。信赖方机制108确定它意欲/希望信赖的事务方面，并向证件110中标识出的信赖服务器104发出一电子信号，该信号代表一个请求次级证件的请求116。信赖服务器根据请求116中的信息、基于原始证件110的先前信息、以及先前由认证机构机制102得到的关于原始证件110的信息，确定是否向信赖方机制108发出次级证件118。

假定在本系统的实际应用中，将由各方双边地或多边地将合同送入系统，这些合同清楚地规定了所涉及各方的作用和责任。信赖服务器的关键功能之一是保证信赖方机制108已经通过送入所需合同而适当地被收入该系统。

与信赖方机制106的合同是使系统100的规则与风险分配可应用于信赖方的实际手段。尽管这里所描述的合同应该与出现的数字签字法律一致，但它即使在尚未专门为数字签字设计法律的法律系统中也提供了统一的边界范围的规范集。

下面更详细地描述每一方完成的处理过程以及它们各自的作用。

1.B 最佳实施例详述

1.B.1  认证机构向客户发出证件

认证机构机制102向客户机制106发出一原始证件110。原始证件是有预定格式的经数字签字的电子文件，在这原始证件中，认证机构作出客户将与其执行事务的信赖方所期望的表述。这个原始证件可以是，而且在许多情况下是，先前引述的标准中规定的X.509证件。或者，该原始证件可以是对一特定个人或组织的代理或任命的表述，或对提供付款承诺人的表述。

标准X.509描述的形式要求证件包括标识客户机制106的信息、陈述客户公用密钥的信息，以及唯一标识该证件的信息。在本实施例中，证件由发出者的标识及唯一针对该发出者的序列号的组合来唯一地标识。在一个X.509证件中，序列号域把一给定证件与这同一认证机构机制102发出的所有其他证件区别开。于是，该序列号是唯一的，并且在由一特定认证机构机制102发出的证件当中绝不会重复。由于一认证机构机制102具有与众不同的(或唯一的)名字，所以发证的认证机构的与众不同的名字和该证件序列号的组合标识出该证件不同于来自任何或所有认证机构的所有其他证件。

在本实施例的一些应用中，为了要求信赖方在信赖该原始证件之前送入一个合同，该原始证件110可以是标准X.509形式，只是它的公用密钥域是空的，而且算法标识指出一个系统，该系统只信赖由信赖服务器104直接发出的证件。或者，在证件中的某些数据可以被加密，而算法标识指示一个系统，该系统能处理和去掉加密，以使被加密的数据可用。

此外，根据犹他法案以及可能还有其他法规和规则，证件110能列出一个货币量，这在犹他法案中被称作“信赖限”，它是根据安全程度和支持该证件的调查结果，由发证的认证机构机制102给出的一个定量声明，声明给出无需进一步调查而在任何给定事务中对该证件合理信赖的最大限度。

在本最佳实施例中，提供要进入认证机构发出的原始证件的货币量，其目的类似于犹他法案的依赖限所表明的目的，然而，那个量在本实施例中被称作原始保证限。

在本最佳实施例中，每个发出证件的原始保证限被设定为一个量，这个量是认证机构机制102根据它在识别客户机制106时搜集的信息，考虑它面对原始证件110的风险，从而认为可接受的量。如果一信赖方机制108从客户机制106收到签字的信息114(包括证件110)，而且该信赖方机制108希望得到比原始证件110中声明的原始保证限更大的保证，那么该信赖方必须向那原始证件110所关联的信赖服务器104请求一次级证件114。这次级证件114通常声明一个高于它所依据的原始证件110的保证限。为承担较高保证限的这一次级证件114所进行的风险管理和质量保证引起额外费用，或者是客户机制106，或者是信赖方机制108，或者是这二者可最终承担那些费用。

认证机构机制102可在证件110中设置一个低的原始保证限，以使那些潜在的信赖方必须向证件110中指定的信赖服务器104申请，以得到次级证件114形式的补充保证，次级证件114声明的保证限大于原始保证限。

1.B.2  认证机构向信赖服务器发送公开证明消息

当认证机构机制102向一客户机制106发出原始证件110时，它还向将要根据原始证件110发出次级证件118的信赖服务器104发送一个公开证明消息。该公开证明消息120包括原始证件110和补充保证(信赖)参数122。多重信赖服务器104可以在市场中或类似经济中做业务，而认证机构机制102选来用于公布一个证件的信赖服务器104通常取决于谈判、签合同和类似的市场动力学。

在公开认证消息120中伴随原始证件110的补充保证参数122包括：

1.能由信赖服务器104根据原始证件110发出的最大限度补充保证，这是在原始证件有效期上的累积结果。(换句话说，这个量是由信赖服务器根据原始证件110在其有效期(即只要它没被吊销或暂停)发出的所有次级证件的全部保证限的总和)。

2.对特定数字签字(如在签字信息114中记录的)所能发出的最大限度补充保证。

3.在一个单个次级证件118中能发出的最大限度补充保证。

4.在一个时间段期间能向任何特定信赖方机制108发出的最大限度补充保证，该时间段可以是原始证件110有效的整个时间段。

5.在一个或多个指定时间间隔，诸如秒、分、日、周、月或年，期间能发出的最大限度补充保证。

6.在一个时间段期间对于原始证件110能发出的次级证件118的最大数量，该时间段可以是原始证件110有效的整个时间段。

7.一个次级证件118可以保持有效的最大时间段。

8.能在一次级证件118中列出的对一指定事务类型有效的最大保证限。

9.按照认证机构机制102和信赖服务器104之间的合同，该公开认证机构机制有资格声明的任何价格限制因子。

10.为了限制要发出的补充保证或为其提供基础，由信赖方机制108必须与其请求次级证件118的请求一起提交的特定信息。这种信息可能包括：已被承诺给信赖方的特定类型证件，为其中出现签字信息114的文件所用的事务类型的说明，第二个签字(诸如由承认、担保、或者以一定限制会签信赖方请求的人所做的签字)，以及类似的相关信息。

11.客户机制106已经预付的补充保证量，以及如何能根据本清单中任何其他参数在次级证件118中发出那个预付保证的约束条件。

12.在信赖方的请求次级证件118的请求能被允许之前，客户机制106同意由信赖服务器104为要发给信赖方机制108的次级证件118发出补充保证所需要的任何要求。

13.触发从信赖服务器104向认证机构机制102发出一个报告的保证阈值(一种状态达到的点，它大于或小于一特定参数、参数百分数、或特定的参数水平)。这些阈值应用于上述参数的任何一个或全部，它们能被独立地陈述，或者联系和/或依赖其他参数阈值来陈述。例如，当已发出对原始证件110最大限度保证的80％时，一个阈值可能要求一个报告。另一个例子是，当在一给定日已发出最大累积保证的50％而且该保证的90％已发给一特定信赖方机制108时，一个阈值可能要求一个报告。

14.每经过多长时间该信赖服务器104应向认证机构机制102报告关于对原始证件110发出的补充保证达到的程度。

15.对于指定人员限制其公布或访问原始证件110(或其拷贝，或关于它的信息或从中导出的信息，包括关于它的存在和有效性的报告)的约束条件(这些人员在被允许公布或访问原始证件110之前最终必须被可靠地识别)。

16.已签字信息114应由客户机制106之外的附加方签字的要求，并可选地指定这些附加方是谁，以及他们有多少必须签字(即可以允许一个有较多方的法定数)。可选地，还有基于签字的附加方的数量及标识所能发出的补充保证的量标度。例如，如果只有一个签字方机制106签字，则每个事务的补充保证最大值为$125，然而，如果还有一个管理人和两个其他人签字，则每个事务的补充保证最大值为$1250。

17.关于原始证件110有效性的信息，证件本身指定它的失效日期，然而，认证机构机制102通知信赖服务器104关于它与客户机制106所作的对要公布的原始证件暂停、吊销和恢复的安排。

18.根据原始证件110向信赖方机制108发出次级证件118或提供补充保证所应满足的干何其他限制或先决条件。

上述说明依赖于认证机构机制102和信赖服务器104之间的合同中做成的使能条款。

认证机构机制102能通过向公布证件110的信赖服务器104发送一个修补的公开证件消息120来修补所使用的补充保证参数122。这修补公开证件消息120只包含补充保证参数122，包括被更新的原始证件110和新的补充保证参数122。

1.B.3  信赖服务器处理公开证件消息

当信赖服务器104从一认证机构机制102收到一公开证件消息120时，它首先检验公开证件消息120上的数字签字以及所包含的原始证件110。如果信赖服务器104核实了签字(即如果签字有效)，它存储该公开证件消息120用于存档和非拒绝目的，然后从公开证件消息120中提取信息。所提取的信息包括原始证件110和补充保证参数122。然后信赖服务器104检验针对待检验认证机构机制102(即发出原始证件110的认证机构机制102)发出的原始证件所能应用的补充保证参数的任何说明的信息，并以易于提取的方式存储这新证件及其补充保证参数。该信息被信赖服务器104电子存储于证件有效性数据库，从而可由图4所示服务器访问。该信息的存储方式使得在给定原始证件110标识时信赖服务器104能容易地确定可应用于根据原始证件发出的或将要发出的次级证件的补充保证参数122。

对于每个原始证件110，证件有效性数据库包括它的有效性状态(有效、被吊销、过期或被暂停)，根据原始证件可应用于次级证件的补充保证参数122，以及与账户历史和周期性报告信息的链接。(请注意，由于每个原始证件110指定了它的生命区间，所以过期状态不是必须的。然而，指定过期状态免除了检验实际证件的需要。)

1.B.3.1  客户登记和初始认证概要

在系统100中，认证机构机制102送入与未来客户机制106的合同、收集要在证件中列出的信息以及获取和保存报告认证机构责任满意程度的证据以便确认那消息的准确性，通过这些作法，认证机构机制102发出一个初始原始证件110(它开始一个新的账户以证明一个客户的可信性)。然后，认证机构机制102通常把对初始证件110的保证限制在零或一低水平，并安排由要发出的次级证件在其后达到指定的保证限。然后认证机构机制102把证件110呈送给客户机制106，以确定如果把证件110发出去的话它是否可被接受，然后把它送到认证机构机制102内部的管理以取得认可。一旦发送被认可，认证机构机制102便以预定形式创建该证件，并对它数字签字，这经常使用一个高度安全的分布式私人密钥。在此基础上，认证机构机制102向一信赖服务器104发布该证件(如果与客户机制106的合同已为发布作了准备的话)。然后客户机制106与信赖服务器104连接，最终接受该证件，而信赖服务器104使证件110在线可得。

1.B.3.2  暂停处理

认证机构机制102接收和登录暂停请求，记录下请求者标识，请求者与客户机制106的关系(如果请求者不是该客户的话)，请求的日期和时间，支持该请求的理由或事实，和任何其他相关信息，以及请求暂停的持续时间。认证机构机制没有责任去确认由请求提供的信息的准确性；然而，如果客户机制106和认证机构机制102之间的合同允许的话，在看来是恶作剧或骗局的情况下，该核实者可以调查、抑制或限制暂停。

认证机构机制102产生和发布一个暂停通告126，并以证件中所列信赖服务器104作为公布暂停或吊销通告的发布地。

信赖服务器104更新证件状态数据库，以指明暂停及其持续时间。如果已有一个暂停在生效，信赖服务器104改变证件状态数据库，以反映最新通告上的信息。

信赖服务器104总是向发出所考虑的证件的认证机构机制102报告每个暂停和与暂停有关的每个看来不正常或不规则的情况。

认证机构机制102更新它的记录，以包括发出的通告和从信赖服务器104返回的认可。

当任何指定的暂停持续时间过去时，暂停自动结束。不确定时间段的暂停防止信赖方关闭或继续进行事务，即使它的依据缺乏确认。认证机构机制102和客户机制106之间的合同一般应阻止由未确认的请求提出的不确定时间段暂停。要在有效通告中指定的结束时间之前结束一个暂停，认证机构机制102遵循与建立暂停类似的过程；认证机构机制102接收并登录一个请求，并通知信赖服务器104，它更新证件状态数据库。

1.B.3.3  吊销处理

收到吊销通告的信赖服务器104更新证件状态数据库以指出该证件被吊销，并向公布认证机构机制102返回一个认可和报告。如果信赖服务器104收到重复的或后来的吊销通告，则登录这第二个请求但在证件状态数据库中不做任何其他改变，并返回一出错消息。信赖服务器总是向发出所考虑的证件的认证机构机制102报告每个吊销和与吊销有关的每个看来不正常或不规则的情况。

如果能得到备用证件申请(下文描述)，而且该申请被安全地保持着，那么上文解释的吊销处理能自动完成，无需牺牲文件或“短路”认证机构的责任以认证吊销请求。一旦根据备用申请发出了一个新的证件，客户机制106能发出一个数字签字的吊销请求，而且能通过对照根据备用申请新发出的证件来确认它的数字签字。这种吊销请求能被自动处理，然而，如果客户机制106不能通过备用申请处理被再证实，或者如果由于任何原因使客户机制106没有剩余能力去建立可由有效证件核实的数字签字，那么认证机构机制102就必须使用数字签字以外的其他手段来确认吊销请求，这类手段通常必须伴有人工处理过程来完成上文概述的步骤。

1.B.4  客户与信赖方执行事务

客户机制106通过构成事务112来完成与一信赖方机制108的事务。通过客户机制106数字签字一个文件，例如合同、信件、购贷订单等，来构成一个事务。有若干…。事务112包括一个数据结构，称作签字信息114，它含有签字及关于它的最后认证的信息。在数字签字该文件并把所造成的签字信息数据结构114附加到签字的文件上之后，客户机构106把结果事务112(文件及其签字信息数据结构114)发送给信赖方机制108。签字信息114包括由认证机构机制102向客户机制106发出的原始证件110。客户机制106可以把下述任何内容包括在签字信息114中或附加到由签字信息114上：

1.签字标识，它唯一地标识签字信息114中包含的数字签字以区别于任何非本客户机制106的签字信息。

2.对于签字信息114内的数字签字或由它认证的事务112，该客户机制106允许发出的补充保证最大量。

3.对于这一签字信息114，允许(或不允许)请求补充保证的信赖方108清单。

4.对于这一签字信息114，能够(或不能够)请求已由客户机制106预付款的补充保证的信赖方108清单。

5.对于这一签字信息114，能发出的次级证件118数量和/或补充保证范围的限度。

6.付款通知，指出对于签字信息114客户机制106将为任何或特定信赖方所需要的补充保证付款。

7.关于对数字签字的信赖受合同约束的声明，包括一个指定的认证实践声明，它要求信赖方机制108至少要核对证件110中指定信赖服务器104的记录中该证件的当前有效性。

客户机制106能使用上述签字参数的任何组合来限制信赖方机制108和/或发出次级证件118的信赖服务器104的可选项。

1.B.5  信赖方检验签字的信息

在确定是否信赖能由一证件保证的数字签字和任何其他项目时，接收数字签字文件(通过事务112)的信赖方106评估如果不得到进一步的保证便信赖该文件它所要承担的风险。所需要的保证程度可以在信赖方机制108的内部操作程序中规定，并根据风险研究来确定，该风险研究考虑了对经验的统计评估和对可预见的脆弱性的技术评价。

信赖方机制108可能很需要认证以使对在线事务的信赖造成可接受的风险。或者用于认证(数字签字)或者用于其他目的的一个或多个证件向信赖方机制108提供保证，并降低与诸如下列各项有关的风险：例如一个文件或事务是否是真实可信的，一个号称的代理人实际上是否有权利为其他人采取行动，以及如果在事务中承责了一种责任，那么值得信赖方(例如认证机构机制102)是否将保证付款或实施。

在从客户机制106收到包括签字信息的事务112之后，信赖方机制108立即对它进行检验，以确定该事务的性质和它必须放在该签字信息上的信任量。虽然签字的信息114和/或签字的文件可能被加密，但假定它们都是为信赖方机制108准备的，并假定信赖方能对其解密或以某种方式使用该文件。还有可能信赖方机制108在必要时能对原始证件110的部分或全部解密，如果认证机构机制102是以加密形式发出这原始证件110的话。假定由信赖方机制108适当地访问和解密事务112，则在任何给定的事务中可由信赖方得到的信息可以包括：

1.所收到的事务文件；

2.签字信息114数据结构及其内容，包括客户的数字签字和证件110；

3.代表在这一事件中客户机制106希望分配给信赖方机制108的最大补充保证量的货币量；

4.付款信息，指明客户机制106是否将为向信赖方机制108提供补充保证的次级证件118付款；

5.对于由信赖服务器104提供的服务，由签字方机制106所加的任何限制。这些限制包括列出哪些信赖方可能收到为事务112提供的次级证件；以及

6.附加信息，例如已由客户机制附加到内容信息和/或签字信息114上的参考、链接、或封装文件或数据。

信赖方机制108根据这一或其他可得到的信息确定是否向信赖服务器104请求含有补充保证的一个或多个次级证件118。这一补充保证告知该事务中的某些信赖方风险，并且是由信赖服务器104和/或认证机构机制102做出的约定，即它们将要承担所提供的补充(次级)保证范围内造成的任何损失。

如果信赖方机制108确定在原始证件110中声明的原始保证少于信赖方机制108所希望的保证，则信赖方机制108可向信赖服务器104请求补充保证。为此，信赖方机制108构成一个请求次级证件118的请求116，并把请求116发送给信赖服务器104。

由信赖方机制108发送给信赖服务器请求次级证件118借以得到补充保证的请求116有图5所示形式。该请求116包括含有客户公用密钥的原始证件110的标识。

在签字信息数据结构114中包括的原始证件110列出了一个信赖服务器104，从它那里能得到补充保证，而且关于暂停和/或吊销原始证件110的通告要发送到它那里。在信赖服务器110中的信赖服务器104列表可以是一实际地址，也可以是一代理服务器或指针，指向列出实际地址的一个网络地点。信赖方机制108可以向证件中列出的信赖服务器104请求补充保证，也可以与另一信赖服务器接触，这或许是该信赖方与之有现存关系的那个信赖服务器。请求次级证件118的请求含有一个域，其中可由信赖方指出要完成的查询范围。如果信赖方机制108向其发送请求116的信赖服务器104不能满足该请求，而且如果查询范围域允许(通过指出一个全局范围)，那个信赖服务器可以试图定位另一个能满足该请求的信赖服务器。如果范围域允许(即范围是全局的)而且如果该查询定位一个能满足该请求的信赖服务器，则初始的信赖服务器能把该请求传递给这另一个信赖服务器。另一方面，如果范围被设定为局部的，那么即使信赖服务器104不能满足该请求，它也不能把该请求传递给另一信赖服务器。

请求消息116还包括：

1.一个通告地址，这是关于该证件(由该消息指定)的任何警告应该发送的地点。这个地址应为电子地址(例如一个电子邮箱地址)或某种其他形式的地址；

2.签字的属性(签字信息数据结构114)；

以及

3.指定被请求保证类型的请求类型(下文描述)。

如果信赖方请求补充保证的请求被认可，则这一点在次级证件118中被说明。次级证件118是由一信赖服务器104或其他认证机构机制102发出并数字签字的一条消息。次级证件118能向一事务证明或保证任何事实、状态、或契约材料，包括：

1.另一证件的准确性，例如用一个公用密钥标识某人的可信性证件的准确性。

2.另一证件的可信性，这是通过证实这样的事实给出的，即对其他证件的数字签字已通过查看止于根证明者的证书链而得到核实。

3.另一证件的有效性，这是通过确定(如果可能的话，而且除了其他事项外)吊销或暂停通告应发往哪里并核实该地点来给出的。

4.按规定的认证原则向指定代理人发出的认可。

5.通过发许可证或由专业团体对某人的任命。

6.关于某人的存在和/或良好状态，该人是一个法律上的或人为的实体。

7.一个契约的性能。(这类证件是对性能的保证或者是保证付款或满足契约的信用信件)。

次级证件118的有效性通常受到与指定时间和一般可达到的指定量有关的限制，而且还可以限定于指定的信赖方机制108、数字签字或事务，指定的EDI事务类型或事务集合，或者根据信赖服务器104和信赖方机制108所同意的其他标准。如果提供补充证明会限制客户机制106得到进一步的补充保证，则客户还可以限制在给定事务中提供的次级保证量。由客户机制106在签署文件时建立的(并作为“签字的属性”纳入一请求消息116的)签字信息数据结构114包括若干个由客户机制106数字签字的域，并把该事务可得到的补充保证限制于一指定的最大保证限。信赖方机制108在请求补充保证时指定一个希望量和一个最小可接受量，如果这个希望量小于由客户机制106指定的最大值，则信赖服务器104按此希望量提供补充保证，如果这个希望量不小于由客户机制106指定的最大值，但如果由客户机制106指定的最大值超过由信赖方指出的最小可接受量，则信赖服务器104按这个由客户机制106指定的最大值提供补充保证。如果由客户机制106指定的最大值小于信赖方机制108可接受的最小量，则信赖服务器104返回一个出错消息，请信赖方与客户机制106处理这一问题。

1.B.6  信赖服务器处理信赖方的请求

一旦收到关于次级证件118的请求，信赖服务器104检验是否通过使用链接于具体合同形式和信赖方赞同该合同的事件的公用密钥来核实信赖方的数字签字从而使信赖方机制108已经被收入系统。如果不能找到信赖方被收入的记录，那么信赖服务器为信赖方提供一个合同，如果信赖方接受它，则为信赖方建立一个证件，它把该合同与一公用密钥链接。所得到的关于信赖方身份的信息都是未经证实的，并按原样保存。

如果信赖方被收入了信赖服务器104，则信赖服务器根据信赖方请求什么而完成下述工作，从而满足信赖方的请求：

1.B.6.1  信赖方请求对另一证件准确性的保证

如果信赖方机制108请求对另一证件准确性的保证，则信赖服务器104检验该证件的有效性及其可信性(通过沿一证件链核实其数字签字)，并检验所请求的保证是否在次级保证参数之内。如果根据有效性、可信性和次级保证参数，能提供进一步的保证，则信赖服务器104发出一次级证件118，确认这指定证件的准确性。

1.B.6.2信赖方请求对另一证件可信性的保证

如果信赖方机制108请求对另一证件可信性的保证，则信赖服务器通过参考另一证件中所列公用密钥来核实该证件的数字签字，然后核实在那个其他证件上的数字签字。这一过程沿一证件链重复进行，直至由一根证明者(认证机构，例如见图2中的根CA)发出的那个证件为止。信赖服务器104还检验每一个这类证件以确定它是否有效。如果通过参考在有效证件中的公用密钥而核实了所有数字签字，则信赖服务器发出一次级证件118，确认这另一证件的可信性。

1.B.6.3  信赖方请求对另一证件有效性的保证

如果信赖方机制108请求对另一证件有效性的保证，则信赖服务器由此证件确定其有效性信息被送到哪里。如果该信赖服务器104是有效性信息所在地，它便检验其证件有效性数据库。如果该数据库指出，该证件已由认证机构机制102发出，由它的客户机制106接受，但未被暂停、吊销或过期，则信赖服务器发出次级证件118，确认该证件的当前有效性。

1.B.6.4  信赖方请求对一代理人代理权的保证

如果信赖方机制108请求对一代理人代理权的保证，则信赖服务器104返回该代理人的授权书或类似的许可证或文件，并带有封装的次级证件以保证其可信性。

1.B.6.5  信赖方请求对某人任命的保证

如果信赖方机制108请求对某人任命的保证，则信赖服务器104返回一个由一发证单位或专业单位提供的关于某人任命的声明，并带有封装的次级证件以保证该声明的可信性。该任命声明可以是一认证机构公开记录，例如在犹他法案及基于它的行政法规中描述的那样。

1.B.6.6  信赖方请求对实体存在和/或良好状态的保证

如果信赖方机制108请求对一法律的或人为的实体的存在和/或良好状态的保证，则信赖服务器104返回一个由包含或创建该实体的公共办公室发出的声明，以指出该实体存在，处于良好状态，和/或有资格进行业务活动。该声明被封装在保证该声明可信性的次级证件118中。

1.B.6.7  信赖方请求对契约执行的保证

如果信赖方机制108请求对一契约执行的保证，则信赖服务器104发出一个信用信，或其他付款担保或保证，如果该信用可以得到而且已与客户机制106做出了适当安排的话。

信赖服务器104根据先前规定的标准，自动地完成上述行动，包括发出次级证件118。

除了系统失效或停机时间外，还会由于多种原因使上述行动的执行失败。如果可能的话，当一请求未能被满足时，信赖服务器104向信赖方机制108返回一出错消息，例如：

证件过期

根据证件自己的过期域内容确定该证件已过期。

证件被吊销

吊销通告已发送到证件中指定的地点，或者由请求的查询发现了该通告。该消息中包括吊销日期。

证件被暂停

暂停通告已发送到证件中指定的地点，或者由请求的查询发现了该通告。还提供关于暂停持续时间、暂停的依据或原因以及触发暂停的事件等的有关信息，如果这些信息能得到的话。

查询失败

该证件不能被找到。

发现多个证件

找到了由相同的被认为是唯一的标识所识别出的两个证件。这一错误表明信赖服务器系统中的一个缺陷。

为了签署和发出次级证件118，信赖服务器104可能把它(作为中间事务证件)发送给某些其他方124a-124n，或许包括下述任何方：

a.担保人机制124a，它保证或者协助承担认证风险；以及

b.故障保护数据库，它是信赖服务器数据库的原样复制品，它保证能检测到对信赖服务器的任何破坏。

其他方124a-124n执行的功能造成次级证件118上的数字签字。一般地说，所用的签字技术是多步签字，它在授予Sudia的题为“多步数字签字方法和系统”的美国专利申请系列号08/462,430中公开和描述，该专利申请被这里完全引用作为参考。

1.B.7  信赖服务器保持事务历史

信赖服务器104和/或它的代理保持所发出的全部次级证件的历史。这一信息在确定证件使用中的异常和确定是否应发出次级证件或更新的证件方面是有用的。

1.B.8  信赖服务器给客户的帐户声明

客户帐户声明

当初始原始证件110或它的替代物之一有效时，被指定为该证件提供保证的信赖服务器104便周期性地向客户机制106发出账户状况电子报告。客户按客户希望的频度收到这些帐户状况报告，但最好是不少于每月一次。一个可选功能指定帐户状况更新间隔，从而每当客户机制106向信赖服务器104发送另一请求时，便有一更新报告提供给客户机制106。这一可选功能使得每当用户从发布证件的信赖服务器104得到其他信息时该信赖服务器便附加上一个帐户声明。这一信息包括例如关于另一人的证件当前有效性的报告，或者用于增加保证的次级证件。

帐户声明不需作为给客户机制106的单独消息，除非客户选择要在它们到达时作为这种单独消息来查看。相反，帐户声明更新在本地数据库中由客户机制106积累的信息。可以基于每个签字或时间顺序来存储和查看帐户声明中收到的信息，该时间顺序或者由创建相关数字签字的日期确定，或者由收到特定帐户声明的时间确定。

帐户声明向客户机制106报告如下信息：

1.客户(基于时间的)证件的有效性：列出全部(基于时间)发给该客户机制106的证件，从最近的证件开始，并指出哪个是当前有效的，何时无效证件被暂停或被吊销的，或者何时它们过期。

2.发出的次级证件：当信赖服务器104发出一次级证件时，信赖服务器104在下一次帐户声明中报告该次级证件的发出。该声明指出其细节，诸如量、请求次级证件人(如果被识别出的话)的名字、以及担保人名字，如果该次级证件包括补充保证的话。客户机制106能使用这一报告确定是否已发生了假冒，因为对保证的未预期的使用，特别是被陌生人使用，会在某些情况下表明已经造成了假冒的或至少是未预料的数字签字。在系统100中，数字签字被编号和打上时间记号，以便于客户回顾保证的使用。

3.保证平衡：帐户声明的保证部分指出可应用的保证限，以及关于每个限度已发出了多大保证。客户机制106把这一信息与已建立的数字签字关联起来，包括那些没有请求次级证件的数字签字。这种数字签字可能代表一种未完成的、未满足的对保证的需求，而客户机制106可能希望评估这种未满足的需求能否由剩余的保证来平衡。

4.保证终止：当一个保证担保过期或者在次级证件上填写权利要求的期限(如果有的话)已过，则原始证件的保证平衡便相应地增加。帐户声明反映那些增加并报告何时保证预计终止。

帐户声明还可以返回关于其他电子服务的信息，如其他帐户事务和平衡，以及关于其他金融和商业服务的信息。客户机制106累积周期性帐户声明中报告的所有信息，直至客户机制106删除或存档这些信息。

帐户声明回送给客户机制106那些为发现和解决问题所必须的信息，从而帮助管理接受认证和保证服务的风险。如果银行客户不能发现问题和采取有助于解决问题的正确行动，则其客户对银行的信任度便被降低。

事件追踪和帐户历史

除了返回给客户的帐户声明外，发出原始证件(包括初始原始证件)的认证机构机制102和根据这原始证件发出次级证件的信赖服务器104追踪该原始证件及其附属的次级证件的历史，并记下所发生的与其有关的事件。事件是指与初始证件的发出有关的事件或迟后收到的信息，它可能指出与该帐户或该原始证件有关的困难或问题，或者如果能得到进一步的信息的话，在某些场合证明是无害的。事件的严重性是各不相同的，取决于一个可能的问题能归因于它的程度。直接与认证其可信性有关的事件以及它们按1至5的标度给出的相对严重性包括：

1.被存疑的权利要求(级别5)：信赖方对基于次级证件的一个权利要求存疑，或根据系统100中发出的证件提出任何要求或发起诉讼。

2.欺诈的或类似的辩词(级别5)：在民事或刑事过程、仲裁、或其他争辩或调查中的一方辩言，称该客户机制106进行了任何显著形式的欺诈、误表现、或其他假声明。

3.请求暂停或吊销(级别1)：客户机制106请求认证机构机制102暂停一基于时间的证件。重复的暂停或吊销可能表明在维护私人密钥安全性方面缺乏所希望的注意。

帐户声明尽可能多地累积关于单个客户的认证信息。对于同一客户机制106在长时间里跨越不同认证机构和信赖服务器的多个原始证件及其它认证，收集其信息，还从信赖服务器和外部源(如法庭)得到信息。

发出原始证件的认证机构和信赖服务器二者都跟踪这一信息并交换事件报告消息以彼此更新，并在根认证机构指导下更新中央帐户历史数据库。信息被在线保持，并按照为系统100规定的帐户历史保留日程中的规定存档。

在信赖服务器104和认证机构机制102之间交换的信息包括：

1.证件吊销清单(CRL)128；

2.证件暂停或吊销通告126；

3.发出的证件清单130；

4.发出的保证报告132；

5.证件例外报告134；以及

6.超出保证报告136。

从它们当中累积或导出的事件报告和记录可以不向下列之外的任何人公开：以良好信誉向作为事件主体的客户机制106发出证件的认证机构机制102，这种认证机构的上级认证机构，在主体客户帐户上发出次级证件的信赖服务器104，以及根认证机构。此外，帐户历史信息受到法律数据保护要求的限制，这些要求可能进一步限制在某些法律系统中得到该信息或者要求向客户机制106公开帐户历史信息。

1.B.9  记帐和付款

上文描述的数字消息(事务112和请求116)包括价格和付款授权信息，这些信息使能根据各方之间的合同分配费用和付款。系统100在使费用传递给其他方和按他们可能的决定进行分配方面具有灵活性。特别是，由信赖服务器104发布证件或吊销通知的费用可由认证机构106或客户机制104支付，而次级证件费用可由客户机制106或信赖方机制108支付。通过请求信赖服务器104，信赖方和客户能自动得到价格表。

举例

例如，假定认证机构Cedric按照与Susan的合同中提供的名为Susan的客户发出了一个证件Cert-1。Cert-1规定它被用于“C类”信赖服务器系统，还规定它的公用密钥是被加密的。Cert-1规定的保证限为$0元；换句话说，对Cert-1不允许任何信赖。Cedric向客户Susan提供Cert-1的一个付本，她接受了它。由于从其$0元保证限的角度看，Cert-1本身是不可依赖的，它的实质用途是把信赖方引向一个信赖服务器。按照与Susan的合同所提供的，Cedric向Margaret公布Cert-1，这里Margaret是一个信赖服务器。

Margaret为Susan的证件建立一个新的认证帐户并在其证件有效性数据库中建立一个条目，并设置参数以控制根据Cedric提供的信息自动发出次级证件。然后Margaret向Susan发出一个初始消息，通知她已完成公布而且她能指望收到周期性的帐户声明。

Susan向Perry发出一个提议，要购买$10,000元的某种货物。Susan数字签字她的提议并附上Cert-1的无密钥版本付本。

为了确定Susan的提议是否是真实的，Perry运行一个核实功能，它报告该数字签字看来可由证件中的公用密钥核实，但该证件有$0元保证限而从Margaret可得到补充保证。Perry向Margaret发出一个请求，请求为该证件提供不少于$10,000元的补充保证。Margaret的系统以次级证件Cret-2回应，Cert-2封装了Cert-1并规定只关于Perry及其代理人以及只对Susan提议上的数字签字，在$10,000元这个限量之内，Cert-1的准确性和可靠性是受保证的。因为Susan没有授权从她的帐户为Cert-2付款，所以Perry为发出次级证件向Margaret付费。

为发出Perry收到的次级证件，Margaret系统分析他的请求，检验Cert-1的有效性，通过核实其数字签字以及沿着证件可信性链的其他数字签字来检验Cert-1的可信性，并按照为Susan的认证帐户指定的参数检验请求的补充保证量。在所有检验返回了肯定结果后，Margaret系统发出Cert-2。

如果Perry曾关注Susan代表某一他人做此提议的授权，或关注Susan为货品支付$10,000的能力，Perry能得到额外的补充保证。他会得到授权Susan做此提议的授权书，以及来自Margaret(如果Margaret不是银行的话，则从她的银行)的保证为此价格付款的信用信。当一数字签字被核实时，不需要请求补充证件。例如，在Perry向Susan发出由他数字签字的对Snsan提议的接受信之后，可以更及时地得到信用信。

1.B.10  暂停和吊销证件

暂停和吊销是一种手段，借这种手段，客户机制106和认证机构机制102能在一证件过期之前减轻它们自身对该证件的责任和风险。吊销永久地结束一证件的有效性，而暂停是暂时中断证件。当该证件无效时，客户机制106不承担保护私人密钥的法律责任，该证件中认证机构机制的代表性不再继续有效，而对该证件的信赖几乎肯定地说是没有理由的。

然而，暂停或吊销的通告一般不需要包括对客户机制106的识别，因为该证件能由它的序号来识别。在系统100中，在证件中指定的位置处的公告指向对一信赖服务器104的通告。哪个信赖服务器104接收和处理一个到来的通告，取决于证件中指定的暂停或吊销通告发送地。

1.B.11  暂停处理

每个信赖服务器104维护一个证件有效性数据库，最好是一个高速关系数据库，它累积从认证机构收到的所有暂停和吊销通告并能在线提供使用。用户可以人工浏览或查询证件状态数据库以查询一特定证件的暂停或吊销通告，但为了得到更高水平的效率和保证，用户能得到一证件指明没有暂停或吊销通告存档。换句话说，信赖服务器104将根据请求自动地以高速发出一个证件，肯定在某日某时由该信赖服务器104累积发布的通告不包括指定证件的吊销通告，以及肯定累积的通告不包括在那个日期和时间有效的暂停通告。

认证机构机制102接收和记录暂停请求，记下请求者的标识，请求者与客户机制106的关系(如果请求者不是客户的话)，请求的日期和时间，支持该请求的事实或理由和任何其他相关信息，以及所请求暂停的持续时间。认证机构机制102没有任何责任去确认请求中提供的任何信息的准确性；然而，如果客户106和认证机构机制102之间的合同允许的话，该认证人可以在看来是恶作剧或欺诈的情况下去调查、抑制或限制暂停。

认证机构机制102以证件中列出的信赖服务器104产生和公布暂停通告126，该信赖服务器104是暂停或吊销通告将被发出的地方。

信赖服务器104更新证件状态数据库以指出该暂停及其持续时间。如果一个暂停已经生效，则信赖服务器104警告证件状态数据库去反映最新通告上的信息。

信赖服务器104总是向发出所考虑证件的认证机构机制102报告每个暂停及暂停有关的每次看来不正常或不规则的情况。

认证机构机制102更新它的记录，以包括发出的通告和来自信赖服务器104的认可。

当任何指定的暂停持续时间过去时，暂停自动结束。无限期的暂停防止信赖方关闭或继续进行事务，即使该暂停缺乏被证认的基础。认证机构机制102和客户机制106之间的合同一般应排除由未证实的请求提出的无限期暂停。为了在使暂停生效的通告中规定的暂停结束时间之前结束暂停，认证机构机制102遵循一个与建立暂停类似的过程；认证机构机制102接收和记录一个请求，并通告信赖服务器104，后者更新证件状态数据库。

1.B.12  吊销

接收吊销通告的信赖服务器104更新证件状态数据库，以指出该证件被吊销，并向发出此通告的认证机构机制102返回一个认可和报告。如果信赖服务器104收到重复的或后来的吊销通告，它把这第二个请求记录下来，但在证件状态数据库中不做任何改变，并返回一个出错消息。信赖服务器104总是向发出所考虑证件的认证机构机制102报告每个吊销及与吊销有关的每次看来不正常或不规则的情况。

如果能得到一个备用证件申请(下文描述)，而且它已被安全地维护着，则上文解释的吊销过程能自动实现，无需牺牲文件或“短路”认证机构的职责去确认吊销请求。一旦根据备用申请已发出了一个新的证件，客户机制106能发出一个数字签字的吊销请求，它的数字签字能通过参考基于备用申请新发出的证件而被确认这种吊销请求能被自动处理，然而，如果客户机制106不能通过备用申请处理被再证实，或者如果由于任何原因使客户机制106没有剩余能力去建立可由有效证件核实的数字签字，那么认证机构机制102就必须使用数字签字以外的其他手段来确认吊销请求，这类手段通常必须伴有人工处理过程来完成上文概述的步骤。

1.B.12.1  暂停或吊销次级证件

一旦信赖服务器104已发出一个次级证件，它能按上述对于一个以时间为基础的证件采取的方式去暂停或吊销该证件。客户机制106几乎总是要暂停或吊销原始证件，因为客户要暂停或吊销证件的最普通理由，即私人密钥的安全性受损，会影响整个原始证件及基于它的所有保证。信赖服务器104立即并自动吊销基于一原始证件发出的所有次级证件，但这种吊销通常来得太迟。

通常，信赖方在信赖一个数字签字之前马上请求一次级证件。一旦信赖方收到次级证件并信赖它，则对于次级证件或原始证件的吊销都太迟了，由于这一理由，不会有任何明显的效果。它可以防止这同一方或其他方的进一步信赖，但在那时信赖方的权益已变成被赋出的了，而那些权益能被转让，即使在此之后支持它的数字签字已变为不可靠了。

再有，发出一个次级证件并在此后立即吊销它，很可能被看作是诱陷或没能以良好信誉对待信赖方。系统100的规则和与信赖方的合同防止信赖服务器104在发出后5分钟内吊销一个证件。

所以，作为一个实际问题，对次级证件的暂停或吊销不大可能及时挽救客户机制106或认证机构免受损失。这样，尽管次级证件在系统100中能被吊销和被吊销，但原始证件的暂停和吊销是防止基于已消失的认证所造成损害的主要手段。

1.B.13  基于时间的证件的过期和替换

基于时间的证件在其中指定的有效期结束时就过期了。在基于时间的证件中指定的过期时间，过期自动地发生，不对任何方采取确认行动。为向信赖方提供关于证件状态的完整信息，关于过期的信息被包括在证件状态数据库中。

通过发出和接收一个标识同一客户机制106但列出新的公用密钥的证件，一个过期的基于时间的证件可被替换。在一个基于时间的证件中认证的加密的密钥对有一个有限的生命时间，因为技术的改进可能使密钥对的安全性易受到一种攻击，这种攻击得益于能得到累积的密码整体。所以，一个旧的过期的证件不应以其旧的公用密钥原样再发出。

向同一客户机制106再发出一个替换证件的过程与发出初始证件的过程基本相同，只是确认较容易些，因为为确认先前证件中的信息所得到的证据能有助于确认新证件中的信息。过时的信息可能需要更新，而认证机构机制102总应被警告，以指出其不准确性，但是，建立在以累积帐户历史为基础的现存信息之上，使再发生一个其后的证件更简单和减少认证机构机制102处理过程的费用和风险。尽管如果没有亲自接触的话，发出一个具有适当确认的新证件是困难的或有风险的，但在一个没问题的帐户中和在没有很大增加保证水平的情况下再发出一个替换证件，可在旧证件过期之前通过电话或由数字签字的请求很好地完成。

1.B.14  基于时间的证件的自动替换

由于对基于时间的证件进行替换比初始发出证件能更好地贡献于自动化，所以一些基于时间的证件可以有相当短的有效期但可被自动地替换。短的初始有效期加上可自动替换性能特别适用于：

试验者：一些客户可能不肯定数字签字和认证是否证明有价值或服务于他们的需要。

害怕的客户：短暂的有效期缓解对长期安全地保持私人密钥以及电子商务的其他风险的担心，但允许客户机制106以一种方便的方式延长其有效性，或许随之增加舒适感。

缺乏历史：对于社区的新人或几乎没有相关历史的潜在客户要比众所周知的申请者表现出更大的风险。使用短期的可替换证件给相对不认识的客户机制106以建立跟踪记录的机会。

不稳定性：其中所列信息可能需要更新的证件可做成为短时过期的，从而使它们的客户能替换它们并更新被认证的信息。

再有，或许是最重要之点，短有效期限制由于私人密钥受损害造成损失的风险。客户的数字签字能力(包括私人密钥)再生越频繁，不能保护特定私人密钥的风险就越小，因为相应证件的生命更短。

然而，虽然自动替换经常是有好处的，但认证机构机制102不应允许在所有可能情况下自动替换基于时间的证件。是否允许以及在什么条件下允许自动替换，在一定程度上要留给发证件的认证机构机制102和受到与保证有关的替换影响的信赖服务器104及保证的担保人合作共同判断。对于每个客户机制106帐户，认证机构机制102包括一个域指明基于时间的证件可以被自动替换的次数，而且每当一次自动替换过程成功时该域中的值便减1。如果该域为零，认证机构机制102便不发起自动替换过程。该值是由发出这要被替换证件的认证机构机制102设定的。判断(由认证机构机制102作出的是否允许及在什么条件下允许自动证件替换和判断)在系统100中被限制，该系统在以下情况下排除自动替换：

标识信息改变：在信赖服务器和认证机构数据库中的某些域，特别是包含标识客户机制106的信息的域，不能被自动证件替换过程更新。如果在客户申请中的标识信息不能与已在信赖服务器数据库中的信息匹配，则该申请被转到发证的认证机构机制102并从那里转到登记管理人员，他能与客户机制106接触以确认标识信息中的改变。

增加保证：认证机构机制102或信赖服务器104(与保证担保人合作)可以完全拒绝在自动替换的证件中增加保证，或者可以根据对保证限规定的软的或硬的上限及其他要求来限制借助自动替换所增加的比率。

无证实能力：发出一替换证件必须基于关于新证件中所列信息继续有效以及关于客户接受新证件的适当文件。要电子地替换一证件，客户机制106必须证实一个申请和对它的接受。如果对于客户机制106，要被替换的证件不再有效，而且不存在用于证件替换的有效证实证件或备用申请(下文描述)，则该客户不能再用电子手段替换该证件。

有问题的历史：认证机构机制102的与信赖服务器及一中央贮藏室相关的帐户历史记录列出了达到认证机构与信赖服务器104的合同中规定的严重程度的事件。换句话说，认证机构机制102和信赖服务器104同意，如果发现了有某种严重级别的事件，则自动替换将不被处理。

信赖服务器104跟踪初始证件可能被自动替换的次数，这个次数可能为零。与暂停和吊销类似，证件的可自动替代性是由发出证件的认证机构机制最初确定的，并在信赖服务器104中公布和使终端用户(包括接收帐户声明的客户机制106)能从那里得到。如果一证件不能被自动替换，它的客户机制106能按前述申请让一新的证件发出。

为自动替换一个基于时间的证件，客户机制106、认证机构机制102和信赖服务器104彼此交互作用如下：

客户发起替代过程：客户机制106跟踪客户的证件的有效性，并在证件快要过期时选择对它的替换。客户机制106从来自信赖服务器的帐户声明得知证件的吊销或暂停情况，然后使用一备用申请发起替换过程。当客户机制106使用该系统时，例如当客户机制106试图建立一个数字签字而又没有有效证件用以核实这一签字时，按照客户的选择，可以给出提示。

客户申请新证件：一旦客户机制106触发替换过程，它建立一个新的申请，列出在旧证件中的信息。客户机制106审查申请表并做出必要的修改，然后产生一个新的密钥对并把公用密钥和一样板数字签字包括在申请中。然后，客户机制106使用客户的旧证件(如果它仍然有效)的私人密钥数字签字该申请。由于该申请包括了将在证件中列出的全部信息并将其呈现给客户机制106，所以客户机制106也接受要在申请中发出的证件。然后，客户机制106或者把替换申请发送给发出要被替换证件的认证机构机制102，或者发给在证件中指明的信赖服务器104，这取决于他们之间的合同。当客户机制106接受该证件并得到初始帐户声明时，该申请替换的地方被存储在客户的系统中。

认证机构机制102或信赖服务器104发出新证件：认证机构机制102检验该申请，如果该申请能被自动处理，则由它创建一个新证件，并对它数字签署。如果认证机构机制102发出该证件，它把该证件送去供信赖服务器104公布，所有这一切无需人工干预。如果信赖服务器104与认证机构机制102的合同需要的话，则由信赖服务器104发出该证件，它通告发出被替换证件的认证机构机制102。如果自动替换未被允许，则替换申请被送去供登记管理人员处理。

信赖服务器104公布该证件并更新客户的证件状态数据库记录，以指出一个新的原始文件及其新的过期日期，并根据信赖服务器104与发出这原始证件的认证机构机制102之间的合同调整保证限。信赖服务器104向公布证件的认证机构机制102承认接收和报告更新，并在发出下一个帐户声明时更新由系统保持的客户记录。

自动替换最终是以被替换的基于时间的证件、保证限及其监测、以及自客户机制106登入以来累积的帐户历史记录为基础。它完成那些处理中的最大多数，而且在按照累积证据看来不能保证结束或中断的情况下在效果上防止了认证帐户的结束或中断。然而，由于自动替换过程压倒了证件过期效应，使得证件的暂停和吊销变得更加重要。

1.B.15  自动替换使用备用申请

只有当客户机制能电子地和可靠地证实要在新证件中列出的信息并接受它，证件才能被自动替换，因为发出这一替换的认证机构机制102必须报告新证件中信息的确认和新证件的接受。如果客户机制106没有剩余的有效证件，该客户便不能再创建足够可信的数字签字。

为了缓解这种境况，客户机制106存储一个数字签字的备用申请，用于认证一个新的密钥对，如果在该申请中至关重要的、数字签字的信息不需被更新的话，该申请能被用于得到一个新证件。当一客户机制106申请新的初始证件时，系统创建两个申请。一个被传送到认证机构机制102用于发出新证件，而另一个被加密封好存储在客户系统中作为备用申请。备用申请包含它自己的与客户系统上任何其他公用密钥不同的公用密钥，而相应的私人密钥被存储在客户系统中一个安全的地方。

备用申请被一私人密钥数字签署，该私人密钥在用于签署该备用申请后被立即销毁。相应的公用密钥被包括在只对该备用申请有效的一个事务证件中，并和主申请一起传送给认证机构机制102。认证机构机制102把这事务证件保持在文件上，以备客户机制106发送备用申请时使用，该认证机构机制102将需要使用这事务证件中的公用密钥来核实这备用申请。

如果客户机制106不能借助一个由现存的有效的数字签字能力进行数字签署的常规申请来替换一个证件，那么客户机制106能使用这备用申请。客户机制106检测没有有效证件是未用的和可确定的，于是它使用该备用申请，假定标识客户机制106的关键信息没有改变的话。如果在备用申请中的标识信息仍然准确，则客户机制106把这备用申请发送给客户的认证机构机制102，后者参考为这种情况而保持在文件上的事务证件以核实申请上的数字签字。然后，认证机构机制102发出一个新的基于时间的证件，列出在备用申请中指出的公用密钥。然后客户机制106打开存在远处的私人密钥，以便在根据这备用申请发出一证件时使用。

一旦客户机制106已收到了使用这备用申请的新证件，客户机制106能在这客户证件过期之前的任何时候发出一个新的常规的申请来替代这客户的证件。建立和发送这常规申请的过程建立和安全地存储一个新的备用申请和备用私人密钥。

触发根据备用申请发出一新证件的事件是向认证机构机制102发送备用申请。响应该申请而发出的证件总是列出发出先前证件时识别出的人作为客户机制106，以使向冒名顶替者发出证件的机会最小。发送一个备用申请本身对任何其他未完结的证件没有影响，尽管客户机制106可以使用这新证件去请求吊销另一个能被证实的证件。

客户机制106和认证机构机制102之间的合同可能限制或阻止使用备用申请。然而，使用备用申请和自动替换可能将证明对多数客户是方便的，并对基于时间的证件造成可能较短的有效期，这限制了持有任何特定私人密钥的风险。

1.B.16  对风险的评论

风险实质上是将受到损失的机会，它的最大值等于潜在的损失量。风险管理基本上和对大多数情况是包括：(1)最大限度地使可能性和潜在损失达到最小，(2)把不能有效排除的风险分散开。尽管以最大努力去使风险最小，但通常仍存在损失的可能性。这剩余的风险最好是通过把它分散到大量的有类似状况的风险承担者身上，于是它变为适度的已知的费用，而不是不稳定的灾难落到单个企业上的那种机会。在这最佳实施例中，其技术和预定或推荐的实践使风险最小，并保证担保人们在认证机构及其他人当中分散风险，其作法是借助保证、合伙安排、以及其他技术，从而以具有广泛基础的方式分布剩余风险。

多维有效性限制和二级认证使该系统能精确地处理系统面对的风险，同时为每个信赖方的需求专门提供高度的保证。一般地说，初始证件和它的替换物有很小的或没有保证量，但根据初始证件，能按要求从信赖服务器得到有更大保证的次级证件。规定一个定制的次级证件中的保证范围，使信赖方清楚地理解数字签字所提供的保证的准确范围。它还使系统管理保证的另一侧面，即由于信赖要造成损失的风险，而对于这种信赖，系统中的参加者将是有责任的。

2.第二实施例

2.A  第二实施例概述

参考图6描述根据本发明第二实施例的电子事务系统200的概况。客户202得到认证机构206层次结构内的一个认证机构发来的或从多个保证人208之一发来的一个或多个证件204。这些证件可以用于标识客户202或授权由客户202进行的某些事务或事务类型。这些证件(或来自这些证件的等效信息)的副本被放在仓库或目录210中。每个认证机构或保证人可以有它自己的目录210或它们可以共享目录210。

客户202通过构成和数字签署事务214然后再把该事务214发送给一方212(此后称作信赖方)来进行与信赖方212的事务214，事务214包括为标识客户和使事务有效和授权所需要的客户证件(或客户证件的唯一标识)。

一旦收到签署的事务214，信赖方212便尽可能多地或按它所希望地去核实事务214，然后合成一个消息216，并把它发送给信赖管理器218。消息216可以是各种不同类型消息之一，包括签字担保请求(SGR)消息，状态检验消息(SCM)，超限担保(OLG)请求和不信赖请求消息(URM)任何一个。在拒绝一RCM的事件中将造成OLG请求。它们允许用户可选地请求增加客户的信赖限。

最好在每个消息216中包括一个目的域，从而使信赖管理器218知道要完成什么任务。一个SGR通知一信赖服务器218该信赖方218意欲信赖该消息中包括的某些信息(从事务214中导出的)，并请求信赖管理器218核实该信息是可靠的并担保核查结果。例如，一个SGR可能指出一信赖方212意欲/希望对于$200元的事务信赖某些证件，于是信赖管理器218被请求核查那个事务对于这个量是好的事务。

一个状态检验消息在形式上与SGR类似，只是信赖方212并不实际请求一个担保，只是请求一个指示，告知如果请求的话将会给出这种担保。

超限担保请求基本上与第一最佳实施例的信赖请求相同。然而，信赖方212可以造成OLG请求，而无需在证件中存在任何东西造成请求这种请求的效果。

当消息216是一个SGR或SCM时，它包含足够的信息供信赖管理器218去核实事务214中的客户信息。信赖方212还可以在消息216中规定事务的种类以及它要依赖的事务214(或者，更准确地说，是与事务214相关联的证件)中客户信息的那些方面。

如所指出的那样，信赖方212能尽可能多地或按他所希望地去核实事务214。这样，例如，信赖方212可以核实该事务内的所有签字、证件和属性值，然后只是请求信赖管理器218针对CRL核查证件序列号。或者，信赖方212可以把整个事务214发送给信赖管理器218供核实，而它本身什么也不做。由信赖管理器218完成的核实服务的费用取决于请求它完成的工作量。

当信赖管理器218从信赖方212得到消息216时，它首先确定它已收到哪种消息。如果消息是SGR或SCM，则信赖管理器218试图核实在事务214中由客户202提供给信赖方212的证件中的信息。为核实这一信息，信赖管理器可以与认证机构206和保证人208核实，或者它可以依赖先前从那些方或其他地方(例如从目录210)得到的信息(例如CRL或来自先前核查的信息)。

信赖管理器218跟踪每个认证机构206和保证人208的累积义务量，并周期性地通知它们这个义务量。这种信息的规则性可以依据信赖管理器218和各方之间的安排，或者它可以依据事务或可信度的类型和大小。例如，在一些情况下，认清机构可能希望对某些事务或事务类型立即得到通知，例如超过某一钱限的事务，由一些特定实体进行的事务，会使其累积可信度超过某值的事务，在一天的某些时刻的事务，或者这些事务的任何组合，以及其他条件。以这种方式，如果必要的话，认证机构206或保证人208将能立即行动，以保证针对这些事务的义务量。

可能有不只一个信赖管理器218，而且不同的事务212或同一事务的不同方可能得要由不同的信赖管理器来核实。为了使各个信赖服务器跟踪与每个未结束证件关联的累积义务量，使用了全局义务量跟踪服务器220。每个义务量跟踪服务器220的作用如同电子事务系统200的全局共享存储器，允许信赖管理器218读出和写入与每个未结束证件关联的累积义务量。对于每个证件，只允许使用一个义务量追踪服务器220。义务量跟踪服务器220可以是单独的实体，或者它们可以是目录210、CA206或保证人208的一部分。如果一个特定证件只能由一个信赖管理器处理，那么该信赖管理器能跟踪与此证件关联的累积义务量。这些义务量跟踪服务器提供一个通用“禁止”功能，以检测和防止对一个证件的过量信赖。“禁止”服务一般由一高可用性系统按照与发证CA的合同来完成。

证件可指定一个信赖限，或每个时间段的信赖限，如每时，每天，每周，每月，每年，每24小时，每周日，等等。这样，一个证件可以有一信赖限每日$200元，而另一个有信赖限$500元。类似地，证件可指定每个时间段的事务数，例如每时、每日、每周、每月、每年、每24小时、每周日等等。这样，一个证件可能指定每日10个事务。这些的组合可能申请例如每日5个事务，每天不超过$500元。此外，根据信赖管理器218的判断，会需要一个要被认可的OLG请求。

义务量跟踪器220对每个证件对证件中声明的周期存储累积义务量和事务数。这些证件可根据它们的唯一标识(发布者名字及证件序列号)来编索引。

由于一个证件可以规定能用于使那证件有效的信赖管理器的类型或类别，所以同时试图在一个义务量跟踪器220处读/写值是可能的。就是说，不只一个信赖管理器在处理同一证件的一个副本和不只一个信赖管理器在根据那个证件请求信赖，这是可能的。因此，义务量跟踪器220使用一个适当的锁住机制来保证对它们的记录进行一致性的读和更新。

每个信赖管理器218、认证机构206和保证人208可以在任何时候通过从保证人222那里得到保证来对某些义务量保证自身。信赖管理器218可以被授权根据诸如认证机构或保证人当未决累积义务量等因素来代表认证机构206或保证人208从保证人222那里得到保证。信赖管理器218还可以从保证人222那里得到它自己的保证。

信赖管理器218通过帐单服务224向各方开出它的服务帐单。信赖管理器218还向适当方开出因它使用被信赖方212信赖的证件需支付的帐单。这可以采取例如向一未知信赖方请求立即电子付款，把例如保证人的前已建立的存储帐户记入借方，或者向具有已建立的信用和付款历史的保证人或信赖方发送周期性清单等形式。

信赖管理器218在处理了一个消息(例如核实SGR或SCM，处理OLG请求)，通告了适当各方，得到了适当的保证，以及为所提供的服务开了帐单之后，它向信赖方212发出一个信赖管理器收据(RMR)226。这个RMR226通知信赖方212状态检验结果和为这些检验所收取的费用量，或者在超限保证请求的情况中，通知响应那些请求的结果，这或者是一个保证收据或者是一个拒绝消息。RMR收据226可以是由信赖服务器218数字签署的，带有日期、时间和消息摘要，从而作为信赖管理器完成核实的证据。必要时，信赖管理器能把消息216、签署的收据226以及与处理消息216有关的任何其他消息归档。

事务214、消息216及RMR226能在创建时由一独立标记服务器228数字签署。

一收到RMR226，信赖方212能存储RMR，并根据RMR226中的信息，与客户202继续进行事务。

尽管图6中所示为单独的实体，但帐单服务224和信赖管理器218可以是同一实体的部分，在这种情况下，事务的各方(例如认证机构、保证人、客户及卖主)能与信赖管理器218建立帐户。信赖管理器将为归于它的状态检验费和归于CA、保证人及承保人的信赖费保持各自的总数，并周期性地完成对所有这些收费的分开和结算，收集到期的资金，把所有收集的资金转移给适当各方，并扣除服务费。

根据客户的请求，信赖管理器或者全局义务量跟踪(“禁止”)服务(如果一个正被使用的话)将定期地向客户发出一个声明，声明列出那个客户的已出现在该信赖管理器的所有签字，包括信赖方的标识，所请求的信赖限(如果有的话)以及所收取的费用。这个声明可以通过传统的纸邮件、电子邮件分发，或者是通过Web服务器可由客户在任何时候浏览的。这声明的目的是提醒已发出签字的客户，并允许它可能识别出或许是错误发出的或不适当信赖的签字。

再有，尽管图6中显示为单独的实体，但客户202在某些场合可能本身就是信赖方212。例如，客户202可能希望在向另一方发出一特定事务之前确定那个事务是否对于一个签字保证是可接受的。

2.B  第二实施例详述

现在参考图6描述认证机构CA-n向客户发出一个证件的过程。客户证件204被存储在某个最好是安全的地方，例如放在客户信任的安全装置230(见图7)中，它可以是一个智能卡之类。

客户证件204有X.509形式(如图12所示)，并包括下列信息或属性：

1.证件发出者名字。

2.唯一的证件序列号(请注意，认证机构名字和证件序列号唯一地标识一个证件)。

3.客户的公用密钥。

4.由发出者设定的信赖限，例如一个事务和/或每个时间段(日、周、月、年等)的最大美元金额。

5.在发出者将根据证件中信息假定任何要信赖的义务量之前，是否必须检验证件状态。

6.至少一个由发出者认可的、在那里能检验该证件的状态检验服务(信赖管理器218)的名字和可选项网络地址，以及它的目录210的适当地址。如果使用了X.500目录查询系统，那么名字和地址将是相同的，否则，可能必须指定有效的网络地址和通信手段。

7.检验服务的状态检验费。

8.保证费(每个信赖美元量的保证费)。

9.谁将支付状态检验费(客户、认证机构或保证人)。

10.这个证件的主体/客户是否是一个装置。

11.签署人/装置是否对其签字编号，如果编号的话，是(a)顺序编号还是(b)伪随机编号。

证件204还可以包括一个可选域，授权允许为状态检验服务向发送人/签署人或另一第三方(通常是签署人的雇主或保证人)开出其部分或全部费用的帐单，而不是要求信赖方去付帐单。当使用这一特性时，状态服务保留签字号或签字值(或从中提取出的某种值)的记录，以防止同一个或不同的信赖方不止一次地利用这第三方付帐单特性。这样，状态服务将检测出一个特定的数字签字先前已被检验和保证过，于是拒绝任何试图由保证人付费对其再检验，这种再检验会造成不合理的收费。

在某些情况下，当被授权时，证件204还将包括一个第三方的名字和帐号，该第三方已同意承担状态检验和保证费。

另一种作法是，证件204可能不是一个把客户名字与一公用密钥链接的标识证件，而是一个把某种特权或授权授予该客户的证件(即如美国申请08/277,438号中描述的授权证件，该申请属于Sudia，1994年7月19日受理，题为“在商业密码系统中安全使用数字签字的方法”，其内容在此全部纳入作为参考)，它与一个标识证件联系在一起。这种授权证件也可以有一个相关联的事务限系统，它需要由一信赖管理器管理，因此将需要把与前述相同或类似的一组“信赖说明”域加到该证件中。

当认证机构CA-n(或一保证人)发出一个证件204时，来自那个证件的相关信息的副本被送到一个适当的存储器或目录210。送到目录210的信息包括认证机构名，证件序列号，以及在标识证件情况下的证件公用密钥。证件信息也被送到一个状态检验服务(RM)。通常这个RM与证件中指定的那个相同。

在一个层次化认证系统中，每个认证机构本身将被另一个CA认证，这些CA中有一个被根认证机构CA-o认证。每个认证机构在某个目录210中公布关于它所发出的证件的适当信息。这些认证机构可用同一个或不同的目录210。

一个CA证件(来自它的父机构)包含的属性与先前列出的客户证件204的属性类似。CA证件还包含一个属性指定亲缘限制是否只应用于该客户或者是否它们应用于一指名认证机构所有客户的每日总量。

参考图7，根据本发明最佳实施例的可信任装置230包括一个防破坏数字计数器232。每次该装置被用于创建一个数字签字时，这个计数器便单调地增加某一值，例如1。再有，计数器的当前值被作为一个签字属性值嵌入到由装置230签署的每个签字块中。

通过对一装置(或用户)的每个签字编号，然后当签字被提交给信赖管理器时收集这些数码中的每一个，从而能检测出对装置的可能破坏和仿造，或者对私人签字密钥的偷窃和非授权使用。如果一个私人签字密钥是从一个装置中提取出来的，它可以用于签署那样一些事务，当这些事务伴有该制造者装置证件时，这些事务看起来如同由那个装置以一种信得过的方式产生的。然而，当在该装置之外使用时，它们便可能被用于产生不适当形式的事务。

这里描述的签字编号方法不能检测出仅在装置外部使用一下的情况，但它能帮助检测使用由拿掉防破坏外罩等作法得到的合法装置签字密钥和证件来假冒或再生假的装置。我们假定，假冒的目的是根据破坏少量合法装置来产生和出售大量装置，因为成功破坏的费用会是相当高的。这样，通过要求每个签字有一个序列号，我们允许由一个中央系统进行可能性检测，该系统收集和比较这些编号。如果发生重号，或收到的编号远在序列之外(由于盗贼们把每个计数器设置于不同的基值)，那么该系统能检测、调查和可能吊销受影响的装置证件。

如果这可信任装置还包含一个可靠的计时钟，它能把一时间值与计数器值一起放到每个证件中，那么这种方案会得到增强。这能允许信赖管理器用签字的创建日期来搜索到达的事务签字，这样便能更容易地确定在序列之外的签字编号。

作为进一步的变化，我们可以：(a)用一个伪随机数发生器(PRNG)来产生签字编号，并使CA和信赖管理器知道该伪随机数发生器的种子值，从而它们可以计算出预期的编号序列；或者(b)以一个基值开始，然后增加一个增量，而这个基值和增量都是特定装置制造者的一个功能。

例如，计数器232的初始值和每次事务的增量能由装置制造者在认证装置时随机设定，然后这些值可与其他信息一起纳入装置230中的装置证件236中。

每个装置制造者234可以被赋予不同的计数因子，最好是一个大于1的质数，该计数器232的增量能在制造时设为一随机值乘以这个因子。这样，例如，如果有三个安全加密装置230制造者，名为M1、M2和M3，那么M1将被赋予因子3，M2被赋予因子5，M3被赋予因子7。然后，对制造者M1制造的每个装置，它产生一个随机数R，并对计数器232设定增量为“3XR”。类似地，制造者M2将在它的装置中设置计数器增量为5乘以随机数，而制造者M3将把它的增量设为7乘以随机数。用于确定增量的随机数的范围可以是限定的，例如1到200，也可以排除质数。初始值也可以用这一因子确定。

代替存储增量本身，由制造者发出的装置证件236只需存储用于确定增量的随机值R或者用于确定R的随机数发生器种子值(只要产生随机数的算法已知)。

装置230包含客户私人密钥238的副本(对应于客户证件204中和目录210中存储的公用密钥)。

装置制造者234本身由根认证机构CA-o之下的认证机构层次结构中的认证机构CA-m认证。这样，在可信任装置230中的装置证件236能由制造者的公用密钥(存储在认证机构CA-m的目录210-m中)来认证。

参考图1-8，当一客户202创建一个事务214时，该客户产生一个消息240，含有事务详情242、客户证件204(由认证机构CA-n发出的)的副本、以及其他有关证件的副本。代替实际证件的副本，客户202可以例出对一些或所有证件包括其唯一标识(发出者名字和证件序列号)。然后，客户202使用他的私人密钥238数字签署事务242与各种签字属性248的组合，以产生一个数字签字250。

如果客户的可信任装置含有如前所述的签字计数器232和计时钟239，那么其他证件244可以包括诸如装置证件236之类信息(从而能确定计数器的初始值和增量)，而签字属性248必须包括计数器232的当前值。如果装置增量为每次增1，则不需要装置证件。如果需要的话，装置证件的副本是其后用于检验存于签字属性248中的计数器232之值。通常，在用户密钥被认证时，装置证件将已被提交到CA，因此它的内容已为该CA以及它与之签定合同的任何RM或全局禁止服务所知。

计数器异常值包括远在序列之外的值、先前在不同事务中已见到的值，与能由制造者发出的那些值不对应的值，以及与那个装置能发出的值不对应的值(基于装置证件236中的信息)。如果事务是打上时间标记的(例如包含一个来自内部计时钟239的时间值)，那么即使事务提交在序列之外，也可能确定一个计数值是否是合法地处于序列之外。

最好是客户私人密钥238存储在客户的可信任装置230中，如同客户证件204那样，然而，这其中任何一个或这两个都能存储在一个安全计算机上或某个其他安全存储装置上。

能以任何可接受的和已知的方式产生数字签字250。例如，可用RSA或DSA构成签字。数字签字250及签字属性248能包括PKCS-7签字块，它包含附属证件244和246的混列，客户是否为一个装置的指示，对这个私人密钥为唯一的签字编号(计数器232之值)，以及最好还有相伴的时间标记(来自内部时钟239)指示何时做成此签字。在带有计数器232的安全装置230的情况下，签字编号是那计数器的当前值。

2.B.1  信赖方接收事务

当信赖方212收到如前所述构成的事务214时，它能做许多事，取决于事务214中包含多少信息和它想要信赖管理器218做多少事。

参考图9，信赖方212接收事务214(步骤200)并完成下列步骤中的某些或全部：

如果信赖方212想要使整个事务214由一信赖管理器218检验，它便确定该适当信赖管理器218的地址，整个事务214将被发送给它(步骤210)。

否则，信赖方212从事务214中提取出客户证件242和其他证件244(如果有的话)的副本。请注意，这些证件242、244的某些或全部可能不存在。它们可能先前已被发出，可从目录中得到，或留给信赖管理器去获取。事务214至少应包含一个对客户证件204的唯一标识参考(例如发出者名和序列号)。

在这一点，信赖方212或者能进一步证实事务214本身的有效性，或者能直接进入确定地址(步骤S210)，让信赖管理器218检验整个事务214。

如果信赖方212决定进一步核实事务214，于是它提取任何漏掉的证件(步骤S204)。漏掉的证件从适当的目录210获得，或者信赖方212可能从先前的提取中已得到了它们的副本。这一证件提取过程是从每个所提供的证件向上工作，以找到所有父证件，最后做到一个已知的好的根密钥。

这样，例如，如果事务214由图2中的客户2签署，而且该事务只包含客户2的证件，那么信赖方212应该要得到证件发出人的证件(即CA-5的证件)，然后是CA-1的证件。另一方面，如果该事务由图2中的客户1签署，而且该事务包含客户1、CA-1、CA-2、CA-3和CA-4的证件，那么信赖方212为了核实客户签字便不必要得到任何其他证件了。

同样，在这一点，信赖方212能继续核实事务214本身，或者它能直接进入确定地址步骤(S210)，把事务214的更多部分交给信赖管理器218去检验。

在得到全部所需证件(在步骤S202、S204)之后，接收者核实证件链(步骤S206)，从根向下工作到签署人，沿着这向下的路径核实证件中的政策控制。然后信赖方212重组该消息，并针对基本客户证件检验其签字(步骤S208)。

2.B.2  信赖方确定状态服务的地址

在让事务214的任何方面被一个或多个信赖管理器218核实之前，信赖方212必须确定哪个(哪些)信赖管理器要使用。每个客户证件或者包括状态检验服务(信赖管理器218)的名字，在那里证件能被检验，以及它的目录210的适当地址，否则信赖方212必须从适当的认证机构206得到那些信息。这样，如果给定一个证件，便有可能确定用哪个信赖管理器去核那个证件的各方面。

于是，在步骤S210，如果信赖方212尚未得到至少一个适当的证件(在步骤S202中)，那么它这样做，并由那个证件确定一信赖管理器218(或一类信赖管理器)的名字，在那里该证件能被检验。

另一方面，如果信赖方已经得到了至少一个证件(在步骤S202中)，它使用那个证件确定信赖管理器218(或一类信赖管理器)的名字，在那里该证件能被检验。

如果信赖方得到了伴随该事务的全部证件，它为每个证件确定一个适当的信赖管理器218。

2.B.3  信赖方创建一个消息

在收到一个事务214(步骤200)并按它希望的那样多地核实了那个事务(步骤S202-S208)之后，信赖方212接下来创建一个或多个消息(或者是SGR、SCM或者OLG请求)216(步骤S212)供发送给一个或多个信赖管理器218。

然而，在创建任何消息216(步骤S212)之前，信赖方212必须确定向哪个(哪些)信赖管理器218发送消息216。如果涉及多个信赖管理器的话，可能有不只一个消息216，所以信赖方212必须首先确定涉及多少信赖管理器。

当一认证机构206或保证人208发出一证件时，它在证件中指定一个状态检验服务(信赖管理器218)，在那里这个证件能被检验。状态检验服务能由名字、提供者类别或以其他方式指定。这样，证件发出者可以确定只有一个特定的信赖管理器218能核实它的证件(并在它的证件中这样指定)，或者它可以允许由满足一定要求的任何信赖管理器218(由一信赖管理器类别来指定这一点)来核实它的证件。

接下来，信赖方212分析要求进行状态检验的证件，以便确定要用于事务认证的状态服务(信赖管理器218)(步骤S210)。

消息的内容取决于信赖方212想要信赖管理器218去做什么。首先，信赖方212可以向信赖管理器218提供整个事务214或者只是事务的一些部分。其次，信赖方212可以向信赖管理器218提供伴随该事务的全部证件，或者它可以只提供只是一些证件的唯一标识。第三，信赖方212可以请信赖管理器218去检验整个事务的有效性或只是它的一些方面的有效性。

信赖方212能要求信赖管理器218完成的各种功能包括：

(1)在只给出证件唯一标识的情况下检验那些证件是否已被吊销(即被列在CRL上)或被暂停。

(2)在给定一组实际证件的情况下检验它们是否已被吊销或暂停。

(3)在给定证件和唯一证件标识组合的情况下检验那些证件是否已被吊销或暂停。

(4)核实证件链，看证件是否实际彼此核实。请注意，RM能把大多数证件以预核实状态存储，以免需要重复计算数字签字。

(5)与上述(1)-(4)相同，但检验整个事务，包括签署该事件的原始客户的数字签字。

如前所述，消息216可以是各种不同类型消息之一，包括或者是SGR(它通知信赖管理器218信赖方212意欲信赖消息中包括的某些信息，并请信赖管理器218去核实那个信息是可靠的)；或者是SCM(它在形式上与SGR相似，只是信赖方212并不实际请求一个担保，只是请求一个指示，即指明如果请求的话会给出这种担保)，或者是OLG请求。

如果消息216是一个SGR或SCM，它包括一个货币量值(用于信赖目的)，它是信赖方212根据事务214最初确定的。如果在事务214中没有提供货币值，或者如果信赖方想信赖一个不同于所提供值的值(例如，如果信赖方212本身保证某值)，信赖方能相应地在消息216中设定该货币值。然而，为防止信赖方212声明的货币值超过事务214中声明的值，从而或许过早地用完客户的最大允许限，事务的签字属性248应包括该事务的实际声明值，而且消息216应包括签字属性248，从而包括这一实际声明值。

如果只希望状态检验，或者可在消息中设置状态检验位，或者可把消息216中的货币值设置为零。最好是使用状态检测位，以避免由于语义学造成数据值过载。在这种情况下，消息216(一个SCM)将被用于请求各证件的状态信息，而不被用于购买任何担保。

消息216(SGR或SCM)包含如下内容(不一定按给定的顺序)：

1.信赖方212的名字和网络地址。

2.一个唯一序列号，从而使重复消息(特别是RCM)能被拒绝。

3.帐单服务224上的帐户信息，用于记帐单(即使客户或保证人付款)。

4.一种可选的请求，以在超过所允许的/剩余的信赖限请求扩展。

5.证件或证件唯一标识(例如发出者名字和序列号)清单。

6.签字序列号和时间标记(如果在事务214中存在的话)。

7.被检验消息(事务214)的混编。

可选地可把整个消息附在后面用于检验和/或存档。

8.请求的日期和时间(由时间标记服务器228提供)。

9.可选的本事务类别清单。

10.即使状态检验失败也要存档的请求；或即使超过信赖限也要存档的请求。

11.存档提取口令，以信赖管理器的公用密钥加密。

12.本消息的目的(担保请求，状态检验、帐单认可等)

13.角色(信赖方)

14.信赖方帐单服务证件复述。

15.为在帐单服务222处帐户交费的信赖方签字。

2.B.4  信赖方发送消息

在确定了地址(步骤S210)和创建了适当消息(步骤S212)之后，信赖方212确定所请求的基本检验费总量和每元信赖值请求的信赖担保费总量(步骤S214)。

对于所创建的消息216，它们被发送(步骤216)到适当的信赖管理器216。使用该信赖管理器目录条目中指定的任何通信机制，如插座、HTTP、电子邮件等，将消息216发送出去。

2.B.5  由信赖管理器进行的处理

1.接收消息

一旦从信赖方212收到消息216(步骤S218)，信赖管理器218完成如下操作(参考图10)。

2.核实消息语法

首先信赖管理器218核实(步骤S220)消息216的一般语法是正确的。如果语法不正确，信赖管理器便通告信赖方212并停止处理。信赖方212可能因语法错误消息要付费。

如果消息216语法正确，于是，如果信赖方214在信赖管理器218有帐户(即如果信赖管理器和帐单服务224为同一实体)，则信赖管理器查寻它在当地存储的信赖方212公用密钥，混编消息216并核实信赖方签字。

如果信赖方212对信赖管理器218没有预先建立的帐户，信赖管理器就必须以某种传统程序核实消息216上的信赖方签字，通常要核实指定信赖方公用密钥的证件链。

3.确定最小费用

接下来，信赖管理器218确定由于这一核实事务应付的最小量，并核实信赖方帐户中能得到的财源(步骤S222)。有时，在整个事务未核实完之前信赖管理器218不能确定该事务的应付费总量。如果信赖管理器218和帐单服务222是分开的实体，那么信赖管理器可以或者向帐单服务的信赖方帐户发帐单，或者与帐单服务接触以确定信赖方是否与它们处于良好状态和是否有可得到的财源或信贷。

4.确定在请求什么

信赖管理器218其后的活动取决于消息216中信赖方212请求什么。信赖管理器218确定在请求什么(步骤S224)并相应地检验消息的有效性(步骤S226)。

5.证实消息

在一种可能情况中，信赖管理器218被给予(在消息216中)各证件的唯一标识和/或实际证件，以及所请求的信赖限。信赖管理器216检验那些证件是否已被吊销(即是否它们被列在CRL上)或被暂停。

信赖管理器218必须首先检验以确定所请求的信赖是否小于或等于事务214的值。该事务的签字属性块248包括该事务值，而这块与实际签字一起，而且与信赖方请求的义务一起被提供给信赖管理器。如果所请求的信赖超过该事务值，信赖管理器应拒绝该请求。在这种情况下，信赖管理器应通告客户202和该请求的其他方。

这样，信赖管理器能在利用客户能得到的信赖限之前核实签字和从该块中提取客户声明的事务值。如果已提交整个事务，RM还能对它进行混编，并看是否与签字属性块中包含的事务混编匹配。对于较小值的消息，检验签字块或整个消息的这些过程可以略掉，在那里信赖由信赖方提供的声明值是适当的。在这种情况下，如果有任何由信赖方提出的误声明，则由信赖管理器提供的签字担保或其他事务保证将简单地被避免，所以提交错误值不符合他的利益。

对于消息中列出的每个证件(或者由序列号列出，或者由所提供的证件本身)，信赖管理器218针对适当的CRL检验证件的序列号，该CRL就是来自那个证件发出者的CRL。如果该证件已被吊销或暂停，信赖管理器记下那个证件的无效性，并继续处置其余证件。如果任何证件无效，则整个事务被认为是无效的。

对于每个被检验的证件，信赖管理器218向发证者通告它的使用以及与那个证件相关联的信赖值(步骤S228)。这种通告可以是每月、每日、每周、每时的，或对每个超过预定量的事务发此通告。

6.更新全局信赖限

假定能得到不只一个RM，则信赖管理器218还能从适当的全局义务跟踪器220读出那个证件的当前累积义务量。如果当前累积义务超过了请求的义务，则该事务是无效的并被拒绝。如果信赖管理器认为是处理一个超限担保请求，则信赖管理器通知信赖方。否则，如果除了请求的义务外，当前累积义务不超过那个证件上的限度，则累积义务应被更新以反映所请求量(步骤S230)。

由于对累积义务量存在潜在的同步更新企图，在做任何读或更新值之前，信赖管理器可能需要得到一个锁，以相应的信赖跟踪器锁住由该事务使用的所有证件的值。或者是，它可使用一种乐观实施战略，在处理每个证件时写入新值，并在其后失败时(超限)退回任何改变。这些记录的更新可采取本领域已知的任何方式完成。再有，在某种情况下，只有少量证件使其相关联的义务量被检验。(客户202的)最后一个是要密切监视的最重要的一个。

在某些情况中，信赖管理器被请求检验整个事务。在这些情况中信赖管理器将得到与该事务关联的全部证件，检验它们的有效性和一致性，然后针对请求的义务限按前述处理它们。

一旦信赖管理器218已确定了一个特定证件的状态，信赖管理器218能为那个证件创建一个记录。可以不管该证件的状态如何去创建这个记录。这记录列出该证件依赖的全部证件及依赖该证件的全部证件。这样，可在单一查表中核实证件链。每当收到CRL或每当信赖管理器确定一特定证件变为无效(被吊销或暂停)，它能更新它的记录，按适当方式使证件链无效。

信赖管理器还记录已信赖每个证件的所有各方。每当处理一个CRL或每当信赖管理器确定一个特定证件无效时，信赖管理器能在一定时间段内(例如1-2周)通告已信赖该证件的所有各方。有时把这称作“回顾通告”，它能帮助在一个证件被吊销之前近来信赖过该证件的各方确定是否对于先前的事务可能存在任何问题，例如在发现客户密钥被盗之前由盗贼发出的欺诈事务，并向CA报告请求吊销证件。

如果与一消息关联的全部证件是可接受的，则根据SGR中请求的信赖，使每个证件对适当时间段的信赖限了增量。

7.确定费用和向各方开帐单

然后，信赖管理器为后面的批处理写事务，在批处理过程中它对每个证件上收集的保证费增量，并按发证件认证机构名字累积担保费(步骤S232)。

如果有任何证件是不能接受的，则信赖方212(或客户202)只被收取基本检验费，而不收信赖和担保费。

8.如果请求的话则对消息存档

如果消息216请求存档，而且附有全部文件，则文件被重新混编并且按所提交的样子核实签字。如果这样做的结果与提交的事务不同，则存档请求被拒绝，否则该消息被存档(步骤S234)。

然后信赖方212对请求的初始存档周期得到帐单，这缺省的周期长度为6个月。信赖方212被告知他将为其后的存档期付帐。由信赖管理器提供的收据包含一个文本，一个事务混编，并用一个长的“存档”签字密钥(至少1800二进位)签署，从而使用户能在任何地方对此事务存档。然而，让RM有效地存储该事务作为一种“一步购物”安排是方便的。

9.核实签署装置

如果事务214的签署者是一个装置(或由装置封装的客户私人密钥)，那么信赖管理器218根据该装置产生的签字的历史来检验其异常(核实装置，步骤S236)。信赖管理器保存事务记录，具有发出者名字，证件编号，签字序列号，以及收到消息216的日期和时间。

在某一时间段之后，信赖管理器搜索这些事务并检验过去事务的序列号和日期-时间值中的异常。如果该装置有制造者指定初始值和增量，则序列号被检验以确定它们是否遵循该正确序列。

如果发现了序列外的值(例如计数器值对不同事务重复，相对于伴随的时间标记不按顺序，或自前一个值到当前值有一个大的不能解释的空隙)，对那个装置和那个客户的证件应立即被吊销。所以，发证的认证机构应得到通告，从而他们能把这用户和装置证件放到适当的CRL中。信赖管理器218还可能通知装置所有人/客户，如果知道的话，以及发证的认证机构或保证人，装置制造者，可能还有法律执行机构。

信赖管理器218能使用义务跟踪服务器220去读和写装置签字编号的当前值。每个装置证件236或每个客户证件204可在义务跟踪器220中有一相应的条目。信赖管理器可在每次处理一个签字时更新这全局签字编号条目。这样，便能更迅速地检测到重复的或欺骗的签字。

10.得到保险

在某些情况中，信赖管理器218可以得到保险(步骤S238)，或者是复盖它自己在证实一个事务时可能的风险，或者代表一个认证机构或保证人。通常，信赖管理器将是一个或多个保险公司的被授权代理，它被授权代表它们去写小签字担保政策，服从预先建立的条款和条件和保险费率。RMR(收据)将列出信赖量、所付费用，还可能可选地列出承担签字担保的保险公司的名字。

11.信赖管理器对信赖方的响应

在信赖管理器218已经核实了消息216(达到信赖方212请求的程度)，已对适当各方发出了帐单和通告，已发出了或购买了适当的保险并把所需要的记录存储起来。之后，信赖管理器218便创建一个信赖管理器响应(RMR)226，它由信赖管理器数字签署，并通过消息216发送所用同样方式，如插座、HTTP、电子邮件等，送回到信赖方212(步骤S240)。数据226在发送给信赖方212之前可由时间标记服务器228打上时间标记。时间标记服务器最好是不同的和合法的实体，从而若这个或那个(信赖管理器或时间标记服务器)被假冒，那么至少看上去回溯有效事务是不可能的。

收据226包括以下信息：

1.信赖管理器218的标识。

2.这个收据的唯一标识(序列号)。

3.信赖方212标识(以及可选的它的地址)。

4.信赖方的唯一消息序列号。

5.被检验消息的混编。

6.处理的日期和时间(声明值)。

7.请求结果，包括：

·证件状态检验是否可接受，

·量是否在请求的信赖限之内，以及

·消息是否被存档，如果存档了，一个存档提取识别号。

8.如果任何状态检验失败，一个由证件给出的状态/理由代码清单。

9.信赖方请求的信赖限(可能为零)。

10.如果签署人(客户202)超过她的限，是否该服务(信赖管理器218)支持超限例外处理。

11.如果曾由信赖方请求超限处理，为此使用了什么方法。

12.如果状态检验和信赖限是可接受的，由被检验证件付费清单，要由客户和/或第三方付款的总费用，以及要由信赖方帐户付款的总费用。

13.该消息先前是否已被检验过，以及客户/保证人是否在财源之外。

14.状态检验服务218的签字。

15.时间标记服务器228的签字和时间。

2.B.6  状态检验费的考虑

即使检验失败，也可以有对每个请求的证件检验的基本收费。在某些情况下，如果证件是可接受的，则可以有较高收费，即使具有零信赖值也如此。

2.B.7  超限担保(OLG)请求

如果信赖方212请求一个超限担保，那一方向信赖管理器218发出一个超限担保(OLG)请求(作为消息216)。OLG请求用于请求一个担保，该担保超过了与事务214关联的证件中所声明的信赖限。

OLG请求包括请求人的名字和网络地址，用于这个OLG请求的唯一标识(序列号)，用于发帐单的帐单服务帐户号，证件发出者名字和序列号清单，以及对于这次状态检验服务的：

1)签字序列号(如果存在的话)；

2)被检验的消息的混编；

3)被引述的超限担保费费用；

4)请求的日期和时间；以及

5)核实者的签字，用于对存款或帐单帐户收费。

信赖管理器218以与RMR响应类似的响应来响应一个OLG请求消息，不同的是信赖管理器218承认和担保信赖方请求的超限信赖量。

2.B.8  信赖方的最后处理

当信赖方212从一信赖管理器218得到一个收据226时，它首先查看收据226中声明的信赖方标识，以检验收据226是否已被发送到这正确的信赖方212。接下来，信赖方212把收条226与它发送出去的消息216关联。为进行这种关联，信赖方212检验收据226中的唯一消息标识(序列号)之值。如果信赖方212没有发现与此收据226对应的消息216，或者如果这收据被送到了错误的信赖方，这接收者或者可以通知被发现不一致性的信赖管理器，或者只是忽略这一收据并什么也不做。

如果信赖方212已经确定它是该收据226的正确接收者，而且已发现了对应于此收据的消息216，则信赖方212核实信赖管理器的签字并评估这收据以确定信赖管理器的处理结果。换句话说，信赖方212审查该收据226，以确定消息216是否通过了所请求的证件状态检验；是否量在所请求的信赖限内；以及该消息是否被存档。如果消息被存档，则信赖方存储这存档提取标识号。

然后，信赖方212分解和存储收据226，用作为一份通知书。应该指出，该收据只对这一指定的信赖方是好的，而其他方若没有付附加的签字保证费则不可以信赖它。在已提交一个先前收据的地方，对于这同一文件或事务信赖管理器对后来的各信赖方可以提供减价。

接下来，如果收据226指明状态检验和信赖限是可接受的，则信赖方212评估、记录和扣除由账单服务224要它的帐户所付的费用。

如果由于客户202超过它的限度而使状态检验失败，则信赖方由收据226确定信赖管理器218是否支持超限例外处理，然后决定是否请求这种处理。

请记住，特定的事务214可能要求把那些消息送到不只一个信赖管理器218。在信赖方212能作出诸如是否继续进行该事务214这类最后决定之前，它必须等待所有信赖管理器以收据226作出响应。于是，信赖方212进行检验以确定对于与这个收据/消息对关联的事务是否有任何未决的信赖管理器请求。如果没有，则信赖方能继续与客户202进行的事务214，否则它继续等待来自其他信赖管理器的对与事务214关联的其他消息216的回答。

根据所有收据226(对应于一特定事务)中报告的结果，信赖方212能继续该事务。就是说，在已完成所有检验和收到担保和保险之后，它现在可以继续进行对该事务的实际信赖了。

2.C  用户证件形式

图11显示用于这里公开的系统的典型签署人证件的元素。所示证件是一个ITU X.509证件，而附加域可以是如X.509版本3中规定的扩展。每个可以是单独的扩展，或者全部“信赖说明”可以是一单个版本3扩展，它含有多个内部元素，或者是这二者的某种组合。

如图11所示，信赖说明可至少包含：

1.不推荐或不保证信赖超过某一标称量；如果损失经验表明较高值不会使CA、或它的保险人和再保险人面对过度的风险，则这个量可以增大。

2.至少一个由发证件CA认可的状态检验服务的名字和可有可无的网络地址。如果使用了X.500目录查询系统，那么名字和地址将是同样的一个。否则，可能必须指定一个有效的网络地址和通信手段。

3.为完成本实施例中描述的服务所需其本费用表，包括状态检验消息(SCM)，信赖担保请求(RGR)，超限担保(OLG)，以及“不信赖”功能(下文描述)，在这项功能中信赖方自愿同意放弃它的部分或全部信赖-给定签字的权利，从而使签署人对当前时间段的信赖限被释放一部分，于是这部分能被用于其他事务。

4.一个可选用的域，用于同意允许状态检验服务向发送人/签署人或另一第三方(通常是签署人的雇主或保证人)收取签字担保费，而不是要求信赖方付款。当使用这一特性时，状态服务将保持对签字编号(如别处描述的那样)或签字值(或由它们导出的某值)的记录，以防止同一或不同信赖方不只一次地利用这第三方付款特性。就是说，状态服务将检测出一特定数字签字(先前已被检验或被保险过，并将拒绝以其保证人付费来再次检验它的任何企图，这种企图会造成保证人资金的浪费。

5.当被授权时，第三方的名字和帐户号，该第三方已同意承担状态检验和担保费。

另一种作法是，所考虑的证件可能不是一个把客户名字与一公用密钥链接的标识证件，而是一个与一标识证件结合把某种特权或授权授予该客户的证件，如美国专利申请序列号08/682,071中描述的那样，该申请题为“在商业密码系统中安全使用数字签字的方法”，其内容在此全部引用作为参考。这与第一实施例中的“次级证件”不会混淆，它与第二实施例中的签字担保收据类似。这种授权证件也可以有一个相关联的事务限系统，它需要由一个信赖管理器管理，因此将需要把与前述相同或类似的一组“信赖说明”域加到该证件中。

2.D  报价请求

状态检验服务还可以包含一个报价请求指示并带有一声明的信赖量，这将使信赖服务发出完全签字担保费用的报价，但没有实际发出担保。

由信赖管理器发出的报价包含一个唯一标识，它能由信赖方结合其后的签字担保请求一起使用。如果在原始状态检验之后不久由信赖管理器收到担保请求，那么能发出担保而不需再次进行状态检验的计算开销。此外，该报价可以规定一个时间段，在此期间无需再进行检验就能发出此担保。通常，在这一时间段过去之后，报价将仍然有效，但得要再次进行状态检验，再次造成状态检验费。

2.E  “不信赖”功能

在一信赖管理系统中，对于一给定的时间段，发证CA通常对每个客户赋予一个固定的信赖限。例如，对于具有某种次要采购授权的较低级雇员，可以给予每月$1000元的信赖限。然而，将会有大量的事务由于这样或那样的原因在它们被购买了签字担保的未来信赖方进行状态检验之后不能通过，从而耗尽了对所考虑时间段签署人被允许的信赖限。

如果一月时间段快要到了，签署人会只是等待再一天的到来，从而系统能把他的信赖限再设回$1000元。然而，如果他已经承诺了他的限度的大部分，而且需要完成额外的事务，这将不足以允许他继续工作而不予以干预。

对于这一问题的直接解决方案是允许信赖方通常按他独自的判断，作为对签署人/客户的一种适应，向信赖管理器发送一个签署的事务，声明不再打算信赖所考虑的事务，从而减轻信赖管理系统为可能是不真实的事务进一步面对和承担支付损失的责任。用户的信赖限能被完全地重新给予信贷，当然系统将保留状态检验费和可能一部分签字担保费。

作为一种扩展，信赖方可以在试图执行一个事务时部分地信赖签字，但其后该事务决不会完成。例如，一个顾客可能向一个股票经纪人发出一个“限量定单”，然后这股票经纪人试图按顾客指定的价格执行这一定单，但由于市场上价格的涨落，这定单从未被执行，因为价格要求从未得到满足。在这种情况下，信赖管理系统已经面对这样的危险或风险，即这个定单可能已被使用一个不真实的签字放入位置了，所以担保费的一些部分已被赚到(可能按要做的事务费来计算，但其后又取消了这笔交易)，但该系统当未暴露于主要损失的完全风险，这种主要损失风险会在根据一伪造的事务发布对某未知人的担保时发生。

各种主要事务系统的各方能事先同意关于失败事务的再信贷计划，或可可能由信赖方(例如股票经纪人)选择吸收费用并由来自可盈利事务的交叉补助来补充它们。这种费用回缴和信赖释放计划也可是信赖管理器服务承诺的元素，并可以出现在信赖服务、客户或经纪人的证件中。

“不信赖”事务参考信赖方已从指定签署人那里收到的指定的先前事务，先前已经根据这一事务发出了担保，当信赖方在状态服务中没有帐户的情况发生时，这“不信赖”事务将声明这老的和新的(较小的，可能是$0元)信赖量，它由具有附带证件的信赖方签署。状态服务将为当前时段向签署人/客户的信赖限再信贷这一差值。

2.F  签字担保时段

在如这里描述的数字签字信赖管理系统中，最好是对数字签字的可信性做出支持(担保、保险等)，这里担保时段的起止时间可由各方选定。这样作的主要理由在于：如果保险商们的风险已通过这种附加手段适当地降低了，那么他们便可能因此而降低担保费用。

信赖数字签字的最高度风险一般来自刚一收到这签字的时候，因为这签字可能是被一未授权人造成的，他不正常地得以进入合法用户的签字装置(可能是偷窃了它)并得知它的启动代码或PIN号，但对于合法用户而言，那时没有足够的时间去检测这盗窃行为和与CA接触请求吊销他们的证件。的确，这段风险时间是这样一段时间，对于这段时间，这里描述的信赖管理服务允许交易及时地进行，即使面对可能的伪造品损失也是如此，其做法是把那些损失化解到一个基于保险的系统中。

a.信赖延迟开始

当一个预期的信赖方处于这样一个地位，即它在实际信赖一个事务之前“持有”它达数小时，数日甚至数周，这时状态服务可能能提出一个较低的签字担保费报价，因为推想的签署人将有多得多的时间去检测和报告他们的签字装置被盗或被未授权使用。当预期的信赖方从信赖服务购买一个担保而这担保能在其后被报告给签署人/客户作为他们周期性纸面或电子声明的一部分，在这样情况下这种风险降低效果最大。当签署人见到这未授权事务，他们能把它报告给状态服务，然后状态服务能在信赖方实际信赖该事务之前通告信赖方。由几乎任何程度的延迟都能实现较小些的风险降低效果，即使小到一至二小时也是有效的，因为这能给合法用户更多时间去发现他们的签字装置丢失并向他们的CA和信赖方报告这一情况。

b.减小信赖拖尾

保险商宁愿假定有较短复盖时间段的风险。一些数字签字可能需要长期被信赖。例如保护议定书、抵押、遗嘱、法律或条约的数字签字可能需要对二十年或更长时间保持可核实和可靠，而主要的商业合同可能需要长达十年的信赖。然而，大量的小事务可能在几周或几月内了结和被忘记，在此之后一个真实的数字签字不再真正被需要作为证据，因为现在有许多其他事实存在，它们能防止签署人否认签字的真实性。例如，如果购买或出售物品、服务或金融手段的合同已在双方完全完成，而且已过去了若干月，那么信赖方可能不再感觉强烈需要被保护以针对一个关于假冒或欺诈的迟到声明。所以，信赖方能(a)从信赖服务请求一个缩短的担保时间段，或(b)在某点上发出一个不信赖事务，以试图恢复一部分所付信赖担保费。

图12以图说明在前一段中讨论的风险、时间、及费用考虑。每当可能时，成熟的信赖方将只对它的实际暴露部分寻求保险，从而降低它的担保费。在所示实例中，(a)在时间T1之前(在此时间之后一个未报告的假冒带来的风险已显著降低)和(b)在时间T2之后信赖方将不需要信赖该事务，这样消除了需要一个“长拖尾”保险来复盖长时间直至未来。为签字担保所付保险费可以与标为T1和T2的两条垂线之间在曲线下方的面积成比例。

c.多阶段信赖价格

在许多商务活动中，一个文件可能被不同方为不同目的多次信赖。一个实例可能是一个结束的交易，其中资产清单(a)被传送给在预期的一个可能贷款或供给资金的贷方或投资人，和(b)作为财务协议下的安全协议的一部分被认证和存档，以此作为结束交易过程的一个要素。另一个实例可能是一个车辆资格，信赖这一车辆资格以得到(a)购买或租用该车辆的资金，(b)义务保险，(c)车辆牌照。然而，总是有这种可能性，即该事务在进行过程中在任何一步被延迟或被放弃。所以，在一个预定义的多阶段事务的前后关系中，信赖服务可以对发给同一或不同各方的同一文件上同一签字的一系列担保报出一个打折扣的价格，然后根据正在完成的阶段对每一方收费。

于是，给状态服务的信赖请求消息将包括一个事务类别和唯一标识，它标识一特定类型多阶段事务(例如住房抵押结束)的起始和继续，并对每个事务阶段或对全部阶段作为一体给出特定价格报价。如果声明为给定阶段所用的事务收据实际上对事务的不同阶段被信赖，则该担保将被避免。

2.G  有价证券风险管理

在另一实施例中，CA或其他保证人向信赖服务器数据库发送一个数据值数组，描述签署人/客户(和他们属于的任何公司或团体)的所允许的活动，并提供信赖服务器可以响应发送给它的要状态检验和签字担保(确认)的事务，独立地管理那些数据值的每一个。

例如，一个金融机构可以雇用各种代理人组去执行不同类型的金融事务，还可以通过实施关于各类风险的公司范围政策来寻求限制它的金融风险，然后对将会违反这些政策的事务不允许或要求特殊的许可。通常，公司的信贷和风险管理部发展和管理这些限制。一些实例包括下述情况：

1.管理“信贷风险”。“信贷风险”是指对方将没有能力为未决事务付款(结算)的风险。为管理“信贷风险”，公司将规定对未付清的与每个对方的交易所允许的最大暴露量，从而使当前应付给对方的或从对应得到的钱或保证量不能超过一个规定值，例如$5千万。当能得到新信息时，这些限制可能被调整，这些信息或者增大或者减小给定对方或给定一类对方的值得信贷程度。

2.管理“货币风险”。“货币风险”是指外币价格突然变化造成的风险。为管理“货币风险”，公司可以规定以特定外币(例如日元)为单位应付给对方或应从对方得到的钱或保证量不能超过某个规定值，例如20亿美元。这样，如果日元对美元的兑换率发生突然的大变化，公司的最大总风险是事先已知和受到控制的。

3.管理“政治风险”。“政治风险”是指给定国家政府可能实施不利的经济或法律政策(包括最坏的情况即没收外国人所有的资产)的风险。为管理“政治风险”，公司可以规定与每个国外经济(如南非)相连系的保证总量不能超过某一规定值，例如10亿美元。这样，如果南非政府突然夺取全部外国资产并拒付外债，公司的最大总风险是事先已知和受到控制的。

4.管理“区域或产业风险”。“区域或产业风险”是指与特定地理区域(新英格兰、Rust Belt、东欧、硅谷等)或产业类型(钢铁、汽车、航线、化工、计算机等)相关联的金融资产(如股票或证券)具有的风险。为管理“区域或产业风险”，公司可以规定与每个给定区域或产业关联的保证总量不能超过某一规定值，例如5亿美元。这样，如果油价涨到四倍，造成航线股票值下跌，公司的最大总风险是事先已知和受到控制的。

由于每日的事务被结算，公司对于每类风险限的未结束的暴露被重新计算和重新初始化，从而使雇员们能进入其他事务。考虑到所察觉的每类风险中的反复无常和风险的程度，外部限度本身被周期性地审查和调整。此外，在人工或半自动基础上可能造成例外或系统负担过重，如果对于公司容忍额外风险而言存在足够的业务案例，可能只是在短时基础之上。

前述风险及其他类似情况可由象这里描述的那类信赖服务进行集中和自动管理，只要向信赖服务器提供每个要检验事务的数据内容。在事务被公司运行的或与其签定合同的中央信赖服务所确认之前，这些事务是无效的。公司周期性地(通常是每日地)以当前授权限更新信赖服务数据库，而在当时期间事务流针对这些限度工作。当然，某些事务会减小暴露量，例如(a)卖出日元买美元，或(b)卖出General Motors(通用汽车公司)股票得到现金将分别增大对于日元(货币)和汽车工业可能得到的暴露限。再有，交易的过夜结算将减少对方公司应得或应付货币量，从而释放了部分或全部他们被允许的信用限。

因此，信赖服务器被修改，以存储为管理风险暴露限所需的信息，这风险暴露限是作为给定公司雇员发起的事务的结果而产生的。公司定期地更新这种信息，而信赖系统根据呈现给它供信赖检验的事务来减小或增大可得到的限度。

这个系统能产生很大的费用节省和效率提高，因为它(a)提供了方便的中央点去管理所有这些事务，不只是为一个公司而是为许多公司，从而可代替许多零碎的系统，那些系统往往事后才被管理，而且(b)它能有效地实际几乎100％的符合，因为除非由状态/信赖检验服务会签，否则事务是无效的并将不能被付款。

这种系统还能响应由政府或贸易组织所加的控制，在地区、州或国家一级实施经济政策，如实施货币兑换控制，或限制特定货物的进口或出口。就是说，一个政府实体或贸易组织可能会根据事务的内容、方向、货币量等(类似于前述公司范围的系统)拒绝实施这些事务或对它们课以不同的税款。对于寻求符合该控制系统的所有事务，可能需要一个来自指定信赖服务的收据。于是，这信赖服务能实施一套限制，例如设计来在发展中国家保存不足的外汇储备的限制。

这样，提供了一个用于电子事务系统的信赖管理器。本领域的技术人员将会理解，本发明能由不同于所描述的实施例的方式实现，这些实施例是为了说明的目的而展现的，并不是为了限制，本发明只由下面提出的权利要求来限定。

Claims (61)

1.电子事务系统中管理信赖的方法，该方法由以下步骤组成：

(A)认证机构向一客户发出电子信号，这些电子信号代表一个证明，证明该客户的至少一个公用密钥与至少一个属性连接；

(B)从认证机构向一信赖服务器传送电子信号，这些电子信号代表有关被发出的证明的信息；

(C)信赖服务器保持被传送的关于所发出证明的信息；

(D)客户构成一个事务，然后将代表该事务的电子信号提供给信赖方，该事务包括代表该证明的电子信号；

(E)信赖方向信赖服务器发出电子信号，这些电子信号代表根据从客户那里收到的事务提出的保证请求；

(F)信赖服务器确定是否提供所请求的保证，所述确定是根据关于发出的证明的信息，根据所请求的保证；以及根据所述确定，

(G)信赖服务器向信赖方发出电子信号，这些电子信号代表向信赖方提供保证的授权消息。

2.如权利要求1中的方法，这里该证明指定一个信赖限，而且这里被认证机构传送给信赖服务器的信息包括代表保证参数的电子信号，这些保证参数控制信赖服务器是否能根据该证明提供保证。

3.如权利要求2中的方法，这里保证参数包括代表超过证明中指定信赖限的一个可接受信赖限的电子信号，而且这里的保证请求是一个对超过指定信赖限的值的信赖请求，这里信赖服务器确定是否提供所请求保证的步骤(F)包含步骤：

(F1)确定所请求信赖是否会超过可接受信赖限。

4.如权利要求3的方法，还包含步骤：

(H)信赖服务器跟踪与该证明关联的累积义务，以及

这里“确定”步骤(F1)包含步骤：

(F2)确定所请求信赖是否会使累积义务超过可接受信赖限。

5.如权利要求2中的方法，这里所请求的保证是为了另一证件的准确性，而且这里步骤(F)进一步包含步骤：

(F1)信赖服务器检验另一证件的当前有效性和真实性；而且这里的“发出”步骤(G)包含步骤：

(G1)信赖服务器发出电子信号，这些电子信号代表证明这另一证件准确性的授权消息。

6.如权利要求5中的方法，这里的“检验”步骤(F1)包含以下步骤：

沿着一个证件链核实这另一证件的数字签字，以及

检验所请求保证是否在保证参数之内。

7.如权利要求2中的方法，这里所请求的保证是为了另一证件的真实性，而且这里步骤(F)进一步包含步骤：

(F1)信赖服务器检验另一证件的真实性；而且这里的“发出”步骤(G)包含步骤：

(G1)信赖服务器发出电子信号，这些电子信号代表证明这另一证件真实性的授权消息。

8.如权利要求7中的方法，这里的“检验”步骤(F1)包含以下步骤：

沿着一个证件链核实这另一证件的数字签字，以及

检验所请求的保证是否在保证参数之内。

9.如权利要求2中的方法，这里所请求的保证是为了另一证件的有效性，而且这里步骤(F)进一步包含步骤：

(F1)信赖服务器检验另一证件的当前有效性；而且这里的“发出”步骤(G)包含步骤：

(G1)信赖服务器发出电子信号，这些电子信号代表证明这另一证件有效性的授权消息。

10.如权利要求9中的方法，这里的“检验”步骤(F1)包含以下步骤：

确定这另一证件是否已被暂停、吊销或已经过期，以及

检验所请求的保证是否在保证参数之内。

11.如权利要求2中的方法，这里所请求的保证是为了保证一代理人的职权，

而且这里步骤(F)进一步包含以下步骤：

信赖服务器返回电子信号，这些电子信号代表代理人文件，该文件带有证明其真实性的封装授权消息。

12.如权利要求11中的方法，这里的代理人文件包括一个授权书。

13.如权利要求2中的方法，这里所请求的保证是为保证某人的任命，而且这里步骤(F)进一步包含以下步骤：

信赖服务器返回一个由特许的或专业的单位提供的关于此人任命的声明，并带有电子信号代表证明声明真实性的封装授权消息。

14.如权利要求2中的方法，这里所请求的保证是为保证实体的存在和/或良好状态，而且这里步骤(F)进一步包含以下步骤：

信赖服务器返回电子信号代表由该实体加入的公共办公室提供的声明，指明该实体存在，处于良好状态，并有资格进行业务，这里的声明被封装在一个证明该声明真实性的授权消息中。

15.如权利要求2中的方法，这里所请求的保证是为保证一个契约的性能，而且这里步骤(F)进一步包含以下步骤：

信赖服务器发出电子信号代表一个付款保证声明，这里的声明被封装在一个证明该声明真实性的授权消息中。

16.如权利要求1中的方法，进一步包含步骤：

(I)在信赖服务器发出授权消息之前信赖服务器和信赖方进入一个合同。

17.如权利要求16中的方法，这里的合同是在信赖方作出它的请求之后被进入的。

18.如权利要求2中的方法，这里该事务包括代表一数字签字的电子信号，而且这里的保证参数包括代表能对一特定数字签字发出的最大补充保证的电子信号。

19.如权利要求2中的方法，这里的保证参数包括的电子信号代表至少以下各项之一：

在单个授权消息中能被发出的最大补充保证；

能对任何特定信赖方发出的最大补充保证；

能在一个或多个指定时间间隔内被发出的最大补充保证；

关于这一保证能被发出的授权消息数量最大值；

一授权消息能保持有效的最大时间段；

在一个授权消息中能被列出的对一指定事务类型有效的最大信赖限；

为了为补充保证提供基础，信赖方必须与其请求一起提交的指定信息；

客户已预付的补充保证量以及对于在一个授权消息中如何能发出预付保证的限制；

一个要求，即要求在信赖方对授权消息的请求能被允许之前，客户要认可由信赖服务器为向信赖方发出的授权声明发出补充保证；

使信赖服务器的认证机构发出报告的触发阈值；

信赖服务器应向认证机构报告该证明上所发出的补充保证范围的经常程度；

代表限制的信号，这限制限定了公开和访问发给指定各方的证明；

该事务应由客户以外的附加方签署的要求，可选项是指定这些附加方是谁以及它们有多少必须签署；

根据签署的附加方的数量和标识，所能发出的补充保证量的尺度；以及

关于此证明有效性的信息。

20.如权利要求19中的方法，这里一个保证参数能被限定在一特定的时间段内。

21.如权利要求20中的方法，这里该特定时间段是该证明有效的整个时间段。

22.如权利要求19中的方法，这里的指定信息包括的电子信号代表已向信赖方承诺的某一特定证件类型，一事务类型的说明以及一个第二签字。

23.一个电子事务系统，包含：

向该系统客户发出代表证明的电子信号的认证机构，每个所述证明代表一个把客户的至少一个公用密钥与至少一个属性连接起来的证明；以及

能与该认证机构连接并从该认证机构接收电子信号的信赖服务器，这些电子信号代表关于由该认证机构发出的证明的信息，信赖服务器一收到来自信赖方的请求消息，所述请求消息包括基于事务的信息，便向信赖方发出代表一授权消息的电子信号，这种发送是根据认证机构提供的信息和由信赖方提供的基于事务的信息。

24.如权利要求23中的系统，还包含：

至少一个能与该信赖服务器连接的其他方，这里信赖服务器在向信赖方发出代表授权消息的电子信号之前，先向这其他方提供代表这授权消息的电子信号。

25.如权利要求23中的系统，这里信赖服务器在向信赖方发出授权消息之前，信赖服务器先对这授权消息数字签署。

26.在一个电子事务系统中，一个认证机构向客户发出代表数字证件的电子信号，一种自动替换客户证件的方法，该方法包含以下步骤，由客户：

(A)创建一个备用申请，用于认证一个新的密钥对；

(B)用私人密钥数字签署这备用申请，然后毁掉这私人密钥；

(C)在一个只对备用申请有效的事务证件中包括代表与该私人密钥相对应的公用密钥功能的电子信号，并把这事务证件传送给认证机构；以及由认证机构

(D)保持代表这事务证件的电子信号；以及接下来，

(E)客户向认证机构发送代表该备用申请的电子信号；

(F)认证机构通过参考这事务证件来核实申请上的数字签字；然后，如果核实成功，则

(G)发出代表新证件的电子信号，这新证件列出了在备用申请中指出的公用密钥。

27.在一电子事务系统中管理信赖的方法，在该系统中客户有由认证机构发出的数字证件，该方法包含以下步骤，由信赖方：

从一客户那里接收代表一事务的电子信号，该事务包括关于该客户的至少一个证件的信息；

根据来自该事务的证件信息创建一个消息，该消息规定信赖方意欲信赖的事务值；以及

向一信赖服务器发出代表该消息的电子信号，请求对信赖方意欲信赖的事务值以供担保。

28.如权利要求27中的方法，还包括以下步骤，这信赖方：

接收代表一凭单的电子信号，这凭单是由信赖服务器响应发送消息步骤而发出的；以及

根据凭单中的信息继续与客户进行该事务。

29.在一电子事务系统中管理信赖的方法，在该系统中客户有由认证机构发出的数字证件，该方法包含以下步骤，由信赖服务器：

接收由一方发出的代表信赖请求消息的电子信号，该消息指定该方意欲信赖的事务值并请求为该事务值提供担保，该消息包括从该事务中导出的证件信息；

确定是否为该事务值提供担保；以及

向信赖方发出代表一个凭单的电子信号，该凭单包括该信赖服务器是否对该事务值担保的指示。

30.如权利要求29中的方法，这里的“确定”步骤进一步包含以下步骤：

确定与该事务关联的证件是否已被吊销或暂停。

31.如权利要求30中的方法，还包含以下步骤：

从认证机构接收代表一证件实际信赖限的电子信号；

存储这实际信赖限；以及

确定所请求量是否超过该实际信赖限。

32.如权利要求31中的方法，这包含为一认证机构保持累积义务量的步骤。

33.在一电子事务系统中管理信赖的方法，该方法包含以下步骤，由认证机构：

向客户发出代表一证件的电子信号，该证件规定了声明的信赖限；以及

向信赖服务器传送代表该证件实际信赖限的电子信号，该实际信赖限不同于声明的信赖限。

34.在一电子事务系统中管理信赖的方法，该系统中客户有数字证件，该方法包含以下步骤，由信赖方：

接收来自客户的代表一事务的电子信号，该事务包括关于那个客户的至少一个证件的信息；

根据事务中的证件信息创建代表一消息的电子信号，该消息规定了信赖方意欲信赖的事务的一个方面；以及

向一信赖服务器发出代表该消息的电子信号，请求对信赖方意欲信赖的该事务方面提供担保。

35.如权利要求34中的方法，还包含以下步骤，该信赖方：

接收代表来自信赖服务器的回答收据的电子信号，该收据是对发送该消息步骤的响应；以及

根据回答收据中的信息与客户继续进行该事务。

36.如权利要求34中的方法，这里一些客户证件有相关费用，该方法还包括以下步骤，该信赖服务器：

根据与该事务关联的证件的费用，定出它的服务费。

37.如权利要求36中的方法，这里费用包括使用费、担保费和查询费。

38.如权利要求35中的方法，这里的消息请求证件状态检验，回答收据指明这证件状态检验是否是可接受的。

39.如权利要求35中的方法，这里的收据指明信赖服务器是否担保信赖方意欲信赖的那个事务方面。

40.如权利要求34中的方法，这里信赖方意欲信赖的那个事务方面规定一个货币值，而收据指明信赖服务器是否为那个货币值担保该事务。

41.如权利要求40的方法，这里信赖服务器的担保是根据与该事务关联的证件中指定的信息。

42.在一电子事务系统中管理信赖的方法，在该系统中客户有数字证件，该方法包含以下步骤，由信赖服务器：

接收代表来自一方的消息的电子信号，由该消息请求对该事务一个方面的担保，该消息包括从该事务中导出的证件信息；

确认该消息中信息的有效性，以确定是否为该事务方面提供担保；以及

向信赖方发出代表一回答收据的电子信号，该回答收据包括对信赖服务器是否担保该事务方面的指示。

43.如权利要求42中的方法，这里的“确认有效性”步骤还包含以下步骤：

确定与该事务关联的证件是否已被吊销或暂停。

44.如权利要求43中的方法，这里在消息中包括的证件信息包括与该事务关联的证件的唯一标识，而且这里的“确定”步骤还包含以下步骤：

在至少一个含有证件信息的清单上查寻唯一证件标识。

45.如权利要求43中的方法，这里的“确定”步骤是根据先前得到并维持的关于证件的信息完成的。

46.如权利要求43中的方法，这里对其请求担保的事务方面是一个货币信赖值，而且这里与该事务关联的至少一个信号规定一个货币限，这“确认有效性”步骤还包含以下步骤：

确定货币信赖值是否在该信号中指定的货币限内。

47.如权利要求46中的方法，这里的“确定”步骤还包含以下步骤：

得到对该证件的当前累积货币义务值；

确定货币信赖值与当前累积货币义务之和是否会超过指定的货币限；以及根据这一确定：

更新当前累积货币义务。

48.在一电子事务系统中管理信赖的方法，该方法包含以下步骤：

认证机构向客户发出代表一证件的电子信号；

从认证机构向一信赖服务器传送代表关于此证件信息的电子信号，该信息包括该证件的唯一标识和该证件的实际信赖量；

客户根据该证件构成代表一事务的电子信号，并把该事务传送给一信赖方；

信赖方向关注此事务的信赖服务器发出代表一信赖请求消息的电子信号；

信赖服务器检验信赖请求中的信息，并根据检验结果；

向信赖方发出代表一事务证件的电子信号作为凭单。

49.如权利要求48中的方法，这里的证件包括一个为零的声明信赖限。

50.如权利要求48中的方法，这里该证件声明只能做成对该证件的信赖，如果该证件被一信赖服务器检验过的话。

51.如权利要求50中的方法，这里该证件指定该信赖服务器。

52.权利要求50的方法，还包含信赖服务器数字签署该事务证件的步骤。

53.如权利要求50中的方法，还包含如下步骤，由信赖服务器：

把代表该事务证件的电子信号传送给至少一个其他方；

从另一方接收代表这事务证件的电子信号；以及

数字签署该事务证件。

54.如权利要求53的方法，还包含其他方数字签署该事务证件的步骤。

55.如权利要求48中的方法，这里信赖请求消息指定一个该信赖方意欲信赖的事务值。

56.如权利要求55的方法，这里的“检验”步骤包含确定所指定量是否会超过证件实际信赖限的步骤。

57.如在权利要求27-56的任何一个中的方法，这里的证件是基于时间的证件。

58.如在权利要求1-18或23-25的任何一个中的方法，这里所述授权消息包含一个次级证件。

59.如权利要求42中的方法，这里“确认有效性”步骤还包括以下步骤：

确定与该事务关联的证件是否对该证件的时间有效。

60.如权利要求26中的方法，这里公用密钥的功能是该公用密钥的混编、该公用密钥的密码以及该公用密钥本身之一。

61.如权利要求46中的方法，这里与该事务关联的信号包含至少一个证件。

Images