[要約] RFC 5940は、"Additional Cryptographic Message Syntax (CMS) Revocation Information Choices"に関する文書で、CMS (Cryptographic Message Syntax) における証明書失効情報の選択肢を拡張します。このRFCの目的は、OCSP (Online Certificate Status Protocol) 応答やCRL (Certificate Revocation List) 以外の方法で証明書の失効情報を提供するための追加オプションを定義することです。これにより、証明書の検証プロセスがより柔軟になり、特定の環境や要件に応じた適切な失効情報の提供方法を選択できるようになります。関連するRFCには、RFC 5652 (CMSの基本仕様) やRFC 5280 (インターネットX.509公開鍵インフラ証明書とCRLプロファイル) などがあります。
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）の要求と応答の2つの追加の失効情報形式を定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2010 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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]で定義されているRevocationInfoChoicesタイプは、一連の失効ステータス情報を提供します。これにより、失効情報を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）[PROFILE]は失効ステータス情報の主要な情報源ですが、他の失効情報形式もサポートできます。このドキュメントでは、他の2つの形式を指定します。オンライン証明書ステータスプロトコル（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では、RevocationInformation構造について説明します。セクション3では、OCSP応答を伝送するメカニズムを定義します。セクション4では、SCVP要求と応答を伝達するメカニズムを定義します。付録Aは、2つのメカニズムの規範的な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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [WORDS]で説明されているように解釈されます。
For convenience, the ASN.1 definition of the RevocationInfoChoices type from [CMS] is repeated here:
便宜上、[CMS]からのRevocationInfoChoicesタイプのASN.1定義をここで繰り返します。
RevocationInfoChoices ::= SET OF RevocationInfoChoice
RevocationInfoChoice ::= CHOICE {
crl CertificateList,
other [1] IMPLICIT OtherRevocationInfoFormat }
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) }
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とDelta CRLに割り当てられています。これらの2つの数値は、CMS [CMS]に含まれている場合、RevocationInfoChoice crl CHOICEを使用するため、使用されません。
To carry an OCSP response, the otherRevInfoFormat is set to id-ri-ocsp-response, which has the following ASN.1 definition:
OCSP応答を伝送するために、otherRevInfoFormatはid-ri-ocsp-responseに設定され、これには次のASN.1定義が含まれています。
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 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.
OSCPとは異なり、SCVPは保護されていない応答と保護された応答を許可します。保護された応答にはデジタル署名したり、メッセージ認証コードを含めることができます。これにより柔軟性が向上しますが、SCVP要求を生成したエンティティ以外のエンティティによってSCVP応答を検証できる場合、実装が複雑になります。下位層がクライアントとサーバーの相互作用に認証と整合性を提供し、応答が保護されていない場合、保護された接続を介して応答が返されたことを知る方法がないため、第三者は応答を検証できません。メッセージ認証コードが使用されている場合、サードパーティは必要な秘密鍵を所有していないため、メッセージ認証コードを検証できません。これらの理由により、サードパーティに送信される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フィールドで）返されることを許可します。マッチングを実行するためにリクエストを保護する必要はありません。 noncesとcertIdsを確認できます。
To carry the SCVP request and response, the otherRevInfoFormat is set to id-ri-scvp, which has the following ASN.1 definition:
SCVP要求と応答を伝送するために、otherRevInfoFormatはid-ri-scvpに設定されます。これには次のASN.1定義があります。
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 }
The SCVPReqRes has the following fields:
SCVPReqResには次のフィールドがあります。
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応答が含まれます。署名された応答が含まれている必要があります。さらに、responseStatusはOKである必要があります。保護されていない認証済みの応答を含めてはなりません。
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応答をSignedDataにカプセル化できます。クライアントによってカプセル化および署名されたこれらの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ワーキンググループに委任された弧で定義されます。 PKIXワーキンググループが終了すると、このアークとその登録手順はIANAに転送されます。このドキュメントまたは予想される更新については、IANAによるさらなるアクションは必要ありません。
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009.
[CMS] Housley、R。、「Cryptographic Message Syntax（CMS）」、RFC 5652、2009年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 5911、2010年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]マイヤーズ、M。、アンクニー、R。、マルパニ、A。、ガルペリン、S。、およびC.アダムス、「X.509インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル-OCSP」、RFC 2560、1999年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、「Server-Based Certificate Validation Protocol（SCVP）」、RFC 5055、2007年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.
[プロフィール] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年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は、1988 ASN.1をサポートするコンパイラの[X.680]で定義されている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を使用して、この仕様で説明されている構造の有益なASN.1定義を提供します2002 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)
}
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) }
;
；
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
id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 }
-- RevocationInfoChoice for SCVP response
-- OID included in otherRevInfoFormat
-- SCVPReqRes included in otherRevInfo
id-ri-scvp OBJECT IDENTIFIER ::= { id-ri 4 }
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)
}
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) }
-- 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) }
;
；
-- Defines OCSP and SCVP formats for RevocationInfoChoice
-RevocationInfoChoiceのOCSPおよびSCVP形式を定義します
SupportedOtherRevokInfo OTHER-REVOK-INFO ::= {
ri-ocsp-response |
ri-scvp,
... }
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-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 }
ri-scvp OTHER-REVOK-INFO ::= {
SCVPReqRes IDENTIFIED BY id-ri-scvp }
id-ri-scvp OBJECT IDENTIFIER ::= { id-ri 4 }
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 Nutley Street、Suite 106 Fairfax、VA 22031 USA
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、VA 20170 USA
EMail: housley@vigilsec.com