Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 5940 IECA
Category: Standards Track R. Housley
ISSN: 2070-1721 Vigil Security
August 2010
Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 5940 IECA
Category: Standards Track R. Housley
ISSN: 2070-1721 Vigil Security
August 2010
Additional Cryptographic Message Syntax (CMS) Revocation Information Choices
其他加密消息语法（CMS）撤销信息选项
Abstract
摘要
The Cryptographic Message Syntax (CMS) allows revocation information to be conveyed as part of the SignedData, EnvelopedData, AuthenticatedData, and AuthEnvelopedData content types. The preferred format for revocation information is the Certificate Revocation List (CRL), but an extension mechanism supports other revocation information formats. This document defines two additional revocation information formats for Online Certificate Status Protocol (OCSP) responses and Server-Based Certificate Validation Protocol (SCVP) requests and responses.
加密消息语法（CMS）允许撤销信息作为SignedData、EnvelopedData、AuthenticatedData和AuthEnvelopedData内容类型的一部分进行传输。吊销信息的首选格式是证书吊销列表（CRL），但扩展机制支持其他吊销信息格式。本文档为联机证书状态协议（OCSP）响应和基于服务器的证书验证协议（SCVP）请求和响应定义了两种附加的吊销信息格式。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5940.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5940.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
The RevocationInfoChoices type defined in [CMS] provides a set of revocation status information alternatives, which allows revocation information to be conveyed as part of the SignedData, EnvelopedData, AuthenticatedData, and AuthEnvelopedData content types. The intent is to provide information sufficient to determine whether the certificates and attribute certificates carried elsewhere in the CMS-protected content have been revoked. There may be more revocation status information than necessary or there may be less revocation status information than necessary.
[CMS]中定义的RevocationFochoices类型提供了一组撤销状态信息备选方案，允许将撤销信息作为SignedData、EnvelopedData、AuthenticatedData和AuthEnvelopedData内容类型的一部分进行传输。其目的是提供足够的信息，以确定CMS受保护内容中其他地方携带的证书和属性证书是否已被撤销。撤销状态信息可能比需要的多，或者撤销状态信息可能比需要的少。
X.509 Certificate Revocation Lists (CRLs) [PROFILE] are the primary source of revocation status information, but any other revocation information format can be supported. This document specifies two other formats: Online Certificate Status Protocol (OCSP) responses [OCSP] and Server-Based Certificate Validation Protocol (SCVP) requests and responses [SCVP].
X.509证书撤销列表（CRL）[配置文件]是撤销状态信息的主要来源，但可以支持任何其他撤销信息格式。本文档指定了另外两种格式：联机证书状态协议（OCSP）响应[OCSP]和基于服务器的证书验证协议（SCVP）请求和响应[SCVP]。
Section 2 discusses the RevocationInformation structure. Section 3 defines a mechanism to carry OCSP responses. Section 4 defines a mechanism to carry SCVP requests and responses. Appendix A provides the normative ASN.1 syntax for the two mechanisms.
第2节讨论了撤销信息结构。第3节定义了承载OCSP响应的机制。第4节定义了承载SCVP请求和响应的机制。附录A提供了这两种机制的标准ASN.1语法。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [WORDS].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[文字]中所述进行解释。
For convenience, the ASN.1 definition of the RevocationInfoChoices type from [CMS] is repeated here:
为方便起见，ASN.1对[CMS]中撤销焦点选择类型的定义在此重复：
RevocationInfoChoices ::= SET OF RevocationInfoChoice
RevocationInfoChoices ::= SET OF RevocationInfoChoice
RevocationInfoChoice ::= CHOICE {
crl CertificateList,
other [1] IMPLICIT OtherRevocationInfoFormat }
RevocationInfoChoice ::= CHOICE {
crl CertificateList,
other [1] IMPLICIT OtherRevocationInfoFormat }
OtherRevocationInfoFormat ::= SEQUENCE {
otherRevInfoFormat OBJECT IDENTIFIER,
otherRevInfo ANY DEFINED BY otherRevInfoFormat }
OtherRevocationInfoFormat ::= SEQUENCE {
otherRevInfoFormat OBJECT IDENTIFIER,
otherRevInfo ANY DEFINED BY otherRevInfoFormat }
The other CHOICE MUST be used to convey OCSP responses, SCVP requests, and SCVP responses.
另一个选项必须用于传递OCSP响应、SCVP请求和SCVP响应。
This document defines the id-ri arc under which the revocation information formats are defined. The id-ri object identifier is:
本文档定义了定义撤销信息格式的id ri弧。id ri对象标识符为：
id-ri OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) ri(16) }
id-ri OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) ri(16) }
NOTE: Numbers 1 and 3 were assigned to CRL and Delta CRL. These two numbers are not used because these formats use the RevocationInfoChoice crl CHOICE when included in CMS [CMS].
注：编号1和3分配给CRL和增量CRL。不使用这两个数字，因为这些格式在包含在CMS[CMS]中时使用RevocationFochoice crl选项。
To carry an OCSP response, the otherRevInfoFormat is set to id-ri-ocsp-response, which has the following ASN.1 definition:
要携带OCSP响应，OtherRevInfo格式设置为id ri OCSP响应，其具有以下ASN.1定义：
id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 }
id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 }
In this case, otherRevInfo MUST carry the OCSP response using the OCSPResponse type defined in [OCSP]. The responseStatus field MUST be successful and the responseBytes field MUST be present.
在这种情况下，otherRevInfo必须使用[OCSP]中定义的OCSPResponse类型携带OCSP响应。responseStatus字段必须成功，responseBytes字段必须存在。
Unlike OSCP, SCVP permits unprotected and protected responses, where protected responses can be digitally signed or include message authentication codes. While this provides more flexibility, it complicates implementations when an SCVP response can be validated by entities other than the entity that generated the SCVP request. If a lower layer provides authentication and integrity for the client-server interaction and the response is not protected, then a third
与OSCP不同，SCVP允许未受保护和受保护的响应，其中受保护的响应可以进行数字签名或包含消息身份验证代码。虽然这提供了更大的灵活性，但当SCVP响应可以由生成SCVP请求的实体以外的实体验证时，会使实现复杂化。如果较低的层为客户机-服务器交互提供身份验证和完整性，并且响应没有受到保护，那么第三层
party cannot validate the response because there is no way to know that the response was returned over a protected connection. If a message authentication code is used, then the third party will be unable to validate the message authentication code because it does not possess the necessary private key. For these reasons, SCVP responses sent to a third party MUST be signed by the SCVP server so that the third party can validate them.
参与方无法验证响应，因为无法知道响应是通过受保护的连接返回的。如果使用了消息身份验证码，则第三方将无法验证消息身份验证码，因为它没有必要的私钥。由于这些原因，发送给第三方的SCVP响应必须由SCVP服务器签名，以便第三方可以验证它们。
SCVP response validation requires matching it to the SCVP request. This means that the SCVP request MUST always be included with the response. SCVP permits the client to retain the response, and SCVP permits the request to be returned in the response (in the requestReq field). The request need not be protected for matching to be performed; nonces and certIds can be checked.
SCVP响应验证需要将其与SCVP请求匹配。这意味着SCVP请求必须始终包含在响应中。SCVP允许客户端保留响应，SCVP允许在响应中返回请求（在requestReq字段中）。执行匹配时不需要保护请求；可以检查nonce和certIds。
To carry the SCVP request and response, the otherRevInfoFormat is set to id-ri-scvp, which has the following ASN.1 definition:
要承载SCVP请求和响应，OtherRevInfo格式设置为id ri SCVP，其具有以下ASN.1定义：
id-ri-scvp OBJECT IDENTIFIER ::= { id-ri 4 }
id-ri-scvp OBJECT IDENTIFIER ::= { id-ri 4 }
In this case, the otherRevInfo MUST carry both the SCVP request and response with the following structure:
在这种情况下，otherRevInfo必须携带具有以下结构的SCVP请求和响应：
SCVPReqRes ::= SEQUENCE {
request [0] EXPLICIT ContentInfo OPTIONAL,
response ContentInfo }
SCVPReqRes ::= SEQUENCE {
request [0] EXPLICIT ContentInfo OPTIONAL,
response ContentInfo }
The SCVPReqRes has the following fields:
SCVPREQURES具有以下字段：
o request contains the SCVP request. It contains the unprotected request, authenticated request, or the signed request. The request MUST be present if the response does not include the requestRef fullRequest field.
o 请求包含SCVP请求。它包含未受保护的请求、已验证的请求或已签名的请求。如果响应不包括requestRef fullRequest字段，则请求必须存在。
o response contains the SCVP response. It MUST contain the signed response. Additionally, the responseStatus MUST be okay. Unprotected and authenticated responses MUST NOT be included.
o 响应包含SCVP响应。它必须包含已签名的响应。此外，响应状态必须是正常的。不得包含未受保护和已验证的响应。
The security considerations of [CMS], [CMS-ASN], [OCSP], [SCVP], and [PROFILE-ASN] apply.
[CMS]、[CMS-ASN]、[OCSP]、[SCVP]和[PROFILE-ASN]的安全注意事项适用。
To locally store unprotected or authenticated SCVP responses, a client can encapsulate the unprotected or authenticated SCVP response in a SignedData. It is a matter of local policy whether these SCVP responses that are encapsulated and signed by the client are considered valid by another entity.
要在本地存储未受保护或已验证的SCVP响应，客户端可以将未受保护或已验证的SCVP响应封装在签名数据中。由客户端封装和签名的这些SCVP响应是否被其他实体视为有效，这是本地政策的问题。
This document makes use of object identifiers. These object identifiers are defined in an arc delegated by IANA to the PKIX Working Group. When the PKIX Working Group closes, this arc and its registration procedures will be transferred to IANA. No further action by IANA is necessary for this document or any anticipated updates.
本文档使用对象标识符。这些对象标识符在IANA委托给PKIX工作组的arc中定义。PKIX工作组结束后，该arc及其注册程序将移交给IANA。IANA无需对本文件或任何预期更新采取进一步行动。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009.
[CMS]Housley，R.，“加密消息语法（CMS）”，RFC 56522009年9月。
[CMS-ASN] Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, June 2010.
[CMS-ASN]Hoffman，P.和J.Schaad，“用于加密消息语法（CMS）和S/MIME的新ASN.1模块”，RFC 59112010年6月。
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[OCSP]Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年6月。
[PROFILE-ASN] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010.
[PROFILE-ASN]Hoffman，P.和J.Schaad，“使用X.509（PKIX）的公钥基础设施的新ASN.1模块”，RFC 5912，2010年6月。
[SCVP] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, "Server-Based Certificate Validation Protocol (SCVP)", RFC 5055, December 2007.
[SCVP]Freeman，T.，Housley，R.，Malpani，A.，Cooper，D.，和W.Polk，“基于服务器的证书验证协议（SCVP）”，RFC 50552007年12月。
[WORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[WORDS]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- 1:2002. Information Technology - Abstract Syntax Notation One.
[X.680]ITU-T建议X.680（2002）| ISO/IEC 8824-1:2002。信息技术.抽象语法符号1。
[X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824- 2:2002. Information Technology - Abstract Syntax Notation One: Information Object Specification.
[X.681]ITU-T建议X.681（2002）| ISO/IEC 8824-2:2002。信息技术.抽象语法符号1:信息对象规范。
[X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824- 3:2002. Information Technology - Abstract Syntax Notation One: Constraint Specification.
[X.682]ITU-T建议X.682（2002）| ISO/IEC 8824-3:2002。信息技术.抽象语法符号1:约束规范。
[X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824- 4:2002. Information Technology - Abstract Syntax Notation One: Parameterization of ASN.1 Specifications, 2002.
[X.683]ITU-T建议X.683（2002）| ISO/IEC 8824-4:2002。信息技术.抽象语法符号1:ASN.1规范的参数化，2002。
[PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[PROFILE]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）简介”，RFC 52802008年5月。
Appendix A.1 provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in [X.680] for compilers that support the 1988 ASN.1.
附录A.1使用[X.680]中定义的ASN.1为支持1988 ASN.1的编译器提供了本规范中所述结构的规范性ASN.1定义。
Appendix A.2 provides informative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in [X.680], [X.681], [X.682], and [X.683] for compilers that support the 2002 ASN.1. This appendix contains the same information as Appendix A.1 in a more recent (and precise) ASN.1 notation, however Appendix A.1 takes precedence in case of conflict.
附录A.2使用[X.680]、[X.681]、[X.682]和[X.683]中定义的ASN.1为支持2002 ASN.1的编译器提供了本规范中所述结构的信息性ASN.1定义。本附录包含与附录A.1相同的最新（准确）ASN.1符号信息，但如有冲突，以附录A.1为准。
CMS-Other-RIs-2009-88
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-cms-otherRIs-2009-88(63)
}
CMS-Other-RIs-2009-88
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-cms-otherRIs-2009-88(63)
}
DEFINITIONS IMPLICIT TAGS ::=
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL IMPORTS
--出口所有进口产品
-- FROM CMS [CMS]
--来自CMS[CMS]
ContentInfo
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24) }
ContentInfo
FROM CryptographicMessageSyntax2004
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) cms-2004(24) }
;
;
id-ri OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) ri(16) }
id-ri OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) ri(16) }
-- RevocationInfoChoice for OCSP response
-- OID included in otherRevInfoFormat
-- signed OCSP response included in otherRevInfo
-- RevocationInfoChoice for OCSP response
-- OID included in otherRevInfoFormat
-- signed OCSP response included in otherRevInfo
id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 }
id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 }
-- RevocationInfoChoice for SCVP response
-- OID included in otherRevInfoFormat
-- SCVPReqRes included in otherRevInfo
-- RevocationInfoChoice for SCVP response
-- OID included in otherRevInfoFormat
-- SCVPReqRes included in otherRevInfo
id-ri-scvp OBJECT IDENTIFIER ::= { id-ri 4 }
id-ri-scvp OBJECT IDENTIFIER ::= { id-ri 4 }
SCVPReqRes ::= SEQUENCE {
request [0] EXPLICIT ContentInfo OPTIONAL,
response ContentInfo }
SCVPReqRes ::= SEQUENCE {
request [0] EXPLICIT ContentInfo OPTIONAL,
response ContentInfo }
END
终止
CMS-Other-RIs-2009-02
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-cms-otherRIs-2009-93(64)
}
CMS-Other-RIs-2009-02
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-cms-otherRIs-2009-93(64)
}
DEFINITIONS IMPLICIT TAGS ::=
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
开始
-- EXPORT ALL IMPORTS
--出口所有进口产品
-- FROM [PROFILE-ASN]
--来自[PROFILE-ASN]
OCSPResponse
FROM OCSP-2009
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-02(48) }
OCSPResponse
FROM OCSP-2009
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-02(48) }
-- FROM [CMS-ASN]
--来自[CMS-ASN]
ContentInfo, OTHER-REVOK-INFO
FROM CryptographicMessageSyntax-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-2004-02(41) }
ContentInfo, OTHER-REVOK-INFO
FROM CryptographicMessageSyntax-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-2004-02(41) }
;
;
-- Defines OCSP and SCVP formats for RevocationInfoChoice
--定义用于撤销选择的OCSP和SCVP格式
SupportedOtherRevokInfo OTHER-REVOK-INFO ::= {
ri-ocsp-response |
ri-scvp,
... }
SupportedOtherRevokInfo OTHER-REVOK-INFO ::= {
ri-ocsp-response |
ri-scvp,
... }
ri-ocsp-response OTHER-REVOK-INFO ::= {
OCSPResponse IDENTIFIED BY id-ri-ocsp-response }
ri-ocsp-response OTHER-REVOK-INFO ::= {
OCSPResponse IDENTIFIED BY id-ri-ocsp-response }
id-ri OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) ri(16) }
id-ri OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) ri(16) }
id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 }
id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 }
ri-scvp OTHER-REVOK-INFO ::= {
SCVPReqRes IDENTIFIED BY id-ri-scvp }
ri-scvp OTHER-REVOK-INFO ::= {
SCVPReqRes IDENTIFIED BY id-ri-scvp }
id-ri-scvp OBJECT IDENTIFIER ::= { id-ri 4 }
id-ri-scvp OBJECT IDENTIFIER ::= { id-ri 4 }
SCVPReqRes ::= SEQUENCE {
request [0] EXPLICIT ContentInfo OPTIONAL,
response ContentInfo }
SCVPReqRes ::= SEQUENCE {
request [0] EXPLICIT ContentInfo OPTIONAL,
response ContentInfo }
END
终止
Authors' Addresses
作者地址
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
Sean Turner IECA，Inc.美国弗吉尼亚州费尔法克斯市努特利街3057号106室，邮编22031
EMail: turners@ieca.com
EMail: turners@ieca.com
Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russ Housley Vigil Security，LLC 918 Spring Knoll Drive Herndon，弗吉尼亚州，邮编20170
EMail: housley@vigilsec.com
EMail: housley@vigilsec.com