ICS35.030

CCSL80

中華人民共和國國家標準

GB/TXXXXX—XXXX

代替GB/T19713—2005

`

信息安全技術公鑰基礎設施

在線證書狀態協議

Informationsecuritytechnology—Publickeyinfrastructure—

Onlinecertificatestatusprotocol

（征求意見稿）

（本稿完成日期：2023-3-10）

在提交反饋意見時，請將您知道的相關專利連同支持性文件一并附上。

XXXX-XX-XX發布XXXX-XX-XX實施

GB/TXXXXX—XXXX

前言

本文件按照GB/T1.1—2020《標準化工作導則第1部分：標準化文件的結構和起草規則》的規定

起草。

本文件代替GB/T19713—2005《信息技術安全技術公鑰基礎設施在線證書狀態協議》，與GB/T

19713—2005相比，主要技術變化如下：

a)更改了“revoked（已撤銷）”狀態的使用范圍，允許對從未簽發過的證書使用此響應狀態

（見5.3）；

b)更改了“unauthorized（未授權）”錯誤響應的使用范圍（見5.4）；

c)增加了“revocationTime（撤銷時間）”語義的定義（見5.5）；

d)增加SM2、SM3算法的支持（見7.3）；

e)更改了相關描述闡明了響應者何時被視為授權響應者（見）；

f)更改了相關描述闡明了ResponderID字段對應于OCSP響應者簽名證書（見）；

g)增加了OCSP響應器按照GM/T0014—2012要求從CA獲得證書發布的狀態（見.2）；

h)增加了Nonce的ASN.1語法，而且對Nonce的長度范圍作出了規定（見7.4.2）；

i)增加了“優先的簽名算法”擴展，該擴展可包含在請求消息中，以指定客戶端希望響應器使

用的簽名算法，建議優先算法使用SM3withSM2（見7.4.8）；

j)增加了“擴展撤銷定義”擴展，該擴展表明響應器支持對第5.3節中定義的未簽發證書的

“revoked（已撤銷）”響應的擴展使用（見7.4.9）；

k)增加了基于HTTP的輕量級OCSP請求及響應格式（見附錄A.2）；

l)更改了使用ASN.1的2008語法的ASN.1模塊，增加支持使用SM2、SM3算法（見附錄B.2）；

m)增加了使用ASN.1的OCSP請求及響應格式示例，支持使用SM2、SM3算法的使用示例（見附錄

C）；

n)把正文的“安全考慮”改為附錄D（見附錄D）。

本文件由全國信息安全標準化技術委員會（SAC/TC260）提出并歸口。

請注意本文件的某些內容可能涉及專利。本文件的發布機構不承擔識別專利的責任。

本文件起草單位：普華誠信信息技術有限公司、上海信息安全基礎設施研究中心有限責任公司、

上海市數字證書認證中心有限公司、國家密碼管理局商用密碼檢測中心、北京數字認證股份有限公

司、鄭州信大捷安信息技術股份有限公司、格爾軟件股份有限公司、深圳市電子商務安全證書管理有

限公司、中電科網絡安全科技股份有限公司、數安時代科技股份有限公司、華為技術有限公司。

本文件主要起草人：梁佐泉、顧青、田文晉、王亞紅、馮四風、高五星、張子鳴、付麗麗、王志

威、高陽、陳犖祺、趙鷹俠、張紹博、張永強、劉為華、鄭強、鄭會濤、岳小陽、杜志強、曾光。

本文件所代替文件的歷次版本發布情況為：

——2005年首次發布為GB/T19713—2005；

——本次為第一次修訂。

II

GB/TXXXXX—XXXX

信息安全技術公鑰基礎設施

在線證書狀態協議

1范圍

本文件規定了面向公鑰基礎設施的在線證書狀態協議（OCSP），此協議是一種無需請求證書撤銷

列表（CRL）即可查詢數字證書狀態的協議，包括總則、功能要求、具體協議等。

本文件適用于公鑰基礎設施的建設以及應用在線證書狀態協議的依賴方等。

2規范性引用文件

下列文件中的內容通過文中的規范性引用而構成本文件必不可少的條款。其中，注日期的引用文

件，僅該日期對應的版本適用于本文件；不注日期的引用文件，其最新版本（包括所有的修改單）適

用于本文件。

GB/T16263.1—2006信息技術ASN.1編碼規則第1部分：基本編碼規則（BER）、正則編碼規則

（CER）和非典型編碼規則（DER）規范

GB/T20518—2018信息安全技術公鑰基礎設施數字證書格式

GB/T25069—2022信息安全技術術語

GB/T32905—2016信息安全技術SM3密碼雜湊算法

GB/T32915—2016信息安全技術二元序列隨機性檢測方法

GB/T33560—2017信息安全技術密碼應用標識規范

GB/T35276—2017信息安全技術SM2密碼算法使用規范

GB/T37092—2018信息安全技術密碼模塊安全要求

GM/T0014—2012數字證書認證系統密碼協議規范

3術語和定義

下列術語和定義適用于本文件。

3.1

數字證書digitalcertificate

由國家認可的、具有權威性、可信性和公正性的第三方證書認證機構（CA）進行數字簽名的一個

可信的數字化文件。

[來源：GB/T25069—2022，3.579]

3.2

證書序列號certificateserialnumber

在某一證書認證機構所簽發的證書中用于唯一標識數字證書的一個整數。

[來源：GB/T25069—2022，3.788]

3.3

請求者requester

申請在線證書狀態查詢服務的實體或設備。

注：根據上下文語境不同，在本文件部分章節中也使用“客戶端”，二者同義。

3.4

響應者responder

提供在線證書狀態查詢服務的實體或設備。

注：根據上下文語境不同，在本文件部分章節中也使用“響應器”，二者同義。

1

GB/TXXXXX—XXXX

3.5

在線證書狀態協議OnlineCertificateStatusProtocol

一種無需請求證書撤銷列表（CRL）即可查詢數字證書狀態的協議。

4縮略語

下列縮略語適用于本文件。

CA：證書認證機構（CertificationAuthority）

CRL：證書撤銷列表（CertificateRevocationList）

HTTP：超文本傳輸協議（HyperTextTransferProtocol）

LDAP：輕量級目錄訪問協議（LightweightDirectoryAccessProtocol）

OCSP：在線證書狀態協議（OnlineCertificateStatusProtocol）

OID：對象標識符（ObjectID）

PKI：公鑰基礎設施（PublicKeyInfrastructure）

SMTP：簡單郵件傳輸協議（SimpleMailTransferProtocol）

URI：統一資源描述符（UniformResourceIdentify）

URL：統一資源定位符（UniformResourceLocator）

5總則

5.1概述

OCSP作為查詢CRL的替代方法或補充方法，對需實時獲得數字證書撤銷狀態相關信息的，OCSP是必

不可少的。

OCSP能使應用程序獲得某個目標證書的撤銷狀態，OCSP可提供比檢查CRL更實時的撤銷狀態信息，

還可提供附加的狀態信息。OCSP客戶端向OCSP響應器發出一個狀態請求時，需暫停接受待驗證的證

書，直到響應器提供響應為止。

本文件規定了查驗證書狀態的應用程序和提供證書狀態查詢的響應器之間需要交換的數據。

5.2請求

本節指明了OCSP請求包括的數據內容及響應器接受請求時對請求數據格式的要求。

a)OCSP請求包含以下數據：

1)協議版本；

2)服務請求；

3)目標證書標識符；

4)OCSP響應器可處理的可選擴展，比如：OCSP客戶端的簽名、隨機數。

b)在接受到請求時，OCSP響應器應確定：

1)報文格式是否正確；

2)響應器是否配置了所要求的服務；

3)請求是否包含了響應器需要的信息。

如果上述任一條件不滿足，OCSP響應器將返回一個錯誤信息；否則，將返回一個明確的響

應。

5.3響應

OCSP響應由響應類型和響應實體兩部分組成，根據實際情況，響應可有不同類型。

a)所有確定的響應報文都應進行數字簽名，用于響應簽名的密鑰應符合下列條件之一：

1)簽發待驗證證書的CA密鑰；

2)CA指定的響應器（即授權的響應器，見）的密鑰，該響應器擁有一個CA直接簽發

的帶有擴展密鑰用法id-kp-OCSPSigning（見GB/T20518—2018.5）的證書，

該擴展項指明該響應器可為CA簽發OCSP響應；

2

GB/TXXXXX—XXXX

3)可信賴的響應器密鑰，即客戶端信任該響應器的密鑰。

b)響應消息由如下內容組成：

1)響應語法的版本；

2)響應者的標識符；

3)生成響應的時間；

4)對請求中每個證書的響應；

5)可選擇的擴展；

6)簽名算法的OID；

7)響應的數字簽名。

c)對請求中證書的響應由如下內容組成：

1)目標證書標識符；

2)證書狀態值；

3)響應有效間隔；

4)可選的擴展。

d)本文件對證書狀態值規定了如下響應標識符：

1)good（在用）：表示證書是有效的在用證書。此響應表示在其有效期內所請求證書序列

號的證書沒有被撤銷，但并不一定意味著該證書曾經被簽發過，或產生響應的時間是在

證書有效性期內。另外，響應擴展可提供關于證書狀態信息的附加聲明，例如已簽發、

有效期等；

2)revoked（已撤銷）：表示證書已被凍結（撤銷原因是凍結）或永久的撤銷。如果相關聯

的CA沒有簽發所請求證書的記錄，也可能返回此狀態；

3)unknown（未知）：表示響應器不能鑒別待驗證狀態的證書。通常是因為該響應器無法識

別驗證請求所包含的頒發者。

注：“已撤銷”狀態表示應拒絕所請求證書序列號的證書，而“未知”狀態表示響應器無法確定狀態，從而允許

客戶端決定是否要嘗試其他狀態信息源（例如CRL）。“已撤銷”響應適用于未簽發的證書，其中響應器的目

的是引導客戶端拒絕證書，而不是嘗試其他狀態信息源。例如，響應器可能不知道請求序列號是否已簽發的

證書，或者在響應器提供預先產生的響應時，不能為所有未簽發的證書序列號提供簽名響應。

e)當響應器向未簽發證書的狀態請求發送“已撤銷”響應時，響應器應在響應中包含擴展

撤銷定義（見7.4.9），從而表明OCSP響應器支持“已撤銷”狀態的擴展定義，以涵蓋未

簽發的證書。另外，未簽發證書與SingleResponse結構字段（見7.3.1）相關。“已撤

銷”響應應符合以下要求：

1)應明確指出撤銷原因是凍結；

2)應明確指出撤銷時間是1970年1月1日；

3)不能包括CRL引用擴展（見7.4.3）或任何CRL條目擴展（見7.4.6）。

5.4異常情況

當出現錯誤時，OCSP響應器應返回某個錯誤消息，且不需要對錯誤消息進行簽名，錯誤可分

為以下幾類：

a)malformedRequest（請求格式錯誤）：OCSP響應器接收到的請求不符合OCSP語法；

b)internalError（內部錯誤）：OCSP響應器處于非協調的工作狀態，應當向另一個響應器再次

進行查詢；

c)tryLater（稍后重試）：OCSP響應器正處于運行狀態，不能返回所請求證書的狀態，即表明

存在所需的服務，但是暫時不能響應；

d)sigRequired（應對請求簽名）：響應器要求客戶端對請求簽名；

e)unauthorized（請求未被授權）：該查詢是由未授權請求者向響應器提出的，或者響應器沒

有能力進行授權響應。

5.5時間語義

本文件中定義的響應可包含thisUpdate、nextUpdate、ProducedAt和revocationTime四個時間，

這些時間的語義分別是：

3

GB/TXXXXX—XXXX

a)thisUpdate：生效時間，響應器可以確認證書狀態的最新時間；

b)nextUpdate：下次更新時間，表示證書在此時間之前，狀態是正常的，并且在此時間可再次

獲得證書狀態更新的信息；

c)producedAt：簽發時間，OCSP響應器產生該響應的時間；

d)revocationTime：撤銷時間，證書被撤銷或者凍結的時間。

5.6預產生響應

為說明某一特定時間內某些證書的狀態，OCSP響應器可預先生成某些簽名響應。簽名響應中的

thisUpdate字段表示證書狀態被認為是合法的時間；nextUpdate字段表示證書狀態再次更新的時間；

ProduceAt字段表示產生響應的時間。

5.7OCSP簽名機構的委托

簽名證書狀態信息的密鑰不必與簽發證書的密鑰相同。證書頒發者通過簽發包含擴展密鑰用法為

id-kp-OCSPSigning的OCSP簽名者證書來指派OCSP簽名機構，此證書應由認可的CA直接簽發給響應器

（見）。

5.8CA密鑰泄漏

如果OCSP響應器知道某個CA的私鑰已被泄漏，則它可為該CA發布的所有證書返回撤銷狀態。

6功能要求

6.1證書內容要求

為向OCSP客戶端提供OCSP響應器的訪問位置，CA應該在證書擴展項中提供用于訪問OCSP響應

器的機構信息訪問（AIA），且證書擴展符合GB/T20518—2018的要求；或者，在OCSP客戶端本地

配置OCSP響應器的訪問地址。

對于提供OCSP服務的CA，不管是在本地實現還是由授權的OCSP響應器實現，都應在機構信息訪

問中包括OID值為id-ad-ocsp的訪問方法和訪問OCSP響應器的URI。

待驗證證書中訪問地址值定義了訪問OCSP響應器的信息傳輸方式（如HTTP），該值中包含其

他的信息（如一個URL）。

6.2簽名響應的接收要求

在將證書的簽名響應視為有效之前，OCSP客戶端應確認：

a)響應中所鑒別的證書與對應請求中所查驗的證書一致；

b)響應方的簽名是有效的；

c)響應方的簽名者身份應和請求的預定接收者保持一致；

d)簽名者已被授權為查驗證書提供簽名響應；

e)指明證書狀態的時間（thisUpdate）應為當前最近的時間；

f)如果設置了nextUpdate字段，此時間應該晚于客戶端當前時間。

7具體協議

7.1約定

本文件按照GB/T16263.1—2006的非典型編碼規則（DER）對OCSP請求、響應的信息項進行編

碼，組成特定的請求、響應數據結構。如果無特殊說明，默認使用ASN.1顯式標記。

OCSPASN1語法的signature、Extensions、CertificateSerialNumber、

SubjectPublicKeyInfo、Name、AlgorithmIdentifier和CRLReason等字段引用GB/T20518—2018

的語法。

本文件中的SM2算法標識符符合GB/T33560—2017的要求。signature域簽名的結果則按照

ASN.1編碼成BITSTRING類型并保存在簽名值域內。如果簽名算法為SM2，SM2密碼算法簽名數據

4

GB/TXXXXX—XXXX

格式符合GB/T35276—2017的要求。

7.2請求

7.2.1OCSP請求語法

本條規定了請求的ASN.1語法。根據所使用的傳輸機制（HTTP、SMTP、LDAP等），實際的消息格

式可能會發生相應的變化。

OCSP請求的ASN.1數據結構（完整的OCSPRequest結構見附錄B.1）為：

OCSPRequest::=SEQUENCE{

tbsRequestTBSRequest,

optionalSignature[0]EXPLICITSignatureOPTIONAL}

TBSRequest::=SEQUENCE{

version[0]EXPLICITVersionDEFAULTv1,

requestorName[1]EXPLICITGeneralNameOPTIONAL,

requestListSEQUENCEOFRequest,

requestExtensions[2]EXPLICITExtensionsOPTIONAL}

Signature::=SEQUENCE{

signatureAlgorithmAlgorithmIdentifier,

signatureBITSTRING,

certs[0]EXPLICITSEQUENCEOFCertificateOPTIONAL}

Version::=INTEGER{v1(0)}

Request::=SEQUENCE{

reqCertCertID,

singleRequestExtensions[0]EXPLICITExtensionsOPTIONAL}

CertID::=SEQUENCE{

hashAlgorithmAlgorithmIdentifier

{DIGEST-ALGORITHM,{...}},

issuerNameHashOCTETSTRING,--頒發者證書主題（DN）的雜湊值

issuerKeyHashOCTETSTRING,--頒發者證書公鑰的雜湊值

serialNumberCertificateSerialNumber--證書序列號

}

OCSPRequest結構中各域的含義是：

——tbsRequest域是包括查驗證書和請求者等信息，OCSP請求信息中的可選簽名值的原文信息；

——optionalSignature域包含簽名算法中的算法標識符和任何相關的算法參數、簽名中的簽名

值、響應器驗證簽名所需的客戶端證書（證書為可選項，通常不包括客戶端的根證書）。

TBSRequest結構中各域的含義是：

——version域表示協議版本，依據本文件的請求消息協議版本為v1(0)；

——requestorName域表示OCSP請求者的名稱，為可選項；

——requestList域包含一個或多個證書狀態請求；

——requestExtensions域是可選項，包括適用于reqCert域中的請求擴展項（見7.4）。

Request結構中各域的含義是：

——reqCert域包含待查驗證書的標識；

5

GB/TXXXXX—XXXX

——singleRequestExtensions域是可選項，包括適用于單個證書狀態請求的擴展項（見7.4

節）。

CertID結構中各域的含義是：

——hashalgalgorithm域是用來生成issuerNameHash值和issuerKeyHash值的雜湊算法；

——issuerNameHash域是頒發者證書主題（DN）的雜湊值，該值應根據所查驗證書中的頒發者名

字字段的DER編碼進行計算；

——issuerKeyHash域是頒發者證書公鑰的雜湊值，該值根據頒發者證書中主體公鑰字段的值（不

包括標簽和長度）進行計算；

——serialNumber域是正在請求其狀態的證書的序列號。

7.2.2OCSP請求語法的注解

請求語法的注解包括：

a)除了使用CA名稱的雜湊值之外，同時又使用CA公鑰值的雜湊來標識頒發者的主要原因是兩個

CA可能使用相同的名稱（雖然推薦名稱的唯一性，但并不強制），但兩個CA的公開密鑰是不

可能相同的，除非兩者都決定共享私鑰，或者一方的密鑰發生泄漏；

b)對任何特殊擴展域的支持是可選項，不應將這些擴展域設置為關鍵性的。7.4章節提出了許多

有用的擴展域。在其他標準中會定義其他的附加擴展域，應忽略那些不能識別的擴展域（除

非它們有關鍵性的標志并且不被理解）；

c)客戶端可選擇對OCSP請求進行簽名，簽名時以tbsRequest結構作為原文來進行簽名。如果請

求被簽名，客戶端應在requestorName域中指定其名稱；對于已簽名的請求，客戶端可在簽名

的證書字段中包含OCSP響應器驗證客戶端簽名所需要的證書。signature域簽名的結果則按照

ASN.1編碼成BITSTRING類型并保存在簽名值域內。如果簽名算法為SM2，SM2密碼算法簽名數

據格式應符合GB/T35276—2017的要求；

d)在輕量級OCSP時，客戶端可以簡化請求的結構（見附錄B.2），簡化的結構為：

1)OCSPRequest結構在OCSPRequest.RequestList域中只能包含一個請求；

2)OCSPRequest結構中不宜包含singleRequestExtensions域，如果包含該結構，建議僅包

含nonce擴展（id-pkix-ocsp-nonce）；

3)客戶端優先使用SM3作為CertID.issuerNameHash值和CertID.issuerKeyHash值的雜湊算

法；

4)客戶端不宜發送簽名的ocsp請求，因為響應器可能會忽略OCSP請求上的簽名。當請求不

簽名時，客戶端不應該在OCSPRequest結構中包含requestorName域，但OCSP響應器可支

持即包含requestorName域又未簽名OCSP請求；

5)如果客戶端發送簽名的OCSP請求，客戶端應在OCSPRequest.requestorName域中指定其名

稱。

7.3響應

7.3.1OCSP響應

本條規定了確定響應的ASN.1語法。根據所使用的傳輸機制（HTTP、SMTP、LDAP等），實際的消

息格式可能會發生相應的變化。

OCSP響應的ASN.1結構（完整的OCSPResponse結構見附錄B.1）為：

OCSPResponse::=SEQUENCE{

responseStatusOCSPResponseStatus,

responseBytes[0]EXPLICITResponseBytesOPTIONAL}

OCSPResponseStatus::=ENUMERATED{

successful(0),--響應被有效確認

malformedRequest(1),--請求格式錯誤

internalError(2),--內部錯誤

6

GB/TXXXXX—XXXX

tryLater(3),--稍候重試

sigRequired(4),--應對請求簽名

unauthorized(5)--請求未被授權

}

OCSP響應至少由responseStatus域構成，如果responseStatus域的值是某個錯誤條件之一，則不

設置responseBytes域。

ResponseBytes結構由一個對象標識符和回復數據組成，該回復數據編碼為OCTECTSTRING。

ResponseBytes::=SEQUENCE{

responseTypeOBJECTIDENTIFIER,

responseOCTETSTRING}

id-pkix-ocspOBJECTIDENTIFIER::={id-ad-ocsp}

id-pkix-ocsp-basicOBJECTIDENTIFIER::={id-pkix-ocsp1}

OCSP響應器應能產生id-pkix-ocsp-basic類型的響應，相應地，OCSP客戶端也應該能接收并

處理此類響應。

Response字段的值應為BasicOCSPResponse結構的DER編碼。

BasicOCSPResponse::=SEQUENCE{

tbsResponseDataResponseData,

signatureAlgorithmAlgorithmIdentifier,

signatureBITSTRING,

certs[0]EXPLICITSEQUENCEOFCertificateOPTIONAL}

signature域包含了對ResponseData結構進行數字簽名的結果。采用ASN.1DER編碼的

ResponseData作為數字簽名的輸入，而簽名的結果則按照ASN.1編碼成BITSTRING類型并保存。如果

簽名算法為SM2，SM2密碼算法簽名數據格式符合GB/T35276—2017的要求。響應器可以在

BasicOCSPResponse結構的certs域中設置響應器證書，方便OCSP客戶端驗證響應器簽名，如果不

包含證書，則不包括證書域。

ResponseData::=SEQUENCE{

version[0]EXPLICITVersionDEFAULTv1,

responderIDResponderID,

producedAtGeneralizedTime,

responsesSEQUENCEOFSingleResponse,

responseExtensions[1]EXPLICITExtensionsOPTIONAL}

ResponderID::=CHOICE{

byName[1]Name,

byKey[2]KeyHash}

KeyHash::=OCTETSTRING--響應器公開密鑰的雜湊值（不包括標簽和長度），雜湊算法采

用OCSPRequest中CertID的hashAlgorithm算法。

SingleResponse::=SEQUENCE{

certIDCertID,

certStatusCertStatus,

thisUpdateGeneralizedTime,

nextUpdate[0]EXPLICITGeneralizedTimeOPTIONAL,

singleExtensions[1]EXPLICITExtensionsOPTIONAL}

7

GB/TXXXXX—XXXX

CertStatus::=CHOICE{

good[0]IMPLICITNULL,

revoked[1]IMPLICITRevokedInfo,

unknown[2]IMPLICITUnknownInfo}

RevokedInfo::=SEQUENCE{

revocationTimeGeneralizedTime,

revocationReason[0]EXPLICITCRLReasonOPTIONAL}

Unknownlnfo::=NULL

7.3.2OCSP響應的注解

時間

響應結構可包含thisUpdate、nextUpdate、ProducedAt和revocationTime四個時間字段域，這四

個字段的定義見5.5。GeneralizedTime字段的格式符合GB/T20518—2018的第.4節要求。

thisUpdate和nextUpdate兩個字段定義了有效時間間隔，該時間間隔和CRL中的

{thisUpdate，nextUpdate}間隔相對應。響應中若NextUpdate值比本地系統時間早，則響應無

效；響應中ThisUpdate值比本地系統時間晚，則該響應也無效。

如果未設置nextUpdate字段，則響應器認為比較新的響應始終可用。

在輕量級OCSP環境下，客戶端不應在OCSPRequest結構中包含requestExtensions字段，為了確

保OCSP響應是最新的，客戶端應檢查nextUpdate字段是否存在，并且應確保當前時間（以GMT時間

表示）介于thisUpdate和nextUpdate時間之間。如果nextUpdate字段不存在，則客戶端應拒絕響

應。客戶端可允許在nextUpdate之后配置一個小的容忍期來接受響應，以處理相對于響應器和高速緩

存的微小時鐘差異，此容忍期應根據調用應用程序環境的時間同步技術的準確性和精度來選擇。

授權的響應器

.1授權響應器的證書要求

對證書狀態信息簽名的密鑰不必與簽發證書的密鑰相同，但應確保對狀態信息簽名的實體是

經過授權的，因此，證書的頒發者應執行以下操作之一：

a)證書的頒發者直接對OCSP響應簽名；

b)授權另一個實體對OCSP響應簽名。

授權響應器的證書應由請求中標識的CA直接簽發，且簽發的證書中應包含id-kp-OCSPSigning

擴密鑰，id-kp-OCSPSigning的定義為：

id-kp-OCSPSigningOBJECTIDENTIFIER::={id-kp9}

CA簽發OCSP響應器證書的密鑰，應與待驗證證書的頒發者證書密鑰相同。依賴于OCSP響應的

系統應確認OCSP響應器證書的頒發者與待驗證證書的頒發者一致，應驗證其頒發者密鑰相同。

.2客戶端對授權響應器證書的檢查

客戶端通過在本地配置一個或多個OCSP簽名權威實體以及信任這些權威實體的CA，可檢測并使

用id-kp-OCSPSigning值（見.1），實現對授權響應器證書的驗證。如果授權響應器證書不

能滿足以下任一標準，響應應被拒絕：

a)本地配置的OCSP響應器證書與待驗證證書的頒發者相匹配；

b)簽發待驗證證書的CA證書；

c)在extendedKeyUsage擴展中含有id-ad-ocspSigning值，并且由簽發待驗證證書的CA簽

發。

其他的接受或拒絕條件可應用于響應自身，或應用于驗證簽名響應的證書。

8

GB/TXXXXX—XXXX

.3授權響應器的撤銷檢查

一個授權權威OCSP響應器可為一個或多個CA提供狀態信息，因此，OCSP客戶端需要檢查授權權威

響應器的證書是否已被撤銷。以下三種方法CA可任選其一進行檢查：

a)CA可指定OCSP客戶端在響應器證書的整個生存期內信任該響應器。CA通過在響應器證書中包

含id-pkix-ocsp-nocheck擴展來完成該指定，該擴展屬于非關鍵性的擴展，擴展值可為空。

然而，對于證書的有效期，上述響應器密鑰的泄密同簽發CRL的CA密鑰的泄密所帶來的后果一

樣嚴重，因此，CA可選擇簽發一種有效期很短并且經常更新的證書，也就是短生命周期的證

書，此項定義為：

id-pkix-ocspOBJECTIDENTIFIER::={id-ad-ocsp}

id-pkix-ocsp-nocheckOBJECTIDENTIFIER::={id-pkix-ocsp5}

b)CA可指定檢查響應器證書是否被撤銷的方法。如果指定使用CRL檢查方式，則需使用CRL分發

點；如果指定其他檢查方式，則需使用授權信息訪問，有關上述兩種機制的說明詳見GB/T

20518-2018。在輕量級OCSP環境下，OCSP響應程序的證書中宜包含id-pkix-ocsp-nocheck擴

展，以向客戶端表明不需要檢查證書狀態。另外，在OCSP響應器證書中不宜包含授權信息訪

問和CRL分發點擴展。因此，響應器證書應該相對較短，并定期更新；

c)CA可選擇不指定檢查響應器證書撤銷狀態的方法，在這種情況下，可根據OCSP客戶端的本地

安全策略來決定是否對證書進行撤銷檢查。

.4證書狀態發布

OCSP響應器按照GM/T0014—2012的第5.5.1要求從CA獲得證書發布的狀態。

基礎響應

基礎響應的注解有以下內容。

a)基本的響應類型包含：

1)響應語法的版本，對于此版本的基本響應語法，響應語法應為v1(0)；

2)響應者名稱或響應者公鑰的雜湊值作為ResponderID字段值；

3)響應生成的時間；

4)對請求中的每個證書的響應；

5)可選的擴展；

6)由響應的雜湊值計算得到簽名值；

7)簽名算法OID。

b)ResponderID字段信息的用途是允許客戶端查找簽署簽名OCSP響應的證書。因此，該信息應與

簽署響應的證書相對應。

c)響應器可在BasicOCSPResponse結構的證書字段中包括有助于OCSP客戶端驗證響應器簽名的證

書。

d)請求中每個證書的響應包括：

1)提供撤銷狀態信息的證書的標識（即目標證書）；

2)證書的撤銷狀態（在用、已撤銷或未知）；如果證書已撤銷，則應說明撤銷證書的時

間，也可說明撤銷證書的原因；

3)響應的有效間隔；

4)可選擴展。

注：響應應為請求中的每個證書包含一個SingleResponse結構。

e)對于輕量級OCSP環境下的響應，關于OCSPResponse結構應注意以下幾點：

1)對于輕量級OCSP響應，ResponseData.responses結構中只能有一個SingleResponse字

段，而且響應中不應包括任何其他的SingleResponse信息；但是，在有必要提高響應預

生成性能或緩存效率的情況下，預先生成狀態響應的OCSP響應器可能會包括附加的

SingleResponse信息；

2)響應中不包含responseExtensions結構，客戶端應忽略響應中無法識別的非關鍵響應擴

展；

9

GB/TXXXXX—XXXX

3)若OCSP請求中包含響應器無法支持的選項時，響應器盡可能返回最完整的響應，例如，

響應器只支持預先生成的響應，并且無法響應包含nonce的OCSP請求，則它應該返回不包

含nonce的響應；

4)即使響應不包含nonce時，客戶端應忽略響應nonce，并且應根據準確的時間確定OCSP響

應是最新；

5)OCSP請求中包含響應器無法支持的選項（例如nonce）時，響應器可將請求轉發給可以提

供響應的響應器；

6)響應器可包括singleResponse.singleExtensions擴展結構。

7.4擴展

7.4.1概述

本章節定義了請求和響應的擴展語法，這些擴展符合X.509V3版本證書的擴展項語法，證書

擴展語法符合GB/T20518—2018的要求。對客戶端和響應器而言，所有擴展均為可選項。對于每

個擴展，本節對擴展語法以及需OCSP響應器或客戶端執行的操作要求進行了定義。

7.4.2Nonce（一次性隨機數）

Nonce是OCSPRequest結構或OCSPResponse結構中的一個字段，在使用時以加密的方式綁定請求

和響應，以防止重放攻擊。在請求中，Nonce字段作為請求結構中的一個requestExtension包含在

請求中，而在響應中則作為響應結構中的一個responseExtension包含在響應中。在請求和響應

中，nonce字段將由對象標識符id-pkix-ocsp-nonce標識，extnValue為Nonce的值。如果存在

nonce擴展，則nonce字段的長度至少為1個字節，最多可為32個字節。

響應器應拒絕任何在nonce字段擴展中有長度為0個字節或大于32字節nonce，在拒絕的響應

中，OCSPResponseStatus返回malformedRequest的結果（見7.3.1）。

nonce的值應是由符合GB/T37092—2018要求的密碼模塊生成，隨機數質量符合GB/T32915—

2016的要求。定義最小的nonce長度為1字節，需要兼容GB/T19713—2005的客戶端，支持本文檔

的較新的OCSP客戶端應在nonce擴展中使用長度為32個字節nonce。OCSP響應器宜接受至少16個字

節長度的nonce值，對于nonce長度小于16個字節的請求，可選擇忽略nonce擴展。此項定義如下：

id-pkix-ocspOBJECTIDENTIFIER::={id-ad-ocsp}

id-pkix-ocsp-nonceOBJECTIDENTIFIER::={id-pkix-ocsp2}

Nonce::=OCTETSTRING(SIZE(1..32))

7.4.3CRL引用

對于OCSP響應器來說，可在CRL上指出一個已撤銷的或已凍結的證書，該方式在OCSP中作為存儲

庫和審計機制使用時非常有用。CRL可能由一個URL（CRL可從這個URL處獲得），一個序列號（CRL

序列號）或一個時間點（創建相應的CRL的時間點）指定，這些擴展被確定為singleExtensions，

該擴展的標識符為id-pkix-ocsp-crl，值為CrlID。此項定義如下：

id-pkix-ocsp-crlOBJECTIDENTIFIER::={id-pkix-ocsp3}

CrlID::=SEQUENCE{

crlUrl[0]EXPLICITIA5StringOPTIONAL,

crlNum[1]EXPLICITINTEGEROPTIONAL,

crlTime[2]EXPLICITGeneralizedTimeOPTIONAL}

可選項crlUrl指定適用于有效CRL的URL，類型為IA5String；可選項crlNum指定相關CRL的CRL

序列號擴展的值，類型為INTEGER；可選項crlTime指定發布相應CRL的時間點，類型為

GeneralizedTime。

10

GB/TXXXXX—XXXX

7.4.4可接受的響應類型

OCSP客戶端可能希望指定它能處理的各種響應類型，為此，OCSP客戶端應該使用具有對象標

識符id-pkix-ocsp-response的擴展，其值為AcceptableResponses。該擴展作為請求中的一個

requestExtensions域，包含在AcceptableResponses域中的OID是該客戶端能夠接受的各種響應類

型（例如：id-pkix-ocsp-basic）的OID。該項定義如下：

id-pkix-ocsp-responseOBJECTIDENTIFIER::={id-pkix-ocsp4}

AcceptableResponses::=SEQUENCEOFOBJECTIDENTIFIER

如7.3.1所述，OCSP響應器應能夠返回id-pkix-ocsp-basic類型的響應，相應的，OCSP的客戶

端也能夠接收和處理id-pkix-ocsp-basic類型的響應。

7.4.5存檔截止

響應的producedAt時間與間隔保持值之間的差值被定義為證書的“存檔截止”時間，在證書過期

后，OCSP響應器可選擇在“存檔截止”時間內仍保留相應的撤銷信息。

OCSP客戶端可使用OCSP存檔截止時間，來提供數字簽名是否有效的證明，即驗證有效簽名的

證書在生成簽名時數字證書是否已過期的證明。

提供歷史參考支持的OCSP響應器應該在響應中包括存檔截止擴展，并把存檔截止時間作為

OCSP的singleExtensions擴展，存檔截止時間由id-pkix-ocsp-archive-cutoff和

GeneralizedTime語法來識別。該項定義如下：

id-pkix-ocsp-archive-cutoffOBJECTIDENTIFIER::={id-pkix-ocsp6}

ArchiveCutoff::=GeneralizedTime

舉例說明，如果響應器采用7年保留策略，且produceAt值為t1，那么響應中ArchiveCutoff值為

（t1-7年）。

7.4.6CRL條目擴展

所有指定為CRL條目擴展符合GB/T20518—2018中的要求。

7.4.7服務定位器

OCSP響應器可以以路由模式運作，即響應器接收到一個請求，并將請求轉發至能識別待驗證

證書的OCSP響應器上。本章節為上述模式定義了serviceLocator請求擴展，該擴展作為一個

singleRequestExtensions包括在請求中。該項定義如下：

id-pkix-ocsp-service-locatorOBJECTIDENTIFIER::={id-pkix-ocsp7}

ServiceLocator::=SEQUENCE{

issuerName,

locatorAuthorityInfoAccessSyntaxOPTIONAL}

上述字段的值可從證書的相應字段中獲得。

7.4.8優先使用的簽名算法

概述

OCSP響應器應支持國家密碼管理主管部門認可的密碼算法的簽名響應，但客戶端沒有選擇算法

的相關機制，因此存在客戶端不支持響應器使用非強制算法簽名響應的風險。

雖然OCSP響應器可提供算法選擇的規則，例如，使用CA簽署CRL和證書的簽名算法，但是這種規則

在下列情況下可能無效：

——簽發CRL和證書的算法可能與OCSP響應器簽發響應所使用的算法不一致；

——對未知證書的請求不能為響應器提供算法選擇的依據。

此外，出于以下兩個原因，OCSP響應器不宜使用CA簽發證書和CRL所用的簽名算法：

——在計算量上，響應器用于簽發證書狀態響應的算法比簽發證書的算法要求低；

11

GB/TXXXXX—XXXX

——通過使用兩個獨立的簽名算法可防止由于其中一個簽名算法泄露而導致密鑰泄露的可能性。

因此，在OCSP請求中，可允許客戶端指定優先使用的簽名算法擴展，反之，如果不支持指定優先

使用簽名算法的擴展，客戶端需選擇最大限度提高成功操作概率的簽名算法。

擴展語法

客戶端可在OCSP請求的requestExtensions擴展字段中增加優先使用簽名算法，該擴展項定義如

下：

id-pkix-ocsp-pref-sig-algsOBJECTIDENTIFIER::={id-pkix-ocsp8}

PreferredSignatureAlgorithms::=SEQUENCEOF

PreferredSignatureAlgorithm

PreferredSignatureAlgorithm::=SEQUENCE{

sigIdentifierAlgorithmIdentifier,

pubKeyAlgIdentifierAlgorithmIdentifierOPTIONAL}

sigIdentifier域指定客戶端優先使用的簽名算法，例如Algorithm=SM3withSM2，簽名算法的參數

依賴于所選的簽名算法，大多數簽名算法的參數均為缺省。

pubKeyAlgIdentifier域指定客戶端用于驗證OCSP響應的公鑰密碼算法的標識符。

pubKeyAlgIdentifier是可選的，它提供了一種方法來指定公鑰密碼算法必要的參數，以區分公鑰密碼

算法的不同用法。如果公鑰密碼算法為SM2，無參數。

客戶端應支持所有指定的優先使用簽名算法，并且客戶端應按照優先順序指定算法，從最優先到

最不優先。

本文檔的第節介紹了響應器選擇簽名算法的方法實現對OCSP響應進行簽名。

響應器簽名算法選擇

.1動態響應

所選算法在滿足OCSP響應器所有安全要求的前提下，響應器可按照以下優先順序選擇支持的簽名

算法，從而最大限度地確保互操作性，下列第一個選擇機制具有最高的優先級：

a)選擇在客戶端請求中指定為優先使用的簽名算法；

b)選擇證書頒發者簽發證書撤銷列表（CRL）所使用的簽名算法，證書頒發者為請求中查驗證書

的證書頒發者；

c)選擇用于簽發OCSP請求的簽名算法；

d)選擇已發布為使用帶外機制的簽名服務的默認簽名算法；

e)選擇為使用的OCSP版本指定強制或推薦的簽名算法。

響應器應始終應用編號最低的選擇機制，從而選擇符合響應器的加密算法強度標準的已知和支持

的算法。

.2靜態響應

為了提高效率，OCSP響應器在請求之前可生成靜態響應。在靜態響應生成期間，響應器不能使用

客戶端請求數據，但可使用歷史客戶請求作為輸入的一部分，來決定使用何種算法來簽署預先生成的

響應；在選擇返回預先生成的響應期間，響應器仍應使用客戶端請求數據。

7.4.9擴展撤銷定義

此擴展表示響應器支持“revoked”狀態的擴展定義，也適應第5.3章節中描述的未簽發的證書，

其主要目的之一是允許審計確定響應器的操作類型，使客戶端不用解析此擴展來確定響應中證書的狀

態。

當OCSP響應支持未簽發證書的“revoked”狀態時，則該擴展應要包含在OCSP響應中；另外，此擴

展也可能出現在其他響應中，用來表明響應器實現了擴展的撤銷定義。如果響應中包含此擴展，則該

12

GB/TXXXXX—XXXX

擴展應包含在responseExtensions字段中，且不能出現在singleExtensions字段中。

該擴展由對象標識符id-pkix-ocsp-tended-revoke標識。該項定義如下：

id-pkix-ocsp-tended-revokeOBJECTIDENTIFIER::={id-pkix-ocsp9}

該擴展的值應為NULL，且不應標記為關鍵擴展。

13

GB/TXXXXX—XXXX

附錄A

（規范性）

基于HTTP的OCSP請求和響應

A.1常規OCSP請求與響應的構造

A.1.1請求

基于HTTP的OCSP請求可以使用GET或POST方法來提交。在啟用HTTP緩存時，可以通過GET方法提交

較小請求（編碼后小于或等于255字節），對于不需要HTTP緩存或大于255個字節的請求，則應通過

POST方法提交。

使用GET方法的OCSP請求構造如下：

GET{url}/{DER編碼的OCSPRequest二進制值進行Base64編碼后再進行url-encoding編碼}

其中{url}可以從正在查詢狀態的證書的機構信息訪問擴展的值或者OCSP客戶端的本地配置獲得。

使用POST方法的OCSP請求構造如下：

HTTP請求頭中Content-Type屬性的值為“application/ocsp-request”，而消息正文是

OCSPRequest的DER編碼的二進制值。

A.1.2響應

基于HTTP的OCSP響應構造如下：

HTTP響應頭中Content-Type屬性的值為“application/ocsp-response”，Content-Length屬

性指定響應的長度，而消息正文是OCSPResponse的DER編碼的二進制值。其他的不能被客戶端識別的

HTTP頭可能存在于響應中，可以被忽略。

A.2輕量級OCSP請求與響應的構造

A.2.1概述

高價值的電子交易或高敏感度信息和操作需要OCSP響應器為每個證書提供及時和安全的狀態

查詢服務，OCSP通常部署在帶寬和處理能力充足不受限制的環境下，但隨著PKI技術使用的不斷發

展，OCSP的應用的場景也不斷增加，例如在大規模的PKI環境中，從效率和成本角度出發，常規

OCSP的應用會受到限制。

為了適應在非常大規模（高容量）PKI環境或需要輕量級解決方案以最大限度地減少帶寬和客

戶端/響應器處理能力的PKI環境下的應用，輕量級OCSP在常規OCSP的基礎上，規范了OCSP客戶端

和響應器允許采用的配置和操作，允許的操作如下：

a)預生成OCSP響應；

b)減小OCSP消息大小以降低帶寬使用；

c)響應消息緩存在客戶端和響應器。

A.2.2請求

輕量級OCSP要求響應器應支持基于HTTP的請求和響應。當發送總共小于或等于255字節（編碼

后）的請求時，客戶端應使用GET方法（以啟用OCSP響應緩存）；當發送大于255字節的OCSP請求

時，則使用POST方法提交。

在構造GET消息時，OCSP客戶端應對OCSPRequest結構進行Base64編碼，并將其附加到機構信

息訪問擴展中id-ad-ocsp指定的URI。客戶端不得在Base64編碼的字符串中包含CR或LF字符，而且

應對Base64編碼的OCSPRequest結構進行url-encoding。例如：

/MEowsDVGMEYavkyaKBgggnkiG9v0TsVYAGG7spbGTKpl2dAdeJaV267ov

kYakinESVKD0mJeBarSzhv%2FVVIKLZhs%2Fg9xF8ooSizol80Mbpg%ZD%ZD

14

GB/TXXXXX—XXXX

A.2.3響應

為了支持可緩存的響應（即包含nextUpdate值的響應），響應中需包含OCSPResponse的DER編

碼的二進制值，響應前應帶有以下HTTP報頭：