RFC2560(x.509因特网公钥基础设施在线证书状态协议——OCSP )
PKI安全体系标准规范
PKI安全体系标准规范 PKI安全体系标准规范 发布单位
公钥加密标准（Public Key 美国RSA数据安全公司及其 第一代标准 Cryptography Standards，PKCS）系 合作伙伴 列
ITU-T X.509
ITU-T
RFC 2459 Internet X.509 公钥基础 IETF 设施证书和CRL简介 RFC 2560 x.509因特网公钥基础设施 IETF 在线证书状态协议——OCSP
RFC 2510 公钥基础设施证书管理协 议 RFC 2511 证书信息请求格式 RFC 3647 公钥基础设施政策实施框 架 RFC3280 X.509 V3证书 RFC2528 密钥交换算法KEA（Key Exchange Algorithm） RFC3039 高可信证书（Qualified Certificates） RFC3279 X.509 v3 公钥证书 RFC2559 公钥基础设施 LDAP v2 RFC2585 Internet X.509 公钥基础 设施: FTP and HTTP RFC2587 Internet X.509 公钥基础 设施 LDAPv2 Schema RFC2527 Internet X.509 公钥基础 设施 Certificate Policy and Certification Practices
微软、Versign和 webMethods 微软、Versign和 webMethods
国内规范
GB/T 19713- 信息技术 安全技术 公钥基础设施 在 信息安全标准委员会 2005 线证书 安全技术 公钥基础设施 证 信息安全标准委员会 2005 书管理协议
国内规范
本标准规定了一种无需请求证书撤销列表（CRL）即可 查询数字证书状态的机制（即在线证书状态协议-OCSP）。该机制可代替CRL或作为周期性检查CRL的一种 补充方式，以便及时获得证书撤销状态的有关信息。本 标准主要描述了以下内容：a）具体描述了在线证书状 态协议的请求形式；b）具体描述了在线证书状态协议 的响应形式；c）分析了处理在线证书状态协议响应时 可能出现的各种异常情况；d）说明了在线证书状态协 议基于超文本传输协议（HTTP）的应用方式；e）提供 了采用抽象语法记法1（ASN.1）描述的在线证书状态协 本标准描述了公钥基础设施(PKI)中的证书管理协议， 定义了与证书产生和管理相关的各方面所需要的协议消 息，这些消息主要包括申请证书、撤销证书、密钥更新 、密钥恢复、交叉认证等。本标准主要适用于在安全或 不安全环境中实施PKI组件并实施管理，可作为PKI运 营机构、PKI组件开发者的参考指南。 本部分提出了基本的管理概念和模型，将这些概念和模 型引入IT安全管理是必要的。在指南的其余部分还将进 一步讨论和开发这些概念和模型以提供更详细的指南。 为有助于标识和管理IT安全的各个方面可以同时使用本 提出IT安全管理的一些基本专题以及这些专题之间的关 系 本部分为GB/T15843的第5部分，等同采用国际标准 ISO/IEC 9798—5：1999《信息技术实体鉴别 第5部 分：使用零知识技术的机制》(英文版)。 规定了任意长度消息的带附录的基于身份的数字签名和 验证过程的总的结构和基本过程 本部分规定了带附录的基于证书的数字签名机制。特别 是，本部分提供了：1）基于证书的签名机制的一般描 述，其安全性是基于所用交换群上的离散对数问题的困 难性。2）基于证书的签名机制的一般描述，其安全机 制是基于因子分解的困难性。3）使用任意长度消息的 基于证书机制的带附录的各种常规数字签名机制。
x.509认证协议
竭诚为您提供优质文档/双击可除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
⽹络安全服务（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
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)，来对用户的访问进行授权管理。
7、信息安全标准组织及相关标准
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证书状态查询机制与实现吕国忠【摘要】证书状态查询是公钥基础设施中最重要的问题之一,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 数字证书结构简介
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 版引入了主体和签发人唯一标识符的概念，以解决主体和/或签发人名称在一段时间后可能重复使用的问题。
rfc2560.X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
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相关的标准
与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，以便验证数字
证书的有效性。
这些标准通常一起使用，以确保公钥基础设施的安全、可靠和互操作性。
基于EJBCA的证书状态查询系统的实现与优化
基于EJBCA的证书状态查询系统的实现与优化星论文网来源： 发布时间：2010-05-30 18:23:361 引言随着电子商务的迅速发展，PKI（Public Key Infrastructure，公钥基础设施）技术的应用将越来越广泛。
在PKI框架中，CA（Certification Authority，认证中心）的主要功能是颁发和管理证书。
证书有一定的生命期，而由于某些原因（私钥泄漏等）一些证书在到期之前会被撤销，证书将不再有效。
证书状态查询是PKI系统中一个重要的问题。
现有PKI 系统所提供的证书状态查询机制一般是基于CRL（Certificate Revoke List，证书撤销列表）的查询机制和基于OCSP协议（Online Certificate Status Protocol，在线证书状态协议）的实时查询机制。
CRL是一种最简单、最常用的证书撤销方法，CRL实质上是由颁发证书的CA定期签发的一个签名的数据结构，内含被该CA撤销的证书列表。
CRL使用证书序列号来标识每一个被撤销的证书。
使用证书的系统就可以通过查询“最近签发”的CRL 来查询证书的状态。
由于CRL是定期发布的，所以不能保证证书撤销信息的实时性和准确性。
OCSP协议是PKIX工作组在RFC2560中提出的协议，给用户提供了一种方便快捷的数字证书状态查询通道，它可以满足那些要求提供比CRL更及时的证书撤销信息的操作要求，例如涉及大量资金的交易或者股票买卖。
因而OCSP可以作为周期性的CRL的一种代替机制或补充机制，使得PKI体系能更有效、更安全地应用于各个领域。
目前，在校园网中部署CA系统的技术已经相对成熟，而且有许多开源的CA系统可供参考。
使用独立的PKI系统，不仅有助于校园网统一管理，而且可以节省大量的费用。
EJBCA用JAVA编写，是一个具有完整功能的证书认证体系，并提供了一个开放的、高性能的、具有独立平台和基于组件的CA。
ocsp原理
OCSP原理名词解释：ocsp：Online Certificate Status Protocol 在线证书状态查询协议是IETF颁布的用于检查数字证书在某一交易时间是否有效的标准在RFC 2560中有描述技术背景：在PKI应用中需要验证证书有效性，CA中心定期颁发证书废除列表，即CRL。
由于CA每隔一定时间才发布CRL，所以CRL不能及时的反应证书的状态。
那么OCSP就能满足实时的在线查询证书状态的要求。
它为电子商务提供了一种检验数字证书有效性的途径，比下载和处理证书撤销清单（CRL）的传统方式更快、更方便和更具独立性。
请求者发送查询请求，ocsp服务器会返回证书可能的三个状态：良好、撤销、未知。
OCSP服务器原理图：OCSP协议：请求一个OCSP请求包含以下数据协议版本服务请求目标证书标识能被OCSP响应器（服务器）处理的可选扩展收到请求后ocsp服务器会检查消息的格式。
并回复。
回复一个确定的回复包括一下数据回复语法的版本响应器（服务器）名称每个证书的回复（注：一个请求的目标证书标识可以包括N个证书）可选扩展签名算法对象标识符号对回复信息散列后的签名每个证书的回复包括：目标证书识别证书状态值回复有效期可选扩展状态值：良好、已撤消、未知良好表示没有被撤销，但是并不表示该证书曾经被颁发或在有效期内。
因为该证书未颁发或者不在有效期是不在吊销列表中的。
如果想知道证书的更详细信息必须在扩展中设置。
已撤消”状态表示证书已被撤消。
未知：表示响应器不知道请求的证书。
基于HTTP的OCSP基于OCSP的HTTP请求可以使用OST方法来提交他们的请求。
内容类型头部（Content-Type header）的值为“应用/OCSP-请求”（ "application/ocsp-request"），同时信息主体是OCSP请求（OCSPRequest）DER编码的二进制值。
一个基于HTTP的OCSP回复的组成是，适当的HTTP头部，紧跟着一个OCSP回复DER编码的二进制值。
中文RFC文档阅读 2501-3000
中文RFC文档阅读2501-3000ＲＦＣ2508 低速串行链路下IP/UDP/RTP数据包头的压缩ＲＦＣ2511 Internet X.509认证请求消息格式ＲＦＣ2516 在以太网上传输PPP的方法（PPPoE）ＲＦＣ2526 IPv6保留的子网任意传送地址ＲＦＣ2541 DNS 安全操作考虑ＲＦＣ2547 BGP/MPLS VPNsＲＦＣ2554 SMTP服务认证扩展ＲＦＣ2560 x.509因特网公钥基础设施在线证书状态协议——OCSPＲＦＣ2570 标准互联网络管理框架第三版介绍ＲＦＣ2577 FTP 安全考虑ＲＦＣ2581 TCP拥塞控制ＲＦＣ2582 TCP的快速恢复算法NewReno修正ＲＦＣ2585 Internet X.509 公共键底部结构操作协议: FTP和HTTPＲＦＣ2597 确定的面向PHB组ＲＦＣ2598 面向加速PHBＲＦＣ2618 RADIUS 身份验证客户端管理系统库(MIB)ＲＦＣ2629 用XML 写I-Ds 和ＲＦＣ文档ＲＦＣ2633 S/多用途网际邮件扩充协议(MIME) 版本3 信息说明书ＲＦＣ2644 更改直接广播在路由器上的缺省值ＲＦＣ2669 DOCSIS 电缆设备管理系统库(MIB) 电缆设备管理信息基础用于DOCSIS 适应性电缆调制解调器和电缆调制解调器中断系统ＲＦＣ2670 音频频率(RF)界面管理信息基础用于MCNS/DOCSIS适应性RF界面ＲＦＣ2685 虚拟专用网标志符ＲＦＣ2702 基于MPLS的流量工程要求ＲＦＣ2706 ECML v1:电子商务字段名ＲＦＣ2713 LDAP（轻型目录存取协议）目录中JAVATM对象的表征模式ＲＦＣ2714 LDAP（轻型目录存取协议）目录中的CORBA对象参考方案ＲＦＣ2731 Dublin核心元数据在HTML上的编码ＲＦＣ2732 文本IPv6地址在URL上的格式ＲＦＣ2733 RTP有效载荷格式用于普通正向错误更正ＲＦＣ2736 RTP有效载荷格式说明书作者的指导方针ＲＦＣ2754 RPS IANA的发布ＲＦＣ2756 超文本缓存协议(HTCP/0.0)ＲＦＣ2764 IP VPN的框架体系ＲＦＣ2773 使用KEA和SKIPJACK加密ＲＦＣ2774 HTTP 扩展框架ＲＦＣ2781 UTF-16,ISO 10646的一种编码ＲＦＣ2784 通用路由封装（GRE）ＲＦＣ2788 网络服务监视MIBＲＦＣ2793 用于文本交谈的RTP负载ＲＦＣ2796 BGP路由映象ＲＦＣ2809 通过RADIUS的L2TP强制通道的执行ＲＦＣ2810 Internet 延迟交谈:体系结构ＲＦＣ2811 Internet延迟交谈：通道管理ＲＦＣ2813 Internet 延迟交谈:服务器协议ＲＦＣ2817 在HTTP/1.1中升级到TLSＲＦＣ2818 TLS之上的HTTPＲＦＣ2824 呼叫过程语言框架和要求ＲＦＣ2825 复杂网络:I18N的发布,域名,和其它Internet协议ＲＦＣ2829 LDAP的身份验证方法ＲＦＣ2830 轻量级目录访问协议(v3): 传输层安全扩展ＲＦＣ2833 用于DTMF数字信号、电话音和电话信号的RTP负载格式ＲＦＣ2854 text/html 媒体类型ＲＦＣ2855 IEEE 1394的DHCPＲＦＣ2861 TCP 拥塞窗口检验ＲＦＣ2862 用于实时指针的RTP负载格式ＲＦＣ2866 RADIUS（远程用户拨号认证系统）记帐协议ＲＦＣ2867 RADIUS 账目管理修改用于通道协议支持ＲＦＣ2868 RADIUS 属性用于协议支持ＲＦＣ2869 RADIUS 扩展ＲＦＣ2871 一个IP电话路由框架ＲＦＣ2873 在Ipv4优先域中的TCP过程ＲＦＣ2874 支持IPv6地址集合和重编号的DNS 扩展ＲＦＣ2882 网络访问服务要求: 扩展范围实践ＲＦＣ2887 可靠的多点传送设计空间用于大的数据传送ＲＦＣ2889 基准方法论用于局域网交换设备ＲＦＣ2890 GRE中Key和SequenceNumber扩展ＲＦＣ2893 IPv6 主机和软件路由器转换机制ＲＦＣ2898 PKCS #5: 基于密码的密码系统说明书版本 2.0. BＲＦＣ2906 AAA 授权要求ＲＦＣ2914 拥塞控制原理ＲＦＣ2917 核心MPLS IP VPN 体系结构ＲＦＣ2918 BGP-4（边界网关协议）的路由刷新功能ＲＦＣ2920 SMTP 针对命令流水线的服务扩展ＲＦＣ2923 TCP的路径MTU发现问题ＲＦＣ2932 IPv4 多点传送路由管理系统库(MIB)ＲＦＣ2935 Internet开放贸易协议(IOTP)HTTP 补充ＲＦＣ2939 新DHCP选项和信息类型的定义步骤和IANA指导方针ＲＦＣ2945 SRP身份验证和键交换系统ＲＦＣ2946 Telnet 数据加密选项ＲＦＣ2947 Telnet加密：DES3 64位密码回馈ＲＦＣ2948 Telnet加密：DES3 64位输出回馈ＲＦＣ2949 Telnet加密:CAST-128 64比特输出回馈ＲＦＣ2950 Telnet加密:CAST-128 64比特密码回馈ＲＦＣ2951 使用KEA和SKIPJACK进行TELNET身份验证ＲＦＣ2952 Telnet加密：DES 64位密码回馈ＲＦＣ2953 Telnet加密:DES 64比特输出回馈ＲＦＣ2957 The 应用/whoispp-请求目录-类型ＲＦＣ2958 The 应用/whoispp-回答目录-类型ＲＦＣ2959 实时传输协议管理信息库ＲＦＣ2964 超文本传输协议(HTTP)状态管理的应用ＲＦＣ2971 Internet信息访问协议(IMAP4)的标识符扩展ＲＦＣ2976 SIP信息方法ＲＦＣ2983 有区别的协议和通道ＲＦＣ2984 CAST-128密码算法在CMS中的使用ＲＦＣ2987 字符集注册和语言媒体特征标签ＲＦＣ2988 计算TCP重传时间的定时器ＲＦＣ2991 多路径分发在Unicast上和多点传送下一路程段选择ＲＦＣ2992 等值多-路径算法的分析ＲＦＣ2994 MISTY1加密算法的描述。
X.509 数字证书的基本原理及应用
X.509 数字证书的基本原理及应用一、前言数字证书是现代互联网中个体间相互信任的基石。
如果没有了数字证书，那么也就没有了各式各样的电商平台以及方便的电子支付服务。
数字证书是网络安全中的一个非常重要组成部分。
如果要学好网络安全，那么必须充分理解它的原理。
目前我们所提到的数字证书都是基于 ITU 制定的 X.509 标准。
二、基础知识2.1 非对称加密有两个密钥，一个是Key_1，另一个是Key_2。
一段明文通过某种加密算法用Key_1加密之后的密文只能用Key_2解密，而不能还是用Key_1解密。
反过来，明文用Key_2加密之后的密文只能用Key_1解密，而不能还是用Key_2解密。
满足这种特征的加密算法称为非对称加密算法。
目前常用的非对称加密算法有 RSA、DSA 等。
2.2 摘要算法将各种不定长的「数据」经过某种算法处理之后，总是能生成一段定长的数据。
这段定长的数据称之为「散列值」。
这种算法如果可以满足以下特征，则可以称为摘要算法。
•可以轻松地将各种不定长的「数据」生成「散列值」。
•不能通过「散列值」来反推出原「数据」。
•不能找出具有相同「散列值」的另一个「数据」。
目前常用的摘要算法有 MD5、SHA-1、SHA-256 等。
2.3 数字签名数字签名其实就是把「散列值」经过非对称加密算法加密得到的一个「加密的散列值」。
数字签名的工作流程如下图：数字签名一般用于身份认证和防止抵赖。
2.4 X.509 数字证书结构图简单来说，数字证书就是一张附带了数字签名的信息表。
下图或许可以帮助对本文的理解。
2.5 互联网中常见的信息窃取方式假设客户端「C」想和互联网另一端的服务器「S」进行无保密通信，且客户端「C」没有部署任何服务器身份验证机制。
2.5.1 假冒服务器假冒的服务器「fake_S」冒充「S」，直接与「C」进行通信。
如果「C」打算将密码之类的敏感信息传递到「S」，那么敏感信息就会被「fake_S」截获。
RFC解析
RFC(Request For Comments)-意即“请求注解”，包含了关于Internet的几乎所有重要的文字资料。
如果你想成为网络方面的专家，那么RFC无疑是最重要也是最经常需要用到的资料之一，所以RFC享有网络知识圣经之美誉。
通常，当某家机构或团体开发出了一套标准或提出对某种标准的设想，想要征询外界的意见时，就会在Internet上发放一份RFC，对这一问题感兴趣的人可以阅读该RFC并提出自己的意见；绝大部分网络标准的指定都是以RFC的形式开始，经过大量的论证和修改过程，由主要的标准化组织所指定的，但在RFC中所收录的文件并不都是正在使用或为大家所公认的，也有很大一部分只在某个局部领域被使用或并没有被采用，一份RFC具体处于什么状态都在文件中作了明确的标识。
截止到2001年中期，公布的RFC大约有3000余篇，以下是几个较为稳定的RFC链接，以及几个重要的标准化组织的网站链接>>> RFC的官方站点，可以检查RFC最及时的更新情况最重要的Internet组织之一http://sunsite.dk RFC查询非常强大(可以以FTP登录下载全部RFC文档)http://www.iso.ch ISO-国际标准化组织 IEEE-电气与电子工程师协会 ANSI-美国国家标准化组织http://www.itu.int ITU-国际电信同盟下面的程序连接到的服务器，只要键入想查看的RFC的完整编号，就可以访问该文档；如果你还不是太清楚每个RFC描述的内容，可以先在本站下载RFC的目录文件压缩包>>> rfcindex.zip (141KB)RFC文档下载推荐RFC英文站点：//rfcs/RFC分类检索：以下根据RFC被公布时的状态把RFC索引划分成几类：Standards(标准)Draft Standards(草案标准)Proposed Standards(提案标准)OTHER RFCS(其他RFC)Experimental(实验性的)Informational(知识性的)Historic(历史性的)Early RFCs (before IETF standards track早期的，在IETF标准化之前)RFC SUB-SERIES(RFC子集)Standards (标准，STD)Best Current Practice (最优当前实现，BCP)For Your Information (FYI)RFC文档阅读（中文）：RFC 1-100RFC 101-700RFC 701-1000RFC 1001-1500RFC 1501-2000RFC 2001-2500RFC 2501-3000RFC 3001-3039Supported Internet RFCs and DraftsRFC文档下载（英文）：[RFC1-500](950K)[RFC501-1000](3544K)[RFC1001-1500](13454K)[RFC1501-2000](8494K) [RFC2001-2500](7565K)[RFC2501-3000](9517K)[RFC3001-latest](1187K)常见协议RFC对应表协议层次协议缩写协议英文全称协议中文名RFCApplication LayerCOPS Common Open Policy Service 公共开放策略服务RFC 2748FANP Flow Attribute Notification Protocol 流属性通知协议RFC 2129Finger User Information Protocol 用户信息协议RFC 1194,1196,1228FTP File Transfer Protocol 文件传输协议RFC 959HTTP Hypertext Transfer Protocol 超文本传输协议RFC 1945,2616IMAP4 Internet Message Access Protocol version 4 因特网信息访问协议第四版RFC 1730IMPP Instant Messaging and Presence Protocol 即时信息表示协议RFC 3861IRC Internet Relay Chat Protocol Internet在线聊天协议RFC 1459ISAKMP Internet Security Association and Key Management Protocol ? Interne安全连接和密钥管理协议RFC 2048DNS Domain Name System 域名系统RFC 4343DHCP Dynamic Host Configuration Protocol 动态主机配置协议RFC 2131BOOTP Bootstrap Protocol 引导协议RFC 951NTP Network Time Protocol 网络时间协议RFC 958NNTP Network News Transfer Protocol 网络新闻传输协议RFC 977POP3 Post Office Protocol version 3 邮局协议第三版RFC 1939Radius Remote Authentication Dial In User Service 远程用户拨号认证服务协议RFC 2138RLOGIN Remote Login 远程登陆协议RFC 1258,1282RTSP Real-time Streaming Protocol 实时流协议RFC 2326SCTP Stream Control Transmision Protocol 流控制传输协议RFC 2960S-HTTP Secure Hypertext Transfer Protocol 安全超文本传输协议RFC 2660SLP Service Location Protocol 服务定位协议RFC 2165SMTP Simple Mail Transfer Protocol 简单邮件传输协议RFC 821,2821ICP Internet Cache Protocol Internet缓存协议RFC 2186SNMP Simple Network Management Protocol 简单网络管理协议RFC 1157SOCKS Socket Secure 安全套接字协议RFC 1928TACACS Terminal Access Controller Access Control System 终端访问控制器访问控制系统协议RFC 1492TELNET TCP/IP Terminal Emulation Protocol TCP/IP终端仿真协议RFC 854TFTP Trivial File Transfer Protocol 简单文件传输协议RFC 1350X-Window X Window X Window RFC 1198Presentation LayerNBSSN NetBIOS Session Service NetBIOS会话服务协议RFC 1001LPP LightWight Presentation Protocol 轻量级表示协议RFC 1085Session LayerTLS Transport Layer Security 传输层安全协议RFC 2246LDAP Lightweight Directory Access Protocol 轻量级目录访问协议RFC 1777RPC Remote Procedure Call protocol 远程过程调用协议RFC 1050,1057,1831Transport LayerMobile IP Mobile IP Protocol 移动IP协议RFC 2002RUDP Reliable User Datagram Protocol 可靠的用户数据报协议RFC 908,1151TALI Transport Adapter Layer Interface 传输适配层接口协议RFC 3094TCP Transmission Control Protocol 传输控制协议RFC 793UDP User Datagram Protocol 用户数据报协议RFC 768Van Jacobson compressed TCP 压缩TCP协议RFC 1144XOT X.25 over TCP 基于TCP之上的X.25协议RFC 1613Network LayerEGP Exterior Gateway Protocol 外部网关协议RFC 827OSPF Open Shortest Path First 开放最短路径优先协议RFC 2178,2328DVMRP Distance Vector Multicast Routing Protocol 距离矢量组播路由协议RFC 1075ICMP Internet Control Message Protocol version 4 Internet控制信息协议RFC 792ICMPv6 Internet Control Message Protocol version 6 Internet控制信息协议第6版RFC 1885,2463 IGMP Internet Group Management Protocol Internet组管理协议RFC 1112, 2236,3376IP Internet Protocol version 4 互联网协议RFC 791NHRP Next Hop Resolution Protocol 下一跳解析协议RFC 2332IPv6 Internet Protocol version 6 互联网协议第6版RFC 1883,2460MOSPF Mulitcast Open Shortest Path First 组播开放最短路径优先协议RFC 1585PGM Pragamatic General Mulitcast Protocol 实际通用组播协议RFC 3208PIM-SM Protocol Independent Multicast-Sparse Mode 稀疏模式独立组播协议RFC 2362 PIM-DM Protocol Independent Multicast-Dense Mode 密集模式独立组播协议RFC 3973 SLIP Serial Line IP 串行线路IP协议RFC 1055MARS Multicast Address Resolution Server 组播地址解析服务器协议RFC 2022RIP2 Routing Information Protocol version 2 路由信息协议第2版RFC 2453RIPng for IPv6 Routing Information Protocol for IPv6 IPv6路由信息协议RFC 2080 RSVP Resource-Reservation Protocol 资源预留协议RFC 2205,2750VRRP Virtual Router Redundancy Protocol 虚拟路由器冗余协议RFC 2338,3768AH Authentication Header Protocol 认证头协议RFC 2402ESP Encapsulating Security Payload 安全封装有效载荷协议RFC 2406Data Link LayerARP Address Resolution Protocol 地址解析协议RFC 826RARP Reverse Address Resolution Protocol 逆向地址解析协议RFC 903IARP Inverse Address Resolution Protocol 逆向地址解析协议RFC 2390DCAP Data Link Switching Client Access Protocol 数据转接客户访问协议RFC 2114 MPLS Multi-Protocol Label Switching 多协议标签交换协议RFC 3031,3032ATMP Ascend Tunnel Management Protocol 接入隧道管理协议RFC 2107L2F The Layer 2 Forwarding Protocol 第二层转发协议RFC 2341L2TP Layer 2 Tunneling Protocol 第二层隧道协议RFC 2661PPTP Point to Point Tunneling Protocol 点对点隧道协议RFC 2637常见RFC名称RFC1 主机软件RFC2 主机软件RFC3 文档规范RFC4 网络时间表RFC6 与Bob Kahn 会话RFC10 文档规范RFC13 零文本长度的EOF信息RFC16 M.I.TRFC18 IMP-IMP和主机-主机控制联接RFC19 可用来降低有限交换节点阻塞的两条协议性的建议RFC20 用于网络交换的ASCII 格式RFC21 网络会议RFC22 主机-主机控制信息格式RFC23 多重传送的调节信息RFC24 文档规范RFC25 不使用高的连接号RFC27 文档规范RFC28 时间标准RFC29 响应RFC 28RFC30 文档规范RFC32 关于SRI所提议的实时时钟的一些想法RFC34 关于ARC时钟的一些初步记录摘要RFC35 网络会议RFC36 协议注解RFC37 网络会议结尾等RFC38 NWG/RFC 36 网络协议的注解RFC40 关于未来协议的更多注解RFC41 IMP-IMP 通讯信息RFC42 信息数据类型RFC43 被提议的会议RFC45 关于未来协议的更多注解RFC53 官方协议机构RFC58 逻辑信息同步RFC60 简单的NCP 协议RFC63 迟来的网络会议报告RFC66 NIC - 第三级别的想法和其它噪音RFC69 提议改变主机/IMP 规范来消除标记RFC71 输入错误后的再分配RFC72 建议改变网络协议延期执行RFC73 响应NWG/RFC 67RFC75 网络会议RFC78 NCP状态报告:UCSB/RANDRFC79 圆木协议错误RFC81 涉及信息的请求RFC84 NWG/RFC的1-80列表RFC85 网络工作组会议RFC90 CCN 作为一种网络服务中心RFC99 网络会议RFC101 对1971年2月17日伊利诺斯州的Urbana的网络工作组会议的注释RFC102 主机-主机协议故障清除委员会的说明RFC103 中断键的执行RFC104 连接191RFC105 通过UCSB 进行远程登录和远程输出返回的网络说明书RFC106 用户/服务器站点协议的网络主机问卷RFC107 主机-主机协议故障清除委员会的说明RFC108 1971年2月17-19日在Urbana 举行的NWG 会议的人员列表RFC124 在RFC 107 中有印刷错误RFC132 RFC 107 的排版错误RFC148 RFC 123 的注释RFC149 最好的铺设计划RFC154 风格显示RFC156 伊利诺斯州站点的状态: 响应RFC 116RFC179 连接的数字分配RFC185 NIC 分发手册RFC188 数据管理会议公告RFC198 站点证明-林肯实验室360/67RFC204 利用报路RFC218 改变IMP 状态报告设备RFC228 澄清RFC232 网络图形会议延缓RFC245 预定网络工作组会议RFC246 网络图形会议RFC256 IMPSYS 变更通知RFC276 NIC过程RFC285 网络图形RFC324 RJE 协议会议RFC335 新界面- IMP/360RFC348 放弃过程RFC404 文件迁移协议的注释RFC405 给TIP 用户的第二封信RFC456 UCSB 的数据重置服务RFC457 FTP 的服务器与服务器交互RFC496 IMP/TIP 内存更新时间表(修订版2)RFC516 丢失消息的检测RFC591 在NVT ASCII UCSB和在线系统之间的实验输入映象RFC621 “注意圣诞节的时候要把长袜挂在烟囱下面”RFC628 更深的数据语言的设计观念RFC634 最近的网络图RFC637 SU-DSL网络地址的更改RFC677 双重数据库的维护RFC692 对于IMP/HOST 协议的改动的注释(RFCS 687 AND 690) RFC697 FTP的CWD命令RFC698 Telnet扩展ASCII选项RFC763 角色邮箱RFC775 面向目录的FTP 命令RFC779 Telnet发送-位置选项RFC792 Internet 控制信息协议RFC797 位图文件格式RFC821 简单邮件传输协议RFC826 以太网地址转换协议或转换网络协议地址RFC827 Exterior 网关协议(EGP)RFC854 Telnet协议说明书RFC855 Telnet选项说明书RFC856 Telnet二进制传输RFC857 Telnet回声选项RFC858 Telnet抑制前进选项RFC859 Telnet状态选项RFC860 Telnet定时标记选项RFC861 Telnet扩展选项列表选项RFC862 回声协议RFC863 废除协议RFC864 字符产生协议RFC865 白天协议的引用RFC866 激活用户RFC867 白天协议RFC868 时间协议RFC872 局域网上的TCP协议RFC877 IP 数据包通过公共数据网络的传输标准RFC888 STUB Exterior Gateway ProtocolRFC890 外部网关协议执行表RFC894 IP 数据包通过以太网网络传输标准RFC895 IP 数据包通过试验性以太网网络的传输标准RFC896 在IPTCP internet网络中的拥塞控制RFC903 反向地址转换协议RFC911 BERKELEY UNIX 4.2下的EGP网关RFC917 因特网子网RFC918 邮局协议RFC925 多局域网地址解决RFC930 Telnet终端类型选项RFC932 子网地址分配方案RFC937 邮局协议( 版本2)RFC948 IP 数据包通过IEEE 802.3 网络传输的两种方法RFC949 FTP 未公开的独特命令RFC951 引导协议(BOOTP)RFC955 朝向一个处理过程应用的传输服务RFC962 TCP-4 的最初RFC968 “这是开动前的黑暗”RFC974 邮件路由与域名系统RFC975 自治联邦RFC976 UUCP 邮件互换格式标准RFC985 Internet 网关要求- 起草RFC988 主机扩展用于IP多点传送RFC1050 RPC远程步骤呼叫协议说明书RFC1055 在串行线路上传输IP数据报的非标准协议RFC1057 RPC远程步骤呼叫协议说明书版本2RFC1073 Telnet窗口大小选项RFC1075 远距离矢量多播选路协议RFC1088 IP 数据包传输通过NetBIOS网络的标准RFC1090 SMTP在X.25RFC1091 TelnetTELNET终端类型选项RFC1094 NFS网络文件系统协议说明书RFC1096 Telnet X 显示定位选项RFC1097 Telnet潜意识-信息选项RFC1112 主机扩展用于IP多点传送RFC1113 Internet电子邮件秘密增强第一部分- 信息加密和身份验证步骤RFC1131 OSPF规范RFC1132 802．2分组在IPX网络上传输的标准RFC1134 +PPP协议：关于在点到点链路上进行多协议包传送的建议RFC1142 OSI IS-IS 域内路由协议RFC1144 低速串行链路上的TCPIP头部压缩RFC1145 SNMPv2的管理模型RFC1155 基于TCPIP网络的管理结构和标记RFC1166 Internet数字RFC1180 TCPIP指南RFC1191 路径MTU探索RFC1215 为使用SNMP定义Trap的惯例RFC1239 试验管理系统库(MIB)到标准管理系统库(MIB)的重分配RFC1242 基准术语用于网络互连设备RFC1258 BSD 的远程登录RFC1287 未来的Internet 体系结构RFC1288 Finger用户信息协议RFC1298 基于IPX协议的SNMPRFC1321 MD5 信息-摘要算RFC1332 PPP Internet 协议控制协议(IPCP)RFC1333 PPP 链接质量监控RFC1355 网络中心数据库的保密和准确性问题RFC1365 一种IP地址扩展提议RFC1370 OSPF适用范围声明RFC1387 RIP（版本2）协议分析RFC1388 RIP协议版本2RFC1393 Traceroute使用IP选项RFC1397 在边界网关协议（Border Gateway Protocol）版本2RFC1408 Telnet环境选项RFC1413 鉴定协议RFC1414 身份识别管理系统库(MIB)RFC1418 SNMP优于OSIRFC1420 SNMP优于IPXRFC1426 SMTP服务扩展用于8bit-多用途网际邮件扩充协议(MIME)传输RFC1428 Internet邮件从Just-Send-8到8bit-SMTPMIME的转换RFC1433 直接ARPRFC1445 简单网络管理协议(SNMPv2)版本2的管理模式RFC1454 下一代IP提议的比较RFC1461 通过X.25多协议互连SNMP管理系统库(MIB)扩展RFC1469 通过令牌－环局域网的IP多点传送RFC1483 通过ATM适应层5的多协议封装RFC1558 LDAP研究过滤器的字符串表达RFC1571 Telnet环境选项互用性问题RFC1590 媒体类型注册过程RFC1591 域名系统的结构和授权RFC1597 私有Internet的地址分配RFC1605 SONET to Sonnet翻译RFC1606 用IP版本9的历史观RFC1611 DNS服务器MIB扩展RFC1612 DNS解析器MIB扩展RFC1618 ISDN上的PPP(点对点)协议RFC1628 UPS 管理信息基础RFC1633 Internet 体系结构中的综合服务概述RFC1635 怎样使用匿名FTPRFC1636 IAB工厂关于在Internet体系结构的安全报告-2月8-10号, 1994 RFC1643 以太网-类似界面类型的管理对象的定义RFC1658 字符流设备使用SMIv2管理对象的定义RFC1661 点对点协议(PPP)RFC1671 向IPng 过渡和其他考虑的白皮书RFC1690 Internet工程与计划组（IEPG）介绍RFC1691 康奈尔大学数字图书馆文档体系结构RFC1696 用SMIv2定义的调制解调器MIBRFC1713 DNS调试工具RFC1715 地址分配效率比率HRFC1723 路由信息协议（版本2）RFC1724 RIP 版本2 管理系统库(MIB) 扩展RFC1738 统一资源定位器(URL)RFC1752 推荐IP下一代协议RFC1769 简单网络时间协议(SNTP)RFC1771 边界网关协议版本4（BGP-4）RFC1776 地址是信息RFC1777 轻量级目录访问协议RFC1787 在多供应Internet上的软件路由RFC1796 不是所有RFCs是标准RFC1797 A级子网实验RFC1810 报告MD5性能RFC1818 最好最新的实践RFC1822 使用具备Photuris技术的指定IBM专利的权利的授予RFC1823 LDAP 应用程序界面RFC1827 IP 密码安全有效载荷(ESP)RFC1828 使用键控MD5进行IP鉴别RFC1860 IPv4变量长度子网表RFC1867 HTML中基于表单的文件上传RFC1869 SMTP服务扩展RFC1878 变量长度子网表格用于IPv4RFC1881 IPv6 地址分配管理RFC1883 Internet协议,版本6(IPv6)说明书RFC1886 DNS扩展支持IP版本6RFC1901 基于社区的SNMPv2介绍RFC1904 简单网络管理协议(SNMPv2)版本2的一致声明RFC1918 个人Internets的地址分配RFC1928 SOCKS V5的用户名/密码鉴定RFC1930 自治系统(AS)创建,选择,和注册的指导方针RFC1939 邮局办公协议-版本3RFC1942 HTML表格RFC1945 超文本传输协议--HTTP/1.0RFC1956 在MIL域中注册RFC1957 邮局协议(POP3)执行的一些观察RFC1962 PPP压缩控制协议(CCP)RFC1977 PPP BSD 压缩协议RFC1979 PPP压缩协议RFC1981 IP 版本6的路径MTU探索RFC1982 序列号算法RFC1988 有条件地授予权利给特殊的HP专利于连接Internet工程特遣队的Internet-标准网络管理框架中RFC1993 PPP G和alf FZA 压缩协议RFC1994 PPP挑战握手身份验证协议(CHAP)RFC1997 BGP 组属性RFC1998 BGP 社区属性在多本地路由中的应用RFC2002 IP移动性支持RFC2003 在IP内封装IPRFC2004 IP最小封装RFC2005 IP移动性的适用性陈述RFC2011 SNMPv2 管理信息基础用于Internet 协议使用SMIv2RFC2012 SNMPv2 管理信息基础用于传输控制协议使用SMIv2RFC2013 有关采用SMIv2用户数据报协议的SNMPv2管理信息数据库RFC2015 多用途网际邮件扩充协议(MIME)安全具有相当好的保密性(PGP)RFC2021 远程网络监控管理信息基础版本2使用SMIv2RFC2025 简单公共密钥GSS-API机制（SPKM）RFC2040 RC5, RC5-CBC, RC5-CBC-Pad,和RC5-CTS算法RFC2042 注册新BGP属性类型RFC2046 多用途Internet邮件扩展(多用途网际邮件扩充协议(MIME))第二部分:媒体类型RFC2053 AM (美国)域RFC2078 通用安全服务应用接口（GSS-API）V2RFC2079 X.500 属性类型和对象类别去掌握统一资源定位器(URIs)的定义RFC2085 具有重放预防的HMAC-MD5 IP 身份验证RFC2088 IMAP4非同步字符RFC2095 简单挑战/回应的IMAP/POP授权扩展RFC2096 IP面向表格管理系统库(MIB)RFC2101 IPv4 今天地址行为RFC2104 HMAC:键入-散列法用于信息身份验证RFC2105 CCisco 系统的标签交换体系结构纵览RFC2113 IP路由器警告选项RFC2118 微软点对点压缩(MPPC)协议RFC2119 关键字用于使用在RFCs指出要求水平RFC2128 拨号控制MIB（SMIv2）RFC2144 CAST-128 加密算法RFC2147 TCP和UDP通过IPv6 JumbogramsRFC2198 多余音频数据的RTP有效载荷RFC2208 资源预留协议(RSVP)——版本1 适用性声明关于配置的一些指导RFC2212 有保证的质量服务说明书RFC2213 综合服务管理信息基础使用SMI版本2RFC2217 TelnetCom端口控制选项RFC2221 IMAP4 登陆参考RFC2228 FTP 安全扩展RFC2234 语法说明书的扩充BNF:ABNFRFC2236 Internet组管理协议,版本2RFC2241 Novell目录服务的DHCP选项RFC2245 匿名SASL机制RFC2260 可升级支持用于多目录多供应者的连通RFC2279 UTF-8,ISO 10646的一种转换格式RFC2281 Cisco热备份路由协议（HSRP）RFC2283 BGP-4的多协议扩展RFC2284 PPP可扩展认证协议RFC2289 一种一次性密码系统RFC2296 HTTP 远程变量选择算法--RVSA/1.0RFC2313 PKCS#1：RSA加密版本1.5RFC2330 IP 执行规则的管理RFC2343 应用于捆绑的MPEG的RTP有效载荷的格式RFC2344 移动IP反向隧道RFC2349 TFTP 休息间隔和传输大小选项RFC2367 PF_KEY键管理API,版本2RFC2372 处理Internet协议（TIP）-要求和补充信息RFC2373 IPv6寻址体系结构RFC2374 IPv6 可集聚全球单播地址格式RFC2379 RSVP通过ATM执行的指导方针RFC2384 POP URL 方案RFC2393 IP有效载荷压缩协议(IPComp)RFC2394 IP有效载荷压缩使用DEFLATERFC2401 Internet 协议的安全体系结构RFC2403 在ESP和AH中使用HMAC-MD5-96RFC2404 在ESP和AH中使用HMAC-SHA-1-96RFC2406 IP 封装安全有效载荷(ESP)RFC2407 Internet IP 用于解释ISAKMP的安全域RFC2408 Internet 安全关联和键管理协议(ISAKMP)RFC2409 Internet密钥交换（IKE）RFC2410 NULL加密算法及其在IPsec协议中的应用RFC2411 IP安全文件指南RFC2412 OAKLEY 键决定协议RFC2413 Dublin核心元数据用于资源发掘RFC2435 针对JPEG压缩视频的RTP荷载格式RFC2449 POP3 扩展机制RFC2451 ESP CBC-模式密码算法RFC2459 Internet X.509 公钥基础设施:证书和CRL简介RFC2460 Internet协议,版本6(IPv6)说明书RFC2463 针对因特网协议第六版(Ipv6)的因特网控制报文协议(ICMPv6)规范RFC2466 IP 版本6 管理信息基础:ICMPv6组RFC2471 IPv6检测地址分配RFC2474 IPv4与IPv6包头中差分服务字段（DS Field）的定义RFC2475 分类业务的体系结构RFC2492 IPv6 通过ATM网络RFC2495 有关DS1,E1,DS2,E2接口类型的管理部件的定义RFC2508 低速串行链路下IP/UDP/RTP数据包头的压缩RFC2511 Internet X.509认证请求消息格式RFC2516 在以太网上传输PPP的方法（PPPoE）RFC2526 IPv6保留的子网任意传送地址RFC2541 DNS 安全操作考虑RFC2547 BGP/MPLS VPNsRFC2554 SMTP服务认证扩展RFC2560 x.509因特网公钥基础设施在线证书状态协议——OCSPRFC2570 标准互联网络管理框架第三版介绍RFC2577 FTP 安全考虑RFC2581 TCP拥塞控制RFC2582 TCP的快速恢复算法NewReno修正RFC2585 Internet X.509 公共键底部结构操作协议: FTP和HTTPRFC2597 确定的面向PHB组RFC2598 面向加速PHBRFC2618 RADIUS 身份验证客户端管理系统库(MIB)RFC2629 用XML 写I-Ds 和RFC文档RFC2633 S/多用途网际邮件扩充协议(MIME) 版本3 信息说明书RFC2644 更改直接广播在路由器上的缺省值RFC2669 DOCSIS 电缆设备管理系统库(MIB)电缆设备管理信息基础用于DOCSIS 适应性电缆调制解调器和电缆调制解调器中断系统RFC2670 音频频率(RF)界面管理信息基础用于MCNS/DOCSIS适应性RF界面RFC2685 虚拟专用网标志符RFC2702 基于MPLS的流量工程要求RFC2706 ECML v1:电子商务字段名RFC2713 LDAP（轻型目录存取协议）目录中JAVATM对象的表征模式RFC2714 LDAP（轻型目录存取协议）目录中的CORBA对象参考方案RFC2731 Dublin核心元数据在HTML上的编码RFC2732 文本IPv6地址在URL上的格式RFC2733 RTP有效载荷格式用于普通正向错误更正RFC2736 RTP有效载荷格式说明书作者的指导方针RFC2754 RPS IANA的发布RFC2756 超文本缓存协议(HTCP/0.0)RFC2764 IP VPN的框架体系RFC2773 使用KEA和SKIPJACK加密RFC2774 HTTP 扩展框架RFC2781 UTF-16,ISO 10646的一种编码RFC2784 通用路由封装（GRE）RFC2788 网络服务监视MIBRFC2793 用于文本交谈的RTP负载RFC2796 BGP路由映象RFC2809 通过RADIUS的L2TP强制通道的执行RFC2810 Internet 延迟交谈:体系结构RFC2811 Internet延迟交谈：通道管理RFC2813 Internet 延迟交谈:服务器协议RFC2817 在HTTP/1.1中升级到TLSRFC2818 TLS之上的HTTPRFC2824 呼叫过程语言框架和要求RFC2825 复杂网络:I18N的发布,域名,和其它Internet协议RFC2829 LDAP的身份验证方法RFC2830 轻量级目录访问协议(v3): 传输层安全扩展RFC2833 用于DTMF数字信号、电话音和电话信号的RTP负载格式RFC2854 text/html 媒体类型RFC2855 IEEE 1394的DHCPRFC2861 TCP 拥塞窗口检验RFC2862 用于实时指针的RTP负载格式RFC2866 RADIUS（远程用户拨号认证系统）记帐协议RFC2867 RADIUS 账目管理修改用于通道协议支持RFC2868 RADIUS 属性用于协议支持RFC2869 RADIUS 扩展RFC2871 一个IP电话路由框架RFC2873 在Ipv4优先域中的TCP过程RFC2874 支持IPv6地址集合和重编号的DNS 扩展RFC2882 网络访问服务要求: 扩展范围实践RFC2887 可靠的多点传送设计空间用于大的数据传送RFC2889 基准方法论用于局域网交换设备RFC2890 GRE中Key和SequenceNumber扩展RFC2893 IPv6 主机和软件路由器转换机制RFC2898 PKCS #5: 基于密码的密码系统说明书版本2.0. BRFC2906 AAA 授权要求RFC2914 拥塞控制原理RFC2917 核心MPLS IP VPN 体系结构RFC2918 BGP-4（边界网关协议）的路由刷新功能RFC2920 SMTP 针对命令流水线的服务扩展RFC2923 TCP的路径MTU发现问题RFC2932 IPv4 多点传送路由管理系统库(MIB)RFC2935 Internet开放贸易协议(IOTP)HTTP 补充RFC2939 新DHCP选项和信息类型的定义步骤和IANA指导方针RFC2945 SRP身份验证和键交换系统RFC2946 Telnet 数据加密选项RFC2947 Telnet加密：DES3 64位密码回馈RFC2948 Telnet加密：DES3 64位输出回馈RFC2949 Telnet加密:CAST-128 64比特输出回馈RFC2950 Telnet加密:CAST-128 64比特密码回馈RFC2951 使用KEA和SKIPJACK进行TELNET身份验证RFC2952 Telnet加密：DES 64位密码回馈RFC2953 Telnet加密:DES 64比特输出回馈RFC2957 The 应用/whoispp-请求目录-类型RFC2958 The 应用/whoispp-回答目录-类型RFC2959 实时传输协议管理信息库RFC2964 超文本传输协议(HTTP)状态管理的应用RFC2971 Internet信息访问协议(IMAP4)的标识符扩展RFC2976 SIP信息方法RFC2983 有区别的协议和通道RFC2984 CAST-128密码算法在CMS中的使用RFC2987 字符集注册和语言媒体特征标签RFC2988 计算TCP重传时间的定时器RFC2991 多路径分发在Unicast上和多点传送下一路程段选择RFC2992 等值多-路径算法的分析RFC2994 MISTY1加密算法的描述RFC3001 对象标识符的URN名称空间RFC3003 audio/mpeg 媒体类型RFC3005 IETF 讨论列表许可证RFC3007 安全的域名系统动态更新RFC3009 奇偶向前纠错MIME类型的注册RFC3012 移动IP的询问/应答扩展机制RFC3014 提示日志管理系统库(MIB)RFC3016 用于MPEG-4视听流的RTP负载格式RFC3018 统一内存空间协议说明书RFC3019 IP 版本6 管理信息基础用于多点传送听众探索协议RFC3021 在Ipv4点对点连接中使用31位前缀RFC3022 传统IP网络地址转换（传统NAT）RFC3026 在ENUM上联络到IETF/ISOCRFC3028 滤网:一种邮件过滤语言RFC3029 Internet X.509 公共键下部构造数据有效性和认证服务协议RFC3032 MPLS标记栈编码RFC3033 信息域和协议标识符在Q.2941普通标识符和Q.2957用户对用户发送信号中的分配用于Internet 协议RFC3034 标签转换在帧中继网络说明书中的使用RFC3035 MPLS使用LD和ATM VC交换RFC3037 LDP 的适用性RFC3038 VCID提示通过ATM链接用于LDPRFC3040 Internet网复制和缓存分类法RFC3042 使用有限传输增强TCP的丢失恢复能力RFC3043 Network Solutions的个人网络名(PIN): 一种个人和组织的统一资源名域RFC3044 在ISSN-URN命名空间中用ISSN作为URNRFC3046 DHCP 中继代理信息选项RFC3048 可靠的多点传输建立阻止一对多大数据传送RFC3051 IP有效载荷压缩使用ITU-T V.44打包方法RFC3055 PINT服务体系结构管理信息基础.RFC3058 IDEA加密算法在CMS上的使用RFC3059 服务定位协议的属性列表扩展RFC3061 对象标识符的一种URN姓名空间RFC3062 LDAP口令修改扩展操作RFC3066 语言鉴定标签RFC3067 TERENA'S事件对象描述和转换格式要求RFC3069 VLAN聚合实现IP地址有效分配RFC3070 基于帧中继的第二层隧道协议RFC3072 结构化的数据改变格式(SDXF)RFC3074 DHC加载平衡算法RFC3078 微软点对点加密(MPPE)协议RFC3081 将区块扩展交换协议（BEEP）核心映射到传输控制协议（TCP）RFC3082 服务定位协议（SLP）的预研报告RFC3083 基线私人界面管理信息基础(MIB)用于兼容Cable Modems和Cable Modem 终端系统的DOCSISRFC3085 新闻型标记语言（NewsML）资源的URN名字空间RFC3090 域名系统在区域状况下的安全扩展声明RFC3091 改进数字产生协议RFC3093 防火墙增进协议(FEP)。
x.509数字证书格式中包含的元素
x.509数字证书格式中包含的元素
x.509是一种广泛使用的公钥基础设施（PKI）标准，在数字证书中有广泛应用。
它包含以下一些重要的元素：
版本号（Version）
数字证书中包含一个版本号，用于表示证书所采用的x.509标准的版本。
序列号（Serial Number）
每个数字证书都有一个唯一的序列号，用于标识证书的唯一性。
颁发者（Issuer）
颁发者指的是发放数字证书的机构或个人，它包含颁发者的名称和一些其他相关信息。
有效期（Validity）
有效期表示数字证书的生效时间和失效时间。
主题（Subject）
主题指的是使用数字证书的实体，例如个人、组织或者网站，它包含主题的名称和其他相关信息。
公钥（Public Key）
数字证书中包含一个公钥，用于加密信息或验证数字签名。
数字签名（Digital Signature）
数字证书中包含有关证书的数字签名，用于验证证书的真实性和完整性。
扩展字段（Extensions）
扩展字段包含一些额外的元数据，用于存储一些特定的信息，例如证书的用途、策略等。
以上只是x.509数字证书中的一些重要元素，还有其他一些元素可以根据需要进行添加或修改。
电子证书技术服务热门协议书
电子证书技术服务热门协议书随着信息技术的不断发展，电子证书技术作为一种数字身份认证和信息安全保障的重要手段，已经在各个领域得到广泛应用。
为了确保电子证书技术的有效运行和互操作性，各个相关方需要制定一系列协议和标准，以保证电子证书的安全性和可信度。
本文将介绍几种热门的电子证书技术服务协议。
一、X.509协议X.509是一种公钥证书的标准格式，它定义了证书的结构和内容，并规定了证书的签发和验证过程。
X.509证书通常用于TLS/SSL协议中，用于实现网站的安全通信。
X.509证书包含了公钥、证书持有者的身份信息以及证书颁发机构的签名等重要信息，通过验证证书的签名可以确保证书的真实性和完整性。
二、OCSP协议OCSP（Online Certificate Status Protocol）是一种在线证书状态查询协议，用于检查证书的有效性和吊销状态。
OCSP协议通过与证书颁发机构的服务器通信，实时查询证书的状态信息，以便及时发现并阻止使用被吊销的证书。
OCSP协议可以提高证书的实时性和可信度，减少证书吊销的漏洞。
三、CMP协议CMP（Certificate Management Protocol）是一种用于证书管理的协议，它定义了证书的请求、颁发、更新和吊销等操作。
CMP协议可以实现证书颁发机构与证书持有者之间的安全通信，确保证书的合法性和及时性。
CMP协议使用公钥加密和数字签名等技术，保护证书的机密性和完整性。
四、SCEP协议SCEP（Simple Certificate Enrollment Protocol）是一种简化的证书申请和颁发协议，主要用于移动设备等资源受限环境下的证书管理。
SCEP协议通过与证书颁发机构的服务器通信，实现了移动设备的自动证书申请和更新，简化了证书管理的流程和操作。
SCEP协议可以提高证书的可用性和便利性，促进移动设备的安全通信。
五、EST协议EST（Enrollment over Secure Transport）是一种基于HTTP的证书申请和颁发协议，它使用TLS/SSL协议保护通信的安全性。
OCSP协议原理概述
OCSP协议原理概述OCSP（Online Certificate Status Protocol）是一种用于查询数字证书状态的网络协议。
该协议的设计目的是为了解决传统的证书吊销列表（CRL，Certificate Revocation List）检查方式的不足之处。
本文将对OCSP协议的原理进行概述。
一、OCSP协议的背景和意义在使用数字证书进行身份认证时，验证证书的有效性是非常重要的。
传统的方式是通过检查CRL来判断证书是否被吊销。
然而，CRL的问题在于更新不及时，需要定期下载最新的CRL，并且对大型CA来说，CRL的大小可能非常庞大，导致网络传输和处理的时间开销都很大。
相比之下，OCSP协议采用了实时查询的方式，可以更加高效和及时地获取证书的状态信息。
二、OCSP协议的基本流程1. 客户端向OCSP服务器发送证书查询请求。
2. 服务器收到请求后，验证请求的合法性，并返回证书的状态信息。
3. 客户端接收到服务器返回的信息，根据返回结果判断证书的有效性。
三、OCSP协议的具体实现步骤1. 客户端从数字证书中提取出证书的签发者（Issuer）信息。
2. 客户端构建OCSP请求消息，包括证书序列号等信息，并通过HTTP等协议发送给OCSP服务器。
3. 服务器接收到请求消息后，首先验证请求的签名，确保请求的合法性。
4. 服务器查询证书状态，如果证书被吊销，则返回相应的吊销信息；如果证书有效，则返回证书正常有效的信息。
5. 服务器将查询结果构建成OCSP响应消息，并通过HTTP等协议返回给客户端。
6. 客户端接收到响应消息后，验证响应的签名，确保响应的可信性。
7. 客户端解析OCSP响应消息，根据响应中的状态信息判断证书的有效性。
四、OCSP协议的优缺点OCSP协议相较于传统的CRL检查方式，具有以下优点：1. 实时性：OCSP协议可以即时查询证书的状态信息，相比于CRL的定期更新方式，能及时发现证书的吊销情况。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
组织：中国互动出版网（/）RFC文档中文翻译计划（/compters/emook/aboutemook.htm）E-mail：ouyang@译者：姚玥（yaoyue baboon@）译文发布时间：2001-6-8版权：本中文翻译文档版权归中国互动出版网所有。
可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。
Network Working Group M. Myers Request for Comments: 2560 VeriSign Category: Standards Track R. AnkneyCertCoA. MalpaniValiCertS. GalperinMy CFOC. AdamsEntrust Technologies June 1999x.509因特网公钥基础设施在线证书状态协议——OCSP (RFC2560 X.509 Internet Public Key Infrastructure Online Certificate StatusProtocol – OCSP)本备忘录的状态本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以得到改进。
请参考最新版的“Internet正式协议标准”(STD1)来获得本协议的标准化程度和状态。
本备忘录的发布不受任何限制。
版权声明Copyright (C) The Internet Society (1999). All Rights Reserved.1. 摘要本文档描述了无需证书撤消列表就可以决定一张数字证书当前状态的协议。
附加描述PKIX操作必要条件的机制在另外的文档中有详细说明。
第二章中有协议的概述。
功能必要条件在第三章中有详细描述。
第四章是具体协议。
第五章我们将讨论一些和协议有关的安全问题。
附录A定义了在HTTP之上的OCSP，附录B有ASN.1的语义元素，附录C详细描述了信息的mime类型。
本文档中的关键字"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"同RFC2119中的叙述一样。
2. 协议概述作为检查定期证书撤消列表的补充，有些场合下必须要获得一些有关证书撤消状态的即时信息。
（RFC2459章节3.3）例如涉及大量资金的交易或者股票买卖。
在线证书状态协议（OCSP）使得应用程序可以测定所需要检验证书的（撤消）状态。
OCSP。
一个OCSP客户端发布一个状态查询给一个OCSP响应器并且侦听当前证书直到响应器提供了一个响应。
这个协议描述了在应用程序检查证书状态和服务器提供状态之间所需要交换的数据。
2.1请求一个OCSP请求包含以下数据——协议版本——服务请求——目标证书标识——可能被OCSP响应器处理的可选扩展在接受一个请求之后，一个OCSP响应器检测是否：1．信息正确格式化2．响应器被配置提供请求服务而且3．请求包含了响应器需要的信息，如果任何一个先决条件没有满足，那么OCSP响应器将产生一个错误信息；否则的话，返回一个确定的回复。
2.2回复OCSP回复可以有几种类型。
一个OCSP回复由回复类型和实际回复字节组成。
有一种OCSP基本回复类型必须被所有的OCSP服务器和客户端支持。
本章的其余部分都仅适用于这个回复类型。
所有确定的回复都应被数字签名。
被用来签名回复信息的密钥必须是下列中的一个——颁发所涉及证书的CA——一个被信任的响应器，它的公钥被请求者信任——一个CA指派的响应器（被授权的响应器），它具有一张由CA直接颁发的用来表示此响应器可以为本CA发布OCSP回复的特别标记证书。
一个确定的回复信息由以下组成：——回复语法的版本——响应器名称——对每一张被提及证书的回复——可选扩展——签名算法对象标识符号——对回复信息散列后的签名对每一张被请求证书的回复包括——目标证书识别——证书状态值——回复有效期——可选扩展这个说明定义了以下在证书状态值中使用的一些确定回复识别：——良好——已撤消——未知“良好”状态表示一个对状态查询的积极回复。
至少，这个积极回复表示这张证书没有被撤消，但是不一定意味着这张证书曾经被颁发过或者产生这个回复在证书有效期内。
回复扩展可以被用来传输一些附加信息，响应器由此可以对这张证书的状态做出一些积极的声明，诸如（已颁发）保证，有效期等等。
“已撤消”状态表示证书已被撤消（无论是临时性的还是永久性的（待判断））“未知”状态表示响应器不知道请求的证书。
2.3例外情况万一出错，OCSP响应器会返回一个出错信息。
这些信息无须签名。
出错信息可以是以下一些类型——未正确格式化的请求（malformedRequest）——内部错误（internalError）——请稍后再试(trylater)——需要签名(sigRequired)——未授权(unauthorized)如果接受到一个没有遵循OCSP语法的请求，服务器产生“未正确格式化的请求”回复。
回复“内部错误”表示OCSP响应器处于一个不协调的内部状态。
请求需要再试，暗示尝试另一个响应器。
如果OCSP响应器正在工作，但是不能返回被请求证书的状态，那么“稍后再试”回复能被用来表示服务存在，但暂时不能响应。
当服务器需要客户端签名请求后才能产生一个回复时，回复“需要签名”将被返回。
当客户端未被授权允许向这台服务器发送请求时，回复“未授权”将被返回。
2.4此次更新(thisUpdate)，下次更新(nextUpdate)和产生时间(producedAt)的语义回复信息可以在其中包含三种时间——此次更新，下次更新和产生时间。
这些域的语义如下：——此次更新：此证书状态被表示为正确的时间——下次更新：在此时间之后，可获得此证书状态的新近信息——产生时间：OCSP签名这个回复的时间如果响应器未设置下次更新，那意味着新近的撤消信息在任何时候都可以被获得。
2.5回复预产生OCSP响应器可以预先产生用来描述在某个确定时间此证书状态的已签名回复。
通过在回复的此次更新域的反映，获得此状态的时间可以被正确认识。
下次新近信息则反映在下次更新域中，与此同时产生这个回复的时间则出现在回复的产生时间域中。
2.6 OCSP签名权威代表用来签名证书状态信息的密钥不一定需要和签名此证书的密钥相同。
通过发布一张包含有扩展密钥用途域唯一值的OCSP签名者证书证书发布者，可以明确的指派OCSP签名权威机构。
这张证书必须直接由认知的CA颁发给响应器。
2.7当CA密钥不安全如果一个OCSP响应器知道一个特定的CA私钥不安全，那么针对所有这个CA颁布的证书都可以返回一个撤消状态。
3功能必要条件3.1证书内容为了传达给OCSP客户端一个知道的信息获取点，CA们可以在权威机构信息获取扩展（可以被检测用来使用OCSP）提供这样的能力。
作为另外一种选择，也可以在OCSP客户端本地配置OCSP提供者获取地（信息）。
支持OCSP服务的CA，无论是自身实现还是通过授权响应器来提供，都必须提供包括统一资源识别形式的获取地信息和在一个获取描述序列中的对象识别符号形式的获取方法。
在主体证书的获取地域中的值定义了使用什么传输（例如HTTP）来获取OCSP响应器并且可以包含其他传输相关信息（例如URL）。
3.2 已签名回复的接受条件在接受一个已签名的回复为有效之前，OCSP客户端必须确认：1.在回复信息中所指的证书和相应请求中所指证书一致。
2.回复中的签名有效。
3.签名者的身份和相映应接受请求者匹配。
4.签名者正被授权签名回复。
5.表示状态被认为是正确的时间（此次更新）足够新。
6.如果有的话，下次更新的时间应该晚于现时时间。
4. 具体协议这个ASN.1语法引用了在RFC2459中定义的术语。
至于签名运算，被签名的数据使用ASN.1显示编码规则（DER）[x.690]。
除非指定了其他，否则默认使用ASN.1外在标记。
从别处引用的的术语有：扩展(Extensions)，证书序列号（CertificateSerialNumber）,主体公钥信息(SubjectPublicKeyInfo),名称(Name),算法识别(AlgorithmIdentifier),证书撤消列表原因（CRLReason）4.1请求这一节描述了请求信息的ASN.1规范。
实际的信息格式根据所使用的传输机制(HTTP,SMTP,LDAP等等)而不同。
4.1.1请求（信息）语法OCSPRequest ::= SEQUENCE {tbsRequest TBSRequest,optionalSignature [0] EXPLICIT Signature OPTIONAL }TBSRequest ::= SEQUENCE {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)是发布者显式名称的散列。