批处理ocsp和批处理分布式ocsp的制作方法

专利名称：批处理ocsp和批处理分布式ocsp的制作方法
相关申请交叉索引本申请要求2004年1月9日申请的美国临时申请60/535,666和2004年1月15日申请的美国临时申请60/536,817的优先权，两个申请均通过引用组合于此。
背景技术：
1.技术领域本申请涉及数字证书领域，特别是涉及验证和确认数字证书及其它信息的领域。
2.背景技术数字签名提供有效形式的因特网鉴别。不像传统的密码和PIN，数字签名以到处可证实的方式鉴别事务。因此，否定已被数字签署的事务是很难的，但并非不可能。数字签名经签署密钥SK产生，并经相配的验证密钥PK进行验证。用户U保密其自己的SK，从而只有U可代表U签署。幸运地，密钥PK不会“背叛”相配的密钥SK；即PK的知识在计算SK时并不提供任何实际的优点。因此，用户U可使其自己的PK尽可能的公开，从而每个人均可验证U的签名。为此，PK被称为公钥。
数字证书是字母数字串，其通过保证给定密钥PK真地是用户U的公钥而使能数字签名。认证机构(CA)产生并发出证书给用户，但通常仅在确定用户的身份之后进行。因此，证书证明CA已验证持有人的身份以及其它属性。证书在指定时间后过期，在公共CA的情况下通常为一年。
大体上，数字证书C由将几个数安全绑定在一起的CA数字签名组成，所述几个数为对证书唯一的序号SN、用户的公钥PK、用户名U、发出日期D1、期满日期D2、及其它数据。表示成符号
C＝SIGCA(SN，PK，U，D1，D2，...)能够确定数字证书的状态是有用的，包括确定特定证书是否被有效发出和/或确定在证书过期之前其是否已被废除。有很多技术可用于确定单个数字证书的状态。例如，美国专利5,666,416和5,717,758描述了提供单个证书状态的技术。其它用于散布和确定证书状态的技术也是众所周知的，包括证书废除列表(CRL)，其是数字签署的废除证书的列表，及包括在线证书状态协议(OCSP)，其规定查询特定证书的状态的机制。
CRL通过使每一CA定期发出载明适当日期且数字签署的列表(CRL)而进行工作，所述列表包含作废证书的序号。在某些实践中，CRL包含给定证书组的所有作废证书。因此，数字证书可和与最近CRL比较的电子事务一起呈现。如果给定证书未过期但在已被废除证书的列表中，则从CRL可知道证书无效且证书持有人不再有权执行由数字证书使能的事务。另一方面，如果证书没有出现在CRL中，则证书被视为有效。或者，CRL可与每一事务的其它记录一起存档，以在将来能够证明事务的有效性，或在作废证书的情况下，证明拒绝服务是正确的。
假定作废率为10％，则平均10个数字证书就有1个在其期满前被废除。根据这样的作废率，具有1000万证书的系统将产生包含100万序号的CRL，这可能使得CRL很难处理。尽管可通过最近出现的CRL分区技术减轻该问题，但将许多证书的作废信息打包在一起的基本策略依然可能产生不方便和成本。如果序号是24位长(以处理几百万证书)，1000个证书的子CRL将是24000位(3000字节)长。在某些部署中，由于开销，每一证书的CRL条目为22位长，因而1000证书的子CRL为22000位长。但在某些情形下这是不可接受的，例如，在无线事务情形下，必须传送这么多位(保护未来的争议及可能的合法要求)是不切实际的。
CRL逐渐变大，因为它们提供关于集中在一起的许多证书的作废证明(因而间接地提供有效性证明)。通过比较，OCSP可提供各个证书的有效性证明。传统的OCSP服务使用可从客户(即依赖方)接收问题的OCSP应答器，所述问题关于给定CA发出的给定证书的有效性，响应于此，OCSP可提供数字签署的答案，其指明证书的状态及关于该答案的时间信息。
为能够提供OCSP服务，传统的OCSP应答器被提供以关于CA的所有证书的状态的信息。由于通常CA可确定其自己的证书的状态，如果OCSP应答器是CA自身，则OCSP应答器/CA已经具有关于证书作废状态的信息。另一方面，如果OCSP应答器不是CA，则OCSP应答器可被保持更新CA的证书状态。例如，可参见美国专利5,717,758基于证据的证书废除系统。
CA可通过发送最近的CRL而更新OCSP应答器。OCSP应答器可查阅该CRL以推断感兴趣的特定证书在当前有效还是已被废除，从而OCSP应答器可向依赖方提供签署的响应，其指明当前CRL的时间、下一次更新的时间及实际处理的时间。
当然，恶意/被损害的OCSP应答器可提供任意签署的关于给定CA的证书的答案，查阅或不查阅任何CRL。因此，为使依赖方安全依赖OCSP应答器数字签署的关于给定CA的证书的答案，OCSP包括机制CA向OCSP应答器提供应答器证书，由CA签署的特殊数字证书，其实质上向其它方担保CA信任该OCSP应答器以提供关于CA的证书的准确证明。应注意，为使该过程适当地工作，每一OCSP应答器(及每一CA)必须具有秘密签署的密钥，且该密钥必须被保护(如通过将实现该应答器的服务器放在保险库中进行保护)。
参考图1，示意图40示出了传统OCSP环境中的信息流。示意图40包括CA42、传统OCSP应答器44、及依赖方46。用于CA42和OCSP应答器44的粗线表明存在必须被保护的密钥以使系统可靠运行。CA42向OCSP应答器44提供有效性信息48(如CRL)。依赖方46向OCSP应答器44其它OCSP请求52。OCSP应答器44检查CA42提供的有效性信息(如CRL形式)并确定所涉及证书的有效性状态。之后，OCSP应答器44准备相应的响应，数字签署该响应并将其作为OCSP应答器54的结果提供给依赖方46。在某些情况下，OCSP应答器44还可向依赖方46提供应答器证书56，其指明OCSP应答器44被CA42授权和委托。
但OCSP有很大的缺陷。首先，数字签名是计算集中的运算。由传统OCSP应答器在每一OCSP响应上建立的数字签名在请求时产生，并可能是确认运算的最计算集中的部分。例如，产生数字签名可增加50毫秒到1秒的事务处理时间。即使传统的OCSP应答器在数字证书C第一次被询问之后缓存关于C的数字签名，并在以后询问C时发送所缓存的签名，由于产生初始数字签名，对询问C的第一用户的回答仍然会被大大延迟。
此外，如果只有一个OCSP应答器，则所有证书有效性查询实际上均被发送给该单一OCSP应答器，之后，其变为主要网络瓶颈并导致相当的拥塞和延迟。如果大量的诚实用户突然查询该OCSP应答器，则中断拒绝服务的情形将跟着发生。
另一方面，为防止集中实施OCSP的问题，机构可考虑跨几个适当证明的、传统OCSP应答器分布请求负载(关于其证书的有效性)。总地来说，跨几个(如100个)战略分布在全球(以避免传输瓶颈)的服务器分布单一服务器的负载可减轻网络拥塞。然而，对于OCSP，负载分布可导致另外的问题，因为，为提供针对证书有效性查询的签署的响应，100个分布式传统OCSP应答器中的每一个均具有其自己的秘密签署的密钥。因此，泄密100个服务器中的任一个均可有效地使整个几个泄密。实际上，如果传统OCSP应答器被泄密，则攻击者可使用已发现的秘密签署的密钥不实地签署响应，其指明(1)有效证书已被废除，或(2)作废证书依然有效。该后一类型的假阳性响应可允许已被解雇的雇员重新获得进入系统的权利。
防止应答器被泄密的一种办法是从安全的保险库运行应答器，其具有全天候监视。不幸的是，这是成本非常高昂的选择。真正安全的保险库，比如满足金融CA的所有要求的保险库，仅建立就须100万美元以上，且每年的运行费用也在100万美元左右。此外，即使机构愿意支付这样的支出，保险库也不可能在一夜之间建成。因此，如果CA需要几个保险库来减轻其当前传统OCSP应答器的负荷，在新的适当保护的OCSP应答器建好之前将有几个月的延迟。
此外，招致几个保险库的花费并不能解决OCSP安全问题。这是因为，OCSP机制要求传统OCSP应答器接收来自非置信来源(依赖方)的请求，并使用应答器的秘密签署的密钥服务于该请求。因此，怀恶意的依赖方(或佯装依赖方的怀恶意的代理)更喜欢通过在基本操作系统中发现可能的弱点而曝光OCSP应答器签署的密钥。
而且，在服务于源自不同安全域的证书有效性请求时，有几个困难与OCSP有关。例如，由机构A运行的传统的OCSP应答器可容易地提供关于机构A的CA的证书状态的响应，但由另一机构运行的OCSP应答器并没有足够的信息来提供关于“外来”证书的响应。
源于缺乏特定知识的该问题可能以下述两种方式之一进行处理。第一，来自机构B的依赖方可从机构A的应答器获得机构A的CA的证书状态。然而，这限制了性能，因为来自机构A的OCSP应答器可能在地理上远离机构B的依赖方，从而网络时间可大大减慢整个确认处理。第二种方式是允许来自机构B的应答器可做出关于机构A的证书的响应，其通过使来自机构A的CA将机构A的CRL转发给外来应答器而实现。实际上，CRL被数字签署因而不必保密，且机构A的CA按理应希望将机构A的证书的有效性状态通知给尽可能多的受众。该第二方式向机构B的OCSP应答器提供足够的信息以回答来自依赖方的、关于机构A的证书的请求。要不是依赖方重视机构B的OCSP应答器的数字签署的答案，机构A的CA还应证明外来应答器在回答关于机构A的证书的有效性查询方面是可信赖的。
参考图2，示意图60示出了图1的示意图40中所示的CA42、传统OCSP应答器44、及依赖方46。然而，在示意图60所示的情形下，依赖方46提供关于证书的OCSP请求62，其不由CA42管理，而是由不同的CA64发出和管理。在这种情况下，OCSP应答器44不可单独基于CA42提供的CRL48内的信息向OCSP应答器44提供OCSP响应。而是，CA64提供不同的CRL66和不同的应答器证书给OCSP应答器44。之后，OCSP应答器44使用不同的CRL66制订关于外来证书的OCSP响应72。在某些情况下，OCSP应答器44还可向依赖方46提供应答器证书68。
该第二种方式可提供更好的可扩缩性和性能，但其使两个机构之间的安全和信任流混乱。在示意图60中，OCSP应答器44正给予依赖方权威响应，即CA64的证书依然有效。如果OCSP应答器44因为任何原因(误配置、敌对攻击、或直接不诚实)而给出不正确的响应，则OCSP应答器44可消极影响CA64的机构。通过允许OCSP应答器44做出关于CA64的机构的证书的权威声明，CA64的机构放弃其先前拥有的某些信任。
作为例子，假设机构为信用卡发行人。来自机构A的银行废除用户的证书，且银行确保机构A的传统OCSP应答器是安全且可靠的。假定机构B的OCSP应答器被误配置，当机构B的商户依赖方询问用户的有效性时，机构B的应答器不正确地回答用户有效。商户接受该回答并允许进行作废用户的交易。机构之间的这种类型的信任授权在某些情况下是可接受的，但对于任何大规模的传统OCSP的不同种类部署，其几乎没有用。
因此希望提供可解决上述困难的系统。

发明内容
根据本发明，提供关于数字证书有效性的信息包括为一组数字证书中的多个数字证书的每一个确定数字证书有效性状态，产生关于多个数字证书的数字证书集的至少一子集的有效性状态的多个人工预计算的消息，其中至少一消息指明一个以上数字证书的有效性状态，及数字签署人工预计算的消息以提供OCSP格式响应，其响应于关于数字证书集中的特定数字证书的OCSP查询，其中至少一数字签名连同OCSP格式响应用于一个以上数字证书。产生并数字签署可在任何OCSP查询被任一OCSP格式响应回答之前进行。确定数字证书有效性状态包括获得关于数字证书的经鉴定的信息。关于数字证书的经鉴定的信息可由废除证书的实体产生。关于数字证书的经鉴定的信息可以是CRL。产生多个人工预计算的响应可包括为数字证书集中至少所有未作废的数字证书产生响应。提供关于数字证书有效性的信息还可包括，在数字签署人工预计算的消息之后，将其结果转发给服务于依赖方的请求的多个应答器，所述依赖方询问数字证书集中的数字证书的有效性状态。提供关于数字证书有效性的信息还可包括，使包含公开验证密钥的特殊数字证书可为应答器所用，所述密钥用于验证在数字签署人工预计算的响应时提供的数字签名。发出特殊数字证书的实体还可发出数字证书集的证书。产生多个人工预计算的响应及数字签署人工预计算的响应可周期性地执行。人工预计算的响应可包括对应于人工预计算的响应在何时产生的时间信息。
根据本发明，保存在计算机可读介质上的、提供关于数字证书有效性信息的计算机软件包括为一组数字证书中的多个数字证书的每一个确定数字证书有效性状态的可执行代码，产生关于多个数字证书的数字证书集的至少一子集的有效性状态的多个人工预计算的消息的可执行代码，其中至少一消息指明一个以上数字证书的有效性状态，及数字签署人工预计算的消息以提供OCSP格式响应的可执行代码，其响应于关于数字证书集中的特定数字证书的OCSP查询，其中至少一数字签名连同OCSP格式响应用于一个以上数字证书。确定数字证书有效性状态的可执行代码包括获得关于数字证书的经鉴定的信息。关于数字证书的经鉴定的信息可由废除证书的实体产生。关于数字证书的经鉴定的信息可以是CRL。产生多个人工预计算的响应的可执行代码可包括为数字证书集中至少所有未作废的数字证书产生响应。计算机软件还可包括将数字签署的人工预计算消息转发给服务于依赖方的请求的多个应答器的可执行代码，所述依赖方询问数字证书集中的数字证书的有效性状态。计算机软件还可包括使包含公开验证密钥的特殊数字证书可为应答器所用的可执行代码，所述密钥用于验证在数字签署人工预计算的响应时提供的数字签名。发出特殊数字证书的实体还可发出数字证书集的证书。产生多个人工预计算的响应及数字签署人工预计算的响应的可执行代码可周期性地产生和签署响应。
根据本发明，提供关于数字证书有效性的信息包括获得多个签署密钥/验证密钥对，其中每一签署密钥提供数字签名及相应的验证密钥验证该数字签名，其中使用签署密钥一起数字签署多个数据元相较个别地数字签署每一数据元在计算上效率更高，为一组数字证书中的每一证书确定数字证书有效性状态，产生关于数字证书集的至少一子集的有效性状态的多个人工预计算的消息，并使用来自密钥对的签署密钥一起数字签署人工预计算的消息。确定数字证书有效性状态可包括获得关于数字证书的经鉴定的信息。关于数字证书的经鉴定的信息可由废除证书的实体产生。关于数字证书的经鉴定的信息可以是CRL。人工预计算的响应可以是OCSP格式响应。产生多个人工预计算的响应包括为数字证书集中至少所有未作废的数字证书产生响应。提供关于数字证书有效性的信息还可包括，在数字签署人工预计算的消息之后，将其结果转发给服务于依赖方的请求的多个应答器，所述依赖方询问数字证书集中的数字证书的有效性状态。产生多个人工预计算的响应及数字签署人工预计算的响应可周期性地执行。人工预计算的响应可包括对应于人工预计算的响应在何时产生的时间信息。提供关于数字证书有效性的信息可包括鉴定验证密钥。鉴定验证密钥包括在单一数字证书中提供验证密钥。鉴定验证密钥可包括在分开数字证书中提供每一验证密钥。
根据本发明，保存在计算机可读介质上的、提供关于数字证书有效性信息的计算机软件包括获得多个签署密钥/验证密钥对的可执行代码，其中每一签署密钥提供数字签名及相应的验证密钥验证该数字签名，其中使用签署密钥一起数字签署多个数据元相较个别地数字签署每一数据元在计算上效率更高，为一组数字证书中的每一证书确定数字证书有效性状态的可执行代码，产生关于数字证书集的至少一子集的有效性状态的多个人工预计算的消息的可执行代码，及使用来自密钥对的签署密钥一起数字签署人工预计算的消息的可执行代码。确定数字证书有效性状态的可执行代码可包括获得关于数字证书的经鉴定的信息的可执行代码。关于数字证书的经鉴定的信息可由废除证书的实体产生。关于数字证书的经鉴定的信息可以是CRL。人工预计算的响应可以是OCSP格式响应。产生多个人工预计算的响应的可执行代码包括为数字证书集中至少所有未作废的数字证书产生响应的可执行代码。计算机可包括鉴定验证密钥的可执行代码。鉴定验证密钥的可执行代码可在单一数字证书中提供验证密钥或在分开数字证书中提供每一验证密钥。
根据本发明，帮助第一方和第二方之间的交易包括，在开始交易之前，交易方之一获得关于特定数字证书的人工预计算的OCSP响应，其中人工预计算的OCSP响应由不同于第一方和第二方的实体产生，交易方之一开始交易，在交易时，第一方提供特定数字证书给第二方，第二方使用人工预计算的OCSP响应验证该特定数字证书。第二方可在交易开始之前获得人工预计算的OCSP响应。第二方可缓存人工预计算的OCSP响应以用于将来交易。第一方可在交易开始之前获得人工预计算的OCSP响应。第一方可缓存人工预计算的OCSP响应以用于将来交易。帮助第一方和第二方之间的交易还可包括在交易开始之后第一方提供人工预计算的OCSP响应给第二方。
根据本发明，确定数字证书的有效性包括检查数字签署的关于数字证书有效性的消息，其中消息由不同于发出数字证书的实体的特殊实体数字签署，且还包括使用来自至少下述之一的信息验证数字签署的消息数字证书和鉴定发出数字证书的实体的证书。信息可以是对应于用于数字签署消息的秘密密钥的公钥。信息可对应于鉴定数字签署消息的特定实体的特定数字证书。
根据本发明，为数字证书集中的每一证书确定数字证书有效性状态包括定期产生多个数字签署的关于数字证书集的至少一子集的有效性状态的人工预计算消息，并定期将数字签署的人工预计算消息转发给多个服务于依赖方的请求的应答器，所述依赖方询问数字证书集中的数字证书的有效性状态，其中关于一些证书的消息以不同于关于其它证书的消息的频率进行转发。相较关于有效证书的消息，关于作废证书的消息可相对不频繁地进行转发。
根据本发明，保存在计算机可读介质中的、确定数字证书有效性的计算机软件包括检查数字签署的关于数字证书有效性的消息的可执行代码，其中消息由不同于发出数字证书的实体的特殊实体数字签署，且还包括使用来自至少下述之一的信息验证数字签署的消息的可执行代码数字证书和鉴定发出数字证书的实体的证书。信息可以是对应于用于数字签署消息的秘密密钥的公钥。信息可对应于鉴定数字签署消息的特殊实体的特殊数字证书。
根据本发明，保存在计算机可读介质中的、提供关于数字证书有效性的信息的计算机软件包括为数字证书集的每一证书确定数字证书有效性状态的可执行代码，定期产生多个数字签署的关于数字证书集的至少一子集的有效性状态的人工预计算消息的可执行代码，及定期将数字签署的人工预计算消息转发给多个服务于依赖方的请求的应答器的可执行代码，所述依赖方询问数字证书集中的数字证书的有效性状态，其中关于一些证书的消息以不同于关于其它证书的消息的频率进行转发。相较关于有效证书的消息，关于作废证书的消息可相对不频繁地进行转发。
在此描述的系统是节省成本的、安全的、可升级的、且整体有效的确认系统，其大大提高了传统的方法。在此描述的系统，即使在保持与OCSP标准的兼容性时，仍较传统OCSP有很明显的优点，从而在质量上提供超级安全性和可扩缩性。
在此描述的系统是独立于传统OCSP工作的一般、独立系统。然而，在一些实施例中，该系统可以是OCSP兼容的，其中根据在此描述的系统的有效性的每一证明均被构造成句法正确的数字签署的OCSP响应，使得依赖方请求并继而根据OCSP格式验证证书有效性信息等。数字签名是计算集中的运算，但在此描述的系统将该困难集中在单一专用服务器上，或者，在其它实施例中，集中在少量的专用服务器上。因此，装备单一专用服务器(或少量服务器)非常容易且相对便宜，其具有足够计算能力以在每一更新时处理所有必需的数字签名。在于此描述的系统中使用的应答器仅需执行普通的读取-转发操作，因而可较传统OCSP应答器更快地服务于输入的依赖方查询，因为传统OCSP应答器必需执行复杂的数字签名。
由于用于在此描述的系统的应答器可采用普通硬件且不需保护，因而可相对便宜地购买和运行应答器。因此，相对大量的应答器可以相对低的开销进行部署。因此，即使在短时间内产生了大量的证书有效性状态请求，该负荷可被分散到许多应答器，从而在不产生太多花费的情况下消除拥塞及良性拒绝服务的风险。应注意，用于在此描述的系统的数字签名的数量取决于证书的数量并相对独立于有效性状态请求的数量。因此，即使预计有相当大量的有效性请求，也可使用单一服务器提供数字签署的响应。
在于此描述的系统中，只有一个专用服务器(或少量专用服务器)及CA(如果不同于单一专用服务器)需要被保护/放入保险库。实际上，在此描述的系统的应答器不保存任何秘密密钥它们仅保存提供给应答器的预计算响应的数字签名，其一旦被计算，则不可能被恶意修改，因而不需要保密。作为对比，所有传统OCSP应答器均需要保护，因为传统OCSP应答器中的每一个均具有秘密签署的密钥，其中之一泄密将使整个系统泄密。因此，在此描述的系统比OCSP更安全，因为保护一个站点(或少量站点)比保护许多且同等重要的站点更可取且更容易。
此外，与OCSP情形不同，依赖方不能容易地在于此描述的系统上安装软件攻击程序。即使依赖方成功地在其查询中嵌入某种类型的特洛伊木马，其也不能使任何秘密公开，因为在此描述的系统的应答器不拥有任何秘密应答器仅保存和返回提供给应答器的预计算的数字签名。因此，所有怀恶意的依赖方希望公开是全部的、准确的、及数字签署的账户，包括在给定时间间隔内哪些证书有效和哪些已作废。然而，这不仅不是秘密信息，且实际上，其是CA希望广为人知的信息，以防止依赖方不正确地依赖于CA发出的已作废的证书。
此外，应注意，软件攻击程序不能容易地针对数字签署预计算响应的单一专用服务器(或少量专用服务器)进行安装。在一些实施例中，单一专用服务器(或少量专用服务器)不处理非置信来源的请求，而是仅接收来自CA的信息并提供数字签署的信息给应答器。因此，不可能在于此描述的系统中插进特洛伊木马。
除了这些优点外，在此描述的系统还使在包括多个机构的异机种部署内能具有很大的灵活性。来自一机构的应答器可将人工预计算的响应转发给另一机构，而无须向另一机构分布任何信任。第一机构可使另一机构的应答器为第一机构提供可相信的有效性证明，而不用放弃对第一机构的证书的有效性状态的任何数量的控制。即，在于此描述的系统中，信任可从一机构流到另一机构，而不会损失任何安全性或控制。在一些实施例中，应答器可被处理为透明的网络基础设施，而不是硬化的信任点。这类似于因特网的DNS基础设施提供的服务云，因为其允许名称服务器的异类集合，这些名称服务器相互透明地合作运行以发现和缓存对查询的有效响应。
安全的异机种性是在此描述的系统相对于传统OCSP的主要优点。安全的异机种性允许多种机构合作运行，从而来自不同机构的依赖方可以安全、可靠、有效的方式交叉确认来自其它机构的证书。
在此描述的系统将所有确认信任提供在单一权力机构(或少量权力机构)中，同时跨任意数量的无保护的应答器分布查询负荷。在此描述的系统不会降低安全性，即使所分布的实施依赖于相当大量的即使未受保护的应答器也是如此。在此描述的系统改善了对查询的响应时间。在此描述的系统不会授权信任给异机种环境中的外来应答器。


图1所示为提供OCSP响应给依赖方的现有技术系统。
图2所示为在异机种环境中提供OCSP响应的现有技术系统。
图3所示为根据在此描述的系统的实施例的RTC系统。
图4为根据在此描述的系统的实施例初始化RTCA的流程图。
图5为根据在此描述的系统的实施例在CA和RTCA之间进行通信的流程图。
图6为根据在此描述的系统的实施例将数据从RTCA进栈到RTC应答器的流程图。
图7为根据在此描述的系统的实施例RTC应答器从RTCA获取数据的流程图。
图8为根据在此描述的系统的实施例RTC应答器提供信息给依赖方的流程图。
图9为根据在此描述的系统的实施例RTC应答器获取有效性信息的流程图。
图10为根据在此描述的系统的另一实施例RTC应答器获取有效性信息的流程图。
图11为根据在此描述的系统的实施例帮助双方交易时所执行步骤的流程图。
图12为根据在此描述的系统的实施例数字证书的示意图。
图13为根据在此描述的系统的实施例CA、RTCA、RTC应答器和依赖方之间的数据流的示意图。
图14为根据在此描述的系统的实施例，第一系统的CA、RTCA、RTC应答器及依赖方和第二系统的CA、RTCA、RTC应答器及依赖方之间的数据流的示意图。
图15为根据在此描述的系统的实施例RTC应答器的异类云的示意图。
图16为根据在此描述的系统的实施例进行优化的流程图。
图17为根据在此描述的系统的实施例的特许机构的示意图。
图18为根据在此描述的系统的实施例在CA、SERTCA、RTC应答器和依赖方之间的数据流的示意图。
图19为根据在此描述的系统的实施例，为成批OCSP处理提供信息给RTCA/SERTCA/OCSP应答器的流程图。
图20为根据在此描述的系统的实施例，为成批OCSP处理提供信息给RTC应答器的流程图。
具体实施例方式
在此描述的系统使用实时凭证(RTC)，也被称为分布式OCSP(DOCSP)，并使用称为RTC权力机构(RTCA)的实体。RTCA可以也可不与给定企业的CA相一致。在一些实施例中，每一CA向其自己的RTCA提供以特殊证书，RTCA证书。CA可数字签署RTCA证书，以表明CA信任并授权RTCA提供关于CA发出的证书的有效性信息。RTCA证书可将RTCA状态传给给定实体(如由给定标识符、OID号等确定的实体)并可将特定验证密钥PK(特定实体拥有相应的秘密签署的密钥)赋值给特定实体。
在CA和RTCA一致的情况下，RTCA具有不同于CA的签署密钥是有利的。因此，如果CA和RTCA为同一实体，实体的CA部分实际上仅发出证书而实体的RTCA部分仅通过证明特定证书是有效还是已作废而管理证书。因此，即使CA和RTCA重合，依然可使用RTCA证书。
在一些实施例中，每一CA与唯一一个RTCA相关联。在其它实施例中，也可能每一CA与一个以上RTCA相关联，其中每一RTCA具有不同的签署密钥，或者，部分或所有RTCA共享签署密钥。使多个RTCA与CA相关联对冗余目的而言是有利的。在其它实施例中，也可能使一个或多个RTCA与多个CA相关联。
正象CA保护其签署密钥那样，RTCA保护其签署密钥，例如借助于保险库、安全设施或安全的硬件。在一些实施例中，RTCA可被放入受保护的设施中，其包括一个以上具有秘密签署密钥的服务器。设施可安全地保存秘密签署密钥的拷贝。RTCA可包括一个以上服务器，每一服务器均具有由CA适当证明的秘密签署密钥。
CA可保持RTCA知道CA的证书的有效性状态，例如通过使用CRL或使用任何其它机制。CA可(1)只要发生变化，即以在线方式将证书有效性的任何变化通知给RTCA；和/或(2)以固定时间间隔和/或在CA产生新CRL时将CRL发送给RTCA。CA可使用大量技术中的任一或多个(单独或组合)来提供各个证书状态信息。例如，参见美国专利5,420,927、5,604,804、5,610,982、6,097,811、6,301,659、5,793,868、5,717,758、5,717,757、6,487,658及5,717,759中提供的内容，所有这些专利均通过引用组合于此。在此描述的系统可使用这些专利中的一个或多个公开的技术，也可与一个或多个其它适当的技术相结合。可被单独或结合使用的技术包括全部CRL、分割的CRL、CRL增量、OCSP响应(单独或成组)、迷你CRL(逐位压缩的CRL)、VTokens(单向散列链)、及各种Merkle树或其它树形。
在一连串日期D1、D2、…的任一日期Di，RTCA，基于其当前的有效性状态的知识(如基于CA的最新CRL)并独立于任何依赖方请求，可通过处理CA的每一未完成的证书并数字签署说明每一证书的状态的声明而执行更新。例如，每一证书的状态可被视为有效、已作废、或延缓决定(及可能“不知道”)。签署的声明可指定时间间隔T。在一些实施例中，在每一更新时，每一签署的声明均指定相同的时间间隔T，而在一些实施例中，全体时间间隔是连续的。例如，在每一更新日期Di，时间间隔可以是T＝Di+1-Di，其中可能Di和Di+1中只有一个是T的一部分，而其它日期是相邻时间间隔的一部分。在一些实施例中，如果RTCA当前关于证书状态的知识是基于CRL，则每一Di可与一CRL的日期一致，且Di+1与下一CRL的日期一致，依此类推。应意识到的是，这样严格的时间依存并不是必需的。例如，RTCA处理或开始处理其声明的日期可以是D1、D2等，而在声明内指定的时间间隔可以是D1’、D2’等，其中Di和Di’可以不同和/或相互独立。例如，Di可早于Di’，在这种情况下，RTCA可在声明的时间间隔开始之前开始处理声明一例如，因为RTCA希望在间隔T开始之前完成其处理。
在一些实施例中，如果CRL被用于来自CA的RTCA更新，声明时间和CRL时间也可不同。在处理时间、CRL时间和声明时间之间可能缺乏同步对在此描述的相同并不至关重要。在实践中，“实时”是抽象，因为需要一些额外的时间来通知并对事件做出适当地反应。首先，应注意，虽然推进RTCA进程，但CRL可能不被实时产生。此外，废除证书的过程也可能不是实时的。例如，用户可能已认识到其秘密密钥已被泄密—因而请求废除其自己的证书—仅在泄密实际发生后一天内。因此，用户证书的废除有1天的延迟，相比较而言，由于RTCA计算引起的与实时的偏差可以忽略不计。
RTCA预计算数字签名，其指明每一证书在特定时间间隔T期间的状态。这样的预计算可独立于任何一方关于证书有效性的请求进行。在一些实施例中，在做出关于C的任何状态查询之前，甚至可能在时间间隔开始之前，RTCA预计算在特定时间间隔中证书C的状态的签署的声明。
在一些实施例中，RTCA签署的证书状态声明可以是标准OCSP格式。这在OCSP软件已经到位的情况下是有用的，从而可方便地利用RTC系统，而不需修改任何现有的依赖方OCSP软件。在一些实施例中，OCSP一致可通过特别选择有关的数量、数字签名算法、OID等而实现。
在许多情况下，RTCA需要为每一发出的证书产生响应，而不是仅对作废证书产生响应。为确定每一发出的证书序号的存在，RTCA可由CA或另一实体给予每一证书的拷贝以用于内部跟踪，或者RTCA可通过另一机制给予发出的序号，所述机制不包括传送各个证书。在一些实施例中，在证书序号是按连续顺序发出的特殊情况下，发出的证书信息可不必明确地提供给RTCA。当使用连续序号时，RTCA可选择仅使用当前CRL推断每一证书序号的存在。这可通过确定CRL中的最低和最高序号完成。在高和低序号之间的范围中的任何中间号均由CA发出。如果范围中的号出现在CRL中，则可知道其状态为已作废。如果范围中的中间号没有出现，则可确定相应的证书尚未被废除，在OCSP标准中其被定义为“有效”。
上述技术可处理所发出证书的大部分，尽管仍然有少量被发出的证书具有或低于最低CRL条目或高于最高CRL条目的序号。RTCA可通过可配置参数包括这些另外的序号，所述参数假定在CRL中第一条目之前和最后条目之后有固定数量的有效序号。例如，RTCA可指定在最低CRL条目之前有100个序号及在最高CRL条目之后有500个序号代表有效证书。这种优化允许RTCA取回一个数据元(CRL)而不是大量数据元(各个证书)。在证书是按从低到高的连续序号发出的情况下，在高端使用的较高号码可用于容纳新发出的证书。在其它实施例中，所发出证书的最低和最高序号可被明确地提供给RTCA，且在一些实施例中，该信息可被数字签署。
应注意，预计算的句法正确的OCSP响应在技术上可被视为不是OCSP响应，因为这些响应并不是响应于任何原始/初始请求而进行计算的。实际上，RTCA对尚未产生且可能永远也不会产生的OCSP请求预计算依从OCSP的响应。因此，RTCA响应可被视为人工预计算的响应。还可能使用术语人工预计算的响应表示任何数字签署的RTCA声明，即使在不依从OCSP的情形也可能使用。
在产生人工预计算的响应之后，RTCA可给出可用于其它方的响应。具体地，RTCA可响应于有效性状态查询返回响应给依赖方。然而，在其它实施例中，RTCA可给出可用于RTC应答器的人工预计算响应。RTC应答器不必保护，因为在实践中RTCA签署的消息(人工预计算响应)不可能以不可检测的方式进行欺骗性地修改或纂改。因此，RTCA可发送人工预计算响应给外来应答器(属于其它机构的应答器)，而不会危害安全性。
在一些实施例中，RTCA可通过以适当组织的方式将人工预计算响应呈现给RTC应答器而帮助RTC应答器进行的处理。例如，RTCA可呈现根据证书序号或根据长度等排序的人工预计算响应。为确保所有有关的人工预计算响应均已被接收，在每一次更新时，RTCA可通过签署全体人工预计算响应并注明日期而向RTC应答器提供另外的签名。在一些实施例中，可使用人工预计算响应的数量的计数或类似机制，具有也可没有数字签名。
此外，RTCA可将CA产生的RTCA证书发送给RTC应答器以证明CA信任和授权RTCA提供关于CA发出的证书的有效性信息。在一些实施例中，不必在每次更新时均进行该发送。在一些情况下，RTCA仅在开始或以某一固定周期或基于请求发送RTCA证书给RTC应答器。
RTC应答器可将所接收的RTCA的人工预计算响应保存足够长的时间。在一些实施例中，如果RTCA的签名涉及特定时间间隔T，RTC应答器可将人工预计算响应至少保存到T结束为止。在一些实施例中，至少部分RTC应答器，如那些与RTCA属于同一机构的应答器，可定期采取措施以确保信息是正确且最新的。例如，RTC应答器可验证关于时间间隔T的人工预计算响应是在T或其它与T有关的适当时间开始之前接收的，验证所有接收的RTCA签名(还可能验证适当的RTCA证书)，验证RTC应答器是否已接收所有签名(如不少于预期数量的签名，不少于已经发出的证书的最后传输的签名)，验证RTC应答器是否已接收指示先前已被声明作废的证书的有效性的信息，验证RTCA证书本身是否已被废除(如因为安全泄密)等。如果检测到任何问题，则RTC应答器可通知RTCA或其它适当实体。
依赖方可向RTC应答器询问证书的有效性状态。在一些实施例中，请求是OCSP格式。当询问特定证书的有效性时，RTC应答器可从存储器取回RTCA产生的特定证书的人工预计算响应并将其返回给依赖方。在一些实施例中，RTC应答器还可转发签署人工预计算响应的RTCA证书。在一些实施例中，依赖方可发出信号表明其对接收RTCA证书不感兴趣(例如因为依赖方已经有拷贝)，或RTC应答器可知道或假定依赖方已经有证书的拷贝。依赖方可处理所接收的响应以确定感兴趣的证书的有效性状态。在一些实施例中，如果人工预计算的响应是OCSP格式，则依赖方可使用OCSP软件用于这样的处理。在一些实施例中，依赖方可验证适当的RTCA证书。在依从OCSP的情形下，依赖方可将RTCA证书作为OCSP应答器证书进行验证。在一些实施例中，RTCA证书可在句法上构造成OCSP应答器证书。
有各种可被执行的优化。例如，假设U是具有证书Cu的一方。作为与V方交易的一部分，U可发送Cu给V(除非V已有Cu)，并可能执行另外的任务(如展示与在Cu中证明属于U的公开验证密钥有关的数字签名，或通过解密由V使用在Cu中证明属于U的公开加密密钥加密的随机难题而被识别)。为使交易安全，V可确定Cu的当前有效性并向RTC应答器进行有效性查询。应答器可通过取回并返回关于Cu的最新RTCA签署的声明(人工预计算响应)而回答所述查询。然而，查询RTC应答器将第三方加入本来是两方的交易中，这增加了交易的时间和复杂性。
一种解决办法是使U方在每一时间间隔T开始时或至少在每一时间间隔T期间接收RTCA签署的声明Du(人工预计算的响应)，其表明Cu在整个T期间均是有效的。U可响应于对RTC应答器的请求接收Du(例如通过进行一般的依赖方请求)。或者，Du可被进栈给U及可能其它方，例如通过RTC应答器或RTCA在每次更新时和/或在自动基础上进行。在任何情况下，在间隔T期间与V交易时，除了交易必需的所有其它步骤或任务以外，U可转发Du给V。因此，U-V之间的交易可得以很大程度地加快，因为V不需要访问任何第三方(如RTC应答器)来确定U的证书的当前有效性。
应注意，即使包括U获取Du的总体时间不被加快，U-V之间的交易也被加快。然而，还应注意，仅加快U-V之间的交易而没有节约总体时间依然是有用且有效率的。例如，如果假定RTCA声明(人工预计算的响应)在午夜进行计算并指定一整天为时间间隔，则U可在大清早(此时交易相当少)获得Du并继而在时间敏感的U-V交易执行期间将Du转发给V，而此时交易相当多，因而节约时间是有用的。还应注意，在获得并缓存Du之后，通过使U在全天与其它方交易时转发Du也可获得另外的效率。这样，例如，单一依赖方查询(U自身的查询，可能在相对不忙的时间做出)可成功地代替大量依赖方请求(可能在更忙的时间)。
上述优化还可由V方完成。在从RTC应答器获得针对关于U方的证书Cu的有效性查询返回的Du之后，V方可将Du给予U，或使Du可为其它方使用。
应注意，在此讨论的优化应用于在此描述的系统的依从OCSP的实施例。应注意，还可能将类似的优化应用于传统的OCSP实施。对于这样的实施，用户请求并获得关于其自己的证书的OCSP响应，之后，将该OCSP响应作为其交易的一部分以适当时间间隔转发给交易的其它方。或者，当依赖方第一次询问U方的证书Cu的有效性时，OCSP应答器可计算响应Ru，将Ru返回给发出查询的依赖方，且还将Ru转发给U，使得U可缓存Ru，至少暂时缓存(直到下一次更新为止)，并可将Ru作为基于Cu的交易的一部分进行转发。
在一些实施例中，在此描述的系统可使用在各个证书中发现的数据进行实施，从而节约另外的证书和/或响应长度。如上所述，CA可发出RTCA证书，其授权特定RTCA提供关于CA发出的证书有效性的权威答案。这样的RTCA证书可指定公钥用于验证RTCA签署的响应(人工预计算的响应)。然而，在一些实施例中，CA可将RTCA公钥嵌入在CA发出的证书内或该信息可被嵌入在CA证书自身内。即，CA(具有适当的格式，OID等)可在证书Cu中包括公钥PK，其可用于验证数字签署的关于Cu的有效性的响应。对于这些实施例，依赖方不必接收单独的RTCA证书。当向RTC应答器询问Cu的有效性的最新证明时，依赖方仅可获得(如因为其那样询问)RTCA签署的响应(人工预计算的响应)。实际上，Cu可指定依赖方可用以验证Cu的有效性证明的公开验证密钥。在其它实施例中，整个RTCA证书(或指向其的指针)可被嵌入在用户证书和/或CA证书中。这些实施例可产生相当的传输节约(因为RTC应答器不必发送单独的RTCA证书，其可能比RTCA响应长很多)及存储器节约(因为依赖方不必将RTCA证书与RTCA响应保存在一起)。
类似地，证书Cu可指定时间间隔。对于这些实施例，RTCA响应不必指定时间间隔T的开始和结束。在一些实施例中，单独T的开始(或其它更简单的规约)可适当地指定T。例如，如果Cu指定每日更新，则特定天内的任何时间均足以指定响应所涉及的全天。或者，如果已了解(如从CA的总体政策)证书具有由全天组成的有效性间隔，则没必要将这样的信息在证书内指出，因而节约了RTCA响应。
应注意，在特定证书C的有效性或延缓决定的RTCA证明可指定证明涉及的时间间隔的同时，作废证明不必指定任何时间间隔。而是，对于这样的证明，指定单一时间点(如废除时间)通常就足够了，因为不像有效性和延缓决定，废除通常是不可撤回的过程。因此，仅废除时间rt即可足以证明证书已作废。应注意，rt不必须是任何时间间隔T的开始，而是可指任何时间。因此，在证书C永久作废的情况下，RTCA不必在所有更新日期(如D1、D2等)发送C的作废证明。而是，作废证明可被仅发送一次(或为了冗余发送几次)并由RTC应答器缓存以在依赖方进行关于C的查询时返回给依赖方。
还应注意，RTCA可被立即通知证书C已被废除。例如，C己被废除的信息可在时间间隔T的中间转发，其时RTCA已经产生并转发C的有效性证明给RTC应答器。在这种情况下，到下一更新之前，将不为C计算有效性证明。然而，到那时(即直到T结束)，不正确的、但表面上有效的、C的有效性证明由RTC应答器保存。可能的对策包括使作废证明优先于有效性证明。在这种情况下，既看见C在某一时间间隔T的有效性证明又看见C的作废证明(在任何时间t)的诚实依赖方应将C视作已废除(在时间t之后)。
在某些情形下，某些依赖方永远不会看见作废证明，因而即使C已被废除，C可被这些依赖方视为仍然有效，直到T结束为止。只要RTCA获知C已被废除(如直接从CA那知道，不用等待下一次CRL更新)，这样的问题可通过使RTCA计算C的废除证明并发送给所有RTC应答器而得以减轻(独立于预定的日期D1、D2等或D1’、D2’等)。之后，所有适当运行的RTC应答器可从存储器删除C的任何有效性证明并用新接收的废除证明替代。在这种情况下，RTC应答器更可能向依赖方提供关于C的有效性的准确证明。
参考图3，示意图80示出了实施在此描述的系统的体系结构。CA82连到RTCA84并向其提供确认信息(如CRL)。RTCA84连到多个RTC应答器86-88，RTC应答器从RTCA接收人工预计算的响应。如本说明书别处所述，CA82和RTCA84中的每一个均使用秘密签署的密钥。在一些实施例中，CA82和RTCA84可以是同一实体，如框85所示。
RTCA84提供人工预计算的响应给RTC应答器86-88。如本说明书别处所述，RTC应答器不需要它们自己的秘密签署的密钥且不需要被保护，因为由RTC应答器86-88之一提供给依赖方的任何信息均已由RTCA84数字签署并是公开信息。
在其它实施例中，可使用一个以上RTCA，其由RTCA92和RTCA94示出，它们代表多个另外的RTCA。每一另外的RTCA92、94可连到由RTCA84服务的应答器86-88。或者，另外的RTCA92、94中的一个或多个可连到另外的、不同的多个应答器96-98。
参考图4，流程图100示出了在初始化RTCA时CA所执行的步骤。流程图100的步骤可在新的RTCA被添加到系统时或在先前的RTCA被发给新证书时执行，或因为旧RTCA证书已期满或因为RTCA的密钥已被泄密。
处理开始于第一步骤102，CA验证RTCA。在步骤102验证RTCA取决于系统的拓扑学和安全性要求，并可能要求管理员在物理上检查RTCA并验证RTCA在适当的位置且是安全的。当然，在步骤102也可执行其它适当的处理以验证RTCA是安全的。在步骤102之后是步骤104，CA为RTCA产生密钥。在步骤104，CA既为RTCA产生秘密密钥，也为RTCA产生公钥。
在步骤104之后是步骤106，CA基于在步骤104产生的密钥为RTCA产生证书。在步骤106产生的证书是RTCA证书。在步骤106之后是步骤108，秘密密钥被提供给RTCA。在一些实施例中，为安全目的，使秘密密钥以离线方式(如用户将秘密密钥写在一张纸上，之后在RTCA处输入该秘密密钥)提供给RTCA是有用的。
在步骤108之后是步骤112，在步骤106产生的证书被提供给RTCA。在步骤112，可能以在线(甚至不安全的)方式将证书提供给RTCA，因为RTCA证书将被公开，实际上，没有CA的秘密密钥(通常不同于在步骤104产生的秘密密钥)的知识，其将不能被纂改。在步骤112之后是步骤114，关于由CA管理的证书的初始证书数据从CA提供给RTCA。在步骤114提供的初始数据可包括初始CRL。此外，如本说明书别处所述，在步骤114提供的初始数据还可包括关于有效、未过期证书的信息，从而RTCA可为有效未过期的证书提供适当的响应。在步骤114之后，处理结束。
在一些实施例中，步骤104由RTCA执行，使得RTCA是具有秘密密钥的知识的唯一实体。在这种情况下，RTCA将相应的公钥呈现给CA(或在线或离线方式)，使得CA可在步骤106产生证书。当然，在这样的情况下，不必执行如上所述的步骤108。这可由流程图100中示出的从步骤106到步骤112的另一流程116说明。
应注意，流程图100的步骤甚至可在CA和RTCA为同一实体的情况下执行。当然，在这样的情况下，在步骤102验证RTCA是没有价值的。此外，对于RTCA/CA将使用同一公钥和秘密密钥对用于CA运行和RTCA运行的实施例，步骤104、106、108和112不需要被执行，因为RTCA证书将简单地是CA的证书。然而，在使RTCA证书格式不同于CA证书格式(如OCSP应答器证书格式)有用的情况下，步骤106可在为RTCA证书产生不同格式的证书时执行。
参考图5，流程图120示出了在定期将证书有效性数据从CA传送给RTCA时执行的步骤。流程图120的步骤或可定期执行，或可基于RTCA的专用请求执行。处理开始于第一测试步骤122，确定最近是否有任何证书已被废除(即自上一次迭代以来)。如果是，则控制从测试步骤122转到步骤124，作废信息被发送给应答器。如本说明书别处所述，在一些实施例中，作废信息被立即(尽可能接近立即)从CA发送给RTCA。在一些实施例中，在步骤124从CA发送给RTCA的作废信息被数字签署或被鉴定。
在步骤124之后或测试步骤122之后(如果最近没有证书被废除)是测试步骤126，确定当前时间是否对应于用于更新证书信息的新的时间间隔。如本说明书别处所述，在一些实施例中，CA以周期性的间隔将新的确认信息进栈到RTCA。因此，如果在测试步骤126确定当前时间不对应于新间隔，则控制从测试步骤126转回到前述的步骤122。否则，如果当前时间对应于新间隔，则控制从测试步骤126转到步骤128，新的确认信息由CA产生，在一些实施例中，其包括数字签署或鉴定该信息。如本说明书别处所述，新的确认信息可以是多种形式中的任何一种，包括CRL。
在步骤128之后是步骤132，在步骤128产生的新确认信息被提供给RTCA。在步骤132之后是测试步骤134，其确定RTCA是否已确认接收在步骤132发送的信息。如果否，则控制从步骤134转到步骤136，执行错误处理。在步骤136执行的错误处理可包括通知系统管理员。应注意，在步骤134确定RTCA是否已接收新信息是有用的，因为怀恶意的攻击者可能使RTCA停用，以作为防止关于最近废除的证书的信息被传播的手段。在步骤136之后，处理结束。
如果在测试步骤134确定RTCA已确认接收在步骤132发送的信息，则控制从步骤134转回到步骤122以处理下一迭代。在一些实施例中，数据被定期从CA提供给RTCA，而不管RTCA是否确认数据的接收。这由另一路径137图示。
在一些实施例中，流程图120的步骤不定期执行，而是仅响应于RTCA请求数据的特定请求执行。这由另外的路径138图示，其使得控制从步骤122或步骤124直接转到步骤128。还应注意，另外的路径142对应于在步骤134的确认的接收。因此，在流程图120的步骤不定期执行的实施例中，当在测试步骤134确定RTCA已确认接收在步骤132发送的信息，则路径142指示处理结束。当然，还可能有RTCA不确认接收来自CA的信息的实施例。这由另一路径144图示。
参考图6，流程图150示出了在数据被定期从RTCA进栈到RTC应答器的实施例中，由RTCA所执行的处理。处理开始于第一步骤152，RTCA确定自先前进栈以来是否已接收新数据。如果否，则控制转回到步骤152以继续循环和轮询，直到新的数据被接收为止。一旦在测试步骤152确定新的数据已被接收，则控制从步骤152转到步骤154，数据被从RTCA传到RTC应答器。在步骤154之后，控制转回到步骤152以继续轮询等待新数据。
参考图7，流程图160示出了在响应于RTC应答器的请求而将数据从RTCA提供给RTC应答器的实施例中RTCA执行的步骤。如本说明书别处所述，RTC应答器自身可定期从RTCA请求数据，而不是依赖于使数据被定期从RTCA自动进栈到RTC应答器。
处理开始于第一步骤162，RTCA从RTC应答器接收查询(请求数据)。在步骤162之后是测试步骤164，其确定RTC应答器是否请求RTCA证书。如本说明书别处所述，RTCA证书用于说明CA信任并授权RTCA提供确认信息。在一些实施例中，每一RTC应答器可缓存RTCA证书(将被提供，如果被请求和/或依赖方需要的话)，在这种情况下，只需请求RTCA证书一次。在其它实施例中，RTC应答器可定期请求RTCA证书，或者在某些情况下，一直请求RTCA证书。
如果在测试步骤164确定RTC应答器已请求RTCA证书，则控制从测试步骤164转到步骤166，RTCA提供RTCA证书给RTC应答器。在步骤166之后或在测试步骤164之后(如果RTC应答器尚未请求RTCA证书)是测试步骤168，其确定其它信息(即人工预计算的响应)是否已被请求。如果否，则处理结束。否则，控制从测试步骤168转到测试步骤172，其确定另一信息是否可在RTCA获得。在某些情况下，由RTC应答器请求的另一信息不可在RTCA获得。例如，如果RTC应答器请求关于外来证书的信息，人工预计算的响应不可在RTCA获得。
如果在测试步骤172确定所请求的信息不可获得，则控制从测试步骤172转到步骤174，RTCA提供数据给RTC应答器，其指明所请求的信息不能得到。在步骤174之后，处理结束。如果在测试步骤172确定所请求的另一信息可得到，则控制从测试步骤172转到步骤176，所请求的信息由RTCA提供给RTC应答器。在步骤176之后，处理结束。
参考图8，流程图190示出了在从依赖方接收请求人工预计算响应(OCSP响应)的请求时RTC应答器所执行的步骤。处理开始于第一步骤192，接收请求。在步骤192之后是步骤194，RTC应答器获得适于该请求的RTCA数据。在步骤194获得RTCA数据将在本说明书别处详细描述。在步骤194之后是测试步骤196，确定是否可得到所请求的数据。如果否，则控制从测试步骤196转到步骤198，RTC应答器提供响应给依赖方，其指明不知道特定证书的状态。在步骤198之后，处理结束。
如果在测试步骤196确定最新的有效性数据可用于感兴趣的证书，则控制从测试步骤196转到步骤202，对数据执行检查。如本说明书别处所述，在步骤202执行的检查可包括下述任一或多个确定数据的当前性，确定RTCA证书尚未被纂改并依然有效，及任一或多个可对步骤194获得的数据执行的其它检查。
在步骤202之后是测试步骤204，其确定在步骤202执行检查的结果是否指示一切正常。如果否，则控制从步骤204转到步骤206，向依赖方提供表明有效性数据不能认可的指示。可在步骤206执行其它适当的处理，例如包括将错误通知给系统管理员。在步骤206之后，处理结束。
如果在测试步骤204确定有效性数据可以认可，则控制从测试步骤204转到测试步骤208，确定依赖方是否请求RTCA证书。如果否，则控制从测试步骤208转到步骤212，向依赖方提供有效性数据(人工预计算响应)。在步骤212之后，处理结束。否则，如果在测试步骤208确定RTCA证书连同有效性数据一起被请求，则控制从测试步骤208转到步骤214，有效性数据(人工预计算的响应)和RTCA证书被提供给依赖方。在步骤214之后，处理结束。
对于某些实施例，依赖方可执行其自己的有效性数据检查，在这种情况下，不必执行步骤202的检查或步骤204的相应测试。这可由从步骤196到步骤208的另一流程路径216图示说明。
参考图9，流程图230更详细地示出了在图8的流程图190的步骤194获取RTCA数据时由RTC应答器执行的步骤。流程图230对应于RTCA数据由RTCA自动进栈到RTC应答器的实施例，RTC应答器不必明确请求数据。对于这些实施例，应答器总是自动拥有最新(或接近于最新)的RTCA数据。
处理开始于第一测试步骤232，RTC应答器确定所请求的数据是否可在RTC应答器得到。如果是，则控制从测试步骤232转到测试步骤234，其确定在RTC应答器的所请求的数据是否是最新数据。如本说明书别处所述，人工预计算的响应可包括人工预计算响应在其期间均有效的时间间隔，在该时间间隔之后，需要获取新的人工预计算响应。不管用于确定人工预计算响应的时间间隔的特殊机制，在测试步骤234确定由依赖方请求的特殊的人工预计算响应是否是最新的，其通过比较当前时间和与人工预计算响应相关联的时间间隔而进行确定。
如果数据是最新的，则控制从测试步骤234转到步骤236，其确定RTCA证书是否有效。在某些情况下，RTCA证书将被废除(或将要期满)也是可能的，从而RTCA提供的数据可能不可靠。例如，如果RTCA的秘密密钥已泄密，则RTCA证书可变为已作废。在步骤236确定RTCA证书的有效性可使用多种已知技术中的任一一种执行，包括在此描述的技术。如果在测试步骤236确定RTCA证书有效，则控制从测试步骤转到步骤238，提供所请求的人工预计算响应以用于进一步处理，如结合图8的流程图190所述的。在步骤238之后，处理结束。
如果在测试步骤232确定不能得到数据，或如果在测试步骤234确定所请求的数据不是最新的，或如果在测试步骤236确定RTCA证书不是有效的，则控制转到步骤242，其表明在图8的流程图190的步骤处理之后不能得到数据。在一些实施例中，在步骤242提供的信息可包括不能得到所请求信息的原因。在步骤242之后，处理结束。
在一些实施例中，可能不希望在每一迭代时均检查RTCA证书的有效性。对于这些实施例，步骤236可被省略，这由另一路径244图示说明。
还应注意，还可能使用流程图230所示的处理，其用于RTC应答器定期从RTCA请求新数据的实施例。在这样的情况下，数据可能不可得到或不是最新的，因为其尚未由RTC应答器从RTCA请求。
参考图10，流程图260更详细地示出了在图8的流程图190的步骤194获取RTCA数据时所执行的步骤，其用于RTC应答器从RTCA请求数据的实施例。处理开始于第一步骤262，确定依赖方是否已请求RTCA证书。如果是，则控制从步骤262转到步骤264，确定RTCA证书是否被RTC应答器缓存。如果否，则控制从测试步骤264转到步骤266，RTC应答器从RTCA请求RTCA证书。
在步骤266之后、或在步骤262之后(如果RTCA证书未被请求)、或在步骤264之后(如果所请求的证书不能得到)是测试步骤268，确定人工预计算响应是否已被请求。如果是，则控制从测试步骤268转到测试步骤272，确定所请求的人工预计算响应是否被缓存(当然是最新的)在RTC应答器。如果否，则控制从测试步骤272转到测试步骤274，RTC应答器从RTCA请求人工预计算响应。在步骤274之后、或在步骤268之后(如果没有人工预计算响应被请求)、或在步骤272之后(如果所请求的人工预计算响应被缓存)是步骤276，获取所请求信息的结果被提供以继续图8的流程图190的步骤的处理。在步骤276之后，处理结束。
参考图11，流程图300示出了在建立双方交易以避免第三方交易的额外步骤和处理的实施例中，由用户或用户与其交易的依赖方执行的步骤。处理开始于第一测试步骤302，确定用户和/或依赖方已缓存的信息(人工预计算响应)是否是最新的(或根本存在于本地)。如果是，则控制转回到测试步骤302以继续轮询直到信息不是最新时为止。一旦在测试步骤302确定缓存的信息不是最新的，则控制从测试步骤302转到步骤304，实体(用户和/或依赖方)获取最新信息，如本说明书别处所述。在步骤304之后是步骤306，在步骤304获得的信息被本地保存(缓存)。在步骤306之后，控制转回到步骤302以继续轮询直到所缓存的信息不再是最新的时候为止。
参考图12，证书320被示作包括传统的证书信息322和RTCA证书信息324。证书320可以是用户证书或CA证书。如上所述，在一些实施例中，可能将RTCA证书324证明的公钥嵌入在证书中。当依赖方查看证书320(或用户证书或CA证书)时，不必单独获取RTCA证书。在其它实施例中，RTCA证书信息324包括整个RTCA证书或指向其的指针。
参考图13，示意图400示出了CA402、RTCA404、RTC应答器406、和依赖方408之间的信息流。如本说明书别处所述，CA402提供确认信息(如CRL)412给RTCA404。RTCA404产生多个人工预计算响应416，其被提供给RTC应答器406。在某些情况下，RTCA404还可提供RTCA证书414给RTC应答器406。然而，如本说明书别处所述，RTCA证书414可仅被提供一次或独立于RTCA404定期提供，RTCA404提供人工预计算响应416给RTC应答器406。
依赖方408产生依赖方408提供给RTC应答器406的OCSP请求418(或某些其它类型的请求有效性信息的请求)。RTC应答器406通过提供人工预计算的OCSP响应422而服务于OCSP请求418，所述响应是先前从RTCA404提供给RTC应答器406的人工预计算OCSP响应422之一。之后，依赖方可使用人工预计算响应422基于所涉及证书的有效性状态而采取适当的进一步行动。如本说明书别处所述，在一些情况下，RTC应答器406可提供RTCA证书414给依赖方408。
参考图14，示意图430示出了在两个另外的独立数字证书系统之间传送确认信息。示意图430示出了图13的示意图400的CA402、RTCA404、RTC应答器406、及依赖方408。示意图430还示出了由CA402提供给RTCA404的确认信息412，并示出了从RTCA404传给RTC应答器406的RTCA证书414和人工预计算响应416。
示意图430还示出了第二CA432、第二RTCA434、第二RTC应答器436、及第二依赖方438。第二CA432提供确认信息442给第二RTCA434。第二RTCA434提供人工预计算响应446给第二RTC应答器436。然而，假定CA402和第二CA432管理独立的数字证书集，则CRL412包含关于不同于CRL442的证书的信息，且人工预计算响应416包含不同于人工预计算响应446的证书的信息。因此，当第二依赖方438提供OCSP请求448给关于CA402管理的证书的第二应答器436时，由第二RTCA434提供的人工预计算响应446中没有响应可适于满足OCSP请求448。
如果RTCA404已提供人工预计算响应416给第二RTC应答器436且如果RTCA404先前已提供RTCA证书414给第二RTC应答器436，则上述困难可得以解决，第二RTC应答器436可通过将RTCA证书414及RTCA404产生的人工预计算响应422提供给第二依赖方438而满足OCSP请求。应注意，如本说明书别处所述，从RTCA404到第二RTC应答器436的传输不必须是安全的，因为在传输给第二应答器436之前，RTCA证书414和人工预计算响应436已被数字签署。
参考图15，示意图460示出了产生图14的示意图430所示的系统。在示意图460中，RTCA404提供人工预计算响应416给RTC应答器的异类云462。类似地，第二RTCA434提供人工预计算响应446给RTC应答器的异类云462。RTCA404、434还可将其各自的RTCA证书(未示出)提供给RTC应答器的异类云462。应注意，任何数量的RTCA均可将人工预计算响应和/或RTCA证书提供给RTC应答器的异类云462。因此，依赖方408、第二依赖方438、或某些其它依赖方可接收人工预计算响应中的适当响应，可选地，还可响应于OCSP请求(或某些其它类型的请求)接收RTCA证书，所述请求是对于其人工预计算响应被提供给异类云462的任何证书的请求。
在于此描述的技术解决了传统OCSP的许多缺陷的同时，如成本高昂的计算、高通信量及花费高昂的安全服务器复制，另外的优化甚至可减少更多的计算和通信成本。具体地，在RTCA和RTC应答器之间的通信量可通过适当的压缩而减少，如下所述。因下述技术的组合所得的节约非常明显，特别是使用标准OCSP语法时更是如此。
如上所述，RTCA发送人工预计算响应给每一RTC应答器，每一人工预计算响应可由多个数据元组成，如响应类型、计算响应的时间、数字签名算法标识符、RTCA的id、证书号、证书是有效还是无效、及数字签名本身。这些项目中的许多项目是相同的、或类似的、跨多个响应。例如，对于所有响应，计算响应的时间及RTCA的id均是相同的。当所有响应被共同从RTCA发送给RTC应答器时，共同的数据元可仅被传输一次。当回答依赖方请求时，RTC应答器还可重新构造适当的响应。此外，当数据项目类似但不相同时，可使用适当的压缩算法以利用类似处并仅传送相差的地方。
此外，为进一步降低计算响应并传送给应答器的成本，基于部分而不是所有证书的有效性状态更新应答器是有利的。例如，所有证书的有效性状态可能按小时更新，而部分高优先性(如高安全性)证书可能使其状态每分钟更新。或者(或此外)，新近作废的证书可使其有效性状态被立即向应答器更新以降低不适当使用的风险。或者，RTCA可向应答器提供其状态已改变的证书的每一分钟的更新，同时还提供每日(或每小时)签署的所有证书的有效性状态信息。
可使用标准普通压缩技术(如Lempel-Ziv)进一步降低通信成本。压缩技术可在上述优化已经降低通信量之后应用。
上述优化降低了RTCA上的计算负载及RTCA和应答器之间的通信成本，因为，在许多情况下，只需计算更少量的签名。实际上，通过减少计算和通信引起的等待时间，该方法增大了安全性如果RTCA不得不一直处理和发送所有数字证书的有效性状态，应答器具有较其应有的更多的当前信息。
参考图16，流程图470示出了压缩RTCA和RTC应答器之间通信的数据的步骤。处理开始于第一步骤472，移除计划外的项目，不进行传输。如上所述，可能的优化之一是以不同的频率更新关于证书的信息，越重要的证书，更新越频繁。因此，在每一更新周期，关于较不重要的、计划外的证书的信息被从将从RTCA发送给RTC应答器的信息中删除。
在步骤472之后是步骤474，从剩余的数据中删除多余的项目。如上所述，多余的项目包括对正被传输的信息均一样的项目。例如，对从RTCA传给RTC应答器的所有信息，RTCA的身份和更新时间均是一样的。在步骤474之后是步骤476，对剩下的信息应用压缩算法。各种可能的压缩算法如上所述。在步骤476之后，处理结束。
证明证书的有效性在证明一个声称的身份时是有价值的。然而，在某些情况下，证明一个声称的身份通常与访问特定的物理位置、逻辑实体或服务的特权相关联。身份和特权的关联可以是不言明的，并可不适应控制同一用户的多个独立特权的需要。不同的方法将采用每一独立特权的分开的特权状态。RTCA可被扩展以除提供证书状态以外还提供多个特权的特权状态。
特权可由一个或多个授权机构授予。这可以是暗含的过程，其中授权机构和CA为同一实体。在这样的情形下，证明其身份的用户可建立访问特定位置、逻辑实体或服务的用户权限。然而，该方法的缺陷在于特权状态可能与证书或身份有效性状态是一样的，因而对所有暗指的特权均导致单纯的是/否回答。如下所述，这可通过扩展RTCA以为各个用户提供个别的、独立的特权状态而得以解决。
在开始，CA证明RTCA为特权管理机构。例如，这可作为在本说明书别处描述的一般CA证明过程的一部分执行。CA可数字签署证书，其指明CA信任并授权RTCA除证书有效性状态以外还提供多个独立的特权状态。授权或可以是暗含的，或在RTCA证书中明确指出。
在证明之后，授权机构可将各个特权状态的当前状态通知给RTCA。授权机构可保持将特权的有效性状态通知给RTCA，所述特权被授予授权机构可对其控制的每一用户。例如，授权机构可(1)只要发生变化，以在线方式将任何特权状态变化通知给RTCA，或(2)将指示变化的数字签署的消息发送给RTCA。
确定实体为有授权的授权机构可通过使用由适当信任和授权的CA发出的数字签署的证书进行。由每一授权机构控制的特权可在证书自身内(即由CA)或在位于RTCA的数据库中或通过一些其它适当的手段与机构绑定。
当RTCA产生单独签署的证书有效性状态消息时，RTCA可包括与特定证书相关联的每一特权的状态。作为提供证书的有效性状态的过程的一部分，RTCA可包括与所涉及证书相关联的每一特权的标识符和当前状态。与特权状态相关联的时间间隔可与应用到证书有效性状态的一样。在这方面，预计算各个特权状态可与如上所述的用于证书状态确认的技术一样并同时发生。特权状态可被包括在与证书状态确认一样的数字签署的消息中。
RTCA可将预计算的特权有效性状态发送给未保护的RTC应答器。分布各个特权状态的过程可与用于如上所述的证书状态确认的一样并同时发生。之后，应答器可保存RTCA预计算的特权状态。在特权状态确认信息被包括为证书状态确认信息的一部分时，特权状态信息可由如上所述的应答器保存为单一响应和/或可与证书确认信息一起保存。
如上所述，当依赖方向应答器询问证书的有效性状态信息时，RTC应答器可提供RTCA预计算的响应，其包括证书有效性状态及所有相关的特权状态。之后，依赖方可验证预计算的响应(及，如果合适，还验证RTCA证书)。依赖方对所接收响应的处理与上述类似，除了现在任何相关的特权状态也可得到以外。特权状态可被读取和使用以确定是否授权所请求的访问。扩展到提供多个清楚的特权状态的RTC系统可类似于在本说明书别处描述的用于提供证书状态的系统，除了预计算的OCSP响应现在可被知道包含特权有效性状态及证书有效性状态信息以外。
参考图17，示意图480示出了授权机构的实施。示意图480示出了连到RTCA484的CA482。如本说明书别处所述，CA482提供信息给RTCA484。RTCA484连到多个RTC应答器486-488以向其提供信息，如本说明书别处所述。
示意图480还示出了提供授权信息给RTCA484的授权机构492。可选地，CA482可以直接连到授权机构492以提供初始授权信息、授权机构证书、及任何其它适当的信息。如本说明书别处所述，CA482和授权机构492可以是同一实体，其由在CA482和授权机构492周围的框496图示。尽管未在示意图480中示出，在此与授权机构492一起描述的系统可包括另外的RTCA、应答器等，如本说明书别处所述(例如，参见图3及相应的描述)。
应注意，在一些实施例中，CA482可将授权机构证书直接提供给RTCA484，而不用从CA482提供证书给授权机构492。还应注意，授权机构证书(或其它授权证据)可在由CA482发出的证书中提供(类似于上面图12中所示的那样)或由CA482提供给RTCA484的其它信息提供。
在RTC系统解决了许多OCSP缺陷的同时，进一步的优化也是可能的。具体地，RTCA的计算成本可通过一次处理多个数字签名而得以降低。对于上述系统，RTCA签署每一数字证书的状态。即使这被提前完成，甚至可能在做出状态查询之前，也可能希望降低该过程的计算成本，特别是因为数字签名的产生是计算集中的运算。
如下面将详述的，通过使签名有效RTCA(SERTCA)将多个证书的状态结合在单一声明中并继而签署并注明该声明的日期而提供改进，从而使用单一签名即可鉴定多个证书在特定时间点的状态。其状态被那样鉴定的证书的数量可以是固定的(每一声明总是包含同样数量证书的状态信息)，也可以是变化的。在单一声明中确定的证书也可在其它声明中确定。例如，一声明可代表属于特定个体的所有证书的有效性状态，另一声明可代表具有某一整数间隔内的序号的所有证书的有效性。同一证书可能属于两个集合，因而属于两个单独的鉴定声明。
在鉴定特定时间间隔的所有声明之后，SERTCA可发送声明给一个或多个RTC应答器，其保存声明以服务于依赖方的查询。当接收关于证书X的查询时，RTC应答器可取回包含X的有效性状态的SERTCA签署的声明并将该声明返回给依赖方。依赖方可验证SERTCA签名并在声明中搜索关于X的信息，因而以经鉴定的方式获知X的状态。
当然，SERTCA还可发出关于单一证书的状态的声明，因此，如果SERTCA发出仅关于单一证书的声明，则SERTCA可提供与RTCA一样的信息。特定的SERTCA可某些时候可用作RTCA并在其它时候不用作RTCA(例如，根据特定时间的计算限制和需要)。系统可结合RTCA和SERTCA。
在开始，CA以类似于上面证明RTCA的方式证明SERTCA，如上所述。正象RTCA那样，SERTCA是可以也可不与特定机构的CA一致的实体。每一CA提供其自己的一个或多个SERTCA，其中每一SERTCA具有特殊证书，即SERTCA证书。CA可数字签署SERTCA证书，以表明CA信任并授权SERTCA提供关于CA的证书的有效性信息。这样的证书将SERTCA状态传给特定实体(如由特定标识符、OID号等确定的实体)，并可将特定验证密钥PK(特定实体拥有其相应的秘密签署的密钥)与特定实体绑定。
正象RTCA那样，即使CA和SERTCA一致，CA和SERTCA具有不同的签署密钥也是有利的。因此，无论CA和SERTCA是否代表同一实体，CA发出证书及SERTCA管理证书(如证明证书有效/已作废/延缓决定)。这样，即使CA和SERTCA一致，也可能依然使用单独的SERTCA证书。在一些实施例中，每一CA仅具有一个SERTCA，尽管因为冗余或其它目的，具有一个以上是有利的，无论是否使用同一签署密钥。如果有多个SERTCA，则其中部分可简单地用作RTCA。
应注意，正象RTCA那样，SERTCA保护其签署密钥。例如借助于保险库、安全设施、或安全硬件。CA保持将其证书的有效性状态通知给SERTCA。例如，CA可(1)只要发生变化，以在线方式将证书有效性的任何变化通知给SERTCA，或者(2)当产生时将其CRL发送给SERTCA。在一连串日期D1、D2、…的任一日期Di，SERTCA基于其当前的确认状态知识(如基于CA的最新CRL)并独立于任何依赖方请求而执行更新，其通过处理CA的每一未完成(最好未过期)证书、将关于证书的有效性状态的信息结合成集、并为每一集合数字签署指明集合中每一证书的状态的声明(人工预计算响应)而实现。例如，这样的状态可以是有效、已作废、或延缓决定(或可能是“不知道”、或“未发出”或另外的状态指示)。签署的声明可指定时间间隔T。在一些实施例中，在每一更新时，每一签署的声明可指定相同的时间间隔T，且这些时间间隔的总数可覆盖整个“时间线”。例如，在每一更新日期Di，时间间隔T＝Di+1-Di-其中可能只有Di和Di+1之一是T的一部分，而另一日期是相邻时间间隔的一部分。
作为例子，声明例子可具有形式SIG-SERTCA(“X有效；Y已作废；Z延缓决定；日期Di；下一日期Di+1”)，其中X、Y和Z代表确定特定证书的信息(如序号)，及“有效”、“无效”、“已作废”是相应证书状态的指示符。如果SERTCA当前关于证书状态的知识是基于CA的CRL，则每一Di可与一CRL的日期一致，Di+1与下一CRL的日期一致。应意识到，这样严格的时间依存不是必需的。例如，在SERTCA处理或开始处理其声明的日期可以是D1、D2等，而在声明内指定的时间间隔可以是D1’、D2’等，其中Di和Di’可以不同。例如，Di可以早于Di’，在这种情况下，RTCA可在开始声明的时间间隔之前开始处理声明一例如，因为SERTCA希望在间隔T开始之前完成其处理。类似地，如果CRL在SERTCA更新时使用，声明时间和CRL时间也可不同。
因此，实际上，SERTCA预计算的数字签名指明所有证书在特定时间间隔T的状态。这样的预计算可独立于任何关于证书有效性的依赖方请求进行执行。SERTCA可在时间间隔中做出任何状态查询之前甚至在该时间间隔开始之前为该特定时间间隔预计算签署的声明。证书状态的SERTCA签署的声明(人工预计算响应)可以是标准OCSP格式，也可以是与现有依赖方软件兼容的格式。在OCSP软件已经在其位时，这对最小化或消除对现有依赖方软件的修改是有用的。例如，为确保依从OCSP的所有有关数量，可适当地选择数字签名算法、OID等。
然而，应注意，SERTCA的句法正确的OCSP响应不必须是传统的OCSP响应，因为SERTCA响应不响应于任何请求进行计算。实际上，SERTCA对尚未产生且可能永远不会产生的OCSP请求预计算OCSP依从的响应。SERTCA响应，无论是否是OCSP格式，均是人工预计算的响应。
在预计算响应之后，SERTCA可使响应可用于其它方。尽管SERTCA可响应于有效性状态查询将响应返回给依赖方，在其它实施例中，SERTCA可提供预计算的响应给RTC应答器，其与上述连同RTCA使用的RTC应答器相似。
SERTCA可通过以适当组织的方式将签名呈现给RTC应答器而帮助RTC应答器处理签名。为确保所有有关的预计算响应均已接收，在每一次更新时，SERTCA可向RTC应答器提供另外的签名，其通过签署并注明RTC应答器接收的人工预计算响应的总体的日期而进行。此外，SERTCA可发送SERTCA证书给RTC应答器。该传送不必在每次更新时都发生，其可仅在开始时或定期执行。
RTC应答器可将所接收的SERTCA的人工预计算响应保存足够长的时间。在一些实施例中，如果签名涉及特定时间间隔T，则RTC应答器可将人工预计算响应至少保存到T结束为止。在一些实施例中，RTC应答器(特别是那些与SERTCA属于同一组织的应答器)可检查以具有正确信息。例如，RTC应答器可验证在T开始之前(或其它与T有关的适当时间)接收的关于时间间隔T的人工预计算响应，验证所有所接收的SERTCA签名(可能及适当的SERTCA证书)，验证RTC应答器是否已接收关于所有证书的信息(如不少于预期数量的证书，不少于上一传输已经发出的证书)，验证RTC应答器是否已接收先前被声明作废的证书的有效性的DERTCA签署的声明等。如果检测到任何问题，RTC应答器通知SERTCA或另一适当的实体。
依赖方可向RTC应答器询问证书的有效性状态。在一些实施例中，依赖方使用OCSP格式用于请求。如果同一证书状态上的信息出现在一个以上声明中，依赖方可向RTC应答器指明哪一声明是依赖方的首选。例如，如果SERTCA提供代表属于特定个体的所有证书的有效性状态的声明，并提供代表具有某一整数间隔内的序号的所有证书的有效性状态的声明，且依赖方主要对属于个体I的具有序号X的证书的有效性状态感兴趣，则依赖方可提供指示优先选择的指示符以接收(a)SERTCA签署的声明，其包括关于序号接近于X的证书的信息，或(b)SERTCA签署的声明，其包括关于I的其它证书的信息，或(c)非常短的SERTCA签署的声明，或(d)包括关于X的状态的信息的SERTCA签署的声明(即没有优先选择)。根据情况选择其中之一是有优点的。
当询问特定证书的有效性时，RTC应答器可从存储器取回SERTCA人工预计算响应，其包括该证书的信息。RTC应答器可返回人工预计算响应。RTC应答器还可为SERTCA转发已签署人工预计算响应的适当证书。应注意，依赖方可提供指示以接收SERTCA证书，或RTC应答器可能知道或假定依赖方已经有SERTCA证书的拷贝。如果有多个预计算的答案包含关于同一证书的信息，RTC应答器可根据依赖方的偏爱或某些指定算法或根据一些其它规则选择返回哪一答案。
依赖方处理所接收的响应以确定感兴趣证书的有效性。在一些实施例中，如果响应是OCSP格式，RTC应答器使用OCSP软件用于这样的处理。RTC应答器可验证适当的SERTCA证书。在OCSP依从的实施例中，RTC应答器可将SERTCA证书验证为OCSP应答器证书。在一些实施例中，SERTCA证书可在句法上构造成OCSP应答器证书。
参考图18，示意图500示出了在CA502、SERTCA504、RTC应答器506和依赖方508之间的数据流。CA502提供确认信息(如CRL)给SERTCA504。SERTCA504使用确认信息产生多个多证书人工预计算响应516。SERTCA504还有其自己的证书514，其可由CA502提供给SERTCA504。
依赖方508产生依赖方508提供给RTC应答器506的OCSP请求518。响应于此，RTC应答器506提供多证书人工预计算响应522，其是最初由SERTCA504提供给应答器506的多证书人工预计算响应516之一。此外，如本说明书别处所述，在某些情况下，应答器506提供SERTCA证书514给依赖方508。
应注意，上述RTCA系统的处理同样可适于与SERTCA系统和/或混合系统一起使用，包括使用授权机构，如上所述，以及提供上面连同图16所述的压缩优化。类似地，上述SERTCA系统的处理同样适于与RTCA系统和/或混合系统一起使用。
另一技术，批处理OCSP可用于降低RTCA或SERTCA计算成本。批处理OCSP可单独使用，也可与在此描述的一个或多个其它机制结合使用。
当在响应中使用的特殊数字签名是RSA数字签名时可采用批处理OCSP。在SERTCA通过鉴定单一签名中的多个证书的状态而提高签名效率时，批处理OCSP可借助于单一计算产生多个单证书OCSP响应而提高效率，使每响应成本大大低于单一OCSP响应的成本。例如，如果10个单证书OCSP响应单独产生，成本大概是RTCA(或传统OCSP应答器)的10个RSA签名的成本。如上所述，SERTCA机制可将成本降低到一个RSA签名的成本，其通过将10个证书上的信息组合在单一声明中实现。然而，使用SERTCA的缺陷在于相应的声明变得更长。批处理OCSP可以低于10个RSA签名的成本的总成本(在一些情况下，大约为2个RSA签名的成本)产生10个不同的单证书，单独签署的OCSP响应。
如下所述，批处理OCSP基于Fiat的批处理RSA计算。RSA的公钥PK由两个整数组成，即(N，e)，其分别为公知的模数及验证指数。模数是两个大的秘密质数p和q的积，RSA的安全性依赖于从模数N发现其组成质数的难度。相应的秘密密钥SK由(N，d)组成，其中d具有下述特性对于所有小于N的正整数b，如果s等于b与以N为模的冥d自乘，则b等于s与以N为模的冥e自乘。换言之，将整数与以N为模的冥e自乘的运算和将整数与以N为模的冥d自乘的运算正好相反。
RSA数字签名的计算包括(可能随机地)格式化消息m的散列以获得b，继而通过使b与冥d自乘而获得签名的计算，之后得到以N为模的结果。相应的验证过程从s计算b，通过使s与以N为模的冥e自乘进行，并检查b实际上是否正确地从m产生。Fiat批处理RSA签名的评论如下所述。假如具有多个值b1、…、bi，多个验证指数e1、…、ei，及相应的签署指数d1、…、di。之后，通过使用号码理论算法(未在此描述，但在本领域是公知的)，s1对以N为模的冥d1、s2对以N为模的冥d2、…、si对以N为模的冥di的计算可比i个单独的个别计算更有效率地执行(假定e1、…、ei不同且满足某些其它条件)。
如上所述，SERTCA(及RTCA)具有由CA发出的数字证书，其证明SERTCA在预计算OCSP响应上签名使用的公钥，所述预计算OCSP响应指明数字证书的有效性信息。同样如上所述，SERTCA数字证书由将几个数如SN、对证书独一无二的序号、PK、SERTCA的公钥、标识符、发出日期、期满日期、及另外的数据安全绑定在一起的CA的数字签名组成。表示成符号C＝SIGCA(SERTCA，SN，PK，ID，D1，D2，...)。在RSA数字签名由SERTCA使用的情况下，SERTCA的公钥PK采用(n，e)的形式，其中n是模数，e是验证指数，且证书采取形式C＝SIGCA(SERTCA，SN，(n，e)，ID，D1，D2，…)RTC应答器和依赖方可以经鉴定的方式从SERTCA证书获知SERTCA公钥。然而，由于传统的证书仅包含单一指数e，传统的证书不适于与使用多个不同指数的批处理RSA一起使用。除非验证人(RTC应答器和/或依赖方)知道在鉴定数字证书的有效性信息的特定签名中使用的验证指数，验证人将不能验证签名。下面使用批处理OCSP内的批处理RSA克服了该问题。
在一方法中，SERTCA首先产生传统RSA签名中那样的模数n，并将n呈现给CA用于验证为SERTCA的公钥。SERTCA保护其秘密密钥，其由质数p和q组成。之后，CA向SERTCA发出用于仅由n组成的公钥的数字证书。例如，SERTCA证书可采取C＝SIGCA(SN，n，ID，D1，D2，...)的形式。之后，CA将SERTCA的用户证书的状态通知给SERTCA。接着，SERTCA产生i个签署指数d1、…、di及相应的验证指数e1、…、ei。独立于任何依赖方请求，SERTCA产生关于一个或多个证书在特定时间间隔的有效性状态的声明，并将这些声明结合为大小为i的一批，并在每一批内用指数d1、…di使用批处理RSA，为每一声明产生数字签名。接着，SERTCA将有效性状态的预计算签名发送给未保护的应答器，另外包括允许应答器和/或依赖方确定用于验证每一声明的指数ej的信息。之后，应答器保存SERTCA人工预计算的响应。
当依赖方向应答器询问有效性状态信息时，RTC应答器用人工预计算响应回答查询。每一响应包括验证响应需要的验证指数ej及SERTCA证书(如果需要)。之后，依赖方可使用具有从SERTCA证书获得的模数n和从RTC应答器获得的验证指数ej的RSA验证来验证人工预计算的响应。
对该方法变化也是可能的。例如，如果指数是任意的(且在发出RSA签名前没有使用特殊的消息格式)，已从SERTCA证书获知SERTCA模数n的敌人可寻找使敌人能够产生相对于n和e的假声明的RSA签名的指数e。为提高安全性，SERTCA指数e1、…、ei可被提前固定(并不必每次均可由应答器得到)。具体地，指数可被指定为由CA签署的SERTCA证书的一部分。接着，SERTCA证书可采取形式C＝SIGCA(SERTCA，SN，(n，e1，...，ei)，ID，D1，D2，...)依赖方还可从SERTCA证书或另一来源获得验证指数，而不是从应答器获得。
使应答器和/或依赖方能够推断哪一指数ej被用于特定声明而不是清楚地指明该信息是有利的。例如，如果在每一批中确认的第j证书总是具有适合以i为模的j的序号，则可进行这样的推断。接下来，应答器和/或依赖方能够简单地从其有效性正被验证的证书的序号推导指数的冥j。
应注意，在该方法中，依赖方验证实施可能不遵循标准RSA签名验证范例，因为SERTCA的公钥可不按对(n，e)呈现给依赖方。修改现有依赖方RSA实施的成本在某些应用中是不允许的。这可由下述另外的方法解决。
对于第二方法，SERTCA在开始产生与传统RSA签名中一样的模数n、及i个验证指数e1、…、ei，SERTCA将其呈现给CA用于证明。对于SERTCA，保护n的素数因素分解是有利的。之后，CA可发出i个用于公钥的数字证书，公钥由PK1＝(n，e1)、PK2＝(n，e2)、...PKi＝(n，ei)组成。例如，i个SERTCA证书可采取形式C1＝SIGCA(SERTCA，SN，(n，e1)，ID，D1，D2，…)、…、Ci＝SIGCA(SERTCA，SN，(n，ei)，ID，D1，D2，…)。之后，CA可将其用户证书的状态通知给SERTCA。在其之后，且独立于任何依赖方请求，SERTCA产生关于一个或多个证书在特定时间间隔的有效性状态的声明，并将这些声明结合为大小为i的一批，并在每一批内用指数d1、…di使用批处理RSA，为每一声明产生数字签名。接着，SERTCA将有效性状态的预计算签名发送给未保护的应答器，另外包括允许应答器和/或依赖方确定用于验证签署每一声明的指数ej的信息。应答器保存SERTCA预计算的响应。
当依赖方向应答器询问有效性状态信息时，RTC应答器用预计算响应回答查询。用指数ej签署的每一响应包括第j个SERTCA证书Cj(如果需要或被请求)。依赖方使用具有从SERTCA证书获得的公钥(n，ej)的RSA验证来验证预计算的答案。应注意，依赖方验证与标准RSA验证在句法上一样，因为标准形式的RSA公钥是从SERTCA证书获得。因此，对依赖方而言，不需修改标准RSA实施。实际上，依赖方可能完全不知道SERTCA正使用批处理OCSP。
对上述方法进行变化也是可能的。例如，不是选择指数e1、…、ej并呈现给CA-这样的指数可被CA提前推断或知道—例如，因为这些指数是系统的固定参数。或者，应答器和/或依赖方能够推断哪一指数ej被用于特定声明而不是清楚地指明该信息是有利的。例如，如果在每一批中确认的第j证书总是具有适合以i为模的j的序号，则可进行这样的推断。接下来，应答器和/或依赖方能够简单地从其有效性正被验证的证书的序号推导指数的冥j。
参考图19，流程图600示出了在初始化SERTCA(或适当的RTCA或OCSP应答器)以执行批处理OCSP时执行的步骤。处理开始于低于步骤602，CA证明模数n。在步骤602之后是步骤604，产生i个指数对(验证指数和签署指数)。在于此的实施例中，指数对由SERTCA使用一对秘密质数产生，秘密质数的积等于n。然而，对于其它实施例，使其它实体产生步骤604的指数对及使用其它算法产生这些对也是可能的。
对于某些实施例，处理可在步骤604之后结束。然而，其它实施例可包括由CA进行另外的证明，如上所述，包括使CA证明验证指数e1、e2、…、ei。在一实施例中，如步骤606所示，CA证明单一证明中的i个验证指数，如上所述。在另一实施例中，如步骤608所示，CA证明表示n、ek的RSA风格公钥的i个单独证书，其中ek是i个验证指数之一。
参考图20，流程图620示出了在产生人工预计算响应时SERTCA(或适当的RTCA或OCSP应答器)执行的步骤。处理开始于第一步骤622，CA提供确认信息给SERTCA，如本说明书别处所述。在步骤622之后是步骤624，SERTCA使用签署指数d1、d2、…、di产生人工预计算响应。在步骤624之后是步骤626，SERTCA以类似于本说明书别处所述的方式将人工预计算响应提供给RTC应答器。
在一些实施例中，SERTCA可提供另外的指数信息给RTC应答器。这由图20的流程图620中所示的可选步骤图示说明。另外的指数信息可由正使用的特定指数的一个或多个证明和/或指示哪些特定指数用于哪些人工预计算响应的信息组成。当然，如本说明书别处所述，也可有其它机制确定哪些指数用于哪些人工预计算响应，从而对于SERTCA，不必单独提供那样的信息。类似地，可以有用于将指数信息通信给RTC应答器(最终通信给依赖方)的机制，从而不必为指数单独提供任何另外的证明。
应注意，上述批处理OCSP技术可代替SERTCA与RTCA一起使用，也可与传统的OCSP框架一起使用，其中OCSP应答器基于从依赖方接收查询而计算数字签署的证书状态信息。具体地，如果OCSP应答器接收孤立的查询，则OCSP应答器可产生单个RSA签署的响应，但如果OCSP应答器在很短时间内接收许多查询，OCSP可以上述批处理的方式回答所有或部分查询。下面将对此进行阐述。
最初，CA将其用户证书的状态以与OCSP相容的方式通知给OCSP应答器。在接收多个证书状态查询的基础上，应答器可使用批处理RSA计算独立的单证书，对第i查询的传统OCSP响应，每一均与指数ej有关。OCSP应答器还可指定一致的指数和/或包括CA签署的应答器证书，其鉴定ej(及适当的RSA模数n)可用于验证应答器签名。CA可向OCSP应答器提供单一OCSP应答器证书，其指出只有RSA模数n由应答器用于其批处理RSA签名。例如，表示成符号C＝SIGCA(responder，SN，n，ID，D1，D2，...)应注意，如果OCSP应答器使用的指数是固定的，则这特别准确和安全。或者，CA可向OCSP应答器提供应答器证书，其指定应答器可用于批处理RSA签署的多个指数。例如，表示成符号C＝SIGCA(responder，SN，(n，e1，...ek)，ID，D1，D2，...)或者，对于特定OCSP应答器，CA可发出k个不同的应答器证书，每一证书对于应答器可用于批处理RSA签署的每一指数。例如，表示成符号C1＝SIGCA(responder，SN，(n，e1)，ID，D1，D2，...)、...、Ck＝SIGCA(responder，SN，(n，ek)，ID，D1，D2，...)在此的整个描述中，CA、RTCA、应答器、交易方、用户可以是任何实体(如个人、机构、服务器、设备、计算机程序、计算机文件)或实体的集合。证书应被理解为包括所有种类的证书，具体地，包括分级证书和平面证书。例如，参见美国专利5,420,927，其通过引用组合于此。有效性状态和有效性状态的证明可包括分级证书的有效性状态和有效性状态的证明(如一系列证书中所有证书的有效性状态和有效性状态的证明)。验证证书C的有效性可包括验证已发出C的CA的CA证书的有效性及提供关于C的有效性状态的签署响应的RTCA/SERTCA的RTCA/SERTCA证书的有效性。
在适当的情况下，数字签署和数字签名在此可被理解为包括任何适当的信息鉴定。
尽管证书描述将特定密钥与特定用户绑定的数字签署的文档，在美国专利5,666,416(通过引用组合于此)之后，证书还应被理解为包括所有类型的数字签署的文档。例如，充作CA的卖主可通过数字签署价格表(可能连同日期信息一起)而证明价格表在其控制之下。知道这样的证书的有效性状态是有用的。例如，卖主可能想证明价格表的当前有效性(并拒绝价格表中的特定价格，除非展示其当前有效性的证明)。因此，客户可能希望确定价格表文档的当前有效性。在此描述的系统可用于此。在此描述的系统可用于证明网页的当前有效性。在一些实施例中，RTCA/SERTCA产生的当前有效性的证明可与网页本身一起保存(或与其关联)。在这样的情况下，交易方可被视作计算机文件。
发送一块数据D(给交易方X)应被理解为包括使D可用(或使X接收D)。
应注意，在此描述的系统可使用硬件、软件或其某种结合进行实施，包括但不限于通用计算机编程，以与专用硬件如数字信号处理硬件结合而提供在此描述的功能。
当本发明已结合多个实施例进行公开的同时，对本领域技术人员而言其修改是非常显然的。因此，本发明的精神和范围由下述权利要求提出。
权利要求
1.提供关于数字证书有效性的信息的方法，包括获得多个签署密钥/验证密钥对，其中每一签署密钥提供数字签名及相应的验证密钥验证该数字签名，且其中使用签署密钥一起数字签署多个数据元相较个别地数字签署每一数据元在计算上效率更高；为一组数字证书中的每一证书确定数字证书有效性状态；产生关于数字证书集的至少一子集的有效性状态的多个人工预计算的消息；及使用来自密钥对的签署密钥一起数字签署人工预计算的消息。
2.根据权利要求1的方法，其中确定数字证书有效性状态包括获得关于数字证书的经鉴定的信息。
3.根据权利要求2的方法，其中关于数字证书的经鉴定的信息由同样废除证书的实体产生。
4.根据权利要求2的方法，其中关于数字证书的经鉴定的信息是CRL。
5.根据权利要求1的方法，其中人工预计算的响应是OCSP格式响应。
6.根据权利要求5的方法，其中产生多个人工预计算的响应包括为数字证书集中至少所有未作废的数字证书产生响应。
7.根据权利要求5的方法，还包括在数字签署人工预计算的消息之后，将其结果转发给服务于依赖方的请求的多个应答器，所述依赖方询问数字证书集中的数字证书的有效性状态。
8.根据权利要求1的方法，其中产生多个人工预计算的响应及数字签署人工预计算的响应被周期性地执行。
9.根据权利要求8的方法，其中人工预计算的响应包括对应于人工预计算的响应在何时产生的时间信息。
10.根据权利要求1的方法，还包括鉴定验证密钥。
11.根据权利要求10的方法，其中鉴定验证密钥包括在单一数字证书中提供验证。
12.根据权利要求10的方法，其中鉴定验证密钥包括在分开的数字证书中提供每一验证密钥。
13.保存在计算机可读介质上的计算机软件，其提供关于数字证书有效性的信息，包括获得多个签署密钥/验证密钥对的可执行代码，其中每一签署密钥提供数字签名及相应的验证密钥验证该数字签名，其中使用签署密钥一起数字签署多个数据元相较个别地数字签署每一数据元在计算上效率更高；为一组数字证书中的每一证书确定数字证书有效性状态的可执行代码；产生关于数字证书集的至少一子集的有效性状态的多个人工预计算消息的可执行代码；及使用来自密钥对的签署密钥一起数字签署人工预计算消息的可执行代码。
14.根据权利要求13的计算机软件，其中确定数字证书有效性状态的可执行代码包括获得关于数字证书的经鉴定的信息的可执行代码。
15.根据权利要求14的计算机软件，其中关于数字证书的经鉴定的信息由同样废除证书的实体产生。
16.根据权利要求14的计算机软件，其中关于数字证书的经鉴定的信息是CRL。
17.根据权利要求13的计算机软件，其中人工预计算的响应是OCSP格式响应。
18.根据权利要求17的计算机软件，其中产生多个人工预计算响应的可执行代码包括为数字证书集中至少所有未作废的数字证书产生响应的可执行代码。
19.根据权利要求12的计算机软件，还包括鉴定验证密钥的可执行代码。
20.根据权利要求19的计算机软件，其中鉴定验证密钥的可执行代码在单一数字证书中提供验证密钥。
21.根据权利要求19的计算机软件，其中鉴定验证密钥的可执行代码在分开的数字证书中提供每一验证密钥。
全文摘要
提供关于数字证书有效性的信息包括获得多个签署密钥/验证密钥对，其中每一签署密钥提供数字签名及相应的验证密钥验证该数字签名，且其中使用签署密钥一起数字签署多个数据元相较个别地数字签署每一数据元在计算上效率更高；为一组数字证书中的每一证书确定数字证书有效性状态；产生关于数字证书集的至少一子集的有效性状态的多个人工预计算的消息；及使用来自密钥对的签署密钥一起数字签署人工预计算的消息。确定数字证书有效性状态包括获得关于数字证书的经鉴定的信息。关于数字证书的经鉴定的信息由同样废除证书的实体产生。关于数字证书的经鉴定的信息是CRL。人工预计算的响应是OCSP格式响应。
文档编号H04L9/32GK1998181SQ200580002152
公开日2007年7月11日 申请日期2005年1月10日 优先权日2004年1月9日
发明者戴维·恩贝里, 菲尔·利宾, 西尔维奥·米卡利 申请人:科尔街有限公司