简单证书认证协议创建时间：2004-11-28 文章属性：翻译 文章提交：Cat----itaq (liumiao1983cn_at_yahoo.com.cn) 简单证书认证协议 (Simple Certificate Validation Protocol (SCVP) )2004 October http://www.infosecurity.org.cn/content/standard/pki-draft/draft-ietf-pkix-scvp-16.txt 翻译:Cat----itaq http://www.itaq.org 1 介绍 证书认证是很复杂的， 证书处理广泛发展在很多应用程序和环境，有很多的应用程序中利用了公匙证书，但是这些应用程序必须自已负担对证书路径构造和确认的开销。SCVP将会降低应用程序利用公匙证书时资源的开销。利用公匙证书的应用程序大致分为两类. 第一类应用程序想要确定两方面，第一，他们要确定公匙是属于用户标识的证书，第二，他们想要知道这个公匙利用是否能够达到想要的目的。客户端授权到达服务端的证书路径的构造和确认，这类应用程序常常当作授权路径确认（DPV）。 第二类应用程序可以确认证书路径运行，但是这些应用程序没有可靠的方法去构造一个到达信任目的端的证书路径，客户端仅仅授权到达SCVP服务端的证书路径构造。这类应用程序常常被称为DPD. 不受信任的SCVP服务器可以提供客户端的证书路径，他们也提供客户端撤消信息，比如：CRLS和OCSP的回复,客户端需要被SCVP服务器认证证书路径构成.这些服务不包括那些需要下载中间证书的协议的服务,这对客户端很有价值.. 信任的SCVP服务器可以为客户端运行证书路径构造和确认.一个客户端可以利用这些服务,这个客户端始终信任这个scvp服务器.就像这个客户端拥有自已的证书路径构造软件一样,一个客户端去信任这样的SCVP服务器主要有两个原因: 1 这个客户端不想使得证书路径认证软件每接收一次证书时都要运行一次. 2 这个客户端是在一个想要认证它的PKI的机构里,这些政策可能规定了个别信任的终端被用和在认证路径确认期间运行的政策类型.. 1.3 Validation Policies (认证政策) 当SCVP在认证一个证书时,一个认可政策,特别是规则和参数会被SCVP服务器使用.在简单证书认证协议里,一个认证政策可以在客户端和服务器端相互同意.在请求中,需要明确的表达必需的参数.. 政策的定义是相当的漫长和复杂的,一些政策可能设定一些参数就像设定一个信任终端一样.一个请求如果先前的协议政策所依赖的参数被一个相互同意的OIK或者URL值请求就可能变得简单.这个参考值表述了一部分或者全部的设定格式.. 这个客户端可以从一个请求中忽略这些已协定的参数.只有通过了任何的不是被先前协定的政策所叙述的参数.因为在这些最简单的表单里 ,认证政策定义了每一个参数都是必须的.一个SCVP请求需要只有包含了一个可认可的证书,认可政策和任何的运行时间参数才给这个请求 SCVP服务器也发布它的默认的认证政策设置,默认的政策可被认证请求,在请求时如果需要的话客户端可以覆盖任何默认的值.在请求中这个默认的值也可以被利用,当处理请求参考一个认证政策除了那个默认的不包含全部参数和客户端已经省略掉的值. 一个客户端可以因为默认的值公布后已被服务器所接受了就可以省略一些参数来简化请求 1.4 Validation Algorithm (认证算法) 认证算法是由客户端和服务器所同意决定的,这个算法定义了检验那个将会被服务器运行来决定是否证书是否认可,叙述每一个定义在政策里参数,SCVP定义了一个基本的认证算法.. 应用程序叙述认证算法除了那些被定义在这个文档里也可以定义到没有被基本的认证算法复盖的叙述需求,这个认证算法文档应该作为一个发展更进一步应用程序-specific的向导 例如:一个新的应用程序-specific认证算法可能需要出现一个独特的名字形式来替代扩充的证书. . 某一个认证路径在一个特别的认证政策里被认为有效..这一定是一个有效的认证路径(被定义在[PKIX-1])和所有认证政策限制适应的认证路径必须被确认. 撤消检验是认证路径确认的一个方面,已被定义在[PKIX-1],所以,认证政策必须叙述撤消信息的来源,有五种可能: 1 全部的CRLs必须收集. 2 OCSP回复,如果正在用中,必须收集 3. CRLs和 the relevant associated full CRLs (or full Authority Revocation Lists) are to be collected; 4 任何可得的撤消的信息必须被收集. 5 没有撤消信息必须收集 2 Protocol Overview (协议概观) SCVP用一个简单的请求-回复模型.也就是,SCVP客户端创建一个请求然后发送请求到SCVP服务器,然后SCVP服务器创建一个单一的回复然后发送到客户端,这种典型利用SCVP被认为超过了HTTP,但是它也可以发送EMAIL或者其它的协议也可以传输数据信号..附录A和附录B提供了通过HTTP利用SCVP的详细需要. SCVP包含了两个请求-回复.第一个请求-回复用来处理证书认证,第二个请求-回复用来决定认证政策列表 和定义一个具体的SCVP服务器所支持的格式. 第三段定义证书认证请求 第四段定义了相对应的证书认证回复. 第五段定义了认政政策请求. 第六段定义了相应的认证政策的回复. 3 Validation Request (认证请求) 一个SCVP客户端请求到服务器必须是一个单一的CVRequest .当一个CVRequest被装入到一个多用途互联网邮件扩充(MIME),应用程序/CVRequest必须被用. 有两种形式的SCVP请求,有符号的和无符号的,一个有符号的请求 常常用来证明客户端到服务端或者提供对一个匿名的客户端的请求—回复对的完整性约束.一个服务器可能需要所有的请求被签名,一个服务器可能丢弃所有无符号请求.或者,一个服务器可能选择处理无符号请求. 无符号请求由一个CVRequest装入到一个CMS. 下面提供了这些结构.它们已被在ASN.1定义了,很多详细的细节没有显示,但是下面是一个例子清楚地说明了SCVP利用CMS. //////////////////////////////////////////////////////////////////// ContentInfo { contentType id-ct-scvp-certValRequest, -- (1.2.840.113549.1.9.16.1.10) content CVRequest } ///////////////////////////////////////////////////////////// 有符号的请求由一个CVRequest封装在一个已签名的数据(SignedData)或者是已验证的数据(AuthenticatedData)里,它们是轮着封装一个ContentInfo, 下面提供了它的结构. 它们已被在ASN.1定义了,很多详细的细节没有显示,但是下面是一个例子清楚地说明了SCVP利用CMS. /////////////////////////////////////////////////////////////////////////////////////// SignedData example: ContentInfo { contentType id-signedData, -- (1.2.840.113549.1.7.2) content SignedData } SignedData { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates [0] IMPLICIT CertificateSet Optional, crls [1] IMPLICIT CertificateRevocationLists Optional, signerInfos SET OF SignerInfo } -- only one in SCVP SignerInfo { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs SignedAttributes, -- Required signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs UnsignedAttributes } -- not used in SCVP EncapsulatedContentInfo { eContentType id-ct-scvp-certValRequest, -- (1.2.840.113549.1.9.16.1.10) eContent OCTET STRING } -- Contains CVRequest AuthenticatedData example: ContentInfo { contentType id-ct-authData, -- (1.2.840.113549.1.9.16.1.2) content AuthenticatedData } AuthenticatedData { version CMSVersion, originatorInfo OriginatorInfo, -- Optional recipientInfos RecipientInfos, -- Only SCVP server macAlgorithm MessageAuthenticationCodeAlgorithm, digestAlgorithm DigestAlgorithmIdentifier, -- Optional encapContentInfo EncapsulatedContentInfo, authAttrs AuthAttributes, -- Required mac MessageAuthenticationCode, unauthAttrs UnauthAttributes } -- not used in SCVP EncapsulatedContentInfo { eContentType id-ct-scvp-certValRequest, -- (1.2.840.113549.1.9.16.1.10) eContent OCTET STRING } -- Contains CVRequest ////////////////////////////////////////////////////////////////////////// 所有的ACVP客户端必须提供已签名的数据给签名的请求和回复,一个SCVP客户端应该提供已验证的数据给签名的请求和回复.如果客户端用已签名数据则必须有一个公匙,而这个公匙必须遵照PKI标准给一个被一个证书标识的用户,而证书必须适合签署SCVP请求.那也就是,如果证书中的公钥用途出现了扩充,.那么数据讯号或者交易的不可否认性位必须坚持. 如果证书中的公钥用途出现了扩充.,它必须包含这个客户端验证OID,SCVP客户端OID,或者一些另外的OID被SCVP服务器同意. 客户端必须放一个明确的证明给它的已签名的数据和已验证的数据请求认证..客户端应该包含签名者的认证在请求里.但是可能为了降低请求的大小而省略了认证..客户端的请求可能包含其它认证为了帮助SCVP服务器认证签名者的证书. 已签名数据,已验证数据,和ContentInfo的语法和语义已在[CMS]里面定义. CVRequest的语法和语义在下面定义了,CVRequest包含了客户端的请求, CVRequest包含了cvRequestVersion和查询项目, CVRequest可能也包含了requestorRef, requestNonce, and requestExtensions items. CVRequest必须包含以下的语法. ///////////////////////////////////////////////////////////////////// CVRequest ::= SEQUENCE { cvRequestVersion INTEGER, query Query, requestorRef [0] SEQUENCE SIZE (1..MAX) OF OCTET STRING OPTIONAL, requestNonce [1] OCTET STRING OPTIONAL, requestExtensions [2] Extensions OPTIONAL dhPublicKey [3] DHPublicKey OPTIONAL} //////////////////////////////////////////////////////////////// CVRequest里面的每一项都在以下有了描述: 3.1 cvRequestVersion cvRequestVersion定义了在请求中SCVP cvRequest的版本,用户回复必须使用相同的版本. CvRequestVersion的值, 现在的规格cvRequestVersion值必须是1,以后规格更新了,这个值一定是其它的值了,如果有什么语法和语义改变的话. query项叙述了一个或多个证书是请求的目的.证书可以公匙证书[pkix-1]也可以是AC[PKIX-AC],一个query必须包含一个顺序的一个或多个queriedCerts和一个check,一个wantBank,一个validationPolicy项,一个query项可能也包含responseRefHash, responseValidationPolByRef, signResponse, serverContextInfo, validationTime, intermediateCerts, revInfos, producedAt, and queryExtensions 项…………. Query必须含有以下语法 ////////////////////////////////////////////////////////////// Query ::= SEQUENCE { queriedCerts SEQUENCE SIZE (1..MAX) OF CertReference, checks CertChecks, Freeman, Housley, & Malpani [Page 11] INTERNET DRAFT SCVP October 2004 wantBack WantBack, validationPolicy ValidationPolicy, responseFlags ResponseFlags OPTIONAL, serverContextInfo [0] OCTET STRING OPTIONAL, validationTime [1] GeneralizedTime OPTIONAL, intermediateCerts [2] CertBundle OPTIONAL, revInfos [3] RevocationInfos OPTIONAL, producedAt [4] GeneralizedTime OPTIONAL, queryExtensions [5] Extensions OPTIONAL } ////////////////////////////////////////////////////////////// 在QUERY项里告诉了证书每一个客户端想要的信息.在check项里叙述了检验客户端想要的运行. WantBack项里叙述了客户端想要服务器回复信息旱返回的目标地. ValidationPolicy项叙述了客户端想要服务端所用的认证政策. The requestRefHash, responseValidationPolByRef 和 signResponse项允许客户端去请求可选择的回复. ServerContextInfo告诉服务端需要一个附加的消息从先前的请求-回复里.. validationTime说明了客户端想要服务器检验的时间和日期. intermediateCerts 和 revInfos项提供了客户端请求的环境. QueryExtensions项提供以后扩展的query语法…这些项的语法和语义将会在下面段讨论.. 3.1.1 queriedCerts queriedCerts项,使用CertReference类型..鉴定请求目标的证书.这个证书可以是一个公匙或者是一个AC,这个证书可能是直接包含或者是相关的.当是相关时,当referenced证书被取得时, referenced项的一个哈希值[SHA-1]去确保SCVP客户端和SCVP服务端都拥有相同的证书.下面是CertReference的语法: /////////////////////////////////////////// CertReference ::= CHOICE { pkc PKCReference, ac ACReference } PKCReference ::= CHOICE { cert [0] Certificate, pkcRef [1] ESSCertID } ACReference ::= CHOICE { attrCert [2] AttributeCertificate, acRef [3] ESSCertID } ///////////////////////////////////////////////////////////////// 未完………………. |
