PKI资源查询协议
版本 : 00 01
PKIX 工作组 M. Pala
因特网草案 Dartmouth College
预案状态：实验 February 25, 2008
期满： 2008年08月28日
PKI资源查询协议
draft-pala-prqp-01
本备忘录状态
当提交这个英特网草案(Internet-Draft)时,每个作者都声称他／她知道的所有可用的专利或其它 IPR 权利都已经或者将要解密,且他／她将会知道的也将依照 BCP 79 的第6章节解密.
英特网草案(Internet-Draft)是 Internet Engineering Task Force (IETF ,英特网工程工作小组)的可实行文档(working document),它的范围,及它的工作团队. 要注意其他团队也可能在发布可实行文档作为英特网草案.
因特网草案(Internet-Draft)是最多6个月内有效的草案文档,且有可能在任何时候升级, 替换或被其他文档废弃.用英特网草案作参考资料或引用它们(除了"工作进展中")都不合适.
现有的英特网草案(Internet-Draft)名单可以在
因特网草案阴子目录(Internet-Draft Shadow Directories)列表可以在
本因特网草案(Internet-Draft)将在2008年8月28日到期.
版权声明
Copyright (C) The IETF Trust (2008).
摘要
以X509为基础的PKI还存在的一个战略性问题是对认证中心 相关的公共数据和服务的定位。这个问题同时也影响着PKIX的互操作性和可用性。这份草案描述了PKI资源查询协议的设计、定义以及它对已经发布的PKIX协议的影响。
目录
要求表示法. . . . . . . . . . . . . . . . . . . .
介绍 . . . . . . . . . . . . . . . . . . . . . . . . .
2.1. 现有解决方案概论 . . . . . . . . . . . . . . 3
2.1.1. 证书扩展 . . . . . . . . . . . . . . . . 3
2.1.2. DNS SRV 记录 . . . . . . . . . . . . . . . . . . . 4
2.1.3. 面向本地网络解决方案 . . . . . . . . . . . 4
3. 协议细节 . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. 资源查询权威 . . . . . . . . . . . . 5
3.2.PRQP概论 . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. PRQP请求 . . . . . . . . . . . . . . . . . . . . . 6
3.2.1.1. 请求语法 . . . . . . . . . . . . . . . . . . 7
3.2.2. PRQP响应 . . . . . . . . . . . . . . . . . . . . 9
3.2.2.1. 响应语法 . . . . . . . . . . . . . . . . . 9
3.3. IANA 因素 . . . . . . . . . . . . . . . . . . . 12
4. PRQP设计原理 . . . . . . . . . . . . . . . . . . . . 12
4.1. 响应复杂性 . . . . . . . . . . . . . . . . . . . 12
4.2.RQA的URL分发 . . . . . . . . . . . . . . . . . . 12
4.3. 安全因素 . . . . . . . . . . . . . . . . . 12
4.4. 时间有效性 . . . . . . . . . . . . . . . . . . . . . . 13
4.5.消息格式 . . . . . . . . . . . . . . . . . . . . . . 13
5.致谢 . . . . . . . . . . . . . . . . . . . . . . . 14
6. 规范参考 . . . . . . . . . . . . . . . . . . . . . 14
附录A.PRQP响应的分发
A.1.基于HTTP的PRQP . . . . . . . . . . . . . . . . . . . . . . 15
A.1.1. 请求. . . . . . . . . . . . . . . . . . . . . . . 15
A.1.2. 响应 . . . . . . . . . . . . . . . . . . . . . . . 15
A.1.3. 消息缓存 . . . . . . . . . . . . . . . . . . . 16
A.2. 基于点对点网络的PRQP . . . . . . . . . . . . . . 16
附录B. PRQP的ASN1.1说明书 . . . . . . . . . . . . . . 17
作者地址 . . . . . . . . . . . . . . . . . . . . . . . . . 20
知识产权及版权声明 . . . . . . . . . . 21
1. 要求表示法
文(text)提供了一致性(conformance)的定义.完整的模式在 附录?B 中.
本文中的 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", 和 "OPTIONAL" 关键词将如 BCP 14, [RFC2119] 中所写的那样解释,已达到那些一致性的目的.
2. 介绍：
越来越多的协议和服务，被用来帮助PKIs的用户和管理员为不同的需求查找地址。
在新程序和服务部署的同时，就很需要去访问证书服务提供者提供的信息和服务。
现在的证书认证是纯粹地公开访问官方网站的诸如提供服务和回复者的网址。
使用PRQP,CA提供的资源就可以自动而又安全的被应用程序发现。
现有解决方案概述
现在有三种可选的方案去查找提供PKI数据的URLs。
o 在证书扩展里包含这样的数据。
o 通过简单搜索可达的资源丰富地区比如DNS,本地数据库等。
o 通过适应现有的协议比如服务定位协议（SLP）。
2.1.1. 证书扩展
要提供对公开数据的指示，可以使用PKIX扩展的权威信息访问(AIA)和主题信息访问(SIA)[RFC3280]。前者可以提供像证书发行者相关服务的信息，而后者在认证证书内部包含了认证方提供的服务。AIA and SIA 扩展是静态的，比如，除非证书被重新发行否则它们不会被修改。如果一个权威认证在他发行的所有证书中都插入AIA 比如，用来识别OCSP响应者位置，倘若后来改变了OCSP位置的话就需要重新发行所有这些证书了，这成为了更改实质上的障碍了。如果权威认证证书是自签名而且被当作一个使用可信锚使用的话，如果重发布这些证书将会改变扩张的SIA内容。比如，对时间印服务器位置的改变将会具有巨大的破坏力的，在封闭的PKIs里比如说企业,使用这样的扩展可以通过手工配置和管理这样的方法来替换这样的数据由于在这样的环境下本质上的中央控制，静态的SIA和AIA扩展并不是十分重要的。
然而，为了促进PKIs之间的互用性，PRQP激活了对指示这样服务（比如增加和删除）的动态管理，而无需改变证书的内容或者第三方去在它们的应用程序中去手工配置服务。即便在封闭的环境中，PRQP可以帮助管理PKI服务类似于DHCP使得网络管理容易的方法一样。
2.1.2. 域名服务 服务 记录
服务记录技术通过域名服务为服务器提供指向指针。[RFC1035] 按照[RFC2782]定义，这种类型的记录的介绍允许管理员去执行类似于 我们在这份草案中陈述的待解决的问题，比如提供服务的URLs. 适应这种机制的问题是这样的，与域名服务环境不同的是， 经常地，在PKIX里证书和域名空间没有固定的映射， 唯一例外的是当域组件属性备用在证书问题中。现今这种方法是没有被广泛适应。 更甚者，当尝试去查找权威认证提供的一个具体服务时，由于在证书中缺少这样的信息，我们没有总是能简单地去识别要查询的那台主机的方法。
面向问题的局域网
另一种提供可靠信息的方法是使用现存的协议去定位服务，比如Jini,UPnP或者SLP。[RFC2609]. IETF定义SLP去提供一个独立于语言的服务定位机制 然而，一些问题使得这不是解决我们的问题的一个好的选择，比如，当考虑到我们列举的问题时, 服务的实现太复杂。 为PKI服务和资源定位定义一个有效而又简单的协议，需要使得PKI能与现在和将来的应用程序特别是对计算能力和通信带宽受限的移动设备集成简单。
3.协议细节
PRQP 协议是一个请求－响应协议，通过交换两个报文组成。比如，客户端和服务器的请求和响应，这被叫做资源请求授权。请求实体（客户端）可以是需要访问与证书相关的响应和服务的信息的任意实体。 RQA是权威授权来为一个具体的CA答复或者为一个用户群比如在企业环境中作PRQP可信权威。第一种情况的RQA是直接由CA指定，它具有CA发行一个证书给具有在扩展的extendedKeyUsage里的有效值集的RQA在这种情况下的RQA为关于CA发行RQA证书的请求提供官方的响应当RQA作为PTA，他需要响应多个CA,而不需要直接去证实他们。 这样的话，一个有效的扩展(prqp信任授权)应该在证书中记录并且它的值应该为真。
3.1. 资源请求权威
资源请求权威是指定的作为PRQP响应者的权威。资源指定权威的签字密钥不需要和CA的一样。CA可能指定了一个资源请求权威来发布证书，这些证书里包含唯一的值，这些值作为区分资源请求证书里的扩充用法所用。 资源请求权威也可以作为一个可信的响应者。 PRQP 签名权若要被委任，那么它就必须包含PRQP响应者证书里的扩展extendedKeyUsage里的id-kp-PRQPSinging.
id-kp-PRQPSigning OBJECT IDENTIFIER ::= {id-kp 10}
当以一个PTA操作的时候，RQA可能提供多个CA的应答，而无须去直接认证他们。
要作为PTA的有效扩展(prqpTrustedAuthority)必须持有RQA的证书以及它的值应该被置为真。
prqpTrustedAuthority ::= BOOLEAN DEFAULT TRUE
3.2. PRQP概述
这个协议强调了客户端和一个RQA间的单回合报文的交换：
客户端通过向RQA发送一个请求给RQA来请求一个资源记号。
RQA通过发送一个响应来回复客户端。
当收到响应客户端必须验证应答的错误状态。如果没有错误发生，那么客户端必须 验证资源应答记号的各个部分和数字签名的有效性（如果有的话）。特定场合下还必须保证应答是否是和一个有效的请求相符合来防止回复攻击。客户端也必须验证应答的有效期。 这是为了最小化减轻RQA的负担，防止在特定的时间段里对同一资源向同一个RQA再次定位。
如果应答验证通过的话，客户端应该验证RQA的证书有效性。
3.2.1. PRQP请求
一个PRQP请求包含一下数据：
o 协议的版本
o 协议的场合(nonce)
o 最大应答数( MaxResponse)
o资源请求记号(ResourceRequestToken)
o 扩展域(Extensions)
ASN.1语法的引入条款定义在［RFC4210］里。为了签名计算，数据必须证明是用DER格式编码的。ASN.1明文标记的除非被说明外应作为默认语法。从［RFC3280］引入的条款是：扩展，证书，证书序列号，公钥主题信息，名字，识别算法
请求语法
PRQP请求语法如下
PRQPRequest ::= SEQUENCE {
requestData TBSReqData,
signature [0] EXPLICIT Signature OPTIONAL }
TBSReqData ::= SEQUENCE {
version INTEGER { v(1) },
nonce INTEGER OPTIONAL,
-- very large number
maxRespEntries INTEGER OPTIONAL,
-- maximum number of accepted entries in
-- corresponding response
serviceToken ResourceRequestToken,
-- token identifying the requested service
extensions [0] IMPLICIT Extensions OPTIONAL }
版本字段（现在为版本1）用来描述PRQP请求的版本特定场合字段，如果有的话，是一个介于80到256比特长的整数。最大应答数标识符号是用来表明RQA的应答中包含的资源回复记号的最大数目。资源请求记号是用来识别请求的服务的。它用来承载关于所请求服务的信息。他包括了一个CA识别符以及可选的一个或者多个服务标识符。
ResourceRequestToken ::= SEQUENCE {
ca CertIdentifier,
servicesList [0] SET OF ResourceIdentifier OPTIONAL }
ca字段是律属于证书识别的。这是用来识别所请求的CA服务的证书。 证书识别语法如下：
BasicCertIdentifier ::= SEQUENCE {
issuerNameHash OCTET STRING,
serialNumber CertificateSerialNumber }
ExtenderCertInfo ::= SEQUENCE {
certificateHash OCTET STRING,
subjectKeyHash OCTET STRING,
subjectKeyIdentifier [0] KeyIdentifier OPTIONAL,
issuerKeyIdentifier [1] KeyIdentifier OPTIONAL }
CertIdentifier ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
basicCertIdentifier BasicCertIdentifier,
extInfo [0] ExtendedCertInfo OPTIONAL,
caCertificate [1] Certificate OPTIONAL,
issuedCertificate [2] Certificate OPTIONAL }
resourceList指定了请求的资源或服务。
ResourceIdentifier ::= SEQUENCE {
resourceId OBJECT IDENTIFIER,
version [0] INTEGER OPTIONAL
--- version of the protocol or data format (if applicable) }
ResourceIdentifier是由用来标识被请求的服务或数据 (如OCSP, LDAP, CRL, etc... )以及一个可以个更好的甄别请求资源的版本号码的OID构成的。
所有的域应该被使用如果合适的话。 如果请求有一个或者多个ResourceIdentifier被提供的话，RQA应该回报每个请求服务的位置。如果没有ResourceIdentifier存在的话， 应答应该传送指定CA所有有效的协议的地址（按照最大应答数和可选限制参数） 这个签名字段域的类型是Signature,它在［RFC2560]中被定义。
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate
OPTIONAL }
扩展字段可以用来充实将来的协议。
3.2.2.PRQP应答
PRQP应答包括如下数据
o 协议版本
o 场合（ nonce）
o 状态
o CA 标识符
o 资源应答记号（ResourceResponseToken）
o 扩展字段
3.2.2.1. 应答语法
应答语法如下：
PRQPResponse ::= SEQUENCE {
respData TBSRespData,
signature [0] EXPLICIT Signature OPTIONAL }
TBSRespData ::= SEQUENCE {
version INTEGER { v(1)},
nonce INTEGER OPTIONAL,
-- as duplicated from the request
producedAt GeneralizedTime,
-- time when the response has been generated
nextUpdate [0] GeneralizedTime OPTIONAL,
-- time till when the response should be considered valid
pkiStatus PKIStatusInfo,
-- status of the response
responseToken SEQUENCE OF ResourceResponseToken
OPTIONAL,
-- token carrying informations about
-- requested services
extensions [0] EXPLICIT Extensions OPTIONAL }
版本字段（现在是版本1）描述了所使用的PRQP应答的版本。 场合字段，如果有的话，是对具体的请求的绑定。场合字段的用法只在验证应答和应答的值必须直接从对应请求 那边拷贝过来时才有意义。 如果请求没有这种情况的话，场合字段应该被忽略。
状态字段是基于［RFC4210］的3.2.3部分对状态的定义，定义如下。
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL }
如果状态值为零，那么responseToken必须在应答中表述出来。当状态值是非零时，responseToken必须被忽略，而且原因代号必须是如下PKIStatus 中的一个值。
PKIStatus ::= INTEGER {
ok (0),
-- when the PKIStatus contains the value zero one or
more responseToken is present
badRequest (1),
-- the request is badly formatted
caNotPresent (2),
-- the requested CA is not present
systemFailure (3)
-- a system failure has occourred }
签名字段的类型为Singnature ，它被定义在［RFC2560］中。
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate
OPTIONAL }
responseToken携带着关于客户端请求的服务的信息。
对于每个请求的服务，RQA应该包含一个ResourceResponseToken，他用来产生服务和对应URI的OID。
ResourceResponseToken的语法描述如下：
ResourceInfo ::= SEQUENCE {
resourceUri IA5String,
--- resource locator
version [0] INTEGER OPTIONAL,
--- version of the protocol or data format (if applicable)
}
ResourceResponseToken ::= SEQUENCE {
serviceId OBJECT IDENTIFIER,
resourceLocator [1] EXPLICIT SEQUENCE OF ResourceInfo }
serviceId字段的值是从相应请求那拷贝过来，它产生客户端想要的服务的OID。 虽然OID已经被PKIX WG定义了，我们定义了可以用来识别特定PKI服务的OID：
id-pkix-prqp-certPolicy OBJECT IDENTIFIER ::= {id-ad 50}
--- Certificate Policy (CP) URL
id-pkix-prqp-certPracticesStatement OBJECT IDENTIFIER ::= {id-ad 51}
--- Certification Practices Statement (CPS) URL
id-pkix-prqp-httpRevokeCertificate OBJECT IDENTIFIER ::= {id-ad 60}
--- HTTP Based (Browsers) Certificate Revocation Service
id-pkix-prqp-httpRequestCertificate OBJECT IDENTIFIER ::= {id-ad 61}
--- HTTP Based (Browsers) Certificate Request Service
id-pkix-prqp-httpRenewCertificate OBJECT IDENTIFIER ::= { id-ad 62 }
--- HTTP Based (Browsers) Certificate Renewal Service
id-pkix-prqp-httpSuspendCertificate OBJECT IDENTIFIER ::= {id-ad 63}
--- Certificate Suspension Service
id-pkix-prqp-cmsGateway OBJECT IDENTIFIER ::= {id-ad 40}
--- CMS Gateway
id-pkix-prqp-scepGateway OBJECT IDENTIFIER ::= {id-ad 41}
--- SCEP Gateway
id-pkix-prqp-xkmsGateway OBJECT IDENTIFIER ::= {id-ad 42}
--- XKMS Gateway
当应答数据被认为是有效的时，producedAt 和 nextUpdate 定义了时间帧。
在定义期间内，客户端不应该再对相同的服务发出请求。使用宽点的时间帧有助于RQA避免从相同客户端得到重复的请求，这样可以减轻应答者的负担。 然而，但是这并不能保证客户端会以更小的查询率去提供数据正如服务器并不会轻易信赖 客户端在应答里提供的通知。
resourceLocator使得用serviceId标识的服务可以访问。这个名字必须是一个绝对的URL，而且必须遵从 RFC4248］和［RFC4266］指定的语法和编码规则。resourceLocator包含了方案（如HTTP或FTP）以及方案特定部分方案特定部分被用来承载怎样到达请求服务的信息，这比如一个完整且合格的域名或者IP地址的主机。如果请求的服务不存在或者服务器对它无所知，resourceLocator的值应该为空。如果需要的话可选的扩展会被添加。
3.3.对IANA的考虑
这份文档不介绍IANA。
4.PRQP设计基本原理
在这部分里我们对协议的设计和细节作了几点思考。
4.1. 应答复杂性
消息复杂性是一个重要的设计因素。一些类型的服务，如delta CRLs，可以通过数据下载直接探索来解决。相反地，如果一个客户端想要查找一个具体版本的协议或者数据类型，一个精良的查询系统应该只有在请求的客户端确实支持才允许下载数据，这样可以减轻服务器的负担此刻我们觉得倘若保持协议的简单将会促进它在现有的环境中的适应性，这同时也是PRQP对现有可选协议来说比较大的一个优势。更甚，在不更改协议的前提下，扩展域可以用来定义协议，使其更精良。如果应用有需求的话，未来版本的协议可能会实现扩展的请求和应答类型。
4.2.RQA的URL分发
AIA和SIA在证书的扩展可以用来携带指向RQA的指针。如果证书中没有RQA的地址，那么客户端可以使用默认配置的URL。 虽然我们在2.1.1部分中批评了使用证书扩展的方法， 但是使用单个的扩展将会为分发RQA的地址提供一个简便的方法。
PRQP的使用将会为其他服务和数据的URL提供一个网关。
4.3. 安全因素
PRQP提供URL给PKI资源。这意味着它指提供了一个定位指针而不是数据本身。
这同样也留给客户端去按照提供的URL去收集需要的数据。场合和签名字段是一个可选项，这为灵活产生请求和应答提供方便。如果客户端没有提供场合这个字段值的话，它有可能会接收到预先估算的应答。这允许RQA为应答去产生一个离线的签名，这是对OCSP的一个改进。更甚，如果客户端和RQA之间的传输层信道一个被证实为可信（如HTTPS 或 SFTP），那么签名可以被安全的忽略。
4.4.时间有效期
时间有效期是应对对配置的URL的频繁升级。 一个值得去考虑的方面是用户为得到的数据集多久执行一次协议。如果太频繁的话会给服务器严重的负担，反之，如果过于稀疏的话，客户端又不能及时的发现提供的资源的改变。 正如附录A的细节里描述的，为了使应答的时间帧有效，它被设计成对这俩方面情况的折衷。但这只是客户端一个推荐的数据，它并不能保证可以对抗客户端发起的拒绝服务攻击。
4.5. 消息格式
有两种不同的选择被考虑。第一种是扩展的标记语言（XML），而第二种是DER。
用ASN.1来描述数据结构可以使软件开发者自由选择其中一种来实现协议.
然而,我们认为基于DER的PRQP实现是最好的选择,因为它对现有的应用和API保持兼容性. 再者,用DER编码会比使用XML来得小一点,而且几乎所有PKI应用都支持它 .
5. 致谢：
作者想要对 Stephen Kent富有见解的评论以及写这份文档时提供的帮助表示感谢，
6. 规范参考
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608,
June 1999.
[RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates
and Service: Schemes", RFC 2609, June 1999.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210, September 2005.
[RFC4248] Hoffman, P., "The telnet URI Scheme", RFC 4248,
October 2005.
[RFC4266] Hoffman, P., "The gopher URI Scheme", RFC 4266,
November 2005.
附录 A. PRQP响应的分发
A.1. 基于HTTP的PRQP
这一部分描述了要在HTTP上运行PRQP的请求和应答所需要的格式。
A.1.1.请求
基于HTTP的PRQP请求应该使用POST方法来提交他们的请求。这里请求属于隐私，使用HTTP的PRQP事务交换可以通过使用TLS／SSL或其他更低层次的协议来获得保护。
提供请求的HTTP头需要包含
o 内容类型
o 内容传送编码
o 内容长度
内容类型头需要被设置成为"应用／PRQP请求"（application/prqp-request）内容传送编码应该被设置为二进制，而内容长度应该被设置成为请求正文的长度。HTTP消息的正文应该携带PRQPRequest的DER编码的二进制值。
A.1.2. 应答
基于HTTP的PRQP应答应该有适当的HTTP头以及用DER编码的PRQP应答的二进制值组成。
应答要求的HTTP头应该包含：
o 内容类型
o 内容传送编码
o 内容长度
内容类型应该被设置为“应用／PRQP－应答”内容传送编码应该为二进制，而内容长度应该被设置为应答的正文长度HTTP消息的正文必须携带有用DER编码的PRQP应答的二进制值。
A.1.3. 消息缓存
为了最小化带宽的使用，客户端在请求有效期内必须本地缓冲官方的PRQP应答。为了使代理服务器也能够缓冲应答，附加HTTP的头部可能会在应答中使用。 PRQP响应者可能为了使缓冲容易会设置如下头部信息：
o日期
o 最后被更改
o 有效期
具体的，日期字段应该携带这个HTTP应答被产生的日期，最后被更改，应该产生应答被更改的日期。这个字段携带着PRQPResponse中producedAt字段相同的日期。
有效期字段携带着这个应答有效的日期。
这个字段的日期应该和PRQPResponse中的nextUpdate中携带的日期一样。
HTTP应答的例子应该像下面：
HTTP/1.0 200 OK
Content-Type: application/prqp-response
Content-Transfer-Encoding: Binary
Content-Length: 860
Date: Thu, 03 May 2007 04:43:43 GMT
Last-Modified: Thu, 03 May 2007 04:43:42 GMT
Expires: Thu, 04 May 2007 04:43:42 GMT
<...response data...>
PRQP客户端不应该在PRQP请求里包含一个不缓冲头部，除非中间代理服务器缓冲了失效的数据，而使客户端得到失效的应答。
A.2.在点对点网络中的PRQP
PRQP提供了一个不同于RQA协同访问非本地数据的PKI资源发现体系结构的出发点。
P2P网络中共享数据的技术仍然产生很好的效果。
验证的PRQP请求应答同样可以在现存的P2P网络运行，或者特定的PRQP网络可以启动来成为世界范围的PKI资源发现体系结构。但这超出了这份文档的范围。
附录 B. PRQP 的ASN1.1 说明书
PRQP DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
-- Directory Authentication Framework (X.509)
Certificate, AlgorithmIdentifier
FROM AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 3 }
-- PKIX Certificate Extensions
AuthorityKeyIdentifier, SubjectKeyIdentifier, KeyIdentifier,
FROM PKIX1Implicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit-88(2)}
CertificateSerialNumber, Extensions, id-kp, id-ad-prqp
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-88(1)};
PRQPRequest ::= SEQUENCE {
requestData TBSReqData,
signature [0] EXPLICIT Signature OPTIONAL }
TBSReqData ::= SEQUENCE {
version INTEGER { v(1) },
nonce INTEGER OPTIONAL,
-- very large number
maxRespEntries INTEGER OPTIONAL,
-- maximum number of accepted entries in
-- corresponding response
serviceToken ResourceRequestToken,
-- token identifying the requested service
extensions [0] IMPLICIT Extensions OPTIONAL }
ResourceRequestToken ::= SEQUENCE {
ca CertIdentifier,
servicesList [0] SET OF ResourceIdentifier OPTIONAL }
BasicCertIdentifier ::= SEQUENCE {
issuerNameHash OCTET STRING,
serialNumber CertificateSerialNumber }
ExtenderCertInfo ::= SEQUENCE {
certificateHash OCTET STRING,
subjectKeyHash OCTET STRING,
subjectKeyIdentifier [0] KeyIdentifier OPTIONAL,
issuerKeyIdentifier [1] KeyIdentifier OPTIONAL }
CertIdentifier ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
basicCertIdentifier BasicCertIdentifier,
extInfo [0] ExtendedCertInfo OPTIONAL,
caCertificate [1] Certificate OPTIONAL,
issuedCertificate [2] Certificate OPTIONAL }
ResourceIdentifier ::= SEQUENCE {
resourceId OBJECT IDENTIFIER,
version [0] INTEGER OPTIONAL
--- version of the protocol or data format (if applicable) }
PRQPResponse ::= SEQUENCE {
respData TBSRespData,
signature [0] EXPLICIT Signature OPTIONAL }
TBSRespData ::= SEQUENCE {
version INTEGER { v(1)},
nonce INTEGER OPTIONAL,
-- as duplicated from the request
producedAt GeneralizedTime,
-- time when the response has been generated
nextUpdate [0] GeneralizedTime OPTIONAL,
-- time till when the response should be considered
-- valid
pkiStatus PKIStatusInfo,
-- status of the response
ca CertIdentifier,
-- certificate identifier of the CA the resp is related to
responseToken SEQUENCE OF ResourceResponseToken
OPTIONAL,
-- token carrying informations about
-- requested services
extensions [0] EXPLICIT Extensions OPTIONAL }
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL }
PKIStatus ::= INTEGER {
ok (0),
-- when the PKIStatus contains the value zero one or
more responseToken is present
badRequest (1),
-- the request is badly formatted
caNotPresent (2),
-- the requested CA is not present
systemFailure (3)
-- a system failure has occourred }
Signature ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate
OPTIONAL }
ResourceInfo ::= SEQUENCE {
resourceUri IA5String,
--- resource locator
version [0] INTEGER OPTIONAL,
--- version of the protocol or data format (if applicable)}
ResourceResponseToken ::= SEQUENCE {
serviceId OBJECT IDENTIFIER,
resourceLocator [0] EXPLICIT SEQUENCE OF ResourceInfo }
-- Object Identifiers
id-kp-PRQPSigning OBJECT IDENTIFIER ::= { id-kp 10 }
id-pkix-prqp OBJECT IDENTIFIER ::= { id-ad-prqp }
id-pkix-prqp-pta OBJECT IDENTIFIER ::= { id-ad-prqp 1 }
id-pkix-prqp-certPolicy OBJECT IDENTIFIER ::= {id-ad 50}
id-pkix-prqp-certPracticesStatement OBJECT IDENTIFIER ::= {id-ad 51}
id-pkix-prqp-httpRevokeCertificate OBJECT IDENTIFIER ::= {id-ad 60}
id-pkix-prqp-httpRequestCertificate OBJECT IDENTIFIER ::= {id-ad 61}
id-pkix-prqp-httpRenewCertificate OBJECT IDENTIFIER ::= { id-ad 62 }
id-pkix-prqp-httpSuspendCertificate OBJECT IDENTIFIER ::= {id-ad 63}
id-pkix-prqp-cmsGateway OBJECT IDENTIFIER ::= {id-ad 40}
id-pkix-prqp-scepGateway OBJECT IDENTIFIER ::= {id-ad 41}
id-pkix-prqp-xkmsGateway OBJECT IDENTIFIER ::= {id-ad 42}
作者的地址
Massimiliano Pala
Dartmouth College
6211 Sudikoff PKI/Trust Lab
Hanover, NH 03755
US
Email: [email protected]
URI: http://www.openca.org/
完整版权声明
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
知识产权
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
[email protected].
致谢
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).