本申请涉及申请号为____于2005年2月28日提交的[律师案号为MSFT-4736/311539.01]题为“用于签发证书的可扩展的数据驱动***和方法”(ExtendableData-Driven System and Method for Issuing Certificates)的美国专利申请。
具体实施方式
某些特定细节在以下说明书和附图中陈述以提供对本发明各实施例的完整理解。然而,为了避免不必要地混淆本发明的各个实施例,通常关联于计算和软件技术的某些众所周知的细节并未在以下揭示中陈述。此外,本领域技术人员将理解,无需以下所述的一个或多个细节他们可实践本发明的其它实施例。最后,尽管各种方法是参照以下说明书中的步骤和顺序来描述的,但是这样的描述是用来提供本发明各实施例的清晰实现的,且各步骤和步骤的顺序不应视为是实践本发明所必须的。
在此所述的设备和方法通常涉及签发数字证书。术语“证书”在此用作“数字证书”的缩写形式。如在背景技术中所述,证书是证明某物或某物所有权的真实性的文档。术语“证明”表示确认是正确、真实或真的。因而在此将被称为客户机的第一实体可使用证书来向第二实体-服务器-确认有关它自己的一些事实。证书通常(尽管并非必须)由受信任的第三方签发。当在此使用时,证书的范围可以从自己产生的文档或令牌到由受信任第三方签发的具有许多安全特性的可高度信任的数字文件,诸如根据一种或多种公钥或私钥技术等的加密。由证书证明的“某物”可以是任何东西。通常,可证明客户机的身份和/或对客户机花去或访问某些资源的授权,但也可证明任何其它东西。
受信任的第三方在此被称为证书签发***。术语“证书签发***”在此且在本行业中也可称为“证书签发服务”,并且为简便起见可简称为术语“签发器”。证书签发***确定是否向特定客户机授权一证书。如果是,则向客户机签发证书并可使用该证书向服务器进行认证。
尽管客户机和服务器可被视为两个完整的计算设备,每一个都包括硬盘、总线、***存储器等,但是本领域技术人员以更广泛含义来理解这些术语。客户机和服务器实际上可以是单个计算设备内、或在分布式计算装置中的多个计算机上存在的两个实体。这样,证书签发***也可存在于包括一个或多个客户机以及一个或单个服务器实体的计算机内,并还可存在于多个设备之上。
参照图1,概述了适于结合证书签发***使用的示例计算设备100。在其最基本配置中,设备100通常包括处理单元102和存储器103。取决于计算设备的准确配置和类型,存储器103可以是易失性存储器103A(诸如RAM)、非易失性存储器103B(诸如ROM、闪存等等)、或两者的某些组合。此外,设备100还可具有诸如磁性或光学的盘或带的大容量存储设备(可移动的104和/或不可移动的105)。类似地,设备100可包括诸如键盘和鼠标的输入设备107,和/或诸如将GUI表示为对计算设备100的功能的图形辅助访问的显示器的输出设备106。设备100的其它方面可包括使用有线或无线介质与其它设备、计算机、网络、服务器等的通信连接108。
易失性存储器103A、非易失性存储器103B、可移动大容量存储104和不可移动大容量存储105是计算机可读介质的示例。计算机可读介质可包括通信介质以及计算机存储介质。通信介质通常体现为计算机可读指令、数据结构、程序模块、或其它诸如载波或其它传送机制的已调制数据的信号的其它数据,并包括任何信息传送介质。术语“已调制数据信号”意指具有以这种把信息编码到信号中的方式来设置或改变的一个或多个特征的信号。作为示例,而非限制,通信介质包括诸如有线网络或直接有线连接的有线介质,以及诸如声学、RF、红外和其它无线介质的无线介质。
计算机存储介质可以用来存储诸如计算机可读指令、数据结构、程序模块、或其它数据的信息的任何方法或技术实现。计算机存储介质包括,但不限于,RAM、ROM、EEPROM、闪存或其它存储器技术、CD-ROM、数字多功能光盘(DVD)或其它光学存储器、磁盒、磁带、磁盘存储器或其它磁性存储设备、或任何其它介质。
本发明至少部分地可通过诸如由计算机100执行的程序模块的计算机可执行指令实现。通常,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等。
计算机可执行指令通常体现为某些形式的计算机可读介质上的对计算机100可用的数字信息。例如在图1中,***存储器103可存储操作***和应用程序以及其它程序模块和程序数据。应用程序等可绑定于操作***,或可单独存在并利用操作***服务来发挥作用。
应当理解,尽管在此所述的本发明的各个实施例可以是软件实现,但在此所述的各种技术也可通过用硬件组件替换至少一些程序模块来实现。因而,尽管本发明的方法和装置、或其某些方面或部分可采取高级过程或面向对象编程语言的程序代码的形式,但(各)程序也可用汇编或及其语言实现。在任一情形中,语言可以是编译或解释语言,并可与硬件实现相结合。
本发明可在许多通用或专用计算***环境或配置中操作。众所周知的适用于本发明的计算***、环境和/或配置的示例包括,但不限于,个人计算机、服务器计算机、手持式或膝上型设备、多处理器***、基于微处理器的***、机顶盒、可编程消费电器、网络PC、小型计算机、包括任何以上***或设备的分布式计算环境等。
图2提供一示例性网络化计算环境。该网络包括计算设备271、272、276和277,对象273、274和275,以及数据库278。这些实体271、272、273、274、275、276、277和278的每一个都可包括或使用程序、方法、数据存储、可编程逻辑等。实体271、272、273、274、275、276、277和278可跨越诸如PDA、音频/视频设备、MP3播放器、个人计算机等的相同或不同设备的各个部分。每个实体271、272、273、274、275、276、277和278可通过通信网络270与另一实体271、272、273、274、275、276、277和278进行通信。
网络上的各个设备利用(各)协议层提供的功能来彼此通信。例如,超文本传输协议(HTTP)是结合万维网(WWW)或“web”使用的通用协议。通常诸如互联网协议(IP)地址的计算机网络地址、或诸如全球资源***(URL)的其它引用可用来彼此标识服务器或客户机计算机。网络地址可被称为URL地址。通信可在通信介质上提供,例如(各)客户机和(各)服务器可通过高容量通信的TCP/IP连接来彼此耦合。
网络本身可包括向图2***提供服务的其它计算实体,并可表示多个互连网络。每个实体271、272、273、274、275、276、277和278可包含离散的功能程序模块,这些程序模块可使用API、或其它对象、软件、固件和/或硬件来请求其它实体271、272、273、274、275、276、277和278的一个或多个的服务。
“客户机”是使用与之不相关的另一类或组的服务的一个类或组的成员。在计算中,客户机可以是请求由另一程序提供的服务的进程,即粗略地为一系列指令或任务。这种服务可以是例如由证书签发***的证书签发。客户机进程无需“知道”任何有关其它程序或服务本身的工作细节就可使用所请求的服务。在客户机/服务器体系结构特别是网络化***中,客户机通常是访问由例如服务器的另一计算机提供的共享网络资源的计算机。在图2示例中,取决于各情形,任何实体271、272、273、274、275、276、277和278可被视为客户机、服务器或两者。
服务器通常(尽管并非必须)是在诸如因特网的远程或局域网上可访问的远程计算机***。该客户机进程可在第一计算机***内活动,而服务器进程可在第二计算机***内活动,彼此经通信介质通信,从而提供分布式功能并允许多个客户机利用服务器的信息收集功能。任何软件对象都可在多个计算设备或对象上分布。
因而本发明的各个实施例可解决请求证书的客户机实体驻留于网络中的例如第一计算设备277的情形。具有为客户机实体所需的一些资源的服务器实体可驻留于例如第二计算设备275中。证书签发***可驻留于例如另外的第三计算设备271。
设备277上的客户机可确定它需要一证书来向设备275上的服务器证明一些客户机凭证。277上的客户机因而在网络总线170上向271上的签发器提交请求。请求本身可包括一个或多个先前签发的证书。271上的签发器继续确定客户机是否有权得到所请求的证书。271上的签发器通过应用证书签发策略来完成它。如果277上的客户机具有策略所需的凭证,则所请求证书可由271上的签发器签发给277上的客户机。然后客户机可在它与275上服务器的通信中使用所签发证书以及任何数量的其它证书。
图3A示出证书签发***的转换组件部分。签发组件34更详细地在图4和5中示出。在本发明的各个实施例中,转换组件实际上可以是接收输入证书的第一个组件,也可以是在证书传送给客户机之前可操纵证书的最后一个组件。在其它实施例中,转换组件可按需用于证书签发***中的任何地方。
当对证书的请求到达证书签发***时,诸如第一格式30的第一证书的任何附带证书可被路由到转换驱动器31。转换驱动器31可操作以进行各证书与用于签发组件34的操作的通用格式之间的转换。因而,第一格式30的第一证书可被转换成第二格式。这种转换的结果是第二格式33的第一证书。
相反,当证书由签发组件34签发时,它可从签发组件34产生的格式转换成客户机所需的任何格式。因而,第二格式35的第二证书可被转换成第三格式。这种转换的结果是第三格式37的第二证书。该第三格式可以是任何证书格式,包括达到对证书的客户机请求的一个或多个证书(例如30)的格式。
证书转换组件最好被设计成转换尽可能多的证书格式。这样,它可转换X.509证书、安全性断言标记语言(SAML)安全令牌证书、XrML 1.2证书、和MPEG-REL证书(仅列出一些较流行的示例性证书格式)。然而,对每种可能的证书类型设计转换装置并非总是经济可行的。本发明并不限于转换组件能够转换的证书类型的数量或特定格式。
因为在本领域中新的证书格式在持续产生,所以将转换组件设计成能进行扩展以容纳其它证书格式是有利的。驱动器31可基于诸如32的一个或多个类所提供的指令,来管理将特定证书30的各个元素转换成通用格式证书33。图3A的特定装置是有利的,因为它允许转换组件可扩展以容纳新的证书格式。然而,驱动器31和诸如图3A中32、36装置的类仅仅是示例性的,并且本领域技术人员将理解各种装置可用来完成证书从一种格式到另一种格式的转换。
在图3A中,通用格式被称为第二格式。通用格式的选择涉及确定一种格式,该格式尽可能稳健以容纳各种格式的输入证书中可包含的全部各种类型信息。尽管可选择任何证书来用作通用格式,包括X.509证书、安全性断言标记语言(SAML)安全令牌证书、XrML 1.2证书、和MPEG-REL证书(仅列出一些较流行的示例性证书格式),但已选择MPEG-REL来实现本发明,并被视为是有利于此目的的。MPEG-REL目前被视为最丰富、最稳健和可扩展的证书格式。然而,随着技术的进步,可开发其它更多有利的证书。
使用转换组件的另一优点源于这样的事实,各种证书格式的每一种都用它自已的方式来表达策略。现有证书签发器互操作性的障碍是格式不能兼容,因为要消费任何特定格式需要遍及签发器的定制算法。我们不能期望说服所有现有的证书制造商采用一通用格式,因此我们必须假设这些格式将继续长期存在。用于将不同的证书格式及其语义映射或转换成通用语言的技术减少了多种格式的***性影响,并且是在解决证书互用性问题的方向上的一个步骤。
正确的转换应满足语法和语义要求。前者需要转换后格式具有有效格式。后者需要转换后证书传送与原始证书相同的信息。然而,有源格式具有比目标格式更多信息的情形,这使得转换中的信息损失不可避免。因而实现本发明的目标是确保信息正确转换同时尽力保留其它信息。
证书转换算法32、26可基于其功能分成两类:
语法级:在结构之间映射
语义级:在证书之间转换
在一实施例中,该算法集合被实现为一个类集。该类集在图3A中被示为证书转换驱动器31。转换驱动器31的各个实施例可包括三个组件:驱动器类、证书转换类和配置类。驱动器类可执行转换过程的整体协调并调用转换类。转换类可执行实际转换过程,而配置类可包含转换驱动器31进行操作所必须的配置数据。
以下简单示例被包括为演示从第一证书格式XrML 1.2到第二证书格式XrML2.0的转换的示例性操作。如本领域技术人员可以理解的,MICROSOFT的RightsManagement Server(权限管理服务器)产品的第一版本使用XrML 1.2格式的证书来进行其策略评估。然而,权限管理服务器产品的将来发行版本将使用XrML 2.0格式的证书。因而,以下提供转换组件的操作和对在此提供的本发明的增长需要的较好示例。情形如下:客户机将证书请求发送给假定的实现本发明的权限管理服务器产品。该请求本身包含XrML 1.2格式的证书,例如图3A中的证书30。XrML 2.0是证书签发***34所使用的通用格式。
为了接收并理解两种格式的证书,实现一转换类集。假设这已经完成,在接收来自客户机的具有XrML 1.2格式的证书30的请求之后,转换驱动器31插件相应的证书转换类32、将配置数据传送给它并调用转换方法。证书转换类32确认XrML 1.2证书30的签名和有效期,并及其转换成XrML 2.0证书33,并将转换特定信息返回给转换驱动器31。然后转换驱动器31使用XrML 2.0格式的证书33来调用权限管理服务器34。在该示例中,权限管理服务器34自然地理解XrML 2.0证书、执行证书签发操作、并将结果发送回转换驱动器31。在接收由权限管理服务器34签发的XrML 2.0证书35之后,转换驱动器31创建将XrML 2.0证书35转换成XrML 1.2证书37的证书转换类36。
图3B示出输入证书请求如何由签发器处理的视图。首先请求到达服务器入口点301。原始格式的证书-或其它请求信息-302被传送给称为转换层303的转换组件。注意,证书并非总是附于证书请求的。通常作出某些形式的证明,并且在证书是确认要证明的事实的较好方式时,它们并非总附于证书请求。各种类型的其它信息也可包括于请求中。当使用一些其它信息时,信息的特定数据类型可以有些像证书格式可不同的方式而不同。因而,证书转换层303可被配置成将诸如302的证书从一种格式转换成另一种格式,或从各种格式转换成单一格式,但也可配置成处理附于证书请求的任何数据。像输入证书的这种数据可被转换成可由单个签发组件或(在此称作)证书引擎305消费的通用格式。
图3B中的输入信息可被转换成第二格式304。如果输入信息已是第二格式,则当然无需转换。然后证书和/或关联于请求304的其它信息可由服务器证书引擎305来处理。
图3C示出本发明的另一视图,其中客户机310向服务器313发送对证书的请求。类型1证书关联于客户机310的请求。类型1证书可被证书转换引擎(CTE)311转换成由签发器312消费的某些其它格式,诸如类型2证书。类型2证书可被签发引擎312用来确定是否要许可客户机310的请求。当签发引擎312签发第二格式的证书时,CTE 311可将其转换成用于客户机310的第一格式。或者,签发引擎312可简便地产生用于客户机310的适当格式的证书,而无需再使用CTE 311来从第二格式证书转换成第一格式证书。注意在本发明的许多实施例中,CTE 311可被配置成处理多个输入证书类型。每种类型最好被配置成将来自签发引擎312的第二格式证书转换成如客户机310所请求的各种证书类型的任一种。
在各示例性情形中,可获益于诸如图3C所示***的使用的是客户机设备和/或进程的证明,来许可客户机许可证颁发证书(CLC)请求、并特许对数字内容的权限。
当使用以第一格式证书操作的客户机(“v1客户机”)的用户首次尝试打开由权限管理***保护的电子邮件时,产生一示例性认证情形。在该情形中,v1客户机可向证书签发***313发送表示客户机身份的目前是XrML 1.2证书的v1机器帐户证书(MAC),以及WINDOWS域凭证。CTE 311可将MAC转换成目前是表示客户机身份的MPEG-REL证书的安全处理器证书(SPC),并将该SPC给予签发引擎312。然后签发引擎可签发第二格式证书,例如目前是表示客户机上用户身份的MPEG-REL证书的权限帐户证书(RAC),并将该RAC送给CTE 311。CTE 311然后可将RAC转换成第一格式证书,例如目前是表示客户机上用户身份的XrML1.2证书的组身份证书(GIC)。该签发***313然后可用GIC向客户机310作出回应。
一示例性CLC请求情形是,客户机310向签发***313发送请求以获取授权用户公布对离线受保护内容的许可证的证书。在该情形中,CTE 311可将关联于该请求的输入RAC转换成可由签发引擎312处理的CLC。或者,客户机310可发出由CTE 311转换成SPC的GIC,且签发器312可返回由CTE 311转换成CLC的RAC。
诸如图3C的***可用于特许数字内容中权限的示例性情形如下:为了消费权限受保护内容,v1客户机310可作出对签发***313的特许请求。客户机310可向签发***313发送v1发布许可证-签发许可证(IL),例如描述对特定保护内容的作者指定使用权限的XrML 1.2证书,和GIC。然后CTE 311可转换输入的IL和RAC,并将它们给予签发引擎312。如果签发引擎312向客户机310授予使用许可证(UL),例如授权特定用户访问特定受保护内容的MPEG-REL证书,则CTE311也可将所签发的UL转换成终端用户许可证(EUL),诸如授权特定用户访问特定受保护内容的由v1客户机310消费的XrML 1.2证书。签发***313然后可将该UL发回客户机310。
尽管众多软件设计可用来实现CTE 311,但如本领域技术人员所理解的,示例性CTE设计可包括三个组件:CTE驱动器、证书转换类和配置类。
在该设计中,CTE驱动器与服务器入口点301和服务器证书引擎305交互。在接收证书请求之后,驱动器创建相应的证书转换类、将配置数据传送给转换类、并调用转换方法。然后证书转换类例如使用诸如a)签名确认,b)证书有效期间隔过期时间以及c)对该签发器和受信任签发器集作比较的技术,来确认所处理证书的签名和有效期。证书转换类还可将证书转换成通用格式证书对应体,并向CTE驱动器返回通用格式证书字符串、以及其它转换-特定信息。
然后CTE驱动器使用通用格式证书来调用证书引擎305。在接收到由证书引擎305签发的合成通用格式证书之后,CTE驱动器创建一证书转换类,该类将所产生的通用格式证书转换成第三格式的对应证书,例如原始输入证书的格式。
因而,CTE的示例性工作流可如下进行:
获得来自客户机的证书请求
按需确认并解密所附证书
将解密后的证书转换成通用格式证书
可替换某些信息(密钥、SPC等)
保存不能在通用格式证书中表示的任何信息
调用证书签发引擎
获得来自证书签发引擎的已签发通用格式证书
按需解密已签发的通用格式证书
将解密后的已签发通用格式证书转换成客户机格式证书
可使用在前一步骤中保存的信息
加密并签名客户机格式证书
将客户机格式化的证书发送给客户机
图4示出证书签发***的签发组件部分。一旦参照图3A所述转换完成,转换后的证书表示可使用图4所示的各种功能组件来处理。转换组件未在图4或图5中示出以避免使示图模糊。对于各个组件的示例性组合,参见图3A。
客户机40发送一个或多个声明、及其对证书的请求。声明是实体所作的任何断定,以用来确定该实体是否有权得到证书。如果声明经校验为真,则客户机实体40显示它具有凭证。在向客户机40签发证书之前证书签发策略最终会需要一个或多个凭证。这些凭证本身可由一个或多个证书证明。
认证41、授权42和凭证格式化43是可由签发组件执行的示例性功能。如图4所示,这些功能可按认证41、授权42和凭证格式化43的顺序连续地执行。该顺序在所有实施例中并非是必需的。取决于满足客户机请求的所需,41、42和43可独立执行,可执行某些子组合,或者一个或多个这些功能可结合图4中所示的有些其它功能来执行。
当连续执行41、42和43时,认证过程41首先可确定声明支持证书请求的客户机40实际上是否是客户机40所声明的实体。如果这得到了证实,则授权过程42可确定客户机是否可获得接收所请求证书的授权。或者,授权过程42可简便地确定客户机40的授权级别,并将其记录在所创建的证书中。最后,当证书代表客户机40产生时,列示于证书中的客户机40凭证可由43在所产生的证书中格式化。以下提供了可由证书签发引擎44应用的示例性算法:
签发证书(用户输入证书,服务器签发策略)
基于签发策略
认证用户输入证书
授权用于签发证书的服务器
如下构建结果证书
创建客户机引擎需要认证的
创建签发策略所允许的许可
授权许可签发
调用扩展以按需授权
产生许可
调用扩展以按需产生许可的一部分
构建作为许可的用户权限
签名所产生的证书
返回该证书
作为执行认证41、授权42和凭证格式化43功能的一部分,通用策略语言解析和实现引擎44可应用证书签发策略45。签发组件在要实现的策略不在引擎44中表达而在由引擎44在运行时间消费的签发策略45中表达的意义上,签发组件是数据驱动的。
尽管现有技术证书签发***在产生证书时应用并实现一策略,但该策略在现有技术签发器中可用证书签发***二进制码表达为经过编译的算法,或者表达为配置参数的经具体建模的“脆弱”集合。结果,改变该实现策略需要重新编码、重新编译、并重新使用新的证书签发***。换言之,所传送的签发器受限于实现证书签发***编程人员所预想的策略集。
证书签发引擎44应几乎不或不包括预想策略结构。相反,引擎44应包含元数据驱动策略实施引擎,该引擎兑现它在运行时间遭遇的来自45的特定策略数据。该策略数据45使用通用的为引擎44使用而设计的可扩展策略表达语言。
引擎44最好用单一的通用策略表达语言来操作,并基于45中的可用策略和数据作授权判定。通过在同类策略表达语言格式上执行该处理,引擎44的逻辑更简单更为有效,并可优化成选定的策略表达语言。通过数据驱动,引擎44可估算所表达策略的广泛范围,而不必改变引擎44的逻辑以容纳新的策略、语义或结构。如附图所示的引擎44包括用于解析和实现策略45的功能组件,以及用于产生证书的功能组件。引擎44所产生的证书的形式可由策略45以及签发策略的其它方面来管理。
用于表达策略45的策略表达语言可取各种各样形式的任一种。所使用语言可以是诸如可扩展标记语言(XML)、超文本标记语言(HTML)、或某些其它标记语言的标记语言。如本领域技术人员所理解的,可读字和标记的集可在这些语言中组合以精确地指定所需操作。诸如引擎44的机器进程可被配置成在运行时间消费该形式的文件并实现所需操作。设计用于本发明的任何策略表达语言应当是稳健的、可扩展的和灵活的,以按需容纳策略中的变化和语言语义的添加。标记指字符或其它符号的序列,它们可***文本或字处理文件中的某些地方以描述文档的逻辑结构。标记指示符常常称为“标签”。标记可通过键入符号或通过使用编辑器并选择预先打包的标记符号(来保存键击)而直接由文档创建者***。
XML是“可扩展”的,因为不像HTML,标记符号是非限制和自定义的。XML实际上是标准通用标记语言(SGML)的较简单和便于使用的子集,SGML是如何创建文档结构的标准。可预期HTML和XML将在许多Web应用程序中一起使用。例如,XML标记可在HTML页面内显现。这样,用于本发明的特定语法可包括标记语言的组合。
在图4中,引擎44应用以策略表达语言表达的并以数字格式存储的策略45。策略45可显现为一个或多个数字文件、或数据库、或任何其它存储的数据格式。本领域技术人员认为数字文件可转换成任何形式:其各方面可被***数据库的各个字段,或者文件可从一格式转换成另一格式。因而,尽管期望至少在开始时策略最好由人用文本编辑器可使用的数字格式,诸如通用文本(.txt)或文档(.doc)格式的文件来创建,但这种初始数字文件可在存储到45中之前转换成任意数量的形式。不管数据的格式如何,如果客户机有权得到所请求的证书,则在此表达的签发策略45必须由客户机40满足。策略45还可管理所产生证书的格式,即它可包括用于证书格式化的策略。
签发策略45最好由至少以下组成:
客户机认证要求
客户机授权要求
证书签发服务的授权要求
授权实现指令
为了再次将流行的MICROSOFT WINDOWSRights Management Server签发器用作证书签发***的示例,本领域技术人员认为该签发器可用来实现用于受保护文档和电子邮件的“信息权限管理”特征,例如MICROSOFTOffice 2003的信息权限管理特征。作为方案的一部分,WINDOWSRights Management Server的现有版本使用包括预想的硬编码的脆弱签发策略定义的签发器。只可实现固定的众所周知的签发策略集-例如:
什么是受信任的应用程序?
什么用户是具体排除的?
什么实体受信任来签发用户标识证书?
权限管理软件的什么版本必须由用户在其桌面上运行?
相反,WINDOWSRights Management Server的现有版本不能实现新的签发策略,诸如:
什么是受用户公司部门信任的应用程序?
哪类用户是具体排除的(例如其网络密码将在少于7天内过期的所有人)?
什么特定证书是证书签发***信任要产生的?
通过重新结构化WINDOWSRights Management证书签发服务的现有版本来实现在此所述的***和方法,产品可用灵活的策略表达语言来理解和实现策略,且无需更改所使用的签发器就可容纳以上列示的新签发策略以及任何其它可能签发策略。只有45中的表达策略需要进行改变。
证书签发***可发布其签发策略45以及可用签发证书格式集,以便于客户机40发现过程、辨析等。以下是为进行说明的一示例性签发策略:<r:license licenseId="f34e026a-836c-4557-97db-4368b3eddd14"xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS">
<r:title>RightsAccountCertificateIssuancePolicyRoot-Public</r:title>
<r:inventory>
<r:forAll licensePartId="LP0"varName="ValidityInterval">
<r:anXmlExpression>/r:validityInterval</r:anXmlExpression>
</r:forAll>
<r:forAll licensePartId="LP1"varName="AccountEncryptionPublicKey"/>
<r:keyHolder licensePartId="LP2">
<r:info>
<KeyNamexmlns="http://www.w3.org/2000/09/xmldsig#">RACIssuancePolicyRoot</KeyName>
<KeyValue xmlns="http://www.w3.org/2000/09/xmldsig#">
<RSAKeyValue><Modulus>rrREhbeyebCOsKWeVh7KSc6oFJj6zZX8vJQQDKWxpDjwm7EvbSSgwt/3/ZVN5QJa8vclZ061gkp5hRGCslVvJzSVs+duOcaz519uQXTCXft0tVuQkv7LCktbT5aKOpUuoDs26Hs/Vw4Cg4IJwbMAmyuAZ27o6ngd1LlVm7o/rr0=</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
</KeyValue>
</r:info>
</r:keyHolder>
<r:forAll licensePartId="LP3"varName="PrivateKey">
<r:anXmlExpression>/tm:privateKey/xkms:RSAKeyValue</r:anXmlExpression>
</r:forAll>
<r:forAll licensePartId="LP4"varName="Licensor">
<r:propertyPossessor>
<trustedLicensor xmlns="tm"/>
<r:trustedRootIssuers>
<r:keyHolder licensePartIdRef="LP2"/>
</r:trustedRootIssuers>
</r:propertyPossessor>
</r:forAll>
<r:forAll licensePartId="LP5"varName="SidPrincipal">
<r:anXmlExpression>/tm:sidPrincipal</r:anXmlExpression>
</r:forAll>
</r:inventory>
<r:grant>
<r:forAll licensePartIdRef="LP4"/>
<r:forAll licensePartIdRef="LP1"/>
<r:forAll licensepartIdRef="LP0"/>
<r:forAll varName="AccountInfo">
<r:anXmlExpression>/tm:account/tm:identity[@type="urn:msft:tm:identity:rfc822" andcontains("microsoft.com")]</r:anXmlExpression>
</r:forAll>
<r:principal varRef="Licensor"/>
<r:issue/>
<r:grant>
<r:keyHolder varRef="AccountEncryptionPublicKey"/>
<r:possessProperty/>
<account varRef="AccountInfo"xmlns="http://www.microsoft.com/DRM/XrML2/TM/v2"/>
<r:validityInterval varRef="ValidityInterval"/>
</r:grant>
<r:validityInterval>
<r:notBefore>2004-05-20T09:48:49Z</r:notBefore>
<r:notAfter>2004-05-20T09:48:49Z</r:notAfter>
</r:validityInterval></r:grant><r:grant>
<r:forAll licensePartIdRef="LP4"/>
<r:forAll licensePartIdRef="LP1"/>
<r:forAll licensePartIdRef="LP0"/>
<r:forAll varName="KeyUsageInfo">
<r:anXmlExpression>/tm:keyUsage[@uri="urn:msft:tm:keyUsage:encryption" or@uri="urn:msft:tm:keyUsage:signing"]</r:anXmlExpression>
</r:forAll>
<r:principal varRef="Licensor"/>
<r:issue/>
<r:grant>
<r:keyHolder varRef="AccountEncryptionPublicKey"/>
<r:possessProperty/>
<keyUsage varRef="KeyUsageInfo"xmlns="http://www.microsoft.com/DRM/XrML2/TM/v2"/>
<r:validityInterval varRef="ValidityInterval"/>
</r:grant></r:grant><r:grant>
<r:forAll licensePartIdRef="LP4"/>
<r:forAll licensePartIdRef="LP1"/>
<r:forAll licensePartIdRef="LP0"/>
<r:forAll varName="BindingPrincipalInfo">
<r:anXmlExpression>/tm:bindingPrincipals/r:allPrincipals/tm:sidPrincipal</r:anXmlExpression>
</r:forAll>
<r:principal varRef="Licensor"/>
<r:issue/>
<r:grant>
<r:keyHolder varRef="AccountEncryptionPublicKey"/>
<r:possessProperty/>
<bindingPrincipals varRef="BindingPrincipalInfo"xmlns=″http://www.microsoft.com/DRM/XrML2/TM/v2"/>
<r:validityInterval varRef="ValidityInterval"/>
</r:grant></r:grant><r:grant>
<r:forAll licensePartIdRef="LP4"/>
<r:forAll licensePartIdRef="LP1"/>
<r:forAll licensePartIdRef="LP0"/>
<r:forAll varName="CertificationPrincipalInfo"><r:anXmlExpression>/tm:ceerificationPrincipals/r:allPrincipals/tm:sidPrincipal</r:anXmlExpression>
</r:forAll>
<r:principal varRef="Licensor"/>
<r:issue/>
<r:grant>
<r:keyHolder varRef="AccountEncryptionPublicKey"/>
<r:possessProperty/>
<certificationPrincipals varRef="CertificationPrincipalInfo"xmlns="http://www.microsoft.com/DRM/XrML2/TM/v2"/>
<r:validityInterval varRef="ValidityInterval"/>
</r:grant>
</r:grant>
<r:grant>
<r:forAll licensePartIdRef="LP4"/>
<r:forAll licensePartIdRef="LP1"/>
<r:forAll licensePartIdRef="LP0"/>
<r:forAll varName="TrustedSecurityProcessor">
<r:propertyPossessor>
<trustedSecurityProcessor xmlns="tm"/>
<r:trustedRootIssuers>
<r:keyHolder licensePartIdRef="LP2"/>
</r:trustedRootIssuers>
</r:propertyPossessor>
</r:forAll>
<r:principal varRef="Licensor"/>
<r:issue/>
<r:grant>
<r:keyHolder varRef="TrustedSecurityProcessor"/>
<r:possessProperty/>
<holdsPrivateKey xmlns="http://www.microsoft.com/DRM/XrML2/TM/v2">
<r:keyHolder varRef="AccountEncryptionPublicKey"/>
</holdsPrivateKey>
<r:validityInterval varRef="ValidityInterval"/>
</r:grant>
</r:grant>
<r:grant>
<r:forAll licensePartIdRef="LP4"/>
<r:forAll licensePartIdRef="LP1"/>
<r:forAll licensePartIdRef="LP0"/>
<r:principal varRef="Licensor"/>
<r:issue/>
<r:grant>
<r:forAll varName="TrustedSecurityProcessor">
<r:propertyPossessor>
<trustedSecurityProcessor xmlns="tm"/>
<r:trustedRootIssuers>
<r:keyHolder licensePartIdRef="LP2"/>
</r:trustedRootIssuers>
</r:propertyPossessor>
</r:forAll>
<r:principal varRef="TrustedSecurityProcessor"/>
<receivePrivateKey xmlns="tm"/>
<r:keyHolder varRef="AccountEncryptionPublicKey"/>
<r:validityInterval varRef="ValidityInterval"/>
</r:grant>
</r:grant>
<r:grant>
<r:forAll licensePartIdRef="LP4"/>
<r:forAll licensePartIdRef="LP3"/>
<r:forAll licensePartIdRef="LP5"/>
<r:forAll licensePartIdRef="LP0"/>
<r:principal varRef="Licensor"/>
<r:issue/>
<r:grant>
<r:allPrincipals>
<sidPrincipal varRef="SidPrincipal"xmlns="http://www.microsoft.com/DRM/XrML2/TM/v2"/>
</r:allPrincipals>
<decryptWithPrivateKey xmlns="tm"/>
<privateKey varRef="PrivateKey"xmlns="http://www.microsoft.com/DRM/XrML2/TM/v2"/>
<r:validityInterval varRef="ValidityInterval"/>
</r:grant>
</r:grant>
<r:grant>
<r:forAll licensePartIdRef="LP4"/>
<r:forAll licensePartIdRef="LP3"/>
<r:forAll licensePartIdRef="LP5"/>
<r:forAll licensePartIdRef="LP0"/>
<r:principal varRef="Licensor"/>
<r:issue/>
<r:grant>
<r:allPrincipals>
<sidPrincipal varRef="SidPrincipal"xmlns="http://www.microsoft.com/DRM/XrML2/TM/v2"/>
</r:allPrincipals>
<signWithPrivateKey xmlns="tm"/>
<privateKey varRef="PrivateKey"xmlns="http://www.microsoft.com/DRM/XrML2/TM/v2"/>
<r:validityInterval varRef="ValidityInterval"/>
</r:grant>
</r:grant>
<r:issuer xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.microsoft.com/xrml/lwc14n"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-shal"/>
<Reference>
<Transforms>
<Transform Algorithm="urn:mpeg:mpeg21:2003:01-REL-R-NS:licenseTransform"/>
<Transform Algorithm="http://www.microsoft.com/xrml/lwc14n"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#shal"/>
<DigestValue>ZYG/bsCMxs5FhAT/atoXYGRuQ6Y=</DigestValue>
</Reference>
</SignedInfo><SignatureValue>Jd72Kt3h1fTYigxaYlrjaES+RLzmMZjr7bJBb9236GD7tty90zmZQxpYqTrA9D/qmrca5k84BGzefXodP8uLokDxUkpdXEI4aVurCDjP7cHwtOnZdMR5ATMvSgPn4kLHZ6E0g2pX7gjAm8jItvmD49Sa2D9CKjOtORq5zEkQMLc=</SignatureValue>
<KeyInfo>
<KeyValue>
<RSAKeyValue><Modulus>rrREhbeyebCOsKWeVh7KSc6oFJj6zZX8vJQQDKWxpDjwm7EvbSSgwt/3/ZVN5QJa8vclZ061gkp5hRGCslVvJzSVs+duOcaz519uQXTCXft0tVuQkv7LCktbT5aKOpUuoDs26Hs/Vw4Cg4IJwbMAmyuAZ27o6ngd1Ll Vm7o/rr0=</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
<r:details>
<r:timeOflssue>2004-05-20T09:48:49Z</r:timeOflssue>
</r:details>
</r:issuer>
<r:otherInfo>
<tm:infoTables xmlns:tm="http://www.microsoft.com/DRM/XrML2/TM/v2">
<tm:infoList tag="#LicenseType">
<tm:infoStr name="licenseRole">RightsAccountCertificateIssuancePolicy</tm:infoStr>
<tm:infoStr name="licenseVersion">1.0</tm:infoStr>
<tm:infoStrname="licenseType">RightsAccountCertificateIssuancePolicy-Public</tm:infoStr>
<tm:infoStr name="licensorUrl">http://rms.microsoft.com/rms/certification</tm:infoStr>
</tm:infoList>
</tm:info Tables>
</r:otherInfo></r:license>
图5示出一种***和方法,用于扩展签发组件以应用和实现策略表达语言和/或策略语言解析和实现引擎56不会自然支持的新签发策略。当策略语言语法通过组合附加数据59和签发策略数据58而得到扩展时,处理扩展后策略表达语言结构的语义的插件逻辑55可被添加到实现引擎56中。当例如通过将通配符替代模式数据60添加到签发策略数据58来使用自然策略语言通配符时,处理扩展通配符替换模式60的插件逻辑57可被添加到实现引擎56中。
数据驱动的策略评估引擎56可被设计成预测它不理解或不打算处理的证书的语义。这些证书语义的可扩展性机制可被呈现,从而可询问用于该证书的诸如55或57的定制逻辑,以用良好定义的方式来提供值、执行定制处理、或以其它方式处理未知语义。该处理的结果可反馈到策略估算引擎56中并可能影响确定对证书权利的最终结果。
估计至少有两种机制可用于扩展签发组件。首先通过在上面建立可扩展策略表达语言(例如发挥XML可扩展性的语言),并提供适当的诸如55的插件机制,证书签发***可支持对其客户的定制可扩展性。其次,通过将通配符替换模式的概念包括在其策略表达语言中并提供诸如57的适当插件机制,签发器可支持对其客户的定制可扩展性。
从用于扩展签发组件的第一所述选项开始,策略表达语言语法在较佳实施例中是可扩展的,策略实现引擎56可预先配置成“知道”如何兑现策略表达语言的原始方面的语义含义。然而,如果策略表达语言的语义得到扩展,则必须也扩展引擎56。
策略表达语言的扩展可在引擎56可访问的数字数据59中陈述。这种扩展可表现为一个或多个文件、或数据库、或任何其它已存储的数据格式。尽管扩展最好由人用文本编辑器可使用的格式,诸如通用文本(.txt)或文档(.doc)格式的文件来创建,但这种初始文件可在存储之前转换成任意数量的形式。不管数据的格式如何,在此表达的签发策略扩展59可由定制逻辑55访问,以使用扩展后的策略表达语法59来应用并实现所表达策略。
为了完成它,引擎56可被配置成允许诸如55的扩展后逻辑(“插件”)进行登记。插件55可提供对策略表达语言的任何新语法扩展59的语义支持。因而非预期的客户要求无需检查引擎56本身或策略表达语言的原始使用语法就可得到解决。策略表达语言被理想地设计成语法支持扩展。
一示例可有助于阐明使用插件55的引擎的可扩展性。假设证书签发***与包含表示用户PKI身份的元素的XML策略表达语言一起发送……可能它看起来如下所示:
<user>
<name>George Washington</name>
<publickey>1234567890</publickey>
</user>
证书签发***可能想要扩展用户的概念,以包括用户的企业低权重目录访问协议(LDAP)身份。包括LDAP语法的策略语言扩展可在需要时用对证书签发***数据库执行LDAP查询的代码来支持。在该情形中,扩展后的策略语言结构看起来如下所示:
<user>
<name>George Washington</name>
<publickey>1234567890</publickey>
<extension:ldapid>georgewashington</extension:ldapid>
</user>
此外,称为插件55的用LDAP查询校验用户的代码将进行编码,并向证书签发***进行登记。该插件55将在遇到扩展后策略表达语言语法时由引擎56调用。注意,在某些实施例中,使用扩展后语法而不登记插件是可能的。这可通过将***的扩展后语法添加到输入/输出证书以及由引擎揭示的签发策略中来完成。
现在参看用于扩展签发组件的第二部分,所使用的策略表达语言可包括通配符替代参数。通配符替代参数可在原始签发策略58中陈述,或者通过使附加数据60可用于补充原始策略58来添加到策略中。
通配符替换模式60可表现为一个或多个文件、或数据库、或任何其它已存储的数据格式。尽管初始替换模式最好由人用文本编辑器可使用的格式,诸如通用文本(.txt)或文档(.doc)格式的文件来创建,但这种初始文件可在存储到60中之前转换成任意数量的形式。不管数据的格式如何,在此表达的通配符替换模式60可由定制逻辑57访问,以使用定制逻辑57指示的方式来应用并实现通配符。
如果策略表达语言包括其语法内的通配符定义60,且引擎56提供一机制来登记选择特定所需值的定制逻辑57,则这向证书签发***提供可扩展性的另一途径。
再一次,一示例可有助于阐明。示例性证书签发***可包含定义已签发格式的策略。例如,服务可包含表述服务可向客户机签发“受信任雇员证书”的证书签发策略。因为签发者必须对客户机的动态世界作出响应,通配符证书签发策略可被结构化为:
证书签发***可向它认为适当的任何客户机签发“受信任雇员证书”。
然后证书签发***所有人可定义并登记例如57的逻辑,它填入客户机“认为适当”的说明书中。逻辑57可确定在特定服务调用期间应向哪些客户机签发“受信任雇员证书”。该理解57可在遇到证书签发策略中更一般的通配符定义从句时由证书签发***来调用。
按照可根据图1和2中提供的一般框架建立的不同计算环境,在此提供的***和方法不能解释为以任何方式受限于特定计算框架。相反,本发明不应解释为限于任何单个实施例,而相反应根据所附权利要求在宽度和范围内进行解释。