RFC5280 日本語訳
5280 Internet X.509 Public Key Infrastructure Certificate andCertificate Revocation List (CRL) Profile. D. Cooper, S. Santesson,S. Farrell, S. Boeyen, R. Housley, W. Polk. May 2008. (Format: TXT=352580 bytes) (Obsoletes RFC3280, RFC4325, RFC4630) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Cooper
Request for Comments: 5280 NIST
Obsoletes: 3280, 4325, 4630 S. Santesson
Category: Standards Track Microsoft
S. Farrell
Trinity College Dublin
S. Boeyen
Entrust
R. Housley
Vigil Security
W. Polk
NIST
May 2008
コメントを求めるワーキンググループD.桶屋要求をネットワークでつないでください: 5280NISTは以下を時代遅れにします。 4630秒間3280、4325、Santessonカテゴリ: 標準化過程マイクロソフトS.ファレルトリニティー・カレッジダブリンS.Boeyenは不寝番セキュリティW.ポークNIST2008年5月にR.Housleyをゆだねます。
Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile
インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)プロフィール
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices.
このメモはインターネットでの使用のために、X.509 v3証明書とX.509 v2証明書失効リスト(CRL)の輪郭を描きます。 序論としてこのアプローチとモデルの概要を提供します。 X.509 v3証明書形式はインターネット名前フォームの形式と意味論に関する追加情報で詳細に説明されます。標準の証明書拡張子は説明されます、そして、2つのインターネット特有の拡大が定義されます。 1セットの必要な証明書拡張子は指定されます。 X.509 v2 CRL形式は標準の、そして、インターネット特有の拡大と共に詳細に説明されます。 X.509証明経路合法化のためのアルゴリズムは説明されます。 ASN.1モジュールと例を付録に提供します。
Cooper, et al. Standards Track [Page 1] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[1ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
Table of Contents
目次
1. Introduction ....................................................4
2. Requirements and Assumptions ....................................6
2.1. Communication and Topology .................................7
2.2. Acceptability Criteria .....................................7
2.3. User Expectations ..........................................7
2.4. Administrator Expectations .................................8
3. Overview of Approach ............................................8
3.1. X.509 Version 3 Certificate ................................9
3.2. Certification Paths and Trust .............................10
3.3. Revocation ................................................13
3.4. Operational Protocols .....................................14
3.5. Management Protocols ......................................14
4. Certificate and Certificate Extensions Profile .................16
4.1. Basic Certificate Fields ..................................16
4.1.1. Certificate Fields .................................17
4.1.1.1. tbsCertificate ............................18
4.1.1.2. signatureAlgorithm ........................18
4.1.1.3. signatureValue ............................18
4.1.2. TBSCertificate .....................................18
4.1.2.1. Version ...................................19
4.1.2.2. Serial Number .............................19
4.1.2.3. Signature .................................19
4.1.2.4. Issuer ....................................20
4.1.2.5. Validity ..................................22
4.1.2.5.1. UTCTime ........................23
4.1.2.5.2. GeneralizedTime ................23
4.1.2.6. Subject ...................................23
4.1.2.7. Subject Public Key Info ...................25
4.1.2.8. Unique Identifiers ........................25
4.1.2.9. Extensions ................................26
4.2. Certificate Extensions ....................................26
4.2.1. Standard Extensions ................................27
4.2.1.1. Authority Key Identifier ..................27
4.2.1.2. Subject Key Identifier ....................28
4.2.1.3. Key Usage .................................29
4.2.1.4. Certificate Policies ......................32
4.2.1.5. Policy Mappings ...........................35
4.2.1.6. Subject Alternative Name ..................35
4.2.1.7. Issuer Alternative Name ...................38
4.2.1.8. Subject Directory Attributes ..............39
4.2.1.9. Basic Constraints .........................39
4.2.1.10. Name Constraints .........................40
4.2.1.11. Policy Constraints .......................43
4.2.1.12. Extended Key Usage .......................44
4.2.1.13. CRL Distribution Points ..................45
4.2.1.14. Inhibit anyPolicy ........................48
1. 序論…4 2. 要件と仮定…6 2.1. コミュニケーションとトポロジー…7 2.2. 受容性評価基準…7 2.3. ユーザ期待…7 2.4. 管理者期待…8 3. アプローチの概要…8 3.1. X.509バージョン3証明書…9 3.2. 証明経路と信頼…10 3.3. 取消し…13 3.4. 操作上のプロトコル…14 3.5. 管理プロトコル…14 4. 拡大プロフィールを証明して、証明してください…16 4.1. 基本的な証明書分野…16 4.1.1. 分野を証明してください…17 4.1.1.1tbsCertificate…18 4.1.1.2signatureAlgorithm…18 4.1.1.3signatureValue…18 4.1.2. TBSCertificate…18 4.1.2.1. バージョン…19 4.1.2.2. 通し番号…19 4.1.2.3. 署名…19 4.1.2.4. 発行人…20 4.1.2.5. 正当性…22 4.1.2.5.1. UTCTime…23 4.1.2.5.2. GeneralizedTime…23 4.1.2.6. かけます。23 4.1.2.7. 対象の公開鍵インフォメーション…25 4.1.2.8. ユニークな識別子…25 4.1.2.9. 拡大…26 4.2. 拡大を証明してください…26 4.2.1. 標準の拡大…27 4.2.1.1. 権威の主要な識別子…27 4.2.1.2. 対象の重要識別子…28 4.2.1.3. 主要な用法…29 4.2.1.4. 方針を証明してください…32 4.2.1.5. 方針マッピング…35 4.2.1.6. 対象の代替名…35 4.2.1.7. 発行人代替名…38 4.2.1.8. テーマ別ディレクトリ属性…39 4.2.1.9. 基本的な規制…39 4.2.1.10. 規制を命名してください…40 4.2.1.11. 方針規制…43 4.2.1.12. 主要な用法を広げています…44 4.2.1.13. CRL分配は指します…45 4.2.1.14. anyPolicyを禁止してください…48
Cooper, et al. Standards Track [Page 2] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[2ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
4.2.1.15. Freshest CRL (a.k.a. Delta CRL
Distribution Point) ......................48
4.2.2. Private Internet Extensions ........................49
4.2.2.1. Authority Information Access ..............49
4.2.2.2. Subject Information Access ................51
5. CRL and CRL Extensions Profile .................................54
5.1. CRL Fields ................................................55
5.1.1. CertificateList Fields .............................56
5.1.1.1. tbsCertList ...............................56
5.1.1.2. signatureAlgorithm ........................57
5.1.1.3. signatureValue ............................57
5.1.2. Certificate List "To Be Signed" ....................58
5.1.2.1. Version ...................................58
5.1.2.2. Signature .................................58
5.1.2.3. Issuer Name ...............................58
5.1.2.4. This Update ...............................58
5.1.2.5. Next Update ...............................59
5.1.2.6. Revoked Certificates ......................59
5.1.2.7. Extensions ................................60
5.2. CRL Extensions ............................................60
5.2.1. Authority Key Identifier ...........................60
5.2.2. Issuer Alternative Name ............................60
5.2.3. CRL Number .........................................61
5.2.4. Delta CRL Indicator ................................62
5.2.5. Issuing Distribution Point .........................65
5.2.6. Freshest CRL (a.k.a. Delta CRL Distribution
Point) .............................................67
5.2.7. Authority Information Access .......................67
5.3. CRL Entry Extensions ......................................69
5.3.1. Reason Code ........................................69
5.3.2. Invalidity Date ....................................70
5.3.3. Certificate Issuer .................................70
6. Certification Path Validation ..................................71
6.1. Basic Path Validation .....................................72
6.1.1. Inputs .............................................75
6.1.2. Initialization .....................................77
6.1.3. Basic Certificate Processing .......................80
6.1.4. Preparation for Certificate i+1 ....................84
6.1.5. Wrap-Up Procedure ..................................87
6.1.6. Outputs ............................................89
6.2. Using the Path Validation Algorithm .......................89
6.3. CRL Validation ............................................90
6.3.1. Revocation Inputs ..................................91
6.3.2. Initialization and Revocation State Variables ......91
6.3.3. CRL Processing .....................................92
7. Processing Rules for Internationalized Names ...................95
7.1. Internationalized Names in Distinguished Names ............96
7.2. Internationalized Domain Names in GeneralName .............97
4.2.1.15. 最も新鮮なCRL(通称デルタCRL分配ポイント)…48 4.2.2. 個人的なインターネット拡大…49 4.2.2.1. 権威情報アクセス…49 4.2.2.2. 対象の情報アクセス…51 5. CRLとCRL拡大プロフィール…54 5.1. CRL分野…55 5.1.1. CertificateList分野…56 5.1.1.1tbsCertList…56 5.1.1.2signatureAlgorithm…57 5.1.1.3signatureValue…57 5.1.2. 「署名される」リストを証明してください…58 5.1.2.1. バージョン…58 5.1.2.2. 署名…58 5.1.2.3. 発行人名…58 5.1.2.4. このアップデート…58 5.1.2.5. 次のアップデート…59 5.1.2.6. 証明書を取り消します…59 5.1.2.7. 拡大…60 5.2. CRL拡張子…60 5.2.1. 権威の主要な識別子…60 5.2.2. 発行人代替名…60 5.2.3. CRL番号…61 5.2.4. デルタCRLインディケータ…62 5.2.5. 分配を発行して、指してください…65 5.2.6. 最も新鮮なCRL(通称デルタCRL分配ポイント)…67 5.2.7. 権威情報アクセス…67 5.3. CRLエントリー拡張子…69 5.3.1. コードを推論してください…69 5.3.2. 無効日付…70 5.3.3. 発行人を証明してください…70 6. 証明経路合法化…71 6.1. 基本的な経路合法化…72 6.1.1. 入力します。75 6.1.2. 初期設定…77 6.1.3. 基本的な証明書処理…80 6.1.4. Certificate i+1のための準備…84 6.1.5. 結論手順…87 6.1.6. 出力…89 6.2. 経路合法化アルゴリズムを使用します…89 6.3. CRL合法化…90 6.3.1. 取消し入力…91 6.3.2. 初期設定と取消しは変数を述べます…91 6.3.3. CRL処理…92 7. 処理は国際化している名前のために統治されます…95 7.1. 分類名における名前を国際的にします…96 7.2. GeneralNameの国際化ドメイン名…97
Cooper, et al. Standards Track [Page 3] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[3ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
7.3. Internationalized Domain Names in Distinguished Names .....98
7.4. Internationalized Resource Identifiers ....................98
7.5. Internationalized Electronic Mail Addresses ..............100
8. Security Considerations .......................................100
9. IANA Considerations ...........................................105
10. Acknowledgments ..............................................105
11. References ...................................................105
11.1. Normative References ....................................105
11.2. Informative References ..................................107
Appendix A. Pseudo-ASN.1 Structures and OIDs ....................110
A.1. Explicitly Tagged Module, 1988 Syntax ....................110
A.2. Implicitly Tagged Module, 1988 Syntax ....................125
Appendix B. ASN.1 Notes ..........................................133
Appendix C. Examples .............................................136
C.1. RSA Self-Signed Certificate ..............................137
C.2. End Entity Certificate Using RSA .........................140
C.3. End Entity Certificate Using DSA .........................143
C.4. Certificate Revocation List ..............................147
7.3. 分類名における国際化ドメイン名…98 7.4. リソース識別子を国際的にします…98 7.5. 電子メールアドレスを国際的にします…100 8. セキュリティ問題…100 9. IANA問題…105 10. 承認…105 11. 参照…105 11.1. 標準の参照…105 11.2. 有益な参照…107 付録A.の疑似ASN.1の構造とOIDs…110 A.1。 明らかにタグ付けををされたモジュール、1988年の構文…110 A.2。 それとなくタグ付けををされたモジュール、1988年の構文…125 付録B.ASN.1注意…133 付録C.の例…136 C.1。 RSA自己署名入りの証書…137 C.2。 RSAを使用して、実体証明書を終わらせてください…140 C.3。 DSAを使用して、実体証明書を終わらせてください…143 C.4。 取消しリストを証明してください…147
1. Introduction
1. 序論
This specification is one part of a family of standards for the X.509 Public Key Infrastructure (PKI) for the Internet.
この仕様はインターネットへのX.509公開鍵暗号基盤(PKI)の規格のファミリーの一部です。
This specification profiles the format and semantics of certificates and certificate revocation lists (CRLs) for the Internet PKI. Procedures are described for processing of certification paths in the Internet environment. Finally, ASN.1 modules are provided in the appendices for all data structures defined or referenced.
この仕様は証明書と証明書失効リスト(CRLs)の形式と意味論のインターネットPKIに輪郭を描きます。 手順はインターネット環境における、証明経路の処理のために説明されます。 最終的に、データ構造が定義したか、または参照をつけたすべてのためにASN.1モジュールを付録に提供します。
Section 2 describes Internet PKI requirements and the assumptions that affect the scope of this document. Section 3 presents an architectural model and describes its relationship to previous IETF and ISO/IEC/ITU-T standards. In particular, this document's relationship with the IETF PEM specifications and the ISO/IEC/ITU-T X.509 documents is described.
セクション2はこのドキュメントの範囲に影響するインターネットPKI要件と仮定について説明します。 セクション3は、前のIETFとITU ISO/IEC/T規格に建築モデルを提示して、関係について説明します。 特に、IETF PEM仕様とITU ISO/IEC/T X.509ドキュメントとのこのドキュメントの関係は説明されます。
Section 4 profiles the X.509 version 3 certificate, and Section 5 profiles the X.509 version 2 CRL. The profiles include the identification of ISO/IEC/ITU-T and ANSI extensions that may be useful in the Internet PKI. The profiles are presented in the 1988 Abstract Syntax Notation One (ASN.1) rather than the 1997 ASN.1 syntax used in the most recent ISO/IEC/ITU-T standards.
セクション4はX.509バージョン3証明書の輪郭を描きます、そして、セクション5はX.509バージョン2CRLの輪郭を描きます。 プロフィールはITU ISO/IEC/TとインターネットPKIで役に立つかもしれないANSI拡張子の識別を含んでいます。 プロフィールは最新のITU ISO/IEC/T規格に使用される1997ASN.1構文よりむしろ1988の抽象的なSyntax Notation One(ASN.1)に提示されます。
Section 6 includes certification path validation procedures. These procedures are based upon the ISO/IEC/ITU-T definition. Implementations are REQUIRED to derive the same results but are not required to use the specified procedures.
セクション6は証明経路合法化手順を含めます。 これらの手順はITU ISO/IEC/T定義に基づいています。 実装は、同じ結果を引き出すREQUIREDですが、指定された手順を用いるのに必要ではありません。
Cooper, et al. Standards Track [Page 4] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[4ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
Procedures for identification and encoding of public key materials and digital signatures are defined in [RFC3279], [RFC4055], and [RFC4491]. Implementations of this specification are not required to use any particular cryptographic algorithms. However, conforming implementations that use the algorithms identified in [RFC3279], [RFC4055], and [RFC4491] MUST identify and encode the public key materials and digital signatures as described in those specifications.
公開鍵の材料とデジタル署名の識別とコード化のための手順は[RFC3279]、[RFC4055]、および[RFC4491]で定義されます。 この仕様の実装は、どんな特定の暗号アルゴリズムも使用するのに必要ではありません。しかしながら、[RFC3279]、[RFC4055]、および[RFC4491]で特定されたアルゴリズムを使用する実装を従わせるのは、それらの仕様で説明されるように公開鍵の材料とデジタル署名を特定して、コード化しなければなりません。
Finally, three appendices are provided to aid implementers. Appendix A contains all ASN.1 structures defined or referenced within this specification. As above, the material is presented in the 1988 ASN.1. Appendix B contains notes on less familiar features of the ASN.1 notation used within this specification. Appendix C contains examples of conforming certificates and a conforming CRL.
最終的に、implementersを支援するために3個の付録を提供します。 付録Aはこの仕様の中で定義されたか、または参照をつけられたすべてのASN.1構造を含んでいます。 同じくらい上では、1988ASN.1で材料を寄贈します。 付録Bはこの仕様の中で使用されたASN.1記法のそれほど身近でない特徴に関する注を含んでいます。 付録Cは証明書と従うCRLを従わせる例を含んでいます。
This specification obsoletes [RFC3280]. Differences from RFC 3280 are summarized below:
この仕様は[RFC3280]を時代遅れにします。 RFC3280からの違いは以下へまとめられます:
* Enhanced support for internationalized names is specified in
Section 7, with rules for encoding and comparing
Internationalized Domain Names, Internationalized Resource
Identifiers (IRIs), and distinguished names. These rules are
aligned with comparison rules established in current RFCs,
including [RFC3490], [RFC3987], and [RFC4518].
* 国際化している名前の高められたサポートはセクション7で指定されます、Internationalized Domain Names、Internationalized Resource Identifiers(IRIs)、および分類名をコード化して、比較するための規則で。 これらの規則は[RFC3490]を含む現在のRFCs[RFC3987]、および[RFC4518]に確立された比較規則に並べられます。
* Sections 4.1.2.4 and 4.1.2.6 incorporate the conditions for
continued use of legacy text encoding schemes that were
specified in [RFC4630]. Where in use by an established PKI,
transition to UTF8String could cause denial of service based on
name chaining failures or incorrect processing of name
constraints.
* そして、セクション4.1 .2 .4、4.1 .2 .6は[RFC4630]で指定されたレガシーテキストコード化体系の継続的な使用のための状態を取り入れます。 確立したPKIで使用中であるところでは、UTF8Stringへの変遷が名前推論失敗に基づくサービスの否定か名前規制の不正確な処理を引き起こす場合がありました。
* Section 4.2.1.4 in RFC 3280, which specified the
privateKeyUsagePeriod certificate extension but deprecated its
use, was removed. Use of this ISO standard extension is neither
deprecated nor recommended for use in the Internet PKI.
* セクション4.2 .1 privateKeyUsagePeriod証明書拡張子にもかかわらず、推奨しない状態で指定したRFC3280の.4、使用、取り除きました。 インターネットPKIでの使用に、このISOの標準の拡張子の使用は、推奨しなくなくて、またお勧めではありません。
* Section 4.2.1.5 recommends marking the policy mappings extension
as critical. RFC 3280 required that the policy mappings
extension be marked as non-critical.
* セクション4.2 .1 .5 重要であるとして方針マッピングが拡大であるとマークすることを勧めます。 RFC3280は、方針マッピング拡張子が非臨界であるとしてマークされるのを必要としました。
* Section 4.2.1.11 requires marking the policy constraints
extension as critical. RFC 3280 permitted the policy
constraints extension to be marked as critical or non-critical.
* セクション4.2 .1 .11 重要であるとして方針規制が拡大であるとマークするのが必要です。 RFC3280は、方針規制拡大が重要であるか非臨界であるとしてマークされるのを可能にしました。
* The Authority Information Access (AIA) CRL extension, as
specified in [RFC4325], was added as Section 5.2.7.
* [RFC4325]で指定されるAuthority情報Access(AIA)CRL拡張子はセクション5.2.7として加えられました。
Cooper, et al. Standards Track [Page 5] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[5ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
* Sections 5.2 and 5.3 clarify the rules for handling unrecognized
CRL extensions and CRL entry extensions, respectively.
* セクション5.2と5.3はそれぞれ認識されていないCRL拡張子とCRLエントリー拡張子を扱うための規則をはっきりさせます。
* Section 5.3.2 in RFC 3280, which specified the
holdInstructionCode CRL entry extension, was removed.
* RFC3280のセクション5.3.2を取り除きました。(RFCはholdInstructionCode CRLエントリー拡張子を指定しました)。
* The path validation algorithm specified in Section 6 no longer
tracks the criticality of the certificate policies extensions in
a chain of certificates. In RFC 3280, this information was
returned to a relying party.
* セクション6で指定された経路合法化アルゴリズムはもう証明書のチェーンで証明書方針拡張子の臨界を追跡しません。 RFC3280では、この情報を信用パーティーに返しました。
* The Security Considerations section addresses the risk of
circular dependencies arising from the use of https or similar
schemes in the CRL distribution points, authority information
access, or subject information access extensions.
* Security Considerations部はhttpsの使用から起こる円形の依存のリスクかCRL分配ポイント、権威情報アクセス、または対象の情報アクセス拡張子における同様の体系を扱います。
* The Security Considerations section addresses risks associated
with name ambiguity.
* Security Considerations部は名前のあいまいさに関連している危険を扱います。
* The Security Considerations section references RFC 4210 for
procedures to signal changes in CA operations.
* カリフォルニアの操作におけるシグナル変化への手順のSecurity Considerationsセクション参照RFC4210。
The ASN.1 modules in Appendix A are unchanged from RFC 3280, except that ub-emailaddress-length was changed from 128 to 255 in order to align with PKCS #9 [RFC2985].
Appendix AのASN.1モジュールはRFC3280から変わりがありません、ub-emailaddress-長さがPKCS#9[RFC2985]に並ぶために128〜255に変わったのを除いて。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Requirements and Assumptions
2. 要件と仮定
The goal of this specification is to develop a profile to facilitate the use of X.509 certificates within Internet applications for those communities wishing to make use of X.509 technology. Such applications may include WWW, electronic mail, user authentication, and IPsec. In order to relieve some of the obstacles to using X.509 certificates, this document defines a profile to promote the development of certificate management systems, development of application tools, and interoperability determined by policy.
この仕様の目標はX.509技術を利用したがっているそれらの共同体のためのインターネットアプリケーションの中のX.509証明書の使用を容易にするためにプロフィールを開発することです。 そのようなアプリケーションはWWW、電子メール、ユーザー認証、およびIPsecを含むかもしれません。 このドキュメントがX.509証明書を使用するのに障害のいくつかを救うために促進するプロフィールを定義する、証明書マネージメントシステムの開発、アプリケーションツールの開発、および方針によって決定している相互運用性。
Some communities will need to supplement, or possibly replace, this profile in order to meet the requirements of specialized application domains or environments with additional authorization, assurance, or operational requirements. However, for basic applications, common representations of frequently used attributes are defined so that
いくつかの共同体が、専門化しているアプリケーションドメインに関する必要条件か追加承認、保証、または操作上の要件がある環境を満たすのにこのプロフィールを補うか、またはことによると置き換える必要があるでしょう。 しかしながら、頻繁に使用された属性の共通表現が基本出願のための、定義されたそう、それ
Cooper, et al. Standards Track [Page 6] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[6ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
application developers can obtain necessary information without regard to the issuer of a particular certificate or certificate revocation list (CRL).
アプリケーション開発者は関係なしで特定の証明書か証明書失効リスト(CRL)の発行人に必要事項を得ることができます。
A certificate user should review the certificate policy generated by the certification authority (CA) before relying on the authentication or non-repudiation services associated with the public key in a particular certificate. To this end, this standard does not prescribe legally binding rules or duties.
証明書ユーザは認証に依存する前に証明権威(カリフォルニア)によって生成された証明書方針か特定の証明書の公開鍵に関連している非拒否サービスを見直すべきです。 このために、この規格は法的に拘束力がある規則か義務を定めません。
As supplemental authorization and attribute management tools emerge, such as attribute certificates, it may be appropriate to limit the authenticated attributes that are included in a certificate. These other management tools may provide more appropriate methods of conveying many authenticated attributes.
補足の承認と属性管理ツールが属性証明書などのように現れるとき、証明書に含まれている認証された属性を制限するのは適切であるかもしれません。 これらの他の管理ツールは多くの認証された属性を伝えるより適切なメソッドを提供するかもしれません。
2.1. Communication and Topology
2.1. コミュニケーションとトポロジー
The users of certificates will operate in a wide range of environments with respect to their communication topology, especially users of secure electronic mail. This profile supports users without high bandwidth, real-time IP connectivity, or high connection availability. In addition, the profile allows for the presence of firewall or other filtered communication.
証明書のユーザはそれらのコミュニケーショントポロジー(特に安全な電子メールのユーザ)に関してさまざまな環境で働くでしょう。 このプロフィールは高帯域も、リアルタイムのIPの接続性も、または高い接続の有用性なしでユーザをサポートします。 さらに、プロフィールは何らかのファイアウォールの存在のためにフィルターにかけることのコミュニケーションを許容します。
This profile does not assume the deployment of an X.500 directory system [X.500] or a Lightweight Directory Access Protocol (LDAP) directory system [RFC4510]. The profile does not prohibit the use of an X.500 directory or an LDAP directory; however, any means of distributing certificates and certificate revocation lists (CRLs) may be used.
このプロフィールは、X.500の展開がディレクトリシステム[X.500]かライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)ディレクトリシステム[RFC4510]であると仮定しません。 プロフィールはX.500ディレクトリかLDAPディレクトリの使用を禁止しません。 しかしながら、証明書と証明書失効リスト(CRLs)を配布するどんな手段も使用されるかもしれません。
2.2. Acceptability Criteria
2.2. ロット判定基準
The goal of the Internet Public Key Infrastructure (PKI) is to meet the needs of deterministic, automated identification, authentication, access control, and authorization functions. Support for these services determines the attributes contained in the certificate as well as the ancillary control information in the certificate such as policy data and certification path constraints.
インターネット公開鍵暗号基盤(PKI)の目標は決定論的で、自動化された識別、認証、アクセスコントロール、および承認機能の需要を満たすことです。 これらのサービスのサポートは付属の制御情報と同様に証明書の方針データなどの証明書に含まれた属性と証明経路規制を決定します。
2.3. User Expectations
2.3. ユーザ期待
Users of the Internet PKI are people and processes who use client software and are the subjects named in certificates. These uses include readers and writers of electronic mail, the clients for WWW browsers, WWW servers, and the key manager for IPsec within a router. This profile recognizes the limitations of the platforms these users
インターネットPKIのユーザは、クライアントソフトウェアを使用する人々とプロセスであり、証明書で指定された対象です。 これらの用途はルータの中にIPsecの電子メールの読者と作家、WWWブラウザのためのクライアント、WWWサーバ、および主要なマネージャを含んでいます。 このプロフィールがプラットホームの制限を認識する、これらのユーザ
Cooper, et al. Standards Track [Page 7] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[7ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
employ and the limitations in sophistication and attentiveness of the users themselves. This manifests itself in minimal user configuration responsibility (e.g., trusted CA keys, rules), explicit platform usage constraints within the certificate, certification path constraints that shield the user from many malicious actions, and applications that sensibly automate validation functions.
ユーザ自身の洗練と注意深さにおける雇用と制限。 これは最小量のユーザ構成責任(例えば、カリフォルニアキー、規則を信じる)、証明書、多くの悪意がある行為からユーザを保護する証明経路規制、および分別よく合法化機能を自動化するアプリケーションの中の明白なプラットホーム用法規制で現れます。
2.4. Administrator Expectations
2.4. 管理者期待
As with user expectations, the Internet PKI profile is structured to support the individuals who generally operate CAs. Providing administrators with unbounded choices increases the chances that a subtle CA administrator mistake will result in broad compromise. Also, unbounded choices greatly complicate the software that process and validate the certificates created by the CA.
ユーザ期待のように、インターネットPKIプロフィールは、一般に、CAsを運用する個人をサポートするために構造化されます。 限りない選択を管理者に提供すると、微妙なカリフォルニア管理者誤りが広い感染をもたらすという可能性は増強されます。 また、限りない選択はカリフォルニアによって作成された証明書を処理して、有効にするソフトウェアを大いに複雑にします。
3. Overview of Approach
3. アプローチの概要
Following is a simplified view of the architectural model assumed by the Public-Key Infrastructure using X.509 (PKIX) specifications.
以下に、X.509(PKIX)仕様を使用することで公開鍵暗号基盤によって思われた建築モデルの簡易型の視点があります。
The components in this model are:
このモデルのコンポーネントは以下の通りです。
end entity: user of PKI certificates and/or end user system that is
the subject of a certificate;
実体を終わらせてください: 証明書の対象であるPKI証明書、そして/または、エンドユーザシステムのユーザ。
CA: certification authority;
カリフォルニア: 証明権威。
RA: registration authority, i.e., an optional system to which
a CA delegates certain management functions;
RA: すなわち、登録局、カリフォルニアが、ある管理機能を代表として派遣する任意のシステム。
CRL issuer: a system that generates and signs CRLs; and
CRL発行人: CRLsを生成して、署名するシステム。 そして
repository: a system or collection of distributed systems that stores
certificates and CRLs and serves as a means of
distributing these certificates and CRLs to end entities.
倉庫: 証明書とCRLsを保存して、実体を終わらせるこれらの証明書とCRLsを配布する手段として機能する分散システムのシステムか収集。
CAs are responsible for indicating the revocation status of the certificates that they issue. Revocation status information may be provided using the Online Certificate Status Protocol (OCSP) [RFC2560], certificate revocation lists (CRLs), or some other mechanism. In general, when revocation status information is provided using CRLs, the CA is also the CRL issuer. However, a CA may delegate the responsibility for issuing CRLs to a different entity.
CAsはそれらが発行する証明書の取消し状態を示すのに責任があります。 Online Certificate Statusプロトコル(OCSP)[RFC2560]、証明書失効リスト(CRLs)、またはある他のメカニズムを使用することで取消し状態情報を提供するかもしれません。 一般に、CRLsを使用することで取消し状態情報を提供するとき、また、カリフォルニアはCRL発行人です。 しかしながら、カリフォルニアは異なった実体にCRLsを発行することへの責任を代表として派遣するかもしれません。
Note that an Attribute Authority (AA) might also choose to delegate the publication of CRLs to a CRL issuer.
また、Attribute Authority(AA)が、CRLsの公表をCRL発行人へ代表として派遣するのを選ぶかもしれないことに注意してください。
Cooper, et al. Standards Track [Page 8] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[8ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
+---+ | C | +------------+ | e | <-------------------->| End entity | | r | Operational +------------+ | t | transactions ^ | i | and management | Management | f | transactions | transactions PKI | i | | users | c | v | a | ======================= +--+------------+ ============== | t | ^ ^ | e | | | PKI | | v | management | & | +------+ | entities | | <---------------------| RA |<----+ | | C | Publish certificate +------+ | | | R | | | | L | | | | | v v | R | +------------+ | e | <------------------------------| CA | | p | Publish certificate +------------+ | o | Publish CRL ^ ^ | s | | | Management | i | +------------+ | | transactions | t | <--------------| CRL Issuer |<----+ | | o | Publish CRL +------------+ v | r | +------+ | y | | CA | +---+ +------+
+---+ | C| +------------+ | e| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 終わりの実体| | r| 操作上の+------------+ | t| トランザクション^| i| そして、管理| 管理| f| トランザクション| トランザクションPKI| i| | ユーザ| c| v| a| ======================= +--+------------+ ============== | t| ^ ^ | e| | | PKI| | v| 管理| & | +------+ | 実体| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| RA| <、-、-、--+ | | C| 証明書+を発表してください。------+ | | | R| | | | L| | | | | vに対して| R| +------------+ | e| <------------------------------| カリフォルニア| | p| 証明書+を発表してください。------------+ | o | CRL^ ^を発行してください。| s| | | 管理| i| +------------+ | | トランザクション| t| <、-、-、-、-、-、-、-、-、-、-、-、-、--、| CRL発行人| <、-、-、--+ | | o | CRL+を発行してください。------------+ v| r| +------+ | y| | カリフォルニア| +---+ +------+
Figure 1. PKI Entities
図1。 PKI実体
3.1. X.509 Version 3 Certificate
3.1. X.509バージョン3証明書
Users of a public key require confidence that the associated private key is owned by the correct remote subject (person or system) with which an encryption or digital signature mechanism will be used. This confidence is obtained through the use of public key certificates, which are data structures that bind public key values to subjects. The binding is asserted by having a trusted CA digitally sign each certificate. The CA may base this assertion upon technical means (a.k.a., proof of possession through a challenge- response protocol), presentation of the private key, or on an assertion by the subject. A certificate has a limited valid lifetime, which is indicated in its signed contents. Because a certificate's signature and timeliness can be independently checked by a certificate-using client, certificates can be distributed via
公開鍵のユーザは暗号化かデジタル署名メカニズムが使用される正しいリモート対象(人かシステム)によって関連秘密鍵が所有されているという信用を必要とします。 公開鍵証明書の使用でこの信用を得ます。(証明書は公開鍵値を対象に縛るデータ構造です)。 信じられたカリフォルニアを各証明書にデジタルに署名させることによって、結合は断言されます。 カリフォルニアは、対象で技術手段(通称挑戦応答プロトコルを通した所有物の証拠)でのこの主張、秘密鍵のプレゼンテーションを基礎づけるか、または主張に関してそうするかもしれません。 証明書には、限られた有効な寿命があります。(それは、署名しているコンテンツで示されます)。 を通して証明書を使用するクライアントが独自に証明書の署名とタイムリーさであるのをチェックできるので、証明書を配布できる。
Cooper, et al. Standards Track [Page 9] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[9ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
untrusted communications and server systems, and can be cached in unsecured storage in certificate-using systems.
信頼されていないコミュニケーションとサーバシステム、証明書を使用するシステムにおけるキャッシュされた中で非機密保護しているストレージはそうであることができます。
ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 9594-8, which was first published in 1988 as part of the X.500 directory recommendations, defines a standard certificate format [X.509]. The certificate format in the 1988 standard is called the version 1 (v1) format. When X.500 was revised in 1993, two more fields were added, resulting in the version 2 (v2) format.
ITU-T X.509(以前CCITT X.509)かISO/IEC9594-8(1988年に最初に、X.500ディレクトリ推薦の一部として発行されました)が標準の証明書書式[X.509]を定義します。 1988年の規格における証明書形式はバージョン1(v1)形式と呼ばれます。 X.500が1993年に改訂されたとき、バージョン2(v2)形式をもたらして、もう2つの分野が加えられました。
The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, include specifications for a public key infrastructure based on X.509 v1 certificates [RFC1422]. The experience gained in attempts to deploy RFC 1422 made it clear that the v1 and v2 certificate formats were deficient in several respects. Most importantly, more fields were needed to carry information that PEM design and implementation experience had proven necessary. In response to these new requirements, the ISO/IEC, ITU-T, and ANSI X9 developed the X.509 version 3 (v3) certificate format. The v3 format extends the v2 format by adding provision for additional extension fields. Particular extension field types may be specified in standards or may be defined and registered by any organization or community. In June 1996, standardization of the basic v3 format was completed [X.509].
1993年に発行されたインターネットPrivacy Enhancedメール(PEM)RFCsはX.509 v1証明書[RFC1422]に基づく公開鍵認証基盤のための仕様を含んでいます。 RFCが1422であると配布する試みで行われた経験は、v1とv2証明書形式がいくつかの点で不完全であると断言しました。 最も重要に、より多くの分野が、PEM設計と実装経験が必要であると判明したという情報を運ぶのに必要でした。 これらの新しい要件に対応して、ISO/IEC、ITU-T、およびANSI X9はX.509バージョン3(v3)証明書形式を発生しました。 v3形式は、追加拡大分野への支給を加えることによって、v2形式を広げています。 特定の拡大フィールド・タイプは、どんな組織や共同体によっても規格で指定されるか、定義されて、または示されるかもしれません。 1996年6月に、基本的なv3形式の標準化は終了しました[X.509]。
ISO/IEC, ITU-T, and ANSI X9 have also developed standard extensions for use in the v3 extensions field [X.509][X9.55]. These extensions can convey such data as additional subject identification information, key attribute information, policy information, and certification path constraints.
また、ISO/IEC、ITU-T、およびANSI X9はv3拡大分野[X.509][X9.55]での使用のための標準の拡大を発生しました。 これらの拡大は追加対象の識別情報、主要な属性情報、方針情報、および証明経路規制のようなデータを伝えることができます。
However, the ISO/IEC, ITU-T, and ANSI X9 standard extensions are very broad in their applicability. In order to develop interoperable implementations of X.509 v3 systems for Internet use, it is necessary to specify a profile for use of the X.509 v3 extensions tailored for the Internet. It is one goal of this document to specify a profile for Internet WWW, electronic mail, and IPsec applications. Environments with additional requirements may build on this profile or may replace it.
しかしながら、ISO/IEC、ITU-T、およびANSI X9の標準の拡張子は彼らの適用性で非常に広いです。 インターネットの利用のX.509 v3システムの共同利用できる実装を開発するために、インターネットに適合したX.509 v3拡張子の使用のためのプロフィールを指定するのが必要です。 それはインターネットWWW、電子メール、およびIPsecアプリケーションのためのプロフィールを指定するこのドキュメントの1つの目標です。 追加要件がある環境は、このプロフィールの上に建てるか、またはそれを取り替えるかもしれません。
3.2. Certification Paths and Trust
3.2. 証明経路と信頼
A user of a security service requiring knowledge of a public key generally needs to obtain and validate a certificate containing the required public key. If the public key user does not already hold an assured copy of the public key of the CA that signed the certificate, the CA's name, and related information (such as the validity period or name constraints), then it might need an additional certificate to obtain that public key. In general, a chain of multiple certificates
一般に、公開鍵に関する知識を必要とするセキュリティー・サービスのユーザは、必要な公開鍵を含む証明書を得て、有効にする必要があります。 公開鍵ユーザが既に、証明書に署名したカリフォルニアの公開鍵の確実なコピー、CAの名前、および関連する情報(規制という有効期間か名前などの)を保持しないなら、それは、その公開鍵を得るために追加証明書を必要とするかもしれません。 一般に、aは複数の証明書をチェーニングします。
Cooper, et al. Standards Track [Page 10] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[10ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
may be needed, comprising a certificate of the public key owner (the end entity) signed by one CA, and zero or more additional certificates of CAs signed by other CAs. Such chains, called certification paths, are required because a public key user is only initialized with a limited number of assured CA public keys.
必要であったかもしれない、公開鍵所有者(終わりの実体)の証明書を包括するのは1カリフォルニア、およびゼロで署名したか、またはCAsの、より多くの追加証明書が他のCAsで署名しました。 公開鍵ユーザが限られた数の確実なカリフォルニア公開鍵で初期化されるだけであるので、証明経路と呼ばれるそのようなチェーンが必要です。
There are different ways in which CAs might be configured in order for public key users to be able to find certification paths. For PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There are three types of PEM certification authority:
公開鍵ユーザが証明経路を見つけることができるようにCAsが構成されるかもしれない異なった方法があります。 PEMに関しては、RFC1422はCAsの堅い階層構造を定義しました。 PEM証明権威の3つのタイプがあります:
(a) Internet Policy Registration Authority (IPRA): This
authority, operated under the auspices of the Internet
Society, acts as the root of the PEM certification hierarchy
at level 1. It issues certificates only for the next level
of authorities, PCAs. All certification paths start with the
IPRA.
(a) インターネット方針登録局(IPRA): インターネット協会の前兆で操作されたこの権威はレベル1におけるPEM証明階層構造の根として機能します。 それは当局、PCAsの次のレベルのためだけの証明書を発行します。 すべての証明経路がIPRAから始まります。
(b) Policy Certification Authorities (PCAs): PCAs are at level 2
of the hierarchy, each PCA being certified by the IPRA. A
PCA shall establish and publish a statement of its policy
with respect to certifying users or subordinate certification
authorities. Distinct PCAs aim to satisfy different user
needs. For example, one PCA (an organizational PCA) might
support the general electronic mail needs of commercial
organizations, and another PCA (a high-assurance PCA) might
have a more stringent policy designed for satisfying legally
binding digital signature requirements.
(b) 方針証明当局(PCAs): 各PCAがIPRAによって公認されて、PCAsは階層構造のレベル2においてそうです。 PCAはユーザか下位の証明当局を公認することに関して方針の声明を確立して、発表するものとします。 異なったPCAsは、異なったユーザ需要を満たすことを目指します。 例えば、1PCA(組織的なPCA)が営利団体の一般的な電子メールの必要性をサポートするかもしれません、そして、別のPCA(高保証PCA)は、法的に拘束力があるデジタル署名要件を満たすように、より厳しい方針を設計させるかもしれません。
(c) Certification Authorities (CAs): CAs are at level 3 of the
hierarchy and can also be at lower levels. Those at level 3
are certified by PCAs. CAs represent, for example,
particular organizations, particular organizational units
(e.g., departments, groups, sections), or particular
geographical areas.
(c) 証明当局(CAs): CAsは階層構造のレベル3にあって、また、下のレベルにあることができます。 レベル3におけるものはPCAsによって公認されます。 CAsは例えば、特定の組織、特定の組織的なユニット(例えば、部、グループ、セクション)、または特定の地理的な領域を代表します。
RFC 1422 furthermore has a name subordination rule, which requires that a CA can only issue certificates for entities whose names are subordinate (in the X.500 naming tree) to the name of the CA itself. The trust associated with a PEM certification path is implied by the PCA name. The name subordination rule ensures that CAs below the PCA are sensibly constrained as to the set of subordinate entities they can certify (e.g., a CA for an organization can only certify entities in that organization's name tree). Certificate user systems are able to mechanically check that the name subordination rule has been followed.
RFC1422には、その上、名前従属規則があります。(それは、カリフォルニアが名前がカリフォルニア自体の名前に下位である(X.500命名木の)実体のための証明書を発行できるだけであるのを必要とします)。 PEM証明経路に関連している信頼はPCA名によって含意されます。 名前従属規則は、PCAの下のCAsがそれらが公認できる下位の実体のセットに関して分別よく抑制されるのを確実にします(例えば、組織のためのカリフォルニアはその組織名木で実体を公認できるだけです)。 証明書ユーザシステムは、名前従属規則に従ってあるのを機械的にチェックできます。
Cooper, et al. Standards Track [Page 11] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[11ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
RFC 1422 uses the X.509 v1 certificate format. The limitations of X.509 v1 required imposition of several structural restrictions to clearly associate policy information or restrict the utility of certificates. These restrictions included:
RFC1422はX.509 v1証明書形式を使用します。 X.509 v1の限界は、明確に方針情報を関連づけるか、または証明書に関するユーティリティを制限するためにいくつかの構造的な制限の賦課を必要としました。 これらの制限は:だった
(a) a pure top-down hierarchy, with all certification paths
starting from IPRA;
(a) すべての証明経路がIPRAから始めている純粋なトップダウン階層構造。
(b) a naming subordination rule restricting the names of a CA's
subjects; and
(b) CAの対象の名前を制限する命名従属規則。 そして
(c) use of the PCA concept, which requires knowledge of
individual PCAs to be built into certificate chain
verification logic. Knowledge of individual PCAs was
required to determine if a chain could be accepted.
(c) PCA概念の使用。(それは、証明書チェーン検証論理が個々のPCAsに関する知識に組み込まれるのを必要とします)。 個々のPCAsに関する知識が、チェーンを受け入れることができるかどうか決定するのに必要でした。
With X.509 v3, most of the requirements addressed by RFC 1422 can be addressed using certificate extensions, without a need to restrict the CA structures used. In particular, the certificate extensions relating to certificate policies obviate the need for PCAs and the constraint extensions obviate the need for the name subordination rule. As a result, this document supports a more flexible architecture, including:
X.509 v3と共に、証明書拡張子を使用することでRFC1422によって扱われた要件の大部分を扱うことができます、構造が使用したカリフォルニアを制限する必要性なしで。 特に、証明書方針に関連する証明書拡張子はPCAsの必要性を取り除きます、そして、規制拡大は名前従属規則の必要性を取り除きます。 その結果、このドキュメントは、よりフレキシブルなアーキテクチャ、包含をサポートします:
(a) Certification paths start with a public key of a CA in a
user's own domain, or with the public key of the top of a
hierarchy. Starting with the public key of a CA in a user's
own domain has certain advantages. In some environments, the
local domain is the most trusted.
(a) 証明経路はユーザの自己のドメインのカリフォルニア、または階層構造の最上部の公開鍵で公開鍵から始まります。 ユーザの自己のドメインでカリフォルニアの公開鍵から始まるのにおいて、ある利点があります。 いくつかの環境で、局所領域は最も信じているものです。
(b) Name constraints may be imposed through explicit inclusion of
a name constraints extension in a certificate, but are not
required.
(b) 名前規制は、証明書での名前規制拡大の明白な包含で課されるかもしれませんが、必要ではありません。
(c) Policy extensions and policy mappings replace the PCA
concept, which permits a greater degree of automation. The
application can determine if the certification path is
acceptable based on the contents of the certificates instead
of a priori knowledge of PCAs. This permits automation of
certification path processing.
(c) 方針拡大と方針マッピングはPCA概念に取って代わります。(それは、より大きい度合いのオートメーションを可能にします)。 アプリケーションは、証明経路がPCAsに関する先験的な知識の代わりに証明書のコンテンツに基づいて許容できるかどうか決定できます。 これは証明経路処理のオートメーションを可能にします。
X.509 v3 also includes an extension that identifies the subject of a certificate as being either a CA or an end entity, reducing the reliance on out-of-band information demanded in PEM.
また、X.509 v3はカリフォルニアか終わりの実体のどちらかであるとして証明書の対象を特定する拡大を含んでいます、バンドの外の情報がPEMで要求した信用を抑えて。
This specification covers two classes of certificates: CA certificates and end entity certificates. CA certificates may be further divided into three classes: cross-certificates, self-issued
この仕様は2つのクラスの証明書をカバーしています: カリフォルニア証明書と終わりの実体証明書。 カリフォルニア証明書はさらに3つのクラスに分割されるかもしれません: 交差している証明書であって、自己によって発行されています。
Cooper, et al. Standards Track [Page 12] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[12ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
certificates, and self-signed certificates. Cross-certificates are CA certificates in which the issuer and subject are different entities. Cross-certificates describe a trust relationship between the two CAs. Self-issued certificates are CA certificates in which the issuer and subject are the same entity. Self-issued certificates are generated to support changes in policy or operations. Self- signed certificates are self-issued certificates where the digital signature may be verified by the public key bound into the certificate. Self-signed certificates are used to convey a public key for use to begin certification paths. End entity certificates are issued to subjects that are not authorized to issue certificates.
証明書、および自己署名入りの証書。 交差している証明書は発行人と対象が異なった実体であるカリフォルニア証明書です。 交差している証明書は2CAsの間の信頼関係について説明します。 自己に証明書を発行しているのは、発行人と対象が同じ実体であるカリフォルニア証明書です。 自己によって発行された証明書は、方針か操作における変化をサポートするために作られます。 自己証明書であると署名されているのは、デジタル署名が証明書に縛られた公開鍵によって確かめられるかもしれない自己によって発行された証明書です。 自己署名入りの証書は、使用が証明経路を始めるように公開鍵を伝えるのに使用されます。 証明書を発行するのは認可されない対象に終わりの実体証明書を発行します。
3.3. Revocation
3.3. 取消し
When a certificate is issued, it is expected to be in use for its entire validity period. However, various circumstances may cause a certificate to become invalid prior to the expiration of the validity period. Such circumstances include change of name, change of association between subject and CA (e.g., an employee terminates employment with an organization), and compromise or suspected compromise of the corresponding private key. Under such circumstances, the CA needs to revoke the certificate.
証明書を発行するとき、全体の有効期間の間、使用中であるとそれを予想します。 しかしながら、様々な事情によって、証明書は有効期間の満了の前に無効になるかもしれません。 そのような事情は名前の変化、対象と、カリフォルニア(例えば、従業員は組織との雇用を終える)と、感染との協会の変化または対応する秘密鍵の疑われた感染を含んでいます。 これでは、カリフォルニアは、証明書を取り消す必要があります。
X.509 defines one method of certificate revocation. This method involves each CA periodically issuing a signed data structure called a certificate revocation list (CRL). A CRL is a time-stamped list identifying revoked certificates that is signed by a CA or CRL issuer and made freely available in a public repository. Each revoked certificate is identified in a CRL by its certificate serial number. When a certificate-using system uses a certificate (e.g., for verifying a remote user's digital signature), that system not only checks the certificate signature and validity but also acquires a suitably recent CRL and checks that the certificate serial number is not on that CRL. The meaning of "suitably recent" may vary with local policy, but it usually means the most recently issued CRL. A new CRL is issued on a regular periodic basis (e.g., hourly, daily, or weekly). An entry is added to the CRL as part of the next update following notification of revocation. An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyond the revoked certificate's validity period.
X.509は証明書取消しの1つのメソッドを定義します。 このメソッドは定期的に証明書失効リスト(CRL)と呼ばれる署名しているデータ構造を発行する各カリフォルニアを伴います。 CRLは公共の倉庫でそれがカリフォルニアかCRL発行人によって署名される取り消された証明書を特定して、自由に利用可能にされた時間で押し込まれたリストです。 それぞれの取り消された証明書はCRLで証明書通し番号によって特定されます。 証明書を使用するシステムが証明書(例えば、リモート・ユーザーのデジタル署名について確かめるための)を使用すると、そのシステムは、証明書署名と正当性をチェックするだけではなく、適当に最近のCRLを獲得して、証明書通し番号がそのCRLにないのをチェックもします。 「適当に最近」の意味はローカルの方針で異なるかもしれませんが、通常、それは最も最近発行されたCRLを意味します。 新しいCRLが通常周期的ベースで発行される、(例えば、1時間ごと、毎日、または毎週、) エントリーは取消しの通知に続く次のアップデートの一部としてCRLに加えられます。 CRLからエントリーを取り消された証明書の有効期間に発行された1定期的に予定されているCRLに現れるまで取り除いてはいけません。
An advantage of this revocation method is that CRLs may be distributed by exactly the same means as certificates themselves, namely, via untrusted servers and untrusted communications.
この取消しメソッドの利点はすなわち、信頼されていないことを通して自分たちでサーバと信頼されていないコミュニケーションを証明するときCRLsがまさに同じ手段で分配されるかもしれないということです。
One limitation of the CRL revocation method, using untrusted communications and servers, is that the time granularity of revocation is limited to the CRL issue period. For example, if a
CRL取消しメソッドの1つの制限(信頼されていないコミュニケーションを使用して、サーバ)は、取消しの時間粒状がCRL問題の期間まで制限されるということです。 例えばaです。
Cooper, et al. Standards Track [Page 13] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[13ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
revocation is reported now, that revocation will not be reliably notified to certificate-using systems until all currently issued CRLs are scheduled to be updated -- this may be up to one hour, one day, or one week depending on the frequency that CRLs are issued.
すべての現在発行されたCRLsがアップデートされる予定であるまで、その取消しは証明書を使用するシステムに確かに通知されないでしょう--取消しは現在報告されて、ある日、これは最大1時間であるかもしれませんか1週間はCRLsが発行される頻度に依存することです。
As with the X.509 v3 certificate format, in order to facilitate interoperable implementations from multiple vendors, the X.509 v2 CRL format needs to be profiled for Internet use. It is one goal of this document to specify that profile. However, this profile does not require the issuance of CRLs. Message formats and protocols supporting on-line revocation notification are defined in other PKIX specifications. On-line methods of revocation notification may be applicable in some environments as an alternative to the X.509 CRL. On-line revocation checking may significantly reduce the latency between a revocation report and the distribution of the information to relying parties. Once the CA accepts a revocation report as authentic and valid, any query to the on-line service will correctly reflect the certificate validation impacts of the revocation. However, these methods impose new security requirements: the certificate validator needs to trust the on-line validation service while the repository does not need to be trusted.
X.509 v3証明書形式のように、X.509 v2 CRL形式は、複数のベンダーから共同利用できる実装を容易にするのにインターネットの利用のために輪郭を描かれる必要があります。 それはそのプロフィールを指定するこのドキュメントの1つの目標です。 しかしながら、このプロフィールはCRLsの発行を必要としません。 オンライン取消しが通知であるとサポートするメッセージ・フォーマットとプロトコルが他のPKIX仕様に基づき定義されます。 X.509 CRLに代わる手段として取消し通知のオンラインメソッドはいくつかの環境で適切であるかもしれません。 オンライン取消しの照合は取消しレポートと情報の分配の間のレイテンシを信用パーティーにかなり減少させるかもしれません。 カリフォルニアが、取消しレポートが正統であって、有効であるといったん受け入れると、パソコン通信へのどんな質問も正しく取消しの証明書合法化影響を反映するでしょう。 しかしながら、これらのメソッドは新しいセキュリティ要件を課します: 証明書validatorは、倉庫が信じられる必要はありませんが、オンライン合法化サービスを信じる必要があります。
3.4. Operational Protocols
3.4. 操作上のプロトコル
Operational protocols are required to deliver certificates and CRLs (or status information) to certificate-using client systems. Provisions are needed for a variety of different means of certificate and CRL delivery, including distribution procedures based on LDAP, HTTP, FTP, and X.500. Operational protocols supporting these functions are defined in other PKIX specifications. These specifications may include definitions of message formats and procedures for supporting all of the above operational environments, including definitions of or references to appropriate MIME content types.
操作上のプロトコルが、証明書とCRLs(または、状態情報)を証明書を使用するクライアントシステムに提供するのに必要です。条項が証明書とCRL配送のさまざまな異なった手段に必要です、LDAP、HTTP、FTP、およびX.500に基づく分配手順を含んでいて。 これらの機能をサポートする操作上のプロトコルが他のPKIX仕様に基づき定義されます。 これらの仕様は上の運用環境のすべてをサポートするためのメッセージ・フォーマットと手順の定義を含むかもしれません、適切なMIME content typeの定義か指示するものを含んでいて。
3.5. Management Protocols
3.5. 管理プロトコル
Management protocols are required to support on-line interactions between PKI user and management entities. For example, a management protocol might be used between a CA and a client system with which a key pair is associated, or between two CAs that cross-certify each other. The set of functions that potentially need to be supported by management protocols include:
管理プロトコルが、PKIユーザと経営体とのオンライン相互作用をサポートするのに必要です。 例えば、管理プロトコルは主要な組が関連しているカリフォルニアとクライアントシステムの間、または、互いを十字で公認する2CAsの間で使用されるかもしれません。 潜在的に管理プロトコルによってサポートされる必要がある機能のセットは:
(a) registration: This is the process whereby a user first makes
itself known to a CA (directly, or through an RA), prior to
that CA issuing a certificate or certificates for that user.
(a)登録: これはユーザが最初にカリフォルニア(直接かRAを通した)にそれ自体を明らかにするプロセスです、そのユーザのために証明書か証明書を発行するそのカリフォルニアの前に。
Cooper, et al. Standards Track [Page 14] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[14ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
(b) initialization: Before a client system can operate securely,
it is necessary to install key materials that have the
appropriate relationship with keys stored elsewhere in the
infrastructure. For example, the client needs to be securely
initialized with the public key and other assured information
of the trusted CA(s), to be used in validating certificate
paths.
(b)初期化: クライアントシステムがしっかりと作動できる前に、インフラストラクチャにおけるほかの場所に保存されるキーとの適切な関係を持っている主要資材をインストールするのが必要です。 例えば、クライアントは信じられたカリフォルニアの公開鍵と他の確実な情報でしっかりと初期化されて、証明書経路を有効にする際に使用される必要があります。
Furthermore, a client typically needs to be initialized with
its own key pair(s).
その上、クライアントは、通常それ自身の主要な組と共に初期化される必要があります。
(c) certification: This is the process in which a CA issues a
certificate for a user's public key, and returns that
certificate to the user's client system and/or posts that
certificate in a repository.
(c)証明: これはカリフォルニアが倉庫でユーザのクライアントシステムへのその証明書をユーザの公開鍵、およびリターンのための証明書に発行する、そして/または、その証明書をポストに発行するプロセスです。
(d) key pair recovery: As an option, user client key materials
(e.g., a user's private key used for encryption purposes) may
be backed up by a CA or a key backup system. If a user needs
to recover these backed-up key materials (e.g., as a result
of a forgotten password or a lost key chain file), an on-line
protocol exchange may be needed to support such recovery.
(d) 主要な組回復: オプションとして、ユーザクライアント主要資材(例えば暗号化目的に使用されるユーザの秘密鍵)はカリフォルニアか主要なバックアップ・システムによって支援されるかもしれません。 ユーザが、これらの支援している主要資材(例えば、忘れられたパスワードか無くなっているキーチェーンファイルの結果、)を回収する必要があるなら、オンラインプロトコル交換が、そのような回復をサポートするのに必要であるかもしれません。
(e) key pair update: All key pairs need to be updated regularly,
i.e., replaced with a new key pair, and new certificates
issued.
(e) 主要な組は以下をアップデートします。 すべての主要な組が、すなわち、定期的に新しい主要な組、および発行された新しい証明書に取って代わった状態でアップデートする必要があります。
(f) revocation request: An authorized person advises a CA of an
abnormal situation requiring certificate revocation.
(f) 取消し要求: 権限保持者は証明書取消しを必要とする異常な状況をカリフォルニアに知らせます。
(g) cross-certification: Two CAs exchange information used in
establishing a cross-certificate. A cross-certificate is a
certificate issued by one CA to another CA that contains a CA
signature key used for issuing certificates.
(g)相互認証: 2CAsが交差している証明書を確立する際に使用される情報を交換します。 交差している証明書は1カリフォルニアによって証明書を発行するのに使用されるカリフォルニア署名キーを含む別のカリフォルニアに発行された証明書です。
Note that on-line protocols are not the only way of implementing the above functions. For all functions, there are off-line methods of achieving the same result, and this specification does not mandate use of on-line protocols. For example, when hardware tokens are used, many of the functions may be achieved as part of the physical token delivery. Furthermore, some of the above functions may be combined into one protocol exchange. In particular, two or more of the registration, initialization, and certification functions can be combined into one protocol exchange.
オンラインプロトコルが唯一の道にどんな上の機能を実装しないものであることに注意してください。 すべての機能のために、同じ結果を獲得するメソッドがオフラインであります、そして、この仕様はオンラインプロトコルの使用を強制しません。 ハードウェアトークンが使用されているとき、例えば、機能の多くが物理的なトークン配送の一部として獲得されるかもしれません。 その上、上の機能のいくつかが1回のプロトコル交換に結合されるかもしれません。 特に、登録、初期化、および2つ以上の証明機能を1回のプロトコル交換に結合できます。
Cooper, et al. Standards Track [Page 15] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[15ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
The PKIX series of specifications defines a set of standard message formats supporting the above functions. The protocols for conveying these messages in different environments (e.g., email, file transfer, and WWW) are described in those specifications.
仕様のPKIXシリーズは上の機能をサポートする1セットの標準のメッセージ・フォーマットを定義します。 異なった環境(例えば、メール、ファイル転送、およびWWW)におけるこれらのメッセージを伝えるためのプロトコルはそれらの仕様で説明されます。
4. Certificate and Certificate Extensions Profile
4. 拡大プロフィールを証明して、証明してください。
This section presents a profile for public key certificates that will foster interoperability and a reusable PKI. This section is based upon the X.509 v3 certificate format and the standard certificate extensions defined in [X.509]. The ISO/IEC and ITU-T documents use the 1997 version of ASN.1; while this document uses the 1988 ASN.1 syntax, the encoded certificate and standard extensions are equivalent. This section also defines private extensions required to support a PKI for the Internet community.
このセクションは相互運用性を伸ばす公開鍵証明書と再利用できるPKIのためのプロフィールを提示します。 このセクションは[X.509]で定義されたX.509 v3証明書書式と標準の証明書拡張子に基づいています。 ISO/IECとITU-Tドキュメントは1997年のASN.1のバージョンを使用します。 このドキュメントは1988ASN.1構文を使用しますが、コード化された証明書と標準の拡大は同等です。 また、このセクションはインターネットコミュニティのためにPKIをサポートするのに必要である個人的な拡大を定義します。
Certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability and limited special purpose requirements. In particular, the emphasis will be on supporting the use of X.509 v3 certificates for informal Internet electronic mail, IPsec, and WWW applications.
証明書は相互運用性目標の広いスペクトルと操作上と保証要件の、より広いスペクトルを含んでいるさまざまなアプリケーションと環境で使用されるかもしれません。 このドキュメントの目標は広い相互運用性と限られた専用要件を必要とする一般的適用のために一般的な基線を確立することです。 特に、強調がX.509 v3証明書の非公式のインターネット電子メール、IPsec、およびWWWアプリケーションの使用をサポートするところにあるでしょう。
4.1. Basic Certificate Fields
4.1. 基本的な証明書分野
The X.509 v3 certificate basic syntax is as follows. For signature calculation, the data that is to be signed is encoded using the ASN.1 distinguished encoding rules (DER) [X.690]. ASN.1 DER encoding is a tag, length, value encoding system for each element.
X.509 v3の証明書の基本的な構文は以下の通りです。 署名計算において、署名されることになっているデータは、規則(DER)[X.690]をコード化しながら区別されたASN.1を使用することでコード化されます。 ASN.1DERコード化はタグ、長さ、それぞれの要素のシステムをコード化する値です。
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
以下を証明してください:= 系列tbsCertificate TBSCertificate、signatureAlgorithm AlgorithmIdentifier、signatureValueビット列
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
TBSCertificate:、:= SEQUENCE、バージョン[0]EXPLICITバージョンDEFAULT v1、serialNumber CertificateSerialNumber、署名AlgorithmIdentifier、発行人Name(正当性Validity)はNameをかけます、subjectPublicKeyInfo SubjectPublicKeyInfo、issuerUniqueID[1]IMPLICIT UniqueIdentifier OPTIONAL--存在しているなら、バージョンは、v2かv3であるに違いありません。
Cooper, et al. Standards Track [Page 16] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[16ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
extensions [3] EXPLICIT Extensions OPTIONAL
-- If present, version MUST be v3
}
プレゼント、バージョンがそうしなければならないなら、subjectUniqueID[2]IMPLICIT UniqueIdentifier OPTIONAL--プレゼント、バージョンがそうしなければならないなら、v2になりなさいか、またはv3拡大[3]EXPLICIT Extensions OPTIONAL--v3になってください。
Version ::= INTEGER { v1(0), v2(1), v3(2) }
バージョン:、:= 整数v1(0)、v2(1)、v3(2)
CertificateSerialNumber ::= INTEGER
CertificateSerialNumber:、:= 整数
Validity ::= SEQUENCE {
notBefore Time,
notAfter Time }
正当性:、:= 系列notBefore時間、notAfter時間
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
以下を調節してください:= 選択utcTime UTCTime、generalTime GeneralizedTime
UniqueIdentifier ::= BIT STRING
UniqueIdentifier:、:= ビット列
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
SubjectPublicKeyInfo:、:= 系列アルゴリズムAlgorithmIdentifier、subjectPublicKey BIT STRING
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
拡大:、:= 拡大の系列サイズ(1..MAX)
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
-- contains the DER encoding of an ASN.1 value
-- corresponding to the extension type identified
-- by extnID
}
拡大:、:= 系列extnID OBJECT IDENTIFIER、重要なBOOLEAN DEFAULT FALSE、extnValue OCTET STRING--タイプが特定した拡大に対応している、ASN.1価値のDERコード化を含んでいます--、extnID
The following items describe the X.509 v3 certificate for use in the Internet.
以下の項目はインターネットでの使用のためのX.509 v3証明書について説明します。
4.1.1. Certificate Fields
4.1.1. 証明書分野
The Certificate is a SEQUENCE of three required fields. The fields are described in detail in the following subsections.
Certificateは3つの必須項目のSEQUENCEです。 分野は以下の小区分で詳細に説明されます。
Cooper, et al. Standards Track [Page 17] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[17ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
4.1.1.1. tbsCertificate
4.1.1.1. tbsCertificate
The field contains the names of the subject and issuer, a public key associated with the subject, a validity period, and other associated information. The fields are described in detail in Section 4.1.2; the tbsCertificate usually includes extensions, which are described in Section 4.2.
分野は対象、有効期間、および他の関連情報に関連している公開鍵という対象と発行人の名前を含んでいます。 分野はセクション4.1.2で詳細に説明されます。 通常、tbsCertificateは拡大を含んでいます。(拡大はセクション4.2で説明されます)。
4.1.1.2. signatureAlgorithm
4.1.1.2. signatureAlgorithm
The signatureAlgorithm field contains the identifier for the cryptographic algorithm used by the CA to sign this certificate. [RFC3279], [RFC4055], and [RFC4491] list supported signature algorithms, but other signature algorithms MAY also be supported.
signatureAlgorithm分野はこの証明書に署名するのにカリフォルニアによって使用された暗号アルゴリズムのための識別子を含んでいます。 [RFC3279]、[RFC4055]、および[RFC4491]リストは署名アルゴリズムをサポートしましたが、また、他の署名アルゴリズムはサポートされるかもしれません。
An algorithm identifier is defined by the following ASN.1 structure:
アルゴリズム識別子は以下のASN.1構造によって定義されます:
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
AlgorithmIdentifier:、:= 系列アルゴリズムOBJECT IDENTIFIER、パラメタANY DEFINED BYアルゴリズムOPTIONAL
The algorithm identifier is used to identify a cryptographic algorithm. The OBJECT IDENTIFIER component identifies the algorithm (such as DSA with SHA-1). The contents of the optional parameters field will vary according to the algorithm identified.
アルゴリズム識別子は、暗号アルゴリズムを特定するのに使用されます。 OBJECT IDENTIFIERの部品はアルゴリズム(SHA-1とDSAなどの)を特定します。 特定されたアルゴリズムによると、任意のパラメタ分野のコンテンツは異なるでしょう。
This field MUST contain the same algorithm identifier as the signature field in the sequence tbsCertificate (Section 4.1.2.3).
この分野が系列tbsCertificateの署名分野と同じアルゴリズム識別子を含まなければならない、(セクション4.1 .2 .3)。
4.1.1.3. signatureValue
4.1.1.3. signatureValue
The signatureValue field contains a digital signature computed upon the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded tbsCertificate is used as the input to the signature function. This signature value is encoded as a BIT STRING and included in the signature field. The details of this process are specified for each of the algorithms listed in [RFC3279], [RFC4055], and [RFC4491].
計算されて、signatureValue分野はデジタル署名を含んでいます。ASN.1DERはtbsCertificateをコード化しました。 署名への入力が機能するので、ASN.1DERは使用されるtbsCertificateをコード化しました。 この署名値は、BIT STRINGとしてコード化されて、署名分野に含まれています。 このプロセスの細部は[RFC3279]、[RFC4055]、および[RFC4491]に記載されたそれぞれのアルゴリズムに指定されます。
By generating this signature, a CA certifies the validity of the information in the tbsCertificate field. In particular, the CA certifies the binding between the public key material and the subject of the certificate.
この署名を生成することによって、カリフォルニアはtbsCertificate分野における、情報の正当性を公認します。 特に、カリフォルニアは公開鍵の材料と証明書の対象の間の結合を公認します。
4.1.2. TBSCertificate
4.1.2. TBSCertificate
The sequence TBSCertificate contains information associated with the subject of the certificate and the CA that issued it. Every TBSCertificate contains the names of the subject and issuer, a public
系列TBSCertificateはそれを発行した証明書とカリフォルニアの対象に関連している情報を含んでいます。 あらゆるTBSCertificateが対象と発行人の名前、公衆を含みます。
Cooper, et al. Standards Track [Page 18] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[18ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
key associated with the subject, a validity period, a version number, and a serial number; some MAY contain optional unique identifier fields. The remainder of this section describes the syntax and semantics of these fields. A TBSCertificate usually includes extensions. Extensions for the Internet PKI are described in Section 4.2.
キーは対象、有効期間、バージョン番号、および通し番号と交際しました。 或るものは任意のユニークな識別子分野を含むかもしれません。 このセクションの残りはこれらの分野の構文と意味論について説明します。 通常、TBSCertificateは拡大を含んでいます。 拡大はセクション4.2にインターネットPKIに説明されます。
4.1.2.1. Version
4.1.2.1. バージョン
This field describes the version of the encoded certificate. When extensions are used, as expected in this profile, version MUST be 3 (value is 2). If no extensions are present, but a UniqueIdentifier is present, the version SHOULD be 2 (value is 1); however, the version MAY be 3. If only basic fields are present, the version SHOULD be 1 (the value is omitted from the certificate as the default value); however, the version MAY be 2 or 3.
この分野はコード化された証明書のバージョンについて説明します。 拡大がこのプロフィールで予想されるように使用されているとき、バージョンは3であるに違いありません(値は2です)。 拡大はいいえなら存在していますが、UniqueIdentifierは存在していて、バージョンはSHOULDです。2(値は1である)になってください。 しかしながら、バージョンは3であるかもしれません。 基礎体が存在してさえいる場合、よかったでしょう、バージョンSHOULD。1(値はデフォルト値として証明書から省略される)になってください。 しかしながら、バージョンは、2か3であるかもしれません。
Implementations SHOULD be prepared to accept any version certificate. At a minimum, conforming implementations MUST recognize version 3 certificates.
実装SHOULD、あらゆるバージョン証明書を受け入れるように用意してください。 最小限では、実装を従わせると、バージョン3証明書は認識されなければなりません。
Generation of version 2 certificates is not expected by implementations based on this profile.
バージョン2証明書の世代はこのプロフィールに基づく実装によって予想されません。
4.1.2.2. Serial Number
4.1.2.2. 通し番号
The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer.
通し番号はカリフォルニアによって各証明書に割り当てられた正の整数であるに違いありません。 与えられたカリフォルニアによって発行された各証明書に、それはユニークであるに違いありません(すなわち、発行人名と通し番号はユニークな証明書を特定します)。 CAsは、serialNumberが非負の整数であることを強制しなければなりません。
Given the uniqueness requirements above, serial numbers can be expected to contain long integers. Certificate users MUST be able to handle serialNumber values up to 20 octets. Conforming CAs MUST NOT use serialNumber values longer than 20 octets.
上記のユニークさの要件を考えて、通し番号が長整数型を含むと予想できます。 証明書ユーザはserialNumber値を20の八重奏まで扱うことができなければなりません。 CAsを従わせると、serialNumber値は20の八重奏より長い間、使用されてはいけません。
Note: Non-conforming CAs may issue certificates with serial numbers that are negative or zero. Certificate users SHOULD be prepared to gracefully handle such certificates.
以下に注意してください。 非の従うCAsは負の通し番号かゼロで証明書を発行するかもしれません。 優雅にそのような証明書を扱うために準備されていて、ユーザSHOULDを証明してください。
4.1.2.3. Signature
4.1.2.3. 署名
This field contains the algorithm identifier for the algorithm used by the CA to sign the certificate.
この分野は証明書に署名するのにカリフォルニアによって使用されたアルゴリズムのためのアルゴリズム識別子を含んでいます。
This field MUST contain the same algorithm identifier as the signatureAlgorithm field in the sequence Certificate (Section
この分野が系列CertificateのsignatureAlgorithm分野と同じアルゴリズム識別子を含まなければならない、(セクション
Cooper, et al. Standards Track [Page 19] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[19ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
4.1.1.2). The contents of the optional parameters field will vary according to the algorithm identified. [RFC3279], [RFC4055], and [RFC4491] list supported signature algorithms, but other signature algorithms MAY also be supported.
4.1.1.2). 特定されたアルゴリズムによると、任意のパラメタ分野のコンテンツは異なるでしょう。 [RFC3279]、[RFC4055]、および[RFC4491]リストは署名アルゴリズムをサポートしましたが、また、他の署名アルゴリズムはサポートされるかもしれません。
4.1.2.4. Issuer
4.1.2.4. 発行人
The issuer field identifies the entity that has signed and issued the certificate. The issuer field MUST contain a non-empty distinguished name (DN). The issuer field is defined as the X.501 type Name [X.501]. Name is defined by the following ASN.1 structures:
発行人分野は証明書に署名して、発行した実体を特定します。 発行人分野は非空の分類名(DN)を含まなければなりません。 発行人分野はX.501タイプName[X.501]と定義されます。 名前は以下のASN.1構造によって定義されます:
Name ::= CHOICE { -- only one possibility for now --
rdnSequence RDNSequence }
以下を命名してください:= 選択--当分間の1つの可能性だけ--rdnSequence RDNSequence
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RDNSequence:、:= RelativeDistinguishedNameの系列
RelativeDistinguishedName ::=
SET SIZE (1..MAX) OF AttributeTypeAndValue
RelativeDistinguishedName:、:= AttributeTypeAndValueのサイズ(1..MAX)を設定してください。
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
AttributeTypeAndValue:、:= 系列AttributeType、値のAttributeValueをタイプしてください。
AttributeType ::= OBJECT IDENTIFIER
AttributeType:、:= オブジェクト識別子
AttributeValue ::= ANY -- DEFINED BY AttributeType
AttributeValue:、:= いずれ--AttributeTypeによって定義されます。
DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..MAX)),
printableString PrintableString (SIZE (1..MAX)),
universalString UniversalString (SIZE (1..MAX)),
utf8String UTF8String (SIZE (1..MAX)),
bmpString BMPString (SIZE (1..MAX)) }
DirectoryString:、:= 選択teletexString TeletexString(サイズ(1..MAX))、printableString PrintableString(サイズ(1..MAX))、universalString UniversalString(サイズ(1..MAX))、utf8String UTF8String(サイズ(1..MAX))、bmpString BMPString(サイズ(1..MAX))
The Name describes a hierarchical name composed of attributes, such as country name, and corresponding values, such as US. The type of the component AttributeValue is determined by the AttributeType; in general it will be a DirectoryString.
Nameは国の名などの属性で構成された、階層的な名前、および米国などの換算値について説明します。 コンポーネントAttributeValueのタイプはAttributeTypeによって決定されます。 一般に、それはDirectoryStringになるでしょう。
The DirectoryString type is defined as a choice of PrintableString, TeletexString, BMPString, UTF8String, and UniversalString. CAs conforming to this profile MUST use either the PrintableString or UTF8String encoding of DirectoryString, with two exceptions. When CAs have previously issued certificates with issuer fields with attributes encoded using TeletexString, BMPString, or UniversalString, then the CA MAY continue to use these encodings of the DirectoryString to preserve backward compatibility. Also, new
DirectoryStringタイプはPrintableString、TeletexString、BMPString、UTF8String、およびUniversalStringの選択と定義されます。 このプロフィールに従うCAsは2つの例外があるDirectoryStringのPrintableStringかUTF8Stringコード化のどちらかを使用しなければなりません。 属性がコード化されている状態でCAsが以前にTeletexStringを使用することで発行人分野がある証明書を発行したとき、BMPString、またはUniversalString、当時のカリフォルニアが、後方の互換性を保存するのにDirectoryStringのこれらのencodingsを使用し続けるかもしれません。 また、新しく
Cooper, et al. Standards Track [Page 20] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[20ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
CAs that are added to a domain where existing CAs issue certificates with issuer fields with attributes encoded using TeletexString, BMPString, or UniversalString MAY encode attributes that they share with the existing CAs using the same encodings as the existing CAs use.
属性がある発行人分野がある既存のCAs問題証明書がTeletexStringを使用するか、BMPString、またはUniversalStringをコード化したドメインに加えられるCAsはそれらがCAsが使用する存在と同じencodingsを使用する既存のCAsと共有する属性をコード化するかもしれません。
As noted above, distinguished names are composed of attributes. This specification does not restrict the set of attribute types that may appear in names. However, conforming implementations MUST be prepared to receive certificates with issuer names containing the set of attribute types defined below. This specification RECOMMENDS support for additional attribute types.
上で述べたように、分類名は属性で構成されます。 この仕様は名前に現れるかもしれない属性タイプのセットを制限しません。 しかしながら、発行人名が以下で定義された属性タイプのセットを含んでいて証明書を受け取るように実装を従わせるのを準備しなければなりません。 この仕様RECOMMENDSは追加属性のためにタイプをサポートします。
Standard sets of attributes have been defined in the X.500 series of specifications [X.520]. Implementations of this specification MUST be prepared to receive the following standard attribute types in issuer and subject (Section 4.1.2.6) names:
属性の標準セットは仕様[X.520]のX.500シリーズで定義されました。 標準の属性が発行人でタイプする以下と対象を受け取るようにこの仕様の実装を準備しなければなりません。(4.1の.2.6)名を区分してください:
* country,
* organization,
* organizational unit,
* distinguished name qualifier,
* state or province name,
* common name (e.g., "Susan Housley"), and
* serial number.
* 国、組織、*組織的なユニット、*分類名資格を与える人、*州または州が命名する*、*一般名(例えば、「スーザンHousley」)、および*通し番号。
In addition, implementations of this specification SHOULD be prepared to receive the following standard attribute types in issuer and subject names:
追加、実装、この仕様SHOULDでは、準備されていて、以下の標準の属性を受けるのは発行人と対象名で以下をタイプします。
* locality,
* title,
* surname,
* given name,
* initials,
* pseudonym, and
* generation qualifier (e.g., "Jr.", "3rd", or "IV").
* 場所、*タイトル、*姓、*与えられた名、*イニシャル、*匿名、および*世代資格を与える人(例えば、「Jr.」、「3番目」、または「IV」)。
The syntax and associated object identifiers (OIDs) for these attribute types are provided in the ASN.1 modules in Appendix A.
これらの属性タイプへの構文と関連オブジェクト識別子(OIDs)をAppendix AのASN.1モジュールに提供します。
In addition, implementations of this specification MUST be prepared to receive the domainComponent attribute, as defined in [RFC4519]. The Domain Name System (DNS) provides a hierarchical resource labeling system. This attribute provides a convenient mechanism for organizations that wish to use DNs that parallel their DNS names. This is not a replacement for the dNSName component of the alternative name extensions. Implementations are not required to
追加、仕様を準備しなければならないこの実装では、[RFC4519]で定義されるようにdomainComponent属性を受けてください。 ドメインネームシステム(DNS)は階層的なリソースラベリングシステムを提供します。 この属性は彼らのDNS名に沿うDNsを使用したがっている組織に便利なメカニズムを提供します。 これは拡大という代替名のdNSNameの部品への交換ではありません。 実装は必要ではありません。
Cooper, et al. Standards Track [Page 21] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[21ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
convert such names into DNS names. The syntax and associated OID for this attribute type are provided in the ASN.1 modules in Appendix A. Rules for encoding internationalized domain names for use with the domainComponent attribute type are specified in Section 7.3.
そのような名前をDNS名に変換してください。 この属性タイプのための構文と関連OIDはdomainComponent属性タイプで使用のための国際化ドメイン名をコード化するためのAppendix A.Rulesの.1のモジュールがセクション7.3でASNでは、指定されるかどうかということです。
Certificate users MUST be prepared to process the issuer distinguished name and subject distinguished name (Section 4.1.2.6) fields to perform name chaining for certification path validation (Section 6). Name chaining is performed by matching the issuer distinguished name in one certificate with the subject name in a CA certificate. Rules for comparing distinguished names are specified in Section 7.1. If the names in the issuer and subject field in a certificate match according to the rules specified in Section 7.1, then the certificate is self-issued.
証明書ユーザが発行人分類名と対象の分類名を処理する用意ができていなければならない、(セクション4.1 .2 実行する.6の)分野が証明経路合法化のために鎖を作るのを(セクション6)と命名します。 名前推論は、1通の証明書の発行人分類名をカリフォルニア証明書の対象の名前に合わせることによって、実行されます。 分類名を比較するための規則はセクション7.1で指定されます。 規則に従った証明書マッチの発行人と対象の分野の名前がセクション7.1で指定したなら、自己に証明書を発行します。
4.1.2.5. Validity
4.1.2.5. 正当性
The certificate validity period is the time interval during which the CA warrants that it will maintain information about the status of the certificate. The field is represented as a SEQUENCE of two dates: the date on which the certificate validity period begins (notBefore) and the date on which the certificate validity period ends (notAfter). Both notBefore and notAfter may be encoded as UTCTime or GeneralizedTime.
証明書有効期間はカリフォルニアが証明書の状態の情報を保守するのを保証する時間間隔です。 2のSEQUENCEがデートするとき、分野は表されます: 証明書有効期間が始まる日付(notBefore)と証明書有効期間が終わる日付(notAfter)。 notBeforeとnotAfterの両方がUTCTimeかGeneralizedTimeとしてコード化されるかもしれません。
CAs conforming to this profile MUST always encode certificate validity dates through the year 2049 as UTCTime; certificate validity dates in 2050 or later MUST be encoded as GeneralizedTime. Conforming applications MUST be able to process validity dates that are encoded in either UTCTime or GeneralizedTime.
このプロフィールに従うCAsはUTCTimeとしていつも証明書使用期限から2049年をコード化しなければなりません。 2050か後でGeneralizedTimeとして証明書使用期限をコード化しなければなりません。 アプリケーションを従わせると、UTCTimeかGeneralizedTimeのどちらかでコード化される使用期限は処理できなければなりません。
The validity period for a certificate is the period of time from notBefore through notAfter, inclusive.
証明書のための有効期間はnotBeforeからnotAfterの期間です。包括的。
In some situations, devices are given certificates for which no good expiration date can be assigned. For example, a device could be issued a certificate that binds its model and serial number to its public key; such a certificate is intended to be used for the entire lifetime of the device.
いくつかの状況で、どんな良い有効期限も割り当てることができない証明書をデバイスに与えます。 例えば、そのモデルと通し番号を公開鍵に縛る証明書はデバイスに発行できました。 そのような証明書によってデバイスの全体の生涯に使用されることを意図します。
To indicate that a certificate has no well-defined expiration date, the notAfter SHOULD be assigned the GeneralizedTime value of 99991231235959Z.
証明書には明確な有効期限がない、notAfter SHOULDがあるのを示すには、99991231235959ZのGeneralizedTime値は割り当てられてください。
When the issuer will not be able to maintain status information until the notAfter date (including when the notAfter date is 99991231235959Z), the issuer MUST ensure that no valid certification path exists for the certificate after maintenance of status
notAfterがデートするまで(いつnotAfter日付が99991231235959Zであるかを含んでいて)発行人が状態情報を保守できないとき、発行人は、どんな有効な証明経路も状態のメインテナンスの後に証明書のために存在しないのを確実にしなければなりません。
Cooper, et al. Standards Track [Page 22] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[22ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
information is terminated. This may be accomplished by expiration or revocation of all CA certificates containing the public key used to verify the signature on the certificate and discontinuing use of the public key used to verify the signature on the certificate as a trust anchor.
情報は終えられます。 公開鍵を含むすべてのカリフォルニア証明書の取消しは以前は証明書の上によく署名について確かめていました、そして、これが満了で達成されるかもしれませんか、または公開鍵の使用を中止すると、署名は以前は証明書の上に信頼アンカーがよく確かめられていました。
4.1.2.5.1. UTCTime
4.1.2.5.1. UTCTime
The universal time type, UTCTime, is a standard ASN.1 type intended for representation of dates and time. UTCTime specifies the year through the two low-order digits and time is specified to the precision of one minute or one second. UTCTime includes either Z (for Zulu, or Greenwich Mean Time) or a time differential.
ユニバーサルタイムタイプ(UTCTime)は日付と時間の表現のために意図する標準のASN.1タイプです。 UTCTimeは2つの下位桁を通して1年を指定します、そして、時間は微小な1秒か1秒の精度に指定されます。 UTCTimeはZ(ズールー族、またはグリニッジ標準時の間の)か時間デフ装置のどちらかを含んでいます。
For the purposes of this profile, UTCTime values MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming systems MUST interpret the year field (YY) as follows:
このプロフィールの目的のために、UTCTime値は、グリニッジ標準時(ズールー族)に表さなければならなくて、秒を含まなければなりません(すなわち、回はYYMMDDHHMMSSZです)、秒数がゼロでさえあるところで。 従うシステムは以下の1年の分野(YY)を解釈しなければなりません:
Where YY is greater than or equal to 50, the year SHALL be
interpreted as 19YY; and
どこYYは50以上、1年のSHALLであるか。19YYとして、解釈されてください。 そして
Where YY is less than 50, the year SHALL be interpreted as 20YY.
YYが50、1年のSHALL以下であるところでは、20YYとして解釈されてください。
4.1.2.5.2. GeneralizedTime
4.1.2.5.2. GeneralizedTime
The generalized time type, GeneralizedTime, is a standard ASN.1 type for variable precision representation of time. Optionally, the GeneralizedTime field can include a representation of the time differential between local and Greenwich Mean Time.
一般化された時間タイプ(GeneralizedTime)は時間の可変精度表現のための標準のASN.1タイプです。 任意に、GeneralizedTime分野は地方の間で特異な時間とグリニッジ標準時の表現を含むことができます。
For the purposes of this profile, GeneralizedTime values MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds.
このプロフィールの目的のために、GeneralizedTime値は、グリニッジ標準時(ズールー族)に表さなければならなくて、秒を含まなければなりません(すなわち、回はYYYYMMDDHHMMSSZです)、秒数がゼロでさえあるところで。 GeneralizedTime値は断片的な秒を含んではいけません。
4.1.2.6. Subject
4.1.2.6. 対象
The subject field identifies the entity associated with the public key stored in the subject public key field. The subject name MAY be carried in the subject field and/or the subjectAltName extension. If the subject is a CA (e.g., the basic constraints extension, as discussed in Section 4.2.1.9, is present and the value of cA is TRUE), then the subject field MUST be populated with a non-empty distinguished name matching the contents of the issuer field (Section 4.1.2.4) in all certificates issued by the subject CA. If the subject is a CRL issuer (e.g., the key usage extension, as discussed in Section 4.2.1.3, is present and the value of cRLSign is TRUE),
対象の分野は対象の公開鍵分野に保存される公開鍵に関連している実体を特定します。 対象の名前は対象の分野、そして/または、subjectAltName拡張子で運ばれるかもしれません。 非空の分類名が発行人分野のコンテンツに合っていて対象がaカリフォルニア(例えば、基本的な規制拡大はセクション4.2.1で.9について議論するので、存在しています、そして、cAの値はTRUEである)であるなら対象の分野に居住しなければならない、(セクション4.1 .2 .4) 対象のカリフォルニアによって発行されたすべての証明書で。 対象がCRL発行人(例えば、主要な用法拡大はセクション4.2.1で.3について議論するので、存在しています、そして、cRLSignの値はTRUEである)であるなら
Cooper, et al. Standards Track [Page 23] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[23ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
then the subject field MUST be populated with a non-empty distinguished name matching the contents of the issuer field (Section 5.1.2.3) in all CRLs issued by the subject CRL issuer. If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical.
次に、非空の分類名が発行人分野のコンテンツに合っていて対象の分野に居住しなければならない、(セクション5.1 .2 .3) 対象のCRL発行人によって発行されたすべてのCRLsで。 対象の命名情報がsubjectAltName拡張子だけで存在しているなら(例えばキーはEメールアドレスかURIだけに固まりました)、対象の名前は空の系列であるに違いありません、そして、subjectAltName拡張子は重要であるに違いありません。
Where it is non-empty, the subject field MUST contain an X.500 distinguished name (DN). The DN MUST be unique for each subject entity certified by the one CA as defined by the issuer field. A CA MAY issue more than one certificate with the same DN to the same subject entity.
それが非空であるところでは、対象の分野はX.500分類名(DN)を含まなければなりません。 DN MUST、発行人分野によって定義されるようにもののカリフォルニアによって公認されたそれぞれの対象の実体において、ユニークであってください。 カリフォルニアは同じDNと共に同じ対象の実体に1通以上の証明書を発行するかもしれません。
The subject field is defined as the X.501 type Name. Implementation requirements for this field are those defined for the issuer field (Section 4.1.2.4). Implementations of this specification MUST be prepared to receive subject names containing the attribute types required for the issuer field. Implementations of this specification SHOULD be prepared to receive subject names containing the recommended attribute types for the issuer field. The syntax and associated object identifiers (OIDs) for these attribute types are provided in the ASN.1 modules in Appendix A. Implementations of this specification MAY use the comparison rules in Section 7.1 to process unfamiliar attribute types (i.e., for name chaining) whose attribute values use one of the encoding options from DirectoryString. Binary comparison should be used when unfamiliar attribute types include attribute values with encoding options other than those found in DirectoryString. This allows implementations to process certificates with unfamiliar attributes in the subject name.
対象の分野はX.501タイプNameと定義されます。 この分野のための実装要件が発行人分野と定義されたものである、(セクション4.1 .2 .4)。 発行人分野に必要である属性タイプを含む対象の名前を受け取るようにこの仕様の実装を準備しなければなりません。 実装、この仕様SHOULDでは、発行人分野のためのお勧めの属性タイプを含む対象の名前を受け取るように用意してください。 これらの属性タイプへの構文と関連オブジェクト識別子(OIDs)はASNでは、この仕様のAppendix A.Implementationsの.1のモジュールが属性値がDirectoryStringからコード化オプションの1つを使用するなじみのない属性タイプ(すなわち、名前推論のための)を処理するのにセクション7.1の比較規則を使用するかもしれないかどうかということです。 なじみのない属性タイプがそれら以外のオプションをコード化するDirectoryStringで見つけられる属性値を入れるとき、2進の比較は使用されるべきです。 これで、なじみのない属性が対象の名前にある状態で、実装は証明書を処理できます。
When encoding attribute values of type DirectoryString, conforming CAs MUST use PrintableString or UTF8String encoding, with the following exceptions:
タイプDirectoryStringの属性値をコード化するとき、CAsを従わせると、以下の例外で以下をコード化するPrintableStringかUTF8Stringが使用されなければなりません。
(a) When the subject of the certificate is a CA, the subject
field MUST be encoded in the same way as it is encoded in the
issuer field (Section 4.1.2.4) in all certificates issued by
the subject CA. Thus, if the subject CA encodes attributes
in the issuer fields of certificates that it issues using the
TeletexString, BMPString, or UniversalString encodings, then
the subject field of certificates issued to that CA MUST use
the same encoding.
(a) 証明書の対象がカリフォルニアであるときに、それが発行人分野でコード化されるのと同様に、対象の分野をコード化しなければならない、(セクション4.1 .2 .4) 対象のカリフォルニアによって発行されたすべての証明書で。 したがって、対象のカリフォルニアがそれが発行する証明書の発行人分野でTeletexString、BMPString、またはUniversalString encodingsを使用することで属性をコード化するなら、そのカリフォルニアに発行された証明書の対象の分野は同じコード化を使用しなければなりません。
(b) When the subject of the certificate is a CRL issuer, the
subject field MUST be encoded in the same way as it is
encoded in the issuer field (Section 5.1.2.3) in all CRLs
issued by the subject CRL issuer.
(b) 証明書の対象がCRL発行人であるときに、それが発行人分野でコード化されるのと同様に、対象の分野をコード化しなければならない、(セクション5.1 .2 .3) 対象のCRL発行人によって発行されたすべてのCRLsで。
Cooper, et al. Standards Track [Page 24] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[24ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
(c) TeletexString, BMPString, and UniversalString are included
for backward compatibility, and SHOULD NOT be used for
certificates for new subjects. However, these types MAY be
used in certificates where the name was previously
established, including cases in which a new certificate is
being issued to an existing subject or a certificate is being
issued to a new subject where the attributes being encoded
have been previously established in certificates issued to
other subjects. Certificate users SHOULD be prepared to
receive certificates with these types.
(c) TeletexString、BMPString、およびUniversalStringは後方の互換性、およびSHOULD NOTのために含まれています。新しい対象のための証明書のために、使用されます。 しかしながら、これらのタイプは名前が以前に確立された証明書で使用されるかもしれません、既存の対象に新しい証明書を発行しているか、またはコード化される属性が以前に他の対象に発行された証明書に確立された新しい対象に証明書を発行している場合を含んでいて。 これらのタイプで証明書を受け取るために準備されていて、ユーザSHOULDを証明してください。
Legacy implementations exist where an electronic mail address is embedded in the subject distinguished name as an emailAddress attribute [RFC2985]. The attribute value for emailAddress is of type IA5String to permit inclusion of the character '@', which is not part of the PrintableString character set. emailAddress attribute values are not case-sensitive (e.g., "subscriber@example.com" is the same as "SUBSCRIBER@EXAMPLE.COM").
emailAddressが[RFC2985]を結果と考えるとき、レガシー実装は電子メールアドレスが対象の分類名に埋め込まれているところに存在しています。 emailAddressのための属性値は、キャラクタ'@'の包含を可能にするためにはタイプIA5Stringのものです。(包含はPrintableString文字集合の一部ではありません)。emailAddress属性値は大文字と小文字を区別していません(例えば、" subscriber@example.com "は" SUBSCRIBER@EXAMPLE.COM "と同じです)。
Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name extension (Section 4.2.1.6) to describe such identities. Simultaneous inclusion of the emailAddress attribute in the subject distinguished name to support legacy implementations is deprecated but permitted.
新しい証明書を作る実装を電子メールアドレスに一致させるとrfc822Nameが拡大という対象の代替名に使用されなければならない、(セクション4.2 .1 .6) そのようなアイデンティティについて説明するために。 レガシー実装をサポートする対象の分類名でのemailAddress属性の同時の包含は、推奨しないのですが、受入れられます。
4.1.2.7. Subject Public Key Info
4.1.2.7. 対象の公開鍵インフォメーション
This field is used to carry the public key and identify the algorithm with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The algorithm is identified using the AlgorithmIdentifier structure specified in Section 4.1.1.2. The object identifiers for the supported algorithms and the methods for encoding the public key materials (public key and parameters) are specified in [RFC3279], [RFC4055], and [RFC4491].
この分野は、公開鍵を運んで、キーが使用されているアルゴリズム(例えば、RSA、DSA、またはディフィー-ヘルマン)を特定するのに使用されます。 アルゴリズムは、セクション4.1.1で.2に指定されたAlgorithmIdentifier構造を使用することで特定されます。 サポートしているアルゴリズムのためのオブジェクト識別子と公開鍵の材料(公開鍵とパラメタ)をコード化するためのメソッドは[RFC3279]、[RFC4055]、および[RFC4491]で指定されます。
4.1.2.8. Unique Identifiers
4.1.2.8. ユニークな識別子
These fields MUST only appear if the version is 2 or 3 (Section 4.1.2.1). These fields MUST NOT appear if the version is 1. The subject and issuer unique identifiers are present in the certificate to handle the possibility of reuse of subject and/or issuer names over time. This profile RECOMMENDS that names not be reused for different entities and that Internet certificates not make use of unique identifiers. CAs conforming to this profile MUST NOT generate certificates with unique identifiers. Applications conforming to
これらの野原がバージョンが2か3であるなら現れるだけでよい、(セクション4.1 .2 .1)。 これらの野原はバージョンが1であるなら現れてはいけません。 対象と発行人のユニークな識別子は時間がたつにつれて対象、そして/または、発行人名の再利用の可能性を扱う証明書に存在しています。 これは名前がないRECOMMENDSの証明書がユニークな識別子の使用を作らない異なった実体とそのインターネットに再利用されていた状態で輪郭を描きます。 このプロフィールに従うCAsはユニークな識別子で証明書を作ってはいけません。 アプリケーション、従います。
Cooper, et al. Standards Track [Page 25] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[25ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
this profile SHOULD be capable of parsing certificates that include unique identifiers, but there are no processing requirements associated with the unique identifiers.
要件を処理しないユニークな識別子を含んでいる構文解析証明書ができますが、あるこのプロフィールSHOULDがユニークな識別子と交際しました。
4.1.2.9. Extensions
4.1.2.9. 拡大
This field MUST only appear if the version is 3 (Section 4.1.2.1). If present, this field is a SEQUENCE of one or more certificate extensions. The format and content of certificate extensions in the Internet PKI are defined in Section 4.2.
この野原がバージョンが3であるなら現れるだけでよい、(セクション4.1 .2 .1)。 存在しているなら、この分野は1つ以上の証明書拡張子のSEQUENCEです。 インターネットPKIの証明書拡張子の書式と内容はセクション4.2で定義されます。
4.2. Certificate Extensions
4.2. 証明書拡張子
The extensions defined for X.509 v3 certificates provide methods for associating additional attributes with users or public keys and for managing relationships between CAs. The X.509 v3 certificate format also allows communities to define private extensions to carry information unique to those communities. Each extension in a certificate is designated as either critical or non-critical. A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized. The following sections present recommended extensions used within Internet certificates and standard locations for information. Communities may elect to use additional extensions; however, caution ought to be exercised in adopting any critical extensions in certificates that might prevent use in a general context.
X.509 v3証明書のために定義された拡大は追加属性をユーザか公開鍵に関連づけて、CAsの間の関係を管理するためのメソッドを提供します。 また、X.509 v3証明書形式で、共同体は、それらの共同体にユニークな情報を運ぶために個人的な拡大を定義できます。 証明書における各拡大は重要であるか非臨界であるとして指定されます。 それが認識しない重要な拡大か処理できないという情報を含む重要な拡大に遭遇するなら、証明書を使用するシステムは証明書を拒絶しなければなりません。 非臨界拡大をそれが認識されないなら無視されるかもしれませんが、それが認識されるなら、処理しなければなりません。 以下のセクションプレゼントは情報にインターネット証明書と標準の位置の中で使用された拡張子を推薦しました。 共同体は、追加拡張子を使用するのを選ぶかもしれません。 しかしながら、警告は一般情勢における使用を防ぐかもしれない証明書におけるどんな重要な拡大も採用するのに訓練されるべきです。
Each extension includes an OID and an ASN.1 structure. When an extension appears in a certificate, the OID appears as the field extnID and the corresponding ASN.1 DER encoded structure is the value of the octet string extnValue. A certificate MUST NOT include more than one instance of a particular extension. For example, a certificate may contain only one authority key identifier extension (Section 4.2.1.1). An extension includes the boolean critical, with a default value of FALSE. The text for each extension specifies the acceptable values for the critical field for CAs conforming to this profile.
各拡大はOIDとASN.1構造を含んでいます。 拡大が証明書、OIDが分野extnIDとして現れて、対応するASN.1DERがコード化したコネに現れるとき、構造は八重奏ストリングextnValueの値です。 証明書は特定の拡大の1つ以上のインスタンスを含んではいけません。 例えば、証明書が1つの権威の主要な識別子拡張子だけを含むかもしれない、(セクション4.2 .1 .1)。 拡大はFALSEのデフォルト値で重要な論理演算子を含んでいます。 各拡大のためのテキストはこのプロフィールに従うCAsとして臨界磁場に許容値を指定します。
Conforming CAs MUST support key identifiers (Sections 4.2.1.1 and 4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section 4.2.1.3), and certificate policies (Section 4.2.1.4) extensions. If the CA issues certificates with an empty sequence for the subject field, the CA MUST support the subject alternative name extension (Section 4.2.1.6). Support for the remaining extensions is OPTIONAL. Conforming CAs MAY support extensions that are not identified within
4.2の.1の.3、)および証明書方針を区分してください。CAsを従わせると主要な識別子がサポートしなければならない、(セクション4.2.1、.1と4.2、.1、.2、)基本的な規制、(セクション4.2 .1 .9、)主要な用法、((セクション4.2.1の.4)拡大。 カリフォルニアが空の系列で対象の分野に証明書を発行するなら、カリフォルニアが、対象が代替の名前拡大であるとサポートしなければならない、(セクション4.2 .1 .6)。 残っている拡大のサポートはOPTIONALです。 CAsが中で特定されない拡大をサポートするかもしれない従うこと
Cooper, et al. Standards Track [Page 26] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[26ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
this specification; certificate issuers are cautioned that marking such extensions as critical may inhibit interoperability.
この仕様。 証明書発行人は重要であるような拡大をマークすると相互運用性が禁止されるかもしれないと警告されます。
At a minimum, applications conforming to this profile MUST recognize the following extensions: key usage (Section 4.2.1.3), certificate policies (Section 4.2.1.4), subject alternative name (Section 4.2.1.6), basic constraints (Section 4.2.1.9), name constraints (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended key usage (Section 4.2.1.12), and inhibit anyPolicy (Section 4.2.1.14).
最小限では、このプロフィールに従うアプリケーションは以下の拡大を認識しなければなりません: 主要な用法、(セクション4.2 .1 .3、)方針を証明してください、(セクション4.2.1、.4、)対象の代替名、(セクション4.2 .1 .6、)基本的な規制、(セクション4.2 .1 .9、)規制を命名してください、(セクション4.2 .1 .10、)方針規制、(セクション4.2.1、.11、)拡張主要な用法、(セクション4.2 .1 .12、)anyPolicyを禁止してください、(セクション4.2 .1 .14)。
In addition, applications conforming to this profile SHOULD recognize the authority and subject key identifier (Sections 4.2.1.1 and 4.2.1.2) and policy mappings (Section 4.2.1.5) extensions.
さらに、このプロフィールSHOULDに従うアプリケーションが権威と対象の主要な識別子を認識する、(セクション4.2.1、.1と4.2の.1の.2と)方針マッピング、(セクション4.2.1の.5)拡大。
4.2.1. Standard Extensions
4.2.1. 標準の拡大
This section identifies standard certificate extensions defined in [X.509] for use in the Internet PKI. Each extension is associated with an OID defined in [X.509]. These OIDs are members of the id-ce arc, which is defined by the following:
このセクションはインターネットPKIでの使用のために[X.509]で定義された標準の証明書拡張子を特定します。 それぞれの拡大は[X.509]で定義されるOIDに関連しています。 これらのOIDsはイドCeアークのメンバーです:(アークは以下によって定義されます)。
id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }
イドCe OBJECT IDENTIFIER:、:= 共同iso-ccitt(2) ds(5)29
4.2.1.1. Authority Key Identifier
4.2.1.1. 権威の主要な識別子
The authority key identifier extension provides a means of identifying the public key corresponding to the private key used to sign a certificate. This extension is used where an issuer has multiple signing keys (either due to multiple concurrent key pairs or due to changeover). The identification MAY be based on either the key identifier (the subject key identifier in the issuer's certificate) or the issuer name and serial number.
権威の主要な識別子拡張子は証明書に署名するのに使用される秘密鍵に対応する公開鍵を特定する手段を提供します。 この拡張子は発行人が複数の署名キー(複数の同時発生の主要な組のためか転換のため)を持っているところで使用されます。 識別は発行人名と主要な識別子(発行人の証明書の対象の主要な識別子)か通し番号のどちらかに基づくかもしれません。
The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate certification path construction. There is one exception; where a CA distributes its public key in the form of a "self-signed" certificate, the authority key identifier MAY be omitted. The signature on a self-signed certificate is generated with the private key associated with the certificate's subject public key. (This proves that the issuer possesses both the public and private keys.) In this case, the subject and authority key identifiers would be identical, but only the subject key identifier is needed for certification path building.
証明経路工事を容易にするためにCAsを従わせることによって作られたすべての証明書にauthorityKeyIdentifier拡張子のkeyIdentifier分野を含まなければなりません。 1つの例外があります。 カリフォルニアが「自己によって署名している」証明書の形で公開鍵を分配するところでは、権威の主要な識別子は省略されるかもしれません。 自己署名入りの証書における署名は証明書の対象の公開鍵に関連している秘密鍵で生成されます。 (これは、発行人には公衆と秘密鍵の両方があると立証します。) この場合、対象と権威重要識別子は同じでしょうが、対象の主要な識別子だけが証明経路ビルに必要です。
The value of the keyIdentifier field SHOULD be derived from the public key used to verify the certificate's signature or a method
keyIdentifierの値は証明書の署名かメソッドを確かめるのに使用される公開鍵から派生していた状態でSHOULDをさばきます。
Cooper, et al. Standards Track [Page 27] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[27ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
that generates unique values. Two common methods for generating key identifiers from the public key are described in Section 4.2.1.2. Where a key identifier has not been previously established, this specification RECOMMENDS use of one of these methods for generating keyIdentifiers or use of a similar method that uses a different hash algorithm. Where a key identifier has been previously established, the CA SHOULD use the previously established identifier.
それはユニークな値を生成します。 公開鍵からの主要な識別子を生成するための2つの共通方法がセクション4.2.1で.2に説明されます。 主要な識別子が以前に確立されていないところでは、これらのメソッドの1つのkeyIdentifiersを生成するこの仕様RECOMMENDS使用か異なったハッシュアルゴリズムを使用する同様のメソッドを使用します。 主要な識別子が以前に確立されたところでは、CA SHOULDは以前に確立した識別子を使用します。
This profile RECOMMENDS support for the key identifier method by all certificate users.
このプロフィールRECOMMENDSは主要な識別子メソッドのためにすべての証明書でユーザをサポートします。
Conforming CAs MUST mark this extension as non-critical.
CAsを従わせると、この拡大は非臨界であるとしてマークされなければなりません。
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
イドCe authorityKeyIdentifier、オブジェクト識別子:、:= イドCe35
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNames OPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
AuthorityKeyIdentifier:、:= 系列keyIdentifier[0]KeyIdentifierの任意の、そして、authorityCertIssuer[1]GeneralNames任意のauthorityCertSerialNumber[2]CertificateSerialNumber任意
KeyIdentifier ::= OCTET STRING
KeyIdentifier:、:= 八重奏ストリング
4.2.1.2. Subject Key Identifier
4.2.1.2. 対象の主要な識別子
The subject key identifier extension provides a means of identifying certificates that contain a particular public key.
対象の主要な識別子拡張子は特定の公開鍵を含む証明書を特定する手段を提供します。
To facilitate certification path construction, this extension MUST appear in all conforming CA certificates, that is, all certificates including the basic constraints extension (Section 4.2.1.9) where the value of cA is TRUE. In conforming CA certificates, the value of the subject key identifier MUST be the value placed in the key identifier field of the authority key identifier extension (Section 4.2.1.1) of certificates issued by the subject of this certificate. Applications are not required to verify that key identifiers match when performing certification path validation.
カリフォルニア証明書、すなわち、すべての証明書を従わせて、基本的な規制拡大を含んでいて、証明経路工事を容易にするために、この拡大がすべてに現れなければならない、(セクション4.2 .1 .9) cAの値がTRUEであるところ。 カリフォルニア証明書を従わせることにおいて、対象の主要な識別子の値は権威の主要な識別子拡張子の主要な識別子分野に置かれた値でなければなりません。(.1通の証明書が)この証明書の対象で発行したセクション4.2.1。 アプリケーションは、証明経路合法化を実行するとき、主要な識別子が合っていることを確かめるのに必要ではありません。
For CA certificates, subject key identifiers SHOULD be derived from the public key or a method that generates unique values. Two common methods for generating key identifiers from the public key are:
カリフォルニア証明書に関しては、ユニークな値を生成する公開鍵かメソッドから派生していた状態で主要な識別子SHOULDをかけてください。 公開鍵からの主要な識別子を生成するための2つの共通方法は以下の通りです。
(1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
value of the BIT STRING subjectPublicKey (excluding the tag,
length, and number of unused bits).
(1) keyIdentifierはBIT STRING subjectPublicKey(未使用のビットのタグ、長さ、および数を除いた)の価値の160ビットのSHA-1ハッシュで構成されます。
Cooper, et al. Standards Track [Page 28] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[28ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
(2) The keyIdentifier is composed of a four-bit type field with
the value 0100 followed by the least significant 60 bits of
the SHA-1 hash of the value of the BIT STRING
subjectPublicKey (excluding the tag, length, and number of
unused bits).
(2) keyIdentifierはBIT STRING subjectPublicKey(未使用のビットのタグ、長さ、および数を除いた)の価値のSHA-1ハッシュの最も重要でない60ビットに従って0100が続いた値で4ビットのタイプ分野から構成されます。
Other methods of generating unique numbers are also acceptable.
また、ユニークな数を生成する他のメソッドも許容できます。
For end entity certificates, the subject key identifier extension provides a means for identifying certificates containing the particular public key used in an application. Where an end entity has obtained multiple certificates, especially from multiple CAs, the subject key identifier provides a means to quickly identify the set of certificates containing a particular public key. To assist applications in identifying the appropriate end entity certificate, this extension SHOULD be included in all end entity certificates.
終わりの実体証明書のために、対象の主要な識別子拡張子はアプリケーションで使用される特定の公開鍵を含む証明書を特定するための手段を提供します。 終わりの実体が特に複数のCAsから複数の証明書を入手したところに、対象の主要な識別子はすぐに特定の公開鍵を含む証明書のセットを特定する手段を提供します。 適切な終わりの実体証明書、この拡大SHOULDを特定するのにアプリケーションを助けるには、すべての終わりの実体証明書で含められてください。
For end entity certificates, subject key identifiers SHOULD be derived from the public key. Two common methods for generating key identifiers from the public key are identified above.
終わりの実体証明書に関しては、公開鍵から派生していた状態で主要な識別子SHOULDをかけてください。 公開鍵からの主要な識別子を生成するための2つの共通方法が上で特定されます。
Where a key identifier has not been previously established, this specification RECOMMENDS use of one of these methods for generating keyIdentifiers or use of a similar method that uses a different hash algorithm. Where a key identifier has been previously established, the CA SHOULD use the previously established identifier.
主要な識別子が以前に確立されていないところでは、これらのメソッドの1つのkeyIdentifiersを生成するこの仕様RECOMMENDS使用か異なったハッシュアルゴリズムを使用する同様のメソッドを使用します。 主要な識別子が以前に確立されたところでは、CA SHOULDは以前に確立した識別子を使用します。
Conforming CAs MUST mark this extension as non-critical.
CAsを従わせると、この拡大は非臨界であるとしてマークされなければなりません。
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
イドCe subjectKeyIdentifier、オブジェクト識別子:、:= イドCe14
SubjectKeyIdentifier ::= KeyIdentifier
SubjectKeyIdentifier:、:= KeyIdentifier
4.2.1.3. Key Usage
4.2.1.3. 主要な用法
The key usage extension defines the purpose (e.g., encipherment, signature, certificate signing) of the key contained in the certificate. The usage restriction might be employed when a key that could be used for more than one operation is to be restricted. For example, when an RSA key should be used only to verify signatures on objects other than public key certificates and CRLs, the digitalSignature and/or nonRepudiation bits would be asserted. Likewise, when an RSA key should be used only for key management, the keyEncipherment bit would be asserted.
主要な用法拡大は証明書に含まれたキーの目的(例えば、暗号文、署名は署名を証明する)を定義します。 1つ以上の操作に使用できたキーが制限されることになっているとき、用法制限は使われるかもしれません。 例えば、RSAキーが使用されるべきですが、公開鍵証明書とCRLs以外のオブジェクトの上に署名について確かめるとき、digitalSignature、そして/または、nonRepudiationビットは断言されるでしょう。 RSAキーがかぎ管理にだけ使用されるべきであるとき、同様に、keyEnciphermentビットは断言されるでしょう。
Cooper, et al. Standards Track [Page 29] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[29ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
Conforming CAs MUST include this extension in certificates that contain public keys that are used to validate digital signatures on other public key certificates or CRLs. When present, conforming CAs SHOULD mark this extension as critical.
CAsを従わせると、この拡大は他の公開鍵の証明書かCRLsでデジタル署名を有効にするのに使用される公開鍵を含む証明書が包含しなければなりません。 現在の、そして、従っているCAs SHOULDが重要であるとしてこの拡大をマークすると。
id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
イドCe keyUsage、オブジェクト識別子:、:= イドCe15
KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1), -- recent editions of X.509 have
-- renamed this bit to contentCommitment
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5),
cRLSign (6),
encipherOnly (7),
decipherOnly (8) }
KeyUsage:、:= ビット列digitalSignature(0)(X.509の最新号がそうしたというnonRepudiation(1))はcontentCommitment keyEnciphermentへのこのビットを(2)に改名しました、dataEncipherment(3)、keyAgreement(4)、keyCertSign(5)、cRLSign(6)、encipherOnly(7)、decipherOnly(8)
Bits in the KeyUsage type are used as follows:
KeyUsageタイプのビットは以下の通り使用されます:
The digitalSignature bit is asserted when the subject public key
is used for verifying digital signatures, other than signatures on
certificates (bit 5) and CRLs (bit 6), such as those used in an
entity authentication service, a data origin authentication
service, and/or an integrity service.
対象の公開鍵がデジタル署名について確かめるのに使用されるとき、digitalSignatureビットは断言されます、証明書における署名(ビット5)とCRLs(ビット6)を除いて、実体認証サービス、データ発生源認証サービス、そして/または、保全サービスに使用されるものなどのように。
The nonRepudiation bit is asserted when the subject public key is
used to verify digital signatures, other than signatures on
certificates (bit 5) and CRLs (bit 6), used to provide a non-
repudiation service that protects against the signing entity
falsely denying some action. In the case of later conflict, a
reliable third party may determine the authenticity of the signed
data. (Note that recent editions of X.509 have renamed the
nonRepudiation bit to contentCommitment.)
対象の公開鍵がデジタル署名について確かめるのに使用されるとき、nonRepudiationビットは断言されます、証明書における署名(ビット5)とCRLs(ビット6)を除いて、間違って何らかの動作を否定する署名実体から守る非拒否しているサービスを提供するのにおいて、使用されています。 後の闘争の場合では、頼もしい第三者は署名しているデータの信憑性を決定するかもしれません。 (X.509の最新号がnonRepudiationビットをcontentCommitmentに改名したことに注意してください。)
The keyEncipherment bit is asserted when the subject public key is
used for enciphering private or secret keys, i.e., for key
transport. For example, this bit shall be set when an RSA public
key is to be used for encrypting a symmetric content-decryption
key or an asymmetric private key.
対象の公開鍵が個人的であるか秘密のキーを暗号化するのに使用されるとき、keyEnciphermentビットは断言されます、すなわち、主要な輸送のために。 例えば、RSA公開鍵が左右対称の満足している復号化キーか非対称の秘密鍵を暗号化するのに使用されることであるときに、このビットは設定されるものとします。
The dataEncipherment bit is asserted when the subject public key
is used for directly enciphering raw user data without the use of
an intermediate symmetric cipher. Note that the use of this bit
is extremely uncommon; almost all applications use key transport
or key agreement to establish a symmetric key.
対象の公開鍵が中間的左右対称の暗号の使用なしで生の利用者データを直接暗号化するのに使用されるとき、dataEnciphermentビットは断言されます。 このビットの使用が非常に珍しいことに注意してください。 ほとんどすべてのアプリケーションが主要な輸送か対称鍵を確立する主要な協定を使用します。
Cooper, et al. Standards Track [Page 30] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[30ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
The keyAgreement bit is asserted when the subject public key is
used for key agreement. For example, when a Diffie-Hellman key is
to be used for key management, then this bit is set.
対象の公開鍵が主要な協定に使用されるとき、keyAgreementビットは断言されます。 例えば、そして、ディフィー-ヘルマンキーがかぎ管理に使用されることになっているとき、このビットは設定されます。
The keyCertSign bit is asserted when the subject public key is
used for verifying signatures on public key certificates. If the
keyCertSign bit is asserted, then the cA bit in the basic
constraints extension (Section 4.2.1.9) MUST also be asserted.
対象の公開鍵が公開鍵証明書の上に署名について確かめるのに使用されるとき、keyCertSignビットは断言されます。 keyCertSignビットが断言されるならcAが基本的な規制拡大で噛み付いた、(セクション4.2 .1 また、.9について)断言しなければなりません。
The cRLSign bit is asserted when the subject public key is used
for verifying signatures on certificate revocation lists (e.g.,
CRLs, delta CRLs, or ARLs).
対象の公開鍵が証明書失効リスト(例えば、CRLs、デルタCRLs、またはARLs)で署名について確かめるのに使用されるとき、cRLSignビットは断言されます。
The meaning of the encipherOnly bit is undefined in the absence of
the keyAgreement bit. When the encipherOnly bit is asserted and
the keyAgreement bit is also set, the subject public key may be
used only for enciphering data while performing key agreement.
encipherOnlyビットの意味はkeyAgreementビットがないとき未定義です。 encipherOnlyビットが断言されて、また、keyAgreementビットが設定されるとき、対象の公開鍵は、主要な協定を実行している間、データを暗号化するのにだけ使用されるかもしれません。
The meaning of the decipherOnly bit is undefined in the absence of
the keyAgreement bit. When the decipherOnly bit is asserted and
the keyAgreement bit is also set, the subject public key may be
used only for deciphering data while performing key agreement.
decipherOnlyビットの意味はkeyAgreementビットがないとき未定義です。 decipherOnlyビットが断言されて、また、keyAgreementビットが設定されるとき、対象の公開鍵は、主要な協定を実行している間、データを解読するのにだけ使用されるかもしれません。
If the keyUsage extension is present, then the subject public key MUST NOT be used to verify signatures on certificates or CRLs unless the corresponding keyCertSign or cRLSign bit is set. If the subject public key is only to be used for verifying signatures on certificates and/or CRLs, then the digitalSignature and nonRepudiation bits SHOULD NOT be set. However, the digitalSignature and/or nonRepudiation bits MAY be set in addition to the keyCertSign and/or cRLSign bits if the subject public key is to be used to verify signatures on certificates and/or CRLs as well as other objects.
keyUsage拡張子が存在していて、対応するkeyCertSignかcRLSignビットが用意ができていない場合、証明書かCRLsで署名について確かめるのに対象の公開鍵を使用してはいけません。 対象の公開鍵が次に、証明書の上に署名について確かめる、そして/または、CRLs、digitalSignature、およびnonRepudiationビットSHOULD NOTに使用されるだけことであるなら、設定されてください。 しかしながら、digitalSignature、そして/または、nonRepudiationビットは対象の公開鍵が他のオブジェクトと同様に証明書、そして/または、CRLsで署名について確かめるのに使用されることであるならkeyCertSign、そして/または、cRLSignビットに加えて設定されるかもしれません。
Combining the nonRepudiation bit in the keyUsage certificate extension with other keyUsage bits may have security implications depending on the context in which the certificate is to be used. Further distinctions between the digitalSignature and nonRepudiation bits may be provided in specific certificate policies.
keyUsage証明書拡張子で他のkeyUsageビットにnonRepudiationビットを結合するのにおいて、使用されている証明書がことである文脈によるセキュリティ意味があるかもしれません。 digitalSignatureとnonRepudiationビットのさらなる区別を特定の証明書方針に提供するかもしれません。
This profile does not restrict the combinations of bits that may be set in an instantiation of the keyUsage extension. However, appropriate values for keyUsage extensions for particular algorithms are specified in [RFC3279], [RFC4055], and [RFC4491]. When the keyUsage extension appears in a certificate, at least one of the bits MUST be set to 1.
このプロフィールはkeyUsage拡張子の具体化で設定されるかもしれないビットの組み合わせを制限しません。 しかしながら、特定のアルゴリズムのためのkeyUsage拡張子のための適切な値は[RFC3279]、[RFC4055]、および[RFC4491]で指定されます。 keyUsage拡張子が証明書に現れるとき、少なくともビットの1つを1に設定しなければなりません。
Cooper, et al. Standards Track [Page 31] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[31ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
4.2.1.4. Certificate Policies
4.2.1.4. 証明書方針
The certificate policies extension contains a sequence of one or more policy information terms, each of which consists of an object identifier (OID) and optional qualifiers. Optional qualifiers, which MAY be present, are not expected to change the definition of the policy. A certificate policy OID MUST NOT appear more than once in a certificate policies extension.
証明書方針拡張子はより多くのある方針情報用語の系列を含んでいます。それはオブジェクト識別子(OID)と任意の資格を与える人からそれぞれ成ります。 任意の資格を与える人(出席しているかもしれません)が方針の定義を変えないと予想されます。 証明書方針OID MUST NOTは証明書方針拡張子で一度より多く見えます。
In an end entity certificate, these policy information terms indicate
the policy under which the certificate has been issued and the
purposes for which the certificate may be used. In a CA certificate,
these policy information terms limit the set of policies for
certification paths that include this certificate. When a CA does
not wish to limit the set of policies for certification paths that
include this certificate, it MAY assert the special policy anyPolicy,
with a value of { 2 5 29 32 0 }.
終わりの実体証明書では、これらの方針情報用語は証明書が発行された方針と証明書が使用されるかもしれない目的を示します。 カリフォルニア証明書では、これらの方針情報用語は方針のセットをこの証明書を含んでいる証明経路に制限します。 カリフォルニアは方針のセットをこの証明書を含んでいる証明経路に制限したがっていなくて、個別保険証券がanyPolicyであると断言するかもしれません、値でいつで2 5、29 32、0
Applications with specific policy requirements are expected to have a list of those policies that they will accept and to compare the policy OIDs in the certificate to that list. If this extension is critical, the path validation software MUST be able to interpret this extension (including the optional qualifier), or MUST reject the certificate.
特定保険証券要件があるアプリケーションは、それらが受け入れるそれらの方針のリストを持って、証明書で方針OIDsをそのリストと比較すると予想されます。 この拡大が重要であるなら、経路合法化ソフトウェアは、この拡大(任意の資格を与える人を含んでいる)を解釈できなければならないか、または証明書を拒絶しなければなりません。
To promote interoperability, this profile RECOMMENDS that policy information terms consist of only an OID. Where an OID alone is insufficient, this profile strongly recommends that the use of qualifiers be limited to those identified in this section. When qualifiers are used with the special policy anyPolicy, they MUST be limited to the qualifiers identified in this section. Only those qualifiers returned as a result of path validation are considered.
相互運用性を促進するために、その方針情報用語のこのプロフィールRECOMMENDSはOIDだけから成ります。 OIDだけが不十分であるところでは、このプロフィールは、資格を与える人の使用がこのセクションで特定されたものに制限されることを強く勧めます。 資格を与える人が個別保険証券anyPolicyで使用されるとき、彼らをこのセクションで特定された資格を与える人に制限しなければなりません。 経路合法化の結果、返されたそれらの資格を与える人だけが考えられます。
This specification defines two policy qualifier types for use by certificate policy writers and certificate issuers. The qualifier types are the CPS Pointer and User Notice qualifiers.
この仕様は証明書方針作家と証明書発行人による使用のために2つの方針資格を与える人タイプを定義します。 資格を与える人タイプは、CPS PointerとUser Notice資格を与える人です。
The CPS Pointer qualifier contains a pointer to a Certification Practice Statement (CPS) published by the CA. The pointer is in the form of a URI. Processing requirements for this qualifier are a local matter. No action is mandated by this specification regardless of the criticality value asserted for the extension.
CPS Pointer資格を与える人はカリフォルニアによって発行されたCertification Practice Statement(CPS)に指針を含みます。 指針がURIの形にあります。 この資格を与える人のための処理所要は地域にかかわる事柄です。 動作は全く拡大のために断言された臨界値にかかわらずこの仕様で強制されません。
User notice is intended for display to a relying party when a certificate is used. Only user notices returned as a result of path validation are intended for display to the user. If a notice is
証明書が使用されているとき、ユーザ通知はディスプレイのために信用パーティーに意図します。 経路合法化の結果、返されたユーザ通知だけがディスプレイのためにユーザに意図します。 通知がそうなら
Cooper, et al. Standards Track [Page 32] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[32ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
duplicated, only one copy need be displayed. To prevent such duplication, this qualifier SHOULD only be present in end entity certificates and CA certificates issued to other organizations.
コピーされていて、コピー1部だけを表示しなければなりません。 そのような複製、この資格を与える人SHOULDを防ぐには、終わりの実体証明書と他の組織に発行されたカリフォルニア証明書に単に存在してください。
The user notice has two optional fields: the noticeRef field and the explicitText field. Conforming CAs SHOULD NOT use the noticeRef option.
ユーザ通知には、2つの任意の分野があります: noticeRef分野とexplicitText分野。 従うCAs SHOULDはnoticeRefオプションを使用しません。
The noticeRef field, if used, names an organization and
identifies, by number, a particular textual statement prepared by
that organization. For example, it might identify the
organization "CertsRUs" and notice number 1. In a typical
implementation, the application software will have a notice file
containing the current set of notices for CertsRUs; the
application will extract the notice text from the file and display
it. Messages MAY be multilingual, allowing the software to select
the particular language message for its own environment.
noticeRef分野は、使用されるなら組織を命名して、数に従って、その組織によって準備された特定の原文の声明を特定します。 例えば、それは、組織「CertsRUs」を特定して、No.1に気付くかもしれません。 典型的な実装では、アプリケーション・ソフトはCertsRUsのための現在の通知を含む通知ファイルを持つでしょう。 アプリケーションは、ファイルから通知テキストを抜粋して、それを表示するでしょう。 ソフトウェアがそれ自身の環境への特定の言語メッセージを選択するのを許容して、メッセージは多数の言語で表現されているかもしれません。
An explicitText field includes the textual statement directly in
the certificate. The explicitText field is a string with a
maximum size of 200 characters. Conforming CAs SHOULD use the
UTF8String encoding for explicitText, but MAY use IA5String.
Conforming CAs MUST NOT encode explicitText as VisibleString or
BMPString. The explicitText string SHOULD NOT include any control
characters (e.g., U+0000 to U+001F and U+007F to U+009F). When
the UTF8String encoding is used, all character sequences SHOULD be
normalized according to Unicode normalization form C (NFC) [NFC].
explicitText分野は直接証明書に原文の声明を含んでいます。 explicitText分野は200のキャラクタの最大サイズがあるストリングです。 従うCAs SHOULDはしかし、explicitText、5月の使用のためにIA5Stringをコード化するUTF8Stringを使用します。 CAsを従わせると、explicitTextはVisibleStringかBMPStringとしてコード化されてはいけません。 explicitTextストリングSHOULD NOTはどんな制御文字(例えば、U+001FへのU+0000とU+009U+007FからF)も含んでいます。 UTF8Stringであるときに、コード化は使用されていて、すべてのキャラクタシーケンスがSHOULDです。ユニコード正常化フォームC(NFC)[NFC]に従って、正常にされてください。
If both the noticeRef and explicitText options are included in the one qualifier and if the application software can locate the notice text indicated by the noticeRef option, then that text SHOULD be displayed; otherwise, the explicitText string SHOULD be displayed.
noticeRefとexplicitTextオプションの両方が1人の資格を与える人に含まれていて、アプリケーション・ソフトがそうすることができるなら、noticeRefオプションで示された通知テキストの場所を見つけてください、テキストSHOULDを表示するその時。 さもなければ、explicitTextはSHOULDを結びます。表示します。
Note: While the explicitText has a maximum size of 200 characters, some non-conforming CAs exceed this limit. Therefore, certificate users SHOULD gracefully handle explicitText with more than 200 characters.
以下に注意してください。 explicitTextには200のキャラクタの最大サイズがある間、いくつかの非の従うCAsがこの限界を超えています。 したがって、証明書ユーザSHOULDは200以上のキャラクタと共にexplicitTextを優雅に扱います。
Cooper, et al. Standards Track [Page 33] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[33ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
イドCe certificatePolicies、オブジェクト識別子:、:= イドCe32
anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }
anyPolicyオブジェクト識別子:、:= イドCe certificatePolicies、0
certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
certificatePolicies:、:= PolicyInformationの系列サイズ(1..MAX)
PolicyInformation ::= SEQUENCE {
policyIdentifier CertPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL }
PolicyInformation:、:= 系列policyIdentifier CertPolicyId、PolicyQualifierInfo任意のpolicyQualifiers系列サイズ(1..MAX)
CertPolicyId ::= OBJECT IDENTIFIER
CertPolicyId:、:= オブジェクト識別子
PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId,
qualifier ANY DEFINED BY policyQualifierId }
PolicyQualifierInfo:、:= 系列policyQualifierId PolicyQualifierId、資格を与える人いずれもDEFINED BY policyQualifierId
-- policyQualifierIds for Internet policy qualifiers
-- インターネット方針資格を与える人のためのpolicyQualifierIds
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
イド-qt OBJECT IDENTIFIER:、:= イド-pkix2、イド-qt-cps OBJECT IDENTIFIER:、:= イド-qt1、イド-qt-unotice OBJECT IDENTIFIER:、:= イド-qt2
PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
PolicyQualifierId:、:= オブジェクト識別子(イド-qt-cps| イド-qt-unotice)
Qualifier ::= CHOICE {
cPSuri CPSuri,
userNotice UserNotice }
資格を与える人:、:= 選択cPSuri CPSuri、userNotice UserNotice
CPSuri ::= IA5String
CPSuri:、:= IA5String
UserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL,
explicitText DisplayText OPTIONAL }
UserNotice:、:= 系列noticeRef NoticeReference任意であって、explicitText DisplayText任意です。
NoticeReference ::= SEQUENCE {
organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER }
NoticeReference:、:= 系列組織DisplayText、noticeNumbers SEQUENCE OF INTEGER
DisplayText ::= CHOICE {
ia5String IA5String (SIZE (1..200)),
visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200)) }
DisplayText:、:= 選択ia5String IA5String(サイズ(1 .200))、visibleString VisibleString(サイズ(1 .200))、bmpString BMPString(サイズ(1 .200))、utf8String UTF8String(サイズ(1 .200))
Cooper, et al. Standards Track [Page 34] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[34ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
4.2.1.5. Policy Mappings
4.2.1.5. 方針マッピング
This extension is used in CA certificates. It lists one or more pairs of OIDs; each pair includes an issuerDomainPolicy and a subjectDomainPolicy. The pairing indicates the issuing CA considers its issuerDomainPolicy equivalent to the subject CA's subjectDomainPolicy.
この拡張子はカリフォルニア証明書で使用されます。 それは1組以上のOIDsを記載します。 各組はissuerDomainPolicyとsubjectDomainPolicyを入れます。 組み合わせは、発行カリフォルニアが、issuerDomainPolicyが対象のCAのsubjectDomainPolicyに同等であると考えるのを示します。
The issuing CA's users might accept an issuerDomainPolicy for certain applications. The policy mapping defines the list of policies associated with the subject CA that may be accepted as comparable to the issuerDomainPolicy.
発行CAのユーザはあるアプリケーションのためにissuerDomainPolicyを受け入れるかもしれません。 方針マッピングはissuerDomainPolicyに匹敵すると認められるかもしれない対象のカリフォルニアに関連している方針のリストを定義します。
Each issuerDomainPolicy named in the policy mappings extension SHOULD also be asserted in a certificate policies extension in the same certificate. Policies MUST NOT be mapped either to or from the special value anyPolicy (Section 4.2.1.4).
各issuerDomainPolicyは方針でマッピング拡張子をSHOULDと命名しました、また、同じ証明書における証明書方針拡張子で断言されてください。 anyPolicy、または、特別な値のanyPolicyから方針を写像してはいけない、(セクション4.2 .1 .4)。
In general, certificate policies that appear in the issuerDomainPolicy field of the policy mappings extension are not considered acceptable policies for inclusion in subsequent certificates in the certification path. In some circumstances, a CA may wish to map from one policy (p1) to another (p2), but still wants the issuerDomainPolicy (p1) to be considered acceptable for inclusion in subsequent certificates. This may occur, for example, if the CA is in the process of transitioning from the use of policy p1 to the use of policy p2 and has valid certificates that were issued under each of the policies. A CA may indicate this by including two policy mappings in the CA certificates that it issues. Each policy mapping would have an issuerDomainPolicy of p1; one policy mapping would have a subjectDomainPolicy of p1 and the other would have a subjectDomainPolicy of p2.
一般に、方針マッピング拡張子のissuerDomainPolicy分野に現れる証明書方針は証明経路のその後の証明書での包含のための許容できる方針であると考えられません。 いくつかの事情では、カリフォルニアは、その後の証明書での包含において許容できると考えられるために、1つの方針(p1)からしかし、それでも、別の(p2)、必需品までissuerDomainPolicy(p1)を写像したがっているかもしれません。 例えば、カリフォルニアが方針p1の使用から方針p2の使用に移行することの途中にあって、それぞれの方針の下で発行された有効な証明書を持っているなら、これは起こるかもしれません。 カリフォルニアは、それが発行するカリフォルニア証明書の2つの方針マッピングを含んでいることによって、これを示すかもしれません。 それぞれの方針マッピングには、p1のissuerDomainPolicyがあるでしょう。 1つの方針マッピングにはp1のsubjectDomainPolicyがあるでしょう、そして、もう片方には、p2のsubjectDomainPolicyがあるでしょう。
This extension MAY be supported by CAs and/or applications. Conforming CAs SHOULD mark this extension as critical.
この拡大はCAs、そして/または、アプリケーションでサポートされるかもしれません。 従うCAs SHOULDは重要であるとしてこの拡大をマークします。
id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }
イドCe policyMappings、オブジェクト識別子:、:= イドCe33
PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
issuerDomainPolicy CertPolicyId,
subjectDomainPolicy CertPolicyId }
PolicyMappings:、:= 系列の系列サイズ(1..MAX)issuerDomainPolicy CertPolicyId、subjectDomainPolicy CertPolicyId
4.2.1.6. Subject Alternative Name
4.2.1.6. 対象の代替名
The subject alternative name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate. Defined options include an Internet electronic mail
拡大という対象の代替名で、アイデンティティは証明書の対象に付きます。 これらのアイデンティティはアイデンティティか証明書の対象の分野のアイデンティティに代わって含まれるかもしれません。 定義されたオプションはインターネット電子メールを含んでいます。
Cooper, et al. Standards Track [Page 35] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[35ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
address, a DNS name, an IP address, and a Uniform Resource Identifier (URI). Other options exist, including completely local definitions. Multiple name forms, and multiple instances of each name form, MAY be included. Whenever such identities are to be bound into a certificate, the subject alternative name (or issuer alternative name) extension MUST be used; however, a DNS name MAY also be represented in the subject field using the domainComponent attribute as described in Section 4.1.2.4. Note that where such names are represented in the subject field implementations are not required to convert them into DNS names.
アドレス、DNS名、IPアドレス、およびUniform Resource Identifier(URI)。 完全に地方の定義を含んでいて、別の選択肢は存在しています。 複数の名前フォーム、およびそれぞれの名前フォームの複数のインスタンスが含まれるかもしれません。 証明書に縛られるそのようなアイデンティティがことであるときはいつも、拡大という対象の代替名(または、発行人代替名)を使用しなければなりません。 しかしながら、また、DNS名は、対象の分野にセクション4.1.2で.4に説明されるようにdomainComponent属性を使用することで表されるかもしれません。 そのような名前が対象で表されるところで分野実装はDNS名にそれらを変換するのに必要でないことに注意してください。
Because the subject alternative name is considered to be definitively bound to the public key, all parts of the subject alternative name MUST be verified by the CA.
対象の代替名によって決定的に公開鍵に縛られると考えられるので、カリフォルニアは対象の代替名のすべての部分について確かめなければなりません。
Further, if the only subject identity included in the certificate is an alternative name form (e.g., an electronic mail address), then the subject distinguished name MUST be empty (an empty sequence), and the subjectAltName extension MUST be present. If the subject field contains an empty sequence, then the issuing CA MUST include a subjectAltName extension that is marked as critical. When including the subjectAltName extension in a certificate that has a non-empty subject distinguished name, conforming CAs SHOULD mark the subjectAltName extension as non-critical.
さらに、対象の分類名は証明書にアイデンティティを含んでいる唯一の対象が代替名フォーム(例えば、電子メールアドレス)であるなら空でなければなりません、そして、(空の系列)subjectAltName拡張子は存在していなければなりません。 対象の分野が空の系列を含んでいるなら、発行カリフォルニアは重要であるとしてマークされるsubjectAltName拡張子を含まなければなりません。 非空の対象の分類名を持っている証明書にsubjectAltName拡張子を含んでいるときCAs SHOULDが非臨界であるとしてsubjectAltName拡張子であるとマークする従うこと。
When the subjectAltName extension contains an Internet mail address, the address MUST be stored in the rfc822Name. The format of an rfc822Name is a "Mailbox" as defined in Section 4.1.2 of [RFC2821]. A Mailbox has the form "Local-part@Domain". Note that a Mailbox has no phrase (such as a common name) before it, has no comment (text surrounded in parentheses) after it, and is not surrounded by "<" and ">". Rules for encoding Internet mail addresses that include internationalized domain names are specified in Section 7.5.
subjectAltName拡張子がインターネット郵便の宛先を含むとき、rfc822Nameにアドレスを保存しなければなりません。 rfc822Nameの形式は.2セクション4.1[RFC2821]で定義されるように「メールボックス」です。 Mailboxには、フォーム" Local-part@Domain "があります。 Mailboxがそれの前に句(一般名などの)を全く持たないで、またそれの後にノーコメント(括弧で囲まれたテキスト)を持って、"<"と">"によって囲まれないことに注意してください。 国際化ドメイン名を含んでいるインターネット郵便の宛先をコード化するための規則はセクション7.5で指定されます。
When the subjectAltName extension contains an iPAddress, the address MUST be stored in the octet string in "network byte order", as specified in [RFC791]. The least significant bit (LSB) of each octet is the LSB of the corresponding byte in the network address. For IP version 4, as specified in [RFC791], the octet string MUST contain exactly four octets. For IP version 6, as specified in [RFC2460], the octet string MUST contain exactly sixteen octets.
subjectAltName拡張子がiPAddressを含むとき、八重奏ストリングに「ネットワークバイトオーダー」でアドレスを保存しなければなりません、[RFC791]で指定されるように。 それぞれの八重奏の最下位ビット(LSB)はネットワーク・アドレスの対応するバイトのLSBです。 IPバージョン4のために、[RFC791]で指定されるように、八重奏ストリングはまさに4つの八重奏を含まなければなりません。 IPバージョン6のために、[RFC2460]で指定されるように、八重奏ストリングはまさに16の八重奏を含まなければなりません。
When the subjectAltName extension contains a domain name system label, the domain name MUST be stored in the dNSName (an IA5String). The name MUST be in the "preferred name syntax", as specified by Section 3.5 of [RFC1034] and as modified by Section 2.1 of [RFC1123]. Note that while uppercase and lowercase letters are allowed in domain names, no significance is attached to the case. In
subjectAltName拡張子がドメイン名システムラベルを含むとき、dNSName(IA5String)にドメイン名を保存しなければなりません。 名前が「都合のよい名前構文」であるに違いありません、[RFC1034]、[RFC1123]のセクション2.1によって変更されるようにセクション3.5によって指定されるように。 大文字していて小文字の手紙がドメイン名で許容されていますが、意味が全くケースに付けられていないことに注意してください。 コネ
Cooper, et al. Standards Track [Page 36] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[36ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
addition, while the string " " is a legal domain name, subjectAltName extensions with a dNSName of " " MUST NOT be used. Finally, the use of the DNS representation for Internet mail addresses (subscriber.example.com instead of subscriber@example.com) MUST NOT be used; such identities are to be encoded as rfc822Name. Rules for encoding internationalized domain names are specified in Section 7.2.
ストリングであることでの追加、「「法的なドメイン名、subjectAltNameは」 「使用されてはいけない」dNSNameとの拡大です。 最終的に、インターネット郵便の宛先( subscriber@example.com の代わりにsubscriber.example.com)のDNS表現の使用を使用してはいけません。 そのようなアイデンティティはrfc822Nameとしてコード化されることです。 国際化ドメイン名をコード化するための規則はセクション7.2で指定されます。
When the subjectAltName extension contains a URI, the name MUST be stored in the uniformResourceIdentifier (an IA5String). The name MUST NOT be a relative URI, and it MUST follow the URI syntax and encoding rules specified in [RFC3986]. The name MUST include both a scheme (e.g., "http" or "ftp") and a scheme-specific-part. URIs that include an authority ([RFC3986], Section 3.2) MUST include a fully qualified domain name or IP address as the host. Rules for encoding Internationalized Resource Identifiers (IRIs) are specified in Section 7.4.
subjectAltName拡張子がURIを含むとき、uniformResourceIdentifier(IA5String)に名前を保存しなければなりません。 名前は相対的なURIであるはずがありません、そして、URI構文と符号化規則が[RFC3986]で指定したということにならなければなりません。 名前は体系(例えば、"http"か"ftp")と体系の特定の部分の両方を含まなければなりません。 権威([RFC3986]、セクション3.2)を含んでいるURIはホストとして完全修飾ドメイン名かIPアドレスを含まなければなりません。 Internationalized Resource Identifiers(IRIs)をコード化するための規則はセクション7.4で指定されます。
As specified in [RFC3986], the scheme name is not case-sensitive (e.g., "http" is equivalent to "HTTP"). The host part, if present, is also not case-sensitive, but other components of the scheme- specific-part may be case-sensitive. Rules for comparing URIs are specified in Section 7.4.
[RFC3986]で指定されるように、体系名は大文字と小文字を区別していません(例えば、"http"は「HTTP」に同等です)。 また、存在しているなら、ホスト部分も大文字と小文字を区別していませんが、体系の特定の部分の他のコンポーネントは大文字と小文字を区別しているかもしれません。 URIを比較するための規則はセクション7.4で指定されます。
When the subjectAltName extension contains a DN in the directoryName, the encoding rules are the same as those specified for the issuer field in Section 4.1.2.4. The DN MUST be unique for each subject entity certified by the one CA as defined by the issuer field. A CA MAY issue more than one certificate with the same DN to the same subject entity.
subjectAltName拡張子がdirectoryNameにDNを含むとき、符号化規則はものが.4にセクション4.1.2における発行人分野に指定したのと同じです。 DN MUST、発行人分野によって定義されるようにもののカリフォルニアによって公認されたそれぞれの対象の実体において、ユニークであってください。 カリフォルニアは同じDNと共に同じ対象の実体に1通以上の証明書を発行するかもしれません。
The subjectAltName MAY carry additional name types through the use of the otherName field. The format and semantics of the name are indicated through the OBJECT IDENTIFIER in the type-id field. The name itself is conveyed as value field in otherName. For example, Kerberos [RFC4120] format names can be encoded into the otherName, using a Kerberos 5 principal name OID and a SEQUENCE of the Realm and the PrincipalName.
subjectAltNameはotherName分野の使用で追加名前タイプを運ぶかもしれません。 名前の形式と意味論はタイプイド分野のOBJECT IDENTIFIERを通して示されます。 名前自体はotherNameの値の分野として伝えられます。 例えば、ケルベロス[RFC4120]形式名をotherNameにコード化できます、ケルベロス5の主要な名前OIDとRealmとPrincipalNameのSEQUENCEを使用して。
Subject alternative names MAY be constrained in the same manner as subject distinguished names using the name constraints extension as described in Section 4.2.1.10.
対象の代替名はセクション4.2.1で.10に説明されるように名前規制拡張子を使用する対象の分類名と同じ方法で抑制されるかもしれません。
If the subjectAltName extension is present, the sequence MUST contain at least one entry. Unlike the subject field, conforming CAs MUST NOT issue certificates with subjectAltNames containing empty GeneralName fields. For example, an rfc822Name is represented as an IA5String. While an empty string is a valid IA5String, such an rfc822Name is not permitted by this profile. The behavior of clients
subjectAltName拡張子が存在しているなら、系列は少なくとも1つのエントリーを含まなければなりません。 対象の分野と異なって、CAsを従わせると、subjectAltNamesが人影のないGeneralName分野を含んでいる証明書は発行されてはいけません。 例えば、rfc822NameはIA5Stringとして表されます。 空のストリングが有効なIA5Stringである間、そのようなrfc822Nameはこのプロフィールによって受入れられません。 クライアントの振舞い
Cooper, et al. Standards Track [Page 37] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[37ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
that encounter such a certificate when processing a certification path is not defined by this profile.
それがそのような証明書に遭遇するので、処理するとき、証明経路はこのプロフィールによって定義されません。
Finally, the semantics of subject alternative names that include wildcard characters (e.g., as a placeholder for a set of names) are not addressed by this specification. Applications with specific requirements MAY use such names, but they must define the semantics.
最終的に、ワイルドカードキャラクタ(例えば、1セットの名前のためのプレースホルダとしての)を含んでいる対象の代替名の意味論はこの仕様で扱われません。 決められた一定の要求があるアプリケーションはそのような名前を使用するかもしれませんが、それらは意味論を定義しなければなりません。
id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
イドCe subjectAltName、オブジェクト識別子:、:= イドCe17
SubjectAltName ::= GeneralNames
SubjectAltName:、:= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralNames:、:= GeneralNameの系列サイズ(1..MAX)
GeneralName ::= CHOICE {
otherName [0] OtherName,
rfc822Name [1] IA5String,
dNSName [2] IA5String,
x400Address [3] ORAddress,
directoryName [4] Name,
ediPartyName [5] EDIPartyName,
uniformResourceIdentifier [6] IA5String,
iPAddress [7] OCTET STRING,
registeredID [8] OBJECT IDENTIFIER }
GeneralName:、:= 選択otherName[0]OtherName、rfc822Name[1]IA5String、dNSName[2]IA5String、x400Address[3]ORAddress、directoryName[4]名、ediPartyName[5]EDIPartyName、uniformResourceIdentifier[6]IA5String、iPAddress[7]八重奏ストリング、registeredID[8]オブジェクト識別子
OtherName ::= SEQUENCE {
type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id }
OtherName:、:= 系列タイプイドOBJECT IDENTIFIER、値[0]EXPLICIT ANY DEFINED BYタイプイド
EDIPartyName ::= SEQUENCE {
nameAssigner [0] DirectoryString OPTIONAL,
partyName [1] DirectoryString }
EDIPartyName:、:= 系列任意のnameAssigner[0]DirectoryString partyName[1]DirectoryString
4.2.1.7. Issuer Alternative Name
4.2.1.7. 発行人代替名
As with Section 4.2.1.6, this extension is used to associate Internet style identities with the certificate issuer. Issuer alternative name MUST be encoded as in 4.2.1.6. Issuer alternative names are not processed as part of the certification path validation algorithm in Section 6. (That is, issuer alternative names are not used in name chaining and name constraints are not enforced.)
セクション4.2.1のように、.6、この拡張子は、インターネットスタイルのアイデンティティを証明書発行人に関連づけるのに使用されます。 4.2のように発行人代替名をコード化しなければなりません。.1 .6。 発行人代替名はセクション6の証明経路合法化アルゴリズムの一部として処理されません。 (すなわち、発行人代替名は名前推論に使用されないで、また名前規制は励行されません。)
Where present, conforming CAs SHOULD mark this extension as non- critical.
現在で、従うところに、CAs SHOULDは非重要であるとしてこの拡大をマークします。
id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
イドCe issuerAltName、オブジェクト識別子:、:= イドCe18
IssuerAltName ::= GeneralNames
IssuerAltName:、:= GeneralNames
Cooper, et al. Standards Track [Page 38] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[38ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
4.2.1.8. Subject Directory Attributes
4.2.1.8. テーマ別ディレクトリ属性
The subject directory attributes extension is used to convey identification attributes (e.g., nationality) of the subject. The extension is defined as a sequence of one or more attributes. Conforming CAs MUST mark this extension as non-critical.
テーマ別ディレクトリ属性拡張子は、対象の識別属性(例えば、国籍)を伝えるのに使用されます。 拡大は1つ以上の属性の系列と定義されます。 CAsを従わせると、この拡大は非臨界であるとしてマークされなければなりません。
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
イドCe subjectDirectoryAttributes、オブジェクト識別子:、:= イドCe9
SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
SubjectDirectoryAttributes:、:= 属性の系列サイズ(1..MAX)
4.2.1.9. Basic Constraints
4.2.1.9. 基本的な規制
The basic constraints extension identifies whether the subject of the certificate is a CA and the maximum depth of valid certification paths that include this certificate.
基本的な規制拡大は、証明書の対象がこの証明書を含んでいる有効な証明経路のカリフォルニアと最大の深さであるかどうか特定します。
The cA boolean indicates whether the certified public key may be used to verify certificate signatures. If the cA boolean is not asserted, then the keyCertSign bit in the key usage extension MUST NOT be asserted. If the basic constraints extension is not present in a version 3 certificate, or the extension is present but the cA boolean is not asserted, then the certified public key MUST NOT be used to verify certificate signatures.
cA論理演算子は、公認された公開鍵が証明書署名について確かめるのに使用されるかもしれないかどうかを示します。 cA論理演算子が断言されないなら、主要な用法拡大におけるkeyCertSignビットについて断言してはいけません。 基本的な規制拡大がバージョン3証明書に存在していないか、拡大が存在していますが、またはcA論理演算子が断言されないなら、証明書署名について確かめるのに公認された公開鍵を使用してはいけません。
The pathLenConstraint field is meaningful only if the cA boolean is asserted and the key usage extension, if present, asserts the keyCertSign bit (Section 4.2.1.3). In this case, it gives the maximum number of non-self-issued intermediate certificates that may follow this certificate in a valid certification path. (Note: The last certificate in the certification path is not an intermediate certificate, and is not included in this limit. Usually, the last certificate is an end entity certificate, but it can be a CA certificate.) A pathLenConstraint of zero indicates that no non- self-issued intermediate CA certificates may follow in a valid certification path. Where it appears, the pathLenConstraint field MUST be greater than or equal to zero. Where pathLenConstraint does not appear, no limit is imposed.
cA論理演算子が断言される場合にだけpathLenConstraint分野が重要であり、存在しているなら主要な用法拡大がkeyCertSignビットについて断言する、(セクション4.2 .1 .3)。 この場合、それは有効な証明経路でこの証明書に従うかもしれない発行された非自己の中間的証明書の最大数を与えます。 (以下に注意してください。 証明経路における最後の証明書は、中間的証明書でなく、またこの限界に含まれていません。 通常、最後の証明書は終わりの実体証明書ですが、それはカリフォルニア証明書であるかもしれません。) ゼロのpathLenConstraintは、どんな自己によって非発行された中間的カリフォルニア証明書も有効な証明経路で従わないかもしれないのを示します。 現れるところでは、pathLenConstraint分野はゼロ以上であるに違いありません。 pathLenConstraintが現れないところでは、限界は全く課されません。
Conforming CAs MUST include this extension in all CA certificates that contain public keys used to validate digital signatures on certificates and MUST mark the extension as critical in such certificates. This extension MAY appear as a critical or non- critical extension in CA certificates that contain public keys used exclusively for purposes other than validating digital signatures on certificates. Such CA certificates include ones that contain public keys used exclusively for validating digital signatures on CRLs and ones that contain key management public keys used with certificate
CAsを従わせると、この拡大が証明書の上にデジタル署名を有効にするのに使用される公開鍵を含むすべてのカリフォルニア証明書に含まれなければならなくて、拡大はそのような証明書で重要であるとしてマークされなければなりません。 この拡大は排他的な証明書の上にデジタル署名を有効にするのを除いた目的に使用される公開鍵を含むカリフォルニア証明書における重要であるか非重要な拡大として現れるかもしれません。 そのようなカリフォルニア証明書はCRLsで排他的にデジタル署名を有効にするのに使用される公開鍵を含むものと証明書と共に使用されるかぎ管理公開鍵を含むものを含んでいます。
Cooper, et al. Standards Track [Page 39] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[39ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
enrollment protocols. This extension MAY appear as a critical or non-critical extension in end entity certificates.
登録プロトコル。 この拡大は終わりの実体証明書における重要であるか非臨界である拡大として現れるかもしれません。
CAs MUST NOT include the pathLenConstraint field unless the cA boolean is asserted and the key usage extension asserts the keyCertSign bit.
cA論理演算子が断言されて、主要な用法拡大がkeyCertSignビットは断言しない場合、CAsがpathLenConstraint分野を含んではいけません。
id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
イドCe basicConstraints、オブジェクト識別子:、:= イドCe19
BasicConstraints ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
BasicConstraints:、:= 系列cA論理演算子は誤っていて、pathLenConstraint整数(0..MAX)任意の状態でデフォルトとします。
4.2.1.10. Name Constraints
4.2.1.10. 名前規制
The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located. Restrictions apply to the subject distinguished name and apply to subject alternative names. Restrictions apply only when the specified name form is present. If no name of the type is in the certificate, the certificate is acceptable.
名前規制拡張子(カリフォルニア証明書だけで使用しなければならない)は証明経路のその後の証明書のすべての対象の名前が位置しなければならない名前スペースを示します。 制限は、対象の分類名に適用して、対象の代替名に適用されます。 形成という指定された名前が存在しているときだけ、制限は適用されます。 タイプの名前が全く証明書にないなら、証明書は許容できます。
Name constraints are not applied to self-issued certificates (unless the certificate is the final certificate in the path). (This could prevent CAs that use name constraints from employing self-issued certificates to implement key rollover.)
名前規制は自己によって発行された証明書に適用されません(証明書が経路の確定品質証明書でないなら)。 (これは、名前規制を使用するCAsが主要なロールオーバーを実装するのに自己によって発行された証明書を使うのを防ぐかもしれません。)
Restrictions are defined in terms of permitted or excluded name subtrees. Any name matching a restriction in the excludedSubtrees field is invalid regardless of information appearing in the permittedSubtrees. Conforming CAs MUST mark this extension as critical and SHOULD NOT impose name constraints on the x400Address, ediPartyName, or registeredID name forms. Conforming CAs MUST NOT issue certificates where name constraints is an empty sequence. That is, either the permittedSubtrees field or the excludedSubtrees MUST be present.
制限は受入れられたか除かれた名前下位木で定義されます。 excludedSubtrees分野で制限に合っているどんな名前もpermittedSubtreesに現れる情報にかかわらず無効です。 CAsを従わせると、この拡大は重要であるとしてマークされなければなりません、そして、SHOULD NOTはx400Address、ediPartyName、またはregisteredID名前フォームに名前規制を課します。CAsを従わせると、名前規制が空の系列である証明書を発行してはいけません。 すなわち、permittedSubtrees分野かexcludedSubtreesのどちらかが存在していなければなりません。
Applications conforming to this profile MUST be able to process name constraints that are imposed on the directoryName name form and SHOULD be able to process name constraints that are imposed on the rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name forms. If a name constraints extension that is marked as critical imposes constraints on a particular name form, and an instance of that name form appears in the subject field or subjectAltName extension of a subsequent certificate, then the application MUST either process the constraint or reject the certificate.
このプロフィールに従うアプリケーションは存在というrfc822Name、uniformResourceIdentifier、dNSName、およびiPAddress名前用紙に課される名前規制を処理できるdirectoryName名のフォームとSHOULDに課される名前規制を処理できなければなりません。重要であるとしてマークされる名前規制拡大が特定の名前フォーム、およびそのインスタンスに規制を課すなら、名前フォームはその後の証明書の対象の分野かsubjectAltName拡張子に現れます; そして、アプリケーションは、規制を処理しなければならないか、または証明書を拒絶しなければなりません。
Cooper, et al. Standards Track [Page 40] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[40ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
Within this profile, the minimum and maximum fields are not used with any name forms, thus, the minimum MUST be zero, and maximum MUST be absent. However, if an application encounters a critical name constraints extension that specifies other values for minimum or maximum for a name form that appears in a subsequent certificate, the application MUST either process these fields or reject the certificate.
このプロフィールの中では、最小の、そして、最大の分野はどんな名前フォームと共にも使用されません、そして、その結果、最小限はゼロであるに違いありません、そして、最大は欠けているに違いありません。 しかしながら、アプリケーションがその後の証明書に現れる名前フォームとして最小限か最大に他の値を指定する重要な名前規制拡大に遭遇するなら、アプリケーションは、これらの分野を処理しなければならないか、または証明書を拒絶しなければなりません。
For URIs, the constraint applies to the host part of the name. The constraint MUST be specified as a fully qualified domain name and MAY specify a host or a domain. Examples would be "host.example.com" and ".example.com". When the constraint begins with a period, it MAY be expanded with one or more labels. That is, the constraint ".example.com" is satisfied by both host.example.com and my.host.example.com. However, the constraint ".example.com" is not satisfied by "example.com". When the constraint does not begin with a period, it specifies a host. If a constraint is applied to the uniformResourceIdentifier name form and a subsequent certificate includes a subjectAltName extension with a uniformResourceIdentifier that does not include an authority component with a host name specified as a fully qualified domain name (e.g., if the URI either does not include an authority component or includes an authority component in which the host name is specified as an IP address), then the application MUST reject the certificate.
URIのために、規制は名前のホスト部分に適用されます。 規制は、完全修飾ドメイン名として指定しなければならなくて、ホストかドメインを指定するかもしれません。 例は、"host.example.com"と".example.com"でしょう。 規制が期間で始まるとき、それは1個以上のラベルで広げられるかもしれません。 すなわち、規制".example.com"はhost.example.comとmy.host.example.comの両方で満足しています。 しかしながら、規制".example.com"は"example.com"で満足していません。 規制が期間で始まらないと、それはホストを指定します。 規制が形成というuniformResourceIdentifier名に適用されて、その後の証明書がホスト名が完全修飾ドメイン名として指定されている権威コンポーネントを含んでいないuniformResourceIdentifierとのsubjectAltName拡張子を含んでいるなら(例えば、URIが権威コンポーネントを含んでいないか、またはホスト名がIPアドレスとして指定される権威コンポーネントを含んでいるなら)、アプリケーションは証明書を拒絶しなければなりません。
A name constraint for Internet mail addresses MAY specify a particular mailbox, all addresses at a particular host, or all mailboxes in a domain. To indicate a particular mailbox, the constraint is the complete mail address. For example, "root@example.com" indicates the root mailbox on the host "example.com". To indicate all Internet mail addresses on a particular host, the constraint is specified as the host name. For example, the constraint "example.com" is satisfied by any mail address at the host "example.com". To specify any address within a domain, the constraint is specified with a leading period (as with URIs). For example, ".example.com" indicates all the Internet mail addresses in the domain "example.com", but not Internet mail addresses on the host "example.com".
インターネット郵便の宛先の名前規制は特定のメールボックス、特定のホストのすべてのアドレス、またはドメインのすべてのメールボックスを指定するかもしれません。 特定のメールボックスを示すために、規制は完全な郵便の宛先です。 例えば、" root@example.com "はホスト"example.com"の根のメールボックスを示します。 特定のホストに関するすべてのインターネット郵便の宛先を示すために、規制はホスト名として指定されます。 例えば、規制"example.com"はホスト"example.com"のどんな郵便の宛先でも満足しています。 ドメインの中のどんなアドレスも指定するために、規制は主な期間で指定されます(URIのように)。 例えば、".example.com"は、すべてのインターネット・メールが、そのドメインでインターネット・メールではなく、"example.com"がホスト"example.com"に関するアドレスであると扱うのを示します。
DNS name restrictions are expressed as host.example.com. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name satisfies the name constraint. For example, www.host.example.com would satisfy the constraint but host1.example.com would not.
DNS名前制限はhost.example.comとして表されます。 単にゼロか以上を加えることによって構成できるどんなDNS名も満足させるという名前の左側と規制という名前をラベルします。 例えば、www.host.example.comは規制を満たすでしょうが、host1.example.comは満たさないでしょう。
Legacy implementations exist where an electronic mail address is embedded in the subject distinguished name in an attribute of type emailAddress (Section 4.1.2.6). When constraints are imposed on the
レガシー実装が電子メールアドレスがタイプemailAddressの属性で対象の分類名に埋め込まれているところに存在している、(セクション4.1 .2 .6)。 規制はいつに課されるか。
Cooper, et al. Standards Track [Page 41] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[41ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
rfc822Name name form, but the certificate does not include a subject alternative name, the rfc822Name constraint MUST be applied to the attribute of type emailAddress in the subject distinguished name. The ASN.1 syntax for emailAddress and the corresponding OID are supplied in Appendix A.
証明書は対象の代替名を含んでいません、そして、rfc822Nameはフォームを命名しますが、対象の分類名における、タイプemailAddressの属性にrfc822Name規制を適用しなければなりません。 Appendix AでemailAddressのためのASN.1構文と対応するOIDを供給します。
Restrictions of the form directoryName MUST be applied to the subject field in the certificate (when the certificate includes a non-empty subject field) and to any names of type directoryName in the subjectAltName extension. Restrictions of the form x400Address MUST be applied to any names of type x400Address in the subjectAltName extension.
証明書の対象の分野(証明書が非人影のない対象の分野を含んでいると)と、そして、subjectAltName拡張子でのタイプdirectoryNameというどんな名前にもフォームdirectoryNameの制限を適用しなければなりません。 subjectAltName拡張子でタイプx400Addressというどんな名前にもフォームx400Addressの制限を適用しなければなりません。
When applying restrictions of the form directoryName, an implementation MUST compare DN attributes. At a minimum, implementations MUST perform the DN comparison rules specified in Section 7.1. CAs issuing certificates with a restriction of the form directoryName SHOULD NOT rely on implementation of the full ISO DN name comparison algorithm. This implies name restrictions MUST be stated identically to the encoding used in the subject field or subjectAltName extension.
フォームdirectoryNameの制限を適用するとき、実装はDN属性を比較しなければなりません。 最小限では、実装はセクション7.1で指定されたDN比較規則を実行しなければなりません。 フォームdirectoryName SHOULDの制限で証明書を発行するCAsが完全なISO DN名前比較アルゴリズムの実装を当てにしません。 これは、同様に対象の分野かsubjectAltName拡張子に使用されるコード化に名前制限を述べなければならないのを含意します。
The syntax of iPAddress MUST be as described in Section 4.2.1.6 with the following additions specifically for name constraints. For IPv4 addresses, the iPAddress field of GeneralName MUST contain eight (8) octets, encoded in the style of RFC 4632 (CIDR) to represent an address range [RFC4632]. For IPv6 addresses, the iPAddress field MUST contain 32 octets similarly encoded. For example, a name constraint for "class C" subnet 192.0.2.0 is represented as the octets C0 00 02 00 FF FF FF 00, representing the CIDR notation 192.0.2.0/24 (mask 255.255.255.0).
iPAddressの構文が特に名前規制のために以下の追加でセクション4.2.1で.6について説明するようにあるに違いありません。 IPv4アドレスのために、GeneralNameのiPAddress分野はアドレスの範囲[RFC4632]を表すためにRFC4632(CIDR)のスタイルでコード化された8(8)八重奏を含まなければなりません。 IPv6アドレスのために、iPAddress分野は同様にコード化された32の八重奏を含まなければなりません。 例えば、「クラスC」サブネットの名前規制、192.0、.2、.0、CIDR記法192.0.2.0/24を表して、八重奏C0 00 02 00FF FF FF00として表される、(マスク、255.255、.255、.0、)
Additional rules for encoding and processing name constraints are specified in Section 7.
名前規制をコード化して、処理するための付則はセクション7で指定されます。
The syntax and semantics for name constraints for otherName, ediPartyName, and registeredID are not defined by this specification, however, syntax and semantics for name constraints for other name forms may be specified in other documents.
otherName、ediPartyName、およびregisteredIDの名前規制のための構文と意味論はこの仕様で定義されないで、しかしながら、他の名前形式の名前規制のための構文と意味論は他のドキュメントで指定されるかもしれません。
id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }
イドCe nameConstraints、オブジェクト識別子:、:= イドCe30
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
NameConstraints:、:= 系列permittedSubtrees[0]GeneralSubtrees任意であって、excludedSubtrees[1]GeneralSubtrees任意です。
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtrees:、:= GeneralSubtreeの系列サイズ(1..MAX)
Cooper, et al. Standards Track [Page 42] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[42ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
GeneralSubtree:、:= 系列ベースGeneralName、最小限[0]BaseDistance DEFAULT0、最大[1]BaseDistance OPTIONAL
BaseDistance ::= INTEGER (0..MAX)
BaseDistance:、:= 整数(0..MAX)
4.2.1.11. Policy Constraints
4.2.1.11. 方針規制
The policy constraints extension can be used in certificates issued to CAs. The policy constraints extension constrains path validation in two ways. It can be used to prohibit policy mapping or require that each certificate in a path contain an acceptable policy identifier.
CAsに発行された証明書で方針規制拡張子を使用できます。 方針規制拡大は2つの方法で経路合法化を抑制します。 方針マッピングを禁止するか、または経路の各証明書が許容できる方針識別子を含むのが必要であるのにそれを使用できます。
If the inhibitPolicyMapping field is present, the value indicates the number of additional certificates that may appear in the path before policy mapping is no longer permitted. For example, a value of one indicates that policy mapping may be processed in certificates issued by the subject of this certificate, but not in additional certificates in the path.
inhibitPolicyMapping分野が存在しているなら、値は方針マッピングがもう受入れられない前に経路に現れるかもしれない追加証明書の数を示します。 例えば、1の値は、方針マッピングが経路でこの証明書の対象によって発行された証明書で処理されますが、追加証明書で処理されるかもしれないというわけではないのを示します。
If the requireExplicitPolicy field is present, the value of requireExplicitPolicy indicates the number of additional certificates that may appear in the path before an explicit policy is required for the entire path. When an explicit policy is required, it is necessary for all certificates in the path to contain an acceptable policy identifier in the certificate policies extension. An acceptable policy identifier is the identifier of a policy required by the user of the certification path or the identifier of a policy that has been declared equivalent through policy mapping.
requireExplicitPolicy分野が存在しているなら、requireExplicitPolicyの値は明白な方針が全体の経路に必要である前に経路に現れるかもしれない追加証明書の数を示します。 明白な方針が必要であるときに、経路のすべての証明書が証明書方針拡張子に許容できる方針識別子を含むのが必要です。 許容できる方針識別子は、証明経路のユーザによって必要とされた方針に関する識別子か方針マッピングを通して同等であると宣言された方針に関する識別子です。
Conforming applications MUST be able to process the requireExplicitPolicy field and SHOULD be able to process the inhibitPolicyMapping field. Applications that support the inhibitPolicyMapping field MUST also implement support for the policyMappings extension. If the policyConstraints extension is marked as critical and the inhibitPolicyMapping field is present, applications that do not implement support for the inhibitPolicyMapping field MUST reject the certificate.
アプリケーションを従わせると、requireExplicitPolicy分野とSHOULDを処理できなければなりません。inhibitPolicyMapping分野を処理できてください。 また、inhibitPolicyMapping分野をサポートするアプリケーションはpolicyMappings拡張子のサポートを実装しなければなりません。 policyConstraints拡張子が重要であるとしてマークされて、inhibitPolicyMapping分野が存在しているなら、inhibitPolicyMapping分野のサポートを実装しないアプリケーションは証明書を拒絶しなければなりません。
Conforming CAs MUST NOT issue certificates where policy constraints is an empty sequence. That is, either the inhibitPolicyMapping field or the requireExplicitPolicy field MUST be present. The behavior of clients that encounter an empty policy constraints field is not addressed in this profile.
CAsを従わせると、方針規制が空の系列である証明書は発行されてはいけません。 すなわち、inhibitPolicyMapping分野かrequireExplicitPolicy分野のどちらかが存在していなければなりません。 人影のない方針規制分野に遭遇するクライアントの振舞いはこのプロフィールで扱われません。
Conforming CAs MUST mark this extension as critical.
CAsを従わせると、この拡大は重要であるとしてマークされなければなりません。
Cooper, et al. Standards Track [Page 43] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[43ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }
イドCe policyConstraints、オブジェクト識別子:、:= イドCe36
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
PolicyConstraints:、:= 系列requireExplicitPolicy[0]SkipCerts任意であって、inhibitPolicyMapping[1]SkipCerts任意です。
SkipCerts ::= INTEGER (0..MAX)
SkipCerts:、:= 整数(0..MAX)
4.2.1.12. Extended Key Usage
4.2.1.12. 拡張主要な用法
This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension. In general, this extension will appear only in end entity certificates. This extension is defined as follows:
この拡大は公認された公開鍵が目的か主要な用法拡大で示された基本的な目的に代わって使用されるかもしれない1つ以上の目的を示します。 一般に、この拡大は終わりの実体証明書だけに現れるでしょう。 この拡大は以下の通り定義されます:
id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
イドCe extKeyUsage、オブジェクト識別子:、:= イドCe37
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
ExtKeyUsageSyntax:、:= KeyPurposeIdの系列サイズ(1..MAX)
KeyPurposeId ::= OBJECT IDENTIFIER
KeyPurposeId:、:= オブジェクト識別子
Key purposes may be defined by any organization with a need. Object identifiers used to identify key purposes MUST be assigned in accordance with IANA or ITU-T Recommendation X.660 [X.660].
主要な目的は必要性があるどんな組織によっても定義されるかもしれません。 IANAかITU-T Recommendation X.660[X.660]によると、主要な目的を特定するのに使用されるオブジェクト識別子を割り当てなければなりません。
This extension MAY, at the option of the certificate issuer, be either critical or non-critical.
証明書発行人の選択のときに、この拡大は、重要であるか、または非臨界であるかもしれません。
If the extension is present, then the certificate MUST only be used for one of the purposes indicated. If multiple purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present. Certificate using applications MAY require that the extended key usage extension be present and that a particular purpose be indicated in order for the certificate to be acceptable to that application.
拡大が存在しているなら、示された目的の1つに証明書を使用するだけでよいです。 複数の目的が示されるなら、アプリケーションは目的が示したすべてを認識する必要はありません、本来の目的が存在している限り。 アプリケーションを使用する証明書は、拡張主要な用法拡大が存在していて、特定の目的が証明書がそのアプリケーションに許容できるために示されるのを必要とするかもしれません。
If a CA includes extended key usages to satisfy such applications, but does not wish to restrict usages of the key, the CA can include the special KeyPurposeId anyExtendedKeyUsage in addition to the particular key purposes required by the applications. Conforming CAs SHOULD NOT mark this extension as critical if the anyExtendedKeyUsage KeyPurposeId is present. Applications that require the presence of a particular purpose MAY reject certificates that include the anyExtendedKeyUsage OID but not the particular OID expected for the application.
カリフォルニアがそのようなアプリケーションを満たすために拡張主要な用法を含んでいますが、キーの使用法を制限したくないなら、カリフォルニアはアプリケーションで必要である特定の主要な目的に加えて特別なKeyPurposeId anyExtendedKeyUsageを含むことができます。 anyExtendedKeyUsage KeyPurposeIdが存在しているなら、従うCAs SHOULDは重要であるとしてこの拡大をマークしません。 特定の目的を存在に要求するアプリケーションは特定のOIDではなく、アプリケーションのために予想されたanyExtendedKeyUsage OIDを含んでいる証明書を拒絶するかもしれません。
Cooper, et al. Standards Track [Page 44] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[44ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
If a certificate contains both a key usage extension and an extended key usage extension, then both extensions MUST be processed independently and the certificate MUST only be used for a purpose consistent with both extensions. If there is no purpose consistent with both extensions, then the certificate MUST NOT be used for any purpose.
証明書が主要な用法拡大と拡張主要な用法拡大の両方を含んでいるなら、独自に両方の拡大を処理しなければなりません、そして、両方の拡大と一致した目的に証明書を使用するだけでよいです。 両方の拡大と一致したどんな目的もなければ、どんな目的にも証明書を使用してはいけません。
The following key usage purposes are defined:
以下の主要な用法目的は定義されます:
anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
anyExtendedKeyUsageオブジェクト識別子:、:= イドCe extKeyUsage、0
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
イド-kp OBJECT IDENTIFIER:、:= イド-pkix3
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
イド-kp-serverAuthオブジェクト識別子:、:= イド-kp1--TLS WWWサーバ証明--一貫するかもしれない主要な用法ビット: digitalSignature--keyEnciphermentかkeyAgreement
id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
-- TLS WWW client authentication
-- Key usage bits that may be consistent: digitalSignature
-- and/or keyAgreement
イド-kp-clientAuthオブジェクト識別子:、:= イド-kp2--TLS WWWクライアント認証--一貫するかもしれない主要な用法ビット: digitalSignature and/or keyAgreement
id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
-- Signing of downloadable executable code
-- Key usage bits that may be consistent: digitalSignature
イド-kp-codeSigningオブジェクト識別子:、:= イド-kp3--ダウンローダブルな実行コードの署名--一貫するかもしれない主要な用法ビット: digitalSignature
id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
-- Email protection
-- Key usage bits that may be consistent: digitalSignature,
-- nonRepudiation, and/or (keyEncipherment or keyAgreement)
イド-kp-emailProtectionオブジェクト識別子:、:= イド-kp4--メール保護--一貫するかもしれない主要な用法ビット: そして/またはdigitalSignature--nonRepudiation。(keyEnciphermentかkeyAgreement)
id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
-- Binding the hash of an object to a time
-- Key usage bits that may be consistent: digitalSignature
-- and/or nonRepudiation
イド-kp-timeStampingオブジェクト識別子:、:= イド-kp8--時間までオブジェクトのハッシュを縛ります--一貫するかもしれない主要な用法ビット: digitalSignature and/or nonRepudiation
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
-- Signing OCSP responses
-- Key usage bits that may be consistent: digitalSignature
-- and/or nonRepudiation
イド-kp-OCSPSigningオブジェクト識別子:、:= イド-kp9--署名OCSP応答--一貫するかもしれない主要な用法ビット: digitalSignature and/or nonRepudiation
4.2.1.13. CRL Distribution Points
4.2.1.13. CRL分配ポイント
The CRL distribution points extension identifies how CRL information is obtained. The extension SHOULD be non-critical, but this profile RECOMMENDS support for this extension by CAs and applications. Further discussion of CRL management is contained in Section 5.
CRL分配ポイント拡張子はどうCRL情報を得るかを特定します。 拡大SHOULD、非臨界であり、このプロフィールRECOMMENDSだけがこれのためにCAsとアプリケーションで拡大をサポートするということになってください。 CRL管理のさらなる議論はセクション5に含まれています。
Cooper, et al. Standards Track [Page 45] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[45ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
The cRLDistributionPoints extension is a SEQUENCE of DistributionPoint. A DistributionPoint consists of three fields, each of which is optional: distributionPoint, reasons, and cRLIssuer. While each of these fields is optional, a DistributionPoint MUST NOT consist of only the reasons field; either distributionPoint or cRLIssuer MUST be present. If the certificate issuer is not the CRL issuer, then the cRLIssuer field MUST be present and contain the Name of the CRL issuer. If the certificate issuer is also the CRL issuer, then conforming CAs MUST omit the cRLIssuer field and MUST include the distributionPoint field.
cRLDistributionPoints拡張子はDistributionPointのSEQUENCEです。 DistributionPointは3つの分野から成ります:それはそれぞれ任意です。 distributionPoint、理由、およびcRLIssuer。 それぞれのこれらの分野が任意である間、DistributionPointは理由分野だけから成ってはいけません。 distributionPointかcRLIssuerのどちらかが存在していなければなりません。 証明書発行人がCRL発行人でないなら、cRLIssuer分野は、存在していて、CRL発行人のNameを含まなければなりません。 また、証明書発行人がCRL発行人であるなら、CAsを従わせると、cRLIssuer分野が省略されなければならなくて、distributionPoint分野は含まれなければなりません。
When the distributionPoint field is present, it contains either a SEQUENCE of general names or a single value, nameRelativeToCRLIssuer. If the DistributionPointName contains multiple values, each name describes a different mechanism to obtain the same CRL. For example, the same CRL could be available for retrieval through both LDAP and HTTP.
nameRelativeToCRLIssuer、distributionPoint分野が存在しているとき、それは一般名のSEQUENCEかただ一つの値のどちらかを含んでいます。 DistributionPointNameが複数の値を含んでいるなら、各名前は、同じCRLを入手するために異なったメカニズムについて説明します。 例えば、LDAPとHTTPの両方のを通した検索について、同じCRLがあるかもしれません。
If the distributionPoint field contains a directoryName, the entry for that directoryName contains the current CRL for the associated reasons and the CRL is issued by the associated cRLIssuer. The CRL may be stored in either the certificateRevocationList or authorityRevocationList attribute. The CRL is to be obtained by the application from whatever directory server is locally configured. The protocol the application uses to access the directory (e.g., DAP or LDAP) is a local matter.
distributionPoint分野がdirectoryNameを含んでいるなら、そのdirectoryNameのためのエントリーは関連理由で現在のCRLを含んでいます、そして、CRLは関連cRLIssuerによって発行されます。 CRLはcertificateRevocationListかauthorityRevocationListが結果と考えるどちらかに保存されるかもしれません。 CRLは局所的に構成されるどんなディレクトリサーバからのアプリケーションでも入手されることになっています。 アプリケーションがディレクトリ(例えば、DAPかLDAP)にアクセスするのに使用するプロトコルは地域にかかわる事柄です。
If the DistributionPointName contains a general name of type URI, the following semantics MUST be assumed: the URI is a pointer to the current CRL for the associated reasons and will be issued by the associated cRLIssuer. When the HTTP or FTP URI scheme is used, the URI MUST point to a single DER encoded CRL as specified in [RFC2585]. HTTP server implementations accessed via the URI SHOULD specify the media type application/pkix-crl in the content-type header field of the response. When the LDAP URI scheme [RFC4516] is used, the URI MUST include a <dn> field containing the distinguished name of the entry holding the CRL, MUST include a single <attrdesc> that contains an appropriate attribute description for the attribute that holds the CRL [RFC4523], and SHOULD include a <host> (e.g., <ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com? certificateRevocationList;binary>). Omitting the <host> (e.g., <ldap:///cn=CA,dc=example,dc=com?authorityRevocationList;binary>) has the effect of relying on whatever a priori knowledge the client might have to contact an appropriate server. When present, DistributionPointName SHOULD include at least one LDAP or HTTP URI.
DistributionPointNameがタイプURIの一般名を含んでいるなら、以下の意味論を想定しなければなりません: URIは、関連理由による現在のCRLへの指針であり、関連cRLIssuerによって発行されるでしょう。 HTTPかFTP URI体系が使用されているとき、URIは[RFC2585]の指定されるとしてのコード化されたCRLを独身のDERに指さなければなりません。 URI SHOULDを通してアクセスされたHTTPサーバ実装は応答のcontent typeヘッダーフィールドでメディアタイプアプリケーション/pkix-crlを指定します。 LDAP URI体系[RFC4516]が使用されているとき、URIは、CRLを持っているエントリーの分類名を含む<dn>分野を含まなければならなくて、CRL[RFC4523]を持っている属性のための適切な属性記述を含む単一の<attrdesc>を含まなければなりません、そして、SHOULDは<ホスト>を含んでいます(例の例えば、<ldap://ldap.example.com/cn=%20CA、dcは例、dc=com--certificateRevocationList; 2進の>と等しいです)。 <ホスト>(例えば、<ldap:///cn=カリフォルニア、dcは例、dc=com--authorityRevocationList; 2進の>と等しい)を省略するのにおいて、クライアントが適切なサーバに連絡するために持っているどんな先験的な知識も当てにするという効果があります。存在しているとき、DistributionPointName SHOULDは少なくとも1つのLDAPかHTTP URIを含んでいます。
If the DistributionPointName contains the single value nameRelativeToCRLIssuer, the value provides a distinguished name
DistributionPointNameが独身の値のnameRelativeToCRLIssuerを含んでいるなら、値は分類名を提供します。
Cooper, et al. Standards Track [Page 46] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[46ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
fragment. The fragment is appended to the X.500 distinguished name of the CRL issuer to obtain the distribution point name. If the cRLIssuer field in the DistributionPoint is present, then the name fragment is appended to the distinguished name that it contains; otherwise, the name fragment is appended to the certificate issuer distinguished name. Conforming CAs SHOULD NOT use nameRelativeToCRLIssuer to specify distribution point names. The DistributionPointName MUST NOT use the nameRelativeToCRLIssuer alternative when cRLIssuer contains more than one distinguished name.
断片化してください。 分配ポイント名を得るためにCRL発行人のX.500分類名に断片を追加します。 DistributionPointのcRLIssuer分野が存在しているなら、それが含む分類名に名前断片を追加します。 さもなければ、証明書発行人分類名に名前断片を追加します。 従うCAs SHOULDは、分配ポイント名を指定するのにnameRelativeToCRLIssuerを使用しません。 cRLIssuerが1つ以上の分類名を含んでいると、DistributionPointNameはnameRelativeToCRLIssuer代替手段を使用してはいけません。
If the DistributionPoint omits the reasons field, the CRL MUST include revocation information for all reasons. This profile RECOMMENDS against segmenting CRLs by reason code. When a conforming CA includes a cRLDistributionPoints extension in a certificate, it MUST include at least one DistributionPoint that points to a CRL that covers the certificate for all reasons.
DistributionPointが理由分野を省略するなら、CRL MUSTはすべての理由で取消し情報を含んでいます。 理由コードでCRLsを区分することに対するこのプロフィールRECOMMENDS。 従うカリフォルニアが証明書にcRLDistributionPoints拡張子を含んでいるとき、それはすべての理由で証明書をカバーするCRLを示す少なくとも1DistributionPointを含まなければなりません。
The cRLIssuer identifies the entity that signs and issues the CRL. If present, the cRLIssuer MUST only contain the distinguished name (DN) from the issuer field of the CRL to which the DistributionPoint is pointing. The encoding of the name in the cRLIssuer field MUST be exactly the same as the encoding in issuer field of the CRL. If the cRLIssuer field is included and the DN in that field does not correspond to an X.500 or LDAP directory entry where CRL is located, then conforming CAs MUST include the distributionPoint field.
cRLIssuerはCRLに署名して、発行する実体を特定します。 存在しているなら、cRLIssuerはDistributionPointが指しているCRLの発行人分野からの分類名(DN)を含むだけでよいです。 cRLIssuer分野での名前のコード化はまさにCRLの発行人分野でのコード化と同じでなければなりません。 cRLIssuer分野が含められていて、その分野のDNがCRLが位置しているX.500かLDAPディレクトリエントリに対応していないなら、CAsを従わせると、distributionPoint分野は包含しなければなりません。
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 }
イドCe cRLDistributionPoints、オブジェクト識別子:、:= イドCe31
CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
CRLDistributionPoints:、:= DistributionPointの系列サイズ(1..MAX)
DistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
reasons [1] ReasonFlags OPTIONAL,
cRLIssuer [2] GeneralNames OPTIONAL }
DistributionPoint:、:= 系列distributionPoint[0]DistributionPointName OPTIONAL、理由[1]ReasonFlags OPTIONAL、cRLIssuer[2]GeneralNames OPTIONAL
DistributionPointName ::= CHOICE {
fullName [0] GeneralNames,
nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
DistributionPointName:、:= 選択fullName[0]GeneralNames、nameRelativeToCRLIssuer[1]RelativeDistinguishedName
Cooper, et al. Standards Track [Page 47] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[47ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
ReasonFlags ::= BIT STRING {
unused (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
privilegeWithdrawn (7),
aACompromise (8) }
ReasonFlags:、:= ビット列未使用の(0)(keyCompromise(1)、cACompromise(2)、affiliationChanged(3))は(4)、cessationOfOperation(5)、certificateHold(6)、privilegeWithdrawn(7)、aACompromise(8)に取って代わりました。
4.2.1.14. Inhibit anyPolicy
4.2.1.14. anyPolicyを禁止してください。
The inhibit anyPolicy extension can be used in certificates issued to
CAs. The inhibit anyPolicy extension indicates that the special
anyPolicy OID, with the value { 2 5 29 32 0 }, is not considered an
explicit match for other certificate policies except when it appears
in an intermediate self-issued CA certificate. The value indicates
the number of additional non-self-issued certificates that may appear
in the path before anyPolicy is no longer permitted. For example, a
value of one indicates that anyPolicy may be processed in
certificates issued by the subject of this certificate, but not in
additional certificates in the path.
中古のコネがCAsに発行された証明書であったかもしれないならanyPolicy拡張子を禁止してください。 禁止、anyPolicy拡張子がそれを示す、値がある特別なanyPolicy OID、2 5、29 32、0、それが中間的自己によって発行されたカリフォルニア証明書に現れる時以外の他の証明書方針のための明白なマッチであることは考えられません。 値はanyPolicyがもう受入れられない前に経路に現れるかもしれない追加発行された非自己証明書の数を示します。 例えば、1の値は、anyPolicyが経路でこの証明書の対象によって発行された証明書で処理されますが、追加証明書で処理されるかもしれないというわけではないのを示します。
Conforming CAs MUST mark this extension as critical.
CAsを従わせると、この拡大は重要であるとしてマークされなければなりません。
id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }
イドCe inhibitAnyPolicy、オブジェクト識別子:、:= イドCe54
InhibitAnyPolicy ::= SkipCerts
InhibitAnyPolicy:、:= SkipCerts
SkipCerts ::= INTEGER (0..MAX)
SkipCerts:、:= 整数(0..MAX)
4.2.1.15. Freshest CRL (a.k.a. Delta CRL Distribution Point)
4.2.1.15. 最も新鮮なCRL(通称デルタCRL分配ポイント)
The freshest CRL extension identifies how delta CRL information is obtained. The extension MUST be marked as non-critical by conforming CAs. Further discussion of CRL management is contained in Section 5.
最も新鮮なCRL拡張子はどうデルタCRL情報を得るかを特定します。 CAsを従わせることによって非臨界であるとして拡大をマークしなければなりません。 CRL管理のさらなる議論はセクション5に含まれています。
The same syntax is used for this extension and the cRLDistributionPoints extension, and is described in Section 4.2.1.13. The same conventions apply to both extensions.
同じ構文は、この拡大とcRLDistributionPoints拡張子に使用されて、セクション4.2.1で.13に説明されます。 同じコンベンションは両方の拡大に適用されます。
id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
イドCe freshestCRL、オブジェクト識別子:、:= イドCe46
FreshestCRL ::= CRLDistributionPoints
FreshestCRL:、:= CRLDistributionPoints
Cooper, et al. Standards Track [Page 48] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[48ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
4.2.2. Private Internet Extensions
4.2.2. 個人的なインターネット拡大
This section defines two extensions for use in the Internet Public Key Infrastructure. These extensions may be used to direct applications to on-line information about the issuer or the subject. Each extension contains a sequence of access methods and access locations. The access method is an object identifier that indicates the type of information that is available. The access location is a GeneralName that implicitly specifies the location and format of the information and the method for obtaining the information.
このセクションはインターネット公開鍵暗号基盤における使用のために2つの拡大を定義します。 これらの拡張子は、発行人かこの件のオンライン情報にアプリケーションを向けるのに使用されるかもしれません。 各拡大はアクセス法とアクセス位置の系列を含んでいます。 アクセス法は手があいている情報の種類を示すオブジェクト識別子です。 アクセス位置はそれとなく情報の位置と形式と情報を得るためのメソッドを指定するGeneralNameです。
Object identifiers are defined for the private extensions. The object identifiers associated with the private extensions are defined under the arc id-pe within the arc id-pkix. Any future extensions defined for the Internet PKI are also expected to be defined under the arc id-pe.
オブジェクト識別子は個人的な拡大のために定義されます。 個人的な拡大に関連しているオブジェクト識別子はアークイド-pkixの中のアークイド-peの下で定義されます。 また、アークイド-peの下でインターネットPKIと定義されたどんな今後の拡大も定義されると予想されます。
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
イド-pkix OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
イド-pe OBJECT IDENTIFIER:、:= イド-pkix1
4.2.2.1. Authority Information Access
4.2.2.1. 権威情報アクセス
The authority information access extension indicates how to access information and services for the issuer of the certificate in which the extension appears. Information and services may include on-line validation services and CA policy data. (The location of CRLs is not specified in this extension; that information is provided by the cRLDistributionPoints extension.) This extension may be included in end entity or CA certificates. Conforming CAs MUST mark this extension as non-critical.
権威情報アクセス拡張子は拡大が現れる証明書の発行人のために情報とサービスにアクセスする方法を示します。 情報とサービスはオンライン合法化サービスとカリフォルニア方針データを含むかもしれません。 (CRLsの位置はこの拡大で指定されません; cRLDistributionPoints拡張子で情報を提供します。) この拡大は終わりの実体かカリフォルニア証明書に含まれるかもしれません。 CAsを従わせると、この拡大は非臨界であるとしてマークされなければなりません。
id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
イド-pe-authorityInfoAccessオブジェクト識別子:、:= イド-pe1
AuthorityInfoAccessSyntax ::=
SEQUENCE SIZE (1..MAX) OF AccessDescription
AuthorityInfoAccessSyntax:、:= AccessDescriptionの系列サイズ(1..MAX)
AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER,
accessLocation GeneralName }
AccessDescription:、:= 系列accessMethodオブジェクト識別子、accessLocation GeneralName
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
イド広告OBJECT IDENTIFIER:、:= イド-pkix48
id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
イド広告caIssuers、オブジェクト識別子:、:= イド広告2
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
イド広告ocsp OBJECT IDENTIFIER、:、:= イド広告1
Cooper, et al. Standards Track [Page 49] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[49ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
Each entry in the sequence AuthorityInfoAccessSyntax describes the format and location of additional information provided by the issuer of the certificate in which this extension appears. The type and format of the information are specified by the accessMethod field; the accessLocation field specifies the location of the information. The retrieval mechanism may be implied by the accessMethod or specified by accessLocation.
系列AuthorityInfoAccessSyntaxにおける各エントリーはこの拡大が現れる証明書の発行人によって提供された追加情報の形式と位置について説明します。 情報のタイプと形式はaccessMethod分野によって指定されます。 accessLocation分野は情報の位置を指定します。 回収機構は、accessMethodによって含意されるか、またはaccessLocationによって指定されるかもしれません。
This profile defines two accessMethod OIDs: id-ad-caIssuers and id-ad-ocsp.
このプロフィールは2accessMethod OIDsを定義します: イド広告caIssuers、そして、イド広告ocsp。
In a public key certificate, the id-ad-caIssuers OID is used when the additional information lists certificates that were issued to the CA that issued the certificate containing this extension. The referenced CA issuers description is intended to aid certificate users in the selection of a certification path that terminates at a point trusted by the certificate user.
公開鍵証明書でイド広告caIssuers OID、追加情報がこの拡大を含む証明書を発行したカリフォルニアに発行された証明書をリストアップするとき、使用されます。 参照をつけられたカリフォルニアの発行人記述が証明書ユーザによって信じられたポイントで終わる証明経路の選択で証明書ユーザを支援することを意図します。
When id-ad-caIssuers appears as accessMethod, the accessLocation field describes the referenced description server and the access protocol to obtain the referenced description. The accessLocation field is defined as a GeneralName, which can take several forms.
いつ、イド広告caIssuers、accessMethod、accessLocation分野が参照をつけられた記述サーバについて説明して、アクセスが参照をつけられた記述を得るために議定書を作るのに従って、現れるか。 accessLocation分野はGeneralNameと定義されます。(GeneralNameは数個の形を取ることができます)。
When the accessLocation is a directoryName, the information is to be obtained by the application from whatever directory server is locally configured. The entry for the directoryName contains CA certificates in the crossCertificatePair and/or cACertificate attributes as specified in [RFC4523]. The protocol that application uses to access the directory (e.g., DAP or LDAP) is a local matter.
accessLocationがdirectoryNameであるときに、情報は局所的に構成されるどんなディレクトリサーバからのアプリケーションでも得ることです。 directoryNameのためのエントリーは[RFC4523]の指定されるとしてのcrossCertificatePair、そして/または、cACertificate属性にカリフォルニア証明書を含んでいます。 アプリケーションがディレクトリ(例えば、DAPかLDAP)にアクセスするのに使用するプロトコルは地域にかかわる事柄です。
Where the information is available via LDAP, the accessLocation SHOULD be a uniformResourceIdentifier. The LDAP URI [RFC4516] MUST include a <dn> field containing the distinguished name of the entry holding the certificates, MUST include an <attributes> field that lists appropriate attribute descriptions for the attributes that hold the DER encoded certificates or cross-certificate pairs [RFC4523], and SHOULD include a <host> (e.g., <ldap://ldap.example.com/cn=CA, dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary>). Omitting the <host> (e.g., <ldap:///cn=exampleCA,dc=example,dc=com? cACertificate;binary>) has the effect of relying on whatever a priori knowledge the client might have to contact an appropriate server.
情報がLDAP、accessLocation SHOULDを通して入手できるところでは、uniformResourceIdentifierがそうですか? LDAP URI[RFC4516]は証明書を保持するエントリーの分類名を含む<dn>分野を含まなければならなくて、DERコード化された証明書か交差している証明書組[RFC4523]を保持する属性のための適切な属性記述を記載する<属性>分野を含まなければなりません、そして、SHOULDは<ホスト>を含んでいます(例えば、<ldap://ldap.example.com/cn=カリフォルニア、dcはdc=com?例、cACertificate; バイナリー、crossCertificatePair; 2進の>と等しいです)。 <ホスト>(例えば、<ldap:///cn=exampleCA、dcは例、dc=com--cACertificate; 2進の>と等しい)を省略するのにおいて、クライアントが適切なサーバに連絡するために持っているどんな先験的な知識も当てにするという効果があります。
Where the information is available via HTTP or FTP, accessLocation MUST be a uniformResourceIdentifier and the URI MUST point to either a single DER encoded certificate as specified in [RFC2585] or a collection of certificates in a BER or DER encoded "certs-only" CMS message as specified in [RFC2797].
情報がHTTPかFTPで利用可能であるところでは、accessLocationはuniformResourceIdentifierであるに違いありません、そして、URIが[RFC2585]の指定されるとしてのコード化された証明書かBERでの証明書の収集を独身のDERに向けなければならない、さもなければ、DERは[RFC2797]の指定されるとしての「本命唯一」のCMSメッセージをコード化しました。
Cooper, et al. Standards Track [Page 50] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[50ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
Conforming applications that support HTTP or FTP for accessing certificates MUST be able to accept individual DER encoded certificates and SHOULD be able to accept "certs-only" CMS messages.
個人DERのためにコード化された証明書とSHOULDを受け入れることができる状態で証明書にアクセスするためのサポートHTTPかFTPがあるに違いない利用を従わせて、「本命専用」CMSメッセージを受け入れることができてください。
HTTP server implementations accessed via the URI SHOULD specify the media type application/pkix-cert [RFC2585] in the content-type header field of the response for a single DER encoded certificate and SHOULD specify the media type application/pkcs7-mime [RFC2797] in the content-type header field of the response for "certs-only" CMS messages. For FTP, the name of a file that contains a single DER encoded certificate SHOULD have a suffix of ".cer" [RFC2585] and the name of a file that contains a "certs-only" CMS message SHOULD have a suffix of ".p7c" [RFC2797]. Consuming clients may use the media type or file extension as a hint to the content, but should not depend solely on the presence of the correct media type or file extension in the server response.
独身のDERが証明書をコード化して、SHOULDが「本命専用」CMSメッセージのための応答のcontent typeヘッダーフィールドでメディアタイプpkcs7アプリケーション/パントマイム[RFC2797]を指定するので、URI SHOULDを通してアクセスされたHTTPサーバ実装は応答のcontent typeヘッダーフィールドでメディアタイプpkixアプリケーション/本命[RFC2585]を指定します。 FTP、DERがコード化したシングルを含むファイルの名前のために、証明書SHOULDには、SHOULDに".p7c"[RFC2797]の接尾語があるという「本命専用」CMSメッセージを含む".cer"[RFC2585]の接尾語とファイルの名前があります。 クライアントを消費するのは、ヒントとしてメディアタイプかファイル拡張子を内容に使用するかもしれませんが、唯一サーバ応答における、正しいメディアタイプかファイル拡張子の存在によるべきではありません。
The semantics of other id-ad-caIssuers accessLocation name forms are not defined.
他の意味論、イド広告caIssuers accessLocation、名前書式は定義されません。
An authorityInfoAccess extension may include multiple instances of the id-ad-caIssuers accessMethod. The different instances may specify different methods for accessing the same information or may point to different information. When the id-ad-caIssuers accessMethod is used, at least one instance SHOULD specify an accessLocation that is an HTTP [RFC2616] or LDAP [RFC4516] URI.
authorityInfoAccess拡張子が複数のインスタンスを含むかもしれない、イド広告caIssuers accessMethod 異なったインスタンスは、同じ情報にアクセスするための異なったメソッドを指定するか、または異なった情報を示すかもしれません。 いつ、イド広告caIssuers accessMethod、中古の少なくとも1つのインスタンスのSHOULDはHTTP[RFC2616]かLDAP[RFC4516]URIであるaccessLocationを指定するか。
The id-ad-ocsp OID is used when revocation information for the certificate containing this extension is available using the Online Certificate Status Protocol (OCSP) [RFC2560].
イド広告ocsp OID、この拡大を含む証明書のための取消し情報がOnline Certificate Statusプロトコル(OCSP)[RFC2560]を使用することで利用可能であるときに、使用されます。
When id-ad-ocsp appears as accessMethod, the accessLocation field is the location of the OCSP responder, using the conventions defined in [RFC2560].
イド広告ocspがaccessMethodとして現れるとき、accessLocation分野はOCSP応答者の位置です、[RFC2560]で定義されたコンベンションを使用して。
Additional access descriptors may be defined in other PKIX specifications.
追加アクセス記述子は他のPKIX仕様に基づき定義されるかもしれません。
4.2.2.2. Subject Information Access
4.2.2.2. 対象の情報アクセス
The subject information access extension indicates how to access information and services for the subject of the certificate in which the extension appears. When the subject is a CA, information and services may include certificate validation services and CA policy data. When the subject is an end entity, the information describes the type of services offered and how to access them. In this case, the contents of this extension are defined in the protocol
対象の情報アクセス拡張子は拡大が現れる証明書の対象のための情報とサービスにアクセスする方法を示します。 対象がカリフォルニアであるときに、情報とサービスは証明書合法化サービスとカリフォルニア方針データを含むかもしれません。 対象が終わりの実体であるときに、情報は提供されたサービスとどうそれらにアクセスするかに関するタイプについて説明します。 この場合、この拡大の内容はプロトコルで定義されます。
Cooper, et al. Standards Track [Page 51] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[51ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
specifications for the supported services. This extension may be included in end entity or CA certificates. Conforming CAs MUST mark this extension as non-critical.
サポートしているサービスのための仕様。 この拡大は終わりの実体かカリフォルニア証明書に含まれるかもしれません。 CAsを従わせると、この拡大は非臨界であるとしてマークされなければなりません。
id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
イド-pe-subjectInfoAccessオブジェクト識別子:、:= イド-pe11
SubjectInfoAccessSyntax ::=
SEQUENCE SIZE (1..MAX) OF AccessDescription
SubjectInfoAccessSyntax:、:= AccessDescriptionの系列サイズ(1..MAX)
AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER,
accessLocation GeneralName }
AccessDescription:、:= 系列accessMethodオブジェクト識別子、accessLocation GeneralName
Each entry in the sequence SubjectInfoAccessSyntax describes the format and location of additional information provided by the subject of the certificate in which this extension appears. The type and format of the information are specified by the accessMethod field; the accessLocation field specifies the location of the information. The retrieval mechanism may be implied by the accessMethod or specified by accessLocation.
系列SubjectInfoAccessSyntaxにおける各エントリーはこの拡大が現れる証明書の対象によって提供された追加情報の形式と位置について説明します。 情報のタイプと形式はaccessMethod分野によって指定されます。 accessLocation分野は情報の位置を指定します。 回収機構は、accessMethodによって含意されるか、またはaccessLocationによって指定されるかもしれません。
This profile defines one access method to be used when the subject is a CA and one access method to be used when the subject is an end entity. Additional access methods may be defined in the future in the protocol specifications for other services.
このプロフィールは1つの対象がカリフォルニアであるときに使用されるべきアクセスメソッドと1つの対象が終わりの実体であるときに使用されるべきアクセスメソッドを定義します。 追加アクセス法は将来、他のサービスのためのプロトコル仕様に基づき定義されるかもしれません。
The id-ad-caRepository OID is used when the subject is a CA that publishes certificates it issues in a repository. The accessLocation field is defined as a GeneralName, which can take several forms.
イド広告caRepository OID、対象がそれが倉庫で発行する証明書を発表するカリフォルニアであるときに、使用されます。 accessLocation分野はGeneralNameと定義されます。(GeneralNameは数個の形を取ることができます)。
When the accessLocation is a directoryName, the information is to be obtained by the application from whatever directory server is locally configured. When the extension is used to point to CA certificates, the entry for the directoryName contains CA certificates in the crossCertificatePair and/or cACertificate attributes as specified in [RFC4523]. The protocol the application uses to access the directory (e.g., DAP or LDAP) is a local matter.
accessLocationがdirectoryNameであるときに、情報は局所的に構成されるどんなディレクトリサーバからのアプリケーションでも得ることです。 拡張子がカリフォルニア証明書を示すのに使用されるとき、directoryNameのためのエントリーは[RFC4523]の指定されるとしてのcrossCertificatePair、そして/または、cACertificate属性にカリフォルニア証明書を含んでいます。 アプリケーションがディレクトリ(例えば、DAPかLDAP)にアクセスするのに使用するプロトコルは地域にかかわる事柄です。
Where the information is available via LDAP, the accessLocation SHOULD be a uniformResourceIdentifier. The LDAP URI [RFC4516] MUST include a <dn> field containing the distinguished name of the entry holding the certificates, MUST include an <attributes> field that lists appropriate attribute descriptions for the attributes that hold the DER encoded certificates or cross-certificate pairs [RFC4523], and SHOULD include a <host> (e.g., <ldap://ldap.example.com/cn=CA, dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary>).
情報がLDAP、accessLocation SHOULDを通して入手できるところでは、uniformResourceIdentifierがそうですか? LDAP URI[RFC4516]は証明書を保持するエントリーの分類名を含む<dn>分野を含まなければならなくて、DERコード化された証明書か交差している証明書組[RFC4523]を保持する属性のための適切な属性記述を記載する<属性>分野を含まなければなりません、そして、SHOULDは<ホスト>を含んでいます(例えば、<ldap://ldap.example.com/cn=カリフォルニア、dcはdc=com?例、cACertificate; バイナリー、crossCertificatePair; 2進の>と等しいです)。
Cooper, et al. Standards Track [Page 52] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[52ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
Omitting the <host> (e.g., <ldap:///cn=exampleCA,dc=example,dc=com? cACertificate;binary>) has the effect of relying on whatever a priori knowledge the client might have to contact an appropriate server.
<ホスト>(例えば、<ldap:///cn=exampleCA、dcは例、dc=com--cACertificate; 2進の>と等しい)を省略するのにおいて、クライアントが適切なサーバに連絡するために持っているどんな先験的な知識も当てにするという効果があります。
Where the information is available via HTTP or FTP, accessLocation MUST be a uniformResourceIdentifier and the URI MUST point to either a single DER encoded certificate as specified in [RFC2585] or a collection of certificates in a BER or DER encoded "certs-only" CMS message as specified in [RFC2797].
情報がHTTPかFTPで利用可能であるところでは、accessLocationはuniformResourceIdentifierであるに違いありません、そして、URIが[RFC2585]の指定されるとしてのコード化された証明書かBERでの証明書の収集を独身のDERに向けなければならない、さもなければ、DERは[RFC2797]の指定されるとしての「本命唯一」のCMSメッセージをコード化しました。
Conforming applications that support HTTP or FTP for accessing certificates MUST be able to accept individual DER encoded certificates and SHOULD be able to accept "certs-only" CMS messages.
個人DERのためにコード化された証明書とSHOULDを受け入れることができる状態で証明書にアクセスするためのサポートHTTPかFTPがあるに違いない利用を従わせて、「本命専用」CMSメッセージを受け入れることができてください。
HTTP server implementations accessed via the URI SHOULD specify the media type application/pkix-cert [RFC2585] in the content-type header field of the response for a single DER encoded certificate and SHOULD specify the media type application/pkcs7-mime [RFC2797] in the content-type header field of the response for "certs-only" CMS messages. For FTP, the name of a file that contains a single DER encoded certificate SHOULD have a suffix of ".cer" [RFC2585] and the name of a file that contains a "certs-only" CMS message SHOULD have a suffix of ".p7c" [RFC2797]. Consuming clients may use the media type or file extension as a hint to the content, but should not depend solely on the presence of the correct media type or file extension in the server response.
独身のDERが証明書をコード化して、SHOULDが「本命専用」CMSメッセージのための応答のcontent typeヘッダーフィールドでメディアタイプpkcs7アプリケーション/パントマイム[RFC2797]を指定するので、URI SHOULDを通してアクセスされたHTTPサーバ実装は応答のcontent typeヘッダーフィールドでメディアタイプpkixアプリケーション/本命[RFC2585]を指定します。 FTP、DERがコード化したシングルを含むファイルの名前のために、証明書SHOULDには、SHOULDに".p7c"[RFC2797]の接尾語があるという「本命専用」CMSメッセージを含む".cer"[RFC2585]の接尾語とファイルの名前があります。 クライアントを消費するのは、ヒントとしてメディアタイプかファイル拡張子を内容に使用するかもしれませんが、唯一サーバ応答における、正しいメディアタイプかファイル拡張子の存在によるべきではありません。
The semantics of other id-ad-caRepository accessLocation name forms are not defined.
他の意味論、イド広告caRepository accessLocation、名前書式は定義されません。
A subjectInfoAccess extension may include multiple instances of the id-ad-caRepository accessMethod. The different instances may specify different methods for accessing the same information or may point to different information. When the id-ad-caRepository accessMethod is used, at least one instance SHOULD specify an accessLocation that is an HTTP [RFC2616] or LDAP [RFC4516] URI.
subjectInfoAccess拡張子が複数のインスタンスを含むかもしれない、イド広告caRepository accessMethod 異なったインスタンスは、同じ情報にアクセスするための異なったメソッドを指定するか、または異なった情報を示すかもしれません。 いつ、イド広告caRepository accessMethod、中古の少なくとも1つのインスタンスのSHOULDはHTTP[RFC2616]かLDAP[RFC4516]URIであるaccessLocationを指定するか。
The id-ad-timeStamping OID is used when the subject offers timestamping services using the Time Stamp Protocol defined in [RFC3161]. Where the timestamping services are available via HTTP or FTP, accessLocation MUST be a uniformResourceIdentifier. Where the timestamping services are available via electronic mail, accessLocation MUST be an rfc822Name. Where timestamping services are available using TCP/IP, the dNSName or iPAddress name forms may be used. The semantics of other name forms of accessLocation (when accessMethod is id-ad-timeStamping) are not defined by this specification.
イド広告timeStamping OID、対象が[RFC3161]で定義されたTime Stampプロトコルを使用することでサービスをtimestampingに提供するとき、使用されます。 timestampingサービスがHTTPかFTPで利用可能であるところでは、accessLocationはuniformResourceIdentifierであるに違いありません。 timestampingサービスが電子メールを通して利用可能であるところでは、accessLocationはrfc822Nameであるに違いありません。 timestampingサービスがどこで形成というTCP/IP、dNSNameまたはiPAddress名を使用することで入手できるかは使用されるかもしれません。 accessLocationの他の名前フォームの意味論、(accessMethodがいつか、イド広告timeStamping、)、この仕様で、定義されません。
Cooper, et al. Standards Track [Page 53] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[53ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
Additional access descriptors may be defined in other PKIX specifications.
追加アクセス記述子は他のPKIX仕様に基づき定義されるかもしれません。
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
イド広告OBJECT IDENTIFIER:、:= イド-pkix48
id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
イド広告caRepository、オブジェクト識別子:、:= イド広告5
id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
イド広告timeStamping、オブジェクト識別子:、:= イド広告3
5. CRL and CRL Extensions Profile
5. CRLとCRL拡大プロフィール
As discussed above, one goal of this X.509 v2 CRL profile is to foster the creation of an interoperable and reusable Internet PKI. To achieve this goal, guidelines for the use of extensions are specified, and some assumptions are made about the nature of information included in the CRL.
上で議論するように、このX.509 v2 CRLプロフィールの1つの目標は共同利用できて再利用できるインターネットPKIの作成を伸ばすことです。 この目標を達成するために、拡張子の使用のためのガイドラインは指定されます、そして、いくつかの仮定がCRLに情報を含む自然に関してされます。
CRLs may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and an even broader spectrum of operational and assurance requirements. This profile establishes a common baseline for generic applications requiring broad interoperability. The profile defines a set of information that can be expected in every CRL. Also, the profile defines common locations within the CRL for frequently used attributes as well as common representations for these attributes.
CRLsは相互運用性目標の広いスペクトルと操作上と保証要件のさらに広いスペクトルを含んでいるさまざまなアプリケーションと環境で使用されるかもしれません。 このプロフィールは広い相互運用性を必要とする一般的適用のために一般的な基線を確立します。 プロフィールはあらゆるCRLで予想できる1セットの情報を定義します。 また、プロフィールはこれらの属性の共通表現と同様に頻繁に使用された属性のためにCRLの中で一般的な位置を定義します。
CRL issuers issue CRLs. The CRL issuer is either the CA or an entity that has been authorized by the CA to issue CRLs. CAs publish CRLs to provide status information about the certificates they issued. However, a CA may delegate this responsibility to another trusted authority.
CRL発行人はCRLsを発行します。 CRL発行人は、CRLsを発行するのがカリフォルニアによって認可されたカリフォルニアか実体のどちらかです。 CAsは、それらが発行した証明書の状態情報を提供するためにCRLsを発行します。 しかしながら、カリフォルニアは別の信じられた権威へこの責任を代表として派遣するかもしれません。
Each CRL has a particular scope. The CRL scope is the set of certificates that could appear on a given CRL. For example, the scope could be "all certificates issued by CA X", "all CA certificates issued by CA X", "all certificates issued by CA X that have been revoked for reasons of key compromise and CA compromise", or a set of certificates based on arbitrary local information, such as "all certificates issued to the NIST employees located in Boulder".
各CRLには、特定の範囲があります。 CRL範囲は与えられたCRLに現れることができた証明書のセットです。 範囲は、例えば、「カリフォルニアXによって発行されたすべての証明書」、「カリフォルニアXによって発行されたすべてのカリフォルニア証明書」、「主要な感染の理由で取り消されたカリフォルニアXによって発行されたすべての証明書とカリフォルニアは妥協する」か、または任意のローカルの情報に基づく、1セットの証明書であるかもしれません、「ボウルダーに位置するNIST従業員に発行されたすべての証明書」などのように。
A complete CRL lists all unexpired certificates, within its scope, that have been revoked for one of the revocation reasons covered by the CRL scope. A full and complete CRL lists all unexpired certificates issued by a CA that have been revoked for any reason. (Note that since CAs and CRL issuers are identified by name, the scope of a CRL is not affected by the key used to sign the CRL or the key(s) used to sign certificates.)
完全なCRLは範囲の中のCRL範囲でカバーされた取消し理由の1つで取り消されたすべての満期になっていない証明書をリストアップします。 完全で完全なCRLはどんな理由でも取り消されて、満期になっていない証明書がカリフォルニアで発行したすべてを記載します。 (CAsとCRL発行人が名前によって特定されるのでCRLの範囲がCRLに署名するのに使用されるキーで影響を受けないか、またはキーが以前はよく証明書に署名していたことに注意してください。)
Cooper, et al. Standards Track [Page 54] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[54ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
If the scope of the CRL includes one or more certificates issued by an entity other than the CRL issuer, then it is an indirect CRL. The scope of an indirect CRL may be limited to certificates issued by a single CA or may include certificates issued by multiple CAs. If the issuer of the indirect CRL is a CA, then the scope of the indirect CRL MAY also include certificates issued by the issuer of the CRL.
CRLの範囲がCRL発行人以外の実体によって発行された1通以上の証明書を含んでいるなら、それは間接的なCRLです。 間接的なCRLの範囲は、単一のカリフォルニアによって発行された証明書に制限されるか、または複数のCAsによって発行された証明書を含めるかもしれません。 また、間接的なCRLの発行人がカリフォルニアであるなら、間接的なCRL MAYの範囲はCRLの発行人によって発行された証明書を含んでいます。
The CRL issuer MAY also generate delta CRLs. A delta CRL only lists those certificates, within its scope, whose revocation status has changed since the issuance of a referenced complete CRL. The referenced complete CRL is referred to as a base CRL. The scope of a delta CRL MUST be the same as the base CRL that it references.
また、CRL発行人は、デルタがCRLsであると生成するかもしれません。 CRLデルタはそれらの証明書をリストアップするだけです、範囲の中で。参照をつけられた完全なCRLの発行以来範囲の取消し状態は変化しています。 参照をつけられた完全なCRLはベースCRLと呼ばれます。 CRL MUSTデルタでは、それが参照をつけるベースCRLと同じであるように見てください。
This profile defines one private Internet CRL extension but does not define any private CRL entry extensions.
このプロフィールは、1つの個人的なインターネットCRL拡張子を定義しますが、少しの個人的なCRLエントリー拡張子も定義しません。
Environments with additional or special purpose requirements may build on this profile or may replace it.
追加しているか専用である要件がある環境は、このプロフィールの上に建てるか、またはそれを取り替えるかもしれません。
Conforming CAs are not required to issue CRLs if other revocation or certificate status mechanisms are provided. When CRLs are issued, the CRLs MUST be version 2 CRLs, include the date by which the next CRL will be issued in the nextUpdate field (Section 5.1.2.5), include the CRL number extension (Section 5.2.3), and include the authority key identifier extension (Section 5.2.1). Conforming applications that support CRLs are REQUIRED to process both version 1 and version 2 complete CRLs that provide revocation information for all certificates issued by one CA. Conforming applications are not required to support processing of delta CRLs, indirect CRLs, or CRLs with a scope other than all certificates issued by one CA.
他の取消しか証明書状態メカニズムを提供するなら、従うCAsはCRLsを発行するのが必要ではありません。 CRLsが発行されるとき、CRLsがバージョン2CRLsであるに違いなく、インクルードが日付である、次のCRLがnextUpdate分野で発行される(セクション5.1 .2 .5) CRL数の拡張子(セクション5.2.3)を含めてください。そうすれば、インクルードは権威の主要な識別子拡張子(セクション5.2.1)を含めます。 CRLsをサポートする従うアプリケーションは1カリフォルニアによって発行されたすべての証明書のための取消し情報を提供するバージョン1とバージョン2の完全なCRLsの両方を処理するREQUIREDです。 従うアプリケーションは、1カリフォルニアによって発行されたすべての証明書以外の範囲でデルタCRLs、間接的なCRLs、またはCRLsの処理をサポートするのに必要ではありません。
5.1. CRL Fields
5.1. CRL分野
The X.509 v2 CRL syntax is as follows. For signature calculation, the data that is to be signed is ASN.1 DER encoded. ASN.1 DER encoding is a tag, length, value encoding system for each element.
X.509 v2 CRL構文は以下の通りです。 署名計算のために、署名されることになっているデータはコード化されたASN.1DERです。 ASN.1DERコード化はタグ、長さ、それぞれの要素のシステムをコード化する値です。
Cooper, et al. Standards Track [Page 55] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[55ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
CertificateList ::= SEQUENCE {
tbsCertList TBSCertList,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
CertificateList:、:= 系列tbsCertList TBSCertList、signatureAlgorithm AlgorithmIdentifier、signatureValueビット列
TBSCertList ::= SEQUENCE {
version Version OPTIONAL,
-- if present, MUST be v2
signature AlgorithmIdentifier,
issuer Name,
thisUpdate Time,
nextUpdate Time OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate Time,
crlEntryExtensions Extensions OPTIONAL
-- if present, version MUST be v2
} OPTIONAL,
crlExtensions [0] EXPLICIT Extensions OPTIONAL
-- if present, version MUST be v2
}
TBSCertList:、:= 系列バージョンバージョンOPTIONAL--、発行人v2署名がAlgorithmIdentifierであったに違いないならNameを寄贈してください、thisUpdate Time、nextUpdate Time OPTIONAL、revokedCertificates SEQUENCE OF SEQUENCE、userCertificate CertificateSerialNumber、revocationDate Time、crlEntryExtensions Extensions OPTIONAL--プレゼント、バージョンがそうしなければならないならv2になってください、OPTIONAL、crlExtensions[0]EXPLICIT Extensions OPTIONAL--プレゼント、バージョンがそうしなければならないなら、v2になってください。
-- Version, Time, CertificateSerialNumber, and Extensions -- are all defined in the ASN.1 in Section 4.1
-- バージョン、Time、CertificateSerialNumber、およびExtensions--セクション4.1でASN.1ですべて定義されます。
-- AlgorithmIdentifier is defined in Section 4.1.1.2
-- AlgorithmIdentifier、定義されたコネセクション4.1.1は.2です。
The following items describe the use of the X.509 v2 CRL in the Internet PKI.
以下の項目はインターネットPKIでのX.509 v2 CRLの使用について説明します。
5.1.1. CertificateList Fields
5.1.1. CertificateList分野
The CertificateList is a SEQUENCE of three required fields. The fields are described in detail in the following subsections.
CertificateListは3つの必須項目のSEQUENCEです。 分野は以下の小区分で詳細に説明されます。
5.1.1.1. tbsCertList
5.1.1.1. tbsCertList
The first field in the sequence is the tbsCertList. This field is itself a sequence containing the name of the issuer, issue date, issue date of the next list, the optional list of revoked certificates, and optional CRL extensions. When there are no revoked certificates, the revoked certificates list is absent. When one or more certificates are revoked, each entry on the revoked certificate list is defined by a sequence of user certificate serial number, revocation date, and optional CRL entry extensions.
系列における最初の分野はtbsCertListです。 この分野は、それ自体で発行人の名前、問題日付、次のリストの問題日付、取り消された証明書の任意のリストを含む系列と任意のCRL拡張子です。 証明書が取り消されないとき、取り消された証明書リストは欠けています。 1通以上の証明書が取り消されるとき、取り消された証明書リストの上の各エントリーはユーザー証明書通し番号、取消し期日、および任意のCRLエントリー拡張子の系列によって定義されます。
Cooper, et al. Standards Track [Page 56] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[56ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
5.1.1.2. signatureAlgorithm
5.1.1.2. signatureAlgorithm
The signatureAlgorithm field contains the algorithm identifier for the algorithm used by the CRL issuer to sign the CertificateList. The field is of type AlgorithmIdentifier, which is defined in Section 4.1.1.2. [RFC3279], [RFC4055], and [RFC4491] list supported algorithms for this specification, but other signature algorithms MAY also be supported.
signatureAlgorithm分野はCertificateListに署名するのにCRL発行人によって使用されたアルゴリズムのためのアルゴリズム識別子を含んでいます。 タイプAlgorithmIdentifierには分野があります。(AlgorithmIdentifierはセクション4.1.1で.2に定義されます)。 [RFC3279]、[RFC4055]、および[RFC4491]リストはこの仕様のためにアルゴリズムをサポートしましたが、また、他の署名アルゴリズムはサポートされるかもしれません。
This field MUST contain the same algorithm identifier as the signature field in the sequence tbsCertList (Section 5.1.2.2).
この分野が系列tbsCertListの署名分野と同じアルゴリズム識別子を含まなければならない、(セクション5.1 .2 .2)。
5.1.1.3. signatureValue
5.1.1.3. signatureValue
The signatureValue field contains a digital signature computed upon the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList is used as the input to the signature function. This signature value is encoded as a BIT STRING and included in the CRL signatureValue field. The details of this process are specified for each of the supported algorithms in [RFC3279], [RFC4055], and [RFC4491].
計算されて、signatureValue分野はデジタル署名を含んでいます。ASN.1DERはtbsCertListをコード化しました。 署名への入力が機能するので、ASN.1DERは使用されるtbsCertListをコード化しました。 この署名値は、BIT STRINGとしてコード化されて、CRL signatureValue分野に含まれています。 このプロセスの細部は[RFC3279]、[RFC4055]、および[RFC4491]のそれぞれのサポートしているアルゴリズムに指定されます。
CAs that are also CRL issuers MAY use one private key to digitally sign certificates and CRLs, or MAY use separate private keys to digitally sign certificates and CRLs. When separate private keys are employed, each of the public keys associated with these private keys is placed in a separate certificate, one with the keyCertSign bit set in the key usage extension, and one with the cRLSign bit set in the key usage extension (Section 4.2.1.3). When separate private keys are employed, certificates issued by the CA contain one authority key identifier, and the corresponding CRLs contain a different authority key identifier. The use of separate CA certificates for validation of certificate signatures and CRL signatures can offer improved security characteristics; however, it imposes a burden on applications, and it might limit interoperability. Many applications construct a certification path, and then validate the certification path (Section 6). CRL checking in turn requires a separate certification path to be constructed and validated for the CA's CRL signature validation certificate. Applications that perform CRL checking MUST support certification path validation when certificates and CRLs are digitally signed with the same CA private key. These applications SHOULD support certification path validation when certificates and CRLs are digitally signed with different CA private keys.
またCRL発行人であるCAsは、証明書とCRLsにデジタルに署名するのに1つの秘密鍵を使用するか、または証明書とCRLsにデジタルに署名するのに別々の秘密鍵を使用するかもしれません。 別々の秘密鍵が採用しているとき、これらの秘密鍵に関連づけられたそれぞれの公開鍵は別々の証明書に置かれます、主要な用法拡大で設定されたkeyCertSignビットがある1、cRLSignビットがある1つが主要な用法拡大でセットした、(セクション4.2 .1 .3)。 別々の秘密鍵が採用しているとき、カリフォルニアによって発行された証明書は1つの権威の主要な識別子を含んでいます、そして、対応するCRLsは異なった権威主要な識別子を含んでいます。 別々のカリフォルニア証明書の証明書署名とCRL署名の合法化の使用は改良されたセキュリティの特性を提供できます。 しかしながら、アプリケーションのときに、負担をかけます、そして、相互運用性を制限するかもしれません。 多くのアプリケーションが、証明経路を構成して、次に、証明経路(セクション6)を有効にします。 順番にチェックするCRLは、別々の証明経路がCAのCRL署名合法化証明書のために組み立てられて、有効にされるのを必要とします。 証明書とCRLsが同じカリフォルニア秘密鍵をデジタルに契約されるとき、CRLの照合を実行するアプリケーションは証明経路合法化をサポートしなければなりません。 証明書とCRLsがデジタルなそうであることのSHOULDが証明経路合法化をサポートするこれらのアプリケーションは異なったカリフォルニア秘密鍵と契約しました。
Cooper, et al. Standards Track [Page 57] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[57ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
5.1.2. Certificate List "To Be Signed"
5.1.2. リストを証明して、「署名されてください」。
The certificate list to be signed, or TBSCertList, is a sequence of required and optional fields. The required fields identify the CRL issuer, the algorithm used to sign the CRL, and the date and time the CRL was issued.
署名される証明書リスト、またはTBSCertListが必要で任意の分野の系列です。 必須項目はCRL発行人を特定して、CRL、および日時がCRLであると署名するのに使用されるアルゴリズムを発行しました。
Optional fields include the date and time by which the CRL issuer will issue the next CRL, lists of revoked certificates, and CRL extensions. The revoked certificate list is optional to support the case where a CA has not revoked any unexpired certificates that it has issued. This profile requires conforming CRL issuers to include the nextUpdate field and the CRL number and authority key identifier CRL extensions in all CRLs issued.
任意の分野は日付、時間、CRL発行人が次のCRL、取り消された証明書のリストを発行するおよびCRL拡張子を含んでいます。 取り消された証明書リストは、カリフォルニアがそれが発行したどんな満期になっていない証明書も取り消していないケースを支えるために任意です。 このプロフィールは、すべてのCRLsのCRL拡張子が発行したnextUpdate分野、CRL番号、および権威の主要な識別子を含むようにCRL発行人を従わせるのを必要とします。
5.1.2.1. Version
5.1.2.1. バージョン
This optional field describes the version of the encoded CRL. When extensions are used, as required by this profile, this field MUST be present and MUST specify version 2 (the integer value is 1).
この任意の分野はコード化されたCRLのバージョンについて説明します。 拡張子が必要に応じてこのプロフィールによって使用されるとき、この分野は、存在していなければならなくて、バージョン2を指定しなければなりません(整数値は1です)。
5.1.2.2. Signature
5.1.2.2. 署名
This field contains the algorithm identifier for the algorithm used to sign the CRL. [RFC3279], [RFC4055], and [RFC4491] list OIDs for the most popular signature algorithms used in the Internet PKI.
この分野はCRLにサインするのに使用されるアルゴリズムのためのアルゴリズム識別子を含んでいます。 最もポピュラーな署名アルゴリズムのための[RFC3279]、[RFC4055]、および[RFC4491]リストOIDsはインターネットでPKIを使用しました。
This field MUST contain the same algorithm identifier as the signatureAlgorithm field in the sequence CertificateList (Section 5.1.1.2).
この分野が系列CertificateListのsignatureAlgorithm分野と同じアルゴリズム識別子を含まなければならない、(セクション5.1 .1 .2)。
5.1.2.3. Issuer Name
5.1.2.3. 発行人名
The issuer name identifies the entity that has signed and issued the CRL. The issuer identity is carried in the issuer field. Alternative name forms may also appear in the issuerAltName extension (Section 5.2.2). The issuer field MUST contain a non-empty X.500 distinguished name (DN). The issuer field is defined as the X.501 type Name, and MUST follow the encoding rules for the issuer name field in the certificate (Section 4.1.2.4).
発行人名はCRLにサインして、発行した実体を特定します。 発行人のアイデンティティは発行人分野で運ばれます。 また、代替名フォームはissuerAltName拡張子(セクション5.2.2)に現れるかもしれません。 発行人分野は非空のX.500分類名(DN)を含まなければなりません。 発行人分野がX.501タイプNameと定義されて、証明書の発行人名前欄に符号化規則に従わなければならない、(セクション4.1 .2 .4)。
5.1.2.4. This Update
5.1.2.4. このアップデート
This field indicates the issue date of this CRL. thisUpdate may be encoded as UTCTime or GeneralizedTime.
この分野は、このCRL. thisUpdateの問題日付がUTCTimeかGeneralizedTimeとしてコード化されるかもしれないのを示します。
CRL issuers conforming to this profile MUST encode thisUpdate as UTCTime for dates through the year 2049. CRL issuers conforming to
このプロフィールに従うCRL発行人は日付から2049年のUTCTimeとしてthisUpdateをコード化しなければなりません。 CRL発行人は従います。
Cooper, et al. Standards Track [Page 58] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[58ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
this profile MUST encode thisUpdate as GeneralizedTime for dates in the year 2050 or later. Conforming applications MUST be able to process dates that are encoded in either UTCTime or GeneralizedTime.
このプロフィールは2050年か後で日付にGeneralizedTimeとしてthisUpdateをコード化しなければなりません。 アプリケーションを従わせると、UTCTimeかGeneralizedTimeのどちらかでコード化される日付は処理できなければなりません。
Where encoded as UTCTime, thisUpdate MUST be specified and interpreted as defined in Section 4.1.2.5.1. Where encoded as GeneralizedTime, thisUpdate MUST be specified and interpreted as defined in Section 4.1.2.5.2.
UTCTimeとしてコード化されるところでは、指定していなければならなくて、解釈されたthisUpdateはセクション4.1.2で.1に.5を定義しました。 GeneralizedTimeとしてコード化されるところでは、指定していなければならなくて、解釈されたthisUpdateはセクション4.1.2で.2に.5を定義しました。
5.1.2.5. Next Update
5.1.2.5. 次のアップデート
This field indicates the date by which the next CRL will be issued. The next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date. CRL issuers SHOULD issue CRLs with a nextUpdate time equal to or later than all previous CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime.
この分野は日付を次のCRLが発行される示します。 示された日以前、次のCRLを発行できましたが、示された期日より遅いいずれもそれに発行されないでしょう。 CRL発行人SHOULDはUTCTimeとしての等しいかnextUpdate時間前のすべてのCRLs. nextUpdateがコード化されるかもしれないより後半かGeneralizedTimeと共にCRLsを発行します。
Conforming CRL issuers MUST include the nextUpdate field in all CRLs. Note that the ASN.1 syntax of TBSCertList describes this field as OPTIONAL, which is consistent with the ASN.1 structure defined in [X.509]. The behavior of clients processing CRLs that omit nextUpdate is not specified by this profile.
CRL発行人を従わせると、すべてのCRLsのnextUpdate分野は包含しなければなりません。 TBSCertListのASN.1構文がこの野原をOPTIONALとして記述することに注意してください。(OPTIONALは[X.509]で定義されるASN.1構造と一致しています)。 nextUpdateを省略するクライアント処理CRLsの動きはこのプロフィールによって指定されません。
CRL issuers conforming to this profile MUST encode nextUpdate as UTCTime for dates through the year 2049. CRL issuers conforming to this profile MUST encode nextUpdate as GeneralizedTime for dates in the year 2050 or later. Conforming applications MUST be able to process dates that are encoded in either UTCTime or GeneralizedTime.
このプロフィールに従うCRL発行人は日付から2049年のUTCTimeとしてnextUpdateをコード化しなければなりません。 このプロフィールに従うCRL発行人は2050年か後で日付にGeneralizedTimeとしてnextUpdateをコード化しなければなりません。 アプリケーションを従わせると、UTCTimeかGeneralizedTimeのどちらかでコード化される日付は処理できなければなりません。
Where encoded as UTCTime, nextUpdate MUST be specified and interpreted as defined in Section 4.1.2.5.1. Where encoded as GeneralizedTime, nextUpdate MUST be specified and interpreted as defined in Section 4.1.2.5.2.
UTCTimeとしてコード化されるところでは、指定していなければならなくて、解釈されたnextUpdateはセクション4.1.2で.1に.5を定義しました。 GeneralizedTimeとしてコード化されるところでは、指定していなければならなくて、解釈されたnextUpdateはセクション4.1.2で.2に.5を定義しました。
5.1.2.6. Revoked Certificates
5.1.2.6. 取り消された証明書
When there are no revoked certificates, the revoked certificates list MUST be absent. Otherwise, revoked certificates are listed by their serial numbers. Certificates revoked by the CA are uniquely identified by the certificate serial number. The date on which the revocation occurred is specified. The time for revocationDate MUST be expressed as described in Section 5.1.2.4. Additional information may be supplied in CRL entry extensions; CRL entry extensions are discussed in Section 5.3.
証明書が取り消されないとき、取り消された証明書リストは欠けているに違いありません。 さもなければ、取り消された証明書はそれらの通し番号によってリストアップされます。 カリフォルニアによって取り消された証明書は証明書通し番号によって唯一特定されます。 取消しが起こった日付は指定されます。 セクション5.1.2で.4について説明するとき、revocationDateのための時間を言い表さなければなりません。 CRLエントリー拡張子で追加情報を提供するかもしれません。 セクション5.3でCRLエントリー拡張子について議論します。
Cooper, et al. Standards Track [Page 59] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[59ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
5.1.2.7. Extensions
5.1.2.7. 拡大
This field may only appear if the version is 2 (Section 5.1.2.1). If present, this field is a sequence of one or more CRL extensions. CRL extensions are discussed in Section 5.2.
この野原がバージョンが2である場合にだけ現れるかもしれない、(セクション5.1 .2 .1)。 存在しているなら、この分野は1つ以上のCRL拡張子の系列です。 セクション5.2でCRL拡張子について議論します。
5.2. CRL Extensions
5.2. CRL拡張子
The extensions defined by ANSI X9, ISO/IEC, and ITU-T for X.509 v2 CRLs [X.509] [X9.55] provide methods for associating additional attributes with CRLs. The X.509 v2 CRL format also allows communities to define private extensions to carry information unique to those communities. Each extension in a CRL may be designated as critical or non-critical. If a CRL contains a critical extension that the application cannot process, then the application MUST NOT use that CRL to determine the status of certificates. However, applications may ignore unrecognized non-critical extensions. The following subsections present those extensions used within Internet CRLs. Communities may elect to include extensions in CRLs that are not defined in this specification. However, caution should be exercised in adopting any critical extensions in CRLs that might be used in a general context.
X.509 v2 CRLs[X.509][X9.55]のためのANSI X9、ISO/IEC、およびITU-Tによって定義された拡大は追加属性を関連づけるための方法にCRLsを提供します。 また、X.509 v2 CRL形式で、共同体は、それらの共同体にユニークな情報を運ぶために個人的な拡大を定義できます。 CRLでの各拡大は批判的であるか非臨界であるとして指定されるかもしれません。 CRLがアプリケーションが処理できない批判的な拡大を含んでいるなら、アプリケーションは、証明書の状態を決定するのにそのCRLを使用してはいけません。 しかしながら、アプリケーションは認識されていない非臨界拡大を無視するかもしれません。 以下の小区分はインターネットCRLsの中で使用されたそれらの拡張子を提示します。 共同体は、この仕様に基づき定義されないCRLsに拡大を含んでいるのを選ぶかもしれません。 しかしながら、警告は一般情勢で使用されるかもしれないCRLsでのどんな批判的な拡大も採用するのに訓練されるべきです。
Conforming CRL issuers are REQUIRED to include the authority key identifier (Section 5.2.1) and the CRL number (Section 5.2.3) extensions in all CRLs issued.
従っているCRL発行人は、権威の主要な識別子(セクション5.2.1)を含むREQUIREDとすべてのCRLsでの数(セクション5.2.3)の拡大が発行したCRLです。
5.2.1. Authority Key Identifier
5.2.1. 権威の主要な識別子
The authority key identifier extension provides a means of identifying the public key corresponding to the private key used to sign a CRL. The identification can be based on either the key identifier (the subject key identifier in the CRL signer's certificate) or the issuer name and serial number. This extension is especially useful where an issuer has more than one signing key, either due to multiple concurrent key pairs or due to changeover.
権威の主要な識別子拡張子はCRLにサインするのに使用される秘密鍵に対応する公開鍵を特定する手段を提供します。 識別は発行人名と主要な識別子(CRL署名者の証明書の対象の主要な識別子)か通し番号のどちらかに基づくことができます。 この拡大は発行人が複数の同時発生の主要な組のためか転換のため1個以上の調印キーを持っているところで特に役に立ちます。
Conforming CRL issuers MUST use the key identifier method, and MUST include this extension in all CRLs issued.
CRL発行人を従わせると、主要な識別子方法が使用されなければならなくて、この拡大はCRLsが発行したすべてに含まれなければなりません。
The syntax for this CRL extension is defined in Section 4.2.1.1.
このCRL拡張子のための構文はセクション4.2.1で.1に定義されます。
5.2.2. Issuer Alternative Name
5.2.2. 発行人代替名
The issuer alternative name extension allows additional identities to be associated with the issuer of the CRL. Defined options include an electronic mail address (rfc822Name), a DNS name, an IP address, and a URI. Multiple instances of a name form and multiple name forms may
拡大という発行人代替名は、追加アイデンティティがCRLの発行人に関連しているのを許容します。 定義されたオプションは電子メールアドレス(rfc822Name)、DNS名、IPアドレス、およびURIを含んでいます。 名前フォームと複数の名前用紙の複数の例はそうするかもしれません。
Cooper, et al. Standards Track [Page 60] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[60ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
be included. Whenever such identities are used, the issuer alternative name extension MUST be used; however, a DNS name MAY be represented in the issuer field using the domainComponent attribute as described in Section 4.1.2.4.
含められてください。 そのようなアイデンティティが使用されているときはいつも、拡大という発行人代替名を使用しなければなりません。 しかしながら、DNS名はセクション4.1.2で.4に説明されるようにdomainComponent属性を使用する発行人分野に表されるかもしれません。
Conforming CRL issuers SHOULD mark the issuerAltName extension as non-critical.
従っているCRL発行人SHOULDは、非臨界であるとしてissuerAltNameが拡大であるとマークします。
The OID and syntax for this CRL extension are defined in Section 4.2.1.7.
このCRL拡張子のためのOIDと構文はセクション4.2.1で.7に定義されます。
5.2.3. CRL Number
5.2.3. CRL番号
The CRL number is a non-critical CRL extension that conveys a monotonically increasing sequence number for a given CRL scope and CRL issuer. This extension allows users to easily determine when a particular CRL supersedes another CRL. CRL numbers also support the identification of complementary complete CRLs and delta CRLs. CRL issuers conforming to this profile MUST include this extension in all CRLs and MUST mark this extension as non-critical.
CRL番号は与えられたCRL範囲とCRL発行人のために単調に増加する一連番号を伝える非臨界CRL拡張子です。 この拡大で、ユーザは、特定のCRLがいつ別のCRLに取って代わるかを容易に決心できます。 また、CRL番号は補足的な完全なCRLsとデルタCRLsの識別を支持します。 このプロフィールに従うCRL発行人は、すべてのCRLsにこの拡大を含まなければならなくて、非臨界であるとしてこの拡大をマークしなければなりません。
If a CRL issuer generates delta CRLs in addition to complete CRLs for a given scope, the complete CRLs and delta CRLs MUST share one numbering sequence. If a delta CRL and a complete CRL that cover the same scope are issued at the same time, they MUST have the same CRL number and provide the same revocation information. That is, the combination of the delta CRL and an acceptable complete CRL MUST provide the same revocation information as the simultaneously issued complete CRL.
CRL発行人が与えられた範囲への完全なCRLsに加えてデルタCRLsを発生させるなら、CRLsの完全なCRLsとデルタは1つの付番系列を共有しなければなりません。 同じ範囲を覆うCRLデルタと完全なCRLが同時に発行されるなら、彼らは、同じCRL番号を持って、同じ取消し情報を提供しなければなりません。 すなわち、CRLデルタの組み合わせと許容できる完全なCRL MUSTは同時に発行された完全なCRLと同じ取消し情報を提供します。
If a CRL issuer generates two CRLs (two complete CRLs, two delta CRLs, or a complete CRL and a delta CRL) for the same scope at different times, the two CRLs MUST NOT have the same CRL number. That is, if the this update field (Section 5.1.2.4) in the two CRLs are not identical, the CRL numbers MUST be different.
CRL発行人がいろいろな時間に2CRLs(2完全なCRLsか、2デルタCRLsか、完全なCRLとCRLデルタ)を同じ範囲に発生させるなら、2CRLsには、同じCRL番号があってはいけません。 すなわち、このアップデート分野、(セクション5.1 .2 .4) 2が、CRLsは同じでない、CRL番号が異なっているに違いありません。
Given the requirements above, CRL numbers can be expected to contain long integers. CRL verifiers MUST be able to handle CRLNumber values up to 20 octets. Conforming CRL issuers MUST NOT use CRLNumber values longer than 20 octets.
上記の要件を考えて、CRL番号が長整数型を含むと予想できます。 CRL検証はCRLNumber値を20の八重奏まで扱うことができなければなりません。 CRL発行人を従わせると、CRLNumber値は20の八重奏より長い間、使用されてはいけません。
id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
イドCe cRLNumber、物の識別子:、:= イドCe20
CRLNumber ::= INTEGER (0..MAX)
CRLNumber:、:= 整数(0..MAX)
Cooper, et al. Standards Track [Page 61] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[61ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
5.2.4. Delta CRL Indicator
5.2.4. デルタCRLインディケータ
The delta CRL indicator is a critical CRL extension that identifies a CRL as being a delta CRL. Delta CRLs contain updates to revocation information previously distributed, rather than all the information that would appear in a complete CRL. The use of delta CRLs can significantly reduce network load and processing time in some environments. Delta CRLs are generally smaller than the CRLs they update, so applications that obtain delta CRLs consume less network bandwidth than applications that obtain the corresponding complete CRLs. Applications that store revocation information in a format other than the CRL structure can add new revocation information to the local database without reprocessing information.
デルタCRLインディケータはCRLデルタであるとしてCRLを特定する批判的なCRL拡張子です。 デルタCRLsは以前に完全なCRLに現れるすべての情報よりむしろ分配された取消し情報にアップデートを含んでいます。 デルタCRLsの使用はいくつかの環境でネットワーク負荷と処理時間をかなり短縮できます。 デルタCRLsが彼らがアップデートするCRLsより一般に小さいので、デルタCRLsを入手するアプリケーションが対応する完全なCRLsを入手するアプリケーションより少ないネットワーク回線容量を消費します。 CRL構造以外の形式で取消し情報を格納するアプリケーションは再処理情報なしで新しい取消し情報をローカルのデータベースに追加できます。
The delta CRL indicator extension contains the single value of type BaseCRLNumber. The CRL number identifies the CRL, complete for a given scope, that was used as the starting point in the generation of this delta CRL. A conforming CRL issuer MUST publish the referenced base CRL as a complete CRL. The delta CRL contains all updates to the revocation status for that same scope. The combination of a delta CRL plus the referenced base CRL is equivalent to a complete CRL, for the applicable scope, at the time of publication of the delta CRL.
デルタCRLインディケータ拡張子はタイプBaseCRLNumberのただ一つの値を含んでいます。 CRL番号はこのCRLデルタの世代における出発点として使用された与えられた範囲に、完全なCRLを特定します。 従っているCRL発行人は完全なCRLとして参照をつけられたベースCRLを発行しなければなりません。 CRLデルタはその同じ範囲への取消し状態にすべてのアップデートを含んでいます。 CRLデルタの組み合わせと参照をつけられたベースCRLは完全なCRLに同等です、適用範囲に、CRLデルタの公表時点で。
When a conforming CRL issuer generates a delta CRL, the delta CRL MUST include a critical delta CRL indicator extension.
従っているCRL発行人がCRLデルタを発生させるとき、デルタCRL MUSTは批判的なデルタCRLインディケータ拡張子を含んでいます。
When a delta CRL is issued, it MUST cover the same set of reasons and the same set of certificates that were covered by the base CRL it references. That is, the scope of the delta CRL MUST be the same as the scope of the complete CRL referenced as the base. The referenced base CRL and the delta CRL MUST omit the issuing distribution point extension or contain identical issuing distribution point extensions. Further, the CRL issuer MUST use the same private key to sign the delta CRL and any complete CRL that it can be used to update.
CRLデルタが発行されるとき、それはそれが参照をつけるベースCRLで含まれていた同じセットの理由と同じセットの証明書を含まなければなりません。 それはそうです、範囲。CRL MUSTデルタでは、ベースとして参照をつけられる完全CRLの範囲と同じにしてください。 参照をつけられたベースCRLとCRL MUSTデルタは、発行している分配ポイント拡大を省略するか、または同じ発行している分配ポイント拡大を含んでいます。 さらに、CRL発行人は、アップデートするのにそれを使用できるCRLデルタとどんな完全なCRLにもサインするのに同じ秘密鍵を使用しなければなりません。
An application that supports delta CRLs can construct a CRL that is complete for a given scope by combining a delta CRL for that scope with either an issued CRL that is complete for that scope or a locally constructed CRL that is complete for that scope.
デルタCRLsを支持するアプリケーションは与えられた範囲に、その範囲に、完全な発行されたCRLかその範囲に、完全な局所的に組み立てられたCRLのどちらかと共にCRLデルタをその範囲に結合することによって完全なCRLを組み立てることができます。
When a delta CRL is combined with a complete CRL or a locally constructed CRL, the resulting locally constructed CRL has the CRL number specified in the CRL number extension found in the delta CRL used in its construction. In addition, the resulting locally constructed CRL has the thisUpdate and nextUpdate times specified in
CRLデルタが完全なCRLか局所的に組み立てられたCRLに結合されるとき、結果として起こる局所的に組み立てられたCRLは構造に使用されるCRLデルタの中で見つけられたCRL数の拡張子でCRL番号を指定させます。 さらに、結果として起こる局所的に組み立てられたCRLは回が指定したthisUpdateとnextUpdateを持っています。
Cooper, et al. Standards Track [Page 62] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[62ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
the corresponding fields of the delta CRL used in its construction. In addition, the locally constructed CRL inherits the issuing distribution point from the delta CRL.
構造に使用されるCRLデルタの対応する野原。 さらに、局所的に組み立てられたCRLはCRLデルタから発行している分配ポイントを引き継ぎます。
A complete CRL and a delta CRL MAY be combined if the following four conditions are satisfied:
以下の4つの条件が満たされているなら、Aは結合されたCRL MAYのCRLとデルタを完成します:
(a) The complete CRL and delta CRL have the same issuer.
(a) CRLの完全なCRLとデルタには、同じ発行人があります。
(b) The complete CRL and delta CRL have the same scope. The two
CRLs have the same scope if either of the following
conditions are met:
(b) CRLの完全なCRLとデルタには、同じ範囲があります。 2CRLsには、以下の条件のどちらかが会われるなら、同じ範囲があります:
(1) The issuingDistributionPoint extension is omitted from
both the complete CRL and the delta CRL.
(1) issuingDistributionPoint拡張子は完全なCRLとCRLデルタの両方から省略されます。
(2) The issuingDistributionPoint extension is present in both
the complete CRL and the delta CRL, and the values for
each of the fields in the extensions are the same in both
CRLs.
(2) issuingDistributionPoint拡張子は完全なCRLとCRLデルタの両方に存在しています、そして、拡大における、それぞれの分野への値は両方のCRLsで同じです。
(c) The CRL number of the complete CRL is equal to or greater
than the BaseCRLNumber specified in the delta CRL. That is,
the complete CRL contains (at a minimum) all the revocation
information held by the referenced base CRL.
(c) CRLデルタの中では、完全なCRLのCRL数は、等しいか、またはBaseCRLNumberが指定したより大きいです。 すなわち、完全なCRLは参照をつけられたベースCRLによって保持されたすべての取消し情報を含んでいます(最小限で)。
(d) The CRL number of the complete CRL is less than the CRL
number of the delta CRL. That is, the delta CRL follows the
complete CRL in the numbering sequence.
(d) 完全なCRLのCRL番号はCRLデルタのCRL番号より少ないです。 すなわち、CRLデルタは付番系列で完全なCRLに続きます。
CRL issuers MUST ensure that the combination of a delta CRL and any appropriate complete CRL accurately reflects the current revocation status. The CRL issuer MUST include an entry in the delta CRL for each certificate within the scope of the delta CRL whose status has changed since the generation of the referenced base CRL:
CRL発行人は、CRLデルタとどんな適切な完全なCRLの組み合わせも正確に現在の取消し状態を反映するのを確実にしなければなりません。 CRL発行人は参照をつけられたベースCRLの世代以来状態が変化しているCRLデルタの範囲の中の各証明書のためのCRLデルタにエントリーを含まなければなりません:
(a) If the certificate is revoked for a reason included in the
scope of the CRL, list the certificate as revoked.
(a) 証明書がCRLの範囲に理由を含むように取り消されるなら、取り消されるように証明書をリストアップしてください。
(b) If the certificate is valid and was listed on the referenced
base CRL or any subsequent CRL with reason code
certificateHold, and the reason code certificateHold is
included in the scope of the CRL, list the certificate with
the reason code removeFromCRL.
(b) 証明書が有効であり、理由コードcertificateHoldと共に参照をつけられたベースCRLかどんなその後のCRLにもリストアップされて、理由コードcertificateHoldがCRLの範囲で含められているなら、理由コードremoveFromCRLと共に証明書をリストアップしてください。
Cooper, et al. Standards Track [Page 63] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[63ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
(c) If the certificate is revoked for a reason outside the scope
of the CRL, but the certificate was listed on the referenced
base CRL or any subsequent CRL with a reason code included in
the scope of this CRL, list the certificate as revoked but
omit the reason code.
(c) 証明書がCRLの範囲の外の理由で取り消されましたが、理由コードがこのCRLの範囲に含まれている状態で証明書が参照をつけられたベースCRLかどんなその後のCRLにもリストアップされたなら、取り消されるように証明書をリストアップしなさい、ただし、理由コードを省略してください。
(d) If the certificate is revoked for a reason outside the scope
of the CRL and the certificate was neither listed on the
referenced base CRL nor any subsequent CRL with a reason code
included in the scope of this CRL, do not list the
certificate on this CRL.
(d) 証明書がCRLの範囲の外の理由で取り消されて、このCRLの範囲で参照をつけられたベースCRLに記載されていて、理由コードがあるどんなその後のCRLも含めて、証明書がどちらもでなかった、このCRLに証明書をリストアップしないでください。
The status of a certificate is considered to have changed if it is revoked (for any revocation reason, including certificateHold), if it is released from hold, or if its revocation reason changes.
証明書の状態が、それが取り消されるかどうかを(どんな取消し理由でもcertificateHoldを含んでいます)変えたと考えられます、それが保持からリリースされるか、または取消し理由が変化するなら。
It is appropriate to list a certificate with reason code removeFromCRL on a delta CRL even if the certificate was not on hold in the referenced base CRL. If the certificate was placed on hold in any CRL issued after the base but before this delta CRL and then released from hold, it MUST be listed on the delta CRL with revocation reason removeFromCRL.
証明書がオンでなかったとしてもCRLデルタのコードremoveFromCRLが参照をつけられたベースCRLで成立する理由で証明書をリストアップするのは適切です。 証明書がベースの後にもかかわらず、次に、このCRLデルタであって保持からリリースされている前を除いて、発行されたどんなCRLでの保持にも置かれたなら、取消し理由removeFromCRLと共にCRLデルタにそれを記載しなければなりません。
A CRL issuer MAY optionally list a certificate on a delta CRL with reason code removeFromCRL if the notAfter time specified in the certificate precedes the thisUpdate time specified in the delta CRL and the certificate was listed on the referenced base CRL or in any CRL issued after the base but before this delta CRL.
CRL発行人は任意に証明書で指定されたnotAfter時間がCRLデルタと証明書で指定されたthisUpdate時間に先行するならコードremoveFromCRLが参照をつけられたベースCRLの上、または、ベースの後に発行されたどんなCRLにも記載された理由にもかかわらず、このCRLデルタの前のCRLデルタに証明書をリストアップするかもしれません。
If a certificate revocation notice first appears on a delta CRL, then it is possible for the certificate validity period to expire before the next complete CRL for the same scope is issued. In this case, the revocation notice MUST be included in all subsequent delta CRLs until the revocation notice is included on at least one explicitly issued complete CRL for this scope.
証明書取消し通知が最初にCRLデルタに現れるなら、同じ範囲への次の完全なCRLが発行される前に期限が切れるのは証明書有効期間の間、可能です。 この場合、取消し通知がこの範囲への少なくとも1明らかに発行された完全なCRLに含まれるまで、すべてのCRLsのその後のデルタに取消し通知を含まなければなりません。
An application that supports delta CRLs MUST be able to construct a current complete CRL by combining a previously issued complete CRL and the most current delta CRL. An application that supports delta CRLs MAY also be able to construct a current complete CRL by combining a previously locally constructed complete CRL and the current delta CRL. A delta CRL is considered to be the current one if the current time is between the times contained in the thisUpdate and nextUpdate fields. Under some circumstances, the CRL issuer may publish one or more delta CRLs before the time indicated by the nextUpdate field. If more than one current delta CRL for a given scope is encountered, the application SHOULD consider the one with the latest value in thisUpdate to be the most current one.
デルタがCRLsであるとサポートするアプリケーションは、以前に発行された完全なCRLとCRLの最も現在のデルタを結合することによって、現在の完全なCRLを組み立てることができなければなりません。 また、デルタがCRLsであるとサポートするアプリケーションは、以前に局所的に組み立てられた完全なCRLとCRLの現在のデルタを結合することによって、現在の完全なCRLを組み立てることができるかもしれません。 thisUpdateとnextUpdate分野に保管されていた回の間には、現在の時間があるなら、CRLデルタは現在のものであると考えられます。 いくつかの状況で、CRL発行人は時間の前のCRLsがnextUpdate分野で示した1つ以上のデルタを発行するかもしれません。 与えられた範囲への1つ以上の電流のデルタCRLが遭遇するなら、アプリケーションSHOULDは、最新の値がthisUpdateにある1つが最も現在のものであると考えます。
Cooper, et al. Standards Track [Page 64] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[64ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
イドCe deltaCRLIndicator、オブジェクト識別子:、:= イドCe27
BaseCRLNumber ::= CRLNumber
BaseCRLNumber:、:= CRLNumber
5.2.5. Issuing Distribution Point
5.2.5. 分配ポイントを発行します。
The issuing distribution point is a critical CRL extension that identifies the CRL distribution point and scope for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA certificates only, attribute certificates only, or a limited set of reason codes. Although the extension is critical, conforming implementations are not required to support this extension. However, implementations that do not support this extension MUST either treat the status of any certificate not listed on this CRL as unknown or locate another CRL that does not contain any unrecognized critical extensions.
発行している分配ポイントは特定のCRLのためにCRL分配ポイントと範囲を特定する重要なCRL拡張子です、そして、CRLが終わりの実体証明書だけのための取消しをカバーするかどうかを示します、カリフォルニア証明書だけ、属性証明書だけ、または限られたセットの理由コード。 拡大は重要ですが、従う実装は、この拡大をサポートするのに必要ではありません。 しかしながら、この拡大をサポートしない実装は、未知のこの同じくらいCRLにリストアップされなかったどんな証明書の状態も扱わなければならないか、または少しの認識されていない重要な拡大も含まない別のCRLの場所を見つけなければなりません。
The CRL is signed using the CRL issuer's private key. CRL distribution points do not have their own key pairs. If the CRL is stored in the X.500 directory, it is stored in the directory entry corresponding to the CRL distribution point, which may be different from the directory entry of the CRL issuer.
CRL発行人の秘密鍵を使用することでCRLは署名されます。 CRL分配ポイントには、それら自身の主要な組がありません。 CRLがX.500ディレクトリに保存されるなら、それはCRL発行人に関するディレクトリエントリと異なるかもしれないCRL分配ポイントに対応するディレクトリエントリに保存されます。
The reason codes associated with a distribution point MUST be specified in onlySomeReasons. If onlySomeReasons does not appear, the distribution point MUST contain revocations for all reason codes. CAs may use CRL distribution points to partition the CRL on the basis of compromise and routine revocation. In this case, the revocations with reason code keyCompromise (1), cACompromise (2), and aACompromise (8) appear in one distribution point, and the revocations with other reason codes appear in another distribution point.
onlySomeReasonsで分配ポイントに関連している理由コードを指定しなければなりません。 onlySomeReasonsが現れないなら、分配ポイントはすべての理由コードのための取消しを含まなければなりません。 CAsは、感染と通常の取消しに基づいてCRLを仕切るのにCRL分配ポイントを使用するかもしれません。 この場合、理由コードkeyCompromise(1)、cACompromise(2)、およびaACompromise(8)との取消しはコードがもう1分配ポイントに現れる他の理由と共に1分配ポイント、および取消しに現れます。
If a CRL includes an issuingDistributionPoint extension with onlySomeReasons present, then every certificate in the scope of the CRL that is revoked MUST be assigned a revocation reason other than unspecified. The assigned revocation reason is used to determine on which CRL(s) to list the revoked certificate, however, there is no requirement to include the reasonCode CRL entry extension in the corresponding CRL entry.
CRLがonlySomeReasonsが存在しているissuingDistributionPoint拡張子を含んでいるなら、取り消されるCRLの範囲のあらゆる証明書に不特定であるのを除いた取消し理由を割り当てなければなりません。 割り当てられた取消し理由はどのCRL(s)で取り消された証明書をリストアップすることを決定するかに使用されて、しかしながら、reasonCode CRLエントリー拡張子を含んでいるという要件が全く対応するCRLエントリーにありません。
The syntax and semantics for the distributionPoint field are the same as for the distributionPoint field in the cRLDistributionPoints extension (Section 4.2.1.13). If the distributionPoint field is present, then it MUST include at least one of names from the corresponding distributionPoint field of the cRLDistributionPoints
distributionPoint分野への構文と意味論がdistributionPoint分野のようにcRLDistributionPoints拡張子で同じである、(セクション4.2 .1 .13)。 distributionPoint分野が存在しているなら、それは少なくともcRLDistributionPointsの対応するdistributionPoint分野からの名前の1つを含まなければなりません。
Cooper, et al. Standards Track [Page 65] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[65ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
extension of every certificate that is within the scope of this CRL. The identical encoding MUST be used in the distributionPoint fields of the certificate and the CRL.
このCRLの範囲の中にあるあらゆる証明書の拡大。 証明書とCRLのdistributionPoint分野で同じコード化を使用しなければなりません。
If the distributionPoint field is absent, the CRL MUST contain entries for all revoked unexpired certificates issued by the CRL issuer, if any, within the scope of the CRL.
distributionPoint分野が欠けるなら、CRL MUSTはCRL発行人によって発行されたすべての取り消された満期になっていない証明書のためのエントリーを含んでいます、もしあれば、CRLの範囲の中で。
If the scope of the CRL only includes certificates issued by the CRL issuer, then the indirectCRL boolean MUST be set to FALSE. Otherwise, if the scope of the CRL includes certificates issued by one or more authorities other than the CRL issuer, the indirectCRL boolean MUST be set to TRUE. The authority responsible for each entry is indicated by the certificate issuer CRL entry extension (Section 5.3.3).
CRLの範囲がCRL発行人によって発行された証明書を含んでいるだけであるなら、indirectCRL論理演算子をFALSEに設定しなければなりません。 さもなければ、CRLの範囲がCRL発行人以外の1つ以上の当局によって発行された証明書を含んでいるなら、indirectCRL論理演算子をTRUEに設定しなければなりません。 証明書発行人CRLエントリー拡張子(セクション5.3.3)で各エントリーに原因となる権威は示されます。
If the scope of the CRL only includes end entity public key certificates, then onlyContainsUserCerts MUST be set to TRUE. If the scope of the CRL only includes CA certificates, then onlyContainsCACerts MUST be set to TRUE. If either onlyContainsUserCerts or onlyContainsCACerts is set to TRUE, then the scope of the CRL MUST NOT include any version 1 or version 2 certificates. Conforming CRLs issuers MUST set the onlyContainsAttributeCerts boolean to FALSE.
CRLの範囲が終わりの実体公開鍵証明書を含んでいるだけであるなら、onlyContainsUserCertsはTRUEに用意ができなければなりません。 CRLの範囲がカリフォルニア証明書を含んでいるだけであるなら、onlyContainsCACertsはTRUEに用意ができなければなりません。 onlyContainsUserCertsかonlyContainsCACertsのどちらかがTRUEに用意ができているなら、CRL MUST NOTの範囲はどんなバージョン1かバージョン2証明書も含んでいます。 CRLs発行人を従わせると、onlyContainsAttributeCerts論理演算子はFALSEに設定されなければなりません。
Conforming CRLs issuers MUST NOT issue CRLs where the DER encoding of the issuing distribution point extension is an empty sequence. That is, if onlyContainsUserCerts, onlyContainsCACerts, indirectCRL, and onlyContainsAttributeCerts are all FALSE, then either the distributionPoint field or the onlySomeReasons field MUST be present.
CRLs発行人が発行分配をコード化するDERが拡大を指すCRLsを発行してはいけない従うのは空の系列です。 すなわち、onlyContainsUserCerts、onlyContainsCACerts、indirectCRL、およびonlyContainsAttributeCertsがすべてFALSEであるなら、distributionPoint分野かonlySomeReasons分野のどちらかが存在していなければなりません。
id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
イドCe issuingDistributionPoint、オブジェクト識別子:、:= イドCe28
IssuingDistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
onlySomeReasons [3] ReasonFlags OPTIONAL,
indirectCRL [4] BOOLEAN DEFAULT FALSE,
onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
IssuingDistributionPoint:、:= 系列distributionPoint[0]DistributionPointName任意です、誤ったonlyContainsUserCertsのデフォルト誤って、[2]のブールデフォルト誤って、onlySomeReasons[3]ReasonFlags任意のonlyContainsCACerts indirectCRL[4]ブールのデフォルトonlyContainsAttributeCerts[5][1]論理演算子論理演算子は虚偽でデフォルトとします。
-- at most one of onlyContainsUserCerts, onlyContainsCACerts,
-- and onlyContainsAttributeCerts may be set to TRUE.
-- 高々、onlyContainsUserCerts、onlyContainsCACerts、およびonlyContainsAttributeCertsの1つはTRUEに設定されるかもしれません。
Cooper, et al. Standards Track [Page 66] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[66ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
5.2.6. Freshest CRL (a.k.a. Delta CRL Distribution Point)
5.2.6. 最も新鮮なCRL(通称デルタCRL分配ポイント)
The freshest CRL extension identifies how delta CRL information for this complete CRL is obtained. Conforming CRL issuers MUST mark this extension as non-critical. This extension MUST NOT appear in delta CRLs.
最も新鮮なCRL拡張子はどうこの完全なCRLのためのデルタCRL情報を得るかを特定します。 CRL発行人を従わせると、この拡大は非臨界であるとしてマークされなければなりません。 この拡大はデルタCRLsに現れてはいけません。
The same syntax is used for this extension as the cRLDistributionPoints certificate extension, and is described in Section 4.2.1.13. However, only the distribution point field is meaningful in this context. The reasons and cRLIssuer fields MUST be omitted from this CRL extension.
同じ構文は、cRLDistributionPointsが拡大を証明するときこの拡大に使用されて、セクション4.2.1で.13に説明されます。 しかしながら、分配ポイント分野だけがこのような関係においては重要です。 このCRL拡張子から理由とcRLIssuer分野を省略しなければなりません。
Each distribution point name provides the location at which a delta CRL for this complete CRL can be found. The scope of these delta CRLs MUST be the same as the scope of this complete CRL. The contents of this CRL extension are only used to locate delta CRLs; the contents are not used to validate the CRL or the referenced delta CRLs. The encoding conventions defined for distribution points in Section 4.2.1.13 apply to this extension.
それぞれの分配ポイント名はこの完全なCRLのためのCRLデルタを見つけることができる位置を提供します。 これらのCRLsデルタの範囲はこの完全なCRLの範囲と同じであるに違いありません。 このCRL拡張子の内容はデルタCRLsの場所を見つけるのに使用されるだけです。 内容は、CRLかCRLsの参照をつけられたデルタを有効にするのに使用されません。 コンベンションが分配のために定義したコード化は.13がこの拡大に適用するセクション4.2.1で指します。
id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
イドCe freshestCRL、オブジェクト識別子:、:= イドCe46
FreshestCRL ::= CRLDistributionPoints
FreshestCRL:、:= CRLDistributionPoints
5.2.7. Authority Information Access
5.2.7. 権威情報アクセス
This section defines the use of the Authority Information Access extension in a CRL. The syntax and semantics defined in Section 4.2.2.1 for the certificate extension are also used for the CRL extension.
このセクションはCRLにおけるAuthority情報Access拡張子の使用を定義します。 また、証明書拡張子がCRL拡張子に使用されるので、構文と意味論はセクション4.2.2で.1を定義しました。
This CRL extension MUST be marked as non-critical.
非臨界であるとしてこのCRL拡張子をマークしなければなりません。
When present in a CRL, this extension MUST include at least one AccessDescription specifying id-ad-caIssuers as the accessMethod. The id-ad-caIssuers OID is used when the information available lists certificates that can be used to verify the signature on the CRL (i.e., certificates that have a subject name that matches the issuer name on the CRL and that have a subject public key that corresponds to the private key used to sign the CRL). Access method types other than id-ad-caIssuers MUST NOT be included. At least one instance of AccessDescription SHOULD specify an accessLocation that is an HTTP [RFC2616] or LDAP [RFC4516] URI.
CRLに存在していて、この拡大が少なくとも1AccessDescriptionの指定を含まなければならない、イド広告caIssuers、accessMethodとして。 イド広告caIssuers OID、情報の利用可能なリスト証明書であるときに、使用されて、CRLで署名について確かめるのにそれを使用できます(すなわち、CRLに発行人名に合っている対象の名前を持っていて、秘密鍵に対応する対象の公開鍵を持っている証明書が以前はよくCRLに署名していました)。 アクセス法がタイプする、イド広告caIssuers、含まれてはいけません。 AccessDescription SHOULDの少なくとも1つのインスタンスがHTTP[RFC2616]かLDAP[RFC4516]URIであるaccessLocationを指定します。
Cooper, et al. Standards Track [Page 67] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[67ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
Where the information is available via HTTP or FTP, accessLocation MUST be a uniformResourceIdentifier and the URI MUST point to either a single DER encoded certificate as specified in [RFC2585] or a collection of certificates in a BER or DER encoded "certs-only" CMS message as specified in [RFC2797].
情報がHTTPかFTPで利用可能であるところでは、accessLocationはuniformResourceIdentifierであるに違いありません、そして、URIが[RFC2585]の指定されるとしてのコード化された証明書かBERでの証明書の収集を独身のDERに向けなければならない、さもなければ、DERは[RFC2797]の指定されるとしての「本命唯一」のCMSメッセージをコード化しました。
Conforming applications that support HTTP or FTP for accessing certificates MUST be able to accept individual DER encoded certificates and SHOULD be able to accept "certs-only" CMS messages.
個人DERのためにコード化された証明書とSHOULDを受け入れることができる状態で証明書にアクセスするためのサポートHTTPかFTPがあるに違いない利用を従わせて、「本命専用」CMSメッセージを受け入れることができてください。
HTTP server implementations accessed via the URI SHOULD specify the media type application/pkix-cert [RFC2585] in the content-type header field of the response for a single DER encoded certificate and SHOULD specify the media type application/pkcs7-mime [RFC2797] in the content-type header field of the response for "certs-only" CMS messages. For FTP, the name of a file that contains a single DER encoded certificate SHOULD have a suffix of ".cer" [RFC2585] and the name of a file that contains a "certs-only" CMS message SHOULD have a suffix of ".p7c" [RFC2797]. Consuming clients may use the media type or file extension as a hint to the content, but should not depend solely on the presence of the correct media type or file extension in the server response.
独身のDERが証明書をコード化して、SHOULDが「本命専用」CMSメッセージのための応答のcontent typeヘッダーフィールドでメディアタイプpkcs7アプリケーション/パントマイム[RFC2797]を指定するので、URI SHOULDを通してアクセスされたHTTPサーバ実装は応答のcontent typeヘッダーフィールドでメディアタイプpkixアプリケーション/本命[RFC2585]を指定します。 FTP、DERがコード化したシングルを含むファイルの名前のために、証明書SHOULDには、SHOULDに".p7c"[RFC2797]の接尾語があるという「本命専用」CMSメッセージを含む".cer"[RFC2585]の接尾語とファイルの名前があります。 クライアントを消費するのは、ヒントとしてメディアタイプかファイル拡張子を内容に使用するかもしれませんが、唯一サーバ応答における、正しいメディアタイプかファイル拡張子の存在によるべきではありません。
When the accessLocation is a directoryName, the information is to be obtained by the application from whatever directory server is locally configured. When one CA public key is used to validate signatures on certificates and CRLs, the desired CA certificate is stored in the crossCertificatePair and/or cACertificate attributes as specified in [RFC4523]. When different public keys are used to validate signatures on certificates and CRLs, the desired certificate is stored in the userCertificate attribute as specified in [RFC4523]. Thus, implementations that support the directoryName form of accessLocation MUST be prepared to find the needed certificate in any of these three attributes. The protocol that an application uses to access the directory (e.g., DAP or LDAP) is a local matter.
accessLocationがdirectoryNameであるときに、情報は局所的に構成されるどんなディレクトリサーバからのアプリケーションでも得ることです。 1つのカリフォルニア公開鍵が証明書とCRLsで署名を有効にするのに使用されるとき、必要なカリフォルニア証明書は[RFC4523]の指定されるとしてのcrossCertificatePair、そして/または、cACertificate属性で保存されます。 異なった公開鍵が証明書とCRLsで署名を有効にするのに使用されるとき、必要な証明書は[RFC4523]の指定されるとしてのuserCertificate属性で保存されます。 したがって、これらの3つの属性のどれかで必要な証明書を見つけるようにaccessLocationのdirectoryNameフォームをサポートする実装を準備しなければなりません。 アプリケーションがディレクトリ(例えば、DAPかLDAP)にアクセスするのに使用するプロトコルは地域にかかわる事柄です。
Where the information is available via LDAP, the accessLocation SHOULD be a uniformResourceIdentifier. The LDAP URI [RFC4516] MUST include a <dn> field containing the distinguished name of the entry holding the certificates, MUST include an <attributes> field that lists appropriate attribute descriptions for the attributes that hold the DER encoded certificates or cross-certificate pairs [RFC4523], and SHOULD include a <host> (e.g., <ldap://ldap.example.com/cn=CA, dc=example,dc=com?cACertificate;binary,crossCertificatePair;binary>). Omitting the <host> (e.g., <ldap:///cn=exampleCA,dc=example,dc=com? cACertificate;binary>) has the effect of relying on whatever a priori knowledge the client might have to contact an appropriate server.
情報がLDAP、accessLocation SHOULDを通して入手できるところでは、uniformResourceIdentifierがそうですか? LDAP URI[RFC4516]は証明書を保持するエントリーの分類名を含む<dn>分野を含まなければならなくて、DERコード化された証明書か交差している証明書組[RFC4523]を保持する属性のための適切な属性記述を記載する<属性>分野を含まなければなりません、そして、SHOULDは<ホスト>を含んでいます(例えば、<ldap://ldap.example.com/cn=カリフォルニア、dcはdc=com?例、cACertificate; バイナリー、crossCertificatePair; 2進の>と等しいです)。 <ホスト>(例えば、<ldap:///cn=exampleCA、dcは例、dc=com--cACertificate; 2進の>と等しい)を省略するのにおいて、クライアントが適切なサーバに連絡するために持っているどんな先験的な知識も当てにするという効果があります。
Cooper, et al. Standards Track [Page 68] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[68ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
5.3. CRL Entry Extensions
5.3. CRLエントリー拡張子
The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9 for X.509 v2 CRLs provide methods for associating additional attributes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also allows communities to define private CRL entry extensions to carry information unique to those communities. Each extension in a CRL entry may be designated as critical or non-critical. If a CRL contains a critical CRL entry extension that the application cannot process, then the application MUST NOT use that CRL to determine the status of any certificates. However, applications may ignore unrecognized non-critical CRL entry extensions.
X.509 v2 CRLsのためにISO/IEC、ITU-T、およびANSI X9によって定義されたCRLエントリー拡張子はCRLエントリー[X.509][X9.55]を追加属性を関連づけるためのメソッドに提供します。 また、X.509 v2 CRL形式で、共同体は、それらの共同体にユニークな情報を運ぶために個人的なCRLエントリー拡張子を定義できます。 CRLエントリーにおける各拡大は重要であるか非臨界であるとして指定されるかもしれません。 CRLがアプリケーションが処理できない重要なCRLエントリー拡張子を含んでいるなら、アプリケーションは、どんな証明書の状態も決定するのにそのCRLを使用してはいけません。 しかしながら、アプリケーションは認識されていない非臨界CRLエントリー拡張子を無視するかもしれません。
The following subsections present recommended extensions used within Internet CRL entries and standard locations for information. Communities may elect to use additional CRL entry extensions; however, caution should be exercised in adopting any critical CRL entry extensions in CRLs that might be used in a general context.
以下の小区分プレゼントは情報にインターネットCRLエントリーと標準の位置の中で使用された拡張子を推薦しました。 共同体は、追加CRLエントリー拡張子を使用するのを選ぶかもしれません。 しかしながら、警告は一般情勢で使用されるかもしれないCRLsのどんな重要なCRLエントリー拡張子も採用するのに訓練されるべきです。
Support for the CRL entry extensions defined in this specification is optional for conforming CRL issuers and applications. However, CRL issuers SHOULD include reason codes (Section 5.3.1) and invalidity dates (Section 5.3.2) whenever this information is available.
CRL発行人とアプリケーションを従わせるのに、この仕様に基づき定義されたCRLエントリー拡張子のサポートは任意です。 しかしながら、この情報が利用可能であるときはいつも、CRL発行人SHOULDは理由コード(セクション5.3.1)と無効日付(セクション5.3.2)を含んでいます。
5.3.1. Reason Code
5.3.1. 理由コード
The reasonCode is a non-critical CRL entry extension that identifies the reason for the certificate revocation. CRL issuers are strongly encouraged to include meaningful reason codes in CRL entries; however, the reason code CRL entry extension SHOULD be absent instead of using the unspecified (0) reasonCode value.
reasonCodeは証明書取消しの理由を特定する非臨界CRLエントリー拡張子です。 CRL発行人がCRLエントリーに重要な理由コードを含んでいるよう強く奨励されます。 しかしながら、理由はCRLエントリー拡張子SHOULDをコード化します。不特定の(0)reasonCode価値を使用することの代わりに、休んでください。
The removeFromCRL (8) reasonCode value may only appear in delta CRLs and indicates that a certificate is to be removed from a CRL because either the certificate expired or was removed from hold. All other reason codes may appear in any CRL and indicate that the specified certificate should be considered revoked.
証明書が期限が切れたか、または保持から取り外されたので、removeFromCRL(8)reasonCode値は、デルタCRLsで見えるだけであるかもしれなく、証明書がCRLから取り除かれることであることを示します。 コードが、どんなCRLでも見えて、指定された証明書が考えられるべきであるのを示すかもしれない他のすべての理由が取り消されました。
Cooper, et al. Standards Track [Page 69] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[69ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }
イドCe cRLReasons、オブジェクト識別子:、:= イドCe21
-- reasonCode ::= { CRLReason }
-- reasonCode:、:= CRLReason
CRLReason ::= ENUMERATED {
unspecified (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
-- value 7 is not used
removeFromCRL (8),
privilegeWithdrawn (9),
aACompromise (10) }
CRLReason:、:= 列挙されます。不特定の(0)、keyCompromise(1)、cACompromise(2)(affiliationChanged(3))は(4)に取って代わりました、cessationOfOperation(5)、certificateHold(6)--値7は中古のremoveFromCRL(8)ではありません、privilegeWithdrawn(9)、aACompromise(10)
5.3.2. Invalidity Date
5.3.2. 無効日付
The invalidity date is a non-critical CRL entry extension that provides the date on which it is known or suspected that the private key was compromised or that the certificate otherwise became invalid. This date may be earlier than the revocation date in the CRL entry, which is the date at which the CA processed the revocation. When a revocation is first posted by a CRL issuer in a CRL, the invalidity date may precede the date of issue of earlier CRLs, but the revocation date SHOULD NOT precede the date of issue of earlier CRLs. Whenever this information is available, CRL issuers are strongly encouraged to share it with CRL users.
無効日付は秘密鍵が感染されたか、またはそうでなければ、証明書が無効になったと知られているか、または疑われる日付を提供する非臨界CRLエントリー拡張子です。 この日付は取消し日付より早くCRLエントリーにあるかもしれません。(それは、カリフォルニアが取消しを処理した日付です)。 取消しが最初にCRLにCRL発行人によって掲示されるとき、無効日付は以前のCRLsの発行日に先行するかもしれませんが、取消し日付SHOULD NOTは以前のCRLsの発行日に先行します。 この情報が利用可能であるときはいつも、CRL発行人がCRLユーザとそれを共有するよう強く奨励されます。
The GeneralizedTime values included in this field MUST be expressed in Greenwich Mean Time (Zulu), and MUST be specified and interpreted as defined in Section 4.1.2.5.2.
この分野に値を含んでいるのをグリニッジ標準時(ズールー族)に言い表されて、指定していなければならなくて、解釈しなければならないGeneralizedTimeはセクション4.1.2で.2に.5を定義しました。
id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
イドCe invalidityDate、オブジェクト識別子:、:= イドCe24
InvalidityDate ::= GeneralizedTime
InvalidityDate:、:= GeneralizedTime
5.3.3. Certificate Issuer
5.3.3. 証明書発行人
This CRL entry extension identifies the certificate issuer associated with an entry in an indirect CRL, that is, a CRL that has the indirectCRL indicator set in its issuing distribution point extension. When present, the certificate issuer CRL entry extension includes one or more names from the issuer field and/or issuer alternative name extension of the certificate that corresponds to the CRL entry. If this extension is not present on the first entry in an indirect CRL, the certificate issuer defaults to the CRL issuer. On
このCRLエントリー拡張子は間接的なCRLのエントリーに関連している証明書発行人を特定します、すなわち、それが分配ポイント拡大を発行する際にindirectCRLインディケータを設定させるCRL。 存在しているとき、証明書発行人CRLエントリー拡張子は拡大というCRLエントリーに一致している証明書の発行人分野、そして/または、発行人代替名からの1つ以上の名前を含んでいます。 この拡大が間接的なCRLの初記入のときに存在していないなら、証明書発行人はCRL発行人をデフォルトとします。 オン
Cooper, et al. Standards Track [Page 70] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[70ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
subsequent entries in an indirect CRL, if this extension is not present, the certificate issuer for the entry is the same as that for the preceding entry. This field is defined as follows:
間接的なCRLのその後のエントリー、この拡大が存在していないなら、エントリーへの証明書発行人は前のエントリーへのそれと同じです。 この分野は以下の通り定義されます:
id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
イドCe certificateIssuer、オブジェクト識別子:、:= イドCe29
CertificateIssuer ::= GeneralNames
CertificateIssuer:、:= GeneralNames
Conforming CRL issuers MUST include in this extension the distinguished name (DN) from the issuer field of the certificate that corresponds to this CRL entry. The encoding of the DN MUST be identical to the encoding used in the certificate.
CRL発行人を従わせると、このCRLエントリーに一致している証明書の発行人分野からの分類名(DN)はこの拡大で包含しなければなりません。 DN MUSTがコード化されて、証明書で使用されるコード化と同じにしてください。
CRL issuers MUST mark this extension as critical since an implementation that ignored this extension could not correctly attribute CRL entries to certificates. This specification RECOMMENDS that implementations recognize this extension.
この拡大を無視した実装が正しくCRLエントリーを証明書の結果と考えることができなかったので、CRL発行人は重要であるとしてこの拡大をマークしなければなりません。 この仕様RECOMMENDS、実装はこの拡大を認識します。
6. Certification Path Validation
6. 証明経路合法化
Certification path validation procedures for the Internet PKI are based on the algorithm supplied in [X.509]. Certification path processing verifies the binding between the subject distinguished name and/or subject alternative name and subject public key. The binding is limited by constraints that are specified in the certificates that comprise the path and inputs that are specified by the relying party. The basic constraints and policy constraints extensions allow the certification path processing logic to automate the decision making process.
インターネットPKIへの証明経路合法化手順は[X.509]で供給されたアルゴリズムに基づいています。 証明経路処理は対象の分類名、そして/または、対象の代替名と対象の公開鍵の間の結合について確かめます。 結合は経路を包括する証明書で指定される規制と信用パーティーによって指定される入力で制限されます。 基本的な規制と方針規制拡大で、証明経路処理論理は意志決定プロセスを自動化できます。
This section describes an algorithm for validating certification paths. Conforming implementations of this specification are not required to implement this algorithm, but MUST provide functionality equivalent to the external behavior resulting from this procedure. Any algorithm may be used by a particular implementation so long as it derives the correct result.
このセクションは証明経路を有効にするためのアルゴリズムを説明します。 この仕様の従う実装は、このアルゴリズムを実装するのが必要ではありませんが、この手順から生じる外部の振舞いに同等な機能性を提供しなければなりません。 正しい結果を引き出す限り、どんなアルゴリズムも特定の実装によって使用されるかもしれません。
In Section 6.1, the text describes basic path validation. Valid paths begin with certificates issued by a trust anchor. The algorithm requires the public key of the CA, the CA's name, and any constraints upon the set of paths that may be validated using this key.
セクション6.1では、テキストは基本的な経路合法化について説明します。 証明書が信頼アンカーによって発行されている状態で、有効な経路は始まります。 アルゴリズムはこのキーを使用することで有効にされるかもしれない経路のセットでのカリフォルニアの公開鍵、CAの名前、および規制を必要とします。
The selection of a trust anchor is a matter of policy: it could be the top CA in a hierarchical PKI, the CA that issued the verifier's own certificate(s), or any other CA in a network PKI. The path
信頼アンカーの選択は方針の問題です: ネットワークPKIで検証の自身の証明書、またはいかなる他のカリフォルニアも発行したのは、階層的なPKI、カリフォルニアの先頭のカリフォルニアであるかもしれません。 経路
Cooper, et al. Standards Track [Page 71] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[71ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
validation procedure is the same regardless of the choice of trust anchor. In addition, different applications may rely on different trust anchors, or may accept paths that begin with any of a set of trust anchors.
合法化手順は信頼アンカーの選択にかかわらず同じです。 さらに、異なったアプリケーションは、異なった信頼アンカーに頼るか、または1セットの信頼アンカーのいずれと共にも始まる経路を受け入れるかもしれません。
Section 6.2 describes methods for using the path validation algorithm in specific implementations.
セクション6.2は特定の実装に経路合法化アルゴリズムを使用するためのメソッドを説明します。
Section 6.3 describes the steps necessary to determine if a certificate is revoked when CRLs are the revocation mechanism used by the certificate issuer.
セクション6.3は、CRLsが証明書発行人によって使用された取消しメカニズムであるときに、証明書が取り消されるかどうか決定するために必要なステップについて説明します。
6.1. Basic Path Validation
6.1. 基本的な経路合法化
This text describes an algorithm for X.509 path processing. A conforming implementation MUST include an X.509 path processing procedure that is functionally equivalent to the external behavior of this algorithm. However, support for some of the certificate extensions processed in this algorithm are OPTIONAL for compliant implementations. Clients that do not support these extensions MAY omit the corresponding steps in the path validation algorithm.
本稿はX.509経路処理のためのアルゴリズムを説明します。 従う実装はこのアルゴリズムの外部の振舞いに機能上同等なX.509経路現像処理を含まなければなりません。 しかしながら、このアルゴリズムで処理されたいくつかの証明書拡張子のサポートは対応する実装のためのOPTIONALです。 これらの拡大をサポートしないクライアントは経路合法化アルゴリズムで対応するステップを省略するかもしれません。
For example, clients are not required to support the policy mappings extension. Clients that do not support this extension MAY omit the path validation steps where policy mappings are processed. Note that clients MUST reject the certificate if it contains an unsupported critical extension.
例えば、クライアントは、方針マッピングが拡大であるとサポートする必要はありません。 この拡大をサポートしないクライアントは方針マッピングが処理される経路合法化ステップを省略するかもしれません。 サポートされない重要な拡大を含むならクライアントが証明書を拒絶しなければならないことに注意してください。
While the certificate and CRL profiles specified in Sections 4 and 5 of this document specify values for certificate and CRL fields and extensions that are considered to be appropriate for the Internet PKI, the algorithm presented in this section is not limited to accepting certificates and CRLs that conform to these profiles. Therefore, the algorithm only includes checks to verify that the certification path is valid according to X.509 and does not include checks to verify that the certificates and CRLs conform to this profile. While the algorithm could be extended to include checks for conformance to the profiles in Sections 4 and 5, this profile RECOMMENDS against including such checks.
このドキュメントのセクション4と5で指定された証明書とCRLプロフィールがインターネットPKIに適切であると考えられる証明書、CRL分野、および拡大に値を指定している間、このセクションに提示されたアルゴリズムはこれらのプロフィールに従う証明書とCRLsを受け入れるのに制限されません。 したがって、アルゴリズムだけが、X.509によると、証明経路が有効であることを確かめるためにチェックを含んでいて、証明書とCRLsがこのプロフィールに従うことを確かめるためにチェックは含んでいません。 セクション4と5のプロフィールに順応のためのチェックを含めるためにアルゴリズムを広げることができましたが、そのようなものを含んでいることに対するこのプロフィールRECOMMENDSはチェックします。
The algorithm presented in this section validates the certificate with respect to the current date and time. A conforming implementation MAY also support validation with respect to some point in the past. Note that mechanisms are not available for validating a certificate with respect to a time outside the certificate validity period.
このセクションに提示されたアルゴリズムは現在の日時に関して証明書を有効にします。 また、従う実装は過去に何らかのポイントに関して合法化をサポートするかもしれません。 メカニズムが証明書有効期間に時間に関して証明書を有効にするのに利用可能でないことに注意してください。
Cooper, et al. Standards Track [Page 72] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[72ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
The trust anchor is an input to the algorithm. There is no requirement that the same trust anchor be used to validate all certification paths. Different trust anchors MAY be used to validate different paths, as discussed further in Section 6.2.
信頼アンカーはアルゴリズムへの入力です。 同じ信頼アンカーがすべての証明経路を有効にするのに使用されるという要件が全くありません。 異なった信頼アンカーはセクション6.2で、より詳しく議論するように異なった経路を有効にするのにおいて使用されているかもしれません。
The primary goal of path validation is to verify the binding between a subject distinguished name or a subject alternative name and subject public key, as represented in the target certificate, based on the public key of the trust anchor. In most cases, the target certificate will be an end entity certificate, but the target certificate may be a CA certificate as long as the subject public key is to be used for a purpose other than verifying the signature on a public key certificate. Verifying the binding between the name and subject public key requires obtaining a sequence of certificates that support that binding. The procedure performed to obtain this sequence of certificates is outside the scope of this specification.
経路合法化のプライマリ目標は対象の分類名か対象の代替名と対象の公開鍵の間の結合について確かめることです、目標証明書に表されるように、信頼アンカーの公開鍵に基づいて。 多くの場合、目標証明書は終わりの実体証明書になるでしょうが、公開鍵証明書の上に署名について確かめるのを除いた目的に使用される対象の公開鍵がことである限り、目標証明書はカリフォルニア証明書であるかもしれません。 名前と対象の公開鍵の間の結合について確かめると、その結合をサポートする証明書は系列を得るのが要求されます。 この仕様の範囲の外に証明書のこの系列を得るために実行された手順があります。
To meet this goal, the path validation process verifies, among other things, that a prospective certification path (a sequence of n certificates) satisfies the following conditions:
この目標を達成するために、経路合法化プロセスは、将来の証明経路(n証明書の系列)が以下の条件を満たすことを特に確かめます:
(a) for all x in {1, ..., n-1}, the subject of certificate x is
the issuer of certificate x+1;
(a) 1、…、n-1のすべてのxに関して、証明書xの対象は+1に証明書xの発行人です。
(b) certificate 1 is issued by the trust anchor;
(b) 証明書1は信頼アンカーによって発行されます。
(c) certificate n is the certificate to be validated (i.e., the
target certificate); and
(c) 証明書nは有効にされるべき証明書(すなわち、目標証明書)です。 そして
(d) for all x in {1, ..., n}, the certificate was valid at the
time in question.
(d) 1、…、nのすべてのxに関して、証明書は問題の時に有効でした。
A certificate MUST NOT appear more than once in a prospective certification path.
証明書は将来の証明経路で一度より多く見えてはいけません。
When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path. Information about trust anchors is provided as inputs to the certification path validation algorithm (Section 6.1.1).
自己署名入りの証書の形に信頼アンカーを提供するとき、将来の証明経路の一部としてこの自己署名入りの証書を含んでいません。 入力として証明経路合法化アルゴリズム(セクション6.1.1)に信頼アンカーに関する情報を提供します。
A particular certification path may not, however, be appropriate for all applications. Therefore, an application MAY augment this algorithm to further limit the set of valid paths. The path validation process also determines the set of certificate policies that are valid for this path, based on the certificate policies extension, policy mappings extension, policy constraints extension, and inhibit anyPolicy extension. To achieve this, the path
しかしながら、すべてのアプリケーションには、特定の証明経路は適切でないかもしれません。 したがって、アプリケーションは、さらに有効な経路のセットを制限するためにこのアルゴリズムを増大させるかもしれません。 また、経路合法化プロセスは証明書方針拡張子、方針マッピング拡張子、方針規制拡大に基づいてこの経路に有効であり、anyPolicy拡張子を禁止する証明書方針のセットを決定します。 これを達成するために経路
Cooper, et al. Standards Track [Page 73] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[73ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
validation algorithm constructs a valid policy tree. If the set of certificate policies that are valid for this path is not empty, then the result will be a valid policy tree of depth n, otherwise the result will be a null valid policy tree.
合法化アルゴリズムは有効な方針木を組み立てます。 この経路に、有効な証明書方針のセットが空でないなら結果が深さnの有効な方針木になる、さもなければ、結果はヌル有効な方針木になるでしょう。
A certificate is self-issued if the same DN appears in the subject and issuer fields (the two DNs are the same if they match according to the rules specified in Section 7.1). In general, the issuer and subject of the certificates that make up a path are different for each certificate. However, a CA may issue a certificate to itself to support key rollover or changes in certificate policies. These self-issued certificates are not counted when evaluating path length or name constraints.
同じDNが対象と発行人分野に現れるなら(セクション7.1で指定された規則に従って彼らが合っているなら、2DNsが同じです)、自己に証明書を発行します。 一般に、各証明書において、経路を作る証明書の発行人と対象は異なっています。 しかしながら、カリフォルニアは、証明書方針で主要なロールオーバーか変化をサポートするためにそれ自体に証明書を下付するかもしれません。 経路の長さか名前規制を評価するとき、これらの自己によって発行された証明書は数えられません。
This section presents the algorithm in four basic steps: (1) initialization, (2) basic certificate processing, (3) preparation for the next certificate, and (4) wrap-up. Steps (1) and (4) are performed exactly once. Step (2) is performed for all certificates in the path. Step (3) is performed for all certificates in the path except the final certificate. Figure 2 provides a high-level flowchart of this algorithm.
このセクションは以下の基本的な4ステップにおけるアルゴリズムを提示します: (1) 初期化、(2)の基本的な証明書処理、次の証明書、および(4)結論のための(3)準備。 ステップ(1)と(4)はまさに一度実行されます。 ステップ(2)は経路のすべての証明書のために実行されます。 ステップ(3)は確定品質証明書以外の経路のすべての証明書のために実行されます。 図2はこのアルゴリズムのハイレベルのフローチャートを提供します。
Cooper, et al. Standards Track [Page 74] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[74ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
+-------+
| START |
+-------+
|
V
+----------------+
| Initialization |
+----------------+
|
+<--------------------+
| |
V |
+----------------+ |
| Process Cert | |
+----------------+ |
| |
V |
+================+ |
| IF Last Cert | |
| in Path | |
+================+ |
| | |
THEN | | ELSE |
V V |
+----------------+ +----------------+ |
| Wrap up | | Prepare for | |
+----------------+ | Next Cert | |
| +----------------+ |
V | |
+-------+ +--------------+
| STOP |
+-------+
+-------+ | 始め| +-------+ | +に対して----------------+ | 初期設定| +----------------+ | + <。--------------------+ | | V| +----------------+ | | プロセス本命| | +----------------+ | | | V| +================+ | | 最後の本命です。| | | 経路で| | +================+ | | | | その時| | ほか| V V| +----------------+ +----------------+ | | 包装は上昇します。| | 用意をします。| | +----------------+ | 次の本命| | | +----------------+ | V| | +-------+ +--------------+ | 停止| +-------+
Figure 2. Certification Path Processing Flowchart
図2。 証明経路処理フローチャート
6.1.1. Inputs
6.1.1. 入力
This algorithm assumes that the following nine inputs are provided to the path processing logic:
このアルゴリズムは、以下の9つの入力が経路処理論理に提供されると仮定します:
(a) a prospective certification path of length n.
(a) 長さnの将来の証明経路。
(b) the current date/time.
(b)現在の日付/時間。
Cooper, et al. Standards Track [Page 75] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[75ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
(c) user-initial-policy-set: A set of certificate policy
identifiers naming the policies that are acceptable to the
certificate user. The user-initial-policy-set contains the
special value any-policy if the user is not concerned about
certificate policy.
(c) ユーザの初期の方針はセットしました: 証明書ユーザにとって、方針をそれと命名する1セットの証明書方針識別子は許容できます。 ユーザの初期の方針セットが含んでいる、特別な値、いくらか、-、方針、ユーザが証明書方針に関して心配していないなら。
(d) trust anchor information, describing a CA that serves as a
trust anchor for the certification path. The trust anchor
information includes:
(d) 証明経路のために信頼アンカーとして役立つカリフォルニアを記述して、アンカー情報を信じてください。 信頼アンカー情報は:
(1) the trusted issuer name,
(1) 信じられた発行人名
(2) the trusted public key algorithm,
(2) 信じられた公開鍵アルゴリズム
(3) the trusted public key, and
そして(3) 信じられた公開鍵。
(4) optionally, the trusted public key parameters associated
with the public key.
任意に、信じられた公開鍵パラメタが公開鍵に関連づけた(4)。
The trust anchor information may be provided to the path
processing procedure in the form of a self-signed certificate.
When the trust anchor information is provided in the form of a
certificate, the name in the subject field is used as the trusted
issuer name and the contents of the subjectPublicKeyInfo field is
used as the source of the trusted public key algorithm and the
trusted public key. The trust anchor information is trusted
because it was delivered to the path processing procedure by some
trustworthy out-of-band procedure. If the trusted public key
algorithm requires parameters, then the parameters are provided
along with the trusted public key.
自己署名入りの証書の形で信頼アンカー情報を経路現像処理に提供するかもしれません。 信頼アンカー情報を証明書の形に提供するとき、信じられた発行人名とsubjectPublicKeyInfo分野のコンテンツが信じられた公開鍵アルゴリズムと信じられた公開鍵の源として使用されるとき、対象の分野の名前は使用されています。 それが何らかの信頼できるバンドで出ている手順で経路現像処理に提供されたので、信頼アンカー情報は信じられます。 信じられた公開鍵アルゴリズムがパラメタを必要とするなら、信じられた公開鍵と共にパラメタを提供します。
(e) initial-policy-mapping-inhibit, which indicates if policy
mapping is allowed in the certification path.
(e) マッピングが禁止する初期の方針。(その方針は、方針マッピングが証明経路に許容されているかどうかを示します)。
(f) initial-explicit-policy, which indicates if the path must be
valid for at least one of the certificate policies in the
user-initial-policy-set.
(f) 初期の明白な方針。(その方針は少なくとも証明書方針の1つに、経路がユーザの初期の方針セットで有効であるに違いないかどうかを示します)。
(g) initial-any-policy-inhibit, which indicates whether the
anyPolicy OID should be processed if it is included in a
certificate.
(g) 方針が禁止するいずれにも頭文字をつけてください、そして、どれが、anyPolicy OIDがそれであるなら処理されるべきであるかどうかを示すか証明書に含まれています。
(h) initial-permitted-subtrees, which indicates for each name
type (e.g., X.500 distinguished names, email addresses, or IP
addresses) a set of subtrees within which all subject names
in every certificate in the certification path MUST fall.
The initial-permitted-subtrees input includes a set for each
name type. For each name type, the set may consist of a
(h) 受入れられた下位木に頭文字をつけてください、それぞれの名前タイプ(例えば、X.500分類名、Eメールアドレス、またはIPアドレス)のために、証明経路のあらゆる証明書のすべての対象の名前が下がらなければならない1セットの下位木を示すどれ。 初期の受入れられた下位木入力はそれぞれの名前タイプのためのセットを含んでいます。 それぞれの名前タイプのために、セットはaから成るかもしれません。
Cooper, et al. Standards Track [Page 76] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[76ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
single subtree that includes all names of that name type or
one or more subtrees that each specifies a subset of the
names of that name type, or the set may be empty. If the set
for a name type is empty, then the certification path will be
considered invalid if any certificate in the certification
path includes a name of that name type.
タイプか1つ以上の下位木をそれと命名するそれがすべての名前を含むただ一つの下位木がそれぞれその名前タイプの名前の部分集合を指定するか、またはセットは空であるかもしれません。 名前タイプのためのセットが空であるなら、証明経路のどれか証明書がその名前タイプの名前を含んでいると、証明経路は無効であると考えられるでしょう。
(i) initial-excluded-subtrees, which indicates for each name type
(e.g., X.500 distinguished names, email addresses, or IP
addresses) a set of subtrees within which no subject name in
any certificate in the certification path may fall. The
initial-excluded-subtrees input includes a set for each name
type. For each name type, the set may be empty or may
consist of one or more subtrees that each specifies a subset
of the names of that name type. If the set for a name type
is empty, then no names of that name type are excluded.
(i) 除かれた下位木に頭文字をつけてください、それぞれの名前タイプ(例えば、X.500分類名、Eメールアドレス、またはIPアドレス)のために、証明経路のどんな証明書でどんな対象の名前も下がらないかもしれない1セットの下位木を示すどれ。 初期の除かれた下位木入力はそれぞれの名前タイプのためのセットを含んでいます。 それぞれの名前タイプのために、セットは、空であるかもしれないか、またはそれぞれその名前タイプの名前の部分集合を指定する1つ以上の下位木から成るかもしれません。 名前タイプのためのセットが空であるなら、その名前タイプの名前は全く除かれません。
Conforming implementations are not required to support the setting of all of these inputs. For example, a conforming implementation may be designed to validate all certification paths using a value of FALSE for initial-any-policy-inhibit.
従う実装は、これらの入力のすべての設定をサポートするのに必要ではありません。 例えば、従う実装は、方針が禁止する初期のいずれにもFALSEの値を使用することですべての証明経路を有効にするように設計されるかもしれません。
6.1.2. Initialization
6.1.2. 初期設定
This initialization phase establishes eleven state variables based upon the nine inputs:
この初期設定段階は9つの入力に基づく11の州の変数を確立します:
(a) valid_policy_tree: A tree of certificate policies with their
optional qualifiers; each of the leaves of the tree
represents a valid policy at this stage in the certification
path validation. If valid policies exist at this stage in
the certification path validation, the depth of the tree is
equal to the number of certificates in the chain that have
been processed. If valid policies do not exist at this stage
in the certification path validation, the tree is set to
NULL. Once the tree is set to NULL, policy processing
ceases.
(a) 有効な_方針_木: 彼らの任意の資格を与える人がいる証明書方針の木。 それぞれの木の葉は現在のところ、証明経路合法化で有効な方針を表します。 有効な方針が現在のところ証明経路合法化で存在するなら、木の深さはチェーンにおける、処理された証明書の数と等しいです。 有効な方針が現在のところ証明経路合法化で存在しないなら、木はNULLに設定されます。 木がいったんNULLに設定されると、方針処理はやみます。
Each node in the valid_policy_tree includes three data
objects: the valid policy, a set of associated policy
qualifiers, and a set of one or more expected policy values.
If the node is at depth x, the components of the node have
the following semantics:
有効な_方針_木の各ノードは3個のデータ・オブジェクトを含んでいます: 1セットの有効な方針か、1セットの関連方針資格を与える人と、1かさらに予想された保険価額。 ノードが深さxにあるなら、ノードの成分には、以下の意味論があります:
(1) The valid_policy is a single policy OID representing a
valid policy for the path of length x.
(1) 有効な_方針は長さxの経路に有効な方針を表すただ一つの方針OIDです。
Cooper, et al. Standards Track [Page 77] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[77ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
(2) The qualifier_set is a set of policy qualifiers associated
with the valid policy in certificate x.
(2) 資格を与える人_セットは証明書xの有効な方針に関連している方針資格を与える人のセットです。
(3) The expected_policy_set contains one or more policy OIDs
that would satisfy this policy in the certificate x+1.
(3) 予想された_方針_セットは+1に証明書xのこの方針を満たす1つ以上の方針のOIDsを含んでいます。
The initial value of the valid_policy_tree is a single node with
valid_policy anyPolicy, an empty qualifier_set, and an
expected_policy_set with the single value anyPolicy. This node is
considered to be at depth zero.
有効な_方針_木の初期の値は_が独身の値のanyPolicyと共に設定した有効な_方針anyPolicy、空の資格を与える人_セット、および予想された_方針があるただ一つのノードです。 このノードが深さゼロにあると考えられます。
Figure 3 is a graphic representation of the initial state of the
valid_policy_tree. Additional figures will use this format to
describe changes in the valid_policy_tree during path processing.
図3は有効な_方針_木の初期状態のグラフィック表示です。 追加数字は、経路処理の間、有効な_方針_木における変化について説明するのにこの形式を使用するでしょう。
+----------------+
| anyPolicy | <---- valid_policy
+----------------+
| {} | <---- qualifier_set
+----------------+
| {anyPolicy} | <---- expected_policy_set
+----------------+
+----------------+ | anyPolicy| <、-、-、-- 有効な_方針+----------------+ | {} | <、-、-、-- 資格を与える人_セット+----------------+ | anyPolicy| <、-、-、-- 予想された_方針_セット+----------------+
Figure 3. Initial Value of the valid_policy_tree State Variable
図3。 有効な_方針_木の州Variableの初期のValue
(b) permitted_subtrees: a set of root names for each name type
(e.g., X.500 distinguished names, email addresses, or IP
addresses) defining a set of subtrees within which all
subject names in subsequent certificates in the certification
path MUST fall. This variable includes a set for each name
type, and the initial value is initial-permitted-subtrees.
(b) 受入れられた_下位木: 各名前のための1セットの根の名は、証明経路のその後の証明書のすべての対象の名前が下がらなければならない1セットの下位木を定義しながら、(例えば、X.500分類名、Eメールアドレス、またはIPアドレス)をタイプします。 この変数はそれぞれの名前タイプのためのセットを含んでいます、そして、初期の値は初期の受入れられた下位木です。
(c) excluded_subtrees: a set of root names for each name type
(e.g., X.500 distinguished names, email addresses, or IP
addresses) defining a set of subtrees within which no subject
name in subsequent certificates in the certification path may
fall. This variable includes a set for each name type, and
the initial value is initial-excluded-subtrees.
(c) 除かれた_下位木: 各名前のための1セットの根の名は、証明経路のその後の証明書でどんな対象の名前も下がらないかもしれない1セットの下位木を定義しながら、(例えば、X.500分類名、Eメールアドレス、またはIPアドレス)をタイプします。 この変数はそれぞれの名前タイプのためのセットを含んでいます、そして、初期の値は初期の除かれた下位木です。
(d) explicit_policy: an integer that indicates if a non-NULL
valid_policy_tree is required. The integer indicates the
number of non-self-issued certificates to be processed before
this requirement is imposed. Once set, this variable may be
decreased, but may not be increased. That is, if a
certificate in the path requires a non-NULL
valid_policy_tree, a later certificate cannot remove this
requirement. If initial-explicit-policy is set, then the
initial value is 0, otherwise the initial value is n+1.
(d) 明白な_方針: 非NULLの有効な_方針_木がそうであるかどうかを示す整数が必要です。 整数は、この要件が課される前に処理されるために発行された非自己証明書の数を示します。 いったん設定されると、この変数は、減少しますが、増強されないかもしれません。 すなわち、経路の証明書が非NULLの有効な_方針_木を必要とするなら、後の証明書はこの要件を取り除くことができません。 初期の明白な方針が設定されるなら初期の値が0である、さもなければ、初期の値はn+1です。
Cooper, et al. Standards Track [Page 78] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[78ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
(e) inhibit_anyPolicy: an integer that indicates whether the
anyPolicy policy identifier is considered a match. The
integer indicates the number of non-self-issued certificates
to be processed before the anyPolicy OID, if asserted in a
certificate other than an intermediate self-issued
certificate, is ignored. Once set, this variable may be
decreased, but may not be increased. That is, if a
certificate in the path inhibits processing of anyPolicy, a
later certificate cannot permit it. If initial-any-policy-
inhibit is set, then the initial value is 0, otherwise the
initial value is n+1.
(e) _anyPolicyを禁止してください: anyPolicy方針識別子がマッチであると考えられるかどうかを示す整数。 整数は、中間的自己によって発行された証明書以外の証明書で断言されるならanyPolicy OIDが無視される前に処理されるために発行された非自己証明書の数を示します。 いったん設定されると、この変数は、減少しますが、増強されないかもしれません。 すなわち、経路の証明書がanyPolicyの処理を抑制するなら、後の証明書はそれを可能にすることができません。 セットしてください。いずれにも頭文字をつけている方針、-、禁止、次に、初期の値が0である、さもなければ、初期の値はn+1です。
(f) policy_mapping: an integer that indicates if policy mapping
is permitted. The integer indicates the number of non-self-
issued certificates to be processed before policy mapping is
inhibited. Once set, this variable may be decreased, but may
not be increased. That is, if a certificate in the path
specifies that policy mapping is not permitted, it cannot be
overridden by a later certificate. If initial-policy-
mapping-inhibit is set, then the initial value is 0,
otherwise the initial value is n+1.
(f) 方針_マッピング: 方針マッピングが受入れられるかどうかを示す整数。 整数が数を示す、非、-自己に証明書を発行して、方針マッピングの前に処理されるのは抑制的です。 いったん設定されると、この変数は、減少しますが、増強されないかもしれません。 すなわち、経路の証明書が、方針マッピングが受入れられないと指定するなら、後の証明書はそれをくつがえすことができません。 セットしてください。初期の方針、-、マッピング禁止、次に、初期の値が0である、さもなければ、初期の値はn+1です。
(g) working_public_key_algorithm: the digital signature
algorithm used to verify the signature of a certificate. The
working_public_key_algorithm is initialized from the trusted
public key algorithm provided in the trust anchor
information.
(g) 働く_公共の_主要な_アルゴリズム: デジタル署名アルゴリズムは以前はよく証明書の署名について確かめていました。 働く_公共の_主要な_アルゴリズムは信頼アンカー情報に提供された信じられた公開鍵アルゴリズムから初期化されます。
(h) working_public_key: the public key used to verify the
signature of a certificate. The working_public_key is
initialized from the trusted public key provided in the trust
anchor information.
(h) 働く_公共の_キー: 公開鍵は以前はよく証明書の署名について確かめていました。 働く_公共の_キーは信頼アンカー情報に提供された信じられた公開鍵から初期化されます。
(i) working_public_key_parameters: parameters associated with
the current public key that may be required to verify a
signature (depending upon the algorithm). The
working_public_key_parameters variable is initialized from
the trusted public key parameters provided in the trust
anchor information.
(i) 働く_公共の_主要な_パラメタ: それが現在の公開鍵であるかもしれないのに関連しているパラメタが署名について確かめるのが必要です(アルゴリズムによって)。 働く_の公共の_主要な_パラメタ変数は信頼アンカー情報に提供された信じられた公開鍵パラメタから初期化されます。
(j) working_issuer_name: the issuer distinguished name expected
in the next certificate in the chain. The
working_issuer_name is initialized to the trusted issuer name
provided in the trust anchor information.
(j) 働く_発行人_名: 次の証明書でチェーンで予想された発行人分類名。 働く_発行人_名は信頼アンカー情報に提供された信じられた発行人名に初期化されます。
Cooper, et al. Standards Track [Page 79] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[79ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
(k) max_path_length: this integer is initialized to n, is
decremented for each non-self-issued certificate in the path,
and may be reduced to the value in the path length constraint
field within the basic constraints extension of a CA
certificate.
(k) _経路_長さに最大限にしてください: この整数は、nに初期化されて、それぞれの発行された非自己証明書のために経路で減少して、カリフォルニア証明書の基本的な規制拡大の中で経路長さの規制分野で値に減少するかもしれません。
Upon completion of the initialization steps, perform the basic certificate processing steps specified in 6.1.3.
初期化ステップの完成に、6.1で.3に指定された基本的な証明書処理ステップを実行してください。
6.1.3. Basic Certificate Processing
6.1.3. 基本的な証明書処理
The basic path processing actions to be performed for certificate i (for all i in [1..n]) are listed below.
証明書iのために実行されるべき基本的な経路処理動作は以下に記載されています([1..n]のすべてのiのために)。
(a) Verify the basic certificate information. The certificate
MUST satisfy each of the following:
(a) 基本の証明書情報について確かめてください。 証明書はそれぞれの以下を満たさなければなりません:
(1) The signature on the certificate can be verified using
working_public_key_algorithm, the working_public_key, and
the working_public_key_parameters.
(1) 働く_公共の_主要な_アルゴリズム、働く_公共の_キー、および働く_公共の_主要な_パラメタを使用することで証明書における署名について確かめることができます。
(2) The certificate validity period includes the current time.
(2) 証明書有効期間は現在の時間を含んでいます。
(3) At the current time, the certificate is not revoked. This
may be determined by obtaining the appropriate CRL
(Section 6.3), by status information, or by out-of-band
mechanisms.
(3) 現在の時間に、証明書は取り消されません。 これは適切なCRL(セクション6.3)を入手するか、状態情報、またはバンドの外による決定しているメカニズムであるかもしれません。
(4) The certificate issuer name is the working_issuer_name.
(4) 証明書発行人名は働く_発行人_名です。
(b) If certificate i is self-issued and it is not the final
certificate in the path, skip this step for certificate i.
Otherwise, verify that the subject name is within one of the
permitted_subtrees for X.500 distinguished names, and verify
that each of the alternative names in the subjectAltName
extension (critical or non-critical) is within one of the
permitted_subtrees for that name type.
(b) 自己に証明書iを発行して、それが経路の確定品質証明書でないなら、証明書iのためのこのステップをサボってください。 さもなければ、X.500分類名のための受入れられた_下位木の1つの中に対象の名前があることを確かめてください、そして、その名前タイプのための受入れられた_下位木の1つの中にsubjectAltName拡張子(重要であるか非臨界である)における、それぞれの代替名があることを確かめてください。
(c) If certificate i is self-issued and it is not the final
certificate in the path, skip this step for certificate i.
Otherwise, verify that the subject name is not within any of
the excluded_subtrees for X.500 distinguished names, and
verify that each of the alternative names in the
subjectAltName extension (critical or non-critical) is not
within any of the excluded_subtrees for that name type.
(c) 自己に証明書iを発行して、それが経路の確定品質証明書でないなら、証明書iのためのこのステップをサボってください。 さもなければ、X.500分類名のための除かれた_下位木のどれかの中に対象の名前がないことを確かめてください、そして、その名前タイプのための除かれた_下位木のどれかの中にsubjectAltName拡張子(重要であるか非臨界である)における、それぞれの代替名がないことを確かめてください。
Cooper, et al. Standards Track [Page 80] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[80ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
(d) If the certificate policies extension is present in the
certificate and the valid_policy_tree is not NULL, process
the policy information by performing the following steps in
order:
(d) 証明書方針拡張子が証明書に存在していて、有効な_方針_木がNULLでないなら、整然とした状態で以下のステップを実行することによって、方針情報を処理してください:
(1) For each policy P not equal to anyPolicy in the
certificate policies extension, let P-OID denote the OID
for policy P and P-Q denote the qualifier set for policy
P. Perform the following steps in order:
(1) 方針PとP-Qが資格を与える人を指示するので、Pで証明書方針拡張子においてanyPolicyと等しく、P-OIDが指示しない各方針のために、OIDは方針P.Performに整然とした状態で以下のステップを設定します:
(i) For each node of depth i-1 in the valid_policy_tree
where P-OID is in the expected_policy_set, create a
child node as follows: set the valid_policy to P-OID,
set the qualifier_set to P-Q, and set the
expected_policy_set to
{P-OID}.
(i) 有効な_方針_木の予想された_方針_セットにP-OIDがある深さi-1の各ノードに関して、以下の子供ノードを作成してください: 有効な_方針をP-OIDに設定してください、そして、資格を与える人_セットをP-Qに設定してください、そして、予想された_方針_セットをP-OIDに設定してください。
For example, consider a valid_policy_tree with a node
of depth i-1 where the expected_policy_set is {Gold,
White}. Assume the certificate policies Gold and
Silver appear in the certificate policies extension of
certificate i. The Gold policy is matched, but the
Silver policy is not. This rule will generate a child
node of depth i for the Gold policy. The result is
shown as Figure 4.
例えば、予想された_方針_がセットした深さi-1のノードがある有効な_方針_木が金、ホワイトであると考えてください。 証明書がGoldとシルヴァーが証明書iの証明書方針拡張子で見える方針であると仮定してください。 Gold方針は取り組んでいますが、シルヴァー方針は取り組むというわけではありません。 この規則はGold方針のために深さiの子供ノードを作るでしょう。 結果は図4として示されます。
+-----------------+
| Red |
+-----------------+
| {} |
+-----------------+ node of depth i-1
| {Gold, White} |
+-----------------+
|
|
|
V
+-----------------+
| Gold |
+-----------------+
| {} |
+-----------------+ node of depth i
| {Gold} |
+-----------------+
+-----------------+ | 赤| +-----------------+ | {} | +-----------------+ 深さi-1のノード| 金、ホワイト| +-----------------+ | | | +に対して-----------------+ | 金| +-----------------+ | {} | +-----------------+ 深さiのノード| 金| +-----------------+
Figure 4. Processing an Exact Match
図4。 完全な一致を処理します。
Cooper, et al. Standards Track [Page 81] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[81ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
(ii) If there was no match in step (i) and the
valid_policy_tree includes a node of depth i-1 with
the valid_policy anyPolicy, generate a child node with
the following values: set the valid_policy to P-OID,
set the qualifier_set to P-Q, and set the
expected_policy_set to {P-OID}.
(ii) マッチが全くステップ(i)になくて、有効な_方針_木が有効な_方針anyPolicyで深さi-1のノードを含んでいるなら、以下の値で子供ノードを作ってください: 有効な_方針をP-OIDに設定してください、そして、資格を与える人_セットをP-Qに設定してください、そして、予想された_方針_セットをP-OIDに設定してください。
For example, consider a valid_policy_tree with a node
of depth i-1 where the valid_policy is anyPolicy.
Assume the certificate policies Gold and Silver appear
in the certificate policies extension of certificate
i. The Gold policy does not have a qualifier, but the
Silver policy has the qualifier Q-Silver. If Gold and
Silver were not matched in (i) above, this rule will
generate two child nodes of depth i, one for each
policy. The result is shown as Figure 5.
例えば、有効な_方針がanyPolicyである深さi-1のノードで有効な_方針_木を考えてください。 証明書がGoldとシルヴァーが証明書iの証明書方針拡張子で見える方針であると仮定してください。 Gold方針には、資格を与える人がいませんが、シルヴァー方針に資格を与える人Q-Silverがあります。Goldとシルヴァーが上で(i)で合わせられなかったなら、この規則は深さiの2つの子供ノードを作るでしょう、各方針あたり1つ。 結果は図5として示されます。
+-----------------+
| anyPolicy |
+-----------------+
| {} |
+-----------------+ node of depth i-1
| {anyPolicy} |
+-----------------+
/ \
/ \
/ \
/ \
+-----------------+ +-----------------+
| Gold | | Silver |
+-----------------+ +-----------------+
| {} | | {Q-Silver} |
+-----------------+ nodes of +-----------------+
| {Gold} | depth i | {Silver} |
+-----------------+ +-----------------+
+-----------------+ | anyPolicy| +-----------------+ | {} | +-----------------+ 深さi-1のノード| anyPolicy| +-----------------+ / \ / \ / \ / \ +-----------------+ +-----------------+ | 金| | 銀| +-----------------+ +-----------------+ | {} | | Q-銀| +-----------------+ +のノード-----------------+ | 金| 深さi| 銀| +-----------------+ +-----------------+
Figure 5. Processing Unmatched Policies when a
Leaf Node Specifies anyPolicy
図5。 Leaf Node Specifies anyPolicyであることの処理Unmatched Policies
(2) If the certificate policies extension includes the policy
anyPolicy with the qualifier set AP-Q and either (a)
inhibit_anyPolicy is greater than 0 or (b) i<n and the
certificate is self-issued, then:
_(2) 証明書方針拡張子が資格を与える人セットAP-Qとどちらかの(a)とanyPolicyが禁止する方針を含んでいるなら、anyPolicyは0歳以上であるか(b) 自己にi<nと証明書を発行します、その時:
For each node in the valid_policy_tree of depth i-1, for
each value in the expected_policy_set (including
anyPolicy) that does not appear in a child node, create a
child node with the following values: set the valid_policy
深さi-1の有効な_方針_木の各ノード、子供ノードに現れない予想された_方針_セット(anyPolicyを含んでいる)における各値には、以下の値で子供ノードを作成してください: 有効な_方針を設定してください。
Cooper, et al. Standards Track [Page 82] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[82ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
to the value from the expected_policy_set in the parent
node, set the qualifier_set to AP-Q, and set the
expected_policy_set to the value in the valid_policy from
this node.
親ノードで用意ができている予想された_方針_からの値に、資格を与える人_セットをAP-Qに設定してください、そして、このノードから値に有効な_方針で予想された_方針_セットを設定してください。
For example, consider a valid_policy_tree with a node of
depth i-1 where the expected_policy_set is {Gold, Silver}.
Assume anyPolicy appears in the certificate policies
extension of certificate i with no policy qualifiers, but
Gold and Silver do not appear. This rule will generate
two child nodes of depth i, one for each policy. The
result is shown below as Figure 6.
例えば、予想された_方針_がセットした深さi-1のノードがある有効な_方針_木が金、シルヴァーであると考えてください。 anyPolicyが方針資格を与える人なしで証明書iの証明書方針拡張子に現れると仮定しなさい、ただし、Goldとシルヴァーは現れません。 この規則は深さiの2つの子供ノード、各方針あたり1つを発生させるでしょう。 結果は図6として以下に示されます。
+-----------------+
| Red |
+-----------------+
| {} |
+-----------------+ node of depth i-1
| {Gold, Silver} |
+-----------------+
/ \
/ \
/ \
/ \
+-----------------+ +-----------------+
| Gold | | Silver |
+-----------------+ +-----------------+
| {} | | {} |
+-----------------+ nodes of +-----------------+
| {Gold} | depth i | {Silver} |
+-----------------+ +-----------------+
+-----------------+ | 赤| +-----------------+ | {} | +-----------------+ 深さi-1のノード| 金、銀| +-----------------+ / \ / \ / \ / \ +-----------------+ +-----------------+ | 金| | 銀| +-----------------+ +-----------------+ | {} | | {} | +-----------------+ +のノード-----------------+ | 金| 深さi| 銀| +-----------------+ +-----------------+
Figure 6. Processing Unmatched Policies When the
Certificate Policies Extension Specifies anyPolicy
図6。 証明書方針拡張子がanyPolicyを指定するとき、優れた方針を処理します。
(3) If there is a node in the valid_policy_tree of depth i-1
or less without any child nodes, delete that node. Repeat
this step until there are no nodes of depth i-1 or less
without children.
(3) ノードが深さi-1か以下の有効な_方針_木に少しも子供ノードなしであれば、そのノードを削除してください。 深さi-1か以下のノードが全く子供なしでないまで、このステップを繰り返してください。
For example, consider the valid_policy_tree shown in
Figure 7 below. The two nodes at depth i-1 that are
marked with an 'X' have no children, and they are deleted.
Applying this rule to the resulting tree will cause the
node at depth i-2 that is marked with a 'Y' to be deleted.
In the resulting tree, there are no nodes of depth i-1 or
less without children, and this step is complete.
例えば、以下の図7で見せられた有効な_方針_木を考えてください。 深さi-1の'X'と共にマークされる2つのノードには、子供が全くいません、そして、彼らは削除されます。 この規則を結果として起こる木に適用するのに、'Y'と共にマークされる深さi-2のノードを削除するでしょう。 結果として起こる木には、深さi-1か以下のノードが全く子供なしでありません、そして、このステップは完全です。
Cooper, et al. Standards Track [Page 83] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[83ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
(e) If the certificate policies extension is not present, set the
valid_policy_tree to NULL.
(e) 証明書方針拡張子が存在していないなら、有効な_方針_木をNULLに設定してください。
(f) Verify that either explicit_policy is greater than 0 or the
valid_policy_tree is not equal to NULL;
(f) 明白な_方針が0以上であるか有効な_方針_木がNULLと等しくないことを確かめてください。
If any of steps (a), (b), (c), or (f) fails, the procedure terminates, returning a failure indication and an appropriate reason.
ステップ(a)、(b)、(c)、または(f)のどれかが失敗するなら、手順は終わります、失敗指示と適切な理由を返して。
If i is not equal to n, continue by performing the preparatory steps listed in Section 6.1.4. If i is equal to n, perform the wrap-up steps listed in Section 6.1.5.
iがnと等しくないなら、セクション6.1.4で記載された準備段階を実行することによって、続いてください。 iがnと等しいなら、セクション6.1.5で記載された結論ステップを実行してください。
+-----------+
| | node of depth i-3
+-----------+
/ | \
/ | \
/ | \
+-----------+ +-----------+ +-----------+
| | | | | Y | nodes of
+-----------+ +-----------+ +-----------+ depth i-2
/ \ | |
/ \ | |
/ \ | |
+-----------+ +-----------+ +-----------+ +-----------+ nodes of
| | | X | | | | X | depth
+-----------+ +-----------+ +-----------+ +-----------+ i-1
| / | \
| / | \
| / | \
+-----------+ +-----------+ +-----------+ +-----------+ nodes of
| | | | | | | | depth
+-----------+ +-----------+ +-----------+ +-----------+ i
+-----------+ | | 深さi-3+のノード-----------+ / | \ / | \ / | \ +-----------+ +-----------+ +-----------+ | | | | | Y| +のノード-----------+ +-----------+ +-----------+ 深さi-2/\| | / \ | | / \ | | +-----------+ +-----------+ +-----------+ +-----------+ ノード| | | X| | | | X| 深さ+-----------+ +-----------+ +-----------+ +-----------+ i-1| / | \ | / | \ | / | \ +-----------+ +-----------+ +-----------+ +-----------+ ノード| | | | | | | | 深さ+-----------+ +-----------+ +-----------+ +-----------+ i
Figure 7. Pruning the valid_policy_tree
図7。 有効な_方針_木を剪定します。
6.1.4. Preparation for Certificate i+1
6.1.4. Certificate i+1のための準備
To prepare for processing of certificate i+1, perform the
following steps for certificate i:
+1 証明書iの処理の用意をするには、証明書iのための以下のステップを実行してください:
(a) If a policy mappings extension is present, verify that the
special value anyPolicy does not appear as an
issuerDomainPolicy or a subjectDomainPolicy.
(a) 方針マッピング拡張子が存在しているなら、特別な値のanyPolicyがissuerDomainPolicyかsubjectDomainPolicyとして現れないことを確かめてください。
(b) If a policy mappings extension is present, then for each
issuerDomainPolicy ID-P in the policy mappings extension:
(b) 方針マッピング拡張子がそして、方針マッピング拡張子におけるそれぞれのissuerDomainPolicy ID-Pのために存在しているなら:
Cooper, et al. Standards Track [Page 84] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[84ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
(1) If the policy_mapping variable is greater than 0, for each
node in the valid_policy_tree of depth i where ID-P is the
valid_policy, set expected_policy_set to the set of
subjectDomainPolicy values that are specified as
equivalent to ID-P by the policy mappings extension.
(1) 方針_マッピング変数が0以上であるなら、ID-Pが有効な_方針である深さiの有効な_方針_木の各ノードに関して、セットは、_方針_が方針マッピング拡張子でID-Pに同じくらい同等な状態で指定されるsubjectDomainPolicy値のセットにセットしたと予想しました。
If no node of depth i in the valid_policy_tree has a
valid_policy of ID-P but there is a node of depth i with a
valid_policy of anyPolicy, then generate a child node of
the node of depth i-1 that has a valid_policy of anyPolicy
as follows:
有効な_方針_木の深さiのどんなノードにもID-Pの有効な_方針がありませんが、深さiのノードがanyPolicyの有効な_方針であれば、anyPolicyの有効な_方針を以下の通りにする深さi-1のノードの子供ノードを作ってください:
(i) set the valid_policy to ID-P;
(i) ID-Pに有効な_方針を設定してください。
(ii) set the qualifier_set to the qualifier set of the
policy anyPolicy in the certificate policies
extension of certificate i; and
(ii) 証明書iの証明書方針拡張子で方針anyPolicyの資格を与える人セットに資格を与える人_セットを設定してください。 そして
(iii) set the expected_policy_set to the set of
subjectDomainPolicy values that are specified as
equivalent to ID-P by the policy mappings extension.
(iii) 方針マッピング拡張子でID-Pに同じくらい同等な状態で指定されるsubjectDomainPolicy値のセットに予想された_方針_セットを設定してください。
(2) If the policy_mapping variable is equal to 0:
(2) 方針_マッピング変数が0と等しいなら:
(i) delete each node of depth i in the valid_policy_tree
where ID-P is the valid_policy.
(i) 有効な_方針_木のID-Pが有効な_方針である深さiの各ノードを削除してください。
(ii) If there is a node in the valid_policy_tree of depth
i-1 or less without any child nodes, delete that
node. Repeat this step until there are no nodes of
depth i-1 or less without children.
(ii) ノードが深さi-1か以下の有効な_方針_木に少しも子供ノードなしであれば、そのノードを削除してください。 深さi-1か以下のノードが全く子供なしでないまで、このステップを繰り返してください。
(c) Assign the certificate subject name to working_issuer_name.
(c) 働く_発行人_名に証明書対象名を割り当ててください。
(d) Assign the certificate subjectPublicKey to
working_public_key.
(d) 働く_公共の_キーに証明書subjectPublicKeyを割り当ててください。
(e) If the subjectPublicKeyInfo field of the certificate contains
an algorithm field with non-null parameters, assign the
parameters to the working_public_key_parameters variable.
(e) 証明書のsubjectPublicKeyInfo分野が非ヌルパラメタがあるアルゴリズム分野を含むなら、働く_の公共の_主要な_パラメタ変数にパラメタを割り当ててください。
If the subjectPublicKeyInfo field of the certificate contains
an algorithm field with null parameters or parameters are
omitted, compare the certificate subjectPublicKey algorithm
to the working_public_key_algorithm. If the certificate
subjectPublicKey algorithm and the
working_public_key_algorithm are different, set the
working_public_key_parameters to null.
証明書のsubjectPublicKeyInfo分野がヌルパラメタがあるアルゴリズム分野を含んでいるか、またはパラメタが省略されるなら、働く_公共の_主要な_アルゴリズムに証明書subjectPublicKeyアルゴリズムをたとえてください。 証明書subjectPublicKeyアルゴリズムと働く_公共の_主要な_アルゴリズムが異なるなら、働く_公共の_主要な_パラメタをヌルに設定してください。
Cooper, et al. Standards Track [Page 85] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[85ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
(f) Assign the certificate subjectPublicKey algorithm to the
working_public_key_algorithm variable.
(f) 働く_の公共の_主要な_アルゴリズム変数に証明書subjectPublicKeyアルゴリズムを割り当ててください。
(g) If a name constraints extension is included in the
certificate, modify the permitted_subtrees and
excluded_subtrees state variables as follows:
(g) 名前規制拡大が証明書に含まれているなら、受入れられた_下位木を変更してください。そうすれば、除かれた_下位木は以下の変数を述べます:
(1) If permittedSubtrees is present in the certificate, set
the permitted_subtrees state variable to the intersection
of its previous value and the value indicated in the
extension field. If permittedSubtrees does not include a
particular name type, the permitted_subtrees state
variable is unchanged for that name type. For example,
the intersection of example.com and foo.example.com is
foo.example.com. And the intersection of example.com and
example.net is the empty set.
(1) permittedSubtreesが証明書に存在しているなら、前の値と価値の交差点への州の変数が拡大分野で示した受入れられた_下位木を設定してください。 permittedSubtreesが特定の名前タイプを含んでいないなら、受入れられた_下位木は、その名前タイプに、変数が変わりがないと述べます。 例えば、example.comとfoo.example.comの交差点はfoo.example.comです。 そして、example.comとexample.netの交差点は空集合です。
(2) If excludedSubtrees is present in the certificate, set the
excluded_subtrees state variable to the union of its
previous value and the value indicated in the extension
field. If excludedSubtrees does not include a particular
name type, the excluded_subtrees state variable is
unchanged for that name type. For example, the union of
the name spaces example.com and foo.example.com is
example.com. And the union of example.com and example.net
is both name spaces.
(2) excludedSubtreesが証明書に存在しているなら、前の値と価値の組合への州の変数が拡大分野で示した除かれた_下位木を設定してください。 excludedSubtreesが特定の名前タイプを含んでいないなら、除かれた_下位木は、その名前タイプに、変数が変わりがないと述べます。 例えば、名前空間のexample.comとfoo.example.comの組合はexample.comです。 そして、example.comとexample.netの組合は両方の名前空間です。
(h) If certificate i is not self-issued:
(h) 証明書iが自己に発行されないなら:
(1) If explicit_policy is not 0, decrement explicit_policy by
1.
(1) 明白な_方針が0でないなら、明白な_方針を1つ減少させてください。
(2) If policy_mapping is not 0, decrement policy_mapping by 1.
(2) 方針_マッピングが0でないなら、方針_マッピングを1つ減少させてください。
(3) If inhibit_anyPolicy is not 0, decrement inhibit_anyPolicy
by 1.
_を禁止してください。(3)、anyPolicyが0歳でない、減少は1で_anyPolicyを禁止します。
(i) If a policy constraints extension is included in the
certificate, modify the explicit_policy and policy_mapping
state variables as follows:
(i) 方針規制拡大が証明書に含まれているなら、以下の明白な_方針と方針_マッピング州の変数を変更してください:
(1) If requireExplicitPolicy is present and is less than
explicit_policy, set explicit_policy to the value of
requireExplicitPolicy.
(1) requireExplicitPolicyが存在していて、明白な_方針以下であるなら、明白な_方針をrequireExplicitPolicyの値に設定してください。
(2) If inhibitPolicyMapping is present and is less than
policy_mapping, set policy_mapping to the value of
inhibitPolicyMapping.
(2) inhibitPolicyMappingが存在していて、方針_マッピング以下であるなら、方針_マッピングをinhibitPolicyMappingの値に設定してください。
Cooper, et al. Standards Track [Page 86] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[86ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
(j) If the inhibitAnyPolicy extension is included in the
certificate and is less than inhibit_anyPolicy, set
inhibit_anyPolicy to the value of inhibitAnyPolicy.
(j) inhibitAnyPolicy拡張子が証明書に含まれていて、_anyPolicyを禁止するより少ないなら、設定されて、_anyPolicyをinhibitAnyPolicyの値に禁止してください。
(k) If certificate i is a version 3 certificate, verify that the
basicConstraints extension is present and that cA is set to
TRUE. (If certificate i is a version 1 or version 2
certificate, then the application MUST either verify that
certificate i is a CA certificate through out-of-band means
or reject the certificate. Conforming implementations may
choose to reject all version 1 and version 2 intermediate
certificates.)
(k) 証明書iがバージョン3証明書であるなら、basicConstraints拡張子が存在していて、cAがTRUEに用意ができていることを確かめてください。 (証明書iがバージョン1かバージョン2証明書であるなら、アプリケーションは、証明書iがバンドで出ている手段でカリフォルニア証明書であることを確かめなければならないか、または証明書を拒絶しなければなりません。 実現を従わせるのは、すべてのバージョン1とバージョン2の中間的証明書を拒絶するのを選ぶかもしれません。)
(l) If the certificate was not self-issued, verify that
max_path_length is greater than zero and decrement
max_path_length by 1.
(l) 証明書が自己に発行されなかったなら、最大_経路_の長さが1時までにゼロと減少最大_経路_の長さより大きいことを確かめてください。
(m) If pathLenConstraint is present in the certificate and is
less than max_path_length, set max_path_length to the value
of pathLenConstraint.
(m) pathLenConstraintが証明書に存在していて、最大_経路_の長さ以下であるなら、最大_経路_の長さをpathLenConstraintの値に設定してください。
(n) If a key usage extension is present, verify that the
keyCertSign bit is set.
(n) 主要な用法拡大が存在しているなら、keyCertSignビットが設定されることを確かめてください。
(o) Recognize and process any other critical extension present in
the certificate. Process any other recognized non-critical
extension present in the certificate that is relevant to path
processing.
(o)は、証明書の現在のいかなる他の批判的な拡大も認識して、処理します。 経路処理に関連している証明書の現在のいかなる他の認識された非臨界拡大も処理してください。
If check (a), (k), (l), (n), or (o) fails, the procedure terminates, returning a failure indication and an appropriate reason.
チェック(a)、(k)、(l)、(n)、または(o)が失敗するなら、手順は終わって、失敗指示と適切な理由を返します。
If (a), (k), (l), (n), and (o) have completed successfully, increment i and perform the basic certificate processing specified in Section 6.1.3.
(a)、(l)、(n)、および(o)が持っている(k)が首尾よく完成して、iを増加してくださいといって、セクション6.1で.3に指定された基本的な証明書処理を実行してくださいなら
6.1.5. Wrap-Up Procedure
6.1.5. 結論手順
To complete the processing of the target certificate, perform the following steps for certificate n:
目標証明書の処理を終了するには、証明書nのための以下のステップを実行してください:
(a) If explicit_policy is not 0, decrement explicit_policy by 1.
(a) 明白な_方針が0でないなら、明白な_方針を1つ減少させてください。
(b) If a policy constraints extension is included in the
certificate and requireExplicitPolicy is present and has a
value of 0, set the explicit_policy state variable to 0.
(b) 方針規制拡大が証明書に含まれていて、requireExplicitPolicyが存在していて、0の値を持っているなら、明白な_政策ポジション変数を0に設定してください。
Cooper, et al. Standards Track [Page 87] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[87ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
(c) Assign the certificate subjectPublicKey to
working_public_key.
(c) 働く_公共の_キーに証明書subjectPublicKeyを割り当ててください。
(d) If the subjectPublicKeyInfo field of the certificate contains
an algorithm field with non-null parameters, assign the
parameters to the working_public_key_parameters variable.
(d) 証明書のsubjectPublicKeyInfo分野が非ヌルパラメタがあるアルゴリズム分野を含むなら、働く_の公共の_主要な_パラメタ変数にパラメタを割り当ててください。
If the subjectPublicKeyInfo field of the certificate contains
an algorithm field with null parameters or parameters are
omitted, compare the certificate subjectPublicKey algorithm
to the working_public_key_algorithm. If the certificate
subjectPublicKey algorithm and the
working_public_key_algorithm are different, set the
working_public_key_parameters to null.
証明書のsubjectPublicKeyInfo分野がヌルパラメタがあるアルゴリズム分野を含んでいるか、またはパラメタが省略されるなら、働く_公共の_主要な_アルゴリズムに証明書subjectPublicKeyアルゴリズムをたとえてください。 証明書subjectPublicKeyアルゴリズムと働く_公共の_主要な_アルゴリズムが異なるなら、働く_公共の_主要な_パラメタをヌルに設定してください。
(e) Assign the certificate subjectPublicKey algorithm to the
working_public_key_algorithm variable.
(e) 働く_の公共の_主要な_アルゴリズム変数に証明書subjectPublicKeyアルゴリズムを割り当ててください。
(f) Recognize and process any other critical extension present in
the certificate n. Process any other recognized non-critical
extension present in certificate n that is relevant to path
processing.
(f) 証明書nの現在のいかなる他の批判的な拡大も認識して、処理してください。 経路処理に関連している証明書nの現在のいかなる他の認識された非臨界拡大も処理してください。
(g) Calculate the intersection of the valid_policy_tree and the
user-initial-policy-set, as follows:
(g) 以下の通り有効な_方針_木とユーザの初期の方針セットの交差点について計算してください:
(i) If the valid_policy_tree is NULL, the intersection is
NULL.
(i) 有効な_方針_木がNULLであるなら、交差点はNULLです。
(ii) If the valid_policy_tree is not NULL and the user-
initial-policy-set is any-policy, the intersection is
the entire valid_policy_tree.
有効な_方針_木であるなら(ii)がNULLでなく、ユーザの初期の方針セットがNULLである、いくらか、-、方針、交差点は全体の有効な_方針_木です。
(iii) If the valid_policy_tree is not NULL and the user-
initial-policy-set is not any-policy, calculate the
intersection of the valid_policy_tree and the user-
initial-policy-set as follows:
有効な_方針_木であるなら(iii)がNULLでなく、またユーザの初期の方針セットがNULLでない、いくらか、-、方針、以下の有効な_方針_木とユーザの初期の方針セットの交差点について計算してください:
1. Determine the set of policy nodes whose parent nodes
have a valid_policy of anyPolicy. This is the
valid_policy_node_set.
1. 親ノードにはanyPolicyの有効な_方針がある方針ノードのセットを決定してください。 これは有効な_方針_ノード_セットです。
2. If the valid_policy of any node in the
valid_policy_node_set is not in the user-initial-
policy-set and is not anyPolicy, delete this node and
all its children.
2. 有効な_方針_ノード_セットにおけるどんなノードの有効な_方針もユーザ初期に方針への設定にされるのになくて、またanyPolicyでないなら、このノードとそのすべての子供を削除してください。
Cooper, et al. Standards Track [Page 88] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[88ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
3. If the valid_policy_tree includes a node of depth n
with the valid_policy anyPolicy and the user-initial-
policy-set is not any-policy, perform the following
steps:
3. 有効な_方針_木が深さのノードを含んでいるなら有効な_方針anyPolicyであってユーザ初期に方針への設定にされるのがあるnがそうでない、いくらか、-、方針、以下のステップを実行してください:
a. Set P-Q to the qualifier_set in the node of depth n
with valid_policy anyPolicy.
a。 有効な_方針anyPolicyで深さnのノードで用意ができている資格を与える人_にP-Qを設定してください。
b. For each P-OID in the user-initial-policy-set that is
not the valid_policy of a node in the
valid_policy_node_set, create a child node whose
parent is the node of depth n-1 with the valid_policy
anyPolicy. Set the values in the child node as
follows: set the valid_policy to P-OID, set the
qualifier_set to P-Q, and set the expected_policy_set
to {P-OID}.
b。 有効な_方針_ノード_セットにおけるノードの有効な_方針でないユーザの初期の方針セットにおける各P-OIDに関しては、有効な_方針anyPolicyで親が深さn-1のノードである子供ノードを作成してください。 以下の子供ノードに値をはめ込んでください: 有効な_方針をP-OIDに設定してください、そして、資格を与える人_セットをP-Qに設定してください、そして、予想された_方針_セットをP-OIDに設定してください。
c. Delete the node of depth n with the valid_policy
anyPolicy.
c。 有効な_方針anyPolicyで深さnのノードを削除してください。
4. If there is a node in the valid_policy_tree of depth
n-1 or less without any child nodes, delete that node.
Repeat this step until there are no nodes of depth n-1
or less without children.
4. ノードが深さn-1か以下の有効な_方針_木に少しも子供ノードなしであれば、そのノードを削除してください。 深さn-1か以下のノードが全く子供なしでないまで、このステップを繰り返してください。
If either (1) the value of explicit_policy variable is greater than zero or (2) the valid_policy_tree is not NULL, then path processing has succeeded.
(1) 明白な_政策変数の値がゼロ以上であるか(2) 有効な_方針_木がNULLでないなら、経路処理は成功しました。
6.1.6. Outputs
6.1.6. 出力
If path processing succeeds, the procedure terminates, returning a success indication together with final value of the valid_policy_tree, the working_public_key, the working_public_key_algorithm, and the working_public_key_parameters.
経路処理が成功するなら、手順は終わります、有効な_方針_木、働く_公共の_キー、働く_公共の_主要な_アルゴリズム、および働く_公共の_主要な_パラメタの検査値と共に成功指示を返して。
6.2. Using the Path Validation Algorithm
6.2. 経路合法化アルゴリズムを使用します。
The path validation algorithm describes the process of validating a single certification path. While each certification path begins with a specific trust anchor, there is no requirement that all certification paths validated by a particular system share a single trust anchor. The selection of one or more trusted CAs is a local decision. A system may provide any one of its trusted CAs as the trust anchor for a particular path. The inputs to the path validation algorithm may be different for each path. The inputs used to process a path may reflect application-specific requirements or limitations in the trust accorded a particular trust anchor. For
経路合法化アルゴリズムはただ一つの証明経路を有効にする過程について説明します。 それぞれの証明経路は特定の信用アンカーと共に始まりますが、特定のシステムによって有効にされたすべての証明経路が独身の信用アンカーを共有するという要件が全くありません。 1かさらに信じられたCAsの品揃えはローカルの決定です。 システムは特定の経路への信用アンカーとして信じられたCAsのいずれも提供するかもしれません。 各経路において、経路合法化アルゴリズムへの入力は異なっているかもしれません。 経路を処理するのに使用される入力は特定の信用アンカーに与えられた信用におけるアプリケーション決められた一定の要求か制限を反映するかもしれません。 for
Cooper, et al. Standards Track [Page 89] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[89ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
example, a trusted CA may only be trusted for a particular certificate policy. This restriction can be expressed through the inputs to the path validation procedure.
例、信じられたカリフォルニアは特定の証明書方針のために信じられるだけであるかもしれません。 経路合法化手順への入力でこの制限を表すことができます。
An implementation MAY augment the algorithm presented in Section 6.1 to further limit the set of valid certification paths that begin with a particular trust anchor. For example, an implementation MAY modify the algorithm to apply a path length constraint to a specific trust anchor during the initialization phase, or the application MAY require the presence of a particular alternative name form in the target certificate, or the application MAY impose requirements on application-specific extensions. Thus, the path validation algorithm presented in Section 6.1 defines the minimum conditions for a path to be considered valid.
実現はさらに特定の信用アンカーと共に始まる有効な証明経路のセットを制限するためにセクション6.1に提示されたアルゴリズムを増大させるかもしれません。 例えば、実現が初期設定段階の間、経路長さの規制を特定の信用アンカーに適用するようにアルゴリズムを変更するかもしれませんか、アプリケーションが目標証明書で特定の代替名フォームを存在に要求するかもしれませんか、またはアプリケーションはアプリケーション特有の拡大に要件を課すかもしれません。 したがって、セクション6.1に提示された経路合法化アルゴリズムは経路が有効であると考えられる最小の状態を定義します。
Where a CA distributes self-signed certificates to specify trust anchor information, certificate extensions can be used to specify recommended inputs to path validation. For example, a policy constraints extension could be included in the self-signed certificate to indicate that paths beginning with this trust anchor should be trusted only for the specified policies. Similarly, a name constraints extension could be included to indicate that paths beginning with this trust anchor should be trusted only for the specified name spaces. The path validation algorithm presented in Section 6.1 does not assume that trust anchor information is provided in self-signed certificates and does not specify processing rules for additional information included in such certificates. Implementations that use self-signed certificates to specify trust anchor information are free to process or ignore such information.
カリフォルニアが信用アンカー情報を指定するために自己署名入りの証書を配布するところでは、経路合法化にお勧めの入力を指定するのに証明書拡張子を使用できます。 例えば、この信用アンカーと共に始まる経路が特約保険証券のためだけに信じられるべきであるのを示すために自己署名入りの証書に方針規制拡大を含むことができました。 同様に、この信用アンカーと共に始まる経路が空間という指定された名前のためだけに信じられるべきであるのを示すために名前規制拡大を含むことができました。 セクション6.1に提示された経路合法化アルゴリズムは信用アンカー情報が自己署名入りの証書に供給されて、そのような証明書に追加情報のための処理規則を含んでいて、指定しないと仮定しません。 そのような情報を処理するか、または信用アンカー情報を指定するのに自己署名入りの証書を使用する実現は無料で無視できます。
6.3. CRL Validation
6.3. CRL合法化
This section describes the steps necessary to determine if a certificate is revoked when CRLs are the revocation mechanism used by the certificate issuer. Conforming implementations that support CRLs are not required to implement this algorithm, but they MUST be functionally equivalent to the external behavior resulting from this procedure when processing CRLs that are issued in conformance with this profile. Any algorithm may be used by a particular implementation so long as it derives the correct result.
このセクションは、CRLsが証明書発行人によって使用された取消しメカニズムであるときに、証明書が取り消されるかどうか決定するために必要なステップについて説明します。 CRLsを支持する従う実現はこのアルゴリズムを実行するのに必要ではありませんが、彼らはこのプロフィールによる順応で発行されるCRLsを処理するときこの手順から生じる外部の振舞いに機能上同等でなければなりません。 正しい結果を引き出す限り、どんなアルゴリズムも特定の実現で使用されるかもしれません。
This algorithm assumes that all of the needed CRLs are available in a local cache. Further, if the next update time of a CRL has passed, the algorithm assumes a mechanism to fetch a current CRL and place it in the local CRL cache.
このアルゴリズムは、必要なCRLsのすべてがローカルなキャッシュで利用可能であると仮定します。 さらに、CRLの次のアップデート時間が過ぎたなら、アルゴリズムは、現在のCRLをとって来て、ローカルなCRLキャッシュにそれを置くためにメカニズムを仮定します。
Cooper, et al. Standards Track [Page 90] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[90ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
This algorithm defines a set of inputs, a set of state variables, and processing steps that are performed for each certificate in the path. The algorithm output is the revocation status of the certificate.
このアルゴリズムは経路の各証明書のために実行される1セットの1セットの入力、州の変数、および処理ステップを定義します。 アルゴリズム出力は証明書の取消し状態です。
6.3.1. Revocation Inputs
6.3.1. 取消し入力
To support revocation processing, the algorithm requires two inputs:
取消し処理を支持するために、アルゴリズムは2つの入力を必要とします:
(a) certificate: The algorithm requires the certificate serial
number and issuer name to determine whether a certificate is
on a particular CRL. The basicConstraints extension is used
to determine whether the supplied certificate is associated
with a CA or an end entity. If present, the algorithm uses
the cRLDistributionPoints and freshestCRL extensions to
determine revocation status.
(a) 以下を証明してください。 アルゴリズムは、証明書が特定のCRLにあるかを決定するために証明書通し番号と発行人名を必要とします。 basicConstraints拡張子は、供給された証明書がカリフォルニアか終わりの実体に関連しているかどうか決定するのに使用されます。 存在しているなら、アルゴリズムは、取消し状態を決定するのにcRLDistributionPointsとfreshestCRL拡張子を使用します。
(b) use-deltas: This boolean input determines whether delta CRLs
are applied to CRLs.
(b)、デルタを使用する、: この論理演算子入力は、デルタCRLsがCRLsに適用されるかどうか決定します。
6.3.2. Initialization and Revocation State Variables
6.3.2. 初期設定と取消し州の変数
To support CRL processing, the algorithm requires the following state variables:
CRL処理を支持するために、アルゴリズムは以下の州の変数を必要とします:
(a) reasons_mask: This variable contains the set of revocation
reasons supported by the CRLs and delta CRLs processed so
far. The legal members of the set are the possible
revocation reason values minus unspecified: keyCompromise,
cACompromise, affiliationChanged, superseded,
cessationOfOperation, certificateHold, privilegeWithdrawn,
and aACompromise. The special value all-reasons is used to
denote the set of all legal members. This variable is
initialized to the empty set.
(a) 理由_マスク: この変数は今までのところ処理されているCRLsのCRLsとデルタによって支持された取消し理由のセットを含んでいます。 セットの法的なメンバーは不特定を引いた可能な取消し理由値です: keyCompromiseする、affiliationChangedであって、取って代わられたcACompromise、cessationOfOperation、certificateHold、privilegeWithdrawn、およびaACompromise。 特別番組は、すべての法的なメンバーのセットを指示するのに使用されます値が、オール推論する。 この変数は空集合に初期化されます。
(b) cert_status: This variable contains the status of the
certificate. This variable may be assigned one of the
following values: unspecified, keyCompromise, cACompromise,
affiliationChanged, superseded, cessationOfOperation,
certificateHold, removeFromCRL, privilegeWithdrawn,
aACompromise, the special value UNREVOKED, or the special
value UNDETERMINED. This variable is initialized to the
special value UNREVOKED.
(b)本命_状態: この変数は証明書の状態を含んでいます。 以下の値の1つはこの変数に割り当てられるかもしれません: 不特定であることで、keyCompromise、cACompromise、affiliationChangedが取って代わられて、cessationOfOperation、certificateHold、removeFromCRL、privilegeWithdrawn、aACompromise、特別な値のUNREVOKED、または特別番組がUNDETERMINEDを評価します。 この変数は特別な値のUNREVOKEDに初期化されます。
(c) interim_reasons_mask: This contains the set of revocation
reasons supported by the CRL or delta CRL currently being
processed.
(c) 当座の_は_マスクを推論します: これは処理される現在CRLのCRLかデルタによって支持されている取消し理由のセットを含んでいます。
Cooper, et al. Standards Track [Page 91] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[91ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
Note: In some environments, it is not necessary to check all reason codes. For example, some environments are only concerned with cACompromise and keyCompromise for CA certificates. This algorithm checks all reason codes. Additional processing and state variables may be necessary to limit the checking to a subset of the reason codes.
以下に注意してください。 いくつかの環境で、すべての理由コードをチェックするのは必要ではありません。 例えば、いくつかの環境がカリフォルニア証明書のためのcACompromiseとkeyCompromiseに関係があるだけです。 このアルゴリズムはすべての理由コードをチェックします。 追加処理と州の変数が、照合を理由コードの部分集合に制限するのに必要であるかもしれません。
6.3.3. CRL Processing
6.3.3. CRL処理
This algorithm begins by assuming that the certificate is not revoked. The algorithm checks one or more CRLs until either the certificate status is determined to be revoked or sufficient CRLs have been checked to cover all reason codes.
証明書が取り消されないと仮定することによって、このアルゴリズムは始まります。 証明書状態が取り消されることを決定しているか、または十分なCRLsがすべての理由コードをカバーするためにチェックされるまで、アルゴリズムは1CRLsをチェックします。
For each distribution point (DP) in the certificate's CRL distribution points extension, for each corresponding CRL in the local CRL cache, while ((reasons_mask is not all-reasons) and (cert_status is UNREVOKED)) perform the following:
それぞれの分配ポイントに、証明書のCRL分配における(DP)は、(_マスクがオール理由でない理由)である間、それぞれの対応するCRLのためにローカルなCRLキャッシュで拡大を指して、以下を実行します(本命_状態はUNREVOKEDです):
(a) Update the local CRL cache by obtaining a complete CRL, a
delta CRL, or both, as required:
(a) 必要に応じて完全なCRL、CRLデルタ、または両方を入手することによって、ローカルなCRLキャッシュをアップデートしてください:
(1) If the current time is after the value of the CRL next
update field, then do one of the following:
(1) 現在の時間がCRLの値の後に次にあるなら、分野をアップデートしてください、そして、次に、以下の1つをしてください:
(i) If use-deltas is set and either the certificate or the
CRL contains the freshest CRL extension, obtain a
delta CRL with a next update value that is after the
current time and can be used to update the locally
cached CRL as specified in Section 5.2.4.
デルタを使用するなら(i)がセットであり、証明書かCRLのどちらかは最も新鮮なCRL拡張子を含んでいて、現在の時間の後に、ある次のアップデート値でCRLデルタを得て、セクション5.2.4における指定されるとしての局所的にキャッシュされたCRLをアップデートするのに使用できます。
(ii) Update the local CRL cache with a current complete
CRL, verify that the current time is before the next
update value in the new CRL, and continue processing
with the new CRL. If use-deltas is set and either the
certificate or the CRL contains the freshest CRL
extension, then obtain the current delta CRL that can
be used to update the new locally cached complete CRL
as specified in Section 5.2.4.
(ii) 現在の完全なCRLと共にローカルなCRLキャッシュをアップデートしてください、そして、現在の時間が次のアップデート値の前に新しいCRLにあることを確かめてください、そして、新しいCRLと共に処理し続けてください。 デルタを使用する、セクション5.2で.4に指定されて、証明書かCRLが局所的に新しくキャッシュされた完全なCRLをアップデートするために、最も新鮮なCRL拡張子を含んでいて、次に使用できるCRLの現在のデルタを得るセットとどちらかです。
(2) If the current time is before the value of the next update
field, use-deltas is set, and either the certificate or
the CRL contains the freshest CRL extension, then obtain
the current delta CRL that can be used to update the
locally cached complete CRL as specified in Section 5.2.4.
次のアップデート分野の値の前に(2)は現在の時間であるならそうです、デルタを使用します。証明書かCRLが最も新たに含むセット、およびどちらかがCRL拡張子であり、次に、セクション5.2.4における指定されるとしての局所的にキャッシュされた完全なCRLをアップデートするのに使用できるCRLの現在のデルタを得てください。
Cooper, et al. Standards Track [Page 92] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[92ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
(b) Verify the issuer and scope of the complete CRL as follows:
(b) 以下の完全なCRLの発行人と範囲について確かめてください:
(1) If the DP includes cRLIssuer, then verify that the issuer
field in the complete CRL matches cRLIssuer in the DP and
that the complete CRL contains an issuing distribution
point extension with the indirectCRL boolean asserted.
Otherwise, verify that the CRL issuer matches the
certificate issuer.
(1) DPがcRLIssuerを含んでいるなら、完全なCRLの発行人分野がDPでcRLIssuerに合って、完全なCRLがindirectCRL論理演算子があるポイント拡大が断言した発行分配を含むことを確かめてください。 さもなければ、CRL発行人が証明書発行人に合っていることを確かめてください。
(2) If the complete CRL includes an issuing distribution point
(IDP) CRL extension, check the following:
(2) 完全なCRLが発行分配を含んでいるなら、(IDP)CRL拡張子を指してください、そして、以下をチェックしてください:
(i) If the distribution point name is present in the IDP
CRL extension and the distribution field is present in
the DP, then verify that one of the names in the IDP
matches one of the names in the DP. If the
distribution point name is present in the IDP CRL
extension and the distribution field is omitted from
the DP, then verify that one of the names in the IDP
matches one of the names in the cRLIssuer field of the
DP.
(i) 存在というIDP CRL拡張子と分配分野の現在の分配ポイント名がDPに存在しているなら、IDPの名前の1つがDPの名前の1つに合っていることを確かめてください。 存在というIDP CRL拡張子と分配分野の現在の分配ポイント名がDPから省略されるなら、IDPの名前の1つがDPのcRLIssuer分野で名前の1つに合っていることを確かめてください。
(ii) If the onlyContainsUserCerts boolean is asserted in
the IDP CRL extension, verify that the certificate
does not include the basic constraints extension with
the cA boolean asserted.
(ii) onlyContainsUserCerts論理演算子がIDP CRL拡張子で断言されるなら、証明書がcA論理演算子が断言されている基本的な規制拡大を含んでいないことを確かめてください。
(iii) If the onlyContainsCACerts boolean is asserted in the
IDP CRL extension, verify that the certificate
includes the basic constraints extension with the cA
boolean asserted.
(iii) onlyContainsCACerts論理演算子がIDP CRL拡張子で断言されるなら、証明書がcA論理演算子が断言されている基本的な規制拡大を含んでいることを確かめてください。
(iv) Verify that the onlyContainsAttributeCerts boolean is
not asserted.
(iv) onlyContainsAttributeCerts論理演算子が断言されないことを確かめてください。
(c) If use-deltas is set, verify the issuer and scope of the
delta CRL as follows:
デルタを使用するなら、(c)はセットであり、以下のCRLデルタの発行人と範囲について確かめてください:
(1) Verify that the delta CRL issuer matches the complete CRL
issuer.
(1) デルタCRL発行人が完全なCRL発行人に合っていることを確かめてください。
(2) If the complete CRL includes an issuing distribution point
(IDP) CRL extension, verify that the delta CRL contains a
matching IDP CRL extension. If the complete CRL omits an
IDP CRL extension, verify that the delta CRL also omits an
IDP CRL extension.
(2) 完全なCRLが発行分配を含んでいるなら、(IDP)CRL拡張子を指してください、そして、CRLデルタが合っているIDP CRL拡張子を含むことを確かめてください。 完全なCRLがIDP CRL拡張子を省略するなら、また、CRLデルタがIDP CRL拡張子を省略することを確かめてください。
Cooper, et al. Standards Track [Page 93] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[93ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
(3) Verify that the delta CRL authority key identifier
extension matches the complete CRL authority key
identifier extension.
(3) デルタのCRLの権威の主要な識別子拡張子が完全なCRL権威主要な識別子拡張子に合っていることを確かめてください。
(d) Compute the interim_reasons_mask for this CRL as follows:
(d) 以下のこのCRLのために当座の_理由_マスクを計算してください:
(1) If the issuing distribution point (IDP) CRL extension is
present and includes onlySomeReasons and the DP includes
reasons, then set interim_reasons_mask to the intersection
of reasons in the DP and onlySomeReasons in the IDP CRL
extension.
(1) 発行分配であるなら、ポイント(IDP)CRL拡張子は、存在していて、onlySomeReasonsを含んでいます、そして、DPはIDP CRL拡張子で理由、当時のセット当座_理由_マスクをDPとonlySomeReasonsの理由の交差点に含めます。
(2) If the IDP CRL extension includes onlySomeReasons but the
DP omits reasons, then set interim_reasons_mask to the
value of onlySomeReasons in the IDP CRL extension.
(2) IDP CRL拡張子がonlySomeReasonsを含んでいますが、DPが理由を省略するなら、当座の_理由_マスクをIDP CRL拡張子における、onlySomeReasonsの値に設定してください。
(3) If the IDP CRL extension is not present or omits
onlySomeReasons but the DP includes reasons, then set
interim_reasons_mask to the value of DP reasons.
(3) IDP CRL拡張子が存在していないか、またはonlySomeReasonsを省略しますが、DPが理由を含んでいるなら、セット当座_理由_はDPの値に理由にマスクをかけます。
(4) If the IDP CRL extension is not present or omits
onlySomeReasons and the DP omits reasons, then set
interim_reasons_mask to the special value all-reasons.
(4) IDP CRL拡張子が存在していないか、またはonlySomeReasonsを省略して、DPが理由を省略するなら、セット当座_理由_は特別な値にオール理由にマスクをかけます。
(e) Verify that interim_reasons_mask includes one or more reasons
that are not included in the reasons_mask.
(e) 当座の_理由_マスクが理由_マスクに含まれていない1つ以上の理由を含んでいることを確かめてください。
(f) Obtain and validate the certification path for the issuer of
the complete CRL. The trust anchor for the certification
path MUST be the same as the trust anchor used to validate
the target certificate. If a key usage extension is present
in the CRL issuer's certificate, verify that the cRLSign bit
is set.
(f) 完全なCRLの発行人のために証明経路を得て、有効にしてください。 証明経路への信頼アンカーは信頼アンカーが以前はよく目標証明書を有効にしていたのと同じであるに違いありません。 主要な用法拡大がCRL発行人の証明書に存在しているなら、cRLSignビットが設定されることを確かめてください。
(g) Validate the signature on the complete CRL using the public
key validated in step (f).
(g) ステップ(f)で有効にされた公開鍵を使用して、完全なCRLで署名を有効にしてください。
(h) If use-deltas is set, then validate the signature on the
delta CRL using the public key validated in step (f).
デルタを使用するなら、(h)はセットして、次に、CRLデルタでステップ(f)で有効にされた公開鍵を使用することで署名を有効にすることです。
(i) If use-deltas is set, then search for the certificate on the
delta CRL. If an entry is found that matches the certificate
issuer and serial number as described in Section 5.3.3, then
set the cert_status variable to the indicated reason as
follows:
デルタを使用するなら(i)がセットである、CRLはその時、デルタの証明書を探します。 セクション5.3.3で説明されるように証明書発行人と通し番号に合っているエントリーが見つけられるなら、本命_状態変数を以下の示された理由に設定してください:
Cooper, et al. Standards Track [Page 94] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[94ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
(1) If the reason code CRL entry extension is present, set the
cert_status variable to the value of the reason code CRL
entry extension.
(1) 理由コードCRLエントリー拡張子が存在しているなら、理由コードCRLエントリー拡張子の値に本命_状態変数を設定してください。
(2) If the reason code CRL entry extension is not present, set
the cert_status variable to the value unspecified.
(2) 理由コードCRLエントリー拡張子が存在していないなら、本命_状態変数を不特定の状態で値に設定してください。
(j) If (cert_status is UNREVOKED), then search for the
certificate on the complete CRL. If an entry is found that
matches the certificate issuer and serial number as described
in Section 5.3.3, then set the cert_status variable to the
indicated reason as described in step (i).
(j)、(本命_状態はUNREVOKEDです)、そして、完全なCRLの上の証明書を検索してください。 セクション5.3.3で説明されるように証明書発行人と通し番号に合っているエントリーが見つけられるなら、ステップ(i)で説明されるように本命_状態変数を示された理由に設定してください。
(k) If (cert_status is removeFromCRL), then set cert_status to
UNREVOKED.
(k)、(本命_状態はremoveFromCRLです)、UNREVOKEDへの本命_状態はその時、セットしました。
(l) Set the reasons_mask state variable to the union of its
previous value and the value of the interim_reasons_mask
state variable.
(l) 前の価値の組合と当座_理由_マスク州の変数の値に理由_マスク州の変数を設定してください。
If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)), then the revocation status has been determined, so return cert_status.
取消し状態が((_マスクがオール理由である理由)OR(本命_状態はUNREVOKEDでない))であるなら決定しているので、本命_に状態を返してください。
If the revocation status has not been determined, repeat the process above with any available CRLs not specified in a distribution point but issued by the certificate issuer. For the processing of such a CRL, assume a DP with both the reasons and the cRLIssuer fields omitted and a distribution point name of the certificate issuer. That is, the sequence of names in fullName is generated from the certificate issuer field as well as the certificate issuerAltName extension. After processing such CRLs, if the revocation status has still not been determined, then return the cert_status UNDETERMINED.
取消し状態が決定していないなら、分配ポイントで指定されませんが、証明書発行人によって発行されているどんな利用可能なCRLsでの上のプロセスも繰り返してください。 そのようなCRLの処理には、理由とcRLIssuer分野の両方が省略されているDPと証明書発行人の分配ポイント名を仮定してください。 すなわち、fullNameの名前の系列は証明書issuerAltName拡張子と同様に証明書発行人分野から生成されます。 そのようなCRLsを処理した後に、取消し状態がまだ決定していないなら、本命_状態UNDETERMINEDを返してください。
7. Processing Rules for Internationalized Names
7. 国際化している名前のための処理規則
Internationalized names may be encountered in numerous certificate and CRL fields and extensions, including distinguished names, internationalized domain names, electronic mail addresses, and Internationalized Resource Identifiers (IRIs). Storage, comparison, and presentation of such names require special care. Some characters may be encoded in multiple ways. The same names could be represented in multiple encodings (e.g., ASCII or UTF8). This section establishes conformance requirements for storage or comparison of each of these name forms. Informative guidance on presentation is provided for some of these name forms.
国際化している名前は多数の証明書、CRL分野、および拡大で遭遇するかもしれません、分類名、国際化ドメイン名、電子メールアドレス、およびInternationalized Resource Identifiers(IRIs)を含んでいて。 そのような名前のストレージ、比較、およびプレゼンテーションは特別な注意を必要とします。 複数の方法でコード化されるキャラクタもあるかもしれません。 複数のencodings(例えば、ASCIIかUTF8)に同じ名前を表すことができました。 このセクションはそれぞれのこれらの名前形式のストレージか比較のための順応要件を確立します。これらのいくつかの名前フォームにプレゼンテーションの有益な指導を提供します。
Cooper, et al. Standards Track [Page 95] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[95ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
7.1. Internationalized Names in Distinguished Names
7.1. 分類名における国際化している名前
Representation of internationalized names in distinguished names is covered in Sections 4.1.2.4, Issuer Name, and 4.1.2.6, Subject Name. Standard naming attributes, such as common name, employ the DirectoryString type, which supports internationalized names through a variety of language encodings. Conforming implementations MUST support UTF8String and PrintableString. RFC 3280 required only binary comparison of attribute values encoded in UTF8String, however, this specification requires a more comprehensive handling of comparison. Implementations may encounter certificates and CRLs with names encoded using TeletexString, BMPString, or UniversalString, but support for these is OPTIONAL.
そして、分類名における、国際化している名前の表現がセクション4.1.2でカバーされている、.4、Issuer Name、4.1 .2 .6 Subject Name。 属性を命名するサポートが国際的にした一般名、DirectoryStringがタイプする雇用などの規格がさまざまな言語を通してencodingsを命名します。 実装を従わせると、UTF8StringとPrintableStringはサポートしなければなりません。 RFC3280はUTF8Stringでコード化された属性値の2進の比較だけを必要として、しかしながら、この仕様は比較の、より包括的な取り扱いを必要とします。 TeletexString、BMPString、またはUniversalStringを使用することで名前がコード化されている状態で、実装は証明書とCRLsに遭遇するかもしれませんが、これらのサポートはOPTIONALです。
Conforming implementations MUST use the LDAP StringPrep profile (including insignificant space handling), as specified in [RFC4518], as the basis for comparison of distinguished name attributes encoded in either PrintableString or UTF8String. Conforming implementations MUST support name comparisons using caseIgnoreMatch. Support for attribute types that use other equality matching rules is optional.
実装を従わせると、LDAP StringPrepプロフィールは使用されなければなりません(わずかな宇宙取り扱いを含んでいて)、[RFC4518]で指定されるように、PrintableStringかUTF8Stringのどちらかでコード化された分類名属性の比較の基準として。 実装を従わせると、caseIgnoreMatchを使用して、名前比較はサポートしなければなりません。 他の平等の合っている規則を使用する属性タイプのサポートは任意です。
Before comparing names using the caseIgnoreMatch matching rule, conforming implementations MUST perform the six-step string preparation algorithm described in [RFC4518] for each attribute of type DirectoryString, with the following clarifications:
caseIgnoreMatchの合っている規則を使用することで名前を比較する前に、実装を従わせると、タイプDirectoryStringの各属性のために[RFC4518]で説明された6ステップのストリング準備アルゴリズムは働かなければなりません、以下の明確化で:
* In step 2, Map, the mapping shall include case folding as
specified in Appendix B.2 of [RFC3454].
* ステップ2、Mapでは、マッピングは[RFC3454]のAppendix B.2の指定されるとしてのケースの折り重なりを含んでいるものとします。
* In step 6, Insignificant Character Removal, perform white space
compression as specified in Section 2.6.1, Insignificant Space
Handling, of [RFC4518].
* ステップ6、InsignificantキャラクターRemovalでは、セクション2.6.1における指定されるとしての余白圧縮、[RFC4518]のInsignificant Space Handlingを実行してください。
When performing the string preparation algorithm, attributes MUST be treated as stored values.
ストリング準備アルゴリズムを実行するとき、保存された値として属性を扱わなければなりません。
Comparisons of domainComponent attributes MUST be performed as specified in Section 7.3.
属性を実行しなければならないdomainComponentの比較はセクション7.3で指定しました。
Two naming attributes match if the attribute types are the same and the values of the attributes are an exact match after processing with the string preparation algorithm. Two relative distinguished names RDN1 and RDN2 match if they have the same number of naming attributes and for each naming attribute in RDN1 there is a matching naming attribute in RDN2. Two distinguished names DN1 and DN2 match if they have the same number of RDNs, for each RDN in DN1 there is a matching RDN in DN2, and the matching RDNs appear in the same order in both DNs. A distinguished name DN1 is within the subtree defined by the
属性タイプが同じであるなら、属性を命名する2が合っています、そして、属性の値はストリング準備アルゴリズムで処理した後の完全な一致です。 それらに同じ数の命名属性があるなら、2親類の分類名のRDN1とRDN2は合っています、そして、RDN1のそれぞれの命名属性のために、合っている命名属性がRDN2にあります。 それらにRDNsの同じ数がそこのDN1の各RDNがDN2の合っているRDNであるのであるならDN1とDN2が合わせて、合っているRDNsが同じくらいで見える2つの分類名が両方のDNsを入るように命じます。 定義された下位木の中にA分類名DN1があります。
Cooper, et al. Standards Track [Page 96] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[96ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
distinguished name DN2 if DN1 contains at least as many RDNs as DN2, and DN1 and DN2 are a match when trailing RDNs in DN1 are ignored.
DN1の引きずっているRDNsが無視されるとき、DN1が少なくともDN2、DN1、およびDN2と同じくらい多くのRDNsを含んでいるなら、分類名DN2はマッチです。
7.2. Internationalized Domain Names in GeneralName
7.2. GeneralNameの国際化ドメイン名
Internationalized Domain Names (IDNs) may be included in certificates and CRLs in the subjectAltName and issuerAltName extensions, name constraints extension, authority information access extension, subject information access extension, CRL distribution points extension, and issuing distribution point extension. Each of these extensions uses the GeneralName type; one choice in GeneralName is the dNSName field, which is defined as type IA5String.
国際化しているDomain Names(IDNs)は証明書とCRLsにsubjectAltNameと、issuerAltName拡張子と、名前規制拡大と、権威情報アクセス拡張子と、対象の情報アクセス拡張子と、CRL分配ポイント拡張子と、分配ポイント拡大を発行する際に含まれるかもしれません。 それぞれのこれらの拡大はGeneralNameタイプを使用します。 GeneralNameでの1つの選択がdNSName分野です。(その分野はタイプIA5Stringと定義されます)。
IA5String is limited to the set of ASCII characters. To accommodate internationalized domain names in the current structure, conforming implementations MUST convert internationalized domain names to the ASCII Compatible Encoding (ACE) format as specified in Section 4 of RFC 3490 before storage in the dNSName field. Specifically, conforming implementations MUST perform the conversion operation specified in Section 4 of RFC 3490, with the following clarifications:
IA5StringはASCII文字のセットに制限されます。 現在の構造で国際化ドメイン名に対応するために、実装を従わせると、国際化ドメイン名はストレージの前にdNSName分野でRFC3490のセクション4における指定されるとしてのASCII Compatible Encoding(ACE)形式に変換されなければなりません。 明確に、実装を従わせると、RFC3490のセクション4で以下の明確化で指定された変換操作は働かなければなりません:
* in step 1, the domain name SHALL be considered a "stored
string". That is, the AllowUnassigned flag SHALL NOT be set;
* 1、ドメイン名SHALLは中に踏みます。「保存されたストリング」であると考えられます。 それはそうであり、AllowUnassigned旗はSHALL NOTです。設定されてください。
* in step 3, set the flag called "UseSTD3ASCIIRules";
* ステップ3では、「UseSTD3ASCIIRules」と呼ばれる旗を設定してください。
* in step 4, process each label with the "ToASCII" operation; and
* ステップ4では、"ToASCII"操作で各ラベルを処理してください。 そして
* in step 5, change all label separators to U+002E (full stop).
* ステップ5では、すべてのラベル分離符をU+002Eの(終止符)に変えてください。
When comparing DNS names for equality, conforming implementations MUST perform a case-insensitive exact match on the entire DNS name. When evaluating name constraints, conforming implementations MUST perform a case-insensitive exact match on a label-by-label basis. As noted in Section 4.2.1.10, any DNS name that may be constructed by adding labels to the left-hand side of the domain name given as the constraint is considered to fall within the indicated subtree.
平等のためにDNS名を比較するとき、実装を従わせると、大文字と小文字を区別しない完全な一致は全体のDNS名に働かなければなりません。 名前規制を評価するとき、実装を従わせると、大文字と小文字を区別しない完全な一致はラベルごとのベースに働かなければなりません。 .10、与えられたドメイン名の左側にラベルを追加することによって構成されるどんな規制が示された下位木の中で低下すると考えられるのとセクション4.2.1で同じくらい有名なDNS名。
Implementations should convert IDNs to Unicode before display. Specifically, conforming implementations should perform the conversion operation specified in Section 4 of RFC 3490, with the following clarifications:
実装はディスプレイの前にIDNsをユニコードに変換するべきです。 明確に、実装を従わせると、RFC3490のセクション4で以下の明確化で指定された変換操作は働くべきです:
* in step 1, the domain name SHALL be considered a "stored
string". That is, the AllowUnassigned flag SHALL NOT be set;
* 1、ドメイン名SHALLは中に踏みます。「保存されたストリング」であると考えられます。 それはそうであり、AllowUnassigned旗はSHALL NOTです。設定されてください。
* in step 3, set the flag called "UseSTD3ASCIIRules";
* ステップ3では、「UseSTD3ASCIIRules」と呼ばれる旗を設定してください。
Cooper, et al. Standards Track [Page 97] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[97ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
* in step 4, process each label with the "ToUnicode" operation;
and
* ステップ4では、"ToUnicode"操作で各ラベルを処理してください。 そして
* skip step 5.
* ステップ5をサボってください。
Note: Implementations MUST allow for increased space requirements for IDNs. An IDN ACE label will begin with the four additional characters "xn--" and may require as many as five ASCII characters to specify a single international character.
以下に注意してください。 実装はIDNsのための増強されたスペース要件を考慮しなければなりません。 IDN ACEラベルが4つの添字で始まる、「xn--」 最大5人のASCII文字が単独の国際的な人物を指定するのが必要であるかもしれません。
7.3. Internationalized Domain Names in Distinguished Names
7.3. 分類名における国際化ドメイン名
Domain Names may also be represented as distinguished names using domain components in the subject field, the issuer field, the subjectAltName extension, or the issuerAltName extension. As with the dNSName in the GeneralName type, the value of this attribute is defined as an IA5String. Each domainComponent attribute represents a single label. To represent a label from an IDN in the distinguished name, the implementation MUST perform the "ToASCII" label conversion specified in Section 4.1 of RFC 3490. The label SHALL be considered a "stored string". That is, the AllowUnassigned flag SHALL NOT be set.
また、ドメインNamesは、分類名として対象の分野、発行人分野、subjectAltName拡張子、またはissuerAltName拡張子にドメインコンポーネントを使用することで表されるかもしれません。 GeneralNameタイプのdNSNameのように、この属性の値はIA5Stringと定義されます。 それぞれのdomainComponent属性は単一のラベルを表します。 IDNから分類名でラベルを表すために、実装はRFC3490のセクション4.1で指定された"ToASCII"ラベル変換を実行しなければなりません。 SHALLをラベルしてください。「保存されたストリング」であると考えられます。 それはそうであり、AllowUnassigned旗はSHALL NOTです。設定されます。
Conforming implementations shall perform a case-insensitive exact match when comparing domainComponent attributes in distinguished names, as described in Section 7.2.
分類名におけるdomainComponent属性を比較するとき、実装を従わせると、大文字と小文字を区別しない完全な一致はセクション7.2で説明されるように働くものとします。
Implementations should convert ACE labels to Unicode before display. Specifically, conforming implementations should perform the "ToUnicode" conversion operation specified, as described in Section 7.2, on each ACE label before displaying the name.
実装はディスプレイの前にACEラベルをユニコードに変換するべきです。 明確に、実装を従わせると、セクション7.2で説明されるように指定された"ToUnicode"変換操作は働くべきです、名前を表示する前のそれぞれのACEラベルの上に。
7.4. Internationalized Resource Identifiers
7.4. 国際化しているリソース識別子
Internationalized Resource Identifiers (IRIs) are the internationalized complement to the Uniform Resource Identifier (URI). IRIs are sequences of characters from Unicode, while URIs are sequences of characters from the ASCII character set. [RFC3987] defines a mapping from IRIs to URIs. While IRIs are not encoded directly in any certificate fields or extensions, their mapped URIs may be included in certificates and CRLs. URIs may appear in the subjectAltName and issuerAltName extensions, name constraints extension, authority information access extension, subject information access extension, issuing distribution point extension, and CRL distribution points extension. Each of these extensions uses the GeneralName type; URIs are encoded in the uniformResourceIdentifier field in GeneralName, which is defined as type IA5String.
国際化しているResource Identifiers(IRIs)は国際化していてUniform Resource Identifier(URI)に理想的です。 IRIsはユニコードからのキャラクタの系列ですが、URIはASCII文字の組からのキャラクタの系列です。 [RFC3987]はIRIsからURIまでマッピングを定義します。 IRIsが直接どんな証明書分野や拡大でもコード化されていない間、それらの写像しているURIは証明書とCRLsに含まれるかもしれません。 URIはsubjectAltNameとissuerAltName拡張子に現れるかもしれなくて、名前規制拡大、権威情報アクセス拡張子、対象の情報アクセス拡張子、分配ポイント拡大を発行して、およびCRL分配は拡大を指します。 それぞれのこれらの拡大はGeneralNameタイプを使用します。 URIはGeneralNameのuniformResourceIdentifier分野でコード化されます。(GeneralNameはタイプIA5Stringと定義されます)。
Cooper, et al. Standards Track [Page 98] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[98ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
To accommodate IRIs in the current structure, conforming implementations MUST map IRIs to URIs as specified in Section 3.1 of [RFC3987], with the following clarifications:
実装を従わせると、現在の構造にIRIsを収容するために、IRIsは[RFC3987]のセクション3.1における指定されるとしてのURIに写像されなければなりません、以下の明確化で:
* in step 1, generate a UCS character sequence from the original
IRI format normalizing according to the NFC as specified in
Variant b (normalization according to NFC);
* ステップ1では、Variant b(NFCに従った正常化)の指定されるとしてのNFCによると、正常にされる元のIRI形式からUCSがキャラクタシーケンスであると生成してください。
* perform step 2 using the output from step 1.
* ステップ1から出力を使用することでステップ2を実行してください。
Implementations MUST NOT convert the ireg-name component before performing step 2.
ステップ2を実行する前に、実装はireg-名前コンポーネントを変換してはいけません。
Before URIs may be compared, conforming implementations MUST perform a combination of the syntax-based and scheme-based normalization techniques described in [RFC3987]. Specifically, conforming implementations MUST prepare URIs for comparison as follows:
URIが比べるかもしれない前に、実装を従わせると、[RFC3987]で説明された構文ベースの、そして、体系ベースの正常化のテクニックの組み合わせは働かなければなりません。 明確に、実装を従わせると、URIは以下の比較のために準備されなければなりません:
* Step 1: Where IRIs allow the usage of IDNs, those names MUST be
converted to ASCII Compatible Encoding as specified in Section
7.2 above.
* ステップ1: IRIsがIDNsの使用法を許容するところでは、上のセクション7.2における指定されるとしてのASCII Compatible Encodingにそれらの名前を変換しなければなりません。
* Step 2: The scheme and host are normalized to lowercase, as
described in Section 5.3.2.1 of [RFC3987].
* ステップ2: セクション5.3.2で.1[RFC3987]について説明するとき、体系とホストは、小文字で印刷するために正常にされます。
* Step 3: Perform percent-encoding normalization, as specified in
Section 5.3.2.3 of [RFC3987].
* ステップ3: .3セクション5.3.2で指定されるように正常化を何パーセントもコード化する[RFC3987]を実行してください。
* Step 4: Perform path segment normalization, as specified in
Section 5.3.2.4 of [RFC3987].
* ステップ4: セクション5.3.2で.4[RFC3987]を指定するので、経路セグメント正常化を実行してください。
* Step 5: If recognized, the implementation MUST perform scheme-
based normalization as specified in Section 5.3.3 of [RFC3987].
* ステップ5: 認識されるなら、実装は.3セクション5.3[RFC3987]における指定されるとしての体系のベースの正常化を実行しなければなりません。
Conforming implementations MUST recognize and perform scheme-based normalization for the following schemes: ldap, http, https, and ftp. If the scheme is not recognized, step 5 is omitted.
実装を従わせるのは、以下の体系のための体系ベースの正常化を認識して、実行しなければなりません: ldap、http、https、およびftp。 体系が認識されないなら、ステップ5は省略されます。
When comparing URIs for equivalence, conforming implementations shall perform a case-sensitive exact match.
等価性のためにURIを比較するとき、実装を従わせると、大文字と小文字を区別する完全な一致は働くものとします。
Implementations should convert URIs to Unicode before display. Specifically, conforming implementations should perform the conversion operation specified in Section 3.2 of [RFC3987].
実装はディスプレイの前にURIをユニコードに変換するべきです。 明確に、実装を従わせると、[RFC3987]のセクション3.2で指定された変換操作は働くべきです。
Cooper, et al. Standards Track [Page 99] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[99ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
7.5. Internationalized Electronic Mail Addresses
7.5. 国際化している電子メールアドレス
Electronic Mail addresses may be included in certificates and CRLs in the subjectAltName and issuerAltName extensions, name constraints extension, authority information access extension, subject information access extension, issuing distribution point extension, or CRL distribution points extension. Each of these extensions uses the GeneralName construct; GeneralName includes the rfc822Name choice, which is defined as type IA5String. To accommodate email addresses with internationalized domain names using the current structure, conforming implementations MUST convert the addresses into an ASCII representation.
電子メールアドレスは証明書に含まれるかもしれません、そして、subjectAltNameとissuerAltName拡張子か、名前規制拡大か、権威情報アクセス拡張子か、対象の情報アクセス拡張子か、分配ポイント拡大を発行するか、CRL分配におけるCRLsは拡大を指します。 それぞれのこれらの拡大はGeneralName構造物を使用します。 GeneralNameはrfc822Name選択を含んでいます。(それは、タイプIA5Stringと定義されます)。 実装を従わせて、国際化ドメイン名が現在の構造を使用しているEメールアドレスに対応するのはASCII表現にアドレスを変換しなければなりません。
Where the host-part (the Domain of the Mailbox) contains an internationalized name, the domain name MUST be converted from an IDN to the ASCII Compatible Encoding (ACE) format as specified in Section 7.2.
ホスト部分(MailboxのDomain)が国際化している名前を含んでいるところでは、ドメイン名をIDNからセクション7.2における指定されるとしてのASCII Compatible Encoding(ACE)形式に変換しなければなりません。
Two email addresses are considered to match if:
2つのEメールアドレスが合っていると考えられる、:
1) the local-part of each name is an exact match, AND
1) それぞれの名前の地方の部分は完全な一致、ANDです。
2) the host-part of each name matches using a case-insensitive
ASCII comparison.
2) 大文字と小文字を区別しないASCII比較を使用することでそれぞれの名前のホスト部分は合っています。
Implementations should convert the host-part of internationalized email addresses specified in these extensions to Unicode before display. Specifically, conforming implementations should perform the conversion of the host-part of the Mailbox as described in Section 7.2.
実装はディスプレイの前にこれらの拡大でユニコードに指定された国際化しているEメールアドレスのホスト部分を変換するべきです。 明確に、実装を従わせると、Mailboxのホスト部分の変換はセクション7.2で説明されるように働くべきです。
8. Security Considerations
8. セキュリティ問題
The majority of this specification is devoted to the format and content of certificates and CRLs. Since certificates and CRLs are digitally signed, no additional integrity service is necessary. Neither certificates nor CRLs need be kept secret, and unrestricted and anonymous access to certificates and CRLs has no security implications.
この仕様の大部分が証明書とCRLsの形式と内容に専念します。 証明書とCRLsがデジタルに署名されるので、どんな追加保全サービスも必要ではありません。 証明書もCRLsも秘密にされる必要はありません、そして、証明書とCRLsへの無制限で匿名のアクセスには、セキュリティ意味が全くありません。
However, security factors outside the scope of this specification will affect the assurance provided to certificate users. This section highlights critical issues to be considered by implementers, administrators, and users.
しかしながら、この仕様の範囲の外のセキュリティ要素はユーザを証明するために提供された保証に影響するでしょう。 implementers、管理者、およびユーザによって考えられるように、このセクションは重要な問題を強調します。
The procedures performed by CAs and RAs to validate the binding of the subject's identity to their public key greatly affect the assurance that ought to be placed in the certificate. Relying
彼らの公開鍵への対象のアイデンティティの結合を有効にするためにCAsとRAsによって実行された手順は証明書に置かれるべきである保証に大いに影響します。 当てにします。
Cooper, et al. Standards Track [Page 100] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[100ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
parties might wish to review the CA's certification practice statement. This is particularly important when issuing certificates to other CAs.
パーティーはCAの認証実施規定を見直したがっているかもしれません。 他のCAsに証明書を発行するとき、これは特に重要です。
The use of a single key pair for both signature and other purposes is strongly discouraged. Use of separate key pairs for signature and key management provides several benefits to the users. The ramifications associated with loss or disclosure of a signature key are different from loss or disclosure of a key management key. Using separate key pairs permits a balanced and flexible response. Similarly, different validity periods or key lengths for each key pair may be appropriate in some application environments. Unfortunately, some legacy applications (e.g., Secure Sockets Layer (SSL)) use a single key pair for signature and key management.
主要な1組の署名と他の目的の両方の使用は強くお勧めできないです。 別々の主要な組の署名とかぎ管理の使用はユーザへのいくつかの利益を提供します。 署名キーの損失か公開に関連している分岐はかぎ管理キーの損失か公開と異なっています。 別々の主要な組を使用すると、バランスのとれていてフレキシブルな応答は可能にします。 同様に、それぞれの主要な組単位の異なった有効期間かキー長がいくつかのアプリケーション環境で適切であるかもしれません。 残念ながら、いくつかのレガシーアプリケーション(例えば、セキュリティソケットレイヤー(SSL))が署名とかぎ管理に主要な1組を使用します。
The protection afforded private keys is a critical security factor. On a small scale, failure of users to protect their private keys will permit an attacker to masquerade as them or decrypt their personal information. On a larger scale, compromise of a CA's private signing key may have a catastrophic effect. If an attacker obtains the private key unnoticed, the attacker may issue bogus certificates and CRLs. Existence of bogus certificates and CRLs will undermine confidence in the system. If such a compromise is detected, all certificates issued to the compromised CA MUST be revoked, preventing services between its users and users of other CAs. Rebuilding after such a compromise will be problematic, so CAs are advised to implement a combination of strong technical measures (e.g., tamper- resistant cryptographic modules) and appropriate management procedures (e.g., separation of duties) to avoid such an incident.
秘密鍵が提供された保護はきわどいセキュリティ要素です。 小規模に、ユーザが彼らの秘密鍵を保護しないと、攻撃者がそれらのふりをするか、またはそれらの個人情報を解読することを許可するでしょう。 より大きいスケールでは、CAの個人的な署名キーの感染は壊滅的な効果を持っているかもしれません。 攻撃者が目だたない状態で秘密鍵を得るなら、攻撃者はにせの証明書とCRLsを発行するかもしれません。 にせの証明書とCRLsの存在はシステムにおける信用を損ねるでしょう。 そのような感染が検出されるなら、感染しているカリフォルニアに発行されたすべての証明書を取り消さなければなりません、他のCAsのユーザとユーザの間のサービスを防いで。 そのような感染が問題が多くなった後に再建によって、CAsがそのようなインシデントを避けるために強い技術的な程度(例えば、耐タンパーの暗号のモジュール)と適切な管理手順(例えば、義務の分離)の組み合わせを実装するようにアドバイスされます。
Loss of a CA's private signing key may also be problematic. The CA would not be able to produce CRLs or perform normal key rollover. CAs SHOULD maintain secure backup for signing keys. The security of the key backup procedures is a critical factor in avoiding key compromise.
また、CAの個人的な署名キーの損失も問題が多いかもしれません。 カリフォルニアは、CRLsを生産できませんし、正常な主要なロールオーバーを実行できないでしょう。CAs SHOULDは署名キーのために安全なバックアップを維持します。 主要なバックアップ手順のセキュリティは主要な感染を避けることにおいて重要な要素です。
The availability and freshness of revocation information affects the degree of assurance that ought to be placed in a certificate. While certificates expire naturally, events may occur during its natural lifetime that negate the binding between the subject and public key. If revocation information is untimely or unavailable, the assurance associated with the binding is clearly reduced. Relying parties might not be able to process every critical extension that can appear in a CRL. CAs SHOULD take extra care when making revocation information available only through CRLs that contain critical extensions, particularly if support for those extensions is not mandated by this profile. For example, if revocation information is supplied using a combination of delta CRLs and full CRLs, and the
取消し情報の有用性と新しさは証明書に置かれるべきである保証の度合いに影響します。 証明書は自然に期限が切れますが、イベントは対象と公開鍵の間の結合を否定する生まれながらの生涯起こるかもしれません。 取消し情報がタイミングが悪いか、または入手できないなら、結合に関連している保証は明確に抑えられます。 信用パーティーはCRLに現れることができるあらゆる重要な拡大を処理できるかもしれないというわけではありません。 取消し情報を重要な拡大を含むCRLsだけを通して利用可能にするとき、CAs SHOULDは付加的な注意を払います、特にそれらの拡大のサポートがこのプロフィールによって強制されないなら。 そして例えばデルタCRLsと完全なCRLsの組み合わせを使用することで取消し情報を提供するなら。
Cooper, et al. Standards Track [Page 101] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[101ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
delta CRLs are issued more frequently than the full CRLs, then relying parties that cannot handle the critical extensions related to delta CRL processing will not be able to obtain the most recent revocation information. Alternatively, if a full CRL is issued whenever a delta CRL is issued, then timely revocation information will be available to all relying parties. Similarly, implementations of the certification path validation mechanism described in Section 6 that omit revocation checking provide less assurance than those that support it.
デルタCRLsは完全なCRLsより頻繁に発行されて、次に、デルタCRL処理に関連する重要な拡大を扱うことができない信用パーティーは最新の取消し情報を得ることができないでしょう。 あるいはまた、CRLデルタが発行されるときはいつも、完全なCRLが発行されると、タイムリーな取消し情報は当てにしているパーティーに皆、利用可能になるでしょう。 同様に、取消しの照合を省略するセクション6で説明された証明経路合法化メカニズムの実装はそれをサポートするものより少ない保証を提供します。
The certification path validation algorithm depends on the certain knowledge of the public keys (and other information) about one or more trusted CAs. The decision to trust a CA is an important decision as it ultimately determines the trust afforded a certificate. The authenticated distribution of trusted CA public keys (usually in the form of a "self-signed" certificate) is a security critical out-of-band process that is beyond the scope of this specification.
証明経路合法化アルゴリズムは公開鍵(そして、他の情報)のおよそ1かさらに信じられたCAsに関する、ある知識によります。 結局証明書が提供された信頼を決定するとき、カリフォルニアを信じるという決定は重要な決定です。 信じられたカリフォルニア公開鍵(通常、「自己によって署名している」証明書の形の)の認証された分配はこの仕様の範囲にあるセキュリティの重要なバンドで出ているプロセスです。
In addition, where a key compromise or CA failure occurs for a trusted CA, the user will need to modify the information provided to the path validation routine. Selection of too many trusted CAs makes the trusted CA information difficult to maintain. On the other hand, selection of only one trusted CA could limit users to a closed community of users.
さらに、主要な感染かカリフォルニアの失敗が信じられたカリフォルニアに起こるところでは、ユーザは、経路合法化ルーチンに提供された情報を変更する必要があるでしょう。 あまりに多くの信じられたCAsの品揃えは信じられたカリフォルニアを維持するのが難しい情報にします。 他方では、1だけの信じられたカリフォルニアの選択はユーザをユーザの閉じている共同体に制限するかもしれません。
The quality of implementations that process certificates also affects the degree of assurance provided. The path validation algorithm described in Section 6 relies upon the integrity of the trusted CA information, and especially the integrity of the public keys associated with the trusted CAs. By substituting public keys for which an attacker has the private key, an attacker could trick the user into accepting false certificates.
また、証明書を処理する実装の品質は提供された保証の度合いに影響します。 セクション6で説明された経路合法化アルゴリズムは信じられたカリフォルニア情報の保全、および特に信じられたCAsに関連している公開鍵の保全を当てにします。 攻撃者が秘密鍵を持っている公開鍵を代入することによって、攻撃者は、ユーザが偽の証明書を受け入れるようにだますことができるでしょう。
The binding between a key and certificate subject cannot be stronger than the cryptographic module implementation and algorithms used to generate the signature. Short key lengths or weak hash algorithms will limit the utility of a certificate. CAs are encouraged to note advances in cryptology so they can employ strong cryptographic techniques. In addition, CAs SHOULD decline to issue certificates to CAs or end entities that generate weak signatures.
キーと証明書対象の間の結合は暗号のモジュール実装とアルゴリズムが以前はよく署名を生成していたより強いはずがありません。 短いキー長か弱いハッシュアルゴリズムが証明書に関するユーティリティを制限するでしょう。 CAsが強い暗号のテクニックを使うことができるように暗号理論における進歩に注意するよう奨励されます。 さらに、CAs SHOULDは、弱い署名を生成するCAsか終わりの実体に証明書を発行するのを断ります。
Inconsistent application of name comparison rules can result in acceptance of invalid X.509 certification paths or rejection of valid ones. The X.500 series of specifications defines rules for comparing distinguished names that require comparison of strings without regard
名前比較規則の無節操な適用は無効のX.509証明経路の承認か有効なものの拒絶をもたらすことができます。 仕様のX.500シリーズは関係なしでストリングの比較を必要とする分類名を比較するための規則を定義します。
Cooper, et al. Standards Track [Page 102] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[102ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
to case, character set, multi-character white space substring, or leading and trailing white space. This specification relaxes these requirements, requiring support for binary comparison at a minimum.
ケースか、文字集合か、マルチキャラクタ余白サブストリングか、先導と引きずると、スペースを空白にしてください。 2進の比較に最小限で支持を要して、この仕様はこれらの要件を弛緩します。
CAs MUST encode the distinguished name in the subject field of a CA certificate identically to the distinguished name in the issuer field in certificates issued by that CA. If CAs use different encodings, implementations might fail to recognize name chains for paths that include this certificate. As a consequence, valid paths could be rejected.
CAsは同様にカリフォルニア証明書の対象の分野でそのカリフォルニアによって発行された証明書の発行人分野の分類名に分類名をコード化しなければなりません。 CAsが異なったencodingsを使用するなら、実装はこの証明書を含んでいる経路として名前チェーンを認識しないかもしれません。 結果として、有効な経路を拒絶できました。
In addition, name constraints for distinguished names MUST be stated identically to the encoding used in the subject field or subjectAltName extension. If not, then name constraints stated as excludedSubtrees will not match and invalid paths will be accepted and name constraints expressed as permittedSubtrees will not match and valid paths will be rejected. To avoid acceptance of invalid paths, CAs SHOULD state name constraints for distinguished names as permittedSubtrees wherever possible.
さらに、同様に対象の分野かsubjectAltName拡張子に使用されるコード化に分類名の名前規制を述べなければなりません。 そうでなければ、次に、excludedSubtreesが合わないので述べられた名前規制と無効の経路を受け入れるでしょう、そして、permittedSubtreesが合わないので言い表された名前規制と有効な経路を拒絶するでしょう。 無効の経路の承認を避けるために、CAs SHOULDはpermittedSubtreesとしてどこでも、可能であるところに分類名の名前規制を述べます。
In general, using the nameConstraints extension to constrain one name form (e.g., DNS names) offers no protection against use of other name forms (e.g., electronic mail addresses).
一般に、1つの名前フォーム(例えば、DNS名)を抑制するのにnameConstraints拡張子を使用すると、ノー・プロテクションは他の名前フォーム(例えば、電子メールアドレス)の使用に対して提供されます。
While X.509 mandates that names be unambiguous, there is a risk that two unrelated authorities will issue certificates and/or CRLs under the same issuer name. As a means of reducing problems and security issues related to issuer name collisions, CA and CRL issuer names SHOULD be formed in a way that reduces the likelihood of name collisions. Implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same name. At a minimum, implementations validating CRLs MUST ensure that the certification path of a certificate and the CRL issuer certification path used to validate the certificate terminate at the same trust anchor.
X.509は、名前が明白であることを強制しますが、2つの関係ない当局が同じ発行人名の下で証明書、そして/または、CRLsを発行するリスクがあります。 発行人がSHOULDと命名する発行人名前衝突、カリフォルニア、およびCRLに関連する問題と安全保障問題を減少させる手段として、名前衝突の見込みを減少させる方法で形成されてください。 Implementersは同じ名前がある複数の関係ないCAsとCRL発行人の可能な存在を考慮に入れるはずです。 最小限では、CRLsを有効にする実装は、証明書の証明経路と証明書を有効にするのに使用されるCRL発行人証明経路が同じ信頼アンカーで終わるのを確実にしなければなりません。
While the local-part of an electronic mail address is case sensitive [RFC2821], emailAddress attribute values are not case sensitive [RFC2985]. As a result, there is a risk that two different email addresses will be treated as the same address when the matching rule for the emailAddress attribute is used, if the email server exploits the case sensitivity of mailbox local-parts. Implementers should not include an email address in the emailAddress attribute if the email server that hosts the email address treats the local-part of email addresses as case sensitive.
電子メールアドレスの地方の部分は大文字と小文字を区別していますが[RFC2821]、emailAddress属性値は大文字と小文字を区別していません[RFC2985]。 その結果、2つの異なったEメールアドレスがメールサーバがケースを利用するならemailAddress属性のための合っている規則が使用されている同じくらいとして扱われたアドレスがメールボックスの地方の部分の感度であったならそうするリスクがあります。 Eメールアドレスをホスティングするメールサーバが大文字と小文字を区別するとしてEメールアドレスの地方の部分を扱うなら、ImplementersはemailAddress属性にEメールアドレスを含んでいるはずがありません。
Implementers should be aware of risks involved if the CRL distribution points or authority information access extensions of
Implementersは分配ポイントか権威情報が拡大にアクセスするCRLであるなら伴われる危険を意識しているべきです。
Cooper, et al. Standards Track [Page 103] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[103ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
corrupted certificates or CRLs contain links to malicious code. Implementers should always take the steps of validating the retrieved data to ensure that the data is properly formed.
改悪された証明書かCRLsが悪質なコードへのリンクを含んでいます。 Implementersはいつもデータが適切に形成されるのを保証するために検索されたデータを有効にする方法を採るはずです。
When certificates include a cRLDistributionPoints extension with an https URI or similar scheme, circular dependencies can be introduced. The relying party is forced to perform an additional path validation in order to obtain the CRL required to complete the initial path validation! Circular conditions can also be created with an https URI (or similar scheme) in the authorityInfoAccess or subjectInfoAccess extensions. At worst, this situation can create unresolvable dependencies.
証明書がhttps URIか同様の体系があるcRLDistributionPoints拡張子を含んでいるとき、円形の依存を導入できます。 信用パーティーは、初期の経路合法化を終了しなければならなかったCRLを入手するためにやむを得ず追加経路合法化を実行します! また、https URI(または、同様の体系)でauthorityInfoAccessかsubjectInfoAccess拡張子で円形の状態を引き起こすことができます。 最悪の場合は、この状況は「非-溶解性」の依存を引き起こすことができます。
CAs SHOULD NOT include URIs that specify https, ldaps, or similar schemes in extensions. CAs that include an https URI in one of these extensions MUST ensure that the server's certificate can be validated without using the information that is pointed to by the URI. Relying parties that choose to validate the server's certificate when obtaining information pointed to by an https URI in the cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess extensions MUST be prepared for the possibility that this will result in unbounded recursion.
CAs SHOULDは拡大でhttps、ldaps、または同様の体系を指定するURIを含んでいません。 これらの拡大の1つでhttps URIを含んでいるCAsは、URIによって示される情報を使用しないでサーバの証明書を有効にすることができるのを確実にしなければなりません。 cRLDistributionPoints、authorityInfoAccess、またはsubjectInfoAccess拡張子でhttps URIによって示された情報を得るときサーバの証明書を有効にするのを選ぶ信用パーティーはこれが限りない再帰をもたらす可能性のために用意ができていなければなりません。
Self-issued certificates provide CAs with one automated mechanism to indicate changes in the CA's operations. In particular, self-issued certificates may be used to implement a graceful change-over from one non-compromised CA key pair to the next. Detailed procedures for "CA key update" are specified in [RFC4210], where the CA protects its new public key using its previous private key and vice versa using two self-issued certificates. Conforming client implementations will process the self-issued certificate and determine whether certificates issued under the new key may be trusted. Self-issued certificates MAY be used to support other changes in CA operations, such as additions to the CA's policy set, using similar procedures.
自己によって発行された証明書は、CAの操作における変化を示すために1つの自動化されたメカニズムをCAsに提供します。 特定の、そして、自己によって発行された証明書では、非感染している主要な1カリフォルニア組から次の組までオーバー変化すると優雅な実装するのに使用されるかもしれません。 「カリフォルニアの主要なアップデート」のための詳細手順書は[RFC4210]で指定されます。そこでは、カリフォルニアが、逆もまた同様に2通の自己によって発行された証明書を使用することで前の秘密鍵を使用することで新しい公開鍵を保護します。 クライアント実装を従わせるのは、自己によって発行された証明書を処理して、新しいキーの下で発行された証明書が信じられるかもしれないかどうか決定するでしょう。 自己によって発行された証明書はカリフォルニアの操作における他の変化をサポートするのに使用されるかもしれません、CAの方針セットへの追加などのように、同様の手順を用いて。
Some legacy implementations support names encoded in the ISO 8859-1 character set (Latin1String) [ISO8859] but tag them as TeletexString. TeletexString encodes a larger character set than ISO 8859-1, but it encodes some characters differently. The name comparison rules specified in Section 7.1 assume that TeletexStrings are encoded as described in the ASN.1 standard. When comparing names encoded using the Latin1String character set, false positives and negatives are possible.
いくつかのレガシー実装が、ISO8859-1文字集合(Latin1String)[ISO8859]でコード化された名前をサポートしますが、TeletexStringとしてそれらにタグ付けをします。 TeletexStringはISO8859-1より大きい文字集合をコード化しますが、それは何人かのキャラクタを異なってコード化します。 セクション7.1で指定された名前比較規則は、TeletexStringsがASN.1規格で説明されるようにコード化されると仮定します。 Latin1String文字集合を使用することでコード化された名前を比較するとき、無病誤診とネガは可能です。
When strings are mapped from internal representations to visual representations, sometimes two different strings will have the same or similar visual representations. This can happen for many different reasons, including use of similar glyphs and use of
ストリングが内部の表現から視覚表現まで写像されるとき、2個の異なったストリングには時々、同じであるか同様の視覚表現があるでしょう。 これは多くの異なった理由、同様の使用がglyphsする包含、および使用のために起こることができます。
Cooper, et al. Standards Track [Page 104] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[104ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
composed characters (such as e + ' equaling U+00E9, the Korean composed characters, and vowels above consonant clusters in certain languages). As a result of this situation, people doing visual comparisons between two different names may think they are the same when in fact they are not. Also, people may mistake one string for another. Issuers of certificates and relying parties both need to be aware of this situation.
落ち着いた性格(9'e+等しさU+00Eや、韓国の落ち着いた性格や、上の子音が、ある言語でクラスタリングさせる母音などの)、' この状況の結果、2つの異なった名前の目視比較をしている人々は、事実上、同じでないときに、それらが同じであると考えるかもしれません。 また、人々は1個のストリングを別のものに間違えるかもしれません。 証明書と信用パーティーの発行人は、ともにこの状況を知る必要があります。
9. IANA Considerations
9. IANA問題
Extensions in certificates and CRLs are identified using object identifiers. The objects are 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.
証明書とCRLsでの拡大は、オブジェクト識別子を使用することで特定されます。 オブジェクトはIANAによってPKIX作業部会へ代表として派遣されたアークで定義されます。 IANAによるさらなるどんな動作もこのドキュメントかどんな予期されたアップデートにも必要ではありません。
10. Acknowledgments
10. 承認
Warwick Ford participated with the authors in some of the design team meetings that directed development of this document. The design team's efforts were guided by contributions from Matt Crawford, Tom Gindin, Steve Hanna, Stephen Henson, Paul Hoffman, Takashi Ito, Denis Pinkas, and Wen-Cheng Wang.
ウォリックフォードは作者と共にこのドキュメントの開発を指示したデザインチーム会議のいくつかに参加しました。 デザインチームの取り組みはマット・クロフォードからの貢献で誘導されました、トムGindin、スティーブ・ハンナ、スティーブン・ヘンソン、ポール・ホフマン、Takashi伊藤、デニス・ピンカス、およびWen-チェンワング。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] ブレーデン、R.、エド、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure: Operational Protocols: FTP and HTTP", RFC
2585, May 1999.
[RFC2585] Housley、R.、およびP.ホフマン、「インターネットX.509公開鍵基盤:」 操作上のプロトコル: 「FTPとHTTP」(RFC2585)は1999がそうするかもしれません。
Cooper, et al. Standards Track [Page 105] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[105ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[RFC2797] Myers, M., Liu, X., Schaad, J., and J. Weinstein,
"Certificate Management Messages over CMS", RFC 2797,
April 2000.
2000年4月の[RFC2797]マイアーズとM.とリュウとX.とSchaad、J.とJ.ワインスタイン、「cmの上の証明書管理メッセージ」RFC2797。
[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
2821, April 2001.
[RFC2821] Klensin、J.、エド、「簡単なメール転送プロトコル」、RFC2821、4月2001日
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[RFC3454] ホフマンとP.とM.Blanchet、「国際化しているストリング("stringprep")の準備」、RFC3454、2002年12月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3490] Faltstrom、P.、ホフマン、P.、およびA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC3986] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987] DuerstとM.とM.Suignard、「国際化しているリソース識別子(虹彩)」、RFC3987、2005年1月。
[RFC4516] Smith, M., Ed., and T. Howes, "Lightweight Directory
Access Protocol (LDAP): Uniform Resource Locator", RFC
4516, June 2006.
[RFC4516] エドスミス、M.、T.ハウズ、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「Uniform Resource Locator」、RFC4516、2006年6月。
[RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Internationalized String Preparation", RFC 4518,
June 2006.
[RFC4518] Zeilenga、K.、「軽量のディレクトリアクセスは以下について議定書の中で述べ(LDAP)」。 「国際化しているストリング準備」、RFC4518、2006年6月。
[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP) Schema Definitions for X.509 Certificates", RFC
4523, June 2006.
[RFC4523]Zeilenga、K.、「X.509証明書のためのライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)図式定義」、RFC4523、2006年6月。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
[RFC4632] フラーとV.とT.李、「以下を掘る(CIDR)階級のない相互ドメイン」 「インターネットアドレス課題と集合は計画している」BCP122、RFC4632、2006年8月。
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation.
[X.680]ITU-T推薦X.680(2002)| ISO/IEC8824-1: 2002、情報技術--抽象的なSyntax Notation One(ASN.1): 基本的な記法の仕様。
Cooper, et al. Standards Track [Page 106] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[106ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
[X.690]ITU-T推薦X.690(2002)| ISO/IEC8825-1: 2002、情報技術--ASN.1符号化規則: 基本的なコード化の仕様は(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)を統治します。
11.2. Informative References
11.2. 有益な参照
[ISO8859] ISO/IEC 8859-1:1998. Information technology -- 8-bit
single-byte coded graphic character sets -- Part 1: Latin
alphabet No. 1.
[ISO8859]ISO/IEC8859-1:1998。 情報技術--8ビットの単一のバイトコード化された図形文字セット--第1部: ローマ字No.1。
[ISO10646] ISO/IEC 10646:2003. Information technology -- Universal
Multiple-Octet Coded Character Set (UCS).
[ISO10646]ISO/IEC10646:2003。 情報技術--普遍的なMultiple-八重奏Coded文字コード(UCS)。
[NFC] Davis, M. and M. Duerst, "Unicode Standard Annex #15:
Unicode Normalization Forms", October 2006,
<http://www.unicode.org/reports/tr15/>.
[NFC] デイヴィス、M.、およびM.Duerst、「ユニコード規格は#15、を付加します」。 「ユニコード正常化フォーム」、2006年10月、<http://www.unicode.org/reports/tr15/>。
[RFC1422] Kent, S., "Privacy Enhancement for Internet Electronic
Mail: Part II: Certificate-Based Key Management", RFC
1422, February 1993.
[RFC1422]ケント、S.、「インターネット電子メールのためのプライバシー増進:」 パートII: 「証明書ベースのKey Management」、RFC1422、1993年2月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年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.、および一人で生活して、「インターネットX.509公開鍵基盤の証明書とCRLは輪郭を描く」D.、RFC2459(1999年1月)。
[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.、ガリペリン、S.、およびC.アダムス、「X.509のインターネットの公開鍵暗号基盤のオンライン証明書状態は議定書を作ります--OCSP」、RFC2560、1999年6月。
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985,
November 2000.
[RFC2985] ニストロム、M.、およびB.Kaliski、「PKCS#9:」 選択されたオブジェクトは属します、そして、属性は2000年11月にバージョン2インチ、RFC2985をタイプします。
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, August 2001.
[RFC3161] アダムス、C.、カイン、P.、ピンカス、D.、およびR.Zuccherato、「インターネットX.509公開鍵暗号基盤タイムスタンププロトコル(ティースプーンフル)」、RFC3161(2001年8月)。
[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、「インターネットX.509公開鍵暗号基盤証明書と証明書取消しのためのアルゴリズムと識別子は(CRL)プロフィールをリストアップします」、RFC3279、2002年4月。
Cooper, et al. Standards Track [Page 107] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[107ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3280] Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(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、および「中のインターネットX.509公開鍵暗号基盤CertificateとCertificate Revocation List(CRL)が輪郭を描く使用のためのRSA Cryptographyのための追加AlgorithmsとIdentifiers」、RFC4055(2005年6月)
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC4120]ヌーマン、C.、ユー、T.、ハートマン、S.、およびK.レイバーン、「ケルベロスネットワーク認証サービス(V5)」、RFC4120 2005年7月。
[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210, September 2005.
[RFC4210] アダムス、C.、ファレル、S.、Kause、T.、およびT.Mononen、「インターネットX.509公開鍵暗号基盤証明書経営者側は(CMP)について議定書の中で述べます」、RFC4210、2005年9月。
[RFC4325] Santesson, S. and R. Housley, "Internet X.509 Public Key
Infrastructure Authority Information Access Certificate
Revocation List (CRL) Extension", RFC 4325, December 2005.
[RFC4325] SantessonとS.とR.Housley、「インターネットX.509公開鍵暗号基盤権威情報アクセス証明書失効リスト(CRL)拡大」、RFC4325、2005年12月。
[RFC4491] Leontiev, S., Ed., and D. Shefanovski, Ed., "Using the
GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
Algorithms with the Internet X.509 Public Key
Infrastructure Certificate and CRL Profile", RFC 4491, May
2006.
[RFC4491]レオーンチエフ、S.(エド)、およびD.Shefanovski(エド)、「インターネットX.509公開鍵暗号基盤証明書とCRLプロフィールがあるGOST R34.10-94、GOST R34.10-2001、およびGOST R34.11-94アルゴリズムを使用します」、RFC4491は2006がそうするかもしれません。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, June
2006.
[RFC4510] Zeilenga、K.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「仕様書ロードマップ」、RFC4510、2006年6月。
[RFC4512] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June
2006.
[RFC4512] Zeilenga、K.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「ディレクトリ情報モデル」、RFC4512、2006年6月。
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names", RFC
4514, June 2006.
[RFC4514] Zeilenga、K.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「分類名のストリング表現」、RFC4514、2006年6月。
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol
(LDAP): Schema for User Applications", RFC 4519, June
2006.
[RFC4519] Sciberras、A.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「ユーザアプリケーションのための図式」、RFC4519、2006年6月。
Cooper, et al. Standards Track [Page 108] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[108ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
[RFC4630] Housley, R. and S. Santesson, "Update to DirectoryString
Processing in the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile", RFC 4630, August 2006.
[RFC4630]Housley(R.とS.Santesson)は「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)プロフィールで処理をDirectoryStringにアップデートします」、RFC4630、2006年8月。
[X.500] ITU-T Recommendation X.500 (2005) | ISO/IEC 9594-1:2005,
Information technology - Open Systems Interconnection -
The Directory: Overview of concepts, models and services.
[X.500]ITU-T推薦X.500(2005)| 情報技術--オープン・システム・インターコネクション--ISO/IEC9594-1:2005、ディレクトリ: 概念の、そして、モデルの、そして、サービスの概要。
[X.501] ITU-T Recommendation X.501 (2005) | ISO/IEC 9594-2:2005,
Information technology - Open Systems Interconnection -
The Directory: Models.
[X.501]ITU-T推薦X.501(2005)| 情報技術--オープン・システム・インターコネクション--ISO/IEC9594-2:2005、ディレクトリ: モデル。
[X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005,
Information technology - Open Systems Interconnection -
The Directory: Public-key and attribute certificate
frameworks.
[X.509]ITU-T推薦X.509(2005)| 情報技術--オープン・システム・インターコネクション--ISO/IEC9594-8:2005、ディレクトリ: 公開鍵と属性はフレームワークを証明します。
[X.520] ITU-T Recommendation X.520 (2005) | ISO/IEC 9594-6:2005,
Information technology - Open Systems Interconnection -
The Directory: Selected attribute types.
[X.520]ITU-T推薦X.520(2005)| 情報技術--オープン・システム・インターコネクション--ISO/IEC9594-6:2005、ディレクトリ: 属性タイプを選びました。
[X.660] ITU-T Recommendation X.660 (2004) | ISO/IEC 9834-1:2005,
Information technology - Open Systems Interconnection -
Procedures for the operation of OSI Registration
Authorities: General procedures, and top arcs of the ASN.1
Object Identifier tree.
[X.660]ITU-T推薦X.660(2004)| ISO/IEC9834-1: 情報技術--オープン・システム・インターコネクション--2005、OSI Registration Authoritiesの操作のための手順: 基本手順、およびASN.1Object Identifier木のトップアーク。
[X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002,
Information technology - Abstract Syntax Notation One
(ASN.1): Parameterization of ASN.1 specifications.
[X.683]ITU-T推薦X.683(2002)| ISO/IEC8824-4: 2002、情報技術--抽象的なSyntax Notation One(ASN.1): ASN.1仕様のパラメタリゼーション。
[X9.55] ANSI X9.55-1997, Public Key Cryptography for the Financial
Services Industry: Extensions to Public Key Certificates
and Certificate Revocation Lists, January 1997.
[X9.55]ANSI X9.55-1997、金融サービス業界のための公開鍵暗号: 公開鍵証明書への拡大と証明書失効リスト、1997年1月。
Cooper, et al. Standards Track [Page 109] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[109ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
Appendix A. Pseudo-ASN.1 Structures and OIDs
付録A.の疑似ASN.1の構造とOIDs
This appendix describes data objects used by conforming PKI components in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 UNIVERSAL Types UniversalString, BMPString, and UTF8String.
この付録が中でPKIの部品を従わせることによって使用されるデータ・オブジェクトについて説明する、「ASN.1のようである、」 構文。 この構文は1988年のハイブリッドであり、1993ASN.1は構文です。 1988ASN.1構文は1993UNIVERSAL Types UniversalString、BMPString、およびUTF8Stringと共に増大します。
The ASN.1 syntax does not permit the inclusion of type statements in the ASN.1 module, and the 1993 ASN.1 standard does not permit use of the new UNIVERSAL types in modules using the 1988 syntax. As a result, this module does not conform to either version of the ASN.1 standard.
ASN.1構文はASN.1モジュールでの型宣言文の包含を可能にしません、そして、.1規格がする1993ASNは1988年の構文を使用することでモジュールにおける新しいUNIVERSALタイプの使用を可能にしません。 その結果、このモジュールはASN.1規格のどちらのバージョンにも従いません。
This appendix may be converted into 1988 ASN.1 by replacing the definitions for the UNIVERSAL Types with the 1988 catch-all "ANY".
この付録は、「少しも」UNIVERSAL Typesのための定義を1988年のキャッチにすべて、取り替えることによって、1988ASN.1に変換されるかもしれません。
A.1. Explicitly Tagged Module, 1988 Syntax
A.1。 明らかにタグ付けををされたモジュール、1988年の構文
PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) }
PKIX1Explicit88iso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1明白な(18)
DEFINITIONS EXPLICIT TAGS ::=
定義、明白なタグ:、:=
BEGIN
始まってください。
-- EXPORTS ALL --
-- すべてをエクスポートします--
-- IMPORTS NONE --
-- なにもインポートしません--
-- UNIVERSAL Types defined in 1993 and 1998 ASN.1 -- and required by this specification
-- UNIVERSAL Typesは1993年と1998年にASN.1を定義しました--そして、この仕様が必要です。
UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
-- UniversalString is defined in ASN.1:1993
UniversalString:、:= [UNIVERSAL28]IMPLICIT OCTET STRING--UniversalStringは1993年にASN.1:定義されます。
BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
-- BMPString is the subtype of UniversalString and models
-- the Basic Multilingual Plane of ISO/IEC 10646
BMPString:、:= [UNIVERSAL30] ISO/IEC10646のBMPStringがUniversalStringとモデルの「副-タイプ」であるというIMPLICIT OCTET STRING基本多言語水準
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The content of this type conforms to RFC 3629.
UTF8String:、:= [UNIVERSAL12] IMPLICIT OCTET STRING--このタイプの内容はRFC3629に従います。
-- PKIX specific OIDs
-- PKIXの特定のOIDs
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
イド-pkix OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)
Cooper, et al. Standards Track [Page 110] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[110ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
-- PKIX arcs
-- PKIXアーク
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
-- arc for private certificate extensions
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
-- arc for policy qualifier types
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
-- arc for extended key purpose OIDS
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
-- arc for access descriptors
イド-pe OBJECT IDENTIFIER:、:= イド-pkix1--兵卒のためのアークは拡大イド-qt OBJECT IDENTIFIERを証明します:、:= イド-pkix2--方針資格を与える人のためのアークはイド-kp OBJECT IDENTIFIERをタイプします:、:= イド-pkix3--拡張キーのためのアークはOIDSイド広告OBJECT IDENTIFIERを目標とします:、:= イド-pkix48--アクセス記述子のためのアーク
-- policyQualifierIds for Internet policy qualifiers
-- インターネット方針資格を与える人のためのpolicyQualifierIds
id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
-- OID for CPS qualifier
id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
-- OID for user notice qualifier
イド-qt-cps OBJECT IDENTIFIER:、:= イド-qt1--、CPS資格を与える人イド-qt-unotice OBJECT IDENTIFIERのためのOID:、:= イド-qt2--ユーザ通知資格を与える人のためのOID
-- access descriptor definitions
-- アクセス記述子定義
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
イド広告ocsp OBJECT IDENTIFIER、:、:= イド広告1、イド広告caIssuers OBJECT IDENTIFIER、:、:= イド広告2、イド広告timeStamping OBJECT IDENTIFIER、:、:= イド広告3、イド広告caRepository OBJECT IDENTIFIER、:、:= イド広告5
-- attribute data types
-- 属性データ型
Attribute ::= SEQUENCE {
type AttributeType,
values SET OF AttributeValue }
-- at least one value is required
以下を結果と考えてください:= SEQUENCEはAttributeType、値のSET OF AttributeValueをタイプします--少なくとも1つの値が必要です。
AttributeType ::= OBJECT IDENTIFIER
AttributeType:、:= オブジェクト識別子
AttributeValue ::= ANY -- DEFINED BY AttributeType
AttributeValue:、:= いずれ--AttributeTypeによって定義されます。
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
AttributeTypeAndValue:、:= 系列AttributeType、値のAttributeValueをタイプしてください。
-- suggested naming attributes: Definition of the following -- information object set may be augmented to meet local -- requirements. Note that deleting members of the set may -- prevent interoperability with conforming implementations. -- presented in pairs: the AttributeType followed by the -- type definition for the corresponding AttributeValue
-- 提案された命名属性: 以下の定義--情報オブジェクトセットは地方で会うために増大するかもしれません--要件。 セットのメンバーを削除するのがそうするかもしれないことに注意してください--実装を従わせるのに相互運用性を防いでください。 -- 組で提示される: AttributeTypeが続いた、--対応するAttributeValueのために定義をタイプしてください
Cooper, et al. Standards Track [Page 111] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[111ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
-- Arc for standard naming attributes
-- 標準の命名属性のためのアーク
id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
イド、-、OBJECT IDENTIFIER:、:= 共同iso-ccitt(2) ds(5)4
-- Naming attributes of type X520name
-- タイプの属性をX520nameと命名します。
id-at-name AttributeType ::= { id-at 41 }
id-at-surname AttributeType ::= { id-at 4 }
id-at-givenName AttributeType ::= { id-at 42 }
id-at-initials AttributeType ::= { id-at 43 }
id-at-generationQualifier AttributeType ::= { id-at 44 }
名前におけるイドAttributeType:、:= イド、-、41、姓におけるイドAttributeType:、:= イド、-、4、givenName AttributeTypeのイド:、:= イド、-、42、イニシャルにおけるイドAttributeType:、:= イド、-、43、generationQualifier AttributeTypeのイド:、:= イド、-、44
-- Naming attributes of type X520Name:
-- X520name ::= DirectoryString (SIZE (1..ub-name))
--
-- Expanded to avoid parameterized type:
X520name ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-name)),
printableString PrintableString (SIZE (1..ub-name)),
universalString UniversalString (SIZE (1..ub-name)),
utf8String UTF8String (SIZE (1..ub-name)),
bmpString BMPString (SIZE (1..ub-name)) }
-- タイプX520Nameの命名属性: -- X520name:、:= DirectoryString(SIZE(1..ub-名前))----parameterizedタイプを避けるために、広げられます: X520name:、:= 選択teletexString TeletexString(サイズ(1..ub-名前))、printableString PrintableString(サイズ(1..ub-名前))、universalString UniversalString(サイズ(1..ub-名前))、utf8String UTF8String(サイズ(1..ub-名前))、bmpString BMPString(サイズ(1..ub-名前))
-- Naming attributes of type X520CommonName
-- タイプの属性をX520CommonNameと命名します。
id-at-commonName AttributeType ::= { id-at 3 }
commonName AttributeTypeのイド:、:= イド、-、3
-- Naming attributes of type X520CommonName:
-- X520CommonName ::= DirectoryName (SIZE (1..ub-common-name))
--
-- Expanded to avoid parameterized type:
X520CommonName ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-common-name)),
printableString PrintableString (SIZE (1..ub-common-name)),
universalString UniversalString (SIZE (1..ub-common-name)),
utf8String UTF8String (SIZE (1..ub-common-name)),
bmpString BMPString (SIZE (1..ub-common-name)) }
-- タイプX520CommonNameの命名属性: -- X520CommonName:、:= DirectoryName(SIZE(1..ub-一般名))----parameterizedタイプを避けるために、広げられます: X520CommonName:、:= 選択teletexString TeletexString(サイズ(1..ub-一般名))、printableString PrintableString(サイズ(1..ub-一般名))、universalString UniversalString(サイズ(1..ub-一般名))、utf8String UTF8String(サイズ(1..ub-一般名))、bmpString BMPString(サイズ(1..ub-一般名))
Cooper, et al. Standards Track [Page 112] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[112ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
-- Naming attributes of type X520LocalityName
-- タイプの属性をX520LocalityNameと命名します。
id-at-localityName AttributeType ::= { id-at 7 }
localityName AttributeTypeのイド:、:= イド、-、7
-- Naming attributes of type X520LocalityName:
-- X520LocalityName ::= DirectoryName (SIZE (1..ub-locality-name))
--
-- Expanded to avoid parameterized type:
X520LocalityName ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-locality-name)),
printableString PrintableString (SIZE (1..ub-locality-name)),
universalString UniversalString (SIZE (1..ub-locality-name)),
utf8String UTF8String (SIZE (1..ub-locality-name)),
bmpString BMPString (SIZE (1..ub-locality-name)) }
-- タイプX520LocalityNameの命名属性: -- X520LocalityName:、:= DirectoryName(SIZE(1..ub場所名))----parameterizedタイプを避けるために、広げられます: X520LocalityName:、:= 選択teletexString TeletexString(サイズ(1..ub場所名))、printableString PrintableString(サイズ(1..ub場所名))、universalString UniversalString(サイズ(1..ub場所名))、utf8String UTF8String(サイズ(1..ub場所名))、bmpString BMPString(サイズ(1..ub場所名))
-- Naming attributes of type X520StateOrProvinceName
-- タイプの属性をX520StateOrProvinceNameと命名します。
id-at-stateOrProvinceName AttributeType ::= { id-at 8 }
stateOrProvinceName AttributeTypeのイド:、:= イド、-、8
-- Naming attributes of type X520StateOrProvinceName:
-- X520StateOrProvinceName ::= DirectoryName (SIZE (1..ub-state-name))
--
-- Expanded to avoid parameterized type:
X520StateOrProvinceName ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-state-name)),
printableString PrintableString (SIZE (1..ub-state-name)),
universalString UniversalString (SIZE (1..ub-state-name)),
utf8String UTF8String (SIZE (1..ub-state-name)),
bmpString BMPString (SIZE (1..ub-state-name)) }
-- タイプX520StateOrProvinceNameの命名属性: -- X520StateOrProvinceName:、:= DirectoryName(SIZE(1..ub州の名))----parameterizedタイプを避けるために、広げられます: X520StateOrProvinceName:、:= 選択teletexString TeletexString(サイズ(1..ub州の名))、printableString PrintableString(サイズ(1..ub州の名))、universalString UniversalString(サイズ(1..ub州の名))、utf8String UTF8String(サイズ(1..ub州の名))、bmpString BMPString(サイズ(1..ub州の名))
Cooper, et al. Standards Track [Page 113] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[113ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
-- Naming attributes of type X520OrganizationName
-- タイプの属性をX520OrganizationNameと命名します。
id-at-organizationName AttributeType ::= { id-at 10 }
organizationName AttributeTypeのイド:、:= イド、-、10
-- Naming attributes of type X520OrganizationName:
-- X520OrganizationName ::=
-- DirectoryName (SIZE (1..ub-organization-name))
--
-- Expanded to avoid parameterized type:
X520OrganizationName ::= CHOICE {
teletexString TeletexString
(SIZE (1..ub-organization-name)),
printableString PrintableString
(SIZE (1..ub-organization-name)),
universalString UniversalString
(SIZE (1..ub-organization-name)),
utf8String UTF8String
(SIZE (1..ub-organization-name)),
bmpString BMPString
(SIZE (1..ub-organization-name)) }
-- タイプX520OrganizationNameの命名属性: -- X520OrganizationName:、:= -- DirectoryName(SIZE(組織が命名する1..ub))----parameterizedタイプを避けるために、広げられます: X520OrganizationName:、:= 選択teletexString TeletexString(サイズ(組織が命名する1..ub))、printableString PrintableString(サイズ(組織が命名する1..ub))、universalString UniversalString(サイズ(組織が命名する1..ub))、utf8String UTF8String(サイズ(組織が命名する1..ub))、bmpString BMPString(サイズ(組織が命名する1..ub))
-- Naming attributes of type X520OrganizationalUnitName
-- タイプの属性をX520OrganizationalUnitNameと命名します。
id-at-organizationalUnitName AttributeType ::= { id-at 11 }
organizationalUnitName AttributeTypeのイド:、:= イド、-、11
-- Naming attributes of type X520OrganizationalUnitName:
-- X520OrganizationalUnitName ::=
-- DirectoryName (SIZE (1..ub-organizational-unit-name))
--
-- Expanded to avoid parameterized type:
X520OrganizationalUnitName ::= CHOICE {
teletexString TeletexString
(SIZE (1..ub-organizational-unit-name)),
printableString PrintableString
(SIZE (1..ub-organizational-unit-name)),
universalString UniversalString
(SIZE (1..ub-organizational-unit-name)),
utf8String UTF8String
(SIZE (1..ub-organizational-unit-name)),
bmpString BMPString
(SIZE (1..ub-organizational-unit-name)) }
-- タイプX520OrganizationalUnitNameの命名属性: -- X520OrganizationalUnitName:、:= -- DirectoryName(SIZE(組織的なユニットが命名する1..ub))----parameterizedタイプを避けるために、広げられます: X520OrganizationalUnitName:、:= 選択teletexString TeletexString(サイズ(組織的なユニットが命名する1..ub))、printableString PrintableString(サイズ(組織的なユニットが命名する1..ub))、universalString UniversalString(サイズ(組織的なユニットが命名する1..ub))、utf8String UTF8String(サイズ(組織的なユニットが命名する1..ub))、bmpString BMPString(サイズ(組織的なユニットが命名する1..ub))
Cooper, et al. Standards Track [Page 114] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[114ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
-- Naming attributes of type X520Title
-- タイプの属性をX520Titleと命名します。
id-at-title AttributeType ::= { id-at 12 }
タイトルにおけるイドAttributeType:、:= イド、-、12
-- Naming attributes of type X520Title:
-- X520Title ::= DirectoryName (SIZE (1..ub-title))
--
-- Expanded to avoid parameterized type:
X520Title ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-title)),
printableString PrintableString (SIZE (1..ub-title)),
universalString UniversalString (SIZE (1..ub-title)),
utf8String UTF8String (SIZE (1..ub-title)),
bmpString BMPString (SIZE (1..ub-title)) }
-- タイプX520Titleの命名属性: -- X520Title:、:= DirectoryName(SIZE(1..ub-タイトル))----parameterizedタイプを避けるために、広げられます: X520Title:、:= 選択teletexString TeletexString(サイズ(1..ub-タイトル))、printableString PrintableString(サイズ(1..ub-タイトル))、universalString UniversalString(サイズ(1..ub-タイトル))、utf8String UTF8String(サイズ(1..ub-タイトル))、bmpString BMPString(サイズ(1..ub-タイトル))
-- Naming attributes of type X520dnQualifier
-- タイプの属性をX520dnQualifierと命名します。
id-at-dnQualifier AttributeType ::= { id-at 46 }
dnQualifier AttributeTypeのイド:、:= イド、-、46
X520dnQualifier ::= PrintableString
X520dnQualifier:、:= PrintableString
-- Naming attributes of type X520countryName (digraph from IS 3166)
-- タイプの属性をX520countryNameと命名します。(連字、3166です)。
id-at-countryName AttributeType ::= { id-at 6 }
countryName AttributeTypeのイド:、:= イド、-、6
X520countryName ::= PrintableString (SIZE (2))
X520countryName:、:= PrintableString(サイズ(2))
-- Naming attributes of type X520SerialNumber
-- タイプの属性をX520SerialNumberと命名します。
id-at-serialNumber AttributeType ::= { id-at 5 }
serialNumber AttributeTypeのイド:、:= イド、-、5
X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number))
X520SerialNumber:、:= PrintableString(サイズ(1..ub-通し番号))
-- Naming attributes of type X520Pseudonym
-- タイプの属性をX520Pseudonymと命名します。
id-at-pseudonym AttributeType ::= { id-at 65 }
匿名におけるイドAttributeType:、:= イド、-、65
-- Naming attributes of type X520Pseudonym:
-- X520Pseudonym ::= DirectoryName (SIZE (1..ub-pseudonym))
--
-- Expanded to avoid parameterized type:
X520Pseudonym ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-pseudonym)),
printableString PrintableString (SIZE (1..ub-pseudonym)),
universalString UniversalString (SIZE (1..ub-pseudonym)),
utf8String UTF8String (SIZE (1..ub-pseudonym)),
bmpString BMPString (SIZE (1..ub-pseudonym)) }
-- タイプX520Pseudonymの命名属性: -- X520Pseudonym:、:= DirectoryName(SIZE(1..ub-匿名))----parameterizedタイプを避けるために、広げられます: X520Pseudonym:、:= 選択teletexString TeletexString(サイズ(1..ub-匿名))、printableString PrintableString(サイズ(1..ub-匿名))、universalString UniversalString(サイズ(1..ub-匿名))、utf8String UTF8String(サイズ(1..ub-匿名))、bmpString BMPString(サイズ(1..ub-匿名))
Cooper, et al. Standards Track [Page 115] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[115ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
-- Naming attributes of type DomainComponent (from RFC 4519)
-- タイプの属性をDomainComponentと命名します。(RFC4519からの)
id-domainComponent AttributeType ::= { 0 9 2342 19200300 100 1 25 }
イド-domainComponent AttributeType:、:= { 0 9 2342 19200300 100 1 25 }
DomainComponent ::= IA5String
DomainComponent:、:= IA5String
-- Legacy attributes
-- 遺産属性
pkcs-9 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 }
pkcs-9 OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1)9をメンバーと同じくらい具体化させます。
id-emailAddress AttributeType ::= { pkcs-9 1 }
イド-emailAddress AttributeType:、:= pkcs-9 1
EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length))
EmailAddress:、:= IA5String(サイズ(1..ub-emailaddress-長さ))
-- naming data types --
-- データ型を命名します--
Name ::= CHOICE { -- only one possibility for now --
rdnSequence RDNSequence }
以下を命名してください:= 選択--当分間の1つの可能性だけ--rdnSequence RDNSequence
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RDNSequence:、:= RelativeDistinguishedNameの系列
DistinguishedName ::= RDNSequence
DistinguishedName:、:= RDNSequence
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue
RelativeDistinguishedName:、:= AttributeTypeAndValueのサイズ(1..MAX)を設定してください。
-- Directory string type --
-- ディレクトリストリングタイプ--
DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..MAX)),
printableString PrintableString (SIZE (1..MAX)),
universalString UniversalString (SIZE (1..MAX)),
utf8String UTF8String (SIZE (1..MAX)),
bmpString BMPString (SIZE (1..MAX)) }
DirectoryString:、:= 選択teletexString TeletexString(サイズ(1..MAX))、printableString PrintableString(サイズ(1..MAX))、universalString UniversalString(サイズ(1..MAX))、utf8String UTF8String(サイズ(1..MAX))、bmpString BMPString(サイズ(1..MAX))
-- certificate and CRL specific structures begin here
-- 証明書とCRLの特定の構造はここで始まります。
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING }
以下を証明してください:= 系列tbsCertificate TBSCertificate、signatureAlgorithm AlgorithmIdentifier、署名BIT STRING
Cooper, et al. Standards Track [Page 116] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[116ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
TBSCertificate ::= SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
extensions [3] Extensions OPTIONAL
-- If present, version MUST be v3 -- }
TBSCertificate:、:= 系列バージョン[0]バージョンDEFAULT v1、serialNumber CertificateSerialNumber、署名AlgorithmIdentifier、発行人Name(正当性Validity)はNameをかけます、subjectPublicKeyInfo SubjectPublicKeyInfo、issuerUniqueID[1]IMPLICIT UniqueIdentifier OPTIONAL(プレゼント、バージョンは、v2かv3 subjectUniqueID[2]IMPLICIT UniqueIdentifier OPTIONALであるに違いありません--存在しているなら、存在しているなら、バージョンがv2かv3拡大[3]拡大OPTIONALであるに違いないなら、バージョンはv3であるに違いありません)
Version ::= INTEGER { v1(0), v2(1), v3(2) }
バージョン:、:= 整数v1(0)、v2(1)、v3(2)
CertificateSerialNumber ::= INTEGER
CertificateSerialNumber:、:= 整数
Validity ::= SEQUENCE {
notBefore Time,
notAfter Time }
正当性:、:= 系列notBefore時間、notAfter時間
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
以下を調節してください:= 選択utcTime UTCTime、generalTime GeneralizedTime
UniqueIdentifier ::= BIT STRING
UniqueIdentifier:、:= ビット列
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
SubjectPublicKeyInfo:、:= 系列アルゴリズムAlgorithmIdentifier、subjectPublicKey BIT STRING
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
拡大:、:= 拡大の系列サイズ(1..MAX)
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING
-- contains the DER encoding of an ASN.1 value
-- corresponding to the extension type identified
-- by extnID
}
拡大:、:= 系列extnID OBJECT IDENTIFIER、重要なBOOLEAN DEFAULT FALSE、extnValue OCTET STRING--タイプが特定した拡大に対応している、ASN.1価値のDERコード化を含んでいます--、extnID
Cooper, et al. Standards Track [Page 117] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[117ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
-- CRL structures
-- CRL構造
CertificateList ::= SEQUENCE {
tbsCertList TBSCertList,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING }
CertificateList:、:= 系列tbsCertList TBSCertList、signatureAlgorithm AlgorithmIdentifier、署名BIT STRING
TBSCertList ::= SEQUENCE {
version Version OPTIONAL,
-- if present, MUST be v2
signature AlgorithmIdentifier,
issuer Name,
thisUpdate Time,
nextUpdate Time OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate Time,
crlEntryExtensions Extensions OPTIONAL
-- if present, version MUST be v2
} OPTIONAL,
crlExtensions [0] Extensions OPTIONAL }
-- if present, version MUST be v2
TBSCertList:、:= SEQUENCE、バージョンバージョンOPTIONAL--、発行人v2署名がAlgorithmIdentifierであったに違いないならNameを寄贈してください、thisUpdate Time、nextUpdate Time OPTIONAL、revokedCertificates SEQUENCE OF SEQUENCE、userCertificate CertificateSerialNumber、revocationDate Time、crlEntryExtensions Extensions OPTIONAL--プレゼント、バージョンがそうしなければならないならv2になってください、OPTIONAL、crlExtensions[0]拡大OPTIONAL、--存在しているなら、バージョンがv2であるに違いない
-- Version, Time, CertificateSerialNumber, and Extensions were -- defined earlier for use in the certificate structure
-- バージョン、Time、CertificateSerialNumber、およびExtensionsはそうでした--証明書構造の使用のために、より早く定義されます。
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
-- contains a value of the type
-- registered for use with the
-- algorithm object identifier value
AlgorithmIdentifier:、:= SEQUENCE、アルゴリズムOBJECT IDENTIFIER、パラメタANY DEFINED BYアルゴリズムOPTIONAL--タイプの値を含んでいます--、使用のために登録する、--、アルゴリズム物の識別子価値
-- X.400 address syntax starts here
-- X.400アドレス構文はここから始まります。
ORAddress ::= SEQUENCE {
built-in-standard-attributes BuiltInStandardAttributes,
built-in-domain-defined-attributes
BuiltInDomainDefinedAttributes OPTIONAL,
-- see also teletex-domain-defined-attributes
extension-attributes ExtensionAttributes OPTIONAL }
ORAddress:、:= 系列内蔵の標準の属性BuiltInStandardAttributes、内蔵のドメインが属性を定義しているBuiltInDomainDefinedAttributes OPTIONAL--また、テレテックスのドメインの定義された属性拡大属性ExtensionAttributes OPTIONALを見てください。
Cooper, et al. Standards Track [Page 118] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[118ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
-- Built-in Standard Attributes
-- 内蔵の標準の属性
BuiltInStandardAttributes ::= SEQUENCE {
country-name CountryName OPTIONAL,
administration-domain-name AdministrationDomainName OPTIONAL,
network-address [0] IMPLICIT NetworkAddress OPTIONAL,
-- see also extended-network-address
terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL,
private-domain-name [2] PrivateDomainName OPTIONAL,
organization-name [3] IMPLICIT OrganizationName OPTIONAL,
-- see also teletex-organization-name
numeric-user-identifier [4] IMPLICIT NumericUserIdentifier
OPTIONAL,
personal-name [5] IMPLICIT PersonalName OPTIONAL,
-- see also teletex-personal-name
organizational-unit-names [6] IMPLICIT OrganizationalUnitNames
OPTIONAL }
-- see also teletex-organizational-unit-names
BuiltInStandardAttributes:、:= 系列 { 国名のCountryName OPTIONAL、管理ドメイン名AdministrationDomainName OPTIONAL、ネットワーク・アドレス0IMPLICIT NetworkAddress OPTIONAL--また、端末の識別子1拡張ネットワーク・アドレスIMPLICIT TerminalIdentifier OPTIONAL、個人的なドメイン名2PrivateDomainName OPTIONAL、組織名の3IMPLICIT OrganizationName OPTIONALを見てください; また、テレテックス組織名の数値ユーザ識別子4IMPLICIT NumericUserIdentifier OPTIONALを見てください、個人名5IMPLICIT PersonalName OPTIONAL--また、テレテックス個人名組織的なユニット名の6IMPLICIT OrganizationalUnitNames OPTIONALを見てください; } また、テレテックスの組織的なユニット名を見てください。
CountryName ::= [APPLICATION 1] CHOICE {
x121-dcc-code NumericString
(SIZE (ub-country-name-numeric-length)),
iso-3166-alpha2-code PrintableString
(SIZE (ub-country-name-alpha-length)) }
CountryName:、:= [アプリケーション1] 選択x121-dcc-コードNumericString(SIZE(ubの国の名前の数値長さ))、iso-3166-alpha2-コードPrintableString(SIZE(ub国の名前アルファの長さ))
AdministrationDomainName ::= [APPLICATION 2] CHOICE {
numeric NumericString (SIZE (0..ub-domain-name-length)),
printable PrintableString (SIZE (0..ub-domain-name-length)) }
AdministrationDomainName:、:= [アプリケーション2] 選択数値NumericString(SIZE(0..ubドメイン名前の長さ))、印刷可能なPrintableString(SIZE(0..ubドメイン名前の長さ))
NetworkAddress ::= X121Address -- see also extended-network-address
NetworkAddress:、:= X121Address--また、拡張ネットワーク・アドレスを見てください。
X121Address ::= NumericString (SIZE (1..ub-x121-address-length))
X121Address:、:= NumericString(サイズ(1..ub-x121アドレスの長さ))
TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length))
TerminalIdentifier:、:= PrintableString(サイズ(1..ubの端末のイドの長さ))
PrivateDomainName ::= CHOICE {
numeric NumericString (SIZE (1..ub-domain-name-length)),
printable PrintableString (SIZE (1..ub-domain-name-length)) }
PrivateDomainName:、:= 選択数値NumericString(SIZE(1..ubドメイン名前の長さ))、印刷可能なPrintableString(SIZE(1..ubドメイン名前の長さ))
OrganizationName ::= PrintableString
(SIZE (1..ub-organization-name-length))
-- see also teletex-organization-name
OrganizationName:、:= PrintableString(SIZE(1..ub組織名前の長さ))--また、テレテックス組織名を見てください。
NumericUserIdentifier ::= NumericString
(SIZE (1..ub-numeric-user-id-length))
NumericUserIdentifier:、:= NumericString(サイズ(1..ubの数値ユーザイドの長さ))
Cooper, et al. Standards Track [Page 119] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[119ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
PersonalName ::= SET {
surname [0] IMPLICIT PrintableString
(SIZE (1..ub-surname-length)),
given-name [1] IMPLICIT PrintableString
(SIZE (1..ub-given-name-length)) OPTIONAL,
initials [2] IMPLICIT PrintableString
(SIZE (1..ub-initials-length)) OPTIONAL,
generation-qualifier [3] IMPLICIT PrintableString
(SIZE (1..ub-generation-qualifier-length))
OPTIONAL }
-- see also teletex-personal-name
PersonalName:、:= SET、姓[0]IMPLICIT PrintableString(SIZE(1..ub姓の長さ))(名[1]IMPLICIT PrintableString(SIZE(1..ub当然のことの名前の長さ))OPTIONAL)は[2] IMPLICIT PrintableString(SIZE(1..ubは長さに頭文字をつける))OPTIONALに頭文字をつけます、世代資格を与える人[3]IMPLICIT PrintableString(SIZE(1..ub世代資格を与える人の長さ))OPTIONAL--また、テレテックス個人名を見てください。
OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units)
OF OrganizationalUnitName
-- see also teletex-organizational-unit-names
OrganizationalUnitNames:、:= SEQUENCE SIZE(1..ubの組織的なユニット)OF OrganizationalUnitName--また、テレテックスの組織的なユニット名を見てください。
OrganizationalUnitName ::= PrintableString (SIZE
(1..ub-organizational-unit-name-length))
OrganizationalUnitName:、:= PrintableString(サイズ(1..ubの組織的なユニットは長さを命名します))
-- Built-in Domain-defined Attributes
-- 内蔵のドメインで定義された属性
BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE
(1..ub-domain-defined-attributes) OF
BuiltInDomainDefinedAttribute
BuiltInDomainDefinedAttributes:、:= BuiltInDomainDefinedAttributeの系列サイズ(1..ubドメインは属性を定義しました)
BuiltInDomainDefinedAttribute ::= SEQUENCE {
type PrintableString (SIZE
(1..ub-domain-defined-attribute-type-length)),
value PrintableString (SIZE
(1..ub-domain-defined-attribute-value-length)) }
BuiltInDomainDefinedAttribute:、:= 系列PrintableString(SIZE(1..ubドメインは属性タイプの長さを定義した))、値のPrintableString(SIZE(1..ubドメインは属性値の長さを定義した))をタイプしてください。
-- Extension Attributes
-- 拡大属性
ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF
ExtensionAttribute
ExtensionAttributes:、:= ExtensionAttributeのサイズ(1..ub拡大属性)を設定してください。
ExtensionAttribute ::= SEQUENCE {
extension-attribute-type [0] IMPLICIT INTEGER
(0..ub-extension-attributes),
extension-attribute-value [1]
ANY DEFINED BY extension-attribute-type }
ExtensionAttribute:、:= 系列拡大属性タイプ[0]IMPLICIT INTEGER(0..ub拡大属性)、拡大属性値[1]ANY DEFINED BY拡大属性タイプ
-- Extension types and attribute values
-- 拡大タイプと属性値
common-name INTEGER ::= 1
一般名INTEGER:、:= 1
CommonName ::= PrintableString (SIZE (1..ub-common-name-length))
CommonName:、:= PrintableString(サイズ(1..ubの一般的な名前の長さ))
Cooper, et al. Standards Track [Page 120] RFC 5280 PKIX Certificate and CRL Profile May 2008
クーパー、他 標準化過程[120ページ]RFC5280PKIX証明書とCRLプロフィール2008年5月
teletex-common-name INTEGER ::= 2
テレテックス一般名INTEGER:、:= 2
TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length))
TeletexCommonName:、:= TeletexString(サイズ(1..ubの一般的な名前の長さ))
teletex-organization-name INTEGER ::= 3
テレテックス組織名のINTEGER:、:= 3
一覧
スポンサーリンク
