Internet Engineering Task Force (IETF) S. Santesson
Request for Comments: 6277 3xA Security
Updates: 2560 P. Hallam-Baker
Category: Standards Track Default Deny Security
ISSN: 2070-1721 June 2011
Internet Engineering Task Force (IETF) S. Santesson
Request for Comments: 6277 3xA Security
Updates: 2560 P. Hallam-Baker
Category: Standards Track Default Deny Security
ISSN: 2070-1721 June 2011
Online Certificate Status Protocol Algorithm Agility
在线证书状态协议算法的敏捷性
Abstract
摘要
The Online Certificate Status Protocol (OCSP) requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used. This may lead to avoidable interoperability failures in contexts where multiple signature algorithms are in use. This document specifies rules for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported.
联机证书状态协议（OCSP）要求对服务器响应进行签名，但未指定选择要使用的签名算法的机制。在使用多个签名算法的环境中，这可能会导致可避免的互操作性故障。本文档指定了服务器签名算法选择规则和一个扩展，该扩展允许客户机通知服务器支持特定的签名算法。
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/rfc6277.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6277.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. OCSP Algorithm Agility Requirements .............................3
3. Updates to Mandatory and Optional Cryptographic Algorithms ......4
4. Client Indication of Preferred Signature Algorithms .............4
5. Responder Signature Algorithm Selection .........................5
5.1. Dynamic Response ...........................................5
5.2. Static Response ............................................6
6. Acknowledgements ................................................6
7. Security Considerations .........................................6
7.1. Use of Insecure Algorithms .................................6
7.2. Man-in-the-Middle Downgrade Attack .........................7
7.3. Denial-of-Service Attack ...................................7
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................8
Appendix A. ASN.1 Modules .........................................9
A.1. ASN.1 Module ...............................................9
A.2. 1988 ASN.1 Module .........................................10
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. OCSP Algorithm Agility Requirements .............................3
3. Updates to Mandatory and Optional Cryptographic Algorithms ......4
4. Client Indication of Preferred Signature Algorithms .............4
5. Responder Signature Algorithm Selection .........................5
5.1. Dynamic Response ...........................................5
5.2. Static Response ............................................6
6. Acknowledgements ................................................6
7. Security Considerations .........................................6
7.1. Use of Insecure Algorithms .................................6
7.2. Man-in-the-Middle Downgrade Attack .........................7
7.3. Denial-of-Service Attack ...................................7
8. References ......................................................7
8.1. Normative References .......................................7
8.2. Informative References .....................................8
Appendix A. ASN.1 Modules .........................................9
A.1. ASN.1 Module ...............................................9
A.2. 1988 ASN.1 Module .........................................10
The Online Certificate Status Protocol (OCSP) [RFC2560] defines a protocol for obtaining certificate status information from an online service. An OCSP responder may or may not be issued an OCSP responder certificate by the certification authority (CA) that issued the certificate whose status is being queried. An OCSP responder may provide pre-signed OCSP responses or may sign responses when queried.
在线证书状态协议（OCSP）[RFC2560]定义了用于从在线服务获取证书状态信息的协议。OCSP响应者可能会，也可能不会被颁发其状态被查询的证书的证书颁发机构（CA）颁发OCSP响应者证书。OCSP响应者可以提供预先签名的OCSP响应，也可以在查询时签名响应。
RFC 2560 [RFC2560] specifies a means for an OCSP responder to indicate the signature and digest algorithms used in a response but not how those algorithms are specified. The only algorithm requirements established by that protocol specification are that the OCSP client SHALL support the Digital Signature Algorithm (DSA) sig-alg-oid specified in Section 7.2.2 of [RFC2459] and SHOULD be capable of processing RSA signatures as specified in Section 7.2.1 of [RFC2459]. The only requirement placed on responders by RFC 2560 is that they SHALL support the SHA1 hashing algorithm.
RFC 2560[RFC2560]指定OCSP响应程序指示响应中使用的签名和摘要算法的方法，但不指定这些算法的指定方式。该协议规范规定的唯一算法要求是OCSP客户端应支持[RFC2459]第7.2.2节中规定的数字签名算法（DSA）sig alg oid，并应能够处理[RFC2459]第7.2.1节中规定的RSA签名。RFC 2560对响应者的唯一要求是，响应者应支持SHA1哈希算法。
This document specifies rules for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported.
本文档指定了服务器签名算法选择规则和一个扩展，该扩展允许客户机通知服务器支持特定的签名算法。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Since algorithms other than those that are mandatory to implement are allowed and since a client currently has no mechanism to indicate its algorithm preferences, there is always a risk that a server choosing a non-mandatory algorithm will generate a response that the client may not support.
由于允许使用强制实现算法以外的算法，并且由于客户端当前没有指示其算法首选项的机制，因此始终存在服务器选择非强制算法将生成客户端可能不支持的响应的风险。
While an OCSP responder may apply rules for algorithm selection, e.g., using the signature algorithm employed by the CA for signing certificate revocation lists (CRLs) and certificates, such rules may fail in common situations:
虽然OCSP响应者可以应用算法选择规则，例如，使用CA用于签名证书撤销列表（CRL）和证书的签名算法，但此类规则在常见情况下可能会失败：
o The algorithm used to sign the CRLs and certificates may not be consistent with the key pair being used by the OCSP responder to sign responses.
o 用于签署CRL和证书的算法可能与OCSP响应程序用于签署响应的密钥对不一致。
o A request for an unknown certificate provides no basis for a responder to select from among multiple algorithm options.
o 对未知证书的请求不提供响应者从多个算法选项中选择的依据。
Without modifying the protocol, the last criterion cannot be resolved through the information available from in-band signaling using the protocol described in RFC 2560 [RFC2560].
在不修改协议的情况下，最后一个标准无法通过使用RFC 2560[RFC2560]中所述协议的带内信令提供的信息来解决。
In addition, an OCSP responder may wish to employ different signature algorithms than the one used by the CA to sign certificates and CRLs for several reasons:
此外，OCSP响应者可能希望采用不同于CA用于签署证书和CRL的签名算法，原因如下：
o The responder may employ an algorithm for certificate status response that is less computationally demanding than for signing the certificate itself.
o 响应者可以采用用于证书状态响应的算法，该算法的计算要求比用于签名证书本身的算法低。
o An implementation may wish to guard against the possibility of a compromise resulting from a signature algorithm compromise by employing two separate signature algorithms.
o 实现可能希望通过使用两个单独的签名算法来防止签名算法妥协导致妥协的可能性。
This document describes:
本文件描述：
o A mechanism that allows a client to indicate the set of preferred signature algorithms.
o 一种允许客户端指示首选签名算法集的机制。
o Rules for signature algorithm selection that maximize the probability of successful operation in the case that no supported preferred algorithm(s) are specified.
o 在未指定受支持的首选算法的情况下，使成功操作概率最大化的签名算法选择规则。
Section 4.3 ("Mandatory and Optional Cryptographic Algorithms") of RFC 2560 [RFC2560] is updated as follows:
RFC 2560[RFC2560]第4.3节（“强制和可选加密算法”）更新如下：
OLD: Clients that request OCSP services SHALL be capable of processing responses signed used DSA keys identified by the DSA sig-alg-oid specified in section 7.2.2 of [RFC2459]. Clients SHOULD also be capable of processing RSA signatures as specified in section 7.2.1 of [RFC2459]. OCSP responders SHALL support the SHA1 hashing algorithm.
旧：请求OCSP服务的客户端应能够处理由[RFC2459]第7.2.2节中规定的DSA sig alg oid识别的使用DSA密钥签名的响应。客户机还应能够按照[RFC2459]第7.2.1节的规定处理RSA签名。OCSP响应者应支持SHA1哈希算法。
NEW: Clients that request OCSP services SHALL be capable of processing responses signed using RSA with SHA-1 (identified by sha1WithRSAEncryption OID specified in [RFC3279]) and RSA with SHA-256 (identified by sha256WithRSAEncryption OID specified in [RFC4055]). Clients SHOULD also be capable of processing responses signed using DSA keys (identified by the id-dsa-with-sha1 OID specified in [RFC3279]). Clients MAY support other algorithms.
新增：请求OCSP服务的客户机应能够处理使用带有SHA-1的RSA（由[RFC3279]中指定的带有RSA加密OID的SHA1标识）和带有SHA-256的RSA（由[RFC4055]中指定的带有RSA加密OID的SHA256标识）签名的响应。客户端还应该能够处理使用DSA密钥（由[RFC3279]中指定的id-DSA-with-sha1 OID标识）签名的响应。客户端可能支持其他算法。
A client MAY declare a preferred set of algorithms in a request by including a preferred signature algorithms extension in requestExtensions of the OCSPRequest [RFC2560].
客户机可以通过在OCSPRequest[RFC2560]的requestExtensions中包含首选签名算法扩展来声明请求中的首选算法集。
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
PreferredSignatureAlgorithms ::= SEQUENCE OF
PreferredSignatureAlgorithm
PreferredSignatureAlgorithms ::= SEQUENCE OF
PreferredSignatureAlgorithm
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier,
pubKeyAlgIdentifier SMIMECapability OPTIONAL
}
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier,
pubKeyAlgIdentifier SMIMECapability OPTIONAL
}
The syntax of AlgorithmIdentifier is defined in Section 4.1.1.2 of RFC 5280 [RFC5280]. The syntax of SMIMECapability is defined in RFC 5751 [RFC5751].
RFC 5280[RFC5280]第4.1.1.2节定义了算法标识符的语法。SMIMECapability的语法在RFC 5751[RFC5751]中定义。
sigIdentifier specifies the signature algorithm the client prefers, e.g., algorithm=ecdsa-with-sha256. Parameters are absent for most common signature algorithms.
sigIdentifier指定客户端首选的签名算法，例如，算法=ecdsa-with-sha256。大多数常见的签名算法都没有参数。
pubKeyAlgIdentifier specifies the subject public key algorithm identifier the client prefers in the server's certificate used to validate the OCSP response, e.g., algorithm=id-ecPublicKey and parameters= secp256r1.
PubKeyalIdentifier指定客户端在用于验证OCSP响应的服务器证书中首选的主题公钥算法标识符，例如，算法=id ecPublicKey和参数=secp256r1。
pubKeyAlgIdentifier is OPTIONAL and provides means to specify parameters necessary to distinguish among different usages of a particular algorithm, e.g., it may be used by the client to specify what curve it supports for a given elliptic curve algorithm.
PubKeyalIdentifier是可选的，它提供了指定必要参数的方法，以区分特定算法的不同用途，例如，客户端可以使用它来指定它支持给定椭圆曲线算法的曲线。
The client MUST support each of the specified preferred signature algorithms, and the client MUST specify the algorithms in the order of preference, from the most preferred to the least preferred.
客户机必须支持每个指定的首选签名算法，并且客户机必须按照从最首选到最不首选的顺序指定算法。
Section 5 of this document describes how a server selects an algorithm for signing OCSP responses to the requesting client.
本文档的第5节描述了服务器如何选择一种算法，对请求客户端的OCSP响应进行签名。
RFC 2560 [RFC2560] does not specify a mechanism for deciding the signature algorithm to be used in an OCSP response. As previously noted, this does not provide a sufficient degree of certainty as to the algorithm selected to facilitate interoperability.
RFC 2560[RFC2560]未指定用于决定OCSP响应中使用的签名算法的机制。如前所述，对于为促进互操作性而选择的算法，这并不能提供足够的确定性。
As long as the selected algorithm meets all security requirements of the OCSP responder, a responder MAY maximize the potential for ensuring interoperability by selecting a supported signature algorithm using the following order of precedence, where the first method has the highest precedence:
只要所选算法满足OCSP响应者的所有安全要求，响应者就可以通过使用以下优先顺序选择受支持的签名算法来最大限度地确保互操作性，其中第一种方法具有最高优先级：
1. Select an algorithm specified as a preferred signing algorithm in the client request.
1. 在客户端请求中选择指定为首选签名算法的算法。
2. Select the signing algorithm used to sign a certificate revocation list (CRL) issued by the certificate issuer to provide status information for the certificate specified by CertID.
2. 选择用于对证书颁发者颁发的证书吊销列表（CRL）进行签名的签名算法，以提供CertID指定的证书的状态信息。
3. Select the signing algorithm used to sign the OCSPRequest.
3. 选择用于对OCSPRequest进行签名的签名算法。
4. Select a signature algorithm that has been advertised as being the default signature algorithm for the signing service using an out-of-band mechanism.
4. 选择一个签名算法，该算法已被公布为使用带外机制的签名服务的默认签名算法。
5. Select a mandatory or recommended signing algorithm specified for the version of the OCSP protocol in use.
5. 选择为正在使用的OCSP协议版本指定的强制或推荐签名算法。
A responder SHOULD always apply the lowest-numbered selection mechanism that results in the selection of a known and supported algorithm that meets the responder's criteria for cryptographic algorithm strength.
响应者应始终应用编号最低的选择机制，以选择满足响应者密码算法强度标准的已知和受支持的算法。
For purposes of efficiency, an OCSP responder is permitted to generate static responses in advance of a request. The case may not permit the responder to make use of the client request data during the response generation; however, the responder SHOULD still use the client request data during the selection of the pre-generated response to be returned. Responders MAY use the historical client requests as part of the input to the decisions of what different algorithms should be used to sign the pre-generated responses.
为了提高效率，允许OCSP响应程序在请求之前生成静态响应。该情况可能不允许响应者在响应生成期间使用客户端请求数据；但是，在选择要返回的预生成响应期间，响应者仍应使用客户端请求数据。响应者可以使用历史客户机请求作为输入的一部分，以决定应使用何种不同算法对预生成的响应进行签名。
The authors acknowledge Santosh Chokhani for the helpful comments made on earlier drafts, Sean Turner for proposing the syntax for algorithm identifiers, Jim Schaad for providing and testing the ASN.1 module in Appendix A, and Stephen Kent for valuable review and input.
作者感谢Santosh Chokhani对早期草案的有益评论，Sean Turner提出了算法标识符的语法，Jim Schaad提供并测试了附录A中的ASN.1模块，Stephen Kent提供了有价值的评论和输入。
The mechanism used to choose the response signing algorithm MUST be considered to be sufficiently secure against cryptanalytic attack for the intended application.
必须考虑用于选择响应签名算法的机制对预期应用程序的密码分析攻击具有足够的安全性。
In most applications, it is sufficient for the signing algorithm to be at least as secure as the signing algorithm used to sign the original certificate whose status is being queried. However, this criteria may not hold in long-term archival applications in which the status of a certificate is being queried for a date in the distant past, long after the signing algorithm has ceased to be considered trustworthy.
在大多数应用程序中，签名算法至少与用于对状态被查询的原始证书进行签名的签名算法一样安全就足够了。但是，在签名算法不再被认为是可信的很久之后，在长期存档应用程序中，该标准可能不适用于查询证书状态以查找遥远过去的某个日期。
It is not always possible for a responder to generate a response that the client is expected to understand and that meets contemporary standards for cryptographic security. In such cases, an OCSP responder operator MUST balance the risk of employing a compromised security solution and the cost of mandating an upgrade, including the risk that the alternative chosen by end users will offer even less security or no security.
对于响应者来说，并不总是能够生成期望客户机理解并满足当代密码安全标准的响应。在这种情况下，OCSP响应者运营商必须平衡使用受损安全解决方案的风险和强制升级的成本，包括最终用户选择的替代方案安全性更低或没有安全性的风险。
In archival applications, it is quite possible that an OCSP responder might be asked to report the validity of a certificate on a date in the distant past. Such a certificate might employ a signing method that is no longer considered acceptably secure. In such circumstances, the responder MUST NOT generate a signature using a signing mechanism that is not considered acceptably secure.
在存档应用程序中，很可能会要求OCSP响应者在遥远的过去某个日期报告证书的有效性。这样的证书可能使用不再被认为是可接受安全的签名方法。在这种情况下，响应者不得使用被认为不可接受安全的签名机制生成签名。
A client MUST accept any signing algorithm in a response that it specified as a preferred signing algorithm in the request. Therefore, it follows that a client MUST NOT specify a preferred signing algorithm that is either not supported or not considered acceptably secure.
客户端必须在响应中接受它在请求中指定为首选签名算法的任何签名算法。因此，客户机不能指定不受支持或认为不安全的首选签名算法。
The mechanism to support client indication of preferred signature algorithms is not protected against a man-in-the-middle downgrade attack. This constraint is not considered to be a significant security concern since the OCSP responder MUST NOT sign OCSP responses using weak algorithms even if requested by the client. In addition, the client can reject OCSP responses that do not meet its own criteria for acceptable cryptographic security no matter what mechanism is used to determine the signing algorithm of the response.
支持客户端指示首选签名算法的机制不受中间人降级攻击的保护。由于OCSP响应程序不得使用弱算法对OCSP响应进行签名（即使客户端请求），因此该约束不被视为重大安全问题。此外，无论使用何种机制来确定响应的签名算法，客户端都可以拒绝不符合其自身可接受密码安全标准的OCSP响应。
Algorithm agility mechanisms defined in this document introduce a slightly increased attack surface for denial-of-service attacks where the client request is altered to require algorithms that are not supported by the server. Denial-of-service considerations from RFC 4732 [RFC4732] are relevant for this document.
本文中定义的算法敏捷性机制为拒绝服务攻击引入了略微增加的攻击面，其中客户端请求被更改为需要服务器不支持的算法。RFC 4732[RFC4732]中的拒绝服务注意事项与本文档相关。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2560]Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年6月。
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3279]Bassham，L.，Polk，W.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的算法和标识符”，RFC 3279，2002年4月。
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[RFC4055]Schaad，J.，Kaliski，B.，和R.Housley，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件中使用的RSA加密的其他算法和标识符”，RFC 4055，2005年6月。
[RFC5280] 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.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 57512010年1月。
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010.
[RFC5912]Hoffman，P.和J.Schaad，“使用X.509（PKIX）的公钥基础设施的新ASN.1模块”，RFC 5912，2010年6月。
[RFC2459] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
[RFC2459]Housley，R.，Ford，W.，Polk，W.，和D.Solo，“互联网X.509公钥基础设施证书和CRL配置文件”，RFC 2459，1999年1月。
[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]Handley，M.，Ed.，Rescorla，E.，Ed.，和IAB，“互联网拒绝服务注意事项”，RFC 47322006年12月。
OCSP-AGILITY-2009 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-ocsp-agility-2009-93(66) }
OCSP-AGILITY-2009 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-ocsp-agility-2009-93(66) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
EXPORTS ALL; -- export all items from this module IMPORTS
全部出口；——导出此模块中的所有项目导入
id-pkix-ocsp
FROM OCSP-2009 -- From OCSP [RFC2560]
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-02(48) }
id-pkix-ocsp
FROM OCSP-2009 -- From OCSP [RFC2560]
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp-02(48) }
AlgorithmIdentifier{}, SMIMECapability{}, SIGNATURE-ALGORITHM,
PUBLIC-KEY
FROM AlgorithmInformation-2009 -- From [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
AlgorithmIdentifier{}, SMIMECapability{}, SIGNATURE-ALGORITHM,
PUBLIC-KEY
FROM AlgorithmInformation-2009 -- From [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
EXTENSION
FROM PKIX-CommonTypes-2009 -- From [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} ;
EXTENSION
FROM PKIX-CommonTypes-2009 -- From [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} ;
-- Add re-preferred-signature-algorithms to the set of extensions
-- for TBSRequest.requestExtensions
-- Add re-preferred-signature-algorithms to the set of extensions
-- for TBSRequest.requestExtensions
re-preferred-signature-algorithms EXTENSION ::= {
SYNTAX PreferredSignatureAlgorithms
IDENTIFIED BY id-pkix-ocsp-pref-sig-algs }
re-preferred-signature-algorithms EXTENSION ::= {
SYNTAX PreferredSignatureAlgorithms
IDENTIFIED BY id-pkix-ocsp-pref-sig-algs }
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
PreferredSignatureAlgorithms ::= SEQUENCE OF
PreferredSignatureAlgorithm
PreferredSignatureAlgorithms ::= SEQUENCE OF
PreferredSignatureAlgorithm
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}},
pubKeyAlgIdentifier SMIMECapability{PUBLIC-KEY, {...}} OPTIONAL }
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier{SIGNATURE-ALGORITHM, {...}},
pubKeyAlgIdentifier SMIMECapability{PUBLIC-KEY, {...}} OPTIONAL }
END
终止
OCSP-AGILITY-88 { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-ocsp-agility-2009-88(67) }
OCSP-AGILITY-88 { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-ocsp-agility-2009-88(67) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL; IMPORTS
--全部出口；进口
id-pkix-ocsp -- From [RFC2560]
FROM OCSP
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)}
id-pkix-ocsp -- From [RFC2560]
FROM OCSP
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)}
AlgorithmIdentifier
FROM PKIX1Explicit88 -- From [RFC5280]
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) };
AlgorithmIdentifier
FROM PKIX1Explicit88 -- From [RFC5280]
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) };
SMIMECapability
FROM SecureMimeMessageV3dot1 -- From [RFC5751]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) msg-v3dot1(21) }
SMIMECapability
FROM SecureMimeMessageV3dot1 -- From [RFC5751]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) msg-v3dot1(21) }
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
PreferredSignatureAlgorithms ::= SEQUENCE OF
PreferredSignatureAlgorithm
PreferredSignatureAlgorithms ::= SEQUENCE OF
PreferredSignatureAlgorithm
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier,
pubKeyAlgIdentifier SMIMECapability OPTIONAL
}
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier,
pubKeyAlgIdentifier SMIMECapability OPTIONAL
}
END
终止
Authors' Addresses
作者地址
Stefan Santesson 3xA Security AB Sweden
瑞典Stefan Santesson 3SA安全AB
Email: sts@aaa-sec.com
Email: sts@aaa-sec.com
Phillip Hallam-Baker Default Deny Security
Phillip Hallam Baker默认拒绝安全性
EMail: hallam@gmail.com
EMail: hallam@gmail.com