[要約] RFC 6277は、オンライン証明書ステータスプロトコル（OCSP）のアルゴリズムの柔軟性に関するものであり、OCSPのアルゴリズムの適用範囲と柔軟性を向上させることを目的としています。
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
オンライン証明書ステータスプロトコルアルゴリズムの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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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 Responder証明書を発行する場合と発行されない場合があります。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をサポートし、セクションで指定されているRSA署名を処理できる必要があることです。[RFC2459]の7.2.1。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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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 Responderが使用して応答に署名するキーペアと一致しない場合があります。
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 Responderは、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 実装は、2つの個別の署名アルゴリズムを使用することにより、署名アルゴリズムの妥協から生じる妥協の可能性を防ぐことを望む場合があります。
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]で指定されたSHA1WithRSAENCRYPTION OIDによって識別）およびSHA-256（[RFC4055]で指定されたSHA256WithRSAENCRYPTION OIDによって識別）。また、クライアントは、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 }
PreferredSignatureAlgorithms ::= SEQUENCE OF
PreferredSignatureAlgorithm
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].
Algorithmidentifierの構文は、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.
PubKeyAlgidentifierは、OCSP応答を検証するために使用されるサーバーの証明書でクライアントが好む主題の公開キーアルゴリズム識別子を指定します。
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.
PubKeyAlgidentifierはオプションであり、特定のアルゴリズムのさまざまな使用法を区別するために必要なパラメーターを指定する手段を提供します。たとえば、クライアントが特定の楕円曲線アルゴリズムでサポートする曲線を指定するために使用できます。
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.
著者は、以前のドラフトに関する有益なコメント、アルゴリズム識別子の構文を提案したSean Turner、付録AのASN.1モジュールを提供およびテストしたJim Schaad、および貴重なレビューとインプットのためにStephen Kentをテストしたことについて、Santosh Chokhaniを認めています。
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 Responderは、クライアントから要求された場合でも弱いアルゴリズムを使用して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インターネット公開キーインフラストラクチャオンライン証明書ステータスプロトコル」、RFC 2560、1999年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、「インターネットで使用するRSA暗号化の追加アルゴリズムと識別子X.509公開鍵インフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、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 5280、2008年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、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.2メッセージ仕様」、RFC 5751、2010年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 4732、2006年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) }
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) }
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)} ;
-- 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 }
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
PreferredSignatureAlgorithms ::= SEQUENCE OF
PreferredSignatureAlgorithm
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) }
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)}
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) }
id-pkix-ocsp-pref-sig-algs OBJECT IDENTIFIER ::= { id-pkix-ocsp 8 }
PreferredSignatureAlgorithms ::= SEQUENCE OF
PreferredSignatureAlgorithm
PreferredSignatureAlgorithm ::= SEQUENCE {
sigIdentifier AlgorithmIdentifier,
pubKeyAlgIdentifier SMIMECapability OPTIONAL
}
END
終わり
Authors' Addresses
著者のアドレス
Stefan Santesson 3xA Security AB Sweden
Stefan Santesson 3XAセキュリティABスウェーデン
Email: sts@aaa-sec.com
Phillip Hallam-Baker Default Deny Security
Phillip Hallam-Bakerデフォルトはセキュリティを拒否します
EMail: hallam@gmail.com