CN1682490B - 从多证书管理机构报告组件检索证书状态时远程访问使能信托和互用服务的系统及方法 - Google Patents

Abstract

公开了可配置的、直接的并且能够从任何批准的证明管理机构(CA)中检索状态的证书状态服务。CSS可以为信托监管实用程序(TCU)和类似的系统或应用所使用，它们的任务就是确认个体的权利以便执行必要的动作，确认所提交的电子信息对象的可靠性，以及确认数字签名核实和用户验证过程中使用的验证证书的状态。有关验证证书的有效性检查是通过查询发行CA来执行的。传统上讲，为了创建确认证书所需的信托公用密钥基础结构(PKI)，通过CA之间的交叉证明或者通过利用PKI桥接器来形成复杂关系。从不同的角度解决PKI和CA的互操作性问题，同时集中于建立适合于电子原始信息对象的创建、执行、维护、转让、检索和销毁的信托环境，所述电子原始信息对象也可以是可转让的记录(所有权可以转手)。TCU仅仅牵涉到一组已知的“经批准的CA”，尽管它们可以支持众多的商业环境，并且在那组CA内，仅仅牵涉到那些与TCU用户帐户相关联的证书。不需要构造PKI/CA信托关系，因为CSS通过仅查询经批准的CA并且维护有效证书状态的高速缓存而达到信托环境。

Description

从多证书管理机构报告组件检索证书状态时远程访问使能信托和互用服务的系统及方法

背景技术

申请人的发明涉及用于为诸如电子原始^TM文档之类的电子原始信息对象的创建、执行、维护、转让(transfer)、检索和销毁提供一系列可核实的凭证和安全的系统和方法。 

在确认个体的权利以执行必要的动作、确认所提交的电子信息对象的可靠性以及确认数字签名核实和用户验证过程中使用的验证证书的状态的过程中，本发明有利地将申请人的保存电子原始记录的信托监管实用程序(Trusted Custodial Utility)和保存类似系统任务用作为虚拟电子保险柜(vault)。在美国专利No.5,615,268、No.5,748,738、No.6,237,096和No.6,367,013中描述了这类TCU和操作。 

在本说明书中使用下列缩写表： 

缩写 

CA证明管理机构 

CRL证书撤销列表 

CSS证书状态服务 

HTML超文本标记语言 

ID标识 

IETF因特网工程任务组 

ITU国际电信联盟 

LDAP轻型目录访问协议 

OCSP在线证书状态协议，IETF-RFC 2560 X.509因特网公用密钥基础结构在线证书状态协议-OCSP，1999年6月 

PIN个人识别码 

PKCS公用密钥密码标准 

PKI公用密钥基础结构 

PKIX公用密钥基础结构(X.509) 

S/MIME安全通用因特网邮件扩展 

SCVP简单证书认证协议，草案-IETF-PKIX-SCVP-06，2000年7月 

SSL安全套接层 

TCU信托监管实用程序 

UETA统一电子交易法案 

XML可扩展标记语言 

美国的全球与国家商业电子签名法案(ESIGN)法规中以及在1999年仿效由统一州法国家专员会议起草并且批准以及推荐用作条例的UETA的美国国家法律的通过使得应用于信息对象的电子签名的合法性成为可能，这已经导致所述电子签名的信息对象已经针对实现这些潜在的完整电子交易的效率与节约而引发政府、银行和电子商务活动。 

PKI和CA都是在创建电子源记录过程中使用的数字签名技术的基本元素。PKI是CA的集合，其中通过创建CA之间的层次关系或者通过在协作CA中的交叉证明而在用户与用户机构之间建立信用。给CA授予发行验证证书的权力，所述验证证书将个体的身份或实体的身份绑定于他或它的公用密钥(核实)，其中只给个体访问匹配私人密钥(签字)的权利。在这种应用时，证书通常符合ITU X.509证书标准并且通过发行CA来为自身数字签名。例如，在美国专利No.6,237,096的图10中描绘了这类证书，引用该篇美国专利并结合于此。这些验证证书包含：序列号、受检者(用户)和发行者(CA)的识别信息、证书的有效期(在此前后不许使用它的日期和时间)、受检者的公用密钥、以及创建和核实数字签名所需的密码算法信息。 

为了创建数字签名，把信息对象弄乱(利用单向加密函数处理的，所述加密函数只能检测对象中的一位更改)，并且然后利用个体的私人(秘密)密钥来对所述散列进行加密。通过将这一过程反向来完成数字签名核实。利用从个体的验证证书中检索出的个体公用密钥来对数字签名进行解密，并且将结果与原始信息对象的再散列相比较。当使用不同的数字签名算法时，这些过程可能会改变。数字签名仅仅同在信赖当事人和发行CA之间存在的信用一样可靠；并且通过CA所实施的物理控制、实践和程序来达到确保级别。 

PKI技术的目的是为正在通信的当事人创建并维持安全环境和信托环境。这类当事人依赖于PKI来建立用户的身份并且当用户的证书 不再可行时通知他们。当个体离开机构时、当发行替换证书时或当签字密钥丢失、被窃取或损害时，都要撤消证书。供应商利用各式各样的方法来报告证书状态。这些不同的方法使用户更加难以获得其它用户的证书状态。 

通过PKI证书和安全策略以及它们的施行来决定信托关系和互操作性的形成。证书策略确定获得发行证书的批准所需要的个人检查(例如，相片ID、信用检查这两种形式)的级别(即验证证书请求信息的适当性以及预定证书接收方的身份)。安全策略指示支持所述应用环境所需的物理控制、程序控制和过程控制。 

存在两种用于创建和编组CA的一般模型。第一种是层次CA模型，其类似于顶部为根CA的倒置树。所述根CA签署它的直接从属的CA证书。然后，这些CA签署它们的从属CA证书等诸如此类。这些关系创建了形成树分支的证书链。两个CA通过“走过”它们各自的证书链直至到达公共节点来证明信托关系存在于它们之间。可以将CA分组并与一个或多个服务递送通道、垂直行业、机构或企业相关联。 

在第二种模型中，为单个企业创建CA并向那个企业内的一个或多个实体提供CA服务。企业CA通常与其它企业的任何CA之间都不具有任何预先建立的信托关系。必须采取明确的行动来以CA交叉证明的形式实现互操作性，借此两个或多个CA同意信任另一个签署彼此的证书并且在数字签名核实期间使用这些已相互证明的证书。由一个CA发行的证书能接着通过另一个已相互证明的CA及其用户来加以验证。 

连同其他原因一起，当证书中所含的信息无效时，当用户的私人密钥受到损害时，或当必须终止用户的基于证书的应用特权时，CA撤消证书。如果证书已经处于所有者的所有权中，则CA无法简单地删除证书或从其所有者那里检索证书。作为替代，在CA的数据库中将证书标记为“撤消”并且公布证书状态。PKI的用户能接着通过从发行CA或已标识的状态知识库(目录)那里请求证书状态来获悉证书的有效性。 

早先用来报告证书状态的方法是通过公布CA的撤消证书列表(通称CRL)。由应用下载CRL并且依赖于当事方来判断特定用户的证书是否已被撤消并且由扩展来判断那个用户的数字签名是否仍然有效。CRL随时间变长，这带来了通信和数据处理开销。这种解决手段的另一个 缺点就在于：往往以很少发生时间间隔(例如，每天一次或两次)公布CRL。由于这个缘故，CRL往往在公布之后就立即过期了。在证书期满之后仅仅从CRL中删掉撤消的证书。 

PKI桥接器是一种通过协同分布CRL来在CA之间提供互操作性的方法。这类桥接器是实际上加入一组同意接收彼此的证书和安全策略的CA的中央CRL知识库。所有CA都将它们的CRL投寄到桥接器。这考虑到任何个体的证书或实体的证书的集中验证。如果证书早先尚未被撤消，那么仍旧认为它是有效的。对于PKI桥接器而言最大的缺点就在于：它们必须是可以由依赖于证书状态的桥接器的任何CA或用户获得的。带宽需求、计算需求和存储器需求可能是费用浩大的。 

用于获得证书状态的最近的方法是IETF OCSP，其进行能够提供实时证书状态的直接数据库查询。然而一些供应商已经实施了基于CRL的OCSP响应器。这类响应器所报告的证书状态仅仅是与它们所基于的CRL一样及时。尝试达到实时证书状态，继续开发诸如IETF SCVP之类的方法。在本发明的时候，状态检查方法的混合和匹配尚未在开放式PKI环境中实践。 

证书验证的任何解决手段是用于发行证书的CA的有或无决策。由成员CA中的一个来发行证书的所有用户都是有效的/使能的，除非他们的证书已被中止或撤消或者已经期满。控制参与的共同主题就是证书是否得以发行。发行是由证书和安全策略以及企业规则来管理的。 

通过对企业或共同利益集团中的全体成员进行要求，信托环境能够从其中能够支付允许进入费用的任何人都能被发行证书的充分开放的环境变化到闭合的或有限的环境。不论在哪种情况下，不管是否允许互操作性，都是CA证书和/或安全策略进行管理。 

从上述那些情况来看，申请人的发明从完全不同的角度解决了PKI和CA的互操作性问题。申请人的聚焦点在于建立适合于创建、执行、维护、转让、检索和销毁电子原始信息对象的信托环境，所述电子原始信息对象也可以是可转让的记录(所有权可以转手)。为了实现这些目的，控制电子原本或授权拷贝的系统必须使从其任何拷贝中识别正本成为可能。正如纸件正本的情况一样，只能有一个正本。可转让记录的示例是电子流通证券和有价证券。电子原始记录可以是任何源记录，不论它是否有资格作为可转让的记录。电子原始记录在系统之 间的转让必须使用确保只存在一个正本的方法进行。 

本发明通过为记录所有者的利益而发放掌握在信托独立当事方、职员或TCU手中的记录的监管来创建电子原始记录。创建信托环境是必要的，但是不足以维持电子源记录。对于本发明的目的而言，信托环境是通过形成具有紧密或有限全体成员的共同利益来创建的，并且其中通过使用管理对团体的许可准许的适当检查程序来确保未来成员、机构和它们的用户的身份。此外，个体的机构、参与、角色和属性都是在向TCU注册时定义的。对于系统而言，个体必须是被唯一标识的，并且处于它们的验证证书当中。另外，必须能做到从团体中删除个体和机构并且可以使此举动让团体的其它成员知晓。对CA互操作性的传统解决手段并没有充分地实现这些目的。 

检查在最低程度上要求通过团体的已知成员来为一个机构和/或个体出资。另外，用于机构的类似Dun和Bradstreet的估价或用于个体的类似Equ ifax的信用检查、或是等效信用和支付历史，都可以被用以估计潜在商业伙伴、客户端和顾客的可接受性。在许可TCU注册之前，检查机构和它出资的用户两者都必须被认为是可信赖的。在机构同意定义全体成员的契约条款之后，将给每一个其出资的个体指定一个唯一标识符和密码，所述唯一标识符和密码将使他们能够访问TCU。 

一旦向一个或多个TCU注册了个体，他们就能够作为交易参与方来由那个交易的所有者进行命名，并且根据他们的身份、角色和/或职责来给他们对源记录的所有子集或识别出的子集进行特定访问的权利。为了便于识别和验证并且使交易能以完全电子的形式进行，将这个识别信息的所选子集包含在参与方的验证证书中。所述验证证书将用户的身份与其用于证实数字签名的公用密钥绑定在一起，所述数字签名是利用他们的匹配签署私人密钥来生成的。 

证书或安全策略解决了在发行证书之前所需的身份证据需求(例如，两种形式的相片ID、信用检查、个人介绍)。如果需要数字签字权的话，则这种证书将被绑定于用户的TCU帐户。所述链接应该包括证书数据元素的子集，所述证书数据元素唯一地标识用户(例如，证书ID、发行CA名称、用户常用名)。一旦与用户的帐户相关联，就可以结合他或它的数字签名来使用所述证书以便提供实现预定已授权动 作集合的身份证据并且核实所提交的信息对象上的用户数字签名。这当控制一组电子记录的所有者或所有者的代理商指示TCU将电子记录的所有权(即，内部交易)和/或监管(即，外部交易)转让给另一个TCU时尤其是如此。 

正如先前描述的那样，利用验证证书和公用密钥加密来支持用户验证和数字签名核实。由发行CA来数字地签署证书，即利用它们的公用密钥来封装接收方的身份的过程。在发行证书的过程中，CA声明在证书中标识的个体是用来数字地签署信息对象或其分段的匹配私人密钥的拥有者。 

本发明不同于其它基于PKI的电子商务解决方案，因为仅仅把所述PKI看作是能够实现信用环境但不是信用环境的唯一基础。为全体成员订约的赞助和注册都是主要的因素。尽管把公用密钥加密的证书和使用看作使能技术，但是证书必须在它们能够绑定于特定用户的TCU帐户之前唯一地标识并被束缚于那个特定用户。 

当采用证书时，可以仅仅当证书与用户帐户之间的这种绑定结束时激活帐户。这种绑定可能同将证书ID和发行CA添加至用户帐户信息中一样简单，或者可以使用由诸如用户的可识别名的组件之类的证书传送的其它信息(参见ITU X.509标准)。所述绑定信息可以以注册形式加以传送，或者按照TCU系统安全策略直接地从证书中提取。每当使用证书时，可以利用相应的检查来确保证书中的用户说明匹配注册数据中的用户说明。由发行CA的证书来对用户的证书进行签署，并且利用发行CA的证书和公用密钥来证实它的完整性和可靠性。用于标识的组件的集合组必须是可证明唯一的。一旦完成这个TCU帐户和用户证书绑定，所述TCU只需要知道到哪里去检查证书状态。 

在CA中央环境中，单个PKI、交叉证书或PKI桥接器的创建(执行证书状态检查的复杂系统，其中多个供应商产品被许多CA使用)是互操作性所需要的。共同的要素就在于所有证书都具有相等的值。证书可以传送不同的信用级别，并且开放式环境中的应用必须具有不同地解释和使用这些信用级别的能力。这一原则能够特性化为“我们将建造把你带到你想要去的任何地方的途径”。当CA注册利用了各种不同的标准(例如，信用检查、支付手段、证书的成本)时，对用户进行检查。 

反之，TCU仅仅牵涉到已知的“经批准的CA”组，并且仅仅牵涉到那个组内与它的用户帐户相关联的那些证书。任何其它的证书都将被忽略。这一原则可以特征化为“将对你开放的唯一途径会是那些指导你的企业所需要的途径”。两次检查用户，一旦满足CA证书策略并且第二次证明存在他们待向TCU注册的企业。TCU所强制的商业规则能够适应在不同信用级别上发行的证书。 

发明内容

迄今为止，所有证书状态报告服务都使用了报告证书状态(CRL、OCSP、LDAP等等)的单一装置。本发明的不同之处在于为了检索和报告证书状态，它实现了与任何CA或PKI的互操作性。在很大程度上，它还通过高速缓存证书状态而减少了对系统或TCU与CA证书状态报告元素之间的实时连续连通性的依赖。 

在申请人发明的一个方面中，一种为检查由各个CA发行的验证证书的有效性而提供CSS的方法，包括以下步骤：识别从发行验证证书的发行CA中检索验证证书的状态所需的信息；根据已识别的信息来配置连接器以供与发行CA进行通信；根据所配置的连接器来与发行CA进行通信；和检索验证证书的状态。按照配置存储库中的经批准的CA的列表来指定发行CA和连接器。 

可以检查本地日期和时间以判断它们是否落入验证证书有效期中所标明的有效期内。通过根据预定企业规则来检查和批准发行CA，可以将发行CA包含在经批准的CA的列表中，并且如果所述发行CA被检查并且未被批准的话，那么可以在配置存储库中的未被批准CA的列表上指定该发行CA。检查和批准发行CA可以包括：利用CSS来登记信托验证证书的表示并且至少将该表示、状态和使用期限数据元素增加至本地超高速缓冲存储器。然后，当查询信托验证证书的状态时，对连接器进行配置以检索所添加的状态。还可以根据连接器的顺序来完成与发行CA的通信。 

所述方法可以进一步包括针对状态检查本地高速缓冲存储器，并且如果在本地高速缓冲存储器中找到状态并且本地日期和时间在有效期内，则从本地高速缓冲存储器中检索状态。如果在本地高速缓冲存储器中没有找到状态或者如果本地日期和时间不在有效期内，则CSS就与发行CA的证书状态报告组件建立通信会话，根据所配置的连接器 来构成证书状态请求，从证书状态报告组件中检索状态，关闭与证书状态报告组件之间的通信会话，并至少将验证证书的标识、状态和使用期限添加至本地高速缓冲存储器。 

可以用CRL来指示证书状态，并且根据发行CA的公布时间表，所述CSS从列在配置存储库中的证书状态报告组件中检索CRL，所述CSS清除与发行CA相关联的高速缓冲存储器，并且所述CSS根据CRL来确定验证证书的状态并且将所述状态存储在与发行CA相关联的高速缓冲存储器中。 

还可以用德耳塔(Δ)证书撤消列表(“CRL”)来指示证书状态，并且当发行CA通知一个CRL是可用的时，所述CSS从列在配置存储库中的证书状态报告组件中检索CRL；如果CRL是完整的CRL，那么CSS就清除与发行CA相关联的高速缓冲存储器，根据该CRL来确定状态，并将所述状态存储在高速缓冲存储器中；以及如果所述CRL仅仅包含在公布全部CRL之后发生的变化，那么CSS就根据CRL来确定状态，并将所述状态存储在高速缓冲存储器中。 

在申请人的发明的另一个方面中，一种响应于从TCU到CSS的查询来检索由发行CA发放的验证证书的状态以便确认验证证书的状态的方法包括以下步骤：如果状态存在并且出现在CSS的高速缓冲存储器中，则定位并报告状态；否则，执行以下步骤：从CSS配置存储库中获得状态类型和检索方法；如果状态类型是CRL并且在高速缓冲存储器中没有找到该状态，那么报告所述状态为有效的；如果状态类型不是CRL，那么就根据该状态类型来构成证书状态请求；与发行CA建立通信会话；利用所获得的检索方法来从发行CA的状态报告组件中检索状态并且结束通信会话；解释检索出的状态；将表示由用于状态类型的CSS策略指定的周期的使用期限值与已解释的检索出的状态相关联；至少将验证证书的标识、状态和使用期限值添加至高速缓冲存储器；以及响应于查询向TCU报告所述状态。 

在申请人的发明的又一个方面中，一种用于提供由发行CA发放的验证证书的准确而及时的状态指示的CSS包括：当证书的发行CA使用CRL以标明状态时，按照CRL的指示提供验证证书的状态。否则，当高速缓冲存储器包括状态数据元素和未被超出的使用期限数据元素时，提供按照高速缓冲存储器指示的状态。如果超出了使用期限数据元素， 则从高速缓冲存储器中清除所述状态，并且当该状态不在高速缓冲存储器中时使用实时证书状态报告协议来请求和检索该状态。至少将证书的标识、状态和使用期限数据元素添加至高速缓冲存储器，以及提供检索出的状态。 

可以将状态使用计数器数据元素添加至高速缓冲存储器中，并且每次检查证书的状态时就将该状态使用计数器数据元素递增或递减。如果状态使用计数器数据元素超过阈值，那么就提供所述状态并且相对于该状态清除高速缓冲存储器。还可以将状态最后访问数据元素添加至高速缓冲存储器，并且状态最后访问数据元素与状态使用计数器数据元素结合实现了证书状态的活动级的确定。 

当对CSS进行请求以检索新证书的状态并且高速缓冲存储器已经到达所分配的缓冲器大小限制时，所述CSS搜索高速缓冲存储器以查找标明最旧日期的最后访问数据元素并且清除相应的高速缓冲存储器条目；并且所述CSS继而检索所请求的状态，将它放置在高速缓冲存储器中，并且提供所请求的状态。 

在申请人的发明的又一个方面中，一种通过转让对具有可核实凭证线索(trail)的经验证的信息对象的控制从而在第一当事方和第二当事方之间执行交易的方法，包括：从信托知识库中检索经验证的信息对象，其中所述经验证的信息对象包括具有提交当事方的数字签名的第一数字签名块以及使至少身份和密钥与提交当事方相关的第一验证证书；通过将第二当事方的数字签名块包含在检索出的经验证的信息对象中从而由第二当事方执行检索出的经验证的信息对象；并且将所执行的检索出的经验证的信息对象转发到TCU。 

所述TCU通过至少从CSS中检索验证证书的状态来核实数字签名并且确认与该数字签名相关联的验证证书。如果相应的数字签名未被核实或者各个验证证书的状态期满或被撤消，则所述TCU拒绝数字签名块，并且如果信息对象中的至少一个签名块未被拒绝，那么所述TCU就将TCU的数字签名块和日期和时间指示符添加至信息对象并且以第一当事方的名义来控制所述对象。 

附图说明

通过结合附图阅读本说明书，申请人的发明的各种特征和优点将变得显而易见，其中： 

图1举例说明了采用CSS的TCU电子信息对象确认过程； 

图2举例说明了后台CSS处理，借此将各个CRL添加到证书状态存储库； 

图3举例说明了已解析的CRL、OCSP响应的独立高速缓存，以及从其它证书状态报告方法中得来的状态； 

图4举例说明了包含示例性数据元素的签名块的可扩展语法，其中将数字签名加到信息对象分段和附加数据(经验证的属性)上； 

图5举例说明TCU经由来自于会员和外来CA的因特网与CSS及证书状态的CSS检索相交互； 

图6举例说明了终止于证书状态检查步骤的TCU用户注册过程，其中数字签名确认示范了成功的注册； 

图7举例说明了终止于证书状态检查步骤的TCU用户注册过程，其中由外来CA发行用户证书，其中数字签名确认示范了成功的注册；和 

图8描绘了自动租赁示例，该示例示出了在电子商务中如何使用CSS。 

具体实施方式

证书状态检查对于任何电子信息对象提交的系统或TCU接收而言都是关键性要素。为了接受提交，必须将证书状态报告为有效的。证书状态的查询通常要求在TCU和证书状态源之间进行通信。这些通信的频率将以与TCU提交的数量成比例地增加。 

证书状态的检查可以是实时要求，并且状态查询是针对每次提交执行的。然而，同对于CRL的情况一样，可以不必实时地对状态进行更新。以规定的时间间隔公布所有CRL，通常为每天一次或两次。CRL检索和重复的解析可能对系统性能有负面的影响。本发明通过对CSS减掉大量的工作而显著降低了直接的计算需求和通信需求。在TCU与CSS之间实施单一证书状态协议。这个状态协议可以具有类似于IETFOCSP的属性，所述IETF OCSP允许为单一证书的状态而查询CA的应用，并且由此使处理开销达到最小。 

所述CSS具备并维持有关位置的充足信息、通信装置和处理对应它需要与其互操作的每个CA的证书状态的装置。因此，所述CSS可能使应用设计稳定并最优化该应用设计。所述CSS有利地解析并高速缓 存证书状态以便最小化对TCU状态查询的状态响应时间。因此，所述CSS消除了对任何传统形式的PKI互操作性的需要。由于能够容易地撤消TCU用户帐户或通过从经批准的CA的CSS列表中删除CA来删去一组用户，因而大大地增强了潜在妥协恢复。 

验证证书的使用： 

在登录到TCU中之后，可以要求参与者进一步验证他们自己，但是要使用公钥密码和他们的验证证书。这类验证可以与安全会话建立、TCU服务或数字签名的请求和电子信息对象的提交相关联。 

在任何人能够与TCU相交互之前，必须满足四个条件：1)他们首先必须注册为系统用户，2)如果不只准许他们进行只读访问的话，则他们必须已经发行并且拥有公用密钥对和他们的匹配验证证书，3)证书必须由经批准的CA来发放，并且4)用户的证书必须尚未期满或者必须尚未报告为无效的或已撤消的。这最后一个条件通常要求TCU将查询指向发行CA以检索证书状态。因为存在用于报告证书状态的多种标准和CA实施方案，所以这不是容易或简单的任务。 

正如背景部分中叙述的那样，当涉及多个CA或PKI时，通常需要某种形式的PKI互操作性。本发明通过创建证书状态服务来消除这种需要。由于CSS所需要的唯一知识就是经批准的发行CA的列表、他们的IP地址等等和他们的报告证书状态的方式，因而CA交叉证明或桥接是不必要的。 

为了检索证书状态，为每个证书状态方法定义连接器或程序模块。每一个验证证书都包含受检者(用户)字段和发行者(CA)字段。使用发行者字段来将TCU查询指向CSS，然后该CSS检查其高速缓存以查找证书状态的存在。如果状态存在于CSS高速缓存之中，则将它返回到TCU。如果状态不存在的话，则所述CSS将调用适当的连接器以检索证书的状态。将要利用许多方法来报告和检索证书状态：LDAP、OCSP、CRL等等。 

为了执行任何TCU动作，用户都必须首先登录到TCU中。一旦成功，若用户得到这类管理机构的准许，那么他们就能创建或选择交易。如果他们具有提交电子信息对象的许可，那么他们现在就可以这样做。当接收到电子信息对象时，所述TCU执行必要的数字签名确认步骤。证书状态查询将被构成并发送给CSS。如果返回有效状态，则所述TCU 将接受并存储所述提交以作为授权拷贝，否则它将遭到拒绝。 

数字签名处理和证书状态检查： 

可以将数字签名应用到信息对象的一个或多个分段上或应用到信息对象的全部内容上。数字签名可以属于交易的当事人或者属于使交易能达到商业过程范围内的状况或状态的代理商。实际上，可以将数字签名应用到与正在执行的任务有关的附加信息上。一个这样的示例可能是所有权契据上的县记录员的注释。另一个示例可能是证实正被提交给TCU的信息对象的可靠性的当事人的签名的应用。在这后一种场合中，把提交称为包封(wrap)或封装信息对象，因为他们的数字签名被应用到全部内容上，这免除了任何随后的修改。 

每当应用数字签名时，都将要求签字人确认他们将要用其数字签名绑定的意图。新近法规所需要的这种提交动作可以采取显示窗口或闪光屏幕中的可读文本的形式，并且可能需要调用图形按钮和/或登录到加密令牌，所述加密令牌同样也是密钥和证书存储库。所述自愿提交的实际范例就是：通过利用使用所选内容来计算用户的数字签名的信托应用并将它与它们的验证证书组合在一起以形成签名块。所述签名块还可以包含经验证的和未经验证的数据元素。将任何的包含在数字签名计算中经验证的数据元素如用于签名的基础或本地日期-时间受到数字签名保护。在签名计算之后添加未经验证的数据元素，并且没有受保护。图4示出了包含数据元素的样本语法和签名块的布局。不应照字面上解释它，其实它仅仅意指说明性的示例。 

可以有利地将信息对象和任何签名块置于包封(S/MIME)中或处于可扩展信息语法(XML、HTML、XHTML)中的标记上以供处理便利性并且简化信息处理。继而，把这种数据结构发送给TCU以供确认。作为选择，可以把签名块独立地发送到待附加到实际源记录上的TCU，所述实际源记录永不离开该TCU。在后一种情况下，独立地确认每个签名块。 

在提交的时候，数字签名确认的过程不同于此后执行的过程。TCU第一次见到数字签名时执行四步确认：1)核实数字签名，证明在传输期间尚未改变受数字签名保护的内容的过程；2)检查当前TCU时间是否落入个体的验证证书的许可的有效期内(“不在有效期之前”、“不在有效期之后”)；3)利用本地指定的CSS来请求并从发行CA、CRL 分布点或证书状态的另一个经批准的源中检索证书状态；4)确认TCU用户帐户信息与证书中传送的信息相符，并且在TCU规则数据库中批准所请求的动作。对于信息对象的提交而言，所述过程增加一个附加步骤。这个第五步检查提交者的身份与同TCU建立当前会话的当事方的身份相匹配。如果所有测试都成功，则允许所述动作和/或接受所述信息对象并且TCU以其所有者的名义来保存它。如果任何一个步骤失败的话，则启动补救程序。 

在这个初始证书状态检查之后，TCU的信托环境维护所有保存信息对象的可靠性和完整性。没有预先考虑到将需要任何附加的证书状态检查除非提交文档的新版本。 

本发明的两个方面不同于PKI实施方案的正常过程。第一就是：本发明是以应用的存在为基础的，也就是说TCU(或需要证书状态确认的任何应用/系统)及其创建并维护电子原始源记录的能力。第二就是只需将“发行CA”识别为遵循管理信托环境的策略并且既不需要CA交叉证明也不需要PKI桥接。“发行CA”包含物的必要证明是文档化的商业关系。在TCU注册过程期间，创建引用用户指定的证书信息的用户帐户，所述证书信息实际上将该用户帐户与用户的验证证书绑定在一起。 

TCU使用： 

典型地，一旦机构同意使用TCU的服务，授予那个机构的代理商对机构交易的访问的控制。机构的代理商继而识别他们将授权执行关于机构交易的所选动作的一组个体。所有动作都要求用户具有带TCU的帐户，要求所述帐户是激活的，并且要求该用户具有注册身份并能提供适当的密码或对询问短语作出响应。另外，由一组版本化的电子原始源记录组成的每个交易都具有以商业过程中的不同步骤来管理用户访问的一组许可。当交易通过正常的商业过程，即经永久保持或破坏而开始的商业过程进行，这是通过准许和消除交易记录的权力来示例的。如果得到许可，则登录到TCU仅需要查看电子源记录。然而，任何系统级动作或者电子源记录的引入或改变都需要个体进一步通过利用公用密钥加密或通过应用它们的数字签名和验证证书来验证他们自己。在所有的情况下，必须验证个体的身份。在采用数字签名的情况下，这要求：1)用户具有适当的访问许可，2)对数字签名进行解密 并且在已经施加的下层散列或消息摘要尚未改变的情况下核实内容，3)检查提交的时间是否落入证书有效期内，以及4)检查用户证书是否仍然有效。 

证书状态检查要求查询发行CA或证书状态响应器。由于这个步骤必须与每个经验证的行动或电子源记录提交一起进行，因而通信带宽可能会变得过量并且可能因未答复的或慢的状态响应而存在时延、积压和拒绝。本发明解决操作TCU和确保所有与TCU相交互的当事方的有效性的这些方面及其它有高度保证的方面。 

在操作TCU的高度确保的环境中，当具有资格的用户请求服务时仅仅需要证书状态检查。对于信息对象而言，仅仅需要在提交的时候检查证书状态。如果确定所有数字签名均有效，则此后认为所述信息对象是可靠的。安全及程序上的实践和方法是在TCU处的适当位置处以阻止导致未经授权的文档更改或损失的恶意行为和硬件故障。每一个提交都会导致电子源记录的新版本的创建。TCU负责维持知识就好像所述知识是源记录的最新版本一样。可以将这个版本确定为电子原本并且作为可转让的记录。所述TCU通过将可靠的日期-时间戳添加到源记录上然后通过将它施加到其数字签名并且增补它的证书，来论证其原始源记录的控制的假设。为了安全和处理便利，可以把包封应用到源记录上。尽管这个版本控制过程创建了独立的经验证的凭证线索(trail-of-evidence)和监管，仍然维护单独的冗余审查记录以供确证(corroboration)。 

申请人的CSS克服了随PKI和电子商务一并存留至今的上述局限。当创建证书状态时，向CSS登记从成员CA那里获得所述证书状态所需要的源信息。可以在用户注册过程期间输入外国批准的CA的源信息。CSS检索信息是每个证书状态源所需要的。存在几种类型的证书状态源，并且要求所述CSS具有用于所登记的每种类型的连接器或方法。 

一些CA用以传送证书状态的一种方法就是CRL，所述CRL包括所撤消的证书的列表以及它们被撤消的原因，当所述CRL被发行时和当将要公布下一个CRL版本时还包括CRL的发行者。由发行CA或指定的签字人来签署每个CRL以确保它的完整性和可靠性。一旦超出证书的有效期，就从CRL中删除这些证书。 

在使用CRL的情况下，所述CSS从例如像X.509 v2 CRL简档(IETF RFC2459，1999年1月)这类CA分布点中检索CRL的最近解释，确认它的签名，对它进行解析，并创建高速缓冲存储器以存储结果。当所述CSS执行下一个CRL下载时，该CSS使用CA的CRL公布时间间隔来进行管理。每个CRL都包含有效性字段，通常将该字段设置为允许执行下载过程中的一些容许偏差。这考虑到通信阻塞和CA故障时间，并且如果超出这一时间间隔的话，则将强制CSS要求补救措施。这类补救可以包括使与新添加的撤消的证书相关联的任何提交重新生效。每个新的CRL取代先前加载的CRL。对这个规则的例外情况就是德耳塔CRL行列(procession)。将德耳塔CRL的内容添加到当前的高速缓存内容上。德耳塔CRL BaseCRLNumber指的是最近发行的完全CRL。自最后的完全CRL以后，以更短的时间间隔(分钟、小时)且只有当已经发生证书撤消时才公布德耳塔CRL。所述CSS负责根据公布时间间隔或通知来检索CRL和德耳塔CRL并且不超出TCU安全策略中建立的时间间隔。 

CA分布证书状态所使用的第二种方法就是OCSP。在使用OCSP的情况下，所述CSS当请求证书状态时查询OCSP响应器。对OCSP响应进行签署以确保它们的完整性和可靠性。所述CSS解析OCSP响应并将证书细节和状态添加至另一个高速缓存中。由本地TCU安全策略确定的使用期限标志被包含在其中并且确定何时将从所述高速缓存中删除条目。这个特征的目的在于：当由同一个当事方/实体在很短的时间间隔内将几个信息对象上载到TCU时最小化通信开销。所述使用期限标志将通常明显比正常的CRL公布时间间隔(每天两次、每天)更短(例如，5分钟)。如果处理一个以上的信息对象，则所述CSS可以在从高速缓存中清除证书状态之前再次检查证书状态，以确保没有发生证书撤消。如果在使用期限时间间隔期间已经发生证书撤消，那么必须通知所有者机构联系点。存在几种其它的查询方法，不过为了简便起见不会对其进行描述。要理解的是，当采用这几种方法时，它们每一种都将需要连接器和潜在独立的高速缓存。 

图1示出了用于创建电子原本的处理流程。为了说明起见，将信息对象假定为销售合同。从TCU中或从文档准备系统中检索电子信息对象的拷贝(未执行的)并且由适当的当事方对其进行数字地或全息地(手写)签署。如果已经监督执行过程，则所有者的代理商利用信 托应用来对信息对象进行数字签署和包封并将它发送给TCU。 

先前已经创建、执行或检索电子文档的情况下，正如在步骤101中那样，提交者对其进行数字签署并将它提交给TCU。在这个电子封装过程中，形成包含签署的内容和数字签名块的包封，所述数字签名块还包含提交者和任何其它签名人的数字签名和证书。在图1中描绘了五个过程：(1)当发现无效的数字签名和/或撤消的证书时进行动作，(2)在本地高速缓存状态的地方进行证书状态检查，(3)在必须检索证书状态的地方进行证书状态检查，(4)CRL检索和处理，以及(5)当确定电子封装文档可靠时创建电子原本。在步骤103中，所述TCU接收电子封装后的电子文档。在步骤105中，所述TCU确认提交者具备将电子文档添加到所选的帐户和/或交易的权限。在步骤107中，所述TCU以密码方式核实已电子包封的数字电子文档中所包含的任何数字签名。在核实过程期间使用在签字人的X.509验证证书中发现的公用密钥。在步骤109中，从签字人的验证证书中提取证书有效期，并且在步骤111中，对照当前日期和时间来检查所述有效期。如果任何上述测试失败的话，则在步骤113中拒绝所述提交并且在步骤115中可以发送否定确认。在步骤117中记录所述动作。 

如果所有测试都成功的话，那么在步骤119中从CSS那里请求包含在包封内的每个证书的证明状态。在步骤121和123中，检查证书状态以查看它是否存在于证书状态存储库中。在步骤125中，检索证书状态，并且在步骤127中检查证书的有效性。如果由于任何原因发现任何证书无效，则在步骤113中拒绝所述提交，在步骤115中可以发送否定确认，并且在步骤117中记录所述动作。期待提交者寻求补救。 

如果在步骤127中确定所有数字签名和证书对所述提交是有效的，那么在步骤129中所述TCU应用另一个包含日期-时间戳和TCU数字签名块的包封。所述TCU继而以记录所有者的名义承担作为电子原始记录的提交的控制。在步骤131中，所述TCU在受保护的持久性存储器中放入电子原本，在步骤133中，所述TCU发送肯定确认，并且在步骤117中，刚一完成，所述TCU就记录所述动作。 

如果在步骤123中确定证书状态不存在于证书状态存储库中，那么在步骤135中所述CSS从处于测试阶段的证书中检索发行CA字段。在步骤137中，所述CSS察看发行CA位于经批准的CA列表上，在步骤139中可以由CA连接器存储库来维护和访问所述经批准的CA列表。如果所述CA不在列表中，那么返回无效状态并且所述过程在步骤125重新开始并经步骤127、113、115和117继续进行，这导致拒绝提交并传输否定确认和记录条目。如果在步骤137中在经批准的CA列表上发现所述发行CA并且在步骤141中确定证书状态报告机制是CRL，那么将有效状态指示返回到步骤125。如果所述CA是已知的并且受检者证书的状态不存在但状态机制是CRL，那么可以假设所述证书状态是有效的，提供存在的并且对于所述CA而言是当前的CRL。所述过程继而经步骤127、129、131、133和117继续进行，这导致创建电子原本、传输肯定确认和刚刚完成的所述动作记录条目。 

如果在步骤141中确定所述证书状态报告机制不是CRL，那么就利用在步骤137中获得的连接器信息来查询证书状态报告机制。连接器说明书中所含的是需要查询适当证书状态知识库的所有配置信息，所述适当证书状态知识库可以是CA、目录或任何其它类型的证书状态知识库。与步骤145、147、149和151相关联的状态存储库(即分别是LDAP目录、OCSP响应器、数据库和服务器)都是这类知识库的示例。响应于步骤143中的查询，这些中的其中一个响应于证书状态信息，并且在步骤153中将状态添加至证书状态存储库中。 

当在步骤153中进行添加时，证书状态存入的过程在步骤121重新开始并且经步骤123、125和127继续进行直至结束，结束时要么接受所述提交(步骤129、131、133、117)，要么拒绝所述提交(步骤113、115、117)。 

在步骤155和步骤159中以预定的时间间隔公布CRL，而在步骤157中根据需要，当报告可疑损害并且策略需要即时响应时公布CRL。这个过程在图2中作了进一步描述。如果所述CA是已知且状态不存在并且状态机制不同于CRL，则所述证书状态服务就选择连接器并查询证书状态机制(步骤143)。所述连接器包含使得状态检索和解释成为可能的必要信息。在步骤145-151中描绘的实时证书状态的任何源将对就当前状态进行的证书状态查询作出响应，但是这个过程不仅仅限于那些源。在步骤153中接收状态并将其添加至证书状态存储库。当添加状态时，产生响应和动作返回到步骤123，同时状态的处理重新开始于步骤125并且如先前描述的那样结束。 

现在参照图2，所述CSS作为后台进程来执行CRL检索。CRL包含所有撤消的或中止的证书的列表直到当前日期和时间超过证书中所含的有效期。将中止的证书认为是它们已经被撤消，但是可以恢复它们，这会导致从CRL中删除它们。无法恢复撤消的证书。 

在步骤155中，CA管理员配置CA以便以预定时间间隔公布CRL。在步骤157中，所述CA管理员还可以按照本地证书或安全策略指示的那样公布德耳塔CRL。所述CA管理员或CA将推行关于德耳塔CRL的公布的通知。每当在全部CRL的公布之间的时间间隔期间证书被撤消或中止时，可以产生德耳塔CRL。德耳塔CRL可以包含被撤消的CRL的完整列表。在步骤201中，将CRL和德耳塔CRL公布到CRL知识库或目录中。 

在步骤203中，所述CSS检索CRL公布时间表或德耳塔CRL通知，并且步骤205描绘了用于预定时间检索的定时器。所述定时器还允许根据所有CRL中所含的“下一次更新”字段来进行检索。在步骤207中，从CRL知识库中检索CRL或德耳塔CRL。在步骤209中，在于步骤153中被添加至适当的高速缓存中、或基于已建立的时间表于步骤121中被添加至证书状态存储库中的列表中之前，对CRL或德耳塔CRL进行解析，或者当通知时进行解析。对CRL进行解析考虑到更容易管理以及在CRL条目查找过程中降低开销。为完整起见，在图2中举例说明所述CSS的步骤119、123、125、135、137和141，并且如结合图1所述的那样加以实施。 

现在参照图3，证书状态存储库包含许多高速缓存，所述高速缓存保留来自不同报告机制的证书状态。所述高速缓存(在图3中描绘了其中的五个)可以映射到单个的CA(高速缓存301、303)或CA的集合(高速缓存307、309)。对于实时报告的状态而言，所述状态保持在高速缓存中直到需要(例如，最不常用的)空间为止或根据策略需求而保持在高速缓存中(例如，只保存规定的时间间隔)。一旦超出标准，则通常要清除状态。 

高速缓存的目的就是为了在策略规定的周期内保存证书状态，由此减少在证书状态和CRL检索期间需要的通信开销。因此，所述CSS能够跨过通信中断。 

可以对CRL进行解析并且可以将个别已撤消的证书状态置于高速 缓存中以便减少当必须重复地检查CRL时带来的计算开销。这是利用高速缓存305、307来描绘的。每当检索新的全部CRL时，替换高速缓存的内容。 

现在参照图4，示出了表示一些更重要的数据元素的示例性语法，所述更重要的数据元素需要被包含在数字签名块中。图4是构成数字签名的数据元素的自由形式示例，其中所述签名被应用到多个消息分段和日期/时间戳上。这个示例意在说明可以用于数字签名块的语法。人们注意到，<CumulativeHashValue>数据元素被应用到一个或多个分段或全部内容以及任何经验证的数据的HashValues上。 

图5描绘了示出支持证书状态服务的构造块(building blocks)的安全通信体系结构。该图示出了在CA、CSS和TCU这三者之间的交互。优选地，将所述CSS本地置于TCU上以确保高效率。其主要目的是为了提供带有公用接口的TCU并且确保证书状态信息的安全和及时供应。其次要目的是通过管理在维护证书状态信息过程中所需要的通信和计算开销来确保有保证的级别或服务质量。 

如图5所示，有利地将带有适当通信路由器和集线器的CSS服务器和TCU布置在通信防火墙的后面。如适当，所述路由器和集线器将信息递交给CSS和TCU。这种信息中的一些包括如上所述经诸如因特网之类的网络而从用户客户端应用那里递交给TCU的电子封装提交。还描绘了经由OCSP的CSS和TCU通信。 

图5还描绘了在各个通信防火墙后面的不同示例性环境中的三个CA。企业CA可以包括与用虚线封闭的租赁行业CA进行接口连接的服务器。外来PKI或响应器可以包括与诸如PKI、CA和证书状态响应器之类的实体进行接口连接的服务器。层次的成员PKI可以包含与诸如用于CRL和证书状态的V3 LDAP、根CA和用于抵押及租赁行业、结算代理商和产权保险公司的CA之类的实体进行接口连接的服务器。 

图6和7描绘了分别对于成员CA和外来CA而言、在用户(订户和实体)注册过程期间证书状态服务的使用。成员CA是被信托以发行用户证书的一个CA。外来CA是外界实体操作且需要在与TCU活动结合使用它们的证书之前被批准的那些CA。用户身份授权需要由所有CA来严格地实施或者委托给机构代理商。附加要求就是：需要直接关联或授权用户的证书以供一个或多个预订机构的帐户在TCU能够准许对那 个用户访问之前使用。一旦实现这一操作，所述TCU就将接受用户的数字签名并且信赖CSS以便证书状态确认。 

在图6中，所述TCU注册过程起始于步骤601，具有来自出资人的用户注册信息的机构管理者/代理商的接收。在步骤603中，这个管理者/代理商负责确认出资人发出请求的权限。出资人通常仅仅对他们的帐户给予控制。在步骤605中，所述管理者/代理商向TCU注册用户，建立用户帐户。在步骤607中，所述管理者/代理商继而可以把交易特权分配给所述用户。交易特权可以包括对电子原本及其它源记录进行提交、解释、转让等能力。 

在步骤609中，对加密令牌(数字签名机制)进行初始化，并且在步骤611中，在令牌上生成公用密钥对。在步骤613中，创建证书请求，并且在步骤615中，向机构的CA发送所述请求。在步骤617中，检索所述证书并且将其置于令牌上。在步骤619中，将所述证书绑定于用户的TCU帐户或者与用户的TCU帐户相关联。 

在步骤621中，确认用户的身份，例如通过向能够亲自确认用户身份的机构管理者/代理商显示自身身份。通常，可能将需要至少两种形式的标识。由于发起用户参与，因而除高值交易外这应该是足够的，在所述高值交易的情况下可以要求为管理者/代理商所知的某个人担保用户的身份。在步骤623中，要求所述用户签订合同契约，借此绑定同意使用该用户的数字签名的用户。在步骤625中，给用户指定应用程序用户手册，并且无论什么指令都被认为是必要的。在步骤627和629中，所述用户配备注册ID、临时密码和加密令牌。 

在步骤631中，所述用户登录到系统上，并且在步骤633中，向TCU提交测试文档。在步骤635中，所述TCU确认用户的数字签名和证书。在步骤637中，所述TCU针对证书状态信息而查询CSS。在步骤639中，所述TCU接收状态并且相应地继续进行。如果接收到的证书状态是有效的，那么在步骤641注册完成，并且所述用户能够访问并使用TCU。如果所述证书状态是无效的，则注册结束于步骤643，并且管理者/代理商确定错误的原因并且开始补救，这可能涉及重复概述的注册过程步骤中的一些步骤或所有步骤。在图6中概述的可靠过程确保在结束时注册者被充分使能。 

在图7中，如果满足规定策略的条件，则允许用户使用先前由外 来CA发放的加密令牌。如上所述，随后执行注册步骤601至607。如上所述，随后还执行用户身份核实和订合同步骤621至627。 

由于所述用户已经具有一个令牌，因而所述过程与图6中描述的过程有区别。在步骤701中，所述用户将令牌置于可兼容读取器中并且登陆。在步骤703中，管理者应用程序从令牌中检索用户的证书。在步骤705中，显示证书信息并且获取发行CA标识信息。在步骤707中利用CA信息来核实CA位于经批准的列表中。如果所述CA不在经批准的列表上，那么在步骤709中向TCU管理者提供所述CA信息，并且在步骤711中管理者对应用策略管理机构进行检查以供许可继续注册。只有应用策略管理机构能够授权将外来CA添加到经批准的列表中。 

如果在步骤713中拒绝许可，注册终止于步骤649，这给予用户三种选择。一个是请求并使用由成员CA发放的令牌。另一个选择是请求对CA拒绝决定的评估。第三个选择是请求先前经批准的外来CA的名称。 

如果在步骤713中所述发行CA得到批准但不在列表上，那么在步骤715中所述管理者就将该CA和连接器信息添加至经批准的列表中，配置CSS以便从所述CA中检索证书状态。 

在步骤619中，将用户的证书绑定于新创建的用户帐户或与新创建的用户帐户相关联。如图6和步骤631至639所示，要求用户向TCU进行尝试性的提交以便确认所述帐户已经被正确地设置并且该用户能够访问所述TCU。如果所述CSS返回有效状态信息，那么在步骤641注册完成。如果所述CSS返回无效状态，那么所述管理者就确定错误的原因并且开始补救，如上所述，这可能会涉及重复注册过程步骤中的一些步骤或所有步骤。最有可能的失败原因可能与能够到达外来CA并从外来CA中正确检索证书状态的CSS有关。 

所述CSS在访问TCU或其它系统时确认用户证书和发行CA两者都得到授权的过程中扮演着重要的角色。如果从经批准的列表中删除发行CA并且删除掉它的连接器配置数据，那么所有相关联的用户都将被拒绝进一步访问TCU。应当理解的是，所述CSS能够与需要证书状态的其它应用和系统一起工作，所述应用和系统包括需要与多个PKI和CA一起互相工作的应用和系统。 

例如，CSS的其它用途就是提供包含自签署证书在内的信托验证证 书的状态，其中在客户端寻求服务和应用操作者之间存在协定。由CSS来对信托证书的表示(例如，PEM、证书ID、所施加的数字签名)进行高速缓存，并且利用信托证书连接器来查询状态。这允许应用具有单一证书状态含义，而不考虑所述证书是被自签署还是由CA发放的。可以使用这种信托证书方法，其中由团体来使用少量的受控制证书，而不是查询该团体的一个或多个CA。因此，将会认识到的是，在本申请中使用的术语“CA”和“发行CA”涵盖这类自签署证书的所接受的发行者以及常规的CA。 

此外，所述CSS可以使用连接器的组合来检索证书状态。至少一个连接器可以是“虚拟的”，比如仅仅为供信托证书使用而描述的连接器。所述CSS以预定顺序(例如，排序的顺序)来调用连接器直到获得证书状态为止。这种方法实现了状态源(例如，最信任到最不信任)的层次结构的创建。 

图8描绘了汽车租赁示例，该示例示出了在电子商务中如何使用CSS。汽车经销商或经销商的代表(在下文中为简明起见称为经销商)，由汽车CA来给其发行相应的验证证书，所述汽车CA可以描绘成计算机。由银行CA来给汽车经销特权中存在的汽车租户发行相应的验证证书。由金融CA来给远程出租人发行相应的验证证书。作为选择，租户或出租人任意一方都已经创建了自签署的证书，所述自签署的证书是经销商向租赁应用和CSS登记过的，例如因为所述租户是经销商的老主雇。 

如本申请中所述，所述CSS利用任何使用经批准的状态报告协议的证书状态报告手段来检索并报告这些及其它证书的状态。在图8中，假设汽车CA和金融CA都使用OCSP，而假设银行CA使用CRL，并且经销商和租户都具备某种形式的令牌(例如，PKCS#11、PKCS#12、浏览器密钥存储库等等)，所述这些令牌包含了他们的证书和加密签署方法。将会认识到的是，图8仅仅是执行交易的一个范例；作为特定交易的必要条件，可以根据需要将更多或更少的CA与通信相连。 

在步骤801中，经销商创建租赁合同或从租赁应用中检索它，比如在代理商处本地运行的计算机程序或在远程站点上(例如，在应用服务器上)远程运行计算机程序。在步骤803中，经销商安排由租户和出租人执行租赁。在此时可以向本地租户和远程出租人显示租约， 并且可以要求经销商回答任何疑问，如果需要的话则可以进行更正。经销商可以通过向出租人提供URL(统一资源定位符)来安排向出租人显示租约，所述URL使所述出租人能审查和执行租约，随带将执行后的版本返回给经销商。在由租户和经销商本地签署之后，例如利用捕获关于所述租约的租户数字签名的平板PC来进行签署，并且由出租人远程签署，将所述租约传输到电子保险柜(步骤805)，所述电子保险柜被示出与应用服务器相通信。有利地，由租户和经销商进行数字签署是动态的，同时应用服务器通过将“由...数字签署”指示符应用到所显示的图像上来更新显示。优选地，不显示实际的数字签名。 

将要认识到的是，可以由经销商来使用应用服务器及相关联的电子保险柜，以便实施为由出租人远程签署的订合同。在步骤807、809和811中，出租人从保险柜中检索租约，通过数字签名来同意租约条款，并且将其数字签署的版本返回到保险柜。步骤807、809和811举例说明了多地点协作和异步交易处理。 

在步骤813、815和817中，为数字签名而检查接收到的电子文档(所述租约)，并且如果发现的话，就核实所述数字签名并且确认相应的验证证书。在步骤817中，检查本地时间以确保它落入证书的有效期内，并且在步骤819中，针对证书的状态而查询CSS。作为在步骤821中的响应，所述CSS首先针对证书状态而检查它的本地高速缓冲存储器或数据存储库，并且如果证书的状态存在并且是当前的，则在步骤827中所述CSS就按“有效”来返回证书的状态。在步骤823中，如果证书状态不存在或不是当前的，那么所述CSS就利用为此目的所创建的连接器类型来查询发行CA。在步骤825中，发行CA(例如，银行CA)或它的状态报告方法(例如，目录)优选地利用相同的连接器来向CSS返回状态，并且在步骤827中，所述CSS向应用服务器报告所查询到的证书的状态。 

在步骤829中，假定所有数字签名和证书都被核实和确认，证明电子文档可靠，应用服务器承担对电子文档的控制并且将其作为新的版本保存在电子保险柜中。因此，将要清楚的是，对于适当的特性而言，应用服务器和电子保险柜像TCU那样协作。在步骤831中，通过将日期-时间戳添加到文档并将TCU的数字签名应用到文档上，将新的版本指定为同样可以是可转让记录的授权拷贝、电子原本记录。只要 文档上的至少一个数字签名是有效的，就会发生这一步骤。 

在步骤833中，如果数字签名或证书有任何一个没能通过所有测试的话，那么就警告经销商寻求补救，这典型地涉及重复步骤801至829直到应用有效的替代数字签名。如果签字人的证书的状态被撤消或期满，就无法完成补救过程，直到发行新的证书和加密材料为止。 

将要理解的是，诸如汽车租约之类的信息对象可以以例如XML、PDF、PKCS#7、S/MIME等等电子形式存在，这实现了数字签名的放置和检测并且阻止未授权的修改。因此可以把这些形式中的许多形式视作是为所包含的信息提供了安全包封或封套。 

还要理解的是，所述CSS能用来检查证书的状态而与密钥使用无关。这类证书包括但不限于：初级使用不是身份和验证的证书，例如，密钥协定/兑换、证书签署、CRL签署、密钥加密、数据加密、仅仅加密、仅仅解密和安全套接层(SSL)。因此，将要理解的是，正如在本申请中使用的那样，术语“验证证书”通常涵盖这类不是用于标识的证书。 

另外，CSS连接器能够有利地在单次通信中嵌入一次以上的证书状态检查。其中，这种能力可以用在确认一连串用户/实体证书和CA证书的一些或全部的过程中，例如从根CA下至发行CA的CA层次结构。这提供了额外的保证，即：证书路径中的所有CA都仍旧是有效的。 

本申请已经描述了一种用于配置证书状态服务(CSS)的方法，该方法包括以下步骤：为必要的发行CA确定检索证书状态所需要的设置信息，识别与用来从发行CA中检索证书状态的证书状态查找技术相兼容的连接器，利用所选连接器和发行CA特定的设置和通信参数来配置连接器，以及在发行CA与连接器之间建立CSS映射。将所述CA指定和连接器添加至配置存储库中的经批准的CA的列表当中。 

一种用于通过转让具有相应的可核实凭证线索的经验证的信息对象来执行交易的方法，包括以下步骤：由第一当事方从信托知识库中检索经验证的信息对象。所述经验证的信息对象包括：提交当事方的第一数字签名、使至少身份和加密密钥与提交当事方相关的第一证书、可靠的日期和时间、信托知识库的数字签名、使至少身份和加密密钥与信托知识库相关的证书；提交当事方的数字签名和证书已经由信托知识库在提交证实信息对象的可靠性时被确认；并且所述验证信息对 象已经作为在信托知识库的控制下设置的电子原始信息对象而被置于存储器中。 

所述交易执行方法还包括以下步骤：在签署动作之前，需要任何签署实体来提交以使用他们的数字签名和将被他们的数字签名绑定，由任何当事方，由应用签署当事方的至少数字签名和验证证书执行所述信息对象，创建包含签署当事方的至少数字签名和验证证书的签名块，将签名块与信息对象相关联，重复前述的执行步骤，其中多个实体对所述信息对象和/或包封进行数字签署，以及将数字签署的和/或包封的信息对象转发到TCU。所述TCU核实每个数字签名并确认每个相关的验证证书，并且从CSS中检索状态。如果签字人的数字签名未被核实或签字人的验证证书已经期满，则拒绝所述签名块，或者报告被撤消。任何签名块的拒绝导致请求替换签名块或启动补救。如果确定至少一个签名块是有效的，那么所述TCU就将它自己的签名块(也包含可靠的日期和时间)添加到受检者信息对象中，创建它以所有者的名义保存并控制的电子原本。 

创建数字签名块可以包括以下步骤：为一个或多个信息对象分段或为整个信息对象计算一个或多个内容散列，遍及一个或多个内容散列和任何添加的数据来计算散列，所述任何添加的数据比如是本地日期和时间、签署原理或指令，利用签署当事方的私人密钥来对计算出的散列进行加密，借此形成签字人的数字签名，并且将签字人的数字签名随同签字人的验证证书一起放置在签名块中。如果添加的数据包括本地日期和时间，那么创建数字签名块还可以进一步包括以下步骤：要么显示本地日期和时间、要求签字人确认日期和时间是正确的、并且如果任一项不正确的话就校正所述本地日期和时间，要么如果这些都是由信托时间服务来设定的并且保护本地日期和时间不受篡改，就信赖所述系统日期和时间。可以检查本地日期和时间以确保它们是准确的而且是落入用户的验证证书有效期内的，并且确保本地数据与时间既不在由有效期指定的日期和时间之前也不在此之后。 

对于核实失败的数字签名的补救需要重新计算数字签名并且重新传输签名块。补救验证证书有效期的违规包括：通知用户该用户的证书已经期满并且必须被更新，并且通知交易所有者交易未完成。 

一个或多个签名块及其中所含信息的布局是由至少一个签名标记 来指定的。将一个或多个手写签名和日期数字化并用于信息对象执行，并且签名和日期的布局是由至少一个签名标记来指定的。可以独立地将一个或多个签名块随同相应的签名标记的指示一起发送给TCU，并且所述TCU能够确认独立地或作为整体发送的每一个签名块。如果数字签名核实或验证证书确认步骤失败的话，那么所述TCU就拒绝签名块并且可以请求补救，而如果签名块确认步骤成功的话，那么所述TCU就将所述签名块放置在所指明的标记处。为了独立地发送签名块，所述TCU可以将可靠的日期和时间添加到每个签名块上。根据企业规则，所述TCU在包含受检者信息对象和已插入的签名块字段的包封中添加它自己的包含可靠日期和时间的签名块，借此来创建电子原始信息对象。可以在包封内添加多个用户签名块，并且递归地应用包封以实施其它商业和安全处理。 

所述TCU可以通过执行以下操作来确认存在于签名块之中的数字签名和验证证书，其中所述签名块将被包含在或被添加到电子原始信息对象的内容中：在商业规则数据库中检查由验证证书标识的签署实体具有执行所请求的动作的权限，核实签署实体的数字签名，检查证书有效期与当前的可靠日期和时间重叠，检查传送的本地日期和时间落入TCU日期和时间的可容许偏差内，并且利用CSS来检查证书状态。如果这些步骤中的任何一个导致无效输出或假输出的话，那么所述数字签名就被认为是无效的，禁止所请求的动作并且寻求补救；否则，所述数字签名就被认为是有效的并且允许所请求的动作。 

发行CA向CSS的登记可以包括以下步骤：根据行业或机构商业规则和系统策略将包含在CSS知识库中的发行CA检查并批准为“经授权的”。如果检查步骤失败，则就把所述发行CA作为“未经授权的”添加到CSS配置存储库中和/或CA登记终止；否则，就把所述发行CA作为“经授权的”添加，并把通信参数(IP地址、SSL密钥和证书)以及用来报告证书状态的方法(OCSP、CRL、LDAP)添加到CSS配置存储库中，并且如果尚未实施的话，则添加连接器以解释证书状态。照此，所述CSS实现了系统或TCU与不同证书状态响应器组之间的互操作性。 

证书状态检查有利地使用CSS以用于建立通信、从经批准的证书发行CA中检索并高速缓存证书状态。当CSS从系统或TCU那里接收证书状态查询时，所述CSS首先检查它的本地高速缓存以查看证书状态 是否存在，并且如果找到且在使用期限时间间隔内，则返回状态。如果证书状态不存在或超过使用期限时间间隔的范围，那么所述CSS就通过首先从它的配置存储库中请求连接信息来检索状态。所述CSS接着与在它的配置存储库中标识的证书状态报告组件建立通信会话。所述CSS按照CSS配置存储库中所含的方法来构成证书状态请求，并且所述CSS从证书状态报告组件中检索证书状态并关闭与组件之间的会话。所述CSS至少将证书的ID、证书状态和使用期限添加到它的高速缓存中并向正在请求的系统或TCU返回证书状态。 

所述证书状态报告可以是以CRL和CRL的处理为基础进行的。根据发行CA的公布时间表，所述CSS从列在CSS配置存储库中的证书状态报告组件中检索CRL。所述CSS清除它的与发行CA相关联的高速缓冲存储器，根据CRL来解析证书状态，并将所述证书状态放置到它的与该发行CA相关联的高速缓存中。当发行CA通知CRL是可用的时，所述CSS可以从列在CSS配置存储库中的证书状态报告组件中检索CRL。在标准要求所述CRL是完整的CRL的情况下，所述CSS清除与发行CA相关联的高速缓存，对CRL进行解析，并且将证书状态和相关的信息放置到与发行CA相关联的高速缓存中。其中所述CRL包含仅仅在公布全部CRL之后发生的改变，所述CSS根据CRL来解析证书状态并且将证书状态和相关的信息放置到与发行CA相关联的高速缓存中。 

使用CSS来获取这样的证书状态，所述证书状态允许用户、系统或TCU使用单个用于获取证书状态的手段，可以包括以下步骤：为存在于信息对象上的签名块之中的验证证书的状态而查询CSS，在所述状态查询可以使用单个手段(例如，OCSP)的情况下，将所述状态查询翻译成发行CA所需要的形式，并且检索和/或报告证书状态。如果证书状态被撤消，就不使用所述签名块并且需要补救；如果所述数字签名核实并且证书状态是有效的，则所述签名块就被添加到电子原始信息对象中。 

如果状态存在并且当前位于CSS高速缓存/数据存储库中的话，则所述TCU能够通过定位和报告证书状态来查询CSS以确认签字人的验证证书状态，并且获取用于从CSS配置存储库中检索证书状态的类型和方法。如果特定的证书状态方法是CRL并且在CSS中的发行CA高速缓存中没有发现指定的证书的状态，那么所述CSS就将证书状态报告 成有效的。如果证书状态方法不是CRL，那么所述CSS就按照CSS配置存储库中所含的方法来构成证书状态请求，并与发行CA建立适当的通信。所述CSS利用已标识的证书状态检查方法来从状态报告组件中检索证书状态，并关闭通信会话。所述CSS解析或解释检索出的证书状态，关联等于由如CSS策略中陈述的状态类型规定的周期的使用期限值，并且至少将证书的ID、状态和使用期限值添加到发行CA的证书状态高速缓存中。所述CSS继而向请求系统返回证书状态。 

一种用于在系统或TCU中注册用户的方法，在所述系统或TCU中证书是由为CSS所知的经批准的发行CA发放的，所述方法包括：利用已建立的成员程序和标准来检查用户，输入也已经被经批准的机构出资人签署的用户注册信息，以及创建并向已标识的发行CA发送证书请求。所述用户的验证证书被检索、发行，并且被置于要传送的令牌上。执行数字签名、数字签名核实和CSS证书状态检查以确保公用密钥对生成和证书发行过程都被正确地完成。需要用户在用户接受协定上签字，所述接受协定承诺用户给予使用他们的数字签名的权重与他们给予他或它的手写签名的权重相同，所述令牌被交付给用户，并且所述用户的系统或TCU帐户被激活。 

一种在系统或TCU中注册用户的方法，其中用户早已具有由CA发放的、且预先不为CSS所知的证书，所述方法可以包括：为用户的验证证书而查询用户的令牌并获取发行者信息，以及查询CSS知识库以查看所述发行CA是否包含在其中。不然的话，联系行业或机构策略管理者以确定所述发行CA是否满足CA包含物的系统规则。如上所述，在所述发行CA被认为是“未经授权”的情况下，登记终止，而在所述发行CA被认为是“经授权”的情况下，注册继续进行。 

一部分用户验证证书内容可以用于通过以下操作来使所述证书绑定于用户帐户：在批准用户访问系统或TCU之后，输入用户注册信息，插入用户的令牌，这将他们的验证证书保存到本地令牌读取器中，检索并显示证书内容，让用户确认所述内容是正确的，并且将所选的字段添加到从证书中提取的系统或TCU用户注册数据中，所选的字段比如是证书ID、发行CA、在证书扩展部分中传送的用户的可识别名称或其它标识信息的子集(例如，subjectAltName)。可以在系统或TCU策略中规定所提取的数据，以便可以自动进行提取和数据输入。 

一种方法，借此信息对象的提交者担保所提交的信息对象的可靠性，该方法包括以下步骤：将提交者的签名块附加在信息对象和/或包封上并且将其转发到系统或TCU。如果签名块确认失败，则所述TCU就请求重新传输或补救，而如果签名块确认成功，则所述TCU就接着检查提交者的身份是否匹配通信会话的发启人，如果发启人和提交者不同的话就拒绝所述提交。如果所有检查都成功的话，那么所述TCU就将它的签名块添加到所述提交，创建电子原始信息对象。 

一种为采用使用期限数据元素的实时证书状态报告方法维护准确而及时的证书状态的CSS中的方法包括以下这些步骤。如果使用CRL状态方法，那么所述CSS就报告状态。如果证书状态处于高速缓存中并且未超出使用期限数据元素的话，那么所述CSS就报告状态。如果超出了使用期限数据元素，那么所述CSS就从发行CA高速缓存中清除所述证书状态条目。如果使用实时证书状态报告方法(例如，OCSP、LDAP查询等等)检索状态并且所述状态不在高速缓存中的话，那么就请求、检索并报告证书状态。所述CSS继而至少将证书的ID、证书状态和使用期限添加到它的高速缓存中并且将证书状态返回给正在请求的系统或TCU。 

可以将证书状态使用计数器数据元素添加到CSS的发行CA高速缓存中的证书的状态条目当中，并且每次检查证书的状态时就能够使状态使用计数器递增或递减。如果状态使用计数器超过由CSS策略设置的阈值，那么就可以报告证书状态，但是所述CSS接着从发行CA高速缓存中清除证书状态条目。如果CSS返回的证书状态是无效的或被撤消的，接着系统或TCU就记录该错误和/或向提交者和/或交易所有者报告该错误，并且禁止所请求的动作并且寻求补救。否则，所述数字签名就被认为是有效的并且允许所请求的动作。可以添加证书状态最后访问的数据元素，并且与使用计数器结合使用所述证书状态最后访问的数据元素以确定证书状态的活动级。 

当满足CSS策略中的标准时，后台进程可能会令CSS自动地检索更新的证书状态并且建立新的使用期限和使用计数器数据元素。可以实现这种预取以便缩短系统或TCU证书状态请求与CSS响应之间的平均时间。 

如果向CSS发出请求以为新的证书检索证书状态并且发行CA高速 缓存已经达到其所分配的缓冲区大小限制，那么就将证书状态最后访问的数据元素添加至CSS的发行CA高速缓存中的证书状态的条目中。所述CSS搜索发行CA高速缓存以查找对应最旧日期(最不常使用)的最后访问的数据元素并且清除那个条目。所述CSS继而检索所请求的证书状态，将其置于发行CA高速缓存中的空闲单元中，并向根据策略来行动的系统或TCU报告状态。 

一种在分布的CSS中进行状态检查的方法，包括：每当引入新的发行CA时都在CSS之间进行协调，如果另一个CSS主要负责查询发行CA则建立所有CSS知识库中的条目，查询其它CSS而不是查询发行CA以减少CSS与发行CA之间的通信，如果多个本地系统相对于发行CA而言具有证书状态请求的高集中度，则在本地使证书状态同步化并对其进行高速缓存，以及如果另一个CSS比原始初级CSS具有针对指定发行CA的更繁重的活动，则共享或转让查询职责。 

通过将CSS知识库中的发行CA引用变为“未经批准的”来排除与发行CA相关联的一组用户，这可以通过以下操作来完成：请求收回对发行CA的批准，针对优点来审查所述请求并且确定如果有的话需要哪些动作，并且如果确定由于任何原因而应该使发行CA无效的话，那么就将CSS知识库中的发行CA的状态变为“未经批准的”。由列为“未经批准的”CA发出的任何后续的证书状态请求都将导致CSS返回失败的状态。 

一种通过预先将发行CA引用设置为“未经批准的”而重新授权给一组已失效的用户的方法能够通过以下操作来完成：请求准许批准重新授权给发行CA，针对优点来审查请求并且确定如果有的话需要哪些动作，并且如果确定应该重新授权给发行CA，那么就将CSS知识库中的发行CA的状态改为“经批准的”。所述CSS处理对已恢复的发行CA的证书状态请求，就如它是任何其它的“经批准的”CA那样。 

可以通过以下操作来建立与状态报告组件的通信：为每一种用于定位、请求和检索这类信息的证书状态协议创建模块化的和可重复使用的设备，使用与理解特定证书状态协议的所有CA和响应器相兼容的设备的版本，以及持有每一种正在使用的状态报告协议的设备版本。对所述设备进行设计以便使它容易适应于支持未来的证书状态报告协议。 

执行这样的交易，其中提交者是第一TCU并且所述提交是要将一个或多个电子原本的监管转让给第二TCU，执行该交易可以包括：让交易的所有者指示第一TCU将一个或多个电子原始文档的监管转让给第二TCU。交易的所有者指示第二TCU转让一个或多个电子原始文档的监管，并且所有者给第一TCU提供标识哪些电子原本将被转让给第二TCU的清单。第一TCU与第二TCU建立通信，并且识别它的动作对于第二TCU的意图。第一TCU或所有者可以向第二TCU传输清单，以便它能够确定监管转让何时已经完成。第一TCU将每个已标识的电子原本转让给第二TCU，所述第二TCU使用CSS来确保每个转让的电子原本上的第一TCU的数字签名是有效的并确保电子原本未改变。如果第一TCU的数字签名中的任何一个是无效的，那么第二TCU就通知第一TCU并且寻求补救(例如，要求第一TCU使用当前的验证证书重新签署)。如果第一TCU不能履行的话，则第二TCU就记录该事件并且通知交易所有者所请求的监管转让已经失败；否则，第二TCU为每个成功转让的信息对象创建新的包封，添加日期-时间戳和它的签名块。第二TCU通知第一TCU每次成功的转让，并且当完成时，第一TCU可以按照所有者的意愿要么以如下方式来标记或保留拷贝，所述方式就是它们无法被翻译成原本，要目可以销毁所有转让的信息对象存在的拷贝。重复该过程直到转让了所有已标识的电子原本为止。照此，第二TCU变成已转让的记录的监管人，所述已转让的记录是授权拷贝。第二TCU可以添加可靠的日期和时间、对清单进行数字化签署、包封和存储，以使它成为监管线索的独立元素。 

在执行交易的过程中，所有者的指令也可以陈述为发生所有权转让，并且可以把所有权转让文档置于第一TCU或者第二TCU中。有责任的TCU通过核实所有数字签名、证书有效期以及利用CSS来检查证书状态来确认所有权转让文档的可靠性。所述TCU继而添加可靠的日期和时间，并且对被添加到清单中的这些目前的电子原始信息对象进行数字化签署、包封和存储。在这些电子原本都被置于第一TCU中的情况下，在监管的转让之前实施所有权的转让，并且启动清单变成所有权线索的一部分。 

一些转让的记录可能是简单的电子信息对象而不仅仅是电子原本。所述CSS可以使用任何适当的证书状态协议来与系统或TCU相通 信。 

在不背离本发明的必要特征的情况下，本发明能够以许多不同的形式来实施，因此无论从哪一方面，上面描述的实施例应该认为是说明性的而非限制性的。要强调的是，如在本说明书和随后的权利要求中使用的术语“包括”意味着指定所述特征的存在而不排除一个或多个其它特征的存在。本发明的期望范围是由下列权利要求阐述的，而不是由前面的说明书来阐述的，并且意在将落入权利要求范围内的所有变型都包含于其中。 

Claims (28)

1.一种为检查由各个发行证明管理机构CA发放的证书的有效性提供证书状态服务CSS的方法，包括以下步骤：

从请求实体中接收一个或多个关于发放的证书的状态查询；

从处于测试阶段的所述发放的证书提取证书有效期，并检查当前日期和时间是否在有效期内；

如果所述当前日期和时间在所述有效期内，为处于测试阶段的证书检查以查看是否证书状态高速缓冲存储器中存在当前证书状态；

如果在所述CSS证书状态高速缓冲存储器中找到了当前证书状态而且没有超出所述证书状态的使用期限数据元素，则返回那些证书的状态；

如果在所述CSS证书状态高速缓冲存储器中不存在处于测试阶段的所述证书中的任何证书的证书状态或者在所述CSS的证书状态高速缓冲存储器中存在的证书状态超过了所述使用期限数据元素，则从处于测试阶段的证书检索发放的CA字段，从各自发放的CA中检索各证书的状态需要所述CA字段；

检测以查看所检索的发放的CA是否列在经批准的CA列表上，并且如果所述CA没有列在经批准的CA列表上，为CA未列在经批准的CA列表上的那些证书返回无效证书状态；

根据识别出的信息配置连接器以供与发放CA进行通信；

根据所配置的连接器来与发放CA进行通信以请求证书状态；

检索所有查询的证书的状态；

根据合适的证书状态报告方法处理证书状态，所述的证书状态报告方法包括在指定的发布间隔检索的证书撤消列表CRL、当通知时检索的Delta证书撤消列表DeltaCRL、LDAP、OCSP以及任何其它使用实时协议查询和检索的证书状态方法；

在CSS的高速缓存存储器中记录所检索证书状态；

向请求的实体报告所检索的证书状态；

其中在配置存储库中在经批准的CA的列表上指定发行CA和连接器地址信息，而且，在所述经批准的CA的列表上指定的发行CA所用的每个证书状态报告方法的连接器被添加到所述配置存储库中以解释证书状态，以启用在CSS与使用不同证书准则和策略的CA或CA域之间的互操作性。

2.如权利要求1所述的方法，其中如果本地日期和时间落在证书中指示的有效期外，则认为所述证书已过期。

3.如权利要求1所述的方法，其中通过根据预定的商业规则检查和批准所述发行CA来将所述发行CA和所述CA的连接器信息加入经批准的CA的至少一个组织的列表中，并且如果发行CA被检查并且未得到批准，那么将所述发行CA加入在配置存储库中的未被批准CA的组织的列表上。

4.如权利要求3所述的方法，其中检查和批准发行CA包括：利用CSS来登记该CA的信托验证证书的表示，并且至少将所述CA的验证证书的表示、状态类型和使用期限数据元素增加至配置存储库。

5.如权利要求4所述的方法，进一步包括以下步骤：在所述返回在证书状态高速缓冲存储器中找到的证书状态的步骤之后，如果使用计数器数据元素值超过阈值，则从证书状态高速缓冲存储器清除所述证书状态；其中如果在所述本地高速缓存存储器中没有发现所述状态或者所述使用期限数据元素被超过，则CSS与发行CA的证书状态报告组件建立通信会话，根据所配置的连接器来构成使用CRL或实时报告方法其中一种的证书状态请求，从证书状态报告组件中检索该证书状态，关闭与所述证书状态报告组件之间的通信会话，以及将证书的标识、证书状态、使用计数器和使用期限数据元素中的至少一个添加至本地高速缓冲存储器。

6.如权利要求1所述的方法，其中根据发行CA的公布时间表将证书状态报告方法指示为CRL，所述CSS从列在配置存储库中的证书状态报告组件中检索CRL，所述CSS清除与该发行CA相关联的高速缓冲存储器，并且所述CSS分析所述的CRL以及将所述状态存储在与该发行CA相关联的高速缓冲存储器中。

7.如权利要求1所述的方法，其中将证书状态报告方法指示为DeltaCRL；当通过发行CA通知所述DeltaCRL是可用的时，所述CSS从列在配置存储库中的证书状态报告组件中检索所述DeltaCRL；并且如果DeltaCRL是完整的CRL，那么CSS就清除与该发行CA相关联的高速缓冲存储器，从该CRL中提取全部证书状态，并将所述状态存储在高速缓冲存储器中；以及如果所述DeltaCRL包含在公布全部CRL之后发生的变化，那么所述CSS就从DeltaCRL提取所有证书状态，并将所述状态存储在高速缓冲存储器中。

8.如权利要求1所述的方法，其中所述通信步骤包括根据多个连接器与多CA和PKI进行通信。

9.如权利要求1所述的方法，其中连接器允许在单个通信步骤中进行多证书状态检查。

10.如权利要求1中所述的方法，其中如果在主要负责查询发行CA的所有CSS知识库中指定任何CSS，则该CSS就能为证书状态查询另一CSS。

11.如权利要求1所述的方法，其中所述请求实体是信托监管实用程序信托知识库；从所述信托知识库接收一个或多个证书状态查询以及向所述信托知识库报告检索到的证书状态的步骤是通过在所述CSS和所述信托知识库之间执行单一证书状态报告方法而完成的。

12.如权利要求1所述的方法，用于提供由经批准的CA发放的证书的证书状态报告，还包括：

当状态类型是CRL，所述CRL是当前的，并且所述的状态未在所述的高速缓冲存储器中发现时，报告有效证书状态；

当在高速缓冲存储器中发现状态以及使用期限元素未被超出，报告所述状态；

如果所述使用期限元素被超出，则从高速缓冲存储器中清除所述状态；

在报告所述状态后，如果状态使用计数器数据元素值超过阈值，则从高速缓冲存储器中清除所述状态；

当在高速缓冲存储器中未发现所述证书状态或者超出使用期限元素，而所述状态类型不是CRL时，就请求来自其配置存储库的连接信息，并建立与在配置存储库中指示的所述证书状态报告组件通信会话，以便检索该状态；

当所述状态类型是CRL时，在下一个指示的公布时间检索和分析新的CRL；

将证书的标识、状态和使用期限添加至高速缓冲存储器；以及

向请求的实体报告检索出的状态。

13.如权利要求12所述的方法，其中将所述状态使用计数器数据元素添加至高速缓冲存储器中；每次检查证书的状态时就将该状态使用计数器数据元素递增或递减；并且如果状态使用计数器数据元素超过阈值，那么就报告所述证书状态，并且针对该证书状态清除高速缓冲存储器。

14.如权利要求13所述的方法，其中将记录每个高速缓存的证书状态何时最后被访问的数据元素添加至高速缓冲存储器，并且记录证书状态何时最后被访问的所述数据元素与状态使用计数器数据元素结合使所述CSS能够确定证书状态的活动级。

15.如权利要求14所述的方法，其中当对CSS进行请求以检索新证书的状态并且高速缓冲存储器已经到达所分配的存储器大小限制时，对于每一个当前时间超过使用期限值的证书状态条目，每一个使用计数器数据元素值超过所述阈值和具有用于记录每个高速缓存的证书状态何时最后被访问的数据元素的最旧值的证书状态条目，所述CSS搜索和清除高速缓冲存储器，其中所述CSS然后检索所请求的证书状态，将所述证书状态放置在高速缓冲存储器中，并且向请求的实体报告所请求的证书状态。

16.一种通过转让对具有可核实的凭证线索的经验证的信息对象的控制从而在第一当事方和第二当事方之间执行交易的方法，包括以下步骤：

从信托知识库中检索经验证的信息对象，其中所述经验证的信息对象包括具有第一当事方的数字签名以及至少使身份和加密密钥与第一当事方相关的第一证书的第一数字签名块、日期和时间指示符、和包括信托知识库的第二数字签名以及至少使身份和加密密钥与该信托知识库相关的第二证书的第二数字签名块；

由信托知识库来确认第一数字签名块；并且在信托知识库的控制下将经验证的信息对象存储为电子原始信息对象；

通过将第三数字签名块包含在检索出的经验证的信息对象中，从而由第二当事方执行检索出的经验证的信息对象，所述第三数字签名块至少包括第二当事方的第三数字签名和第三证书；以及

将所执行的检索出的经验证的信息对象转发到信托知识库，其中信托知识库通过至少从根据权利要求1的方法所提供的证书状态服务CSS中检索证书的状态的该信息对象，来核实数字签名并且确认与包含在该信息对象中的数字签名相关联的证书；如果相应的数字签名未被核实或者相应的证书的状态期满或被撤消，则所述信托知识库拒绝数字签名块；以及

如果信息对象中的至少一个签名块未被拒绝，则所述信托知识库就将信托知识库的数字签名块以及日期和时间指示符添加到信息对象中并且以第一当事方的名义来控制所述对象。

17.如权利要求16所述的方法，其中所述签名块中的每一种签名块包括至少一部分包含有签名块的信息对象中的至少一个散列，利用所述块的相应签字人的加密密钥来对所述至少一个散列进行加密，由此形成签字人的数字签名，并且将签字人的数字签名包含在具有签字人的证书的签名块中。

18.如权利要求17所述的方法，其中所述执行步骤包括向第二当事方显示本地日期和时间，由第二当事方确认所显示的本地日期和时间是正确的，并且如果任一个不正确，则校正本地日期和时间。

19.如权利要求16所述的方法，其中如果信托知识库拒绝数字签名块，则所述信托知识库就请求需要重新计算数字签名和重新转发签名块的补救。

20.如权利要求16所述的方法，其中所述信托知识库检查本地日期和时间的准确度，并且检查它们是否在由第二当事方的证书指示的有效期内。

21.如权利要求20所述的方法，其中如果本地日期和时间不在由第二当事方的证书指示的有效期内，则所述信托知识库就通知第二当事方所述证书被拒绝并通知第一当事方交易未完成。

22.如权利要求16所述的方法，其中一个或多个数字化手写签名被包含在信息对象中，并且所述信息对象中的数字化手写签名的位置是由至少一个签名标记来指定的。

23.如权利要求16所述的方法，其中所述信息对象中的一个或多个签名块的位置是由至少一个签名标记来指定的。

24.如权利要求23所述的方法，其中独立地将一个或多个签名块转发到具有相应签名标记的信托知识库，并且所述信托知识库通过下列操作来确认签名块：

如果相应数字签名未被核实或者相应证书未被确认，则拒绝签名块，以及

如果签名块未被拒绝则根据相应的签名标记来放置签名块，

其中对于独立地发送的签名块，所述信托知识库将日期和时间指示添加到每个签名块中，并且根据商业规则在包封中附加该信托知识库的签名块，所述包封包含信息对象和放置的签名块。

25.如权利要求24所述的方法，其中所述信托知识库通过下列操作来核实数字签名并且确认签名块中的证书：

根据商业规则来确定与验证证书相关联的第一或第二当事方是否具有权限，

核实第一或第二当事方的数字签名，

检查证书的有效期是否与信托知识库的当前日期和时间重叠，

检查本地日期和时间是否落入偏离信托知识库当前日期和时间的容许偏差范围内，以及

从CSS中检索证书的状态，以及如果前面的任何一个步骤导致无效输出或假输出的话，则认为所述数字签名是无效的，不执行交易，否则就认为所述数字签名是有效的并且执行交易。

26.如权利要求16所述的方法，其中所述CSS至少通过检查本地高速缓冲存储器的状态的步骤来向信托监管实用程序TCU提供证书状态，并且如果在本地高速缓冲存储器中找到所述状态并且本地日期和时间在有效期内，从本地高速缓冲存储器中检索该状态；

如果在本地高速缓冲存储器中没有找到所述状态或者如果本地日期和时间不在有效期内，则所述CSS就与发行CA的证书状态报告组件建立通信会话，根据所配置的连接器构成证书状态请求，从证书状态报告组件中检索所述状态，关闭与证书状态报告组件之间的通信会话，并且至少将证书的标识、状态以及使用期限数据元素添加至本地高速缓冲存储器。

27.如权利要求16所述的方法，其中第一当事方是第一信托知识库，并且交易是用于将一个或多个电子原本的监管从第二信托知识库转让给第一信托知识库，交易的所有者向第二信托知识库提供清单，所述清单标识了待转让给第一信托知识库的电子原本，第二信托知识库建立与第一信托知识库通信并且识别其动作的目的，将所述清单传送给第一信托知识库以便使它能够确定监管的转让何时已经结束，第二信托知识库将每个已标识的电子原本转让给第一信托知识库，第一信托知识库检索第二信托知识库的证书的状态并且在每个已转让的电子原本上核实第二信托知识库的数字签名，如果任何一个第二信托知识库的数字签名或证书是无效的，那么第一信托知识库就通知第二信托知识库并且寻求补救，如果第二信托知识库没有提供补救，则第一信托知识库就通知交易所有者所请求的监管转让已经失败，否则第二信托知识库就为每个成功转让的信息对象创建新的包封，添加日期-时间戳和第一信托知识库的签名块。

28.如权利要求27所述的方法，其中所述交易是响应于指令的所有权转让，将所有权转让文档放置于第一信托知识库或者第二信托知识库中，具有所有权转让文档的信托知识库通过核实所有数字签名、证书有效期以及利用CSS检查所有权转让文档中所包含的所有证书的证书状态来确认所有权转让文档的可靠性，添加日期和时间指示，并且对被添加到清单中的所有权转让文档进行数字签署、包封和存储。

Images