GBT27913-2011用于金融服务的公钥基础设施实施和策略框架.pdf 90页

'lCS35．240．40A11囝雷中华人民共和国国家标准GB／T27913—2011用于金融服务的公钥基础设施2011-12-30发布实施和策略框架Publickeyinfrastructureforfinancialservices——Practicesandpolicyframework(IS021188：2006，MOD)2012-02-01实施丰瞀髁紫瓣訾雠赞星发布中国国家标准化管理委员会捉19， 标准分享网www.bzfxw.com免费下载前言⋯⋯⋯⋯⋯⋯⋯一引言⋯···⋯⋯⋯⋯⋯··1范围⋯⋯⋯⋯⋯⋯2规范性引用文件⋯3术语和定义⋯⋯⋯4缩略语⋯⋯⋯⋯⋯5公钥基础设施(PKI)5．1概述⋯⋯⋯⋯5．2PKI简介⋯⋯目次5．3商业要求对PKI环境的影响⋯⋯⋯⋯··5．4功能⋯⋯·⋯·⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯5．5商业视角⋯·····⋯⋯·⋯⋯⋯⋯⋯·⋯⋯⋯·5．6证书策略(cP)⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一5．7认证业务说明(CPS)⋯⋯⋯⋯⋯⋯⋯⋯··5．8证书策略和认证业务说明间的关系⋯·····5．9协议··⋯⋯·⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯··5．10时间戳⋯⋯⋯·⋯⋯⋯⋯⋯···⋯⋯⋯⋯·6证书策略和认证业务说明要求⋯⋯⋯⋯⋯⋯··6．1证书策略(CP)⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一6．2认证业务说明(CPS)⋯⋯⋯⋯⋯·⋯⋯⋯-7认证机构控制目标⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一7．1概述⋯⋯⋯······⋯⋯⋯⋯⋯⋯⋯·⋯⋯⋯·7．2CA环境控制目标⋯⋯⋯⋯⋯⋯⋯⋯⋯··7．3CA密钥生命周期管理控制目标⋯⋯⋯··7．4主体密钥生命周期管理控制目标⋯··⋯⋯7．5证书生命周期管理控制目标··⋯⋯·⋯⋯“7．6CA证书生命周期管理控制⋯⋯⋯⋯⋯·一8认证机构控制程序⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·-8．1概述⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯“8．2cA环境控制⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯“8．3CA密钥生命周期管理控制⋯⋯⋯⋯⋯··8．4主体密钥生命周期管理控制⋯⋯⋯⋯·····8．5证书生命周期管理控制⋯⋯⋯⋯⋯⋯⋯·一8．6CA证书生命周期管理控制⋯⋯⋯⋯⋯·附录A(资料性附录)根据证书策略进行管理·A．1证书策略引言和目的⋯⋯⋯·⋯·⋯⋯．．GB／T27913—2011ⅢⅣ，●o00，№M"协加nn驼黔髂孔筋筋孙凹船鹅凹如∞∞蛆“蛆弘％ 标准分享网www.bzfxw.com免费下载GB／T27913—2011A．2A．3A．4A．5A．6A．7A．8A．9证书策略的定义一在证书内建立策略命名的证书策略下的证书适用性··⋯··交叉认证，证书链、策略映射和证书策略证书类型⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·⋯证书分类和命名证书策略规定证书策略管理附录B(资料性附录)B．1概述⋯⋯⋯B．2引言⋯⋯⋯B．3一般规定···B．4认证与鉴别B．5操作要求···认证业务说明的要素B．6物理的、程序性的和人员的安全控制B．7技术上的安全控制⋯⋯⋯⋯⋯⋯-·B．8证书和CRL框架⋯⋯⋯⋯⋯⋯⋯··B．9实施管理⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·一6668697172附录C(资料性附录)对象标识符(oID)⋯⋯⋯⋯⋯⋯⋯⋯⋯··⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·74C．1为什么有OlD⋯··⋯⋯·········⋯⋯⋯⋯⋯····⋯⋯⋯⋯·⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．74C．2什么是0ID⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯74C．3OID的注册⋯⋯⋯····⋯··⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯74c．4为什么需要OID并且如何对它们进行管理⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯75附录D(资料性附录)CA密钥生成过程⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯76D．1概述·⋯⋯⋯····⋯·⋯⋯⋯⋯⋯⋯⋯·⋯··⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯76D．2角色和责任⋯·⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一76D．3CA密钥生成过程脚本⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯77D．4cA密钥生成过程程序⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯·⋯⋯⋯··⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯77附录E(资料性附录)将RFC2527映射到RFC3647⋯·⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯“79参考文献⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯85Ⅱ弱弘卯w驱始∞缸眈舵∞够¨ 标准分享网www.bzfxw.com免费下载刖罱GB／T27913—2011本标准按照GB／T1．1—2009给出的规则起草。本标准修改采用ISO21188：2006《用于金融服务的公钥基础设施实施和策略框架》(英文版)。本标准与ISO21188：2006的技术性差异为：a)删除第4章中FIPS缩略语；b)删除缩略语PKIX，该缩略语在正文中没有出现；c)删除8．3．2中FJPS】40—2的引用；d)删除8．4．3中FIPSl40—2的引用；e)删除8．4．4中FIPSl40—2的引用；f)删除B．7．3中FIPSl40—2的引用；g)删除B．7．9中FIPSl40—2的引用；h)删除参考文献中FIPS的引用。对于Is021188做了下列编辑性修改：a)“本国际标准”改为“本标准”；b)删除国际标准前言。本标准由中国人民银行提出。本标准由全国金融标准化技术委员会(SAC／TC180)归口。本标准负责起草单位：中国金融电子化公司。本标准参加起草单位：中国人民银行、中国银行、中国工商银行、中国银联股份有限公司、中国科学院软件研究所、中国人民银行兴化中心支行。本标准主要起草人：王平娃、陆书春、李曙光、仲志辉、张凡、贾树辉、赵志兰、景芸、刘运、冉平、王治纲、周燕媚。Ⅲ 标准分享网www.bzfxw.com免费下载GB／T27913—2011引言随着金融服务业对互联网技术应用的不断扩大，金融行业对提供安全的、机密的和可信赖的金融交易及处理系统方面的需求不断增长，从而导致了先进安全技术与公钥密码学的结合。公钥密码学需要业务优化的技术、管理和策略基础设施(本文中定义为公钥基础设施或PKI)来满足金融应用系统中电子标识、鉴别、报文完整性保护和授权的要求。PKI中电子标识、鉴别和授权标准的应用进一步确保了系统安全的一致性、可预测性和电子交易的可信任性。数字签名和PKI技术可用于开发金融服务业的应用。这些应用的安全和有效性部分依赖于确保基础设施整体完整性的实践。对于将个人身份与其他实体和密钥要素(如密钥)关联起来的基于授权的系统，其用户可以从标准的风险管理系统和本标准定义的可审计业务基础中受益。国际标准化组织TC68技术委员会的成员已经通过制定数字签名、密钥管理、证书管理和数据加密的技术标准和指南确定了公钥技术。IsO15782第1和第2部分定义了供金融业使用的证书管理系统，但没有包括证书策略和认证业务要求。本标准制定了通过证书策略、认证业务说明、控制目标和控制程序来管理PKI的框架，对ISO15782第1和第2部分进行补充。对这些标准的实现者来说，金融交易中的实体可以依赖PKI标准实现的程度以及使用这些国际标准达到的PKI间的互操作的程度，都将部分依赖于本标准中定义的与策略和实施相关的因素。Ⅳ 标准分享网www.bzfxw.com免费下载1范围用于金融服务的公钥基础设施实施和策略框架6B／T27913—2011本标准规定了通过证书策略和认证业务说明对PKI进行管理，以及将公钥证书用于金融服务行业的要求框架。同时也定义了风险管理的控制目标和控制程序。本标准适用于开放、封闭和契约环境中的PKI系统进行区分，并且根据金融服务行业信息系统控制目标进一步定义了运行的业务。本标准的目的在于帮助实施者定义支持多证书策略的PKI业务，包括数字签名、远程鉴别和数字加密的使用。本标准使得契约环境中满足金融服务行业要求且基于PKI控制的业务的可操作性更易于实现。尽管本标准主要针对契约环境，但并不排除将文档应用于其他环境。文档中术语“证书”是指公钥证书。属性证书不在本标准范围之内。本标准的目标是针对不同需求的多种使用者，因此每类使用者会关注不同的内容。业务管理者和分析者是那些需要在开展的业务中使用PKI技术的人员，应关注第1～第6章。技术设计者和实现者是鄂些编写他们的证书策略和认证业务说明的人员，应关注第6～第8章，以及附录At附录F。运行管理和审计者是那些负责PKI系统日常运行并根据本标准进行一致性检查的人员，应关注第6～第8章。2规范性引用文件下列文件对于本文件的应用是比不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。GB13000．1信息技术通用多八位编码字符集(UCS)第一部分；体系结构与基本多文种平面(GB13000．1—1993，idt，ISO／IEC10646—1：1993)GB／T14916识别卡物理特性(GB／T14916—2006，Is0／IEC7810：2003，IDT)GB／T15120(所有部分)识别卡记录技术(GB／T15120．1～15120．5—1994，idt，IsO7811—1～7811—5：1985)GB／T16264．8—2005信息技术开放系统互连目录第8部分：公钥和属性证书框架(ISO／IEC9594—8：2001，IDT)GB／T16649．1识别卡带触点的集成电路卡第1部分；物理特性(GB／T16649．1—2006，ISO／IEC7816—1：1998，MOD)GB／T16649．2识别卡带触点的集成电路卡第2部分：触点的尺寸和位置(GB／T16649．2--2006，ISCl／IEC7816—2；1999，IDT)GB／T16649．3识别卡带触点的集成电路卡第3部分：电信号和传输协议(GB／T16649．3--2006，ISO／IEC7816-3：1997，IDT)GB／T16649．5识别卡带触点的集戒电路卡第5部分：应用标识符的国家编号体系和注册规程(GB／T16649．5—2002，ISO／IEC7816—5；1994，NEQ)GB／T16649．6识别卡带触点的集成电路卡第6部分：行业间数据元(GB／T16649．6—1 标准分享网www.bzfxw.com免费下载GB／T27913—20”2001，ISO／IEC7816—6：1996，IDT)16649．7识别卡带触点的集成电路卡第7部分：用于结构化卡查询语言(SCQL)的行业间命令(GB／T16649．7—2000，lSO／IEC7816—7：1999，IDT)16649．8识别卡带触点的集成电路卡第8部分：与安全相关的行业间命令(GB／T16649．82002，ISO／IEC78168：1999，IDT)16649．10识别卡带触点的集成电路卡第10部分：同步卡的电信号和复位应答(GB／T16649．10—2002，ISO／IEC7816-10：1999，IDT)16790．1金融交易卡使用集成电路卡的金融交易系统的安全结构第1部分：卡的生命周期(GB／T16790．1—1997，idt，ISO10202—1：1991)16790．5金融交易卡使用集成电路卡的金融交易系统的安全体系第5部分：算法应用(GB／T16790．5—2006，ISO10202—5：1998，IDT)16790．6金融交易卡使用集成电路卡的金融交易系统的安全体系第6部分：持卡人身份验证(GB／T16790．6—2006，ISO10202—6：1994，IDT)16790．7金融交易卡使用集成电路卡的金融交易系统的安全体系第7部分：密钥管理(GB／T16790，7—2006。ISO10202—7：1998，IDT)17552信息技术识别卡金融交易卡(GB／T17552--2008，Iso／IEc7813：2006，IDT)17969．1—2000信息技术开放系统互连OSI登记机构的操作规程第l部分：一般规程(ISO／IEC9834—1：1993，EQV)18336(所有部分)信息技术安全技术信息技术安全性评估准则(GB／T18336．1～18336．3—200l，ISO／IEC15408—1～15408—3：1999，IDT)19716信息技术信息安全管理实用规则(GB／T19716--2005，IsO／IEc17799：2000，MoD)21077．2银行业务证书管理第2部分：证书扩展项(GB／T21077．2—2007，ISO15782—2：2001，MOD)ISO／IEC7816—4信息技术识别卡带触点的集成电路卡第4部分：行业问交换指令(Identi—ficationcards--Integratedcircuitcards～Part4：Organization，securityandcommandsforinter—change)IsO／1Ec7816-9识别卡带触点的集成电路卡第9部分：附加行业间命令和安全属性(Identi—ficationcards--Integratedcircuitcards—Part91Commandsforcardmanagement)IsO／IEc7816—11识别卡集成电路卡第11部分：通过生物特征的个人认证(Identificationcards--Integratedcircuitcards—Part11：Personalverificationthroughbiometricmethods)IsO／IEc7816—12识别卡集成电路卡第12部分；USB电气接口和操作规程(Identificationcards--Integratedcircuitcards—Part12：Cardswithcontacts--USBelectricalinterfaceandoperatingprocedures)ISO／IEC7816—15识别卡带触点的集成电路卡第15部分：密码信息的应用(Identificationcards--IntegratedcircuitcardsPart15：Cryptographicinformationapplication)IsO10202—2金融交易卡使用集成电路卡的金融交易系统的安全结构第2部分：交易处理(Financialtransactioncards--Securityarchitectureoffinancialtransactionsystemsusingintegratedcircuitcards—Part21Transactionprocess)ISO102023金融交易卡使用集成电路卡的金融交易系统的安全结构第3部分：加密密钥(Financialtransactioncards--Securityarchitectureoffinancialtransactionsystemsusingintegratedcircuitcards—Pan3：Cryptographickeyrelationships)ISO10202—4金融交易卡使用集成电路卡的金融交易系统的安全结构第4部分：安全应用模2 标准分享网www.bzfxw.com免费下载块(Financialtransactioncards--Securityarchitectureoffinancialtransactionsystemsusingintegratedcircuitcards—Part41Secureapplicationmodules)ISO10202—8金融交易卡使用集成电路卡的金融交易系统的安全结构第8部分：通用原则及概述(Financialtransactioncards—Securityarchitectureoffinancialtransactionsystemsusingintegrat—edcircuitcards--Part8：Generalprinciplesandoverview)ISO15782—1：2003金融服务的证书管理第1部分公钥证书(Certificatemanagementforfi—nancialservicesPart1：Publickeycertificates)ISO18014—2信息技术安全技术时间戳服务第2部分生成独立令牌的机制(Informationtechnology--SecuritytechniquesTime—stampingservicesPart2：Mechanismsproducingindependenttokens)1SO18014-3信息技术安全技术时间戳服务第3部分生成链接令牌的机制(Informationtechnology--SecuritytechniquesTime-stampingservices--Part3：Mechanismsproducinglinkedtokens)IsO／IEc18032信息技术安全技术素数的生成(InformationtechnologySecuritytech—niques--Primenumbergeneration)ISO／IECl8033．1～18033．4信息技术安全技术加密算法(InformationtechnologySecuritytechniquesEneryptionalgorithms(parts1to4))3术语和定义以下术语和定义适用于本文件。3．1激活数据activationdata除密钥外的用于操作密码模块的数据，该数据需要受到保护(如PIN、通行字、生物特征或手工持有的共享密钥部分)。3．2鉴别authentication对个体所声明的身份的验证：a)注册时，评估终端实体(如用户)的凭证以证明其所声称的身份的行为；b)使用期间，将电子形式提交的身份和凭证(如用户ID和口令)与存储值进行比较以证明其身份的行为。3．3鉴别数据authenticationdata用于验证实体所声称的身份的信息，例如个人、定义的角色、公司或机构。3．4发卡方cardbureau将包含(至少包含)用户私钥的Ic卡(3．32)进行个人化的CA(3．18)或RA(3．46)代理。3．5持卡人cardholder集成电路卡的所有者，卡中包含公私密钥对，并且证书(3．6)已经签发。3．6证书certificate公钥和实体身份以及其他信息，采用签发公钥证书的认证机构的私钥对证书信息进行签名 标准分享网www.bzfxw.com免费下载GB／T27913—2011可伪造。3．7证书挂起certificatehold；certificatesuspension暂停证书(3．6)的有效性。3．8证书签发者certificateissuer(CI)名称出现在证书(3．6)签发者字段的机构。3．9证书生成者certificatemanufacturer代表证书签发者对证书签署请求进行数字签名的机构。3．10证书簧略certificatepolicy(CP)命名的一组规则，指明证书对特定团体和／或具有通用安全要求的应用的适用性。3．11证书框架certificateprofile规定特定类型证书(3．6)所需的格式(包括使用标准域和扩展域的要求)。3．12证书密钥更新certificatere-key已经拥有密钥对和证书的实体在生成新的密钥对后获得新的公钥证书的过程。3．13证书更新certificaterenewal；rollover为实体已有证书签发一个具有新的有效期的实例的过程。3．14证书撤销列表certificaterevocationlist(CRL)已撤销的证书(3．6)的列表。3．15证书确认服务certificatevalidationservice由CA(3．18)或其代理向信任方提供的确认证书有效性的服务。3．16证书确认服务提供者certificatevalidationserviceprovider(CVSP)向其信任方用户提供证书确认服务的实体。3．17认证certification为实体创建公钥证书的过程。3．18认证机构certificationauthority(cA)一个或多个实体所信任的机构，负责生成、分配、撤销或挂起公钥证书。3．19认证路径certificationpath实体证书的有序序列，通过处理该有序序列及其初始实体的公钥从而获得该路径上最终实体的公钥。 标准分享网www.bzfxw.com免费下载GB／T27913—2013．2U认证业务说明certificationpracticestatement(CPS)认证机构在颁发证书时采用的业务说明，它定义了CA为满足由它支持的证书策略的要求而采用的设备、策略和过程。3．21认证请求certificationrequest由RA(3．46)、代理或主体向CA提交的有效注册请求，请求将一个主体的公钥进行注册并置于证书当中。3．22认证响应certificationresponse在认证之后，由CA发送的对证书请求进行响应的报文。3．23证书有效性certificatevalidity有效性validity证书的适用性(对特定用途的适用性)和状态(有效、挂起、撤销或过期)。324泄密compromise破坏系统安全，可能发生敏感信息未经授权的泄露。3．25交叉认证crosscertification两个CA互相证明彼此的公钥的过程。注：该过程可以是自动化的，也可以不是。3．26密码硬件cryptographichardware密码设备cryptographicdevice硬件安全模块hardwaresecuritymodule硬件密码模块。3．27数字签名digitalsignature数据加密转换方式，当与数据单元关联时．可以提供数据源鉴别和数据完整性的服务，并可支持签名者的不可否认性。3．28终端实体endentity不以签署证书为目的而使用其私钥的证书主体。3．29实体entityCA(3．18)、RA(3．46)或者终端实体(3．28)。3．30事件日志eventjournal审计日志auditjournal／auditlog按时间顺序记载系统活动的记录。该记录能够用来重建、复审和检查从开始到最终结果输出期间在事务路径上围绕每一事件的环境或产生及的活动序列。 GB／T27913—2011331功能测试functionaltesting安全测试的一部分，测试所声称的系统属性运行正确。3．32集成电路卡integratedcircuitcardIC卡内部封装一个或多个集成电路用于执行处理和存储功能的卡片。3．33签发认证机构issuingcertificationauthority签发CAissuingCA在特定证书的环境中签发证书的CA。3．34密钥托管keyescrow允许授权方访问用于机密性的私钥副本的管理功能。注：这可以是一项法定要求，允许法律强制机构获得对实体或CA的用于机密性的私钥的访问。3．35密钥恢复keyrecovery在密钥丢失、损坏或其他不可用的情况下，从安全存储中恢复实体的私钥或对称加密密钥的能力。3．36多重控制multiplecontrol是这样一种情况，独立的两方或多方分别机密地保存一个密钥的各个组件，并且各自无法独立合成整个密钥。3．37对象标识符objectidentifier(OLD)惟一的整数序列，无歧义地标识一个信息对象。3．38在线证书状态机制onlinecertificatestatusmechanism允许信任方(3．49)请求并获得证书状态信息的机制，而无需请求使用CRL(3．14)。3．39在线证书状态协议onlinecertificatestatusprotocol(OCSP)确定证书当前状态的协议，替代或作为对周期性CRI。进行检查的补充，规定了在检查证书状态的应用程序和提供状态信息的服务器之间需要交换的数据。3．40工作周期operatingperiod证书的周期，从CA签发的日期和时间(或者，在证书中注明的一个稍后的日期时间)开始，终止于到期的日期和时间或证书被撤销的日期和时间。3．41PKI揭示说明PKIdisclosurestatement(PDS)CP(3．10)或CPS(3．20)的补充文件，揭示关于CA(3．18)、PKI(3．45)策略和实施的关键信息。注：PKI揭示说明是揭示和强调通常在相关CP和／或CPS中已经包含的详细内容的信息。因此，PDS并不是要取代CP或CPS。3．42策略机构policyauthority(PA)拥有最终权威和职责的实体，规定证书策略并根据CPS的定义确保CA实施和控制能够完全支持6 GB／T27913—2011所规定的证书策略。3．43策略映射policymapping策略映射标识或表明，当一个信任域内的CA认证另一个域内的CA时，可以认为第二个域内的一个特定证书策略与第一个域的一个特定证书策略等价(但并不需要在所有方面相同)。注：见3．25，交叉认证。3．44策略限定符policyqualifier由策略决定的信息，在x．509证书中附有证书策略标识符。3．45公钥基础设施publickeyinfrastructure(PKI)硬件、软件、人员、过程和策略的集合，采用数字签名技术提供一个公私钥对中公钥部分和拥有相应私钥的用户间的可证实的关系。注；公钥可提供用来进行数字签名验证，在通信对话中进行主体鉴别，和／或报文加密密钥交换或协商。3．46注册机构registrationauthority(RA)负责标识和鉴别主体身份的实体，但不是CA，因此并不签署或颁发证书。注：RA可辅助证书申请处理或撤销处理，或两者。RA无需是一个分离的实体，可以是CA的一部分。3．47注册请求registrationrequest由实体提交给RA或CA的申请，请求在证书中注册实体的公钥。3．48注册响应registrationresponse由RA或CA发送给实体的报文，以响应注册请求。3．49信任方relyingparty(RP)证书的接受方，其行为依赖于该证书或使用该证书进行数字签名认证。3．50资料库repository存储或分发证书及相关信息的系统(如：证书存储、证书分发、证书策略存储和检索、证书状态等)。3．51根CArootCA位于CA层次结构或树状结构PKI顶点的CA。3．52签名验证signatureverification(对于一个数字签名)准确判定：a)数字签名是在证书的有效期内由证书内公钥相对应的私钥所生成的；b)自从数字签名生成后被签名报文未经过修改。3．53主体SUbject其公钥被签发了证书的实体。3．54主体CASUbjectCA其公钥被签发CA签发了证书的CA，因此它遵循签发CA的证书策略。7 GB／T27913—2013．55主体终端实体subjectendentity是一个证书主体的终端实体。3．56从属CAsubordinateCA；sub-CACA分层结构或树状PKI结构中相对另一CA较低的CA，即在该结构中是另一个CA的下级CA。3．57用户subscriber代表一个或多个主体向认证机构就相关公钥认证服务进行定购的实体。3．58上级CAsuperiorCA在CA分层结构中相对另一CA(从属CA)较高的cA，但不是根CA。3．59篡改证据tamperevident拥有能够提供证据证明已经有攻击发生的特性。3．60抗篡改tamperresistant拥有能够提供被动物理保护来抵御攻击的特性。3．61可信角色trustedrole执行关键功能的工作职位。如果关键功能不能满意地执行，可能对CA提供的信任程度有不利影响。3．62信任服务提供者trustservicesprovider(TSP)通过许多认证机构向他们的用户(用户或信任方)提供信任服务的核准机构(由合同各方确定)。注：信任服务提供者也可提供证书确认服务。3．63确认服务请求validationservicerequest信任方向验证服务提出询问以检查证书的有效性。抽象语法记法1认证机构证书签发者证书生成者证书策略认证业务说明证书撤销列表证书确认服务提供者欧洲信用卡、万事达卡、维萨卡金融机构文件传输协议攀黧赫裂至薰篆槲m呲mmm渤渤l；；㈨h嘶叭帅呲哪叭叭叭Ⅲm№一掣a拳菡篱：；4 硬件安全模块超文本传输协议集成电路卡标识符国际电工委员会Internet工程任务组国际标准化组织国际电信联盟轻量级目录访问协议报文鉴别码在线证书状态协议对象标识符策略机构个人识别码公钥基础设施注册机构请求评论信任方安全套接层传输层安全时间戳机构信任服务提供者可信第三方统一资源定位器5公钥基础设施(PKI)5．1概述GB／T27913—2011在重点介绍PKI策略和实施要求的细节之前，本标准提供一些背景信息来帮助读者更好地理解在PKI内使用的策略和实施之间的关系。5．2PKI简介本条描述了PKI的组件并阐述了PKI内各种实体所承担的角色。电子商务的快速发展产生了通过开放式网络(如Internet)处理企业与企业、企业与消费者和政府与消费者之间的交易活动的要求。网络通信协议的设计对于金融机构及其进行业务交易的用户来说产生了很多问题，他们需要电子身份标识、交易方鉴别、源证明、报文完整性保护和保密性服务。电子鉴别也产生了与证据、合同、义务、隐私、消费者保护和交易等相关的重要问题。PKl是解决这些开放式网络问题的实际技术方案。金融机构正在成为采用在线通信安全和鉴别市场的信任服务提供者(TSP)。信任方作为信息的接收者使用TSP来验证用于鉴别在线通信的证书。TSP是被一个或多个信任方信任的用来生成和签署证书的公认权威。TSP也可以撤销他生成和签署的证书。一个TSP运行一个或多个认证机构，这些证书认证机构的核心功能是证书的签发、生成和证书确认。在金融机构内，CA不必是一个商业实体，可以是一个单位或功能，提供可被信任方及其用户信任的cA功能。～～一一～一一～一～一一一一一一～一～一一～一～哪一叶D，J阱∞叫姒眦姗加强州w认矾计飘|刍认唧m觚m阴阱m眦一㈨刖吼心懈∞队刚Ⅲ队眦即蛆|刍姒僻哪㈣ GB／T27913—201公钥技术用于支持机密-性、完整性和真实性要求。通过公钥密码算法可以生成两个密钥(私钥和公钥)。私钥秘密持有，而公钥被签发了证书并位于证书中，因此可以以能够保护公钥真实性的证书形式公开。主体的公钥和鉴别数据用CA的私钥签名后形成证书。证书是根据证书策略生成的。公钥的公开并不会泄露私钥。金融机构可使用PKI在以下环境中根据与信任方之间的关系来服务于他们的商业需求。表1到表3提供了每一种环境的示例。a)封闭环境：所有实体(证书主体和信任方)依附于”单个金融机构的信任服务，必须至少共享一个证书策略。见图l和表1；b)契约环境：证书主体和信任方可具有不同的TSP。TSP通过包含证书使用的不同契约形式联系在一起。这些形式包括：1)在协定的规则下，使用单个证书策略的多边形式；2)町使用不同证书策略的双边交叉认证形式；3)通过中心机构或实体可识别不同证书策略的鉴定桥形式。见图2和表2。c)开放环境：金融机构可作为TSP向公众签发证书并允许在一个开放的网络环境中进行证书确认。TSP可在自愿的TSP的鉴定方案下或在本国规章制度内运行。典型的情况下，用户的TSP和信任方之间不存在正式的合同。见图3、表3和表4。PKl由技术、程序和人员部分组成，必须在一个有效的基础设施内协调。对于任何基础设施，商业要求必须最初进行确定。这些要求在部署PKI时实现。5．3商业要求对PKI环境的影响5．3．1概述本条根据商业背景来阐述封闭、开放和契约环境的主要区别。表1～表3描述了典型的商业背景、示例的安全要求，以及如果采用PKI处理这些要求时将执行的相关PKI操作。5．3．2封闭环境中证书应用的说明本条描述了几种背景，金融机构可使用PKl支持其服务，进行内部通信或与客户之间的通信。金融机构认证机构用户和／证书主体或职员图1封闭环境中的两个实体1)依附于一个信任服务的实体可代表自己或代表其他证书主体以证书依赖方或证书用户的身份工作。在这种情况下，用户和证书主体可以是通过业务关系联系在一起的不同的实体，这不在本标准的范围之内。lO 表1封闭环境中的证书应用环境GB／T27913—2011典型情景范例要求PKI操作金融机掏(FI)向用户发送电·为接收方鉴别发送方；·发送方产生数字签名；L·为发送方和接收方保证报·接收方验证发送方证书；子邮件(如利率变化的通知)文完整性·接收方验证数字签名·接收方验证发送方的证书；·为接收方鉴别发送方；·发送方产生数字签名；在F1的网络范围内雇员间交·为发送方和接收方保证报·接收方验证数字签名；2换敏感电子邮件文完整性；·发送方从目录中取得接收方的证书；·保护报文内容的机密性·发送方用接收方的公钥加密报文；·接收方用自己的私钥解密报文使用FI笔记本电脑的旅行销·FI对雇员和雇员对服务器·准备雇员的身份证书；3售人员需要与集中支持系统交的相互鉴别；·准备服务器ID证书；·调用SSL加密；换用户和销售信息·保护数据的机密性·调用SSL加密向面对用户的设备进行FI软件·证明准备加载到设备内部·FI对软件应用程序进行数字签名；4·接收方验证数字签名；的内部网络分发(如ATM软件)的软件有一个可信的来源·接收方确认FI的证书·用户使用客户证书向服务器进行用户使用远程银行服务，其中·Fl对客户，用户软件对服鉴别；5务器的相互鉴别；·服务器使用服务器证书向用户进行服务器和浏览器由FI提供·保护用户数据的机密性鉴别；·调用SSL加密5．3．3契约环境中证书应用的说明本条描述r在一个方案内或在各方间建立的规则契约内使用PKI来支持与用户交易的情况。它将向其用户提供证书签发或证书确认服务。金融机构#1图2契约环境中的四个实体金融机构#2 GB／T27913—201表2契约环境中的证书应用环境典型情景范例要求PKI操作·接收方验证发送方的证书：FI的雇员通过Internet向使·为接收方鉴别发送方；·用户检查数字签名；】用另一个TSP的用户发送电子·保证报文完整性；·发送方从目录中取得接收力的证书；邮件·保护报文内容的机密性·发送方用接收方的公钥加密报文；·接收方用自己的耘钥解密报文·顾客批准订单；·顾客使用证书对订单数字签名．证2顾客向商户提交购买订单·商户对用户顾客进行鉴别；明被委托的支付授权；·接收方验证发送方证书；·交易报文完整性·商户验证数字签名l顾客从商户接收发货单·报文鉴别·验证数字签名并对证B进行确认·用户验证FI的服务器证书；·FT验证用户的证书；已有的用户使用电子银行服·强双向鉴别；·H验证数字签名；4·报文完整性；·发送方从目录中取得接收方的务向FI发送高额支付指令·机密性证书；·发送方用接收方的公钥加密报文；·接收方用自己的私钥船密报文·票据交换所验证用户证书；·票据交换所验证数字签名；·为接收方鉴别发送方(账·用户从目录中取得票据_交换所的法人用户直接向自动化的票户持有人)；证书；·报文完整性和不可否认性；·发送方用接收方的公钥加密报文；据交换所发送支付文件·保护报文内容的机密性；·接收方用自己的私钥解密报文；·双重用户授权·两个个体对支付文件进行数字签名；·票据交换所验证两个数字签名持卡人在销售点使用EMV·Ic卡生成数字签名：6·终端离线鉴别1c卡·终端使用由CA签发丁证书的1c购买卡发卡方公钥检查【c昔的真实性5．3．4开放环境中证书应用的说明本条描述了金融机构使用PKI为自己、用户和外部交易伙伴提供开放的外部通信。金融机构可以向它的用户提供信任服务。 台融机构证书确认服务提供者用户——一依赖方图3金融机构在开放环境中作为证书服务提供者金融机构证书签发者用户证书主体图4金融机构在开放环境中作为证书签发者表3开放环境中的证书应用环境GB／T27913—201典型情景范例要求PKI操作Web站点访问者在浏览金融·FI的鉴别；·用户验证Fl的证书；1机构网站时下载可执行代码·H可执行代码的完整性·用户验证H的数字签名·FI官方网站的鉴别(如无2用户访问FI网站·用户验证FI服务器的证书欺骗)不同FI的雇员在没有正式协·为接收方鉴别发送方；·每个FI的雇员验证发送方的证书：3议的情况下通过Internet交换电·报文完整性和不可否认性·每个H的雇员验证数字签名；证明；·每个FI的雇员从目录中获得接收方子邮件·保护报文内容的机密性的证书发布重要的电子文档(如财务·用户验证F1的证书；4·源和内容完整性的鉴别结果)·用户验证数字签名·每个用户验证发送方的证书；两个用户使用不同的TSP交·为接收方鉴别发送方；·每个用户验证接收到的报文的数字5·报文完整性；签名；换敏感电子邮件·保护报文内容的机密性·每个用户从目录中取得接收方的证书 5．4功能可以从很多不同的角度了解PKI。硬件、软件和安全程序提供了丰富的PKI功能，从逻辑上定义丁以FPKI角色。下面的条款描述r策略机构[a)]。认证机构的组成部分[b)～g)]，主体[h)]和信任方[-)]。下面提供了角色的典型功能分配，特定的功能可由不同的角色承担。一个机构可承担多个角色。图5是PKI内功能元素及其关系的总体说明。图5策略机构、认证机构和终端实体关系本标准中采用的术语“认证机构”反映r以下PKI角色的集合，包括：证书签发者、证书生成者、注册机构、资料库、证书确认服务提供方和主体密码机制提供方。策略机构负责对按照其证书策略签发证书的CA进行有效控制、管理和运行。CA使用的控制在其认证业务说明中定义。a)策略机构(PA)执行以下管理功能：——创建、维护并核准证书策略；——按照证书策略的描述规定公钥证书的内容；-_～发布并推广证书策略；对其证书策略的遵从性进行解释；授权特定机构按照证书策略行使证书认证机构职责；——为授权的CA核准认证业务说明；——解决证书策略相关的争议；14 GB／T27913—2011——确保监管的一致性；一确保CP的防护对于潜在的安全威胁有效；接收并检查CA安全事件和所采取行动的报告；——对在CI’的程序内的证书撤销进行核准并制订规则，包括：·谁可提交撤销请求和报告；·他们如何提交；·证实随后所做的撤销报告和撤销请求必要条件；·证书是否并且出于什么原因可被挂起；·用于分发撤销状态信息的机制；——根据风险分析规定从收到撤销请求或报告到发布撤销状态信息并使之对所有信任方可用时的最大延迟。b)证书签发者(CI)执行以下管理功能：管理公钥证书签发过程；——签发并管理证书状态；在用户协议或银行、Jk务条款及条件下与用户建立合同关系；——在一个或多个正书策略下为证书主体签发证书；——为主体或用户提供提交撤销请求的方法；安排并管理撤销公钥证书的过程；——拥有并控制其签名密钥，因此可以转换证书生成者；维护对其商业记录的所有权和控制；——预订CPS；——根据收到的撤消请求和撤销报告进行处理；——对证书撤销请求和报告进行源鉴别；一通知主体或用户其一张证书被撤销或挂起；——根据证书策略条款直接提供或核准执行密码签名和解密功能的机制；一～按照CP的规定管理相关职责和义务。c)证书生成者(CM)执行以下CA运行功能：——创建并维护自己的CPS；——在其CPS的范围内操作；宅成并分发公钥证书；——生成并管理用于证书签名的非对称密钥对并与证书签发者的规定保持一致；——分发证书签发者的公钥证书；——生成证书状态信息(如CRL)；——在得到请求时，提供证书签发和撤销的带外通知；——在不同宿主的证书签发者之间保持分离：——按照其CPS的描述维护证书签名功能的安全性、呵用性和持续性；定期核实保证与第7章中规定的认证机构控制目标保持审计的一致性}一确保监管的一致性；——确保CPS的规定对潜在安全威胁有效；一可选的，在CP允许的情况下根据RA的请求生成用户的密钥对。d)注册机构(RA)执行以下运行功能：管理来自主体或用户的公钥认证请求；一在CM按照cP所允许的方式生成用户密钥对后管理用户密钥对的分发；】5 GB／T27913—201——通过以下方式执行注册过程：·检查主体的身份鉴别信息凭证与所声明的身份一致并按照行业规则(如反洗钱规则)·鉴别主体身份；·验证证书主体提供的身份鉴别数据是有效的；·验证身份鉴别数据属于证持主体；·根据证书策略验证证书主体具有获得公钥证书的资格；·验证证书主体拥有与该公钥相对应的非对称私钥；一一管理向证书生成者提交证书请求；一一记录证书主体身份鉴别数据和证书主体公钥之间的绑定；一接收并处理证书主体或用户的撤销证书、挂起证书和恢复挂起的证书的请求；一在可用证书策略和可用CM的CPS范围内运行。e)资料库执行以下技术功能：——存储和分发公钥证书；——存储并分发证书状态信息(如CRl。和／或在线证书状态)；——存储并分发PKI公开信息(如证书策略)。f)证书确认服务提供者(CVSP)执行以下功能：——建立与信任方的合同协议，并且当正式承诺时，与那些签署信任方协议的机构建立合同协议；——建立与策略机构的合同协议以收集证书策略信息并更新相关证书的状态；一一在其自身机构策略和可用证书策略的范围内运行；一当CVSP根据证书策略代表其他信任服务提供者持有证书时，维护这些证书的状态；——寻求从其他信任服务提供者处获得证书的当前状态；——确认证书状态并向请求者提供响应。g)主体密码机制提供者(ScMP)执行以下功能：——提供一种包括物理安全签名生成设备(如Ic卡)或提供具有可比功能的软件仿真的机制，目的是：·安全存储主体私钥和相关证书；·使私钥能够安全“激活”和安全“去激活”；·提供安全初始激活机制。h)主体或用户执行以下功能：——按照相关证书策略提供其身份鉴别凭证以证实所声称的身份；——向证书认证机构申请为其生成一个或多个非对称密钥对；——向注册机构提供公钥认证请求；——遵循非对称私钥保护要求(即密钥存储和持卡人验证)；——报告私钥丢失或泄露的情况，以及证书信息的错误；——遵循可用策略并按照相应的CP在授权的商业应用中使用他们的密钥对i——使用他们自己的私钥(签名)对报文摘要或类似的数据元进行密码签名；——使用他们自己的私钥解密报文。i)信任方(RP)执行以下功能：——验证主体公钥证书或请求CVSP确认证书主体的公钥证书；——遵循可用策略并按照相关CP使用主体证书中的公钥，用于授权的商业应用和适当的密16 GB／T27913—201码功能(如数字签名验证、密钥交换等)；——使用主体公钥验证数字签名的有效性；——使用主体(机密性)公钥和适当的密码机制来加密报文，提供机密性保护(可选)。将证书认证机构的任意或全部角色以直接或间接方式委托给一个或多个第三方机构是可能的；然而，管理相关的CP风险是证书签发者的责任和义务。5．5商业视角5．5．1概述通过电子媒介进行商业活动的可信任安全环境决定了金融机构将来参与全球在线经济的能力。金融机构的理想目标是为在线市场建立一个支持内部安全需求的安全基础设施，该基础设施是金融机构提高用户服务的基础，也为进入新市场提供了可信任的服务。在定义金融机构的商业操作时，将涉及很多议题，包括5．5．2～5．5．7的事项。5．5．2商业风险进行电子商务风险管理是一种商业需求。PKI是一种可被用于许多不同应用的控制机制5．5．3适用性PKI是一种控制机制，它可提供适当保护来管理风险。能够被看做是一种通用的、可复用的基础设施。涉及到的各方必须确定证书策略是否适用于商业应用和相关风险。5．5．4规范方面规范的观点将公钥证书看作是由认证机构做出的关于主体对信任方的一项或一系列声明。CP(可能通过CPS来增强)确定认证机构所作声明的细节。CP也可规定认证机构提供何种担保，证明这些声明是真实的，并且如果一项声明是不真实的，认证机构将承担何种赔偿责任。它也可规定对这些赔偿责任的限制，如规定一个特定的组，只有该组成员才允许作为信任方。也可规定对每张证书或每笔交易的最大赔偿责任，以及规定对于这些担保有效的交易类型。规定提交赔偿要求和解决争议的程序。规定信任方应满足的条件或信任方在被授权依赖一个证书及其声明前应执行的程序。与PKl相关的职责和责任，尤其是涉及不同商业机构时，通常是契约型PKI环境的一个主要议题。对于信任服务，商业责任和责任的范围在设定商业要求时是一个重要的因素。5．5．5监管方面监管方面关注PKI过程可接受程度的不同，以及可选择的权限、行业标准或行业审计相关业务行为中的服务。5．5．6商业使用方面如5．3所描述的商业使用，是在环境中定义的实体(即证书主体或用户，以及信任方)之间的。两方必须承担CP或定义相关责任的协议中所提出的责任。证书主体或用户可使用数字签名过程授权一个报文或一项交易，随后信任方可信赖这个经过鉴别的签名。在担保框架下，可通过CP或单独的协议确定赔偿的限度。这样信任方可选择为该项交易寻求一个特定上限的担保。5．5．7互操作方面从商业和技术的角度来看，完全不同的商业行为和相关策略经常是对开放式PKI环境的进一步挑17 GB／T27913—2011战。但是，在契约PKI环境中，操作规则的建立是专门来克服互操作问题的。在封闭的环境中，证书签发者和信任方是相同的金融机构，解决互操作问题取决于该金融机构。在制定信任服务业务要求时需要考虑PKI使用的不同策略。金融机构信任服务的互操作需要有一个管理框架，来处理以下问题：法定权限和职责；——商业风险管理需考虑的问题；——证书的技术认可和操作处理方面；——策略和信任方案的责任。非技术性互操作问题通过遵循和遵守特定环境的合同规则束解决，合同规则在证书策略下根据商业应用描述商业合同的责任和义务。CPS的细节自身不构成由一个或多个不同组织运行的CA间互操作性的基础，而证书策略最好作为行业或全球服务的基础，使得通用互操作标准、证书要求和通用担保标准基于证书策略之上。使用单个CPS的CA可支持多个证书策略(如用于不同的应用目的，并且／或者由不同的证书用户群体使用)。此外，使用不同CPS的CA可支持相同的证书策略。a)CP的应用范围可更广泛而不仅限于单个部门或单个机构。如果一个特定的CP被广泛认可，则它很有可能成为多个系统中证书自动接受的基础；b)向公众或机构间提供认证服务的金融机构应在其CPS中明确他们自己的业务实簏规则。CPS是机构保护它自己以及确定与用户和其他实体间关系的一种方式；c)技术的实现可因PKI集成者对标准和协议的解释和理解有所不同而不同。在PKI环境内必须进行技术对照以确保互操作性。对于不同CA运行的PKI间的互操作性，需要一条信任路径使信任方可以验证另一个CA颁发的证书。这条信任路径可以通过由一个CA向另一个CA签发交叉首E书来提供。甚至可包括其他第三方CA通过交叉证书链提供信任路径。需要仔细确认这样的交叉证书的策略含义，特别是隐含的信任关系需要通过一个适当的商业关系来匹配。CA可通过层次的结构或树状结构来组织，其中根CA被所有信任方信任，并且为从属CA或下级CA签发“CA”证书。因为对根CA的成功攻击有非常严重的影响，所以需要特别注意根CA采用的安全控制措施。此外，根CA的策略和业务实施在某些领域如关于注册等功能的需求可能有很大不同。在不同证书策略下的不同CA所运行的PKl之间需要互操作的情况下：——一个PKI系统下运行的信任方必须接受他自己的CA使用的策略以及另一个CA的策略；——必须存在一个认可的外部CA使用的策略到信任方自己的CA使用的策略的等价映射；这一等价映射需要由信任方的CA来建立，以提供本地策略到外部策略的单向映射，但是，实践中是在CA问通过双边协议建立双方策略相互的等价映射，5．6证书策略(cP)5．6．1概述CP是关于信任级别的一组通用规则集合，让用于特定目的的相关证书满足该信任级别。cP也规定证书认证机构在其签发的证书被信任方所接受前该认汪机构应认可并遵守被信任方所接受的准则。CP由策略机构开发。策略机构编写CP的适用范围可从单个商业实体到一组实体，如为成员实体间进行交易交换而建立的支付联盟。例如，希望与另一公司进行交易的公司出于商业原冈可要求使用数字签名的报文。每一方将需要定义他们的商业要求并采用符合这些要求的证书策略。双方都需要从支持该证书策略的认证机构获得】8 GB／"r27913—2011证书。CP的目的包括：——定义并限制证书的使用；——规定证书主体、用户、认证机构及信任方的要求和义务；——定义证书主体、用户、认证机构及信任方的责任；——规定策略管理过程；——规定监管法律。CP应通过一个被契约环境中所有成员识别的惟一注册对象标识符表示。为了证书用户的检查，注册该对象标识符的PA也发布一个CP的文本文件型规范(更多信息参见附录c)。CP关注于证书将用于什么目的，并且CP的定义独立于认证机构特定运行环境的细节。5．6．2证书策略的使用证书策略在pKI和商业环境中出于特定目的而创建。在一个层次结构或树状结构PKI中可有很多证书策略，每个证书策略为使用同一策略要求的证书组定义商业或策略要求。在每种情况下，策略机构必须开发特定的证书策略，并确保签发证书的认证机构的认证业务说明真正符合每一证书策略的要求。不同证书策略的使用示例将包括但并不限于：a)为特定功能应用制定的证书策略(如服务器认证证书，用于用户鉴别他们的在线银行服务提供者)；b)认同与商业应用相匹配的证书策略(如用户从商户签署一份订单)；c)在预先定义的限制内，认同与已定义环境的一般安全应用相匹配的证书策略(如跨越Internet向证书主体提供所有类型报文的机密性保护)。5．6．3层次信任结构或树状信任结构中的证书策略PKI通常以层次或树状结构出现，结构的顶部是根。根CA基于机构需求将其自身信任的一部分授权委托给下级CA。根CA和中间层CA主要鉴别并签署它们的从属层CA的数字证书，并且通过区分不同机构的需求(如组织结构或组织区域间、国家间、组织单位间等)来提供商业要求。如图6所示，层次或树状结构允许使用多个证书策略，每一策略根据具体不同的商业环境定义不同的商业要求。对于一个层次或树状结构，每一层次的CA对颁发给终端实体的一组证书具有更小的粒度或更多的同质性。这样的每组证书的终端实体共享一套共同的证书策略。例如，层次结构中最高层的根CA必须根据定义使用一个自签名的证书．并且仅可用于对从属CA证书进行签名。从属CA必须基于行政区划、组织机构或其他要求定义。从属CA必须根据多层次结构需求构成多层次的结构，或者向终端实体颁发证书。在一个层次结构中，根CA必须是最受信任的节点。每一从属层CA与它们的对等方之间共享信任，但是每一方必须信任对它们进行委托的上级节点。不同证书策略的使用示铡包括但不限于：a)通过其隐含的自签名证书来识别根CA的证书策略，如图6中策略A下签发的证书；b)用于标识从属CA的证书策略，该从属CA建立在根CA或另一从属CA之下。为了签署从属或中间CA的公钥，根CA作为金融机构中CA层次结构的最终信任顶点，如图6中策略B下签发的证书。图6中，策略机构发布根策略和信任层次结构中所有的从属策略。 GB／T27913—2011图6根状层次结构创建层次结构信任5．6．4证书状态遵照ISO15782l的定义，证书可处于以下状态中的一种：a)有效一可用的；b)挂起([SO15782—1中称为“挂起”的状态)；c)撤销；d)过期。一旦证书撤销或过期就不能再返回有效状态。证书管理的进一步讨论可遵照ISOl5782—1。策略机构应规定在特定CP下颁发的证书状态的适用条件。5．7认证业务说明(CPS)认证业务说明描述了CA为满足证书策略要求所采取的必要的和充分的程序和控制。认证业务说明的目的是明确定义CA管理证书策略相关风险的程序和业务。一种完成认证业务说明的有用方法是遵循附录B的提纲，并且扶证书请求／颁发、证书确认和所需支持功能定义每一步的业务及操作。如前所示，CA是负责执行五种角色的实体：注册、证书生成者、证书签发者、资料库、验证服务。CA负责明确定义使这些角色符合CP要求的控制方法。这些控制在认证业务说明中详细论述。CA的角色和功能可以由它所希望的任何方式安全地委派，但应完成所有的角色和功能，且CPS应由CA编写和维护。CPS可采取由CA声明的形式，声明可信系统的细节以及在其运行过程中采用的安全方案及管理证书的业务实施。认证业务说明的某些部分可成为CA和用户间合同的一部分。当CA和用户间的法律关系建立并由双方同意时(如消费者或公司与银行间的电子银行业务关系)，如用户协议或账户协议的这类合同将成为CPS的有效内容。20 GB／T27913—20115．8证书策略和认证业务说明间的关系5．8．1概述证书策略和认证业务说明的角色如5．8．2和5．8．6所示。5．8．2认证机构与策略机构策略机构制定证书策略，该策略由证书认证机构采纳，同时证书认证机构拥有自己的适应于该证书策略的控制措施，这些控制措施在证书认证机构的认证业务说明中论述。CP由策略机构建立、维护、分发和解释。策略机构可代表一个金融机构或由多个主要股东共享。认证机构为支持其运行制定一个CPS或等价文件作为其符合一个或多个证书策略的证明。正式的CPS在契约PKI环境中不是必须的，通常由相关机构或策略机构的规则确定。任何情况下，CA应将其业务实施规则文档化。虽然一个简单的一致性说明对契约PKI环境是足够的，但是CPS为内部业务操作和受委托角色所完成的业务操作都能提供指导。5．8．3目的证书策略的目的是规定CA、主体和信任方“应遵循什么”，而CPS规定CA“采取什么手段来确保证书策略得到贯彻”(即CA生成和维护数字证书使用的控制过程)。CP包含在数字证书中的索引中。CP和CPS问的关系本质上与其他商业规则相似，商业策略论述商业要求，而运行单位定义实施程序来说明如何执行商业策略。5．8．4特性届性证书策略是规范性的。认证业务说明是描述性的，且是详细的。这些文档通常定义为内部操作程序文档，描述机构内的特定任务和职责。这样的文件可用于CA的日常运行并由执行复审和审计的实体检查。5．8．5方法CP基于已知的业务要求。CPS根据组织结构、操作程序、认证机构的设备和计算环境量身定制。5．8．6受众及访问通常，CP作为契约环境中的公开信息进行管理，因此由PA向所有参与者广泛分发。CP应明确公开、敏感和机密信息在契约环境内的分发策略以及向适当的外部参与方分发的策略。CPS是CA关于签发和维护证书所遵守的控制程序和业务说明，并且明确定义其实施如何完全支持所标识的CP。因此它本质上是一个敏感文件并可认为是机密的。如果CPS的散发是受到限制的，则金融机构可使用PKI揭示说明指明控制的类型和性质，而不揭示特定控制的细节，以支持CP。例如+CP可声明所有证书注册交易是敏感的，并且出于个人隐私的原因，所有交易将在传输和存储期间受到保护。CPS可进一步标识所有证书注册交易将在传输期间进行加密，并且列出允许访问相关存储信息的具体机构部门。CPS也可规定传输加密的算法和密钥长度以及相关存储信息的访问控制机制。CA的机密性操作程序，不仅仅是CP或CPS，还包括访问控制机制管理的详细信息。5．9协议为了将业务关系正式化，证书签发者和用户之间应建立用户协议。用户协议描述了服务的条款和91 GB／T27913—2011服务条件，同时也将用户与相应证书策略中规定的义务与责任相关联。策略机构应对用户公布其相关证书策略。证书确认服务提供者和信任方之间应有信任方协议。策略机构应对信任方和CVSP公布其相关证书策略。通常，用户和信任方之间没有合同。证书生成者应对证书签发者和策略机构公布其CPS。通常CPS不对用户和信任方或CVSP公布。一般，PKI揭示说明可用于此目的，或者作为选择，可使用独立评估来决定CPS中描述的控制方式的适用性。但是认证机构可根据其决定将CPS的副本提供给CVSP。PKl揭示说明的内容由CA决定。当PKI在一个系统范围内运行时，该系统将规定PK[系统内各实体应遵守的规则。策略机构负责确保CP与方案规则保持一致。出于互操作性的目的，每一CA的CPS或PKI揭示说明可在交叉认证前对相应CA发布。图7说明了标准金融PKI模型内典型控制文件的概览。5．10时间戳图7标准金融PKI模型内的控制文件来自可信时间源(即世界协调时间(UTC))的事件时间可作为PKI所提供的安全服务的重要辅助手段。可信时间源不仅是处理安全事件的保证(如用于解决争议)，而且也是一种确保信任服务的方法。时间对于证书使用的两个方面是尤其重要的。首先，信任服务是基于具有有效期的证书。如果证书在其有效期之外对数据进行保护，则证书的有效性不能得到保证。其次．如果证书撤销，则所有在撤销时间之后的证书使用都可被认为是无效的。因此，在采用证书保护数据安全和检验这个保护的有效性之间必须存在一个重要的时间，如将数字签名应用于存储数据，则确认数字签名的时间是很重要的。如果可以确认签名在其证书过期或撤销前产生，则签名的有效性可以在这些事件发生很长时间后得到保证。通常由信任方来决定是否接受由于证书可能已经过期或已撤销的相关风险。提供签名时间保证的一个方法是采用可信第三方，通常称为时间戳机构(TSA)，来将一个标准时间与数字签名的生成的准确或接近时间相关联。这一技术通常称为时间戳。时问戳协议的示例在27 GB／T27913—2011ISO18014-2中定义。时间戳协议使用可信机构对待加时间戳的数据的哈希摘要(如签名的数据)与呵信时问源的时间进行签名。例如，时间戳服务可由签名者在签名后或进行长期数据存储前使用。一旦对数据加盖了时间戳，数据可被认为是有效的，即使支持的证书随后过期或被撤销。当数据要归档很长时间时．例如超过了TSA自己证书的有效期，则可进一步应用时间戳来确保签名数据是正在进行保护的。时阃戳的这种应用也可用于防止签名人通过随后声明签名密钥泄露以使证书撤销来否认签名。如果签名数据在签名创建的时间附近加时间戳，即使证书随后被撤销，也可以证明签名在那个时间是有效的。以上所描述的时间戳机制的一种变形是将时间戳令牌与时间戳机构此前签发的其他令牌相关联，提供比单个时间戳安全性更高的保证(见ISO18014-3)。另一种变形是使用多个独立的时间戳机构．避免依赖于单个可信机构。6证书策略和认证业务说明要求6．1证书簧略(CP)证书应至少在一个CP之下签发。以X．509v3格式签发的证书应遵照ISO15782—1：20038．2．6中定义的方式与一个或多个证书策略明确地关联。a)CP应描述CA签发的证书的适用条件，包括：——如果证书的使用限于特定的应用，则包括所允许的特定使用；——如果证书有规定禁止的使用，则包括证书使用的限制。b)CP应：——被唯一标识；——包含其名称；——标识何处可获得该文件(如UR[。、电子邮件地址、OID等)。c)CP应提供策略内使用的术语的定义(这些定义不同于第3章中的术语和定义)；d)CP应提供进行管理的程序。CP应包括管理程序，以便：～标识策略机构；——标识发布、变更和后续通知的程序；一一标识版本号和生效日期；——如果可用，则包括过期日期。e)CP应包括监管法律的披露或监管法律是如何确定的；f)CP应标识用户义务和责任。CP应包括用户义务和责任，以便：——提供准确的证书请求信息，并且接受证书行为保证证书包含信息的准确性；一保证如果用户或证书主体产生公开密钥对，该密钥对的生成过程需符合特定控制目标(见8．3．4)；——保护对证书相关私钥的访问；——在CP规定的时间框架内通知签发者私钥的泄露或变更证书状态；一将证书限制于特定的使用。g)CP应标识签发者的义务和责任。CP应包括签发者的义务和责任，以便：——通知主体和证书用户证书已经签发；——通知主体和用户证书已经撤销、挂起或取消挂起；一根据CP的规定使证书状态信息对信任方可用(即在参与方和信任方可用的资料库中发布证书状态信息)；23 GB／T27913—2011——遵守所标识的CP及其相关认证业务说明；——提供免责通知(如证书误用于不允许的应用)；——对非公开用户和信任方的信息提供机密性保护。h)CP应标识信任方的义务和责任。cP应包括信任方的义务和责任，以便——限制所标识应用的使用；——提供在证书误用于所排除应用的免责通知；——检查数字签名；——确认证书内容和状态；——提供适用赔偿责任上限和担保的通知。t)CP应明确适用的信任限制或证书使用的财务限制；i)CP应为以下内容规定最小要求：——用户认证与鉴别；——证书状态发布；——用户私钥保护；——cA私钥保护。k)CP应为X．509v3强制字段规定最小要求：——版本号；——序列号；——签名算法；——签发者；——有效期起止日期；——主1本；——公钥算法和最小密钥长度；——要求的证书扩展域。证书策略的更多信息见附录A。62认证业务说明(CPS)a)认证机构应以文档记录其认证如何实施；b)CPS或等价文件应支持CA签发或制造证书所遵循的每一cP；c)CA的认证业务应处理附录B中的内容，包括以下策略机构要求的由总体至细节的关于证书策略的内容：1)引言；2)一般规定；3)认证与鉴别；4)操作要求；5)物理的、程序的和人员的安全控制；6)技术的安全控制；7)证书和CRL；8)实施管理。d)CA的认证实施应与第7章规定的控制目标一致；e)CA的认证实施应包括第8章规定的控制程序，这些程序基于CA的风险评估并符合所支持的证书策略。认证业务说明的更多信息见附录B。24 7认证机构控制目标7．1概述CA环境控制区域内的控制目标、CA密钥生命周期管理控制和证书生命周期管理控制在7．2到7．6中提出，表示了CA应遵循的基本控制标准，可评估或审计CA是否违反这些标准。这种评估可使用根据契约环境规则定义的适当审计方法采取内部审计或外部审计的形式。很多控制目标是可选的，如果CA支持才会使用。包括：——CA提供的主体密钥牛成服务；CA提供的主体密钥存储、恢复和托管服务；一集成电路卡生命周期管理；证书更新；——证书挂起。7．2CA环境控制目标7．2．1认证业务说明和证书策略管理控制目标：(：A应维持控制以提供合理的保证，确保认证业务说明和证书策略管理过程是有效的。策略机构应负责为使用数字证书的业务定义业务需求和策略，并在证书策略和支持协议中规定。为这些控制目标所设计的控制程序见8．2．1。7．2．2安全管理控制目标：CA应维持控制以提供合理的保证，确保：安全在机构内得到规划、管理和支持；有效管理已鉴别的风险；——CA设施、系统和由第三方访问的信息资产的安全得到维护；一当CA子功能及其相关责任外包给其他机构或实体时，信息安全得到维护。为这些控制目标所设汁的控制程序见8，2．2。安全管理指南可在GB／T】9716中找到。7．2．3资产分类和管理控制目标：CA应维持控制以提供合理的保证，确保CA的资产和信息得到适当级别的保护，该保护基于所支持的证书策略和风险分析之上。为这一控制目标所设计的控制程序见8．2．3。7．2．4人员安全控制目标：CA应提供合理的保证，确保员工的工作实践提高并支持CA运行的可信性。为这一控制目标所设计的控制程序见8．2．4。7．2．5物理和环境安全控制目标：CA应维持控制以提供合理的保证，确保——仅有已授权的个人才能对CA设施进行访问；——保护CA设施防止来自环境的危险； GB／T27913—201～防止资产的丢失、损坏或泄露以及业务活动的中断；——防止信息和信息处理设施的泄露。为这些控制目标所设计的控制程序见8．2．5。7，2．6运行管理控制目标：CA应维持控制以提供合理的保证，确保：——cA信息处理设施的正确和安全运行；～cA系统失效的风险最小化：——cA系统和信息的完整性受到保护，防止病毒和恶意软件；——通过使用事件报告和响应处理程序将安全事件和故障的损失最小化——安全地处理信息介质以防止其损坏、被窃或被非授权访问。为这些控制目标所设计的控制程序见8．2．6。7．2．7系统访问管理控制目标：CA应维持控制以提供合理的保障，确保已获授权的个人对CA系统进行访问。这样的控制应提供合理的保证，确保：——仅限于已授权的个人进行运行系统的访问；——仅限于已授权的个人、应用程序和服务对CA系统所处的网段进行访问；——仅限于已授权的个人使用CA应用程序。为这些控制目标所设计的控制程序见8．2．7。7，2．8系统开发和维护控制目标：CA应维持控制以提供合理的保证．确保通过授权进行CA系统的开发和维护，并以此来维护CA系统的完整性。为这一控制目标所设计的控制程序见8．2．8。7．2．9业务连续性管理控制目标：CA应维持控制以提供合理的保证，确保灾难事件发生时运行的连续性。这样的控制至少应包括：——cA灾难恢复计划的开发和测试；一在备用地点存储必需的密钥要素(即安全密码设备和激活材料)；-_在备用地点存储系统、数据和配置信息的备份；——保证用于恢复的备用地点、设备和连接的可用性。CA应维持控制以提供合理的保证．确保因CA服务停止或功能下降而导致的用户和信任方的相关服务中断的潜在因素最小化。为这些控制目标所设计的控制程序见8．2．9。7．2．10监视和一致性控制目标：CA应维持控制以提供合理的保证，确保：～cA的运行及服务符合相关法律、制度和合同要求；——cA的运行及服务与CA安全策略和程序的一致性；——能够检测到任何对CA系统的非授权使用。26 为这些控制目标所设{叶的控制程序见8．2．10。7．2．11审计日志控制目标：CA应维持控制以提供合理的保证，确保：——准确适当地记录CA环境、密钥管理和证书管理事件；——当前的和归档的审计甘志的机密性和完整性得到维护——根据业务揭示说明将审计日志完整地、机密地归档；⋯审计Et志由授权人员周期性的审阅。为这螳控制目标所设计的控制程序见8．2．11。GB／T27913—2017．3CA密钥生命周期管理控制目标7．3．1CA密钥生成控制目标：CA应维持控制以提供合理的保证，确保CA密钥对根据规定的密钥生成脚本和CPS的要求生成。为这～控制目标所设计的控制程序见8．3．1。7．3．2密钥存储、备份和恢复控制目标：CA应维持控制以提供合理的保证，确保：——cA私钥保持机密性和完整性；一仅限制已授权的个人对CA密码设备进行访问。为这些控制目标所设计的控制程序见8．3．2。7，3．3CA公钥分发控制目标：CA应维持控制以提供合理的保证，确保CA公钥和相关参数的完整性和可鉴别性在初始化和随后的分发期间得到维护。为这一控制目标所设计的控制程序见8．3．3。7．3．4CA密钥的使用控制目标：CA应维持控制以提供合理的保证，确保CA密钥仅在预定的地方用于预定的功能。为这一控制月标所设汁的控制程序见8．3．4。7．3．5CA密钥归档和销毁控制目标：CA应维持控制以提供合理的保证，确保：——归档的CA密钥在重新导人生产系统后仍然保持机密性和安全性CA密钥在CPS确定的密钥对生命周期结束时被完全销毁。为这些控制目标所设计的控制程序见8．3．5。7．3．6CA密钥泄露控制目标：CA应维持控制以提供合理的保证，确保CA私钥泄露时运行的连续性得到维护。为这一控制目标所设计的控制程序见8．3．6。 GB／T27913—201174主体密钥生命周期管理控制目标7．4．1CA提供的主体密钥生成服务(如果支持)控制目标：如果CA为用户提供密钥管理服务，CA应维持控制以提供合理的保证，确保：由CA(或RA或发卡方)生成的主体密钥是根据相应CP生成的；——由CA(或RA或发卡方)生成的主体密钥由cA(或RA或发卡方)安全地分发给该主体。为这些控制目标所设计的控制程序见8．4．1。7．4．2CA提供的主体密钥存储、恢复和托管服务(如果支持)控制目标：如果CA向主体提供机密性密钥存储、恢复或托管服务，CA应维持控制以提供合理的保证，确保：——由CA存储的主体私钥保持机密性和完整性；一一由CA归档的主体私钥保持机密性；～由CA存储的主体私钥在密钥对生命周期结束时被完全销毁；——由【：A托管的主体私钥保持机密性。为这些控制目标所设计的控制程序见8．4．2。7．4．3集成电路卡(IC卡)生命周期管理(如果支持)控制目标：如果CA(或RA)使用集成电路卡分发主体密钥对和证书，CA应维持控制以提供合理的保证，确保：——Ic卡的获得、准备和个性化由cA(或RA或发卡方)安全地控制；——Ic卡的使用在Ic卡签发前由CA(或RA或发卡方)激活；—IC卡由CA(或RA或发卡方)安全地存储和分发；——Ic卡由CA(或RA或发卡方)安全地更换；——返回给CA(或RA或发卡方)的lC卡的被安全地终止。为这些控制目标所设计的控制程序见8．4．3。7．4．4主体密钥管理的要求CA应规定在密钥生命周期内安全管理主体密钥的方法。为这一控制目标所设计的控制程序见8．4．4。7．5证书生命周期管理控制目标7．5．1主体注册控制目标：CA应维持控制以提供合理的保证，确保：——主体(或用户)按照适用的“了解用户”的要求被准确识别；⋯～主体(或用户)的证书请求是准确的、授权的和完整的。为这些控制目标所设计的控制程序见8．5．1。7．5．2证书更新(如果支持)控制目标：如果证书更新在CP下得到支持，则CA应维持控制以提供合理的保证，确保证书更新请求是准确的、已授权的和完整的。为这一控制目标所设计的控制程序见8．5．2。，8 GB／T27913—2017．5．3证书密钥更新控制目标：CA应维持控制以提供合理的保证，确保证书密钥更新请求是准确的、已授权的和完整的。为这一控制目标所设计的控制程序见8．5．3。7．5．4证书签发控制目标：CA应维持控制以提供合理的保证，确保证书根据CP生成并签发。为这一控制目标所设计的控制程序见8．5．4。7．5．5证书分发控制目标：CA应维持控制以提供合理的保证，确保完整并准确的证书一经签发，对于CP中定义的任何实体都可用。为这一控制目标所设计的控制程序见8．5．5。7．5．6证书撤销控制目标：CA应维持控制以提供合理的保证，确保按照风险所指示的方式，基于经过授权和验证的证书撤销请求及时撤销该证书。为这一控制目标所设计的控制程序见8．5．6。7．5．7证书挂起(如果支持)控制目标：如果支持证书挂起，则CA应维持控制以提供合理的保汪，确保按照风险所指示的方式，基于授权和确认了的证书挂起请求及时挂起证书。为这一控制目标所没计的控制程序见8．5．7。7．5．8证书确认服务控制目标：CA应维持控制以提供合理的保证，确保根据CP的规则，及时、完整和准确的证书状态信息(包括证书撤销列表和其他证书状态机制)对相关实体(用户和信任方或其代理——即CVSP)是可用的。为这一控制目标所设计的控制程序见8．5．8。7．6CA证书生命周期管理控制7．6．1从属CA证书生命周期管理控制目标：签发从属CA证书的CA应维持控制以提供合理的保证，确保其：一从属CA证书请求是准确的、已鉴别并核准的；——从属CA证书更换(更新或密钥更新)请求是准确的、已授权的和完整的；——新的、更新了的和密钥更新了的从属CA证书是根据特定CP生成并签发的；——完整并准确的从属CA证书一经签发，按照CP的要求，其对相关各方(用户和信任方)是可用的；一从属CA证书基于授权的和确认的证书撤销请求进行撤销；一及时、完整和准确的证书状态信息(包括CRI。和其他证书状态机制)按照CP的要求对任何相关实体是可用的。为这些控制目标所设计的控制程序见8．6．1。29 GB／T27913—20118认证机构控制程序8．1概述本条描述的控制程序为、人证机构的、世务、运行和技术使用提供r实施规程建议。某些控制程序(如使用“应”的控制程序)要求与本标准一致。CA的CPS应仅包括基于CA风险评估的适合的控制程序，以支持签发证书所遵循的证书策略。评估CA控制目标及控制程序时，评审者应评审CA的CPS、支持的证书策略、其他的CA业务揭示文件和其他相关CA文件(如CA操作程序、安全策略、网络结构图和审计日志)。如何使片I证书策略建屯CA层次结构见5．6．3。关于信任模型的更多细节，应查阅ISO15782—1：2003的附录G。8．2CA环境控制82．1认证业务说明和证书策略管理控制目标CA应维持控制以提供合理的保证，确保认证业务说明和证书策略管理过程是有效的。策略机构应负责为使用数字证书的业务定义业务需求和策略，并在证书策略和支持协议中规定控制程序策略机构(PA)管理LPA应负责确保CA控制过程按照认证业务说明或等价文件中的规定，并完全符合CP的要求2PA应有最终授权和责任规定并核准证书策略3PA应有聚终授权和责任核准CA的认证业务说明PA应确保认证业务说明或等价文件的产生并确保这些文件至少描述以下内容：a)CA环境控制；4b)密钥生命周期管理控制；c)证书生命周期管理控制PA或委托的代表应确保其业务服务应用使用适当的证书策略当证书策略终止时，PA应维护相关程序并通知受影响的各方。PA应首先立即通知支持其证书策略的CA6以迅速采取适当的行动PA应维护其终止情况下的程序，在这种情况F．应通知受影响的各方传输归档记录到相关管理者。证书策7略管理8策略机构按照确定的程序核准证书策略．包括对证书策略的维护9应存在确定的程序以确保CPS中规定的控制支持证书策略10PA应使CA支持的证书策略对所有适合的用户和信任方都是可用的CPS应包括对控制的解释以确保与以下保持一致：a)法律要求；b)合同要求}llc)教育和通告要求；d)防止并检测病毒及其他恶意软件：e)业务连续性要求；f)’因违反安全策略或安全事故结果导致的增强管理的要求 GB／T27913—2011控制程序12PA应周期性地执行评估以确定c11对相关业务风险的应对是充分的。由CA进行的认证业务说明(CPS)管理13应由PA根据确定的程序核准CA的CPS并修改，包括维护Ct’S的责任14CA应使其认证业务说明对所有适合的各方都可用15CA．的CPS的修订版应对适用的各方可用CA管理16CA的控制应在CI’S或等价文件中描述8．2．2安全管理控制目标CA应维持控制以提供合理的保证，确保安全在机构内得到规划、管理和支持；有效管理已鉴别的风险；cA设施、系统和由第三方访问的信息资产的安全得到维护；当CA子功能及其相关职责被外包给其他机构或实体时．信息的安全性得到维护控制程序信息安全策略信息安全策略文档，包括物理的、人员的、程序的和技术的控制，应通过相关管理来核准、公布并通知给所有1员工信息安全策略应包括：a)信息安全的定义，全部目标和范围，以及安全作为能够进行信息共享的一种机制的重要性；b)管理目的的描述、支持的目标和信息安全原则；2c)解释对机构特别重要的安全策略、原则、标准和一致性要求；d)定义信息安全管理的一一般和特别责任，包括报告安全事件；e)支持本策略的文件的引用3应有确定的程序用于维护信息安全策略，包括职责和评审日期信息安全基础设施4高级管理和／或高层管理信息安全委员会应确保有明确的指导和管理，以此来支持有效的风险处理5应设置管理组或安全委员会来协调信息安全控制的实施和风险管理6应明确定义保护个人资产和执行特定安全过程的职责7应存在并遵循新信息处理设备的管理授权过程第三方访问的安全应存在程序以控制第三方(如在场订约者、交易伙伴和合作者)对CA设施和系统的物理及逻辑访问，应遵循8该程序如果CA有业务需求允许第三方访问CA的设施及系统，则应进行风险评估以确定涉及到的安全和特定的9控制要求10涉及第三方对CA设施及系统进行访问的安排应基于包含所有必要的安全要求的正式合同31 GB／T27913—2011控制程序外包如果CA将全部或部分信息系统、网络和7或桌面环境的管理和控制外包，则应在相关各方签署的合同中明11确CA的安全要求如果CA选择将CA的部分角色和相应功能委托给另一方，则CA应最终负责外包功能的完成以及CPS规12则的定义和维护8．2．3资产分类和管理I控制目标‘CA应维持控制以提供台理的保证，确保CA的资产和信息受到适当等级的保护，这些保护基于所支持的所有证书l策略的和风险分析之上控制程序1应识别所有CA资产的所有者，并且为其分配维持适当控制的责任。维护适当的控制分配责任2应维护CA资产的清单3CA应对基于业务需求和与之相关的业务影响信息进行信息分类，并采取相关的保护控制应定义程序以确保信息的标汜和处理是按照CA的信息分类方案执行的8．2．4人员安全【控制目标cA应维持控制以提供合理的保证，确保员工的工作实践提高并支持CA运行的可信性控制程序1CA应雇用拥有与工作内容相适应的相关技能、知识和经验的人员机构安全策略中所规定的安全角色和职责应在工作描述中记录。应明确标识CA运行安全所依赖的可信2角色可信的角色至少应包括行使以下职责的角色：a)CA安全业务实施的全面管理职责；b)证书生成、撤销和挂起的核准；c)CA系统的安装、配置和维护；3d)CA系统的日常操作及系统备份和恢复；e)CA系统归档文件和审计日志的审查和维护；f)密码密钥生命周期管理功能(如密钥组件管理者>；g)CA系统开发CA策略和程序应规定对可信角色和非可信角色要求的背景检查和清除。至少对永久职员的验证检查应在4工作申请时执行，并且对承担可信角色的个人进行周期性检查5个人的可信状态应在获碍对系统／设施的访问或执行需要可信状态的行为前核准6CA的雇员和可信角色应签署一份保密协议作为雇用的条件32 GB／T27913—2011控制程序7执行可信角色的签约员工应至少受到和雇员一样的背景检查及人员管理程序签约员工和CA之间的合同协议应包括这样的条款，使临时签约员工明确同意CA对违反机构安全策略的签约员工采取下列措施：8a)同签约员工签署明确要求；b)要求签约员工对故意的有害行为导致的损害进行赔偿；c)进行经济处罚9应有正式的纪律处理程序，对违反组织安全策略和程序的雇员加以处罚10当终止雇用时应及时采取适当的行动，使得控制不会被削弱11对可能成为强制对象的人员提供监禁警告12机构的所有雇员和相关第三方签约员工应接受机构策略和程序的适当培训8．2．5物理和环境安全控制目标CA应维持控制以提供合理的保证，确保：仅有已授权的个人才能对CA设施进行访问；保护CA设施防止来自环境的危险；防止资产的丢失、损坏或泄露以及业务活动的中断；防止信息和信息处理设施的泄露控制程序CA设施物理安全应通过创建严格的安全边界(即物理和逻辑屏障)来提供物理保护。CA的证书生产设备应由它自己惟一的1物理边界保护2包括CA证书生产设施的建筑或地点的边界应有最少数量的受控访问点应设置有人接待区域或其他控制物理访问的方法，使得对CA运行所在的建筑或地点的访问仅限于授权3人员4应设置物理屏障(如从地板到天花板的坚固墙体)以防止对CA证书生产设施的非授权进入或环境污染应设置物理屏障(如电磁屏蔽)以防止对所有根CA操作(如密钥生成和CA证书认证)以及证书策略所规定5内容的电磁辐射6围绕CA运行设施的安全边界上的防火门应具有警报装置并遵循地方防火规定7应安装并定期检查人侵检测系统，范围覆盖放置CA运行设施的建筑的所有外面的门8无人时，应将CA运行设施物理锁住并设置报警装置9所有人员应佩戴可见的身份标识。应鼓励雇员查问任何没有佩戴可见标识的人员10应通过使用鉴别控制，限制仅授权人员对CA运行设施进行访问11应将所有进入和离开CA运行设施的人员记人日志(即应维护所有访问的审计追踪)12应监督CA设施的访闻人员，记录他们进人和离开的日期和时间13应限制第三方支持服务人员对安全CA设施的访问，当必须访问时，也应对该访问进行授权并且有人陪同33 GB／T27913—2011控制程序CA设施物理安全j4应定期审查并更新CA设施的所有访问权设备安全15cA应维护一个设备清尊16应确定设备放置地点并对设备进行保护，以减少环境威胁和灾害．以及减少非授权访问的机会17设备应受到保护以有效应对停电或其他电力异常情况18应保护CA服务的电力电缆和通信电缆不受到侦听或破坏19应根据制造商说明书和／或其他文档化的程序维护设备，确保其连续可用性和完整性应检查包含存储介质(固定和可移动的磁盘)设备的所有项目，确保在销毁前不再包含敏感数据。包含敏感20数据的存储介质应被物理销毁或在重新使用前进行安全重写通用控制21敏感或关键业务信息应在不需要或CA设旌不再使用时被锁起22程序应要求个人计算机和工作站在不使用时退出登录，或通过密钥锁、物理上锁、口令或其他控制措施保护23程序应要求属于机构的设备、信息和软件不能未经授权就被带离所在位置8．2．6运行管理控制目标CA应维持控制以提供合理的保证，确保：cA信息处理设施的正确和安全运行；一cA系统失效的风险最小化；cA系统和信息的完整性受到保护，防止病毒和恶意软件；一通过使用事件报告和响应程序将安全事件和故障的损失最小化；安全地处理信息介质以防止其损坏、被窃或被非授权访问控制程序运行程序和责任l对于每个功能去，应将CA遥仃程序通过文件记录并维护2应有正式的管理责任和程序来控制CA设备、软件和运行程序的所有变更3责任和责任范围应被分开，以减少非授权修改、信息或服务误用4开发和测试设施应与运行设施分开系统计划和接受5应监视容量需求并预测未来的容量要求。以确保有充足的处理能力和存储量6应建立新信息系统、升级系统或新版本系统的接受标准，并在接受前执行适当的系统测试防止病毒和恶意软件7应实施防止病毒和恶意软件的检测和防护控制。应有适当的程序使雇员知晓控制措施。事件报告和响应应有正式的安全事件报告程序，在接收到事件报告时启动应采取的行动。这包括分配的责任和自动调整程8序。任何事件都应作为紧急问题报告给PA34 GB／T27913—2011控制程序敌授予可信角色的CA系统用户应记录并报告观察到的或怀疑的在系统或服务中的安全弱点及威胁，以确9保对安全事件的适当响应10应建立并遵循硬件和软件故障报告程序11应建立并遵循相应程序，报告错误．并采取正确的行动。12应建立并遵循规范的阃题管理程序．以记录、量化并监视事件和故障的类型、数昔和影响介质处理和安全可移动的计算机介质的管理程序应要求：a)如果不再需要，应有效擦除任何准备移走的可重用介质中原有数据内容，或者将该介质销毁；13b)从机构内移走的所有介质需要得到授权，并且保存所有移动的记录以维持审计追踪；c)所有介质应根据制造商的规定在安全的环境中存储和放置包含存储介质的设备(即固定硬盘)应受到检查，以确定在销毁或重用前是否包含敏感数据。包含敏感信息14的存储设备应在销毁或重用前被物理销毁或安全地重写15应建立并遵循信息处理和存储程序以防止该信息非授权暴露或误用16应保护系统文件．舫止菲授权访问8．2．7系统访问管理控制目标CA应维持控制以提供舍理的保证，确保仅限于已授权的人员对CA系统进行访问。这样的控制应提供合理的保证：仅限于已授权的拥有预定任务权限的人员对运行系统进行访问；一仅限于已授权的个人、应用和服务对CA系统所处同段进行访问；仅限于已授权的人员使用CA应用程序控制程序用户访问管理应在访问控制策略中定义并以文件形式明确访问控制的业务要求．至少包括：a)角色和相应的访问许可；b)每一用户的认证与鉴别过程；1c)责任分离；d)执行特定CA操作所要求的人员的数量(即”分之717规则．其中，一表示需要执行一项操作的密钥分享组件持有者的数量，”表示密钥分享组件的总数)2应有正式的可信角色用户注册和注销程序，以允许访问CA信息系统和服务3权限的分配和使用应受到限制并受到双重控制4口令的分配应通过正式的管理过程进行控制S被授予可信角色的用户的访问权限应定期审查网络访问控制6CA雇员应只对明确授权其使用的服务进行直接访问。用户终端到计算机服务的路径应受到控制7如果允许CA雇员或外部系统对CA系统的远程访问．则应要求进行相互鉴别8CA雇员或CA系统和远程计算机系统的连接应被相互鉴别9诊断端口的访问应得到安全地控制35 GB／T27913—2011控制程序lO应具有有效控制(如防火墙)以保护CA的内部网络区域，防止来自其他区域的任何非授权访问根据CA的访问控制策略．应具备有效控制来限制授权用户可用的厕络服务(如HTTP、F’FP等)。CA机构11使用的所有网络服务的安全属性应由CA以文件形式明确12应具有路由控制以确保计算机连接和信息流不违反CA的访问控制策略CA应确保本地网络组件(如防火墙和路由器)处于物理安全的环境中，并周期性地审计它们的配置与CA13配置要求的一致性14通过公共或不可信网络交换的敏感数据应被加密操作系统访问控制15操作系统应根据CA的操作系统配置标准进行配置并周期性审查16操作系统补丁-和升级程序应基于风险评估在的确需要系统升级时及时应用17应使用自动终端认证来鉴别到特定地点和便携设备的连接18访问CA系统应要求一个受保护的登录过程所有CA人员用户应有惟一标识(用户ID)供个人单独使用．这样活动可以被追踪到责任人。需要共享账户19或组账户的地方应实施其他监控措施来维持个人行为与系统操作的有效绑定20系统工具程序的使用应限制于已授权人员并有效控制21服务于CA系统的非活动终端应在使用前重新鉴别22对高风险的应用应使用连接时间限制，以提供额外的安全性23应防止敏感的操作系统数据泄露给非授权用户应用访问控制24信息和应用系统功能的访问应根据CA的访同控制策略进行限制25CA人员使用与证书管理相关的关键应用前应被成功识别和鉴别26敏感系统(如根CA)应要求专门的(隔离的)计算环境82．8系统开发和维护l控制目标cA应维持控制以提供合理的保证，确保通过授权进行CA系统的开发和维护，并以此来维护CA系统的完整性控制程序1新系统和系统升级的业务要求中应明确规定控制要求对于操作系统上的软件实施．包括预定的软件发布、修改和紧急软件修复，应建立和遵循软件测试和变更2程序3应建立和遵循硬件、网络组件和系统配置变更程序4应维持对程序源代码库访问的控制5操作系统发生变更时应对系统进行审查和测试6应眼制对软件包的修改，应严格控制所有变更7应控制和检查软件的购买、使用和修改，防止可能的璺蔽通道或恶意代码。这些应包括软件来源的鉴别。这些控制同样应用于外包软件开发。应遵照GB／T18336定义的通用准则或类似标准进行评估鉴定36 8．2．9业务连续性管理GB／T27913—201控制目标CA应维持控制以提供合理的保证，确保灾难发生时运行的连续性。这样的控制至少应包括：cA灾难恢复计划的开发和测试；在备用地点存储必需的密钥要素(即安全密码设备和激活材料)；在备用地点存储系统、数据和配置信息的备份；保证用于恢复的备用地点、设备和连接的可用性CA应维持控制以提供合理的保证，确保因CA服务停止或功能下降导致的用户和信任方的相关服务中断的潜在因素最小化控制程序lCA应有开发和维护其业务持续性计划的管理过程。CA应有基于适当风险评估的业务持续性计划策略。CA应有在关键CA过程中断或失效后及时维护或恢复CA运行的业务持续性计划。CA的业务持续性计划应明确：a)激活计划的条件；b)应急程序；c)撤退程序；2d)恢复程序；e)计划的维护方案；f)知晓和教育要求；g)个人职责；h)恢复时问目标(RTO)；1)业务持续性计划的定期测试CA业务持续性计划应包括一个或多个组件失效时CA所有关键组件的灾难恢复过程，包括软件、硬件和密钥，特别是：3a)用于存储CA私钥备份的密码设备应安全保存在异地，以在主CA设施灾难事件时得到恢复；b)使用并管理灾难恢复密码设备所需的必要子密钥和密钥组件也应在异地保存4应定期进行基本业务信息的备份。这些备份的安全要求应与信息备份控制要求保持一致CA应确定并安排备用地点，在CA主地点发生灾难事件时核心的PKI操作可恢复。撤退设备和备份介质5应放置在安全距离外，避免来自主地点灾难的破坏不管是在本地还是远程，当灾难发生并且安全环境没有恢复期间，cA业务持续性计划应包括这段时间内保6护设施安全的程序7CA业务持续性计划应明确如果计算资源、软件和／或数据被破坏或被怀疑受到破坏时使用的恢复程序8业务持续性计划应定期进行测试以确保是最新的和有效的9业务持续性计划应通过定期审查和更新进行维护以确保持续有效性8．2．10监视和遵守控制目标CA应维持控制以提供合理的保证，确保：CA的运行及服务符合相关法律、制度和合同要求{CA的运行及服务与CA安全策略和程序的一致性；能够检测到任何对CA系统的非授权使用37 GB／T27913—2011控制程序遵守法律要求lCA应有程序确保对每个信息系统都明确定义并以文件形式明确了所有相关的法令、规定和合同要求2CA应有实施的程序以确保遵守使用知识产权和专有软件产品的法律规定3应有控制来确保对密码硬件与软件的访问或使用符合国家法律、法规或其他规定4应有程序来确保个人信息依据相关法律受到保护信息安全策略应明确：a)必须由CA或RA保密的信息；b)不认为是机密的信息；c)向法律强制机构发布信息的策略；d)可以作为当事人证据收集被披露的信息；e)信息在主体同意情况下可被披露的条件；f)机密信息可被披露的其他情况6保护CA的重要记录，防止丢失、破坏和伪造篡改安全策略和技术的一致性审查7管理者应负责确保他们职责范围内的安全程序正确执行8CA的运行应受到定期审查以确保与CPS一致9应周期性检查CA系统与安全实施标准的一致性监视系统访问和使用10应建立监视CA系统使用的程序，监视活动的结果应定期审查。应实施报警机制检铡非授权访问8．2．11审计日志控制目标CA应维持控制以提供合理的保证，确保：准确适当地记录CA环境、密钥管理和证书管理事件；当前和归档的审计日志的机密性和完整性得到维护；根据业务揭示说明将审计日志完整地机密地归档；审计Et志由授权人员周期性的审阅控制程序审计日志1CA应接照法律和证书繁略的要求生成自动的(电子的)和手工的审计日志所有日志条目应包括：a)条目的日期和时间；b)条目的序列号或顺序号(对于自动日志条目)；2c)条目种类；d)条目来源(如终端、端口、地点、客户等)；e)生成日志条目的实体身份38 GB／T27913—2011控制程序记录的事件CA应记录以下CA和主体密钥生命周期管理相关的事件：8)CA密钥生成；b)手工密钥的安装及结果(连同操作者的身份)；c)CA密钥备份；d)CA密钥存储；e)CA密钥恢复；[)CA密钥托管活动(如果有)；3g)CA密钥使用；h)CA密钥归档；·)密钥要素从服务中撤销；J)CA密钥销毁；k)授权一个密钥管理操作的实体的身份；1)处理密钥要素【如存储在便携设备或介质内的密钥组件或密钥)的实体的身份；m)密钥，设备或保存密钥的介质的保管；n)私钥的泄露CA应记录以下密码设备生命周期管理的相关事件：a)设备接收和安装；b)放置或移除储存器中的设备；4c)设备激活和使用；d)设备解除安装；e)指定对设备的服务和修理；f)设备退役如果CA提供主体密钥管理服务，CA应记录以下主体密钥生命周期管理相关的事件：a)密钥生成；b)密钥分发(如果可用)；c)密钥备份(如果可用)；d)密钥托管(如果可用)；5e)密钥存储；f)密钥恢复(如果可用)；g)密钥归档(如果可用)；h)密钥销毁；，>授权一项密钥管理操作的实体的身份；J)密钥泄露CA应记录(或要求RA记录)以下证书应用信息：a)采用的身份认证方法和用于符合“了解你的用户”的要求的信息。b)惟一身份鉴别数据记录、号码或组合的记录(如申请者驾照号码)，如果可用；c)申请和认证文件副本的存储地点；d)接受申请的实体的身份；6e)用于验证认证文件的方法；f)接收申请的CA或提交申请的RA的名称，如果可用；g)主体用户协议的接受；h)按照个人隐私的相关法律要求，用户同意CA保存包含用户个人数据的记录，同意将该信息传递给特定第三方并发布证书39 GB／T27913—2011控制程序CA应记录以下证书生命周期管理相关的事件：a)收到证书请求——包括初始证书请求、更新证书请求和更新密钥请求；b)提交用于认证的公钥；c)实体从属关系的变更；d)证书生成；7e)CA公钥的分发；f)证书撤销请求；g)证书撤销；h)证书挂起请求(如果可用)；·)证书挂起和取消挂起；J)证书撤销列表的生成和发布CA应记录以下安全敏感事件：a)包括审计日志本身的安全敏感文件或|己录的读写；b)对安全敏感数据采取的行动；c)安全配置文件的更改；d)认证与鉴别机制的使用，不论成功还是不成功(包括多次失败的鉴别尝试)；8e)安全敏感的非金融交易(如账户或名称／地址变更等)；f)系统崩溃、硬件失效或其他异常；g)可信角色、计算机操作员、系统管理员和系统安全员个人所采取的行动；h)实体从属关系的变更；1)不进行加密／鉴别过程或程序的决定；J)访问CA系统或其中的任何组件9审计日志不应以任何形式(如明文或加密的形式)记录私钥10CA计算机系统时钟应按照CP或CPS中规定的可接受时间源进行同步，以准确进行记录审计日志保护11当前和归档的审计日志应以防止修改或非授权销毁的形式进行维护12在可能或要求满足法律要求的情况下应使用数字签名保护审计日志的完整性用于对审计日志签名的私钥不应用于其他目的。用于对称MAC机制中使用的对称密钥同样不应用于其他13目的审计日志归档14CA应定期归档审计日志数据15除了可能的相关规则的规定，应执行风险评估确定保持归档审计日志的适当时间长度CA应在一个异地的安全位置，在预定的时间周期内维护归档的审计日志，周期长度由风险评估和法律要求16来确定审计日志的审查17当前和归档的审计日志应只能被授权人员以合理的业务原因或安全原因获取18审计日志应根据CPS中建立的业务规则进行审查当前或归档的审计日志的审查应包括验证审计日志的完整性，以及异常、非授权或可疑活动的鉴别及其后续事件的追踪19要求分析的情况和可能行为的示例包括系统资源的异常饱和、数量的突然变化和意外的增加以及在异常时间或来自异常地点的访问 8．3CA密钥生命周期管理控制8．3．1CA密钥生成GB／T27913—201控制目标CA应维持控制以提供合理的保证，确保CA密钥对根据规定的密钥生成脚本和CPS的要求生成控制程序CA密钥，包括根CA密钥的生成CA密钥生成应根据规定了执行步骤和参与者责任的详细的CA密钥生成过程脚本来执行。CA密钥生程序脚本应包括：a)角色和责任的定义}b)执行密钥生成过程的核准；c)密钥生成过程需要的密码硬件和激活材料；ld)规定密钥生成过程期间执行的步骤；e)密钥生成后密码硬件和激活材料安全存储的程序；n参与者和见证人签署指明密钥是否根据详细密钥生成过程脚本生成。g)任何密钥生成过程脚本执行及执行结果异常现象的注释CA密钥生成过程的更多讨论参见附录DCA密钥的生成应在按照ISO15782—1和CPS业务要求的密码模块执行。这样的密码设备应使用ISO，2IECI8032规定的随机数生成器(PNG)或伪随机数生成器(PRNG)进行密钥生成CA密钥的生成应在物理安全环境中(见825)由被授予可信角色的人员在多重控制和知识分割的原则下3(参见附录D)进行4CA应在使用密钥对的同一密码设备内生成密钥对，或者直接从生成它的设备注入到使用它的设备当中CA所生成的密钥应：a)适合丁预定的应用或目的，并且与识别的风险相适应；b)使用ISO／IEC18033，第1到第4部分核准的算法；c)具有与密码算法和CA证书有效期相适应的密钥长度：d)同时考虑上级CA和它的从属CA密钥大小的要求：￡)与CI’一致6CA密钥的生成应产生符合CP的密钥长度。经CA认证的公钥长度应小于或等于CA签名私钥的长度7用于密钥生成的软硬件的完整性和与这些软硬件的接口应在生产使用前进行测试8．3．2CA密钥存储、备份和恢复控制目标CA应维持控制以提供合理的保证，确保：cA私钥保持机密性和完整性；仅限于已授权的个人对cA密码设备进行访问l控制程序l-CA的(签名和机密性)私钥应在安全密码设备内存储和使用，这些设备应基于风险评估和CA的业务要求符合GB／T18336保护配置文件的要求并与CA的CPS和适用的证书策略一致 GB／T27913—2011控制程序2如果CA的私钥没有从安全密码模块中导出，则CA私钥应在同一个密码模块内生成、存储和使用如果CA的私钥从安全密码模块导出到安全存储，用于离线处理或备份和恢复的目的，则它们应在一个安全密钥管理方案内被导出，该方案可包括：3a)密文使用的密钥被适当像护；b)加密的密钥片断使用多重控制和分割知汉／所有权；c)使用另一个安全密码模块，如使用多重控制的密钥传输设备如果备份CA的私钥，则它们应由被授予可信角色的授权人员，在物理安全环境中使用多重控制进行备份、4存储和恢复。授权执行该功能的人员的数量应保持最小如果备份CA的私钥，则CA私钥的备份应受到与当前使用的密钥相同或更高级别的安全控制。CA密钥的5恢复应以与备份过程相同安全的方式执行CA密码设备生命周期管理策略和程序应要求CA密码硬件由制造商发送给CA时使用防篡改包装通过挂号邮件(或等效方法)发送。6一旦收到制造商发送到CA的密码硬件，授权的CA人员应检查该防篡改包装以确定封条是否完整一旦收到制造商发送到CA的密码硬件，就应执行验收测试和固件设置验证。一旦对CA密码硬件进行服7务维修．就应执行验收测试和固件设置验证为防止篡改，CA密码硬件应在安全地点存储和使用，并将访问限制于授权人员。CA密码硬件具有以下特征：a)详细清单控制过程和程序管理每一设备的来源、到达、状况、出发和目的地；8b)访问控制过程和程序限制授权人员的物理访问；c)在审计日志内记录所有对CA设施和设备存储机制(如保险箱)成功或失败的访问；d)具有事件处理过程和程序来处理异常事件、违反安全事件、调查和报告；e)具备审计过程和程序以验证控制的有效-|生9未连接到CA系统时，CA密码硬件应保存在防篡改的容器内，容器在多重控制下安全地保存t如保险箱)CA密码硬件的处理，包括以下任务，应在不少于两个可信雇员在场的情况下执行：a)安装CA密码硬件；10b)从生产系统中移走CA密码硬件；c)CA密码硬件的服务或修理(包括新硬件、固件或软件的安装)；d)拆卸并从使用中永久移除11用于私钥存储和恢复的设备以及与这些设备的接口应在使用前对完整性(如遵循制造商的说明)进行测试8．3．3CA公钥分发控铷程序CA应提供验证CA公钥可鉴别性和完整性的机制。对于根CA公钥分发过程(如使用自签名的证书)，应使用带外通知机制。在自签名证书被用于任何CA的地方，CA应提供验证自签名证书bT鉴别性的机制(如证书l指纹的发布)对随后的和／或下级的CA公钥．这些应通过使用证书链方法或类似过程链接到可信根证书进行验证。对于新的根证书，可要求带外过程42 GB／T27913—2011控制程序CA公钥的初始分发机制应按照CA的CPS中明确的方式进行控制。CA公钥应在证书内使用以下方法之一按照CA的CPS进行初始分发：2a)来自己进行源鉴别的机器易读的介质(如智能卡、CDROM)；h)嵌入在实体的密码模块内；c)其他确保可鉴别性和完整性的安全方法3CA公钥应根据CPS的要求周期性变更(密钥更新)。应提前通知以避免CA服务的中断4cA公钥随后的分发机制应按照CA的CPS中明确的方法进行控制如果实体已经有CA公钥的已鉴别副本，新的CA公钥应使用以下方法之一按照CA的CPS进行分发：a)从CA直接进行电子传输；5b)放入远程缓存或目录；c)加载到密码模块内：d)用于初始分发的任何方法8．3．4CA密钥使用【控制目标CA应维持控制以提供合理的保证，确保cA密钥仅在预定的地方用于预定的功能控制程序1CA签名私钥的激活应使用多方控制执行(即n分之卅)．卅使用的最小值推荐为32基于风险评估，如果必要，CA私钥的激活应使用多因素鉴别进行(如智能卡和口令、生物鉴别和口令等)3用于生成证书和／或签发撤销状态信息的CA签名私钥不应用于其他目的4CA的私钥应只在物理安全前提内使用(见8．2．5)CA应在定义的密钥对的运行生命期结束时或者已知或怀疑私钥泄露时停止使用该密钥对6CA密码硬件的正确处理应周期性地得到验证7f’A应要求对密钥长度每年进行审查，以确定适当的密钥使用期并作出建议8．3．5CA密钥归档和销毁控制目标CA应维持控制以提供合理的保证，确保：归档的CA密钥在重新导人生产系统后仍然保持机密性和安全性；CA密钥在CPS确定的密钥对生命周期结束时被完全销毁控制程序CA密钥归档1归档的CA密钥应受到与当前使用的密钥相同或更高级别的安全控制2CA的私钥应直到其业务目的或应用已经终止或者法律责任已经期满时才能被销毁 GB／T27913—201控制程序CA密钥归档归档的密钥只有在安全事件导致生产密钥丢失或历史证据要求验证时才能重新放回到生产当中。应要求3控制过程确保CA系统和密钥集的完整性4归档的密钥应在最短的可能时间期内恢复以符台业务要求CA密钥销毁授权销毁CA私钥以及如何销毁CA私钥(如交出令牌、销毁令牌或密钥重写)应根据CA的CPS进行限制6CA私钥的所有副本和分段应以私钥无法被重新得到的方式被销毁7如果CA密码设备正从服务中永久移除，则设备内包含的用于任何密码目的的密钥应从设备内擦除83．6CA密钥泄露控制程序lCA的业务连续性计划中应将CA私钥的泄露或怀疑泄露作为灾难事件CA签名私钥泄露或怀疑泄露的事件发生时，应存在灾难恢复程序，包括由CA私钥签发的所有证书的撤销2和重新签发如果CA私钥泄露，则使用的恢复程序应包括以下行动：a)如何保护生产环境中的密钥使用被重新建立；b)CA的旧公钥如何撤销；3c)对受影响方(如受影响的CA、资料库、用户和CVSP)的通知程序；d)CA的新公钥如何连同鉴别机制一起提供给终端实体及信任方；e)主体公钥如何重新认证CA不得不更换其根CA私钥时，应具备程序将以下内容安全地并经过鉴别地撤销：a，旧的CA根公钥；4b)基于泄露私钥的根CA或任何CA签发的所有证书集(包括自签名的证书)；c)任何从属CA公钥和需要重新认证的相应证书用于密钥泄露的CA业务连续性计划应包括要通知谁，对系统软硬件、对称和非对称密钥、以前生成的签名5和加密的数据要采取什么样的行动6CA业务连续性计划应考虑密钥复制技术，如IS015782l：2003附录J中的描述8．4主体密钥生命周期管理控制84．1CA提供的主体密钥生成服务(如果支持)控制目标如果CA向用户提供密钥管理服务，则CA应维持控制以提供合理的保证，确保：cA(或RA或发卡方)生成的主体密钥根据CP生成的；cA(或RA或发卡方)生成的主体密钥通过CA(或RA或发卡方)安全地分发给主体 GB／T27913—2011控制程序CA(或RA或发卡方)提供的主体密钥生成由CA(或RA或发卡方)执行的主体密钥生成应在安全密码设备内发生．符合基于风险评估的适当的1Is()157821级别要求以及CA的业务要求，并符合适用的CP。这样的密码设备应使用ISO+IEC18032规定的随机数生成器或伪随机数牛成器(I)RNG)执行主体密钥的生成2南CA(或RA或发卡方)执行的主体密钥生成应使用CP中规定的密铜生成算法3由CA(或RA或发卡方)执行的主体密钥生成应按照CP产生具有适当密钥长度的密钥4由CA(或RA或发乍方)执行的主体密钥生成应由授权人员根据该CA的CPS来执行当CA(或RA或发乍方)执行主体密钥生成时+CA(或RA或发卡方)应安全地将CA(或RA或发卡方)生成5的主体密钥对根据CP传送给主体8．4．2CA提供的主体密钥存储和恢复服务(如果支持)控制目标如果CA向主体提供机密性密钥存储、恢复或托管服务，则CA应维持控制以提供合理的保证．确保：由CA存储的主体私钥保持机密性和完整性；由CA归档的主体私钥保持机密性；～由CA存储的主体私钥在密钥对生命周期结束时被完全销毁：由CA托臂的主体私钥保持机密性控制程序CA提供的主体密钥存储、备份和恢复l由CA(或RA)存储的主体私钥应使用基于风险评估和CP要求的密码算法和密钥长度以加密形式存储2如果CA为用户生成密钥对，则CA(或RA)应确保主体的私钥没有泄露给除r该主体外的任何实体如果CA(或RA)生成签名公／私密钥对，则一旦主体确认收到密钥，CA(或RA)就不应保留任何签名私钥的3副本如果CA(或RA)提供主体(机密性)密钥存储洛份和恢复，或主体(机密性)私有密钥备份和恢复-则这些服4务只应由授权的人员执行如果CA(或RA)提供主体密钥存储、备份和恢复，则应有控制来确保主体(机密性)私有密钥的完整性在生命周期内得到保证CA提供的主体密钥归档由CA归档的主体(机密性)私有密钥应使用基于风险评估和CP要求的密码算法和密钥长度以加密形式6存储7如果CA提供主体(机密性)密钥归档，则所有归档的用户密铜应在归档期结束时被销毁CA提供的主体密钥销毁一如果CA提供主体(机密性)密钥存储，则授权销毁丰体私钥和销毁主体(机密性)私有密钥的方法(如密钥重8写)应根据c11进行限制9如果CA提供主体(机密性)密钥存储，则主体私钥的所有副本和分段应在密钥对生命周期结束时被销毁CA提供的主体密钥托管由CA保管的用于法律强制访问目的的主体(机密性)私有密钥臆使用基于风险评估和CP要求的密码算法10和密钥长度以加密形式存储 GB／T27913—20118．4．3集成电路卡(IC卡)生命周期管理(如果支持)控制目标如果CA(或RA)使用集成电路卡(IC卡)分发主体密钥对和证书，则CA(或RA)应维持控制以提供合理的保证，确保：Ic卡的获得、准备和个性化由CA(或RA或发卡方)安全地控制；Ic卡的使用在Ic卡签发前由CA(或RA或发卡方)激活；Ic卡由CA(或RA或发卡方)安全地存储和分筮；Ic卡由CA(或RA或发卡方)安全地更换；返回给CA(或RA或发卡方)的Ic卡被安全地终止控制程序Ic卡的获得如果CA或RA约定了发K方的服务，则相关各方间应存在正式协议。当发乍功能委托给第三方时，CA应1保持对Ic卡的职责和义务2I(1卡在卡制造商和发卡方之间传输时应通过使用传输密钥或通行字进行逻辑保护颁发给主体的lc卡应基于风险评估和CP的要求，符合适当的GB／T18336保护配置文件、国家或ISO卡标准(如GB／T14916、GB／1、】5120(1～5部分)、GB／T17552、GB／T16649(1～3部分)、GB／T16649(5～8部3分)、GB／T1664910、IS()／IEC78164、IS(1／IEC78169、ISO／IEC7816(11～12部分)、ISO／IEC781615、167901、GB／T16790(5～7部分)、ISO10202(2--4部分)、ISO10202．8)的等级要求4发卡方应根据来自卡制造商的收据验证Ic卡的物理完整性5当1c卡在发卡方控制之下时，Ic号应被安全地存储并在资产清单控制之下卡的准备和个性化1c卡准备过程和程序，包括以下内容，这些内容应存在并被遵守：a)加载卡操作系统；6b)创建逻辑数据结构(卡文件系统和卡安全域)；c)加载应用程序；d)逻辑保护1(、卡，防止对卡操作系统、矗文件系统、卡安全域和应用程序的非授权修改1c卡个性化过程和程序，包括以下内容．这些内容应存在并被遵守：a)将身份认证信息加载到卡上；b)根据8．4．1和CP的要求生成主体密钥对；7c)将主体私钥以加密的形式加载到Ic卡上(如果在卡外生成)；d)加载主体证书到Ic卡上；e)加载CA或其他用于契约环境的证书到IC昔上；f)逻辑上防止Ic卡受到非授权访问8发卡方或CA(或RA)应在审计日志内记录Ic卡的准备和个性化9除非卡已经由发卡方、cA或RA准备和个性化，否则不应颁发Ic卡10除非处于激活状态，否则IC昔应是不可使用的，Ic卡的分发11应创建并遵循过程和程序来分发、追踪和说明主体安全接收到用户1c卡1c卡初始激活数据(初始化PIN)应安全地传输给主体，或者使用带外方法传送到用户。应鼓励主体在接收12到IC卡初始激活数据并使卡激活时，更改初始激活数据13Ic卡的分发应由发卡方、CA(或RA)在审计日志内记录46 GB／T27913—201控制程序主体IC卡的使片|应为主体提供在用户使用期间保护对卡数据．包括存储在I(：卡卜的私钥，进行访问的机制(即PIN访问控14制机制⋯一持卡人验证方法)15lc卡上的主体私钥不应导出到应用程序执行加密(即签名)功能16对于密码应用和声功能，砬要求主体使用双向鉴别机制，以确保系统完整性应要求主体使用应用程序在签名报文(或交易)数据前向}体显示报文或报文摘要。主体Ic卡应用应产生17所有使用Tc卡的审计日志。这包括私钥所有者验证过程中的所有尝试注：如果信任方对交易的可鉴别性和／或完整性有争议．则口r由主体或用户提供此证据18lc卡应由主体或用户根据CP的条款使用1c卡的更换19应创建并遵循过程和程序来更换主体丢失的或损坏的1C矗20卡丢失或损坏时，应根据CP(见8．j．2和85．3)更新主体证书或更新密钥211c卡的更换应由发卡力或CA(或RA)在审计口志内记录IC}的终』r22所有返回给发卡方或CA(或RA)的所有Ic卡应解除激活或安全地销毁，防止非授权访问23IC卡的终止应由发卡方或CA(或RA)在审计日志内记录8．4，4主体密钥管理的要求控制程序主体密钥的生成1CP应规定用于主体密钥生成的密码模块和适当的1s()15782—1级别要求2CP应规定可用于主体密钥生成的密钥生成算法3CP应规定用于主体密钥生成的可接受密钥长度主体密钥的存储、备份和恢复CA或RA应向用户提供机制允许用户访问(即私钥所有人验证方法)、管理和控制私钥的使用并使这些机4制对用户是可用的5CP应规定对存储的主体私钥的保护要求6CP应规定恢复主体私钥时的环境和授权以及控制过程7CP应规定由主体存储的主体私钥的备份副本的保护要求主体密钥使用范嗣银行条款和条件(或单独的用户协议)应描述用户(及主体)使用密码机制(如HSM或Ic卡和软件应用程8序)需要遵循的程序和过程9CP应规定主体密钥对可接受或允许的使用10CP应规定对主体密钥使用的要求主体密钥旧档1lCP应规定归档的主体私钥的保护要求12CP应规定归档的主体密钥在归档期结束时的销毁要求47 GB／T27913—201控制程序主体密钥的销毁13CP应规定可执行主体密钥销毁的方法14CP或CPS应规定在密钥对生命周期结束时主体私钥的所有副本和片断的销毁要求主体密码硬件生命周期管理如果要求，CP应规定密码硬件在其他物理位置时(即HSM连接到主机或远程服务器)使用和处理密码硬件l5以及主体鉴别过程的要求主体密钥泄露16CP应规定主体密钥泄露时对CA或RA的通知的要求8．5证书生命周期管理控制8．5．1主体注册控制目标CA应维持控制以提供合理的保证，确保：主体(或用户)按照适用的“了解你的用户”的要求被准确地识别；主体(或用户)的证书请求是准确的、授权的和完整的控制程序认证与鉴别CA应验证或要求RA验证主体提供的证明其身份或授权的凭证，以证明根据证书策略和法律法规要求该主体可以执行特定的角色a)对于个人终端实体证书，CA或RA应(按照CP所确定的方式)验证姓名包含在证书基本域的主体惟一识别名字段内的人的身份。未经鉴别的个人姓名不应包括在证书基本域的主体惟一识别名当中；1b)对于机构证书(包括基于角色的、服务器、网络资源、代码签名的证书)，CA或RA应(按照CP所确定的方式)验证包含在证书基本域的主体惟一识别名字段机构属性内的机构名称的合法性和请求方的权威性。未经鉴别的机掏名不应包括在证书当中；c)对于包含机构域名的机构证书．CA或RA应(按照CP所确定的方式)验证包含在证书基本域的主体惟一识别名字段通用名属性内的域名的所有权、控制权和使用权。未经鉴别的域名不应包括在证书当中2CA或RA应根据CP验证包含在请求实体的证书请求中的信息的准确性3CA或RA应根据CP检查证书请求中的差错或省略信息4对于终端实体证书，CA应使用包含在实体证书请求中的RA的公钥来验证证书请求提交的签名5CA应在CP定义的边界或在CA服务的群体范围内验证主体惟一识别名的惟一性6应使用加密和访问控制来保护传输和存储中的注册数据的机密性和完整性7在注册时(证书签发之前)RA或CA应通知主体或用户关于证书使用的条款和条件8证书签发前，CA应通知主体或用户关于证书使用的条款和条件证书请求9CA应要求请求证书的实体必须按照CP的要求准备并向RA(或CA)提交恰当的证书请求数据(注册请求)CA应要求请求实体以自签名的报文的形式向CA提交其公钥进行证书申请。CA应要求请求实体使用与注册请求中包含的公钥相关的私钥对注册请求进行数字签名，臣的是：10a)允许在证书应用处理中检测差错；b)证明拥有该注册公钥对应的私钥48 GB／T27913—2011控制程序11证书请求应被认为请求实体已经按照用户西议接受了使用证书的条件条款12CA应在特定CPF验证经授权发出注册请求的RA的身份CA应要求RA在由RA签名的报文(证书请求)中向CA提交请求实体的证书请求数据。CA在接收证书请13求后应验证RA的签名14CA应要求RA根据CA的CPS来保护其(RA)负责的那部分的证书申请过程的安全15CA应要求RA在审计日志中记录他们的行为16CA应根据CA的CPS验证RA提交的请求的可鉴别性8．5．2证书更新(如果支持)l控制目标如果证书更新在CP下得到支持，则CA应维持控制以提供合理的保证，确保证书更新请求是准确的、已授权的和l完整的控制程序证书更新请求证书更新请求应至少包括主体的惟一识别名、证书的序列号(或标识证书的其他信息)和请求的更新证书的1有效期。(CA只更新由他自己签发的证书)2CA应要求请求实体使用与请求实体已有证书中包含的公钥对应的私钥对证书更新请求进行数字签名只有公钥的密码安全性在新证书的预定有效期内仍然足够且没有主体私钥已经泄露的迹象，CA才能使用3主体以前已认证过的公钥来签发新的证书4CA或RA应处理证书更新数据以验证请求实体的身份并鉴别要更新的证书CA或RA应验证证书更新请求上的签名CA应验证要更新的证书的存在性和有效性。除非现有证书状态是有救的(即没有被撤销或挂起)，否则不6应允许更新CA或RA应验证证书更新请求，包括其延长的有效期，符合CP定义的要求。7注：ISO15782】：2003，639也要求更新的证书中有效期的起始日期与原始证书中的相同8如果使用RA，则CA应要求RA在RA签署的报文(证书更新请求)中向CA提交证书更新数据。9RA应根据CP保护它(RA)负责的那部分证书更新过程的安全10CA应要求外部RA在审计日志中记录他们的行为11CA应验证由RA提交的请求的可鉴别性12CA应验证证书更新请求上的RA的签名13CA应检查证书更新请求的差错或忽略的内容。该功能可明确委托给RA14CA或RA应在证书期满前通知主体或用户，证书需要按照CP更新15CA应发布一份签名的通知，指出证书更新已经成功16CA应根据CP使新的证书对终端实体可用 GB／T27913—20118．5．3证书密钥更新l控制目标CA应维持控制以提供合理的保证．确保证书密钥更新请求是准确的、已授权的和完整的控制程序1CA应要求请求实体使用已有私钥对包含新公钥的证书密钥更新请求进行数字签名2CA或RA应验证证书密钥更新请求符合相关CP中定义的要求3如果使用RA，CA应要求RA在由RA签名的报文中向CA提交实体的证书密钥更新请求数据4如果使用RA，CA应要求RA保护它(RA)负责的那部分证书密钥更新过程的安全5如果使用RA，CA应要求外部RA在审计日志中记录他们的行为6如果使用RA，CA应验证证书密钥更新请求上的RA的签名7CA或RA应检查证书密钥更新请求的差错或忽略的内容8CA或RA应在证书期满前通知用户密钥需要更新新证书生成和签发前，CA或RA应验证以下内容：a)对证书密钥更新数据提交所做的签名；9b)该密钥更新请求的存在性和有效性；c)该请求符合CP中定义的要求10在证书撤销后，当用户要求新证书时，实体应被要求根据CP申请新证书11实体证书过期后，当用户要求新证书时．证书可被自动生成，或者应要求实体根据CP申请新的证书8．5．4证书签发l控制目标cA应维持控制以提供合理的保证，确保证书根据cP生成并签发控制程序CA应使用证书请求数据生成证书，并遵照符台GB／T162648和IS(]15782—1格式化规则的证书框架制造1证书2应在CP内设置有效期并遵照GB／T16264．8和ISO15782一l进行格式化3证书扩展域应遵照GB／T162648和ISO157821格式化4CA应用CA的签名私钥签署实体的公钥和其他相关信息5证书应基于根据85．1到85，3的要求核准的主体注册、证书更新或证书密钥更新请求程序进行签发6当RA为主体提交了证书请求，证书被签发给主体时．CA应向RA发出一个签名了的通知证书被签发时，CA应向主体发出一个带外通知。当该通知包括初始激活数据时，控制过程应确保向主体的7安全交付8如果证书过期、被撤销或被挂起，应在cI，中规定的适肖时间长度内保留证书的副本 8．5．5证书分发GB／T27913—2011控制程序CA应使用一种已建立的符合cl’的机制(例如，像目录服务器这样的资料库)使CA签发的证书对相关各方可用。可信的机制包括：1a)收集，资料库或在线目录服务；b)交付，使用受保护的介质(如CI)-ROM或Ic卡)分发2只有授权的CA人员才能管理CA的资料库或其他可替代的分发机制3CA资料库或可替代的其他分发机制的性能应受到监视和管理4资料库或可替代的其他分发机制的完整性应得到维护和管理5当法律对保护个人隐私有要求时，只有在获得主体同意的情况下证书才可被其他相关实体获取8．5．6证书撤销l控制目标CA应维持控制以提供合理的保证，确保按照风险所指示的方式，基于经过授权和验证的证书撤销请求及时撤销该l证书控制程序eA应提供一种快速通信的方法，以便将瞄下汪书安全地、经鉴别地撤销：a)一个或多个主体的一个或多个证书；1b)CA基于生成证书的单个公／私钥对签发的所有证书的集合；c)CA签发的所有证书2CA应验证或要求RA根据CP验证请求撤销汪书的实体的身份和授权3如果RA接受了撤销请求，则CA应要求RA根据CP以一种可鉴别的方式向CA提交签名的证书撤销请求如果RA接受并向CA转发了撤销请求，则CA应向RA提供一个签名的确认以确认收到了该证书撤销请求4和将采取的行动CA应在CP规定的时间框架内遵照GB／T16264．8和1S015782一l定义的格式更新证书撤销列表(CR!。)和5其他证书状态机制6CA应遵照ISO157821：2003在审计日志中记录所有的证书撤销请求段其结果7CA或RA可向发出撤销请求的实体提供一个可鉴别的证书撤销确认(签名或类似方法)8若支持证书更新，当证书被撤销时．所有有效的该证书的实例也应被撤销并不再恢复9应向已撤销或挂起的证书的实体(和用户)通知其证书状态的改变8．5．7证书挂起(如果支持)l控制目标如果支持证书挂起，则cA应维持控制以提供合理的保证，确保按照风险所指示的方式，基于授权和验证了的证书l挂起请求及时挂起证书 GB／T27913—2011控制程序根据CA的CPS，CA提供一种快速通信的方法．以便将以下证书安全地、经鉴别地挂起：a)一个或多个主体的一个或多个证书；1h)CA基于生成证书的单个公／私钥对签发的所有证书的集合；c)cA签发的所有证书2CA应验证或要求RA根据CP验证请求证书挂起和请求证书取消挂起的实体的身份和授权3如果RA接受了挂起请求，则RA应根据CP以一种可鉴别的方式向CA提交签名的证书挂起请求4证书挂起时，CA或RA应通知该主体和用户5应按照CP的要求处理和验证证书挂起请求CA应在证书挂起时更新证书撤销列表(CRI．)和其他证书状态机制。证书状态的更改应在CP规定的时问6框架内完成7证书应根据CP只被在允许的时间长度内挂起一旦证书挂起已经发布，挂起应以下面三种方式之一处理：a)挂起的证书的条目保留在CRI，上，没有进一步动作；8b)挂起的证书的CRI，条目被同一证书的撤销条目代替；c)挂起的证书被明确解除，条目从CRI，中移除证书挂起条目应保留在CRI。上，直到证书期满或挂起期满时间中的一个先到达。CP可规定一张证书可被9挂起的最大次数和处于该状态的最大时间周期。如果达到限度，则可通知PA进行进一步的调查lOCA应在证书取消挂起对根据其CP来更新其证书撤销列表(CRI。)和其他证书状态机制11CA应验证或要求RA验证请求取消证书挂起的实体的身份和授权12证书挂起和取消挂起应遵照IsO157821：2003附录F的要求在审计13志中记录8．5．8证书确认服务l控制目标cA鼍篓持控掣譬雾供合理簟保证，确竺竺据c：跫规则，及时、完整和准确的证书状态信息(包括证书撤销列表和l其他证书状态机制)对相关实体(用户和信任方或其代理·即cVsP)是可用的控制程序CA应根据CP使用已建立的机制使证书状态信息对相关各方(信任方或其代理)是可用的。这可使用以下方式达到：1a)请求响应方式，信任方向证书状态提供方的响应嚣发出一个签名的请求；反过来，证书状态提供方的响应器用适时签名的证书状态信息进行响应(OCSP是一种使用该方法的协议实例)；b)传递方式，由CA签署一CRI，并在策略规定的时间框架内发布该CRI。使用CRI。时的可用控制程序2cA应对发布的每一个CRt．进行数字签名，这样实体可以验汪CR[．的完整性和发布的日期时间3CA应根据CP的规定以固定时间间隔发布CRI。，即使从上次发布以来投有发生改变标识一个撤销了的证书的CRL条目至少应在CRI。上保留到该证书有效期结束。可要求在给定的时间点回4顾证书的状态。因此，CRI。条目可被保持到超过证书有效期的时间，以证明它在使用时的有效性如果支持证书挂起，证书挂起条目连同其原始动作日期和期满日期应保留在CRI．上，直到该证书正常到期或取消挂起6CRI。应根据相应CP的要求，包括归档的CRL的获取方法，进行归档 GB／T27913—201控制程序CRI，应包括CA签发的所有已撤销的未过期证书的条目。可要求在给定的时间回顾证书的状态。因此，7CRI，条目可被保持到超过证书有效期的时间，以证明它在使用时的有效性8旧的CRI。应根据相应CA保留适当时间长度使用在线证书状态机制(如OCSP)时的可用控制程序如果使用在线证书状态收集方式(如OCSP)，则CA应根据相应CP要求证书状态询问(如OCSP请求)包括9所有必须的数据在收到来自信任方或其代理的证书状态请求(如OCSP请求)时，CA应向信任方或其代理返回确定的响应，如果：a)该请求报文格式正确；b)证书状态提供方响应器已有配置来提供所请求的服务；10c)该请求按照相应CP的要求包含证书状态提供方响应嚣所需的信息(即证书标识，序列号——()ID等)；d)证书状态提供方响应器能够定位证书并解释其状态。当这些条件满足时，CA或证书状态提供方应产生签名的响应报文，根据CP的要求指出证书的状态：如果以上条件中的任何一条不能满足，则返回“未知”状态11所有响应报文应进行数字签名并包括CP要求的所有数据8．6CA证书生命周期管理控制8．6．1从属CA证书生命周期管理控制目标上级CA应维持控制以提供合理的保证，确保：从属CA证书请求是准确的、已鉴别并核准的；从属CA证书更换(更新和密钥更新)请求是准确的、已授权并完整的；新的、更新的和密钥更新的从属CA证书根据特定CP的要求生成签发的；一经签发，完整并准确的从属CA证书按照CP的要求对相关各方(用户和信任方)是可用的；从属CA证书基于授权的和验证的证书撤销请求进行撤销；及时、完整和准确的证书状态信息(包括CRL和其他证书状态机制)按照CP的要求对任何相关实体是可用的控制程序从属CA(sub-CA)注册1上级CA应规定提交从属CA认证请求的要求2上级CA应根据其CP鉴别从属CA的证书请求上级CA应在核准从属CA的证书请求前审计从属CA的CP与其自身的CP要求的一致性，或者，可替代的3方法是，从属CA应提交它的CPS供审计从属CA更新4当允许从属CA证书更新时，上级CA的CP应规定提交从属CA更新请求的要求当允许从属CA证书更新时，上级CA应根据其CA的CP鉴别其从属CA的证书更新请求从属CA密钥更新6上级CA的CP应规定提交从属CA密钥更新请求的要求7上级CA应根据其CP鉴别从属CA的证书密钥更新请求 GB／T27913—2011控制程序从属CA证书签筮上级CA应按下列规则生成从属CA证书：a)使用适当的证书框架，符合CP和GB／T16264．8以及IS()157821的格式化规则；8b)具有遵照GB／T16264．8、ISO15782—1和CP的要求格式化了的有效期；c)当使用扩展域时，扩展域根据GB／T162648、ISO】5782—1和CP进行格式化9上级CA应用其签名私钥签署从属CA证书从属cA证书分发上级CA应按照其CP的要求使用已建立的机制(如像目录这样的资料库)使其从属CA证书对相关实体(如10信任方)可用从属CA证书撤销11上级CA应根据CP的要求验证请求撤销从属CA证书的实体的身份和授权12在证书撤销时，上级CA应根据CP的要求更新证书撤销列表(CRI。)和其他从属CA证书状态机制从属CA证书状态信息处理13上级CA应根据其CP的要求使用已建立的机制(如CRL，OCSP等)使从属CA证书状态信息对信任方可用54 A．1证书策略引言和目的附录A(资料性附录)根据证书策略进行管理本附录描述了证书策略并确定了它们如何进行实施，以此来有效管理在契约环境下的PKI内各方的风险。本附录在RFC3647[11]的基础上起草完成，其前身为RFC2527[9]。ISO15782—1和GB／T21077．2提供了在金融服务环境中使用证书策略的进一步阐述。证书策略在可信交易的管理中扮演了关键的角色。CP的主要目的是使信任方能够确定证书及其相关条件对于给定的交易是否是可接受的。同样的，明确指导用户在哪里可使用其私钥来签名交易并将其信任交给支持它的认证服务。A．2证书策略的定义CP是描述证书在指定群体和／或应用类别中适用性的惟一命名规则集。CP作为允许的证书使用及其相关规则的记录和根据各自义务的相关规定，包括所涉及的各方间的责任和管理。证书策略由策略机构负责发布。CP应被证书的各种用户使用，以决定是否接受(证书的)主体和公钥之间的绑定关系。CP在X．509v3的证书内通过一个注册对象标识符(OID)表示。CP的对象标识符可包括在X．509v3证书内的以下扩展域中：证书策略、策略映射和策略约束。对象标识符可不在证书中出现或在上述扩展域的某些或所有这些字段当中出现。证书策略也可使用URI。检索，该URI．可在证书策略扩展中标识。策略机构或其代理可向潜在的用户提供已签名的纸质的证书策略副本，作为一种合同捆绑关系，或向信任方提供已签名的纸质的证书策略副本。另一方面，信任方可使用电子链接定位证书策略。CVSP可向信任方提供服务来确认证书以及相关证书策略的适用性。A．3在证书内建立策略OID用于无歧意地标识证书策略和策略限定符，这样它们可以在使用证书的应用和系统中通过自动化方法处理。这些策略和策略限定符由签发CA在证书的证书策略扩展项中列出，GB／T21077．2中定义如下：certificatePolicjesEXTENSION：：一{SYNTAXCertificatePoliciesSvntaxIDENTIFIEDBYidce—certjficatePolicies在certificatePolicies证书扩展中，对象标识符idcecertificatePolicies标识了一个ASN．1类型certificateP01iciessyntax的值，它定义为：CertlflcateP01iciesSyntax：：一SEQUENCESIZE(1．．MAX)OFPolicvInformationPolicylnformation：：一SEQUENCE{ GB／T27913—2011pollcyIdentifierCertPolicyId，policy’QualifiersPolicy’QualifiersOPTIONAI，CertPo[ieyId：：一OBJECTIDENTIFIERPolicyQualifiers：：一SEQUENCESIZE(1．．MAX)OFPolic"’rQualifierln{o当cert讯catePolicies证书扩展项在证书中出现时，它必须至少有一个Po[icylnformation类型的值。PolicyInfornlation类型的每个实例必须包含一个CertPolicyld类型的值，它标识CP的一个对象类型标识符。PolieyInformation的p。1icyQualiflers组件列出了与给定CP相关的策略限定符。该组件是可选的(不需要一定包括)。certificatePolicies证书扩展项中列出的证书策略是那些签发CA认为适合于该证书的策略。信任方使用该策略信息来确定CA签发的密钥对的恰当使用方法。信任方可在接受一张证书对于一个特定应用是有效的之前，要求特定的证书策略包含在该证书的证书策略扩展项中。典型的，一个CP可与一组应用程序相关联，只有当该CP出现时签发了证书的密钥的所有者才可使用这些应用程序。证书中的每个eertificatePolicies证书扩展项可由证书签发者设置为关键的或非关键的。如果该扩展项被设置为关键的，则该扩展项表示该证书只能由信任方用于该证书策略所指的目的。特定的cP可要求使用证书的系统以特定的方式处理任何限定符的值，进一步限制或扩展证书使用的有效性。如果证书策略扩展项被设置为非关键的，则使用该扩展就不需要限制使用证书的系统根据证书中列出的策略使用证书。但是，信任方或计算机应用程序为了使用证书可要求出现特定的策略。策略限定符根据信任方的选择，可被处理或忽略。当CP限定符与给定的CP关联时，Polieylnformation类型的可选p01l。yQualtflers组件出现，并包含至少一个CP限定符，PolicyQualifierlnfo类型的值定义为：Polic37QualifierInfo：；=SEQUENCE{policyQualifierIdCERT—POI，ICY—QUALIFIER．&id({SupportedP。1icyQualifiers))．qualifierCERT—POLICY—QUAI。IFIER．＆QuMifier({SupportedPolicyQualifiers){@policyQualifierld))OPTl0NAI。、SupportedP01lcyQualifiersCERT—POI，ICY—QUALIFIER：：一{．．．}PolicyQualifierInfo类型由两个组件组成，policyQualifierld和qualifier，它们根据信息对象类CERTPOI。ICYQUALIFIER的＆ld和＆Qualifier域规定。这个类定义为：CERT—POLICYQUALIFIER：：一CLASS{&idOBJECT1DENTIFlERUNIQUE，＆QualifierOPTIONAI．，WITHSYNTAX{POLICY—QUAI。IFIER—ID＆id[QUAI，IFIERTYPE&QuaIifier]}PolicyQualifierInfo的pollcyQualifierId组件根据8Lid域定义，且必须包含一个对象标识符值。可选的qualifier组件根据＆Qua[tfier域定义，且可以包含任何ASN．1类型的值。Policylnformation类型的值为一个CP标识并传递了限定符信息。组件policyldentifier包含r一个CP的标识符，组件policyQualifiers为那个元素包含了策略限定符的值。策略标识符类型可由任何组织注册。以下策略标识符类型在IETFRFC245918]、证书和CRI。框架中定义：a)认证业务说明指针限定符包含了指向cA发布的认证业务说明的指针。该指针是由统一资源定位器(URL)的形式构成。56 GB／T27913—2011b)用户通知限定符包含了在使用证书前将显示给证书用户(包括用户和信任方)的文本串。该文本串可以是IA5串或BMP串GB13000．1多八位编码字符集的子集。CA可调用一个程序要求证书用户确认已经揭示或接受可用的条款和条件。A．4命名的证书策略下的证书适用性一旦各方能够识别和定位与一张证书相关的CP，用户必须能够明确证书的用途和限制。策略机构可以有选择地要求CA签发：a)与一个特定CP有严格关联的证书；或者b)允许～个证书与许多CP关联。有几个问题需要讨论。这根据以下基本假设的背景进行：——证书策略是面向用户的，因为证书提供了一种控制机制来管理提供给用户服务的相关风险；——证书策略和证书的适用性需要被各方识别，包括签发者、用户、信任方和可能的信任方的验证服务提供者；——在新必的信任服务市场内，出现了各种信任服务提供者提供的大量证书。大量证书的各种命名惯例给不明所以的用户造成困惑，不知道哪个证书适用于特定应用。当用户管理证书的知识需要加强时，可以主张针对一些用户透明，金融机构可考虑一对一作为一种最初的谨慎的策略。这将减少混淆，使终端用户更容易学习，并在一个长期的过程中逐渐熟悉+使得软件应用程序更有效地处理多张证书。“一张证书一个cP”也将使得用户更易于知晓证书“如何和为什么”能够被用于特定应用。证书策略以一种对用户友好的，根据责任和义务无歧意且清晰的方式书写也是很重要的。这些内容是用户使用证书的条款和条件，用户们必须清楚地理解。此外，信任方或他们的信任服务提供者将对哪个CP用于当前的证书有明确的信息。除非在交易中明确或预先确定，否则必须有一种可信机制用来确定哪一个是适用的cP。另外，对于交叉认证，清楚说明哪个CP适用于扩展证书使用是很重要的。一证书一CP的策略将使技术上、机构上和操作上的交叉认证要求最小化。A．5交叉认证，证书链、策略映射和证书策略A．51交叉认证交叉认证是两个或更多不同策略机构发布的证书策略的相互认证过程。交叉认证使不同策略机构拥有的证书能够互相使用。交叉认证增加了用户证书使用和可接受的范围。交叉认证要求策略机构和签发CA的控制在策略的互操作方面有一定程度的一致性或等价性。A．5．2证书链验证证书的可接受性时，不仅需要验证从使用证书的终端实体到根证书的整个证书序列，而且也要验证它们各自的证书策略。一个可接受的策略标识符是一个认证路径上的用户要求的CP标识符，或者通过策略映射(见A．5．3)已经声明与之等价的策略的标识符。将证书的策略扩展项设置为关键的，将强制证书应用检查出现在证书链上的证书策略是可接受的证书策略。因此建议证书策略扩展项被设置为一个关键的扩展项。在认证路径验证期间，该扩展项将 GB／T27913—2011与证书的策略约束扩展项一同处理，如ITuT建议X．509标准中所描述。A5．3证书策略映射本证书扩展项允许策略机构，通过其证书签发者指出它的一个或多个证书策略被认为与在该扩展项中使用的另一个CP等价。CP的映射限定由策略机构和认证机构定义，并可通过证书的policyConstraints扩展项进一步约束。本扩展项将通过规定等价证书繁略的OlD来支持交叉认证。本扩展的语法如下：policyMappingsEXTENSION：：一{SYNTAXPolicyMappingsSyntaxIDENTIFIEDBYid—cepolicyMappmgs}PolicyMappingsSyntax：：一SEQUENCESIZE(1．．MAX)OFSEQUENCE{issuerDomainPolicyCertPolicyld，subjectDomainPolicyCertPolicyId)遵照GB／T21077．2，本扩展项可根据证书签发者的判断和相应CP规定设置为关键的或非关键的。CA应为支持策略映射的CA数字签名证书生成策略映射扩展项，并且包括issuerDomainPolicy域、subjectDomainPolicy域和可应用的CertPolicyId域的组合。信任方应将issuerDomainPolicy和subjectDomainP。Iicy组合的CP对象标识符解释为等价的。A5．4策略约束证书的策略约束扩展项支持两个可选的特性。第一，能为认证机构在认证路径上的所有后继证书指出明确的CP。证书用户认为认证路径起始的证书是一个信任域的一部分(即认证机构对所有应用目的都是可信的，这样在证书策略扩展中就不需要特定的CP)，这样的证书不需要包含明确的CP指示。但是，当一个信任域中的认证机构认证另一个信任域的证书时，它可在认证路径上随后的证书中激活明确指示的CP。使用时，r8quireExplicitPolicy约束项要求所有的证书都包括一个可接受的策略．而不仅仅是那些随后声明了要求的证书。策略约束扩展项的其他可选特性是对于认证机构能够禁止认证路径上随后的认证机构设置的策略映射。当对另一个信任域进行认证时，禁用策略映射是谨慎的选项。这可以辅助控制因信任传递带来的风险(如域A信任域B，域B信任域c，但是域A不希望被迫信任域c)。本扩展项的语法如下：policyConstraintsEXTENSION：：一{SYNTAXP01icvConstramtsSvntaxIDENTJFIEDBYidceDo】icyConstrajnls)PolicyConstraIntsSyntax：：一SEQUENCE{requireExplicitPollcy0SkipCertsOPTIONAL，inhibitPolicyMapping[1]SkipCertsOPTIONAI。}SkipCerts：：一INTEGER(0．MAX)遵照GB／T21077．2，本扩展应被标记为关键的。A．6证书类型由于各种用户对解决方案的要求不同，可能要求的证书类型是复杂的。策略机构可采用通用目的策略的证书策略，不去限制其使用。作为选择，策略机构也可为特定目的建立证书策略以约柬不适当的58 GB／T27913—2011使用或限制责任。因此，终端实体证书的主要类型是：——特定应用(基于属性)证书：在明确要求授权的地方，签发这些证书来支持特定的应用、产品和／或服务；一普通证书：基于特定信息的可鉴别性的单个证书，证明公钥持有者的身份，其身份构成了授权的基础。注：单个证书可被用于支持多个应用。单个证书的使用将需要符合最高级别分类应用的要求。一般认为通用目的证书对于用户将占优势，因为：～⋯只基于ID的证书很可能在中长期内经常使用；——在中长期内，基于属性的证书或定制的证书可以是增值价值的来源；——数字签名和证书的内外部使用还没有被充分挖掘或开发。交易中的每个实体对业务风险都需要大量的保障，保障程度根据该方的角色和对风险的关注程度有所不同。一种“适用于的”的方法在A．7中讨论。一般而言，早期信任服务市场是一个技术不成熟的市场，在初期部署时就提出定义一个考虑到策略粒度包能够包罗万象的系统是不可行的。建议签发普通证书给用户，用米在PKI部署的初始阶段为所有类别的服务建立最小要求系统。这一方法考虑了随后的补充要求，这些要求可由市场为证书策略和相关信任服务的进一步分类而提出。存在其他类型为特定目的指定的证书策略，如服务器证书和使用证书创建PKI层次结构或树状结构。A．7证书分类和命名证书的分类可区别不同级别的保障，并描述特定第三方签发、管理、挂起和撤销证书的责任。每个级别或证书类别提供特定的功能性和安全特性。对于信任方和用户非常关键的问题是确定在一个CP下签发的特定证书提供的保障等级。已识别的策略机构的选项包括以下内容：⋯一基于任意值的CP分类，如铜、银、金：应注意到，这将使针对特定安全服务能力的线性度量比较困难。类别之间的差异可以是多维的，并且可包含独特的属性，与其他类别没有准确的可比性。使用证书分类名使它们的使用和功能性具有一个“相对值”；——对于契约环境基于公认标准的CP分类：对于终端用户，这些证书类的使用在与它们的使用相关的安全类型和责任问题上映射了一个“绝对值”；策略机构也应考虑下列情况：一数字证书可在电子市场中代表熟知的品牌；——用户和商业信心是品牌认可的尺度，依附于安全的产品和服务，包括证书功能性和适用性等级；其他没有隐含值(如1、2、3)的命名规则可以使用，集中于建立使用差别而不是相对优点，但是在金融服务的背景中这些似乎不可能适用于产生信任；——标准的使用作为一个普遍理解的基准，但是，需要注意运用在规定的级别上，以避免对使用旋加任何约束。基于绝对值，如低、中、高的证书分类可能不能确切反映金融机构为基于电子化信任服务开发所要求的信任保障类型。为了促进更大范围的可接受性，减少终端用户对证书使用的迷惑，对于证书策略建议遵循公认的标准或契约环境内所有各方都同意的规定。 GB／T27913—2011A8证书策略规定A．8．1概述本条款简要描述了CP的条款。A．8．2解释cP应在引言中根据其提供的服务来概括cP是作什么用的，对于使用群体的前提条件是什么，以及法律上有约束力的合同条件，这也可包括适用于群体及证书使用的任何要求。本附录应描述证书使用群体及其证书预计的使用(如证书是否可用于远程鉴别的目的、数字签名或数据机密性)。它也可规定对使用群体成员的会员要求(如证书可只签发给私有账户持有者，信任方必须与由策略机构核准或许可的实体签订协议等)。A．8．3义务每个实体的主要义务是根据他们各自的角色规定——策略机构、CA、用户、信任方和证书确认服务提供者。策略机构负责确保根据与合同各方达成协议的条款或方案执行有效的和可信的服务。CA负责确保证书根据cP签发。CA也负责确保证书状态的变化在cP规定的期限内，在它自己的资料库和授权的证书确认机构的资料库中反映出来。用户负责根据用户协议的条款保护对私钥的访问。这表示任何对使用私钥的访问从不泄露给他人(如PIN对于非授权用户)。也要求用户在他们认为私钥泄露时通知注册机构或代理。当决定是否依赖于一个证书时，尽管私钥已经用于交易，信任方应行使合理的判断，但必须只依赖于没有撤销、挂起或过期的证书。他也有责任确保与当地法规的一致性。A．8．4强制cP必须规定监管法律、适用的合同或方案，以便在条款冲突或缺乏已定义的规则或引用时建立权威性的规则。A．8．5责任我们将集中于关注用户和信任方的商业责任。用户的责任总是由一个合同关系涵盖。签发和使用证书的条款和条件由适当的cP涵盖。这些将在用户获得证书前建立并可以设计来确保所有预期的责任被明确，并且，如果可能，将受到限制。对信任方的责任更为复杂。如上所述，信任方与任何CA／RA／资料库可以没有合同关系，但可使用一个已知并可信的证书确认服务提供者的服务。以下三个简单的例子说明了各种控制或限制责任的方法：——cP可确定这样的环境，在这里信任方只需要检查证书签名的有效性并且签名是在证书有效期内做的。在这种情况下，类似于支票担保卡，就足以依赖其本身的证书可鉴别性·虽然该项策略在特定“交易”上可能是限制责任的。因此，证书的价值被信任方看做是有保证的并且是有限制责任的；——其他环境中，cP可要求(但不强制)信任方在接受一张证书前从CA／RA(通过资料库)获得该证书的在线验证。以这种方法，证书完全作为一种没有内在价值的认证方式。每个交易被有效地在线授权，对于非授权的交易不承担责任；——当信任方能控制其使用证书的软件／环境时，可以提出信任方协议，该协议必须在证书可以使 GB／T27913—2011用前被信任方主动地接受。只有在这种方式成为一种使用证书的标准方法并被广泛用于商业和免费产品中时，如浏览器和电子邮件，才是限制责任的可靠方式。A．8．6操作要求应说明以下带有特定时间规定的过程：——包括身份凭证类型的初始注册申请；证书请求、签发和接受；——证书确认方法；一证书挂起和撤销，以及证书撤销和挂起的原因(包括谁授权的，相应程序和通知)。应陈述证书更替如何管理(如身份的自动或重新验证)或者是否需要生成新的密钥对。还应陈述证书的更改(如果支持)如何管理(如为r更改已有证书中的信息，需要什么祥的鉴别程序)。这里可陈述技术性的安全控制，详细说明公私密钥对如何生成并安装，以及关于表明一致性的标准。对私钥的访问管理的控制方法也与私钥托管、备份和归档的规则一起给出。应附加证书框架以说明在各个字段应设置什么值。并且对如何确定那些值提供指导。A．9证书策略管理CP必须说明它的惟一名称、策略限定符、策略版本、状态、策略参考OID和发布日期，如果适用，还包括它的到期日期。CP应包括策略机构的详细联系方式，包括邮政地址、电话号码、业务运行时间和可能提供客户支持的电子邮件地址。发布和资料库的详细联系方式应连同阐明以f内容的方法一起明确说明：⋯CP的管理；——策略信息的机密性；——变更控制过程；——变更通知；——认证凭证和注册过程。CP应有一个起始日期，可能的到期日期。在没有策略到期日期的情况下管理具有不同失效期的签发证书是困难的。还应陈述CP的纸质和电子副本可在哪里获取。CP应描述策略机构调用的过程，用来检查CA的CPS能够支持CP要求。策略机构必须确保CA的CPS中规定的控制适合于支持其CP。在规定的时间周期内(如两年)根据CPS审计CA的正式方法应在策略机构和CA间达成一致。如果CA希望在其CPS中变更条款，则建议使用这种方法以及经过协商解决争议的方法来快速解决问题。 GB／T27913—2011B．1概述附录B(资料性附录)认证业务说明的要素认证业务说明应包含本附录中包括的所有组件和子组件的引用。CPS不需要包括每个主题的确定性陈述。特定的CPS对组件、子组件或元素没有要求时可声明为“不实施”。这将指示读者清楚地作出决定是包括或是排除那一主题。这样在决定业务应用的适用性时便于比较不同的认证业务说明以确认哪一个更合适。本附录遵循RFC2527[9]的结构，它已经被RFC3647[11]取代。从RFC2527到RFC3647的变化可见附录E中的映射表。B．2引言B．2．1概述CPS的引言部分有以下子部分：——综述；——认证；——参与群体和适用性；——详细联系方式。B．2．2综述本子部分提供了一般性的介绍(如业务规则的通用目的)。B．2．3认证本子部分提供可用名称或其他标识符，包括ASN．1对象标识符。B．2．4参与群体和适用性本子部分描述了签发证书或主体cA的实体类型，执行RA功能的实体类型和、主体终端实体或用户的实体类型。注：主体CA的实体类型类似从属组织(如银行，支行或分行，政府代理或部门)。例如，假设一家银行声明它只向其支行签发CA证书，那么使用该银行签发的CA证书中的主体CA就是该银行的支行。主体RA实体类型类似客户服务或数据安全部门。主体终端实体类型类似零售或批发银行客户、持卡人、个人投资者、保险客户和雇员。本子部分也包括：——签发的证书适用的应用列表；——使用签发的证书受到限制的应用列表，或者使用签发的证书受到禁止的应用列表。B．2．5详细联系方式本子部分包括负责注册、维护和解释CPS的机构的名称和邮件地址。也包括所有适当联系人的名称、电子邮件地址、电话号码和传真号码。62 B．3一般规定B．3．1概述GB／T27913—201本部分在法律和一般业务主题范围内规定了适用的规则，包括：——义务；——责任；——解释和强制；——发布和资料库；——一致性审计；——机密性。每个子部分必须分别说明用于实体类型的规定，这里所指的实体类型包括：CA、资料库、RA、用户和信任方。B．3．2义务对于实体类型，本子部分包括实体对其他实体的义务规定，这些规定为——CA和／或RA或证书状态提供者义务：·向正在签发的证书的主体发出证书签发通知；·通知证书主体外的其他各方证书已经签发；·通知证书被撤销或挂起的用户其证书已经撤销或挂起；·通知除了主体以外的其他各方主体证书已经撤销或挂起。一用户的义务：·在证书应用中其相关证书信息是准确的；·保护实体的私钥；·保护使私钥可用的机制(即持卡人验证方法)；·限制私钥和证书的使用；·对私钥泄露进行通知。——信任方的义务：·明确证书使用的目的；·数字签名验证责任；·撤销和挂起的证书的检查责任；-适用的赔偿责任上限和担保的确认。——资料库义务：·及时发布证书和撤销信息。——证书状态提供者：·使验证服务可用，且在协议规定的服务级别时间内响应；·准确验证证书。B．3．3责任对于每个实体类型，本子部分包括责任分配的适用规定，如：——担保和担保的限度；——各种隐含的损害(如间接的、特殊的、作为结果的、偶然的、惩罚性的、清偿的破坏、疏忽和欺诈)和放弃声明； GB／T27913—2011——每张证书或每笔交易的损失限度(上限)；——其他被排除的因素(如不可抗力、其他方的责任)。B．3．4解释和强制本子部分包括CP或CPS的解释和强制的适用规定，针对以下主题——团体安全策略和程序；——监管法律；——规定的中止、生存、合并和通告；——争议解决程序。B．3．5发布和资料库本子部分包括关于以下内容的适用规定：——cA具有义务使得与其业务、证书和证书当前状态有关的信息是可用的或可获取的——发布频率；——发布信息的分类，包括CP的定义、CPS、证书、证书状态和CRI。；——与资料库使用有关的要求，包括在线证书状态验证(如果支持)。B．3．6一致性审计本子部分提出以下内容：——每个实体的一致性审计频率；——审计者与被审计实体的关系(即声明审计者必须是独立的)；——一致性审计的主题列表，包括CA环境控制、密钥管理控制和证书生命周期管理控制。B．3．7机密性本子部分提出以下内容：——应由CA或RA保密的信息的类型：——不认为是保密的信息类型；——谁有资格被通知证书撤销和挂起的原因；一向法律强制机关释放信息的策略；——可作为当事人证据收集义务部分因遵守法规要求而揭示的信息；——cA或RA在信息拥有者要求下可揭露的信息和可以向谁揭露的条件——机密信息可被揭露的其他情况。B．4认证与鉴别B．4．1概述本部分描述在证书签发前提交给CA或RA的用于验证证书申请的程睁。也描述了如何验证请求密钥更新或撤销的各方。本部分也描述了命名业务，包括名称所有权识别和名称争议解决。本部分包括以下子部分：——初始注册；——常规密钥更新；——撤销后的密钥更新；——撤销的请求；64 一一挂起的请求。B．4．2初始注册GB／T27913—201本子部分包括以下实体注册或证书签发期间与认证和鉴别程序相关的内容：分配给主体的名称的类型；注l：例如X500中的识别名．互联网电子邮件地址和URI，。名称是否必须有意义；注2：术语“有意义”的意思是名称的形式具有通常可以理解的语法，能够确定人和／或组织的身份。目录名和RFC822名或多或少可以是的有意义。一解释各种名称形式的规则；——名称是否必须惟一；——如何解决名称的争议；——识别、鉴别和商标的角色；——是否需要主体证明他拥有与正在注册的公钥相对应的私钥，主体如何证明他拥有与正在注册的公钥相对应的私钥；注3：例如签发CA生成密钥，或者要求主体发送一个电子签名的请求．或者签名一个口令。对主体(CA、RA或终端实体)的机构身份的鉴别要求；注4：机构身份鉴剐的类型包括公司条例文件、适时签署的法人决议、公司印章和公证文件。对代表主体(CA、RA或终端实体)进行相关业务的人员的鉴别要求；注5：个人身份鉴别的类型包括物理识别、个人的知识、生物特征(拇指指纹、十指指纹、面容、手掌和视网膜扫描)的身份鉴别卡、驾驶执照、护照、语音识别或巴建立的雇员监别方法。——所需的认证证明材料的数量；——cA或RA如何验证各种认证证明材料是真实的：作为可选的用于远程验证身份的程序；¨啊是否个人必须亲自到场，出现在进行鉴别的CA或RA现场；⋯如何鉴别作为机构代表的个人，以及他们是否被公司委托代表公司进行相关业务。注6：例如适时签署的授权文件或机构ID证章。B．4．3常规密钥更新本子部分描述r对每个主雄类型(CA、RA和终端实体)进行常规密钥更新的认证与鉴别程序。注：常规密钥更新的认证业务应与初始注册时相同。除非已到期的证书在过期前被用于鉴别。密钥更新鉴别可使用用于初始认证与鉴别的技术实现．或者使用数字签名的请求实现，B．4．4撤销后的密钥更新——无密钥泄露本子部分描述了对每个主体类型(CA、RA、CVSP和终端实体)在主体证书撤销后进行密钥更新的认证与鉴别程序。如果证书已经撤销，则其状态不能改变。这个认证与鉴别业务应与初始注册时相同。B．4．5撤销请求本子部分描述了每个主体类型(CA、RA和终端实体)或其他(根据CP规定的)授权方或监管方发出的证书撤销请求的认证与鉴别程序。注：因为相同主体的证书需要被撤销，则撤销请求的认证业务可以与初始注册时相同。鉴别业务可以接受主体数字签名了的撤销请求。对于撤销请求，初始注册期间使用的鉴别信息可以被接受。其他不太严格的鉴别方式也可眦被定义。6j GB／T27913—2011B46挂起请求本子部分描述了每个主体类型(CA、RA和终端实体)或其他(根据CP规定的)授权方或监管方发出的挂起请求的认证与鉴别程序。注：因为相同主体的证书需要被挂起，则挂起请求的认证业务可以与初始注册时相同。鉴别业务可以接受主体数字签名了的挂起请求。对于挂起请求，初始注册期问使用的鉴别信息可以被接受。其他不太严格的鉴别方式也可以被定义。B．5操作要求B．5．1概述本部分用于规定施加于签发CA、主体CA、RA、CVSP或终端实体的各种操作活动的要求。本部分包括以下子部分：——证书申请；——证书签发；——证书接受；——证书确认；一证书挂起和撤销；——安全审计程序；——记录归档；——密钥改变；——泄露和灾难恢复；——CA终止。在每个子部分内，对于签发CA、资料库、主体CA、RA和终端实体必须分别考虑。B．5．2证书申请本子部分用于说明主体登记注册和请求签发证书的有关要求。B．5．3证书签发本子部分用于说明证书签发和通知申请者该证书的签发情况的有关要求。B．54证书接受本子部分用于说明对已签发的证书的接受和随之发布该证书的有关要求。B．5．5证书挂起、撤销和状态管理本子部分描述了以下内容：——撤销证书要满足的条件；——谁可以请求撤销实体的证书；——用于证书撤销请求的程序；——对主体可用的撤销请求的宽限期——挂起证书需要满足的条件；——谁可以请求挂起证书；——请求挂起证书的程序；66 GB／T27913—2011挂起可持续多长时间；挂起的证书可返回有效状态要满足的条件；——如果使用CRI．机制，CRI．发布的可用性和其更新的频率；——对信任方检查CRL的要求；——在线状态检查的町用性和保证的响应时间；——对信任方执行在线状态检查的要求；——对证书状态提供者鉴别信任方状态H自应的要求；其他形式的官方挂起、撤销或证书状态通知；——对证书确认机构和信任方检查其他形式的官方挂起、撤销或证书状态通知的要求；——当挂起或撤销是由于私钥泄露所导致时(与其他挂起或撤销的原因相对)，以上约定的变化。B．5．6安全审计程序本子部分用于描述事件日志和审计系统。包括以下内容：一记录的事件类型；注：审计事件的示例如请求创建证书、请求挂起或撤销证书、密钥泄露通知、证书的创建、证书的撤销、证书的签发、CRI。的签发、密钥泄露CRI．的签发、CA可信角色的建立、可信人员的行为、CA密钥的变更等。——处理或审核审计日志的频率；——审计日志的保存周期；-__审计日志的保护；谁在什么授权下可以查看审计日志；——防止审计日志的修改；——防止审计日志的删除；审计日志备份程序；——对实体的审计日志积累制度足内部的还是外部的；——是否在审汁过程中通知导致审计事件发生的主体；——脆弱性评估。B．5．7记录归档本子部分用于描述一般的记录归档(或记录保留)策略，包括以下内容：——记录的事件类型；注：归档事件的示例有：请求创建证书、请求撤销证书、密钥泄露通知、证书的创建、证书的撤销、证书的签发、CRL，的签发、密钥泄露CRL的签发和CA密钥的变更。一归档的保留期；——归档的保护：·谁可以查看归档文件；·防止修改归档文件；·防止删除归档文件；——归档的备份程序；记录的时问戳要求；归档收集制度是内部的还是外部的；——获取并验证归档信息的程序。B．5．8密钥更改本子部分描述向CA用户提供新的公钥的程序。67 GB／T27913—2011B．5．9泄露和灾难恢复本子部分描述了在泄露或灾难事件发生时与通知和恢复程序有关的要求。以下每种情况需要分别描述：一如果计算资源、软件和／或数据被破坏或怀疑受到破坏，则使用恢复程序：这些程序描述如何重新建立安全环境，哪些证书被撤销，实体密钥是否撤销，新的实体公钥如何提供给用户，以及如何重新给主体签发证书；——如果实体公钥被撤销，则使用恢复程序：这些程序描述如何重新建立安全环境，如何获得新的实体公钥以及如何重新签发实体证书。B．5．10CA终止本子部分描述与CA或RA的终止以及终止的通知相关的程序，包括CA和RA归档记录管理人的身份。从法规和风险的角度应对保留付‘么信息给予考虑。B．6物理的、程序性的和人员的安全控制B．6．1概述本子部分描述了签发CA使用的物理的、程序性的和人员的控制，安全地执行密钥生成、主体鉴别、证书签发、证书撤销、审计和归档的功能。本子部分也可以用于定义对资料库、主体CA、RA和终端实体的控制。对主体CA、RA和终端实体的控制可根据实俸的不同而变化。这些控制对信任证书是关键的，因为缺乏物理、程序性和人员安全则可破坏CA的运行，导致带有错误信息的证书或CRI。生成，或者CA私钥的泄露。本子部分包括三个子部分：一～物理安全控制；——程序性控制；一一人员安全控制。在每个子部分内，通常需要对每个实体类型分别考虑．即签发CA、知识库、主体CA、RA和终端实体。B．6．2物理安全控制本子部分中描述r对放置实体系统的设施的物理控制。注：物理访问控制的示例有：监视的设施、保护的设施、锁定的设施、使用令牌控制的访同、使用生物鉴别控制的访问和通过访问控制列表控制的访问。描述的主题可包括：——场地的地点和建设；～物理访问；一～密码硬件；——电力和空调；一排水；——防火和保护；一电磁防护；～介质保存；68 GB／T27913—201一一废物处理；异地备份。B．6．3程序控制本子部分中描述了对于识别可信角色的要求，以及每一角色的责任。注：角色的示例包括系统管理员、系统安全员和系统审计员。系统管理员的责任是配置、生成、引导和操作系统，系统安全员的责任是分配账户和权限。系统审计员的责任是建立系统审计配置文件、进行审计文件管理并执行审计审查。对于为每一角色确定的任务，也应说明如何要求多人来执行任务(m分之“规则)。也可为每一角色定义认证与鉴别要求。B．6．4人员安全控制本子部分描述以下内容：——对承担可信角色的人员所要求的背景检查和安全检查程序；注1：背景检查可包括安全检查级别(如无保密要求、敏感、保密、机密、顶级机密等)和安全级别批准方名称。除了定义的安全检查，背景检查可包括背景信息的类型(如名称、出生地、出生日期、家庭地址、前居住地、以前的职业和其他可帮助确定可信性的信息)。描述还应包括哪些信息被验证．如何验证。——对其他人员，包括门房人员的背景检查和安全检查程序要求；注2：例如．CP可对负责CA网络访问的网络系统管理员施加人员安全要求。——对每个角色的培训要求和培训程序；一～因为非授权行为、非授权使用权力以及人员对实体系统的非授权使用从而导致的对相关人员的执行纪律程序；注3：每个授权人员应对其行为负责。——对合同人员的控制；--提供给相关人员的文件(如操作或培训手册)。B．7技术上的安全控制B．7．1概述本子部分用于定义签发CA为保护其密钥和激活数据(如PIN，口令或手工持有的密钥分享组件)而采取的安全措施。本子部分也可用于对注册机构、资料库、主体CA和终端实体施加约束以保护他们的密钥和关键安全参数。安全的密钥管理对于确保所有密钥和激活数据受到保护并只被授权人员使用是很关键的。本子部分也描述签发CA使用的其他技术上的安全控制，以安全执行密钥生成、用户鉴别、证书注册、证书撤销、审计和归档的功能。技术上的控制包括生命周期安全控制(包括软件开发环境安全、可信软件开发方法)和操作安全控制。本子部分也可以用于定义对资料库、主体CA、RA和终端实体的其他技术上的安全控制。本子部分有以下各部分：一密钥对生成和安装；——私钥在存储和使用中的保护；——cA或发卡方创建的私钥的分发；——密钥对管理的其他方面；——激活数据；69 GB／T27913—2011——计算机安全控制；——生命周期安全控制；——网络安全控制；——密码模块工程控制。B．7．2密钥对生成和安装需要为签发CA、资料库、主体CA、RA和主体终端实体考虑密钥对的生成和安装。对于每个实体类型，需要回答以下问题：——谁生成终端实体的公私密钥对；——私钥如何保存并安全地提供给终端实体；——实体的公钥如何安全地提供给证书生成者；——如果实体是CA或证书状态提供者(签发者或主体)，则该实体的公钥证书如何安全地提供给终端实体；——使用什么算法，密钥长度是多少；——谁生成公钥参数；——密钥生成时是否检查参数的质量；——密钥生成是在硬件还是在软件中执行；——密钥可被用于何种目的，或者密钥的使用应被限制于何种目的(对于X．509证书，这些目的应在X．509v3证书中映射为密钥使用标记)。B．7．3私钥保护需要为签发CA、资料库、主体CA、RA和主体终端实体考虑私钥保护的要求。对于每个实体类型，控制要求可以是不同的，为了能够确定这个不同，需要回答以下问题：——用于生成密钥的模块需要什么标准?——私钥是在m分之n多人控制下的吗?如果是，提供n和m的具体值(两人控制是m分之n的特例，其中”一m一2)。注1：m分之n规则允许密钥或密钥激活数据被分剖成m份。m份可被分给m个不同的个人。这m份中的任何n份可被用来完全重建密钥。但拥有任何”一1份并不能提供有关密钥的任何信息。——私钥被托管吗?如果是。谁是托管代理，密钥以何种形式托管(如明文的、加密的和分割密钥的)，托管系统的安全控制是什么；注2：密钥可被托管、备份或归档。每个功能都有不同的目的。这样，根据需要密钥可由这些功能的任何子集进行处理。托管的目的是允许第三方(如机构或政府)在法律上无需主体的协作蔼获得密钥。备份的目的是允许主体在密钥受到破坏时重建密钥。归档的目的是提供密铜在未来重新使用(如使用私钥解密文件)。——私钥备份吗?如果是，谁是备份代理，密钥以何种形式备份(如明文的、加密的、分割密钥的)，备份系统的安全控制是什么；——私钥归档吗?如果是，谁是归档代理，密钥以何种形式归档(例子包括明文的、加密的、分割密钥的)，归档系统的安全控制是什么}——谁将私钥输入到密码模块?以何种形式(即明文的、加密的或分割密钥的)?私钥如何存储在模块内(即明文的、加密的或分割密钥的)；——谁可以激活(使用)私钥?激活私钥必须执行什么动作(如登录，开机，提供PIN，插入令牌／密钥，自动地等)一旦密钥被激活，密钥是在一个不确定的时间周期内处于激活状态、激活一次还是在一个定义了的时间周期内处于激活状态；——谁可以解除私钥的激活，如何解除?如退出、关机、移除令牌／密钥、自动地或时间过期I70 ——谁可以销毁私钥，如何销毁?如令牌放弃，令牌销毁或密钥数据重写。B．7．4密钥对管理的其他方面GB／T27913—2011需要为签发CA、资料库、主体CA、RA和主体终端实体考虑密钥管理的其他方面。对于每个实体类型需要回答以下问题：——公钥归档吗?如果这样，谁是归档代理，对归档系统的安全控制是什么?归档系统应提供除数字签名外的完整性控制，因为归档期可以比密钥的密码分析时间长，并且归档需要防篡改保护，而数字签名无法提供；——公钥和私钥各自的使用期，或有效生命期是什么，B．7．5激活数据对私钥的访问在初始和整个有效使用期内需要受到控制和保护。激活数据在鉴别机制中用于验证私钥的所有者。激活数据指除密钥外需要操作密码模块并需要受到保护的数值。需要为签发CA、主体cA、RA和主体终端实体考虑激活数据的保护。这种考虑需要描述激活数据从生成到归档和销毁的整个生命周期的保护程序。对于每个实体类型(签发CA、资料库、主体CA、RA和主体终端实体)，B．7．2到B．7．4中列出的所有问题都需要就激活数据而不是密钥来回答。注：激活数据的实例有PIN，通行字或生物特征。B．7．6计算机安全控制本子部分用于描述计算机安全控制，如：使用可信计算概念，自由决定的访问控制，标记，强制访问控制，对象重用、审计、认证与鉴别、信任路径、安全测试和穿透性测试，也可描述产品保障。B．7．7生命周期安全控制本子部分描述系统开发控制和安全管理控制。系统开发控制包括开发环境安全、开发人员安全和产品维护期间的配置管理安全、软件工程实践、软件开发方法、模块化和分层，故障保护设计的使用和实施技术(如防御程序设计)和设备安全开发。安全管理控制包括运行工具和程序，确保运行系统和网络遵循配置的安全性。这些工具和程序包括检查安全软件、防火墙和硬件的完整性，确保它们正确运行。B．7．8网络安全控制本子部分描述网络安全相关的控制，包括防火墙。B．7．9密码机制工程控制本子部分描述密码模块的以下方面：密码模块边界的鉴定、输入／输出、角色和服务、有限状态机、物理安全、软件安全、操作系统安全、算法遵从性、电磁兼容和自测。相关要求可通过参考标准来表达。注：密码机制是硬件、软件和使用特定设备时相关固件的组合。遵从性描述应是详细具体的。例如，对于每个相关国家标准的要求，描述该设备的级别并说明公认的实验室是否已经鉴定了该设备的级别，B．8证书和CRL框架B．8．1概述本子部分用于规定证书格式，如果使用CRL，还需要规定CRL的格式。如果假设使用X．509证书和CRL格式，这包括框架信息、版本和使用的扩展，以及它们是否需要进行数字签名。71 GB／T27913—2011本子部分包括三个部分：——证书框架；——CRL框架；——ocsP框架。B．8．2证书框架本子部分描述以下主题：——支持的版本号；——使用的证书扩展及其关键性；——密码算法对象标识符；——用于CA、RA和终端实体的名称形式；——使用的名称约束以及在名称约束中使用的名称形式——适用的证书策略对象标识符；——策略约束扩展的使用；——策略限定符语法和语义；——对关键证书策略扩展的处理语义；——非标准扩展的内容和使用。B．8．3CRL框架本子部分描述以下主题：——支持CRL的版本号；——cRL更新的可用性和频率；——cRL是否需要进行数字签名；——使用的CRL和CRL条目扩展以及它们的关键性。B．8．4OCSP框架如果应用OCSP，本子部分描述以下主题——OCSP请求的要求；——确定的响应报文的要求；——可用性和保证的响应时间；——状态响应是否需要进行数字签名；——差错报文的要求。B．9实施管理B．9．1概述本子部分用于规定如何维护实施。包括以下各部分：——修改程序；——发布和通知程序；——CP一致性。 B．9．2变更程序GB／T27913—2011有时需要变更证书策略和认证业务说明。有些变更不会从本质上降低CP或其执行所提供的保障，并且也将由策略管理员判断在现有的策略下，这些变更不会改变证书的可接受性。这种证书策略和认证业务说明的变更不需要在CP对象标识符或CPS指针(URL)中变更。其他对CP和CPS的变更将改变用于特定目的的证书可接受性，这些变更将需要对CP对象标识符或CPS指针进行变更。本子部分包括以下信息：——无需通知就可以变更的部分、子部分和／或其他项目的列表，CP对象标识符或CPS指针(URL)也无需变更；——在通知期后变更的部分、子部分和／或其他组成部分的列表，而不变更CP对象标识符或CPS指针(URL)。描述用于通知和CP或认证业务说明变更有关系的各方(信任方、认证机构等)的程序。通知程序的描述包括通知机制、通知评价期、接收机制、审阅并结合评价、策略最后变更的机制和最后的变更生效前的时期；——需要变更CP对象标识符或CPS指针(URL)的部分、子部分和／或其他组成部分的列表。B．9．3发布和通知程序本子部分包括以下内容：——存在但没有公开的部分、子部分和／或其他项目的列表；注：因为其敏感性，机构可选择不公开某些安全控制、安全检查程序或其他项目。——描述用于分发CP或使其可用的机制，包括访问控制。B．9．4CP一致性本子部分搂述检查CPS符合CP要求的过程。73 GB／T27913—2011C．1为什么有OlD附录c(资料性附录)对象标识符(oID)使用OID可以使得信任方自动地识别CP(如建立了一个或多个策略域的根CA适用的cP文件)。每个从属CA将需要一个OID来标识他们的CPS。C．2什么是OID对象标识符是明确标识信息对象的一个惟一的整数序列。ASN．1标准把信息对象定义为“定义好的一则信息、定义或规定，它需要一个名称以标识它在一个通信实例中的使用”。对象标识符可用于为任何内容提供一个名称，包括CP、CPS、密码算法、业务、机构、文件格式、角色、产品、设备、文件版本或标准。ISO／TC68组织由对象标识符1．3．133标识。该值是TC68⋯arc，是TC68作为注册管理者控制的OlD值，TC68被ISO授权在其下分配对象标识符。TC68成员国家在OlDl．3．133．16下标识，每个TC68成员国家被分配了他们自己的OlD，由他们自己独自负责这些标识符的注册。OID可从TC68秘书处或被选为分配这些值的成员国家获得。所有TC68标准的集合由OIDl．3．133．17标识。本文件由OID1．3．133．17．21188标识。OlD可通过任何种类的途径传达，通过语音、纸上手写或计算机程序，这样这些值的表示形式可以广泛地变化。本文件的OID可t：A--进制格式表示，方便应用程序的使用，或者使用ASN．1表示，基本值符号为“iso(1)identitled—organization(3)tc68(133)standard(17)pki—c1)_cps(21188)”，或者使用ASN．1XML表示，作为XML标记值的符号为“(pkicpcps)1．3．133．17．21188(／pkicp-cps)”。设想策略OID被嵌入到数字证书内，这样PKI服务提供者、终端实体和其他实体可确定签发者／证书生成者生成证书所使用的规则集合。CP的OlD的标准集合使数字证书应用程序能够自动处理策略和业务信息。应为每个证书策略获取对象标识符并注册，以惟一标识该策略。获取OID的典型方法是到适当的国家注册机构获取OID。C．3OlD的注册GB／T17969．1—1993的X．660建议书定义了注册机构运行的一般程序。当前国际标准由国际标准化组织(ISO)、国际电工委员会(IEC)和国际电信联盟(ITu)联合批准。这些国际标准组织控制所有的顶级OIDarc，即可出现在任何OlD整数序列第一个位置的值。这些值表示为OID值“itu—t(o)”，“iso(1)”和“joint。iso—itu-t(2)”，形成了所有OlD值的注册分级命名树(RH—name—tree)的根部。该树的叶和非叶节点对应于注册的对象。非叶节点对应于注册机构，他们的注册责任由他们的上级节点赋予。国际标准组织将分配的arcs的管理委托给其他作为注册者的负责组织。ISO已经通过分配一个arc给TC68来这样做了。为了保证没有OlD被多次分配，TC68设计了一个OID管理方案，在其arc下分配。TC68通过分配其arc下的OID形成了一个对象标识符树。通过给他的成员国家分配一个arc，TC68选择将注册责任的管理委托给其are下的节点。这就确保了通过成员国家分配的OID是惟74 GB／T27913—2011一的，不会与其他注册机构进行的分配产生冲突，并且每个成员国可以独立于TC68和其他成员国来分配OlD。C．4为什么需要OID并且如何对它们进行管理OlD加其他信息内容用于管理目录资源的访问。OlD也嵌人在证书扩展中。但是，如何管理对CP文件的修改是个问题。当包含一个散列值时，每次CP文件修改时命名该CP的OlD可能被改变。这不太令人满意。作为选择，当散列值标识CP文件的版本时，则相同的OID可以保留，只改变散列值。 GB／T27913—2011D．1概述附录D(资料性附录)CA密钥生成过程本附录提供了建立CA密钥生成过程要求的综述。尤其与根CA有关。D．2角色和责任D．2．1概述CA密钥生成过程包括以下角色：——操作系统管理员；——cA应用管理员；——密钥要素管理人；——密钥分享组件持有人；——过程的主持者；——策略机构；——独立观察员。可要求其他角色，依赖于机构实施的特定软硬件组件、PKI体系结构和CPS的要求。可要求其他角色进行CA密钥生成过程完成后的CA操作。D．2．2操作系统管理员主要的责任有：——根据CA密钥生成过程脚本安装和配置操作系统；——建立操作系统用户账户；——控制操作系统根口令或管理员I=l令。D．2．3CA应用管理员主要的责任有：——根据CA密钥生成过程脚本安装和配置CA应用系统；——建立CA应用用户账户。D．2．4密钥要素管理人主要责任有：——维护CA密钥生成过程中密钥要素的准确清单，包括保存位置；——维护CA激活材料和共享持有人分配的准确清单；——确保过程中使用的密钥要素以防篡改的包装方式密封；——确保过程中使用的密钥要素在过程结束后安全地保存。76 GB／T27913—2011D．2．5密钥分享组件持有人主要责任有：——负责管理分配到的CA激活材料，如用来激活保护CA私钥的安全模块所需的令牌、智能卡或通行字；——保护分配到的CA激活材料。D．2．6过程主持者主要责任有：——协调CA密钥生成过程，确保始终遵循CA密钥生成过程脚本中定义的程序；——记录CA密钥生成过程脚本的任何偏差，并且记录CA密钥生成过程中发生的任何事件——批准任何重要的与CA密钥生成过程脚本的偏差及修订，该修订方案由策略机构提出。D．2．7策略机构主要的责任是：——授权CA密钥生成过程的执行；——批准CA密钥生成过程角色的分配。D．2．8独立观察员主要的责任是：——见证CA密钥的生成过程；——证实是否遵循密钥生成过程脚本并记录任何例外(如在过程脚本执行记录上签署或在单独的报告中提出意见)。独立观察员应独立于负责CA密钥生成过程和正在进行的CA操作的实体。该角色可以由内部审计员、外部审计员或其他独立方承担。独立观察员应通晓CA密钥生成过程的要求和PKI。D．3CA密钥生成过程脚本CA密钥生成过程应根据CPS和详细的CA密钥生成过程脚本执行。虽然脚本的细节会根据实现技术和PKI体系结构而变化，但是CA密钥生成过程脚本应描述以下元素：——cA密钥生成过程的角色和责任(见D．2)；——密钥生成过程的环境，包括：·对地点的物理安全要求；·参与者签到和签退程序；——cA密钥生成过程程序(见D．4)；——过程后cA密钥要素的保存，包括：·指定材料保存在特定的安全存储位置；·传输材料到异地或灾难恢复存储位置的程序。D．4CA密钥生成过程程序虽然特定的程序会根据具体实现变化，但表D．1中程序应包括在脚本中。 GB／T27913—2011表D．1CA密钥生成过程程序阶段描述PKI管理员应准备硬件平台。至少应采纳以下内容：一检查CA机器发现任何明显的篡改迹象；一确定只有系统规范中规定的硬件组件存在；1．硬件准备一cA绝不能连接到任何外部系统或网络；一确定格式化的硬盘是惟一连接到系统的硬盘；在异常表上记录所有问题。提供可移动介质，以使CA证书请求和分发(如果可用)能够进行操作系统管理员应遵循CA密钥生成过程脚本规定的程序安装和配置操作2．操作系统安装系统CA应用管理员应准备软件系统。至少应采纳以下内容：一安装CA应用软件和其他所需的应用(如HSM管理者软件、数据库等)；8．CA应用安装一确定软件只来自可倍介质上的可信源；一确定事件日志是活动的。在异常表上记录任何问题CA应用应根据脚本进行配置。例如。建立CA应用用户账户、配置登录、配置4．CA应用配置证书框架、配置硬件安全模块、配置“n分之m”要求。对于根CA，m推荐使用最小值3(即3人)CA密钥对根据脚本中详细的程序生成。这一步骤根据机构选择的硬件安全5．CA密钥生成模块配置方案，要求多个密钥共享持有人参与。对业务持续性目的，机构应考虑遵照ISO15782—1：2003的附录J生成二级根CA对于业务持续性的目的，通常创建并在不同的位置保存CA私钥的一个或多6．CA密钥备份个备份的副本。脚本应描述这样做的相关程序对于根CA，此过程应包括为向终端用户分发而创建的自签名根CA证书。对于从属CA，此过程应包括证书请求的生成，请求向其上级CA的传送，以及上级7．cA证书签名CA对该从属CA证书的签名根CA证书的散列值应使用批准的算法创建用于之后的分发，以使用户验证根cA证书的可鉴别性应备份CA系统，然后关闭。CA系统应根据脚本移动到正确保护的设施内。8．CA系统关闭对于某些根CA系统，可能希望从硬盘上完全攘除软件系统(包括操作系统)。如果需要进一步的CA运行，可要求重新建立系统所有过程的信息应准备归档。这应包括CA系统的备份、过程的书面记录(即签署的脚本)和事件日志。9．存储材料准备密钥要素(包括硬件安全模块和激活材料)也应准备在预定的安全存储地点保存78 附录E(资料性附录)将RFC2527映射到RFC3647E．1表E．1将RFC2527的各部分映射到其后续的RFC3647的新部分当中。表E．1GB／T27913—2011RFC2527部分RFC3647部分1引言1．11综述1．11．2认证1．21．3参与群体和适用性1．31．3．1认证机构13．11．3．2注册机构1．3．21．3．3终端实体1．3．3、1．3．41．3．4适用性1．4、451．4详细联系方式1．51．4．1规范管理机构1．5．11．4．2联系人1．5．21．4．3确定CPS对策略适宜性的人员1．5．32一般规定2、8、92．1义务2．6．42．1．1CA义务多种2．1．2RA义务多种4．1．2，4．4，4．5、4．5．14．6．54．7．5，4．8．1，4．8，52．1．3用户义务49．1、4．9．2、4．9．13、4．9．15、5、6、9．6．3、9．92．1．4信任方义务45、4．52、4．9．6、5、6、9．6．4、9．92、4．4．2、4．4．3、4．6．6、4．6．7、4．7．6、4．7．7、4．8．6、2．1．5资料库义务4．8．72．2责任9．6、9．7、98、9．92．2．1CA责任9．6．1、9．7、9．8、9．92．2．2RA责任9．6．2、9．7、9．8、9．92．3金融职责9．22．3．1由信任方赔偿92．3．2信托关系9．72．4解释和强制9162．4．1监管法律9．14、9．1579 Ca／T27913—2011表E．1(续)RFC2527部分RFC3647部分2，4．2可分离性，残存，合并，通知9．10．3、9．11、9．161、9．16．32．4．3争议解决程序9．13、9．164——2．5费用9．12．5．1证书签发或更新费9．1．12，5．2证书访问费9．122．53撤销或状态信息访问费9．1．3——2．5．4其他服务费，如策略信息9142．5．5退款镱略9．1．52．6发布和资料库2．2．2、4．4．2、4．43、4．6．6、46．7、476、4．7．7、2．6．1CA信息的发布4．8．6、4．8．72．6．2发布的频率232．6．3访问控制2．42．6．4资料库2．127一致性审计8．2．7．1实体一致性审计的频率8．12．7．2审计者的身份／资格8．22．7．3设计者与被审计方的关系8．32．7．4审计覆盖的主题8．4——2．75由于缺陷而采取的行动8．52．7．6结果的通信8．628机密性93、9．42．8．1要保密的信息类型9．3．】、9．4．22．8．2不认为是保密的信息类型9．3．2、9．4．32．8．3证书撤销／挂起信息的披露9．3．1、932、9．3．3、9．4．2、9．4．3、9．4．42．8．4向法律强制机关披露9．3．3、9．4．62．8．5作为部分当事人证据搜集的披露9．3．3、9．4．62，8．6根据所有者的请求披露9．3．3、9．4．72．8．7其他信息揭示情况9．3．3、94．7——2．9知识产权保护9．53认证与鉴别3．3．1初始注册3．1、323．1．1名称的类型3．1．13．1．2名称需要有意义3．1．2、3．1．33．1．3解释各种名称形式的规则3．1．4 表E．1(续)GB／T27913—2011RFC2527部分RFC3647部分3．1．4名称的惟一性3．1．53．1．5名称声明争议解决程序3．1．63．1．6识别、鉴别和商标的角色3．1．6317证明拥有私钥的方法3．2．13．1．8机构身份的鉴别323．1．9个人身份的鉴别3．233．2常规密钥更新3．3．1、4．6、473．3撤销后的密钥更新3．3．234撤销请求344操作要求4、54．1证书应用4．1、4．2、4．6、4．74．2证书签发4．2、4．3、44．3、4．6、47、4．8．4、4．8．6、4．8．74．3证书接受4．3．2、4．4、46、4．7、484Ⅵ4874．4证书挂起和撤销4．8、4．94．4．1撒销的情况4．8．1、4．9．14．4．2谁可以请求撤销4．82、4．9．24．4．3撤销请求的程序4．83——4．8．7、4．9．344．4撤销请求宽限期4．9．44．45挂起的情况4．9．134．4．6谁可以请求挂起4．9．144．4．7挂起请求的程序4．9．154．4．8挂起期跟4．9．164．4．9CRL签发频率(如果应用)4．9．7、4．9．8、4．104．4．10CRL检查要求4．9．6、4．10411在线撤销／状态检查的可用性，4．9．9、4．104．4．12在线撤销检查要求4．96、4．9．10、4．104．4．13其他形式的撤销公告4．9．11、4．104．4．14对其他形式撤销公告的检查要求49．6、4911、4．104．4．15关于密钥泄露的特殊要求49．124．5安全审计程序5．44．51记录的事件类型5．4．14．5．2处理日志的频率5．4．2453审计日志的保持周期5．4．3454审计日志的保护5．4．44．5．5审计日志备份程序5．4．581 GB／T27913—2011表E．1(续)RFC2527部分RFC3647部分4．5．6审计收集系统(内部的及外部的)5．4．64．5．7对事件引起的主体的通知5．4．74．5．8脆弱性评估5．4．84．6记录归档5．54，6．1归档的记录的类型5．5．14．6．2归档的保留期5．5．24．6．3归档的保护5．5．34．6．4归档的备份程序5．5．44．6．5记录的时间戤要求5．5．54．6．6归档收集系统(内部的或外部的)5．5．64．6．7获得和验证归档信息的程序5．5．74．7密钥变更5．64．8泄露和灾难恢复5．7、5．7．14．8．i计算资源、软件和／或数据被破坏5．7．24．8．2实体公钥被撤销49．7、4．9．9、4．9．114．8．3实体密钥泄露5．7．34．8．4自然或其他类型的灾难后对设箍进行保护5．7．44．9CA的终止5．85物理、程序和人员安全控制55．1物理控制5．15．1．1场地位置和建设5．1．15．1．2物理访问5．1_25．1．3电力和空调5．1．35．1．4排水5．1．45．15防火和保护5．1．55．1．6介质存储5．1．65．1．7废物处理5．1．75．1．8异地备份5．1．85．2程序控制5．25．2．1可信角色5．2．1、5．2．45．2．2每项任务要求的人员数量5．2．2、5．2．45．2．3对每个角色的认证与鉴别5．2．35．3人员控制5．35．3．1背景、资格、经历和安全检查要求5．3．15．3．2背景检查程序5．3．2 表E．1(续)GB／T27913—2011RFC2527部分RFC3647部分5．3．3培训要求5．3．35．3．4再培训频率和要求5．3．45．3．5职位轮换频率和顺序5．3．55．36对非授权行为的制裁5．3．65．3．7签约员工要求5．3．75．3．8提供给人员的文件5．3．86技术上的安全控制6．6．1密钥对生成和安装6．161．1密钥对生成6．1．16．1．2私钥向实体的传送6．1．26．1．3公钥向证书签发者的传送6．1．3614CA公钥向用户的传送6．1．46．1．5密钥长度6．1．56．1．6公钥参数的生成6．1．66．1．7参数质量检查6．1．66．1．8硬件／软件密钥生成6．1．16．1．9密钥使用目的(根据X．509v3的每个密钥使用域)6．1．96．2私钥的保护6．26．2．1密码模块的标准6．2．16．2．2私钥(m分之")多人控制6．2．26．2．3私钥托管6．2．36．2．4私钥备份6．2．46．2．5私钥归档6．2．56．2．6私钥输入密码模块6．2．6、62．76．27激活私钥的方法6．2．86．2．8解除私钥激活的方法6．2．96．2．9销毁私钥的方法6．2．106．3密钥对管理的其他方面6．36．3．1公钥归档6316．3．2公开和私有密钥的使用期6．3．26．4激活数据6．46．4．1激活数据的生成和安装6．4．16．4．2激活数据的保护6．4．26．4．3激活数据的其他方面6．4．36．5计算机安全控制6．5 GB／T27913—2011表E．1(续)RFC2527部分RFC3647部分6．51具体计算机安全技术要求6．516．5．2计算机安全等级6．5．26．6生命周期技术控制66．6．1系统开发控制6．6．16．6．2安全管理控制626．63生命周期安全控制6．6，36．7网络安全控制676．8密码模块工程控制6．2．1、6．2、6．2．1、6．2．117证书和CRL框架7．7．1证书框架717．11版本号7．1．17．1．2证书扩展7．1．27．1．3算法对象标识符7．1．37．1．4名称形式7．1．47．1．5名称约束7．1．57，1．6证书策略对象标识符7．1．67．1．7策略约束扩展的使用7．1．77．18对关键证书策略扩展的处理语义7．1．87．2CRL框架7．27．2．1版本号72l7．2．2CRL稚CRL条目扩展7．2．18规范的管理N／A8．1规范的修改程序9．1282发布和通知策略2．2、2．38．3CPS核准程序1．5．484 参考文献GB／T27913—2011[1]ISO／IEC8824信息技术抽象语法标记1(ASN．1)(1到4部分)[2]IsO／lEc10118—3信息技术一安全技术散列函数一第3部分：专用的散列函数[3]1so／TR13569金融服务信息安全指导E4]ISO／IECTR14516信息技术一安全技术可信第三方服务使用和管理指导E5]ISO／IEC15945信息技术安全技术支持数字签名应用的可信第三方服务规范E6]ISO／IEC19790信息技术安全技术密码模块的安全要求[7]RFC822，ARPAInternet文本报文格式标准，Internet请求注解822，D．CROKER，1982．8[8]RFC2459，Internetx．509公钥基础设施证书和CRI，框架，Internet请求注解2459，R．HoUSI．EY，W．FORD，W．POl。K，D．S()I．O，I999．1[9]RFC2527，InternetX．509公钥基础设施证书策略和认证业务框架，Internet请求注解2527，S．CHOKHANI，W．FORD，1999．3ElO]RFC2560，X．509Internet公钥基础设施在线状态协议OCSP，Internet请求注解2560，M．MYERS，R．ANKNEY，A．MAI．PANI，S．GAI。PERIN，C．ADAMS，1999．9[11]RFC3647，InternetX．509公钥基础设施证书策略和认证业务框架，Internet请求注解3647，S．CHOKHANI，W．FORD，R．SABETT，C．MERRIIA～SWU，November2003[12]ETSITS10l456V1．2．I(2002—04)，认证机构签发附加条件的证书的策略要求[13]ETSITS102042VI．1．1(200204)，认证机构签发公钥证书的策略要求[14]CWA14168，安全的签名创建设备“EAI。4”[15]CWA14169，安全的签名创建设备“FAI。4+”[16]CWA14170，签名创建应用的安全要求[17]数字签名指导，认证机构和安全电子商务的法律基础结构，1996．8．1[18]PKIAssessmentGuidelines，2002[19]认证机构的Web信任⋯程序一1．0版本，2000．8．25见http：／／www．aicpa．orgorhttp：／／www．cica．ca'