RFC2560(x.509因特网公钥基础设施在线证书状态协议——OCSP )

竭诚为您提供优质文档/双击可除x.509认证协议篇一：x.509与pkix.509与pki公钥基础设施（publickeyinfrastructure，简称pki）是利用公钥理论和技术建立的提供加密和数字签名等安全服务的基础设施。

它以公开密钥密码算法为基础，结合对称密码算法、摘要算法等，通过数字签名、数字证书等技术来保证网络传输数据的机密性、完整性、不可否认性noRepudiation以及身份鉴别等。

1.pki的基础协议pki的基础协议有很多，如itu-tx.680abstractsyntaxnotationone（语法符号标准asn.1）、itu-tx.690asn.1encodingRules（数据编码标准）和itu-tx.500系列标准等。

而国际电信联盟itux.509协议，是pki技术体系中应用最为广泛、也是最为基(x.509认证协议)础的一个协议。

它主要目的在于定义一个规范的数字证书格式，以便为基于x.500协议的目录服务提供一种认证手段。

一个标准的x.509数字证书是由用户公开密钥与用户标识符组成，此外还包括版本号、证书序列号、ca标识符、签名算法标识、签发者名称、证书有效期等。

最初的数字证书x.509v1版1988年发布，1993年国际电信联盟itu公布x.509v2，增强了对目录存取控制和鉴别的支持。

x.509v3版（1997年发布）支持扩展的概念，以提供更多的灵活性及特殊环境下所需的信息传送。

x.509v3定义的公钥证书比x.509v2证书增加了多项预留扩展域，如：发证证书者或证书用户的身份标识，密钥标识，用户或公钥属性等。

同时x.509v3对cRl结构也进行了扩展。

最新的第四版x.509v4于2000年5月发布。

x.509v4在扩展x.509v3的同时，提出了特权管理基础设施pmi （privilegemanagementinfrastructure）和授权模型。

pmi 是建立在pki提供的可信的身份认证服务的基础上，通过属性证书ac(attributecertificate)，来对用户的访问进行授权管理。

证书主要的文件类型和协议有: PEM、DER、PFX、JKS、KDB、CER、KEY、CSR、CRT、CRL、OCSP、SCEP等。

PEM– Openssl使用 PEM(Privacy Enhanced Mail)格式来存放各种信息,它是 openssl 默认采用的信息存放方式。

Openssl 中的 PEM 文件一般包含如下信息:1.内容类型:表明本文件存放的是什么信息内容,它的形式为“——-BEGIN XXXX——”,与结尾的“——END XXXX——”对应。

2.头信息:表明数据是如果被处理后存放,openssl 中用的最多的是加密信息,比如加密算法以及初始化向量 iv。

3.信息体:为 BASE64 编码的数据。

可以包括所有私钥（RSA 和 DSA）、公钥（RSA 和 DSA）和 (x509) 证书。

它存储用 Base64 编码的 DER 格式数据，用ascii 报头包围，因此适合系统之间的文本模式传输。

使用PEM格式存储的证书：—–BEGIN CERTIFICATE—–MIICJjCCAdCgAwIBAgIBITANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCV VMx………1p8h5vkHVbMu1frD1UgGnPlOO/K7Ig/KrsU=—–END CERTIFICATE—–使用PEM格式存储的私钥：—–BEGIN RSA PRIVATE KEY—–MIICJjCCAdCgAwIBAgIBITANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCV VMx………1p8h5vkHVbMu1frD1UgGnPlOO/K7Ig/KrsU=—–END RSA PRIVATE KEY—–使用PEM格式存储的证书请求文件：—–BEGIN CERTIFICATE REQUEST—–MIICJjCCAdCgAwIBAgIBITANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCV VMx………1p8h5vkHVbMu1frD1UgGnPlOO/K7Ig/KrsU=—–END CERTIFICATE REQUEST—–DER–辨别编码规则 (DER) 可包含所有私钥、公钥和证书。

⽹络安全服务（NetworkSecurityServices,NSS⽹络安全服务(Network Security Services, NSS)是⼀套为⽹络安全服务⽽设计的库⽀持⽀持安全的客户端和服务器应⽤程序。

使⽤NSS构建的应⽤程序可以⽀持SSL v2和v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509v3证书和其他安全标准。

如果需要命令⾏⼯具，请安装nss-tools包操作NSS证书和密钥数据库。

开源加密库经过验证的应⽤程序安全体系结构如果您想为您的应⽤程序添加对SSL、S/MIME或其他互联⽹安全标准的⽀持，您可以使⽤⽹络安全服务(NSS)来实现所有的安全特性。

NSS提供了AOL、Red Hat、⾕歌和其他公司在各种产品中使⽤的加密库的完整开源实现，包括以下内容:Mozilla产品，包括Firefox、Thunderbird、SeaMonkey和Firefox OS。

美国在线即时通讯(AIM)开源客户端应⽤程序，如Evolution、Pidgin、Apache OpenOffice和LibreOffice。

Red Hat的服务器产品包括:Red Hat Directory Server、Red Hat Certificate System和Apache web服务器的mod_nss SSL模块。

Oracle(原Sun Java企业系统)的服务器产品，包括Oracle通信消息传递服务器和Oracle⽬录服务器企业版。

SUSE Linux Enterprise Server⽀持NSS, Apache web服务器⽀持mod_nss SSL模块。

NSS包括⼀个框架，开发⼈员和原始设备制造商可以提供补丁，如汇编代码，以优化其平台上的性能。

NSS 3。

x已经在18个平台上获得了认证。

有关NSS的更多详细信息，请参阅和NSS FAQ。

x.509与PKI公钥基础设施（Public Key Infrastructure，简称PKI）是利用公钥理论和技术建立的提供加密和数字签名等安全服务的基础设施。

它以公开密钥密码算法为基础，结合对称密码算法、摘要算法等，通过数字签名、数字证书等技术来保证网络传输数据的机密性、完整性、不可否认性NO REPUDIATION以及身份鉴别等。

1.PKI的基础协议PKI的基础协议有很多，如ITU-T X.680 Abstract Syntax Notation One（语法符号标准ASN.1）、ITU-T X.690 ASN.1 Encoding Rules（数据编码标准）和ITU-T X.500 系列标准等。

而国际电信联盟ITU X.509协议，是PKI技术体系中应用最为广泛、也是最为基础的一个协议。

它主要目的在于定义一个规范的数字证书格式，以便为基于X.500协议的目录服务提供一种认证手段。

一个标准的X.509数字证书是由用户公开密钥与用户标识符组成，此外还包括版本号、证书序列号、CA标识符、签名算法标识、签发者名称、证书有效期等。

最初的数字证书X.509v1版1988年发布，1993年国际电信联盟ITU公布X.509v2，增强了对目录存取控制和鉴别的支持。

X.509v3版（1997年发布）支持扩展的概念，以提供更多的灵活性及特殊环境下所需的信息传送。

X.509v3定义的公钥证书比X.509v2证书增加了多项预留扩展域，如：发证证书者或证书用户的身份标识，密钥标识，用户或公钥属性等。

同时X.509v3对CRL结构也进行了扩展。

最新的第四版 X.509v4于2000年5月发布。

X.509v4在扩展X.509v3的同时，提出了特权管理基础设施PMI（Privilege Management Infrastructure）和授权模型。

PMI 是建立在PKI提供的可信的身份认证服务的基础上，通过属性证书AC(Attribute Certificate)，来对用户的访问进行授权管理。

1、信息安全标准组织简介国际组织国际上信息安全标准化工作兴起于20世纪70年代中期，80年代有了较快的发展，90年代引起了世界各国的普遍关注。

目前世界上有近300个国际和区域性组织制定标准或技术规则，与信息安全标准化有关的组织主要有以下4个：国内组织国内的安全标准组织主要有信息技术安全标准化技术委员会(CITS)以及中国通信标准化协会(CCSA)下辖的网络与信息安全技术工作委员会。

2、IETF PKIX (“PKI 使用X.509”)标准PKI on X.509:包含一系列协议，主要定义基于X.509的PKI模型框架，定义X.509证书在Internet上的使用。

包括证书的生成、发布和获取，各种产生和分发密钥的机制，以及怎样实现这些协议的轮廓结构等。

制订基于X.509的PKI标准支持各种应用，包括Web、email、IPSec等，已提交10多个RFC文档，含盖PKI的方方面面。

具体见/html.charters/pkix-charter.html。

PKIX标准清单标准草案Internet X.509公开密钥基础设施时间戳协议（TSP）Internet X.509公开密钥基础设施Internet X.509公开密钥基础设施身份验证用Internet属性证书结构Internet X.509公开密钥基础设施操作协议-LDAPv3简单证书有效性协议Internet X.509公开密钥基础设施证书和CRL结构Internet X.509公开密钥基础设施抗抵赖服务的技术要求Internet X.509公开密钥基础设施证书管理协议Internet X.509公开密钥基础设施永久识别符CMP传输协议Internet X.509公开密钥基础设施PKI和PMI的附加LDAP构架Internet X.509公开密钥基础设施证书和CRL算法和标识符授权路径有效性在线证书状态协议第2版在线证书状态协议PostScript版OCSP授权路径的发现Internet X.509公开密钥基础设施证书请求报文格式（CRMF）PKIX用户组名和通用名类型Internet X.509公开密钥基础设施扮演证书结构CMS的证书管理报文RFC标准Internet X.509公开密钥基础设施证书和CRL结构（RFC 2459）Internet X.509公开密钥基础设施证书管理协议（RFC 2510）Internet X.509证书请求报文格式（RFC 2511）Internet X.509公开密钥基础设施证书策略和证书作业框架（RFC 2527）Internet X.509公开密钥基础设施密钥交换算法表述（RFC 2528）Internet X.509公开密钥基础设施操作协议LDAPv2（RFC 2559）Internet X.509公开密钥基础设施操作协议FTP和HTTP（RFC 2585）Internet X.509公开密钥基础设施LDAPv2构架（RFC 2587）Internet X.509公开密钥基础设施在线证书状态协议OCSP（RFC 2560）CMS的证书管理报文（RFC 2797）Diffie-Hellman Proof-of-Possession 算法（RFC 2875）Internet X.509公开密钥基础设施合格证书结构（RFC 3039）Internet X.509公开密钥基础设施数据有效性和认证服务协议（RFC 3029）3、PKCS系列标准PKCS是由美国RSA数据安全公司及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。

OCSP证书状态查询机制与实现吕国忠【摘要】证书状态查询是公钥基础设施中最重要的问题之一,OCSP是解决这个问题的一种重要机制.文章分析了CRL协议、OCSP协议、状态缓存、线程池、预签名.设计了一种OCSP服务器的实现方法,详细描述了该设计在具体实现中需要特别注意的几项关键技术,以提高系统的性能和稳定性.【期刊名称】《电脑与信息技术》【年(卷),期】2010(018)001【总页数】3页(P44-45,52)【关键词】PKI;在线证书状态协议;证书撤销【作者】吕国忠【作者单位】江南计算技术研究所,无锡,214083【正文语种】中文【中图分类】TP393.08随着电子商务、电子政务的迅猛发展，PKI（Public Key Infrastructure，公钥基础设施）技术的应用越来越广泛。

其中数字证书是PKI基础设施中的重要概念，它是用户在网络交易中的电子身份凭证，是一个由权威机构CA（Certificate Authority）中心发行的。

应用系统在使用证书前，必须先验证数字证书的有效性，包括CA对证书的签名值、证书签发者、证书使用策略、证书有效期及证书状态等。

其中证书状态是指在证书的生命周期中，由于某些原因（私钥泄露、人员调离等）一些证书会被撤销，被撤销的证书其状态被标识为无效，这就需要一个证书状态查询系统。

现有PKI系统所提供的证书状态查询机制主要有两种：基于CRL （Certificate Revoke List，证书撤销列表）的查询机制和基于OCSP（Online Certificate Status Protocol，在线证书状态协议）的实时查询机制。

CRL是一种最简单、最常用的证书撤销方法。

CRL是由颁发证书的CA定期签发的一个由其签名的数据结构，内含该CA撤销的所有证书列表。

但CRL在使用过程中有其局限性：（1）时效性差由于CRL撤销列表是定时发布的，发布周期往往需要几天或几周，甚至更长，因此在CRL表本次发布后下次发布前撤销的证书，无法准确识别其状态，会给交易带来隐患。

X.509 数字证书结构简介1、简介X.509被广泛使用的数字证书标准，是由国际电联电信委员会（ITU-T）为单点登录（SSO-Single Sign-on）和授权管理基础设施（PMI-Privilege Management Infrastructure）制定的PKI标准。

X.509定义了（但不仅限于）公钥证书、证书吊销清单、属性证书和证书路径验证算法等证书标准。

在X.509系统中，CA签发的证书依照X.500的管理，绑定了一个唯一甄别名（DN-Distinguished Name ），可以包含多个字段和值，还可以支持别名（Alternative Name ）。

一个组织受信任的根证书会分发给所有需要用到的PKI系统的员工手上。

主流浏览器：IE、Netscape/Mozilla，Opera和Safari会预先安装一部分根证书，这些根证书都是受信任的证书认证机构CA，这样他们颁发的证书，浏览器将可以直接信任。

虽然用户可以删除或者禁用这些根证书，但事实上，用户很少这么做。

在最新的微软平台，甚至会在用户移除了预先安置的根证书后，当用户再访问这些被删除的根证书网站的时候，会自动将这些根证书恢复到信任列表中。

X.509包含了一个证书吊销列表（CRL-Certificate Revocation List）实施的标准，这在PKI系统中经常被人所忽略。

IETF提出的检查证书有效性的方法是在线证书状态(OCSP- Online Certificate Status Protocol)。

Firefo3 缺省就是使用OCSP协议。

2、历史和用途X.509最初是在1988年的7月3日发布的，版本是X.509 v1，当时是作为ITU X.500目录服务标准的一部分。

它设定了一系列严格的CA分级体系来颁发数字证书。

和其他网络信任模型（譬如PGP)对比，任何人，不仅仅是特定的CA，可以签发并验证其他密钥证书的有效性。

X.509 2 版引入了主体和签发人唯一标识符的概念，以解决主体和/或签发人名称在一段时间后可能重复使用的问题。

Network Working Group M. Myers Request for Comments: 2560 VeriSign Category: Standards Track R. Ankney CertCo A. Malpani ValiCert S. Galperin My CFO C. Adams Entrust Technologies June 1999 X.509 Internet Public Key InfrastructureOnline Certificate Status Protocol - OCSPStatus of this MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited. Copyright NoticeCopyright (C) The Internet Society (1999). All Rights Reserved.1. AbstractThis document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. Additionalmechanisms addressing PKIX operational requirements are specified in separate documents.An overview of the protocol is provided in section 2. Functionalrequirements are specified in section 4. Details of the protocol are in section 5. We cover security issues with the protocol in section6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1syntactic elements and appendix C specifies the mime types for themessages.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119].Myers, et al. Standards Track [Page 1]2. Protocol OverviewIn lieu of or as a supplement to checking against a periodic CRL, it may be necessary to obtain timely information regarding therevocation status of a certificate (cf. [RFC2459], Section 3.3).Examples include high-value funds transfer or large stock trades.The Online Certificate Status Protocol (OCSP) enables applications to determine the (revocation) state of an identified certificate. OCSPmay be used to satisfy some of the operational requirements ofproviding more timely revocation information than is possible withCRLs and may also be used to obtain additional status information. An OCSP client issues a status request to an OCSP responder and suspends acceptance of the certificate in question until the responderprovides a response.This protocol specifies the data that needs to be exchanged betweenan application checking the status of a certificate and the serverproviding that status.2.1 RequestAn OCSP request contains the following data:-- protocol version-- service request-- target certificate identifier-- optional extensions which MAY be processed by the OCSP ResponderUpon receipt of a request, an OCSP Responder determines if:1. the message is well formed2. the responder is configured to provide the requested service and3. the request contains the information needed by the responder Ifany one of the prior conditions are not met, the OCSP responderproduces an error message; otherwise, it returns a definitiveresponse.2.2 ResponseOCSP responses can be of various types. An OCSP response consists of a response type and the bytes of the actual response. There is onebasic type of OCSP response that MUST be supported by all OCSPservers and clients. The rest of this section pertains only to thisbasic response type.Myers, et al. Standards Track [Page 2]All definitive response messages SHALL be digitally signed. The keyused to sign the response MUST belong to one of the following:-- the CA who issued the certificate in question-- a Trusted Responder whose public key is trusted by the requester-- a CA Designated Responder (Authorized Responder) who holds aspecially marked certificate issued directly by the CA, indicating that the responder may issue OCSP responses for that CAA definitive response message is composed of:-- version of the response syntax-- name of the responder-- responses for each of the certificates in a request-- optional extensions-- signature algorithm OID-- signature computed across hash of the responseThe response for each of the certificates in a request consists of-- target certificate identifier-- certificate status value-- response validity interval-- optional extensionsThis specification defines the following definitive responseindicators for use in the certificate status value:-- good-- revoked-- unknownThe "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that the certificateis not revoked, but does not necessarily mean that the certificatewas ever issued or that the time at which the response was producedis within the certificate’s validity interval. Response extensionsmay be used to convey additional information on assertions made bythe responder regarding the status of the certificate such aspositive statement about issuance, validity, etc.The "revoked" state indicates that the certificate has been revoked(either permanantly or temporarily (on hold)).The "unknown" state indicates that the responder doesn’t know aboutthe certificate being requested.Myers, et al. Standards Track [Page 3]2.3 Exception CasesIn case of errors, the OCSP Responder may return an error message.These messages are not signed. Errors can be of the following types: -- malformedRequest-- internalError-- tryLater-- sigRequired-- unauthorizedA server produces the "malformedRequest" response if the requestreceived does not conform to the OCSP syntax.The response "internalError" indicates that the OCSP responderreached an inconsistent internal state. The query should be retried, potentially with another responder.In the event that the OCSP responder is operational, but unable toreturn a status for the requested certificate, the "tryLater"response can be used to indicate that the service exists, but istemporarily unable to respond.The response "sigRequired" is returned in cases where the serverrequires the client sign the request in order to construct aresponse.The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server.2.4 Semantics of thisUpdate, nextUpdate and producedAtResponses can contain three times in them - thisUpdate, nextUpdateand producedAt. The semantics of these fields are:- thisUpdate: The time at which the status being indicated is knownto be correct- nextUpdate: The time at or before which newer information will beavailable about the status of the certificate- producedAt: The time at which the OCSP responder signed thisresponse.If nextUpdate is not set, the responder is indicating that newerrevocation information is available all the time.Myers, et al. Standards Track [Page 4]2.5 Response Pre-productionOCSP responders MAY pre-produce signed responses specifying thestatus of certificates at a specified time. The time at which thestatus was known to be correct SHALL be reflected in the thisUpdatefield of the response. The time at or before which newer information will be available is reflected in the nextUpdate field, while thetime at which the response was produced will appear in the producedAt field of the response.2.6 OCSP Signature Authority DelegationThe key that signs a certificate’s status information need not be the same key that signed the certificate. A certificate’s issuerexplicitly delegates OCSP signing authority by issuing a certificate containing a unique value for extendedKeyUsage in the OCSP signer’scertificate. This certificate MUST be issued directly to theresponder by the cognizant CA.2.7 CA Key CompromiseIf an OCSP responder knows that a particular CA’s private key hasbeen compromised, it MAY return the revoked state for allcertificates issued by that CA.3. Functional Requirements3.1 Certificate ContentIn order to convey to OCSP clients a well-known point of information access, CAs SHALL provide the capability to include theAuthorityInfoAccess extension (defined in [RFC2459], section 4.2.2.1) in certificates that can be checked using OCSP. Alternatively, theaccessLocation for the OCSP provider may be configured locally at the OCSP client.CAs that support an OCSP service, either hosted locally or providedby an Authorized Responder, MUST provide for the inclusion of a value for a uniformResourceIndicator (URI) accessLocation and the OID value id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.The value of the accessLocation field in the subject certificatedefines the transport (e.g. HTTP) used to access the OCSP responderand may contain other transport dependent information (e.g. a URL). Myers, et al. Standards Track [Page 5]3.2 Signed Response Acceptance RequirementsPrior to accepting a signed response as valid, OCSP clients SHALLconfirm that:1. The certificate identified in a received response corresponds tothat which was identified in the corresponding request;2. The signature on the response is valid;3. The identity of the signer matches the intended recipient of therequest.4. The signer is currently authorized to sign the response.5. The time at which the status being indicated is known to becorrect (thisUpdate) is sufficiently recent.6. When available, the time at or before which newer information will be available about the status of the certificate (nextUpdate) isgreater than the current time.4. Detailed ProtocolThe ASN.1 syntax imports terms defined in [RFC2459]. For signaturecalculation, the data to be signed is encoded using the ASN.1distinguished encoding rules (DER) [X.690].ASN.1 EXPLICIT tagging is used as a default unless specifiedotherwise.The terms imported from elsewhere are: Extensions,CertificateSerialNumber, SubjectPublicKeyInfo, Name,AlgorithmIdentifier, CRLReason4.1 RequestsThis section specifies the ASN.1 specification for a confirmationrequest. The actual formatting of the message could vary depending on the transport mechanism used (HTTP, SMTP, LDAP, etc.).4.1.1 Request SyntaxOCSPRequest ::= SEQUENCE {tbsRequest TBSRequest,optionalSignature [0] EXPLICIT Signature OPTIONAL }TBSRequest ::= SEQUENCE {Myers, et al. Standards Track [Page 6]version [0] EXPLICIT Version DEFAULT v1,requestorName [1] EXPLICIT GeneralName OPTIONAL,requestList SEQUENCE OF Request,requestExtensions [2] EXPLICIT Extensions OPTIONAL }Signature ::= SEQUENCE {signatureAlgorithm AlgorithmIdentifier,signature BIT STRING,certs [0] EXPLICIT SEQUENCE OF CertificateOPTIONAL}Version ::= INTEGER { v1(0) }Request ::= SEQUENCE {reqCert CertID,singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL }CertID ::= SEQUENCE {hashAlgorithm AlgorithmIdentifier,issuerNameHash OCTET STRING, -- Hash of Issuer’s DNissuerKeyHash OCTET STRING, -- Hash of Issuers public keyserialNumber CertificateSerialNumber }issuerNameHash is the hash of the Issuer’s distinguished name. Thehash shall be calculated over the DER encoding of the issuer’s namefield in the certificate being checked. issuerKeyHash is the hash of the Issuer’s public key. The hash shall be calculated over the value (excluding tag and length) of the subject public key field in theissuer’s certificate. The hash algorithm used for both these hashes, is identified in hashAlgorithm. serialNumber is the serial number of the certificate for which status is being requested.4.1.2 Notes on the Request SyntaxThe primary reason to use the hash of the CA’s public key in addition to the hash of the CA’s name, to identify the issuer, is that it ispossible that two CAs may choose to use the same Name (uniqueness in the Name is a recommendation that cannot be enforced). Two CAs willnever, however, have the same public key unless the CAs eitherexplicitly decided to share their private key, or the key of one ofthe CAs was compromised.Support for any specific extension is OPTIONAL. The critical flagSHOULD NOT be set for any of them. Section 4.4 suggests severaluseful extensions. Additional extensions MAY be defined inadditional RFCs. Unrecognized extensions MUST be ignored (unless they have the critical flag set and are not understood).Myers, et al. Standards Track [Page 7]The requestor MAY choose to sign the OCSP request. In that case, the signature is computed over the tbsRequest structure. If the requestis signed, the requestor SHALL specify its name in the requestorName field. Also, for signed requests, the requestor MAY includecertificates that help the OCSP responder verify the requestor’ssignature in the certs field of Signature.4.2 Response SyntaxThis section specifies the ASN.1 specification for a confirmationresponse. The actual formatting of the message could vary dependingon the transport mechanism used (HTTP, SMTP, LDAP, etc.).4.2.1 ASN.1 Specification of the OCSP ResponseAn OCSP response at a minimum consists of a responseStatus fieldindicating the processing status of the prior request. If the valueof responseStatus is one of the error conditions, responseBytes arenot set.OCSPResponse ::= SEQUENCE {responseStatus OCSPResponseStatus,responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }OCSPResponseStatus ::= ENUMERATED {successful (0), --Response has valid confirmationsmalformedRequest (1), --Illegal confirmation requestinternalError (2), --Internal error in issuertryLater (3), --Try again later--(4) is not usedsigRequired (5), --Must sign the requestunauthorized (6) --Request unauthorized}The value for responseBytes consists of an OBJECT IDENTIFIER and aresponse syntax identified by that OID encoded as an OCTET STRING.ResponseBytes ::= SEQUENCE {responseType OBJECT IDENTIFIER,response OCTET STRING }For a basic OCSP responder, responseType will be id-pkix-ocsp-basic. id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } Myers, et al. Standards Track [Page 8]OCSP responders SHALL be capable of producing responses of the id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL becapable of receiving and processing responses of the id-pkix-ocsp-basic response type.The value for response SHALL be the DER encoding ofBasicOCSPResponse.BasicOCSPResponse ::= SEQUENCE {tbsResponseData ResponseData,signatureAlgorithm AlgorithmIdentifier,signature BIT STRING,certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } The value for signature SHALL be computed on the hash of the DERencoding ResponseData.ResponseData ::= SEQUENCE {version [0] EXPLICIT Version DEFAULT v1,responderID ResponderID,producedAt GeneralizedTime,responses SEQUENCE OF SingleResponse,responseExtensions [1] EXPLICIT Extensions OPTIONAL }ResponderID ::= CHOICE {byName [1] Name,byKey [2] KeyHash }KeyHash ::= OCTET STRING -- SHA-1 hash of responder’s public key(excluding the tag and length fields)SingleResponse ::= SEQUENCE {certID CertID,certStatus CertStatus,thisUpdate GeneralizedTime,nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL,singleExtensions [1] EXPLICIT Extensions OPTIONAL }CertStatus ::= CHOICE {good [0] IMPLICIT NULL,revoked [1] IMPLICIT RevokedInfo,unknown [2] IMPLICIT UnknownInfo }RevokedInfo ::= SEQUENCE {revocationTime GeneralizedTime,revocationReason [0] EXPLICIT CRLReason OPTIONAL }UnknownInfo ::= NULL -- this can be replaced with an enumerationMyers, et al. Standards Track [Page 9]4.2.2 Notes on OCSP Responses4.2.2.1 TimeThe thisUpdate and nextUpdate fields define a recommended validityinterval. This interval corresponds to the {thisUpdate, nextUpdate}interval in CRLs. Responses whose nextUpdate value is earlier thanthe local system time value SHOULD be considered unreliable.Responses whose thisUpdate time is later than the local system timeSHOULD be considered unreliable. Responses where the nextUpdate value is not set are equivalent to a CRL with no time for nextUpdate (seeSection 2.4).The producedAt time is the time at which this response was signed.4.2.2.2 Authorized RespondersThe key that signs a certificate’s status information need not be the same key that signed the certificate. It is necessary however toensure that the entity signing this information is authorized to doso. Therefore, a certificate’s issuer MUST either sign the OCSPresponses itself or it MUST explicitly designate this authority toanother entity. OCSP signing delegation SHALL be designated by theinclusion of id-kp-OCSPSigning in an extendedKeyUsage certificateextension included in the OCSP response signer’s certificate. Thiscertificate MUST be issued directly by the CA that issued thecertificate in question.id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}Systems or applications that rely on OCSP responses MUST be capableof detecting and enforcing use of the id-ad-ocspSigning value asdescribed above. They MAY provide a means of locally configuring one or more OCSP signing authorities, and specifying the set of CAs forwhich each signing authority is trusted. They MUST reject theresponse if the certificate required to validate the signature on the response fails to meet at least one of the following criteria:1. Matches a local configuration of OCSP signing authority for thecertificate in question; or2. Is the certificate of the CA that issued the certificate inquestion; or3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsageextension and is issued by the CA that issued the certificate inquestion."Myers, et al. Standards Track [Page 10]Additional acceptance or rejection criteria may apply to either theresponse itself or to the certificate used to validate the signature on the response.4.2.2.2.1 Revocation Checking of an Authorized ResponderSince an Authorized OCSP responder provides status information forone or more CAs, OCSP clients need to know how to check that anauthorized responder’s certificate has not been revoked. CAs maychoose to deal with this problem in one of three ways:- A CA may specify that an OCSP client can trust a responder for the lifetime of the responder’s certificate. The CA does so by including the extension id-pkix-ocsp-nocheck. This SHOULD be a non-criticalextension. The value of the extension should be NULL. CAs issuingsuch a certificate should realized that a compromise of theresponder’s key, is as serious as the compromise of a CA key used to sign CRLs, at least for the validity period of this certificate. CA’s may choose to issue this type of certificate with a very shortlifetime and renew it frequently.id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }- A CA may specify how the responder’s certificate be checked forrevocation. This can be done using CRL Distribution Points if thecheck should be done using CRLs or CRL Distribution Points, orAuthority Information Access if the check should be done in someother way. Details for specifying either of these two mechanisms are available in [RFC2459].- A CA may choose not to specify any method of revocation checkingfor the responder’s certificate, in which case, it would be up to the OCSP client’s local security policy to decide whether thatcertificate should be checked for revocation or not.4.3 Mandatory and Optional Cryptographic AlgorithmsClients that request OCSP services SHALL be capable of processingresponses signed used DSA keys identified by the DSA sig-alg-oidspecified in section 7.2.2 of [RFC2459]. Clients SHOULD also becapable of processing RSA signatures as specified in section 7.2.1 of [RFC2459]. OCSP responders SHALL support the SHA1 hashing algorithm.4.4 ExtensionsThis section defines some standard extensions, based on the extension model employed in X.509 version 3 certificates see [RFC2459]. Support for all extensions is optional for both clients and responders. For Myers, et al. Standards Track [Page 11]each extension, the definition indicates its syntax, processingperformed by the OCSP Responder, and any extensions which areincluded in the corresponding response.4.4.1 NonceThe nonce cryptographically binds a request and a response to prevent replay attacks. The nonce is included as one of the requestExtensions in requests, while in responses it would be included as one of theresponseExtensions. In both the request and the response, the noncewill be identified by the object identifier id-pkix-ocsp-nonce, while the extnValue is the value of the nonce.id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }4.4.2 CRL ReferencesIt may be desirable for the OCSP responder to indicate the CRL onwhich a revoked or onHold certificate is found. This can be usefulwhere OCSP is used between repositories, and also as an auditingmechanism. The CRL may be specified by a URL (the URL at which theCRL is available), a number (CRL number) or a time (the time at which the relevant CRL was created). These extensions will be specified as singleExtensions. The identifier for this extension will be id-pkix- ocsp-crl, while the value will be CrlID.id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }CrlID ::= SEQUENCE {crlUrl [0] EXPLICIT IA5String OPTIONAL,crlNum [1] EXPLICIT INTEGER OPTIONAL,crlTime [2] EXPLICIT GeneralizedTime OPTIONAL }For the choice crlUrl, the IA5String will specify the URL at whichthe CRL is available. For crlNum, the INTEGER will specify the value of the CRL number extension of the relevant CRL. For crlTime, theGeneralizedTime will indicate the time at which the relevant CRL was issued.4.4.3 Acceptable Response TypesAn OCSP client MAY wish to specify the kinds of response types itunderstands. To do so, it SHOULD use an extension with the OID id-pkix-ocsp-response, and the value AcceptableResponses. Thisextension is included as one of the requestExtensions in requests.The OIDs included in AcceptableResponses are the OIDs of the various response types this client can accept (e.g., id-pkix-ocsp-basic). Myers, et al. Standards Track [Page 12]id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIERAs noted in section 4.2.1, OCSP responders SHALL be capable ofresponding with responses of the id-pkix-ocsp-basic response type.Correspondingly, OCSP clients SHALL be capable of receiving andprocessing responses of the id-pkix-ocsp-basic response type.4.4.4 Archive CutoffAn OCSP responder MAY choose to retain revocation information beyond a certificate’s expiration. The date obtained by subtracting thisretention interval value from the producedAt time in a response isdefined as the certificate’s "archive cutoff" date.OCSP-enabled applications would use an OCSP archive cutoff date tocontribute to a proof that a digital signature was (or was not)reliable on the date it was produced even if the certificate neededto validate the signature has long since expired.OCSP servers that provide support for such historical referenceSHOULD include an archive cutoff date extension in responses. Ifincluded, this value SHALL be provided as an OCSP singleExtensionsextension identified by id-pkix-ocsp-archive-cutoff and of syntaxGeneralizedTime.id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } ArchiveCutoff ::= GeneralizedTimeTo illustrate, if a server is operated with a 7-year retentioninterval policy and status was produced at time t1 then the value for ArchiveCutoff in the response would be (t1 - 7 years).4.4.5 CRL Entry ExtensionsAll the extensions specified as CRL Entry Extensions - in Section 5.3 of [RFC2459] - are also supported as singleExtensions.4.4.6 Service LocatorAn OCSP server may be operated in a mode whereby the server receives a request and routes it to the OCSP server which is known to beauthoritative for the identified certificate. The serviceLocatorrequest extension is defined for this purpose. This extension isincluded as one of the singleRequestExtensions in requests.Myers, et al. Standards Track [Page 13]id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } ServiceLocator ::= SEQUENCE {issuer Name,locator AuthorityInfoAccessSyntax OPTIONAL }Values for these fields are obtained from the corresponding fields in the subject certificate.5. Security ConsiderationsFor this service to be effective, certificate using systems mustconnect to the certificate status service provider. In the event such a connection cannot be obtained, certificate-using systems couldimplement CRL processing logic as a fall-back position.A denial of service vulnerability is evident with respect to a flood of queries. The production of a cryptographic signature significantly affects response generation cycle time, thereby exacerbating thesituation. Unsigned error responses open up the protocol to anotherdenial of service attack, where the attacker sends false errorresponses.The use of precomputed responses allows replay attacks in which anold (good) response is replayed prior to its expiration date butafter the certificate has been revoked. Deployments of OCSP shouldcarefully evaluate the benefit of precomputed responses against theprobability of a replay attack and the costs associated with itssuccessful execution.Requests do not contain the responder they are directed to. Thisallows an attacker to replay a request to any number of OCSPresponders.The reliance of HTTP caching in some deployment scenarios may result in unexpected results if intermediate servers are incorrectlyconfigured or are known to possess cache management faults.Implementors are advised to take the reliability of HTTP cachemechanisms into account when deploying OCSP over HTTP.Myers, et al. Standards Track [Page 14]6. References[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "InternetX.509 Public Key Infrastructure Certificate and CRLProfile", RFC 2459, January 1999.[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.[URL] Berners-Lee, T., Masinter, L. and M. McCahill, "UniformResource Locators (URL)", RFC 1738, December 1994.[X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995,Information Technology - ASN.1 encoding rules:Specification of Basic Encoding Rules (BER), CanonicalEncoding Rules (CER) and Distinguished Encoding Rules(DER).Myers, et al. Standards Track [Page 15]。

与pki相关的标准
与pki（公钥基础设施）相关的标准有很多，以下是其中一些常见的标准：
1. X.509：这是一种数字证书标准，用于在公钥基础设施中发布和管理数字证书。

X.509标准定义了证书的主题、颁发者和有效期等属性，以及如何使用证书来验证身份和授权。

2. PKCS（公钥密码标准）：PKCS是一组与公钥基础设施相关的标准，包括PKCS#1、PKCS#7、PKCS#8、PKCS#10、PKCS#11和PKCS#12等。

这些标准定义了与公钥密码学相关的算法、协议和格式，例如RSA、椭圆曲线和数字签名等。

3. LDAP（轻量级目录访问协议）：LDAP是一种用于访问目录服务的协议，它定义了如何在公钥基础设施中使用目录服务来存储和管理数字证书和密钥。

4. SMIME（安全/多用途互联网邮件扩展）：SMIME是一种用于在互联网上发送加密的电子邮件的协议，它定义了如何在公钥基础设施中使用加密和数字签名来保护电子邮件。

5. OCSP（在线证书状态协议）：OCSP是一种用于检查数字证书是否被吊销的协议，它定义了如何在公钥基础设施中使用OCSP来检查数字证书的状态。

6. CRL（证书吊销列表）：CRL是一种包含已吊销证书列表的公告，它定义了如何在公钥基础设施中发布和管理CRL，以便验证数字
证书的有效性。

这些标准通常一起使用，以确保公钥基础设施的安全、可靠和互操作性。