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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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レスポンダ証明書を発行してもしなくてもよいです。 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クライアントがデジタル署名をサポートすることをアルゴリズム（DSA）SIG-ALG-OIDは、[RFC2459]のセクション7.2.2で指定され、セクションで指定されるように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レスポンダは、アルゴリズムの選択のためのルールを適用することができるが、例えば、証明書失効リスト（CRL）と証明書に署名するためにCAによって使用される署名アルゴリズムを使用して、そのようなルールは、一般的な状況で失敗することがあります。
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レスポンダは、いくつかの理由のために証明書とCRLを署名するためにCAによって使用されるものとは異なる署名アルゴリズムを採用することができます。
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.
OLD：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.
NEW：OCSPサービスを要求するクライアントは、処理応答が可能なものでなければならないが（[RFC4055]で指定sha256WithRSAEncryption OIDで識別される）SHA-256で（[RFC3279]で指定sha1WithRSAEncryption OIDで識別される）SHA-1およびRSAとRSAを使用して署名しました。クライアントはまた、（[RFC3279]で指定されたID-DSA-WITH-SHA1 OIDによって識別される）DSAキーを使用して署名処理応答することができなければなりません。クライアントは、他のアルゴリズムをサポートするかもしれません。
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応答、例えば、アルゴリズム= 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.
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の方法は最高の優先順位を有する次の優先順位を使用してサポートされる署名アルゴリズムを選択することにより、相互運用性を確保するための可能性を最大にすることができます。
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. CertIDで指定された証明書のステータス情報を提供するために、証明書発行者によって発行された証明書失効リスト（CRL）の署名に使用される署名アルゴリズムを選択します。
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.
著者は、貴重なレビューと入力については、付録AにASN.1モジュールを提供し、テストするためのアルゴリズム識別子、ジムSchaadの構文を提案し、スティーブン・ケントのために、以前のドラフトで作られた有益なコメントを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.
好適な署名アルゴリズムのクライアント表示をサポートするためのメカニズムはのman-in-the-middleダウングレード攻撃から保護されていません。 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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、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.、ポーク、W.、およびR. Housley氏、RFC 3279、2002年4月 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィールのためのアルゴリズムと識別子"。
[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氏、 "インターネット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]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネット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.ターナー、 "/セキュア多目的インターネットメール拡張（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]ホフマン、P.およびJ. Schaad、RFC 5912、2010年6月 "公開鍵インフラストラクチャの使用X.509（PKIX）のための新しいASN.1モジュール"。
[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.、フォード、W.、ポーク、W.、およびD.ソロ、 "インターネット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]ハンドリー、M.、エド。、レスコラ、E.、エド。、およびIAB、 "インターネットサービス拒否の注意事項"、RFC 4732、2006年12月。
Appendix A. ASN.1 Modules
付録A. ASN.1モジュール
A.1. ASN.1 Module
A.1。 ASN.1モジュール
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）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（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) }
OCSP [RFC2560] {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MODから - ID-PKIX-OCSP OCSP-2009 FROM （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、署名アルゴリズムAlgorithmInformation-2009年公開鍵 - [RFC5912] {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（より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)} ;
PKIX-CommonTypes-2009からの伸長 - から[RFC5912] {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0） ID-MOD-pkixCommon-02（57）}。
-- Add re-preferred-signature-algorithms to the set of extensions -- for TBSRequest.requestExtensions
- 拡張機能のセットに再好ましい-署名アルゴリズムを追加 - 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
終わり
A.2. 1988 ASN.1 Module
A.2。 1988 ASN.1モジュール
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）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（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)}
ID-PKIX-OCSP - [RFC2560]からOCSP FROM {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（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) };
PKIX1Explicit88 FROMのAlgorithmIdentifier - [RFC5280] {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-pkix1-から明示的な（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) }
SecureMimeMessageV3dot1 FROM SMIMECapability - [RFC5751] {ISO（1）部材本体（2）米国（840）RSADSI（113549）PKCS（1）PKCS-9（9）SMIME（16）モジュール（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
ステファンSantesson 3XAセキュリティABスウェーデン
Email: sts@aaa-sec.com
メール：sts@aaa-sec.com
Phillip Hallam-Baker Default Deny Security
フィリップハラム - ベイカーのデフォルトのセキュリティを拒否します
EMail: hallam@gmail.com
メールアドレス：hallam@gmail.com