CN100581098C

CN100581098C - 创建拥有确认证明的方法和系统

Info

Publication number: CN100581098C
Application number: CN200510109426A
Authority: CN
Inventors: M·B·贝南塔; T·L·金丁; J·W·斯威尼
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2004-10-28
Filing date: 2005-10-18
Publication date: 2010-01-13
Anticipated expiration: 2025-10-18
Also published as: ATE380370T1; DE602005003631T2; US7543147B2; CN1767427A; TW200633459A; DE602005003631D1; TWI390937B; US20060095760A1; EP1653387B1; EP1653387A1

Abstract

一种用于创建由属性证书机构包括进属性证书之中的拥有确认证明的方法，所述属性证书由最终用户所使用。所述方法包括响应于最终用户的请求而从属性证书机构接收与目标系统对应的多个数据字段、最终用户的身份以及最终用户的身份拥有证明。所述方法还包括准备对应于属性证书的授权属性的数据结构，该数据结构包括目标系统名、最终用户身份和最终用户的密钥标识符。使用与目标系统相关联的私钥，对该数据结构进行签名从而产生拥有确认证明，并将拥有确认证明发送到属性证书机构，以便将其包括于属性证书中。

Description

创建拥有确认证明的方法和系统

技术领域

本发明一般地涉及信息安全，并且特别地涉及一种用于创建由属性证书机构包括进属性证书之中的拥有确认证明的方法和系统。

背景技术

属性证书(AC)和公钥证书(PKC)被用于保护对电子信息的访问，并可实现于例如因特网邮件、IPSec和web应用的需要分布式安全的各种应用中。虽然这些证书在结构上类似，但二者之间的显著差异在于，AC不包含公钥，而它通常包含PKC的身份或主体名。AC寻求对AC持有者证实(即安全地绑定)一组授权能力(如，组成员资格、角色、安全许可等等)，而PKC将公钥绑定到PKC持有者。这种授权信息可被安置于PKC扩展或AC中；不过，一般不推荐将授权信息安置于PKC中，因为授权信息典型地具有比公钥更短的有效期，而公钥的有效期可以持续数年。这样，当授权信息改变时，PKC就不再有效。进一步地，如果PKC的颁发者和授权企业是不同的实体，则将会要求PKC的颁发者在将授权信息包括到PKC中之前获得授权企业的批准，这样是低效率的。

当基于AC做出访问控制决定时，可能需要验证过程，以确保适当的AC持有者是已请求访问的实体。可通过建立到与AC相应的PKC的连接并使用与PKC相关联的私钥以执行认证来完成此验证。图1说明了通过AC 102的持有者104与相应的X.509 PKC 106连接的X.509 AC 102的框图。X.509是由国际电信联盟(ITU)所推荐的用于定义数字证书和属性证书的标准，所述国际电信联盟是发展电信技术的政府间的组织。在验证过程期间通过跟踪AC 102的持有者104回到相关联的PKC 106而在AC 102中建立信任路径110。AC 102的一个属性是由以下ASN.1语法所定义的服务认证信息属性108：

SvceAuthInfo::＝SEQUENCE{

service GeneralName

ident GeneralName

authInfo OCTET STRING OPTIONAL

}

服务认证信息属性108被用于将目标系统名(service)与例如身份(ident)和凭证(authInfo)的认证信息封装在一起。对于旧应用，身份可以是用户名，而凭证可以是口令。一旦目标服务/系统通过用户和该目标服务之间的某类安全协议而接收到证书102，它就可以认证AC持有者。这样的安全协议将确立用户为PKC的拥有者(如SSL或它的后继者TLS)。为了在创建AC之后保护敏感数据，可使用目标服务的公钥加密用户的凭证信息(即SvceAuthInfo)。根据RFC3281中所概述的推荐标准，由AC的颁发者加密凭证信息，并在将其包括在AC中之前将其安置于被称为encAttrs的另一属性中。除了凭证信息之外，所加密数据也将包括AC颁发者的名字和AC的序列号。该额外信息将凭证信息唯一地绑定于包含它的AC。因此，当对AC进行计算时，目标系统能够验证凭证信息是真实的，并且没有从另一AC中窃取该凭证信息作为重放攻击(replay attack)的一部分。

以下的两个缺点可归因于以上解决方案：(1)当AC颁发者是第三方时口令暴露的潜在可能性；以及(2)改变口令将使AC不可用。对于第一个缺点，以上解决方案将迫使AC颁发者和目标服务/系统成为同一个实体。假如AC颁发者是无法访问目标服务/系统的凭证数据库的第三方，那么当AC的请求者请求AC时，将要求AC请求者向AC颁发者提供明文的口令，从而不适当地将口令暴露给可能是不可信的第三方。不能由请求者在请求AC之前预先加密凭证信息，因为请求者和目标系统二者通常都不知道尚未颁发的证书的序列号，而AC颁发者应该无需知道口令。对于第二个缺点，由于请求者的口令包含于AC中(已加密)，则请求者在目标上的任何口令改变将会使AC不可用。事实上，在口令改变之后对AC的任何使用可显得是非法闯入尝试。

发明内容

一种用于创建由属性证书机构包括进属性证书之中的拥有确认证明的方法、系统和存储介质克服或减轻了本领域的以上讨论的和其他的缺点和不足，所述属性证书由最终用户所使用。所述方法包括响应最终用户的请求而从属性证书机构接收与目标系统对应的多个数据字段、最终用户的身份以及最终用户的身份拥有证明。所述方法还包括准备对应于属性证书的授权属性的数据结构，所述数据结构包括目标系统名、最终用户身份和最终用户的密钥标识符。通过使用与目标系统相关联的私钥，所述方法包括对数据结构进行签名以产生拥有确认证明，以及将拥有确认证明发送到属性证书机构，以便将其包括于属性证书中。

进一步的示例性的实施例包括一种用于创建由属性证书机构包括进属性证书之中的拥有确认证明的计算机数据信号，所述属性证书由最终用户所使用。所述计算机数据信号包括被配置用于使处理器实现一方法的代码。所述方法包括响应最终用户的请求而从属性证书机构接收与目标系统对应的多个数据字段、最终用户的身份以及最终用户的身份拥有证明。所述方法还包括准备对应于属性证书的授权属性的数据结构，所述数据结构包括目标系统名、最终用户身份和最终用户的密钥标识符。通过使用与目标系统相关联的私钥，所述方法包括对数据结构进行签名以产生拥有确认证明，以及将拥有确认证明发送到属性证书机构，以便将其包括于属性证书中。

另外的示例性实施例包括一种用于创建由属性证书机构包括进属性证书之中的拥有确认证明的被编码为带有机器可读的程序代码的存储介质，所述属性证书由最终用户所使用。所述程序代码包括用于使计算机实现一方法的指令。所述方法包括响应最终用户的请求而从属性证书机构接收与目标系统对应的多个数据字段、最终用户的身份以及最终用户的身份拥有证明。所述方法还包括准备对应于属性证书的授权属性的数据结构，所述数据结构包括目标系统名、最终用户身份和最终用户的密钥标识符。通过使用与目标系统相关联的私钥，所述方法包括对数据结构进行签名以产生拥有确认证明，以及将拥有确认证明发送到属性证书机构，以便将其包括于属性证书中。

附图说明

现在参考附图，其中在若干附图中对同样的单元标以同样的标号：

图1说明了属性证书以及相关联的PKI证书的示图；

图2是说明了在本发明的示例性实施例中参与创建和处理属性证书的实体之间关系的框图；

图3是说明了根据本发明的第一实施例用于处理AC请求的方法的流程图，其中属性机构是高度可信的，并且在AC请求之时目标系统可用于口令确认；

图4是说明了根据图3中描述的实施例的用于处理服务请求的方法的流程图；

图5是说明了根据本发明的第二实施例用于处理AC请求的方法的流程图，其中属性机构是部分可信的，并且在AC请求之时目标系统不可用；

图6是说明了根据图5中描述的实施例的用于处理服务请求的方法的流程图；

图7是说明了根据图5中描述的实施例的用于由目标系统触发对AC的升级的方法的流程图；以及

图8是说明了根据图5中描述的实施例的用于由目标系统触发对AC的非同步升级的方法的流程图。

具体实施方式

首先参考图2，其示出说明了参与颁发AC以及与AC相关的服务请求的实体之间关系的系统图。最终用户客户端系统202(也被称为“最终用户”、“用户”或“密钥持有者”)具有由证书机构(CA)(未示出)颁发的PKC 106(图1)。最终用户202请求从属性证书机构(AA)204颁发AC 102(图1)。最终用户202也从目标系统208请求服务(应用、信息等等)。此处所述目标系统208不必是单一机器，或甚至是具有单一网络接口的一组机器。相反地，目标系统208被期望具有在图2的系统内的各节点之间共享用于最终用户的某些或所有的重要子集的非公钥认证凭证的特性。在RFC32814.4.1中定义了目标系统208。在示例性实施例中，根据RFC32814.4.1执行AC验证，在此将RFC32814.4.1整体并入作为参考。目标系统208和AA 204可以是单一企业系统的一部分，由此AA 204被认为是可被目标系统208高度信任的实体。或者可选地，AA 204可以是被认为可被目标系统208部分信任的外部第三方系统。

最终用户202、AA 204和目标系统208可通过一个或多个网络(如网络210)彼此通信。网络210可以是任何类型的已知网络，包括：广域网(WAN)、局域网(LAN)、全球网络(如因特网)、虚拟专用网(VPN)和内联网，但并不局限于以上示例。可使用无线网络或本领域内已知的任何种类的物理网络来实现网络210。最终用户202可通过多个网络(如内联网和因特网)连接于目标系统208，因此不是所有最终用户都通过同一网络连接于目标系统208。一个或多个最终用户和目标系统208可用无线方式连接于网络210。

AA 204根据利用了图1中示出的授权属性108的authInfo字段的本发明的示例性实施例处理AC请求。RFC3281所描述的authInfo字段是包含持有者的明文口令的可选的OCTET STRING。以上列出的两个缺点可分别解决，并在某些情况下可通过扩展对authInfo字段的使用而将两者一起解决。可将authInfo OCTET STRING如下进行编码：

secureAuthInfo::＝CHOICE{

SealedPOP OCTET STRING，

longSealedPOP [3]IMPLICIT Enveloped Data，

aCPOPConfirmation[6]IMPLICIT SignedData-从不在请求

中，仅在AC中

}

sealedPOP或“密封的拥有证明”是用于保护目标系统208不受冒充者的重放攻击的机制。使用sealedPOP结构加密或封装请求者的口令(或其他身份证明)。sealedPOP结构也包括对证书请求的subjectPublicKey(计算为由证书请求102的持有者字段104所引用的证书中的subjectPublicKey位串的值的摘要)的密钥标识符(keyId)的加密，以及各填充。通过用以下步骤首先创建clearSealedPOP结构来准备sealedPOP：

(1)将口令字段设置为在目标系统上的用户实际登记的口令，或可由目标系统验证的另一种格式的身份拥有证明，如“票证”(ticket)；

(2)找到由证书请求所引用的公钥证书；

(3)找到所述公钥证书的subjectPublicKey；

(4)计算作为subjectPublicKey位串的值的SHA-1摘要的、此subjectPublicKey的密钥标识符；以及

(5)生成二进制数据的随机字节流，并将它分配给填充字段。

以下示出了clearSealedPOP结构的语法：

clearSealedPOP::＝SEQUENCE{

password::＝CHOICE{

simple PrintableString，

intl UTFString，

ascii IA5String，

binary OCTET STRING

}，

keyId KeyIdentifier，--来自RFC2459

padding [0]IMPLICIT OCTET STRING OPTIONAL

}

一旦准备了clearSealedPOP，就通过使用目标系统的公钥加密clearSealedPOP而创建sealedPOP。此外，可以不对称地完成加密，而生成sealedPOP。或者，如果以PKCS#7或密码消息语法的格式对称地完成加密(封装)，以致所加密的对称密钥仅能够由主机读出，则结果为longSealedPOP。在任一情况下，将密封的拥有证明发送到AA 204作为认证请求的一部分。接着可将sealedPOP安置于AC中作为此处进一步描述的请求的结果。在由本发明的受让人于2001年5月22日所申请的标题为“用于与主机身份结合的数字签名的口令暴露排除”(Password ExposureElimination for Digital Signature Coupling With A Host Identity)的序列号为09/862,797的美国专利申请中描述了这些sealedPOP、longSealedPOP和clearSealedPOP结构，并在此将该专利申请整体并入作为参考。

由目标系统对SvceAuthInfo结构的编码进行签名，以产生以上的aCPOPConfirmation结构，并且其被提供如下：

signedContent::＝SvceAuthInfo一其中authInfo被设为keyId

现转到图3，现在将描述用于创建一AC的过程，其中AA 204为高度可信的，并且当请求AC之时目标系统208可用于口令确认。图3中描述的过程假定AA 204是目标系统208的可信计算基的一部分。目标系统208的用户从目标系统请求服务之前从AA 204请求AC。在步骤302，AA 204从最终用户客户端系统202接收对AC的请求。用户通过带有客户端认证的SSL(或类似的协议)认证到AA 204。换句话说，最终用户提供有效的PKC。用户提供目标系统凭证信息，即，用户名/口令对。

在接收到AC请求之后，AA 204准备包含由用户提供的口令的clearSealedPOP结构和在来自用户的PKC的公钥上计算出的keyId。接着在步骤304，或者使用目标系统208的公钥来不对称地加密此clearSealedPOP结构而产生sealedPOP结构，或者使用PKCS#7(密码消息语法)对称地加密(封装)此clearSealedPOP结构而产生longSealedPOP结构。在任一方法中，clearSealedPOP数据将仅能由目标系统208恢复。接着在步骤306，AA 204会将此已加密结构和用户名的值发送到目标系统208用于验证。

在接收到用于验证的信息之后，在步骤308，目标系统208使用它自己的私钥直接地(或者如果被封装则间接地)恢复clearSealedPOP数据。例如，可通过或者(1)用主机系统的私钥直接解密密文，或者(2)如果使用了封装，则通过首先用主机系统的私钥解密对称密钥，再用已解密的对称密钥解密密文而实现所述恢复。接着在步骤310，对照目标系统的凭证数据库检查用户名/口令对的真实性。此外，目标系统通过验证密钥标识符与证书主体公钥的密钥标识符相匹配来确定重放攻击不存在。

如果真实性检查揭示出不匹配，则在步骤312可发送信息以表明数据是无效的，并在步骤314终止请求。如果在步骤310的真实性检查成功，则在步骤316，目标系统208准备包含了目标系统208名(service)、用户名的值(ident)和KeyId(authInfo)的SvceAuthInfo。在步骤318，通过由目标系统208使用目标系统208的私钥对该SvceAuthInfo结构的编码进行签名，以产生aCPOPConfirmation。可使用唯一编码规则(DER)实现所述编码，所述唯一编码规则是用于以独立于平台的方式封装数据的标准。DER编码经常被用于需要数字签名的数据，并将被本领域内的技术人员所理解。在步骤320将aCPOPConfirmation返回到AA 204用于包括进AC中。

一旦aCPOPConfirmation被返回到AA 204，在步骤322，AA 204将来自它的service和ident字段复制到即将创建的SvceAuthInfo属性中的相应字段。aCPOPConfirmation本身将被用作为secureAuthInfo的CHOICE值，该CHOICE值一旦被DER编码，将成为svceAuthInfo属性的authInfoOCTET STRING。在步骤324，将按照RFC3281准备AC的其余部分，并在步骤326将其颁发给用户。现在最终用户202可请求来自目标系统208的服务。

根据图3中描述的实施例，最终用户202请求来自目标系统208的服务。现在将相对于图4描述服务请求过程。在步骤402，目标系统208接收对服务的请求。此步骤涉及通过带有客户端认证的SSL(或类似协议)使用户认证到目标系统208。在此情况下，PKC必须与请求AC时所使用的PKC相同，或至少具有与初始PKC相同的公钥。在步骤404，目标系统208执行对AC的验证。在示例性的实施例中，根据RFC32815执行对AC的验证。如果在步骤406中AC无效，则在步骤412可发送错误信息到请求者。如果在步骤406中AC有效，并且它包含了带有secureAuthInfo-aCPOPConfirmation结构的svceAuthInfo属性，则在步骤408，目标系统208使用目标系统208的公钥在aCPOPConfirmationSignedData上执行签名检查。如果在步骤410中签名无效，则在步骤412发送错误信息。如果签名有效，则目标系统208确信aCPOPConfirmation数据是真实的。接着在步骤414，目标系统208检查以确保该用户确实是初始请求该AC的用户。通过将来自aCPOPConfirmation的keyId与在来自用户的PKC的公钥之上计算的keyId进行比较而执行此步骤。如果在步骤416二者不同(无效)，则在步骤412发出错误信息。如果有效，则完成secureAuthInfo验证过程。在步骤418，目标系统208使用来自aCPOPConfirmation的ident值来为用户创建安全上下文(即登录该用户)。

通过以上描述将理解，由于用户口令实际上并未存储于AC中，因此在目标系统208上的任何用户口令改变将不会使AC不可用。因此，以上方法解决了以上的第二个缺点。不过，它并未解决上述的第一个缺点，因为仍需要请求者向AA 204提供明文口令。以下在图5和6中描述的过程解决第一个缺点的不足。

现在转到图5，其示出一种用于创建AC的过程，其中AA 204是部分可信的，并且在请求AC时，目标系统208不可用于口令确认。图5中描述的过程假定AA 204由外部第三方操作。目标系统208的用户将在从目标系统208请求服务之前从AA 204请求AC。由于AA 204不是目标系统208的可信计算基的一部分，因此当请求AC时不希望将用户口令发送到AA204。为了避免将口令发送到AA 204，在步骤504，在请求AC之前，由用户(而非AA 204)如图3的304中所述创建sealedPOP结构或者longSealedPOP结构。在步骤507，AA 204从最终用户客户端系统202接收对AC的请求。用户通过带有客户端认证的SSL(或类似协议)认证到AA204。换句话说，用户必须提供有效的PKC。作为步骤507的一部分，将sealedPOP或longSealedPOP结构连同用户的目标系统用户名一起提交给AA 204。

在从用户接收AC请求之后，在步骤508，AA 204通过所提供的信息构造要被创建的SvceAuthInfo属性。sealedPOP或longSealedPOP结构被用作secureAuthInfo的CHOICE值，该CHOICE值一旦被DER编码，就成为SvceAuthInfo属性的authInfo OCTET STRING。在步骤510，根据RFC3281准备其余的AC，并在步骤512将其颁发到用户。

如现在将在图6的过程中被描述的，根据图5中描述的实施例，用户请求来自目标系统208的服务。在步骤602，目标系统208接收对服务的请求。此步骤涉及通过带有客户端认证的SSL(或类似协议)将用户认证到目标系统208。在此情况下，PKC必须与请求AC时所使用的PKC相同，或至少具有与初始PKC相同的公钥。在步骤604，目标系统208执行对AC的验证。在示例性的实施例中，根据RFC32815执行对AC的验证。如果在步骤606中验证不成功，则在步骤614发送错误信息并终止会话。如果AC有效，并且它包含了secureAuthInfo-sealedPOP或longSealedPOP结构，则在步骤608，解密该结构以恢复clearSealedPOP，并从而恢复明文口令和KeyId。在步骤610，验证明文口令为ident的口令。如果步骤612成功，则在步骤616将来自clearSealedPOP的keyId与在来自用户的PKC的公钥之上计算的keyId进行比较，以确保用户确实是起初请求AC的人。如果在步骤618中二者相同，则完成secureAuthInfo验证过程。接着在步骤620，目标系统208将使用来自SvceAuthInfo属性的ident值来为用户创建安全上下文(即登录该用户)。可以理解，由于没有将口令暴露给第三方AA 204，解决了以上的问题1。不过，由于AC包含了口令，没有解决问题2。在目标系统208上用户口令的改变将使AC不可用。

可通过结合以上图3和5中描述的两种过程的特性来同时解决上述的两个缺点。以下场景假定AA 204是部分可信的，并且当AC请求之时目标系统208可用于口令确认。如图3中所述地实现该过程，除了如图5中所述地由用户(而非AA 204)创建sealedPOP或longSealedPOP结构。AA 204将此信息转发到目标系统208用于验证。在接收到用于验证的信息之后，目标系统208遵循图3中概述的过程恢复clearSealedPOP，检查用户名/口令对的真实性，检查keyId，以及(如果成功的话)构造将被返回到AA 204的aCPOPConfirmation。根据aCPOPConfirmation对AC的构造和用户对AC的使用分别与图3和图4中所述相同。因为未将口令暴露给AA 204并且AC能够经受住口令改变，所以同时解决了问题1和2。

可以为AA 204颁发的AC实现升级。图7描述了用于在登录后由目标系统208触发对AC升级的过程，并且此过程是图5和6中所述过程的延续。图8描述了用于由目标系统208非同步触发对AC升级的过程，并且此过程是图5和6中所述过程的延续。

现在转到图7，AA 204颁发了包含sealedPOP或longSealedPOP结构的AC，而用户以后使用它进行登录。当目标系统208为用户创建其安全上下文时(在成功地完成如图6所述的验证之后)，接着在步骤702，它检查看这是否是带有该AC的第一次登录尝试。如果否，则在步骤704照常地继续会话。如果这是第一次登录尝试，则在步骤706，目标系统208准备包含目标系统208的名(service)、用户名的值(ident)和keyId(authInfo)的新的SvceAuthInfo结构。在步骤708，将由目标系统208(使用目标系统的私钥)对此SvceAuthInfo结构的DER编码进行签名，以生成aCPOPConfirmation。在步骤710，将此aCPOPConfirmation连同PKC和AC的副本一起发送到AA 204。

在步骤712，在颁发任何新的AC之前，AA 204确认PKC的密钥ID匹配aCPOPConfirmation中的密钥ID，以及现有的AC引用了PKC。当AA 204接收了包含了这三个项目的消息时，在步骤714，AA 204可以颁发新的AC，所述AC的AttributeCertInfo与之前的AC相同，除了以下的差异：改变了serialNumber，将attrCertValidityPeriod.notBeforeTime更新为当前时间(尽管未改变attrCertValidityPeriod.notAfterTime)，以及由aCPOPConfirmation更新SvceAuthInfo以替换sealedPOP或longSealedPOP。

可以理解，此过程允许目标系统208将作为图4中描述的实施例的结果被颁发的AC迁移为作为图3中描述的实施例的结果被颁发的AC，后者不受口令改变的影响。可以用多种标准方式中的任一种将新的AC分发给主体。具体地，仅举几例，可在与目标系统208的一会话期间将新的AC返回给主体，通过电子邮件(加密的或明文的)发送，以及将其放置于一目录、FTP站点或Web站点中。

现转到图8，现在将描述用于由目标系统208非同步触发对AC升级的过程。在步骤802，AA 204颁发包含sealedPOP或longSealedPOP结构的AC，并将它的副本连同相应的PKC一起发送到属于目标系统208的队列或储存库。当目标系统208低负载时，在步骤804，它就处理来自这个队列或储存库的条目。在步骤806目标系统208验证AC，并且在步骤808目标系统208解密secureAuthInfo-sealedPOP或longSealedPOP结构以恢复clearSealedPOP，并从而恢复明文口令和KeyId。如果在步骤810中没有恢复clearSealedPOP，则在步骤812不采取任何行动。

如果在步骤810中恢复了clearSealedPOP，则在步骤814，验证明文口令为ident的口令，并接着为了确保用户确实是最初请求AC的人，在步骤816将来自clearSealedPOP的keyId与在来自用户的PKC的公钥上计算的keyId进行比较。如果它们相同，则在步骤818，目标系统208准备包含了目标系统208的名(service)、用户名的值(ident)和keyId(authInfo)的新的SvceAuthInfo结构。在步骤820，由目标系统208(使用目标系统的私钥)对此SvceAuthInfo结构的DER编码进行签名，以生成aCPOPConfirmation。在步骤822，将此aCPOPConfirmation连同PKC和AC的副本一起发送到AA 204。

在步骤824，在颁发任何新的AC之前，AA 204确认PKC的密钥ID匹配aCPOPConfirmation中的密钥ID，以及现有的AC引用了PKC。当AA 204接收到包含了这三个项目的消息时，在步骤826，AA 204颁发新的AC，所述AC的AttributeCertInfo与之前的AC相同，除了以下的差异：改变了serialNumber，将attrCertValidityPeriod.notBeforeTime更新为当前时间(尽管未改变attrCertValidityPeriod.notAfterTime)，以及由aCPOPConfirmation更新SvceAuthInfo以替换sealedPOP或longSealedPOP。

可以理解，此过程允许目标系统将作为图5中描述的过程的结果被颁发的AC迁移为作为图3中描述的过程的结果被颁发的AC，后者不受口令改变的影响。可以用多种标准方式中的任一种将新的AC分发给主体。具体地，可在与目标系统的一会话期间将新的AC返回给主体，通过电子邮件(加密的或明文的)发送，以及将其放置于一目录、FTP站点或Web站点中。

注意，通过将AC请求者的密钥标识符包括于任何形式的authInfo(现在是安全的)中，POP信息被加密地绑定到请求者的PKC。从而，不需要进一步将SvceAuthInfo属性绑定到AC以防止重放。因此，当构造AC时，将不会将SvceAuthInfo包括于encAttrs属性中。

如上所述，可以用计算机实现的过程和用于实践这些过程的装置的形式体现本发明的实施例。也可以用包含指令的计算机程序代码的形式体现本发明的实施例，所述代码包含于例如软盘、CD-ROM、硬盘驱动器或任何其他计算机可读存储介质的有形介质中，其中，当计算机装载并执行所述计算机程序代码时，该计算机成为用于实践本发明的装置。也能够用计算机程序代码的形式体现本发明，所述计算机程序代码例如是不论是否存储于存储介质中由计算机装载和/或执行的，或者在某种传输介质上例如在电线或电缆线路上、通过光纤或通过电磁辐射传送的，其中，当计算机装载并执行所述计算机程序代码时，该计算机成为用于实践本发明的装置。当实现于通用微处理器上时，所述计算机程序代码段配置该微处理器，以创建特定逻辑电路。

虽然已参照示例性的实施例描述了本发明，本领域中的技术人员将理解，无需背离本发明的范围即可以做出各种改变并可以用同等物替换本发明中的元件。此外，无需背离本发明的本质范围即可对本发明的示教做出许多修改，以适应特定的情况或材料。因此，本发明并非旨在局限于作为被认为是执行本发明的最好模式而公开的特定实施例，而是本发明旨在将包括落在所附权利要求的范围内的所有实施例。此外，对术语第一、第二等等的使用不表示任何顺序或重要性，而是将术语第一、第二等等用于区别一个单元和另一个。

Claims

1.一种用于创建由属性证书机构包括进属性证书之中的拥有确认证明的方法，该属性证书由最终用户所使用，该方法包括：

响应于最终用户的请求而从属性证书机构接收与目标系统对应的多个数据字段、最终用户的身份以及最终用户的身份拥有证明；

准备对应于属性证书的授权属性的数据结构，该数据结构包括目标系统名、最终用户身份和最终用户的密钥标识符，其中通过经由对应于该属性证书的授权信息字段的OCTET STRING来扩展该授权信息字段而准备所述数据结构；

使用与目标系统相关联的私钥，对该数据结构进行签名以产生拥有确认证明；

将该拥有确认证明发送到属性证书机构，以便将其包括于属性证书中；以及

处理与目标系统相关联的队列中存储的属性证书的副本，升级属性证书，当目标系统低负载时，由目标系统非同步地触发所述升级。

2.根据权利要求1所述的方法，还包括：

在准备所述数据结构之前确认所述多个数据字段。

3.根据权利要求1所述的方法，其中，由最终用户加密所述身份拥有证明，其中属性证书机构不是与目标系统相关联的可信计算基的一部分，最终用户在所述请求之时加密所述身份拥有证明。

4.根据权利要求1所述的方法，其中，由属性证书机构加密所述身份拥有证明，其中属性证书机构是与目标系统相关联的可信计算基的一部分，属性证书机构在所述请求之时加密所述身份拥有证明。

5.一种用于创建由属性证书机构包括进属性证书之中的拥有确认证明的计算机系统，所述属性证书由最终用户所使用，在所述系统包括：

用于响应于最终用户的请求而从属性证书机构接收与目标系统对应的多个数据字段、最终用户的身份以及最终用户的身份拥有证明的装置；

用于准备对应于属性证书的授权属性的数据结构的装置，该数据结构包括目标系统名、最终用户身份和最终用户的密钥标识符，其中通过经由对应于该属性证书的授权信息字段的OCTETSTRING来扩展该授权信息字段而准备所述数据结构；

用于使用与目标系统相关联的私钥，对该数据结构进行签名以产生拥有确认证明的装置；

用于将该拥有确认证明发送到属性证书机构，以便将其包括于属性证书中的装置；以及

用于处理与目标系统相关联的队列中存储的属性证书的副本，升级属性证书，当目标系统低负载时，由目标系统非同步地触发所述升级的装置。

6.根据权利要求5所述的系统，还包括：

用于在准备所述数据结构之前确认所述多个数据字段的装置。

7.根据权利要求5所述的系统，其中，由最终用户加密所述身份拥有证明，其中属性证书机构不是与目标系统相关联的可信计算基的一部分，最终用户在所述请求之时加密所述身份拥有证明。

8.根据权利要求5所述的系统，其中，由属性证书机构加密所述身份拥有证明，其中属性证书机构是与目标系统相关联的可信计算基的一部分，属性证书机构在所述请求之时加密所述身份拥有证明。