Internet Engineering Task Force (IETF) J. Solinas
Request for Comments: 5759 L. Zieglar
Category: Informational NSA
ISSN: 2070-1721 January 2010
Suite B Certificate and Certificate Revocation List (CRL) Profile
スイートB証明書と証明書失効リスト（CRL）のプロフィール
Abstract
抽象
This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Suite B Cryptography. The reader is assumed to have familiarity with RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".
この文書は、米国国家安全保障局（NSA）のスイートB暗号化で使用するX.509 v3の証明書とX.509 v2の証明書失効リスト（CRL）のための基本プロファイルを指定します。読者はRFC 5280、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール」に精通しているものとします。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc5759.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5759で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Requirements and Assumptions ....................................3
3.1. Implementing Suite B .......................................3
3.2. Suite B Object Identifiers .................................4
4. Suite B Certificate and Certificate Extensions Profile ..........4
4.1. signatureAlgorithm .........................................4
4.2. signatureValue .............................................5
4.3. Version ....................................................6
4.4. SubjectPublicKeyInfo .......................................6
4.5. Certificate Extensions for Particular Types of
Certificates ...............................................7
4.5.1. Suite B Self-Signed CA Certificates .................7
4.5.2. Suite B Non-Self-Signed CA Certificates .............8
4.5.3. Suite B End Entity Signature and Key
Establishment Certificates ..........................8
5. Suite B CRL and CRL Extensions Profile ..........................9
6. Security Considerations .........................................9
7. IANA Considerations .............................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use by applications that support the United States National Security Agency's Suite B Cryptography.
この文書は、米国国家安全保障局（NSA）のスイートB暗号化をサポートするアプリケーションで使用するためにX.509 v3の証明書とX.509 v2の証明書失効リスト（CRL）のための基本プロファイルを指定します。
The reader is assumed to have familiarity with [RFC5280]. This Suite B Certificate and CRL Profile is a profile of RFC 5280. All MUST-level requirements of RFC 5280 apply throughout this profile and are generally not repeated here. In cases where a MUST-level requirement is repeated for emphasis, the text notes the requirement is "in adherence with [RFC5280]". This profile contains changes that elevate some MAY-level options in RFC 5280 to SHOULD-level and MUST-level in this profile; this profile also contains changes that elevate some SHOULD-level options in RFC 5280 to MUST-level for this profile. All options from RFC 5280 that are not listed in this profile remain at the requirement level of RFC 5280.
読者は、[RFC5280]に精通しているものとします。このスイートB証明書とCRLプロファイルは、RFC 5280のすべてのMUSTレベルの要件は、このプロファイルを通して適用し、一般的にここでは繰り返さないRFC 5280のプロファイルです。 MUSTレベルの要件を強調するために繰り返される場合には、テキストは、要件は「[RFC5280]との密着性に」あるノート。このプロファイルはSHOULDレベルにRFC 5280でいくつかのMAYレベルのオプションを高め、このプロファイルでMUSTレベルの変更が含まれています。このプロファイルは、このプロファイルのMUSTレベルにRFC 5280でいくつかのSHOULDレベルのオプションを高める変更が含まれています。このプロファイルに記載されていないRFC 5280からのすべてのオプションは、RFC 5280の要求レベルのままです。
The reader is also assumed to have familiarity with [RFC5480], which specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography and [RFC5758], which specifies algorithm identifiers for Elliptic Curve Digital Signature Algorithm (ECDSA).
読者はまた、ECDSA（楕円曲線デジタル署名アルゴリズムのためのアルゴリズム識別子を指定する楕円曲線暗号と[RFC5758]をサポートする証明書のサブジェクト公開鍵情報フィールドの構文とセマンティクスを指定し、[RFC5480]、に精通しているものとします）。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The goal of this document is to define a base set of certificate and CRL formats to support interoperability among Suite B solutions. Specific communities, such as the US National Security Systems, may define community profiles that further restrict certificate and CRL formats by mandating the presence of extensions that are optional in this base profile, defining new optional or critical extension types, or restricting the values and/or presence of fields within existing extensions. However, communications between distinct communities MUST use the formats specified in this document when interoperability is desired. (Applications may add additional non-critical extensions to these formats but they MUST NOT assume that a remote peer will be able to process them.)
このドキュメントの目標は、スイートB・ソリューション間の相互運用性をサポートするために、証明書とCRLの形式の基本セットを定義することです。例えば、米国国家安全保障システムのような特定のコミュニティには、さらに値を、この基本プロファイルのオプションである拡張の存在を義務付ける新しいオプションまたは重要な拡張タイプを定義する、または制限することにより、証明書とCRLの形式を制限するコミュニティプロファイルを定義することができ、および/または既存の拡張内のフィールドが存在します。相互運用性が望まれる場合しかし、異なるコミュニティ間の通信は、この文書で指定されたフォーマットを使用しなければなりません。 （アプリケーションは、これらのフォーマットに追加の非クリティカルな拡張を追加することが、彼らは、リモートピアがそれらを処理することができるようになりますと仮定してはいけません。）
Every Suite B certificate MUST use the X.509 v3 format, and contain either:
すべてのスイートBの証明書は、X.509 v3の形式を使用して、どちらか含まれている必要があります
* An ECDSA-capable signing key, using curve P-256 or P-384; or
* ECDSA可能な署名鍵を用いて曲線P-256またはP-384。または
* An ECDH-capable (Elliptic Curve Diffie-Hellman) key establishment key, using curve P-256 or P-384.
* ECDH対応（楕円曲線ディフィ - ヘルマン）鍵確立鍵を用いて曲線P-256またはP-384。
Every Suite B certificate and CRL MUST be signed using ECDSA. The signing Certification Authority's (CA's) key MUST be on the curve P-256 or P-384 if the certificate contains a key on the curve P-256. If the certificate contains a key on the curve P-384, the signing CA's key MUST be on the curve P-384. Any certificate and CRL MUST be hashed using SHA-256 or SHA-384, matched to the size of the signing CA's key.
すべてのスイートB証明書とCRLは、ECDSAを使用して署名する必要があります。証明書は、曲線P-256上のキーが含まれている場合、署名認証局の（CAの）キーは、曲線P-256またはP-384上にある必要があります。証明書は、曲線P-384上のキーが含まれている場合は、署名CAのキーは、曲線P-384上にある必要があります。任意の証明書とCRLは署名CAのキーの大きさに合わせた、SHA-256またはSHA-384を使用してハッシュされなければなりません。
The primary OID structure for Suite B is as follows per [X9.62], [SEC2], [RFC5480], and [RFC5758].
[SEC2]、[RFC5480]及び[RFC5758]、[X9.62]あたり、以下のようにスイートBのプライマリOID構造です。
ansi-X9-62 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) 10045 }
certicom-arc OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) }
id-ecPublicKey OBJECT IDENTIFIER ::= {
ansi-X9-62 keyType(2) 1 }
secp256r1 OBJECT IDENTIFIER ::= {
ansi-X9-62 curves(3) prime(1) 7 }
secp384r1 OBJECT IDENTIFIER ::= {
certicom-arc curve(0) 34 }
id-ecSigType OBJECT IDENTIFIER ::= {
ansi-X9-62 signatures(4) }
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {
id-ecSigType ecdsa-with-SHA2(3) 2 }
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= {
id-ecSigType ecdsa-with-SHA2(3) 3 }
This Suite B certificate profile is a profile of [RFC5280]. The changes in the requirements from RFC 5280 are listed here. Note that RFC 5280 has varying mandates for marking extensions as critical or non-critical. This profile changes some of those mandates for extensions that are included in Suite B certificates.
このスイートBの証明書プロファイルは、[RFC5280]のプロファイルです。 RFC 5280からの要件の変更はここにリストされています。そのRFC 5280が重大または非クリティカルとして拡張をマークする義務を変化させた注意してください。このプロファイルは、スイートB証明書に含まれている拡張のため、これらの義務の一部を変更します。
The two algorithm identifiers used by Suite B are: 1.2.840.10045.4.3.2 for ecdsa-with-SHA256 and 1.2.840.10045.4.3.3 for ecdsa-with-SHA384, as described in [RFC5758] AND [X9.62].
スイートBによって使用される二つのアルゴリズム識別子は、次のとおりと-SHA256 ECDSA-およびECDSA-WITH-SHA384ため1.2.840.10045.4.3.3ため1.2.840.10045.4.3.2、[RFC5758]と[X9.62]に記載されているように。
The parameters MUST be absent as per [RFC5758].
パラメータは、[RFC5758]の通り存在してはなりません。
ECDSA digital signature generation is described in [FIPS186-3]. An ECDSA signature value is comprised of two unsigned integers, denoted as r and s. r and s MUST be represented as ASN.1 INTEGERs. If the high order bit of the unsigned integer is a 1, an octet with the value 0x00 MUST be prepended to the binary representation before encoding it as an ASN.1 INTEGER. Unsigned integers for the P-256 and P-384 curves can be a maximum of 32 and 48 bytes, respectively. Therefore, converting each r and s to an ASN.1 INTEGER will result in a maximum of 33 bytes for the P-256 curve and 49 bytes for the P-384 curve.
ECDSAデジタル署名生成は[FIPS186-3]に記載されています。 ECDSA署名値をrとsと示される2つの符号なし整数、から構成されています。 rおよびsはASN.1整数として表現されなければなりません。符号なし整数の上位ビットが1である場合、値0x00を持つオクテットはASN.1のINTEGERとしてコード前バイナリ表現の先頭に付加されなければなりません。 P-256およびP-384曲線のための符号なし整数は、それぞれ、32および48バイトの最大値とすることができます。したがって、ASN.1整数にそれぞれRおよびSを変換するP-256曲線の33バイト、P-384曲線の49バイトの最大になります。
The ECDSA signatureValue in an X.509 certificate is encoded as a BIT STRING value of a DER-encoded SEQUENCE of the two INTEGERS. As per [RFC5480], the structure, included for convenience, is as follows:
X.509証明書におけるECDSA signatureValueは二つの整数のDER符号化されたシーケンスのビット列の値として符号化されます。次のように[RFC5480]に従って、便宜のために含まれる構造は、次のとおりです。
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
For example, in a signature using P-256 and hex notation:
例えば、P-256と16進表記を使用して署名で：
r= 52e3f7b7 27fba9e8 eddb1d08 3b75c188 2517e6dc 63ded9c0 524f8f9a 45dc8661
R = 52e3f7b7 27fba9e8 eddb1d08 3b75c188 2517e6dc 63ded9c0 524f8f9a 45dc8661
s= b8930438 de8d33bd ab12c3a2 bdad9795 92a1fd65 76d1734c 3eb0af34 0456aef4
S = b8930438 de8d33bd ab12c3a2 bdad9795 92a1fd65 76d1734c 3eb0af34 0456aef4
r represented as a DER-encoded INTEGER: 022052e3 f7b727fb a9e8eddb 1d083b75 c1882517 e6dc63de d9c0524f 8f9a45dc 8661
DER符号化された整数として表されるR：022052e3 f7b727fb a9e8eddb 1d083b75 c1882517 e6dc63de d9c0524f 8f9a45dc 8661
s represented as a DER-encoded INTEGER: 022100b8 930438de 8d33bdab 12c3a2bd ad979592 a1fd6576 d1734c3e b0af3404 56aef4
DER符号化された整数として表される（S）022100b8 930438de 8d33bdab 12c3a2bd ad979592 a1fd6576 d1734c3e b0af3404 56aef4
Representation of SEQUENCE of r and s: 30450220 52e3f7b7 27fba9e8 eddb1d08 3b75c188 2517e6dc 63ded9c0 524f8f9a 45dc8661 022100b8 930438de 8d33bdab 12c3a2bd ad979592 a1fd6576 d1734c3e b0af3404 56aef4
RとSのSEQUENCEの表現：30450220 52e3f7b7 27fba9e8 eddb1d08 3b75c188 2517e6dc 63ded9c0 524f8f9a 45dc8661 022100b8 930438de 8d33bdab 12c3a2bd ad979592 a1fd6576 d1734c3e b0af3404 56aef4
Representation of resulting signatureValue: 03480030 45022052 e3f7b727 fba9e8ed db1d083b 75c18825 17e6dc63 ded9c052 4f8f9a45 dc866102 2100b893 0438de8d 33bdab12 c3a2bdad 979592a1 fd6576d1 734c3eb0 af340456 aef4
その結果signatureValueの表現：03480030 45022052 e3f7b727 fba9e8ed db1d083b 75c18825 17e6dc63 ded9c052 4f8f9a45 dc866102 2100b893 0438de8d 33bdab12 c3a2bdad 979592a1 fd6576d1 734c3eb0 af340456 aef4
For this profile, Version MUST be 3, which means the value MUST be set to 2.
このプロファイルのために、バージョンの値が2に設定する必要があることを意味しており、3でなければなりません。
For ECDSA signing keys and ECDH key agreement keys, the algorithm ID, id-ecPublicKey, MUST be used.
ECDSA署名鍵およびECDH鍵共有鍵、アルゴリズムID、ID-ecPublicKeyために、使用しなければなりません。
The parameters of the AlgorithmIdentifier in this field MUST use the namedCurve option. The specifiedCurve and implicitCurve options described in [RFC5480] MUST NOT be used. The namedCurve MUST be either the OID for secp256r1 (curve P-256) or secp384r1 (curve P-384) [RFC5480].
この分野でのAlgorithmIdentifierのパラメータはnamedCurveオプションを使用する必要があります。 [RFC5480]で説明specifiedCurveとimplicitCurveオプションを使用してはいけません。 namedCurveはsecp256r1（曲線P-256）またはsecp384r1（曲線P-384）[RFC5480]のためのOIDのいずれかでなければなりません。
The elliptic curve public key, ECPoint, SHALL be the OCTET STRING representation of an elliptic curve point following the conversion routine in section 2.2 of [RFC5480] and sections 2.3.1 and 2.3.2 of [SEC1].
楕円曲線公開鍵、ECPointは、[RFC5480]のセクション2.2およびセクション2.3.1および[SEC1]の2.3.2に変換ルーチン次の楕円曲線点のOCTET STRINGを表現しなければなりません。
Suite B implementations MAY use either the uncompressed form or the compressed form of the elliptic curve point [RFC5480]. For interoperability purposes, all relying parties MUST be prepared to process the uncompressed form.
スイートBの実装は、非圧縮形式又は楕円曲線点[RFC5480]の圧縮形式も使用することができます。相互運用性のために、すべての信頼者は、非圧縮形式を処理するために準備しなければなりません。
The elliptic curve public key (an ECPoint that is an OCTET STRING) is mapped to a subjectPublicKey (a BIT STRING) as follows: the most significant bit of the OCTET STRING becomes the most significant bit of the BIT STRING and the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING [RFC5480].
オクテット文字列の最上位ビットはビット列の最下位ビットの最上位ビットとなる次のように楕円曲線公開鍵（オクテット列であるECPointは）のsubjectPublicKey（ビット列）にマップされオクテット文字列は、ビット列[RFC5480]の最下位ビットとなります。
An octet string representation of a P-256 uncompressed elliptic curve point:
P-256の非圧縮楕円曲線点のオクテット文字列表現。
046cc93a 2cdb0308 47fa0734 2bc8e130 4c77f04f 63557372 43f3a5d7 f51baa82 23d21ebf b87d9944 f7ec170d 64f9924e 9ce20e4d 361c2db5 f1d52257 4259edad 5e
046cc93a 2cdb0308 47fa0734 2bc8e130 4c77f04f 63557372 43f3a5d7 f51baa82 23d21ebf b87d9944 f7ec170d 64f9924e 9ce20e4d 361c2db5 f1d52257 4259edad 5E
A DER-encoded bit string representation of the subject public key:
サブジェクト公開鍵のDER符号化されたビット列表現：
03420004 6cc93a2c db030847 fa07342b c8e1304c 77f04f63 55737243 f3a5d7f5 1baa8223 d21ebfb8 7d9944f7 ec170d64 f9924e9c e20e4d36 1c2db5f1 d5225742 59edad5e
03420004 6cc93a2c db030847 fa07342b c8e1304c 77f04f63 55737243 f3a5d7f5 1baa8223 d21ebfb8 7d9944f7 ec170d64 f9924e9c e20e4d36 1c2db5f1 d5225742 59edad5e
A DER-encoded representation of the AlgorithmIdentifier:
AlgorithmIdentifierのDER符号化された表現。
30130607 2a8648ce 3d020106 082a8648 ce3d0301 07
30130607 2a8648ce 3d020106 082a8648 ce3d0301 07
A DER-encoded representation of the subjectPublicKeyInfo using the P-256 curve:
P-256曲線を用いSubjectPublicKeyInfoでのDER符号化された表現。
30593013 06072a86 48ce3d02 0106082a 8648ce3d 03010703 4200046c c93a2cdb 030847fa 07342bc8 e1304c77 f04f6355 737243f3 a5d7f51b aa8223d2 1ebfb87d 9944f7ec 170d64f9 924e9ce2 0e4d361c 2db5f1d5 22574259 edad5e
30593013 06072a86 48ce3d02 0106082a 8648ce3d 03010703 4200046c c93a2cdb 030847fa 07342bc8 e1304c77 f04f6355 737243f3 a5d7f51b aa8223d2 1ebfb87d 9944f7ec 170d64f9 924e9ce2 0e4d361c 2db5f1d5 22574259 edad5e
Different types of certificates in this profile have different required and recommended extensions. Those are listed in this section. Those extensions from RFC 5280 not explicitly listed in this profile remain at the requirement levels of RFC 5280.
このプロファイルでは、証明書の種類によって異なり、必要と推奨の拡張子を持っています。これらは、このセクションに記載されています。明示的にこのプロファイルに記載されていないRFC 5280からこれらの拡張機能は、RFC 5280の要求水準にとどまります。
In adherence with [RFC5280], self-signed CA certificates in this profile MUST contain the subjectKeyIdentifier, keyUsage, and basicConstraints extensions.
密着性にこのプロファイルに[RFC5280]、自己署名されたCA証明書はsubjectKeyIdentifier、のkeyUsage、及びbasicConstraintsの拡張を含まなければなりません。
The keyUsage extension MUST be marked as critical. The keyCertSign and cRLSign bits MUST be set. The digitalSignature and nonRepudiation bits MAY be set. All other bits MUST NOT be set.
keyUsageの拡張は、クリティカルとしてマークする必要があります。 KeyCertSignが及びcRLSignビットを設定しなければなりません。デジタル署名と否認防止ビットが設定されるかもしれません。他のすべてのビットを設定してはいけません。
In adherence with [RFC5280], the basicConstraints extension MUST be marked as critical. The cA boolean MUST be set to indicate that the subject is a CA and the pathLenConstraint MUST NOT be present.
[RFC5280]との密着性において、basicConstraintsの拡張は、クリティカルとしてマークされなければなりません。カリフォルニアブール値は、対象者がCAで、pathLenConstraintが存在してはならないことを示すために設定しなければなりません。
Non-self-signed CA Certificates in this profile MUST contain the authorityKeyIdentifier, keyUsage, and basicConstraints extensions. If there is a policy to be asserted, then the certificatePolicies extension MUST be included.
このプロファイルでは非自己署名CA証明書のauthorityKeyIdentifier、keyUsageの、およびbasicConstraintsの拡張を含まなければなりません。アサートされるポリシーがある場合には、certificatePolicies拡張を含まなければなりません。
The keyUsage extension MUST be marked as critical. The keyCertSign and CRLSign bits MUST be set. The digitalSignature and nonRepudiation bits MAY be set. All other bits MUST NOT be set.
keyUsageの拡張は、クリティカルとしてマークする必要があります。 KeyCertSignが及びCRLSignビットを設定しなければなりません。デジタル署名と否認防止ビットが設定されるかもしれません。他のすべてのビットを設定してはいけません。
In adherence with [RFC5280], the basicConstraints extension MUST be marked as critical. The cA boolean MUST be set to indicate that the subject is a CA and the pathLenConstraint subfield is OPTIONAL.
[RFC5280]との密着性において、basicConstraintsの拡張は、クリティカルとしてマークされなければなりません。カリフォルニアブール値は、被験者がCAであり、pathLenConstraintサブフィールドがオプションであることを示すように設定されなければなりません。
If a policy is asserted, the certificatePolicies extension MUST be marked as non-critical, MUST contain the OIDs for the applicable certificate policies and SHOULD NOT use the policyQualifiers option. If a policy is not asserted, the certificatePolicies extension MUST be omitted.
ポリシーがアサートされている場合は、certificatePolicies拡張が非クリティカルとしてマークする必要があり、該当する証明書ポリシーのOIDを含まなければならないとpolicyQualifiersオプションを使用しないでください。方針が表明されていない場合は、certificatePolicies拡張を省略しなければなりません。
Relying party applications conforming to this profile MUST be prepared to process the policyMappings, policyConstraints, and inhibitAnyPolicy extensions, regardless of criticality, following the guidance in [RFC5280] when they appear in non-self-signed CA certificates.
このプロファイルに準拠する証明書利用者アプリケーションは、非自己署名CA証明書に表示されたときに、[RFC5280]のガイダンスを以下に関係なく、重要度の、policyMappings、PolicyConstraintsの、およびinhibitAnyPolicy拡張を処理するために準備しなければなりません。
In adherence with [RFC5280], end entity certificates in this profile MUST contain the authorityKeyIdentifier and keyUsage extensions. If there is a policy to be asserted, then the certificatePolicies extension MUST be included. End entity certificates SHOULD contain the subjectKeyIdentifier extension.
[RFC5280]との密着性に、このプロファイル内のエンドエンティティ証明書はauthorityKeyIdentifierとのkeyUsage拡張を含まなければなりません。アサートされるポリシーがある場合には、certificatePolicies拡張を含まなければなりません。エンドエンティティ証明書は、subjectKeyIdentifier拡張を含むべきです。
The keyUsage extension MUST be marked as critical.
keyUsageの拡張は、クリティカルとしてマークする必要があります。
For end entity digital signature certificates, the keyUsage extension MUST be set for digitalSignature. The nonRepudiation bit MAY be set. All other bits in the keyUsage extension MUST NOT be set.
エンドエンティティのデジタル署名証明書、keyUsage拡張子は、デジタル署名のために設定しなければなりません。否認防止ビットを設定することができます。 keyUsage拡張の他のすべてのビットを設定してはいけません。
For end entity key establishment certificates, the keyUsage extension MUST BE set for keyAgreement. The encipherOnly or decipherOnly bit MAY be set. All other bits in the keyUsage extension MUST NOT be set.
エンドエンティティ鍵確立証明書の場合は、keyUsageの拡張がするKeyAgreementのために設定する必要があります。 encipherOnlyまたはdecipherOnlyビットが設定されるかもしれません。 keyUsage拡張の他のすべてのビットを設定してはいけません。
If a policy is asserted, the certificatePolicies extension MUST be marked as non-critical, MUST contain the OIDs for the applicable certificate policies and SHOULD NOT use the policyQualifiers option. If a policy is not asserted, the certificatePolicies extension MUST be omitted.
ポリシーがアサートされている場合は、certificatePolicies拡張が非クリティカルとしてマークする必要があり、該当する証明書ポリシーのOIDを含まなければならないとpolicyQualifiersオプションを使用しないでください。方針が表明されていない場合は、certificatePolicies拡張を省略しなければなりません。
This Suite B CRL profile is a profile of [RFC5280]. There are changes in the requirements from [RFC5280] for the signatures on CRLs of this profile.
このスイートB CRLプロファイルは、[RFC5280]のプロファイルです。このプロファイルのCRLの上の署名のための[RFC5280]からの要件の変更があります。
The signatures on CRLs in this profile MUST follow the same rules from this profile that apply to signatures in the certificates, see section 4.
このプロファイル内のCRLの署名は、セクション4を参照して、証明書に署名に適用され、このプロファイルから同じ規則に従わなければなりません。
The security considerations in [RFC5280], [RFC5480], and [RFC5758] apply.
[RFC5280]、[RFC5480]、および[RFC5758]のセキュリティの考慮事項が適用されます。
A single key pair SHOULD NOT be used for both signature and key establishment per [SP-800-57].
単一の鍵ペアは、[SP-800-57]あたりの署名と鍵確立の両方のために使用すべきではありません。
The Suite B algorithms provide significantly improved performance when compared to equivalent-strength cryptography that does not employ elliptic curve cryptography. Where performance has previously been an impediment, use of Suite B may permit employment of PKI-based cryptographic security mechanisms.
楕円曲線暗号を使用しない同等の強度暗号と比較した場合、スイートBアルゴリズムは、大幅に改善された性能を提供します。パフォーマンスは以前に障害されている場合は、スイートBの使用は、PKIベースの暗号化セキュリティ・メカニズムの雇用を許可することができます。
This document makes extensive use of object identifiers to register public key types, elliptic curves, and algorithms. Most of them are registered in the ANSI X9.62 arc with the exception of some of the curves, which are in the Certicom, Inc. arc (these curves have been adopted by ANSI and NIST). Extensions in certificates and CRLs are identified using the object identifiers defined in an arc delegated by IANA to the PKIX working group. No further action by IANA is necessary for this document or any anticipated updates.
この文書は、公開鍵の種類、楕円曲線、およびアルゴリズムを登録するためのオブジェクト識別子を多用します。それらのほとんどは、Certicomの株式会社アークにあるカーブ、（これらの曲線は、ANSIおよびNISTによって採用されている）の一部を除いてANSI X9.62アークに登録されています。証明書とCRLに拡張はPKIXワーキンググループにIANAによって委任円弧で定義されたオブジェクト識別子を使用して同定されます。 IANAによってそれ以上のアクションは、この文書または任意の予想されるアップデートの必要はありません。
[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月。
[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月。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[RFC5480]ターナー、S.、ブラウン、D.、耀輝、K.、Housley氏、R.、およびT.ポーク、 "楕円曲線暗号件名公開鍵情報"、RFC 5480、2009年3月。
[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. Polk, "Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", RFC 5758, January 2010.
[RFC5758]ダン、Q.、Santesson、S.、モリアーティ、K.、ブラウン、D.、およびT.ポーク、 "インターネットX.509公開鍵インフラストラクチャ：DSAとECDSAのための追加のアルゴリズムと識別子"、RFC 5758、 2010年1月。
[FIPS186-3] "Digital Signature Standard (DSS)", June 2009.
[FIPS186-3] "デジタル署名標準（DSS）"、2009年6月。
[SEC1] Standards for Efficient Cryptography, "SEC1: Elliptic Curve Cryptography", September 2000.
[SEC1]効率的な暗号化のための標準化、 "SEC1：楕円曲線暗号"、2000年9月。
[SEC2] Standards for Efficient Cryptography, "SEC 2: Recommended Elliptic Curve Domain Parameters", September 2000.
[SEC2]効率的な暗号化のための標準化、「SEC 2：推奨楕円曲線ドメインパラメータ」、2000年9月。
[SP-800-57] Barker, E., Barker, W., Burr, W., Polk, W. Smid, M., "NIST SP-800-57:Recommendation for Key Management-Part 1: General", March 2007.
[SP-800-57]バーカー、E.、バーカー、W.、バリ、W.、ポーク、W. SMID、M.、 "NIST SP-800-57：キー管理-パート1のための推奨事項：一般"、 2007年3月。
[X9.62] ANS X9.62, "Public Key Cryptography for the Financial Services Industry; The Elliptic Curve Digital Signature Algorithm (ECDSA)", December 2005.
[X9.62] ANS X9.62、「金融サービス業界向けの公開鍵暗号、楕円曲線デジタル署名アルゴリズム（ECDSA）」、2005年12月。
[X9.63] ANS X9.63, "Public Key Cryptography for the Financial Services Industry; Key Agreement and Key Transport Using Elliptic Curve Cryptography", December 2001.
[X9.63] ANS X9.63、「金融サービス業のための公開鍵暗号、鍵協定と主要交通が楕円曲線暗号の使用」を、2001年12月。
Authors' Addresses
著者のアドレス
Jerome Solinas National Information Assurance Research Laboratory National Security Agency
ジェロームSolinas国家情報保証研究所国家安全保障局
EMail: jasolin@orion.ncsc.mil
メールアドレス：jasolin@orion.ncsc.mil
Lydia Zieglar National Information Assurance Research Laboratory National Security Agency
リディアチーグラー国家情報保証研究所国家安全保障局
EMail: llziegl@tycho.ncsc.mil
メールアドレス：llziegl@tycho.ncsc.mil