RFC2459 日本語訳
2459 Internet X.509 Public Key Infrastructure Certificate and CRLProfile. R. Housley, W. Ford, W. Polk, D. Solo. January 1999. (Format: TXT=278438 bytes) (Obsoleted by RFC3280) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Housley
Request for Comments: 2459 SPYRUS
Category: Standards Track W. Ford
VeriSign
W. Polk
NIST
D. Solo
Citicorp
January 1999
Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2459年のSPYRUSカテゴリ: 標準化過程W.フォードベリサインW.ポークNIST D.はシティコープ1999年1月に独奏します。
Internet X.509 Public Key Infrastructure
Certificate and CRL Profile
X.509公開鍵基盤の証明書とCRLが輪郭を描くインターネット
Status of this Memo
この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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. An overview of the approach and model are 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 (e.g., IP addresses). Standard certificate extensions are described and one new Internet-specific extension is defined. A required set of certificate extensions is specified. The X.509 v2 CRL format is described and a required extension set is defined as well. An algorithm for X.509 certificate path validation is described. Supplemental information is provided describing the format of public keys and digital signatures in X.509 certificates for common Internet public key encryption algorithms (i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are provided in the appendices.
このメモはインターネットでの使用のためにX.509 v3証明書とX.509 v2 CRLの輪郭を描きます。 序論としてアプローチとモデルの概要を提供します。 X.509 v3証明書形式はインターネット名前フォーム(例えば、IPアドレス)の形式と意味論に関する追加情報で詳細に説明されます。 標準の証明書拡張子は説明されます、そして、1つの新しいインターネット特有の拡大が定義されます。 必要な証明書拡張子は指定されます。 X.509 v2 CRL形式は説明されます、そして、また、必要な拡大セットは定義されます。 X.509証明書経路合法化のためのアルゴリズムは説明されます。 一般的なインターネット公開鍵暗号化アルゴリズム(すなわち、RSA、DSA、およびディフィー-ヘルマン)のためのX.509証明書における公開鍵とデジタル署名の形式について説明しながら、補足的情報を提供します。 ASN.1モジュールと例を付録に提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
Housley, et. al. Standards Track [Page 1] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[1ページ]。
Please send comments on this document to the ietf-pkix@imc.org mail list.
このドキュメントのコメントを ietf-pkix@imc.org メール・リストに送ってください。
TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttssss
バイバイ、T T Tはn n nt t t Te e eアンn n nt t t t s s sのf f f C C C Co o oのa腹筋b b bl l l le e e e o o oです。
1 Introduction ................................................ 5 2 Requirements and Assumptions ................................ 6 2.1 Communication and Topology ................................ 6 2.2 Acceptability Criteria .................................... 7 2.3 User Expectations ......................................... 7 2.4 Administrator Expectations ................................ 7 3 Overview of Approach ........................................ 7 3.1 X.509 Version 3 Certificate ............................... 9 3.2 Certification Paths and Trust ............................. 10 3.3 Revocation ................................................ 12 3.4 Operational Protocols ..................................... 13 3.5 Management Protocols ...................................... 13 4 Certificate and Certificate Extensions Profile .............. 15 4.1 Basic Certificate Fields .................................. 15 4.1.1 Certificate Fields ...................................... 16 4.1.1.1 tbsCertificate ........................................ 16 4.1.1.2 signatureAlgorithm .................................... 16 4.1.1.3 signatureValue ........................................ 17 4.1.2 TBSCertificate .......................................... 17 4.1.2.1 Version ............................................... 17 4.1.2.2 Serial number ......................................... 18 4.1.2.3 Signature ............................................. 18 4.1.2.4 Issuer ................................................ 18 4.1.2.5 Validity .............................................. 21 4.1.2.5.1 UTCTime ............................................. 22 4.1.2.5.2 GeneralizedTime ..................................... 22 4.1.2.6 Subject ............................................... 22 4.1.2.7 Subject Public Key Info ............................... 23 4.1.2.8 Unique Identifiers .................................... 24 4.1.2.9 Extensions ............................................. 24 4.2 Certificate Extensions .................................... 24 4.2.1 Standard Extensions ..................................... 25 4.2.1.1 Authority Key Identifier .............................. 25 4.2.1.2 Subject Key Identifier ................................ 26 4.2.1.3 Key Usage ............................................. 27 4.2.1.4 Private Key Usage Period .............................. 29 4.2.1.5 Certificate Policies .................................. 29 4.2.1.6 Policy Mappings ....................................... 31 4.2.1.7 Subject Alternative Name .............................. 32
1つの序論… 5 2の要件と仮定… 6 2.1のコミュニケーションとトポロジー… 6 2.2 受容性評価基準… 7 2.3 ユーザ期待… 7 2.4 管理者期待… アプローチの7 3概要… 7 3.1 X.509バージョン3証明書… 9 3.2 証明経路と信頼… 10 3.3取消し… 12 3.4 操作上のプロトコル… 13 3.5 管理プロトコル… 13 4 拡大プロフィールを証明して、証明してください… 15 4.1 基本的な証明書分野… 15 4.1 .1 分野を証明してください… 16 4.1 .1 .1tbsCertificate… 16 4.1 .1 .2signatureAlgorithm… 16 4.1 .1 .3signatureValue… 17 4.1 .2TBSCertificate… 17 4.1 .2 .1バージョン… 17 4.1 .2 .2通し番号… 18 4.1 .2 .3署名… 18 4.1 .2 .4発行人… 18 4.1 .2 .5の正当性… 21 4.1 .2 .5 .1UTCTime… 22 4.1 .2 .5 .2GeneralizedTime… 22 4.1 .2 .6 かけます。 22 4.1 .2 .7 対象の公開鍵インフォメーション… 23 4.1 .2 .8のユニークな識別子… 24 4.1 .2 .9の拡大… 24 4.2 拡大を証明してください… 24 4.2 .1 標準の拡大… 25 4.2 .1 .1の権威の主要な識別子… 25 4.2 .1 .2の対象の主要な識別子… 26 4.2 .1 .3 主要な用法… 27 4.2 .1 .4秘密鍵用法の期間… 29 4.2 .1 .5 方針を証明してください… 29 4.2 .1 .6 方針マッピング… 31 4.2 .1 .7 対象の代替名… 32
Housley, et. al. Standards Track [Page 2] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[2ページ]。
4.2.1.8 Issuer Alternative Name ............................... 34 4.2.1.9 Subject Directory Attributes .......................... 34 4.2.1.10 Basic Constraints .................................... 35 4.2.1.11 Name Constraints ..................................... 35 4.2.1.12 Policy Constraints ................................... 37 4.2.1.13 Extended key usage field ............................. 38 4.2.1.14 CRL Distribution Points .............................. 39 4.2.2 Private Internet Extensions ............................. 40 4.2.2.1 Authority Information Access .......................... 41 5 CRL and CRL Extensions Profile .............................. 42 5.1 CRL Fields ................................................ 43 5.1.1 CertificateList Fields .................................. 43 5.1.1.1 tbsCertList ........................................... 44 5.1.1.2 signatureAlgorithm .................................... 44 5.1.1.3 signatureValue ........................................ 44 5.1.2 Certificate List "To Be Signed" ......................... 44 5.1.2.1 Version ............................................... 45 5.1.2.2 Signature ............................................. 45 5.1.2.3 Issuer Name ........................................... 45 5.1.2.4 This Update ........................................... 45 5.1.2.5 Next Update ........................................... 45 5.1.2.6 Revoked Certificates .................................. 46 5.1.2.7 Extensions ............................................ 46 5.2 CRL Extensions ............................................ 46 5.2.1 Authority Key Identifier ................................ 47 5.2.2 Issuer Alternative Name ................................. 47 5.2.3 CRL Number .............................................. 47 5.2.4 Delta CRL Indicator ..................................... 48 5.2.5 Issuing Distribution Point .............................. 48 5.3 CRL Entry Extensions ...................................... 49 5.3.1 Reason Code ............................................. 50 5.3.2 Hold Instruction Code ................................... 50 5.3.3 Invalidity Date ......................................... 51 5.3.4 Certificate Issuer ...................................... 51 6 Certificate Path Validation ................................. 52 6.1 Basic Path Validation ..................................... 52 6.2 Extending Path Validation ................................. 56 7 Algorithm Support ........................................... 57 7.1 One-way Hash Functions .................................... 57 7.1.1 MD2 One-way Hash Function ............................... 57 7.1.2 MD5 One-way Hash Function ............................... 58 7.1.3 SHA-1 One-way Hash Function ............................. 58 7.2 Signature Algorithms ...................................... 58 7.2.1 RSA Signature Algorithm ................................. 59 7.2.2 DSA Signature Algorithm ................................. 60 7.3 Subject Public Key Algorithms ............................. 60 7.3.1 RSA Keys ................................................ 61 7.3.2 Diffie-Hellman Key Exchange Key ......................... 61
4.2.1.8 発行人代替名… 34 4.2 .1 .9 テーマ別ディレクトリ属性… 34 4.2 .1 .10 基本的な規制… 35 4.2 .1 .11 規制を命名してください… 35 4.2 .1 .12 方針規制… 37 4.2 .1 .13の拡張主要な用法分野… 38 4.2 .1 .14 CRL分配は指します… 39 4.2 .2 個人的なインターネット拡大… 40 4.2 .2 .1 権威情報アクセス… 41 5のCRLとCRL拡大プロフィール… 42 5.1 CRL分野… 43 5.1 .1 CertificateList分野… 43 5.1 .1 .1tbsCertList… 44 5.1 .1 .2signatureAlgorithm… 44 5.1 .1 .3signatureValue… 44 5.1 .2は「署名される」ためにリストを証明します… 44 5.1 .2 .1バージョン… 45 5.1 .2 .2署名… 45 5.1 .2 .3発行人名… 45 5.1 .2 .4 このアップデート… 45 5.1 .2 .5 次のアップデート… 45 5.1 .2 .6は証明書を取り消しました… 46 5.1 .2 .7の拡大… 46 5.2 CRL拡張子… 46 5.2 .1の権威の主要な識別子… 47 5.2 .2 発行人代替名… 47 5.2 .3 CRL番号… 47 5.2 .4デルタCRLインディケータ… 48 5.2 分配を発行する.5が指します… 48 5.3 CRLエントリー拡張子… 49 5.3 .1 コードを推論してください… 50 5.3 .2 命令コードを保持してください… 50 5.3 .3無効日付… 51 5.3 .4 発行人を証明してください… 51 6 経路合法化を証明してください… 52 6.1 基本的な経路合法化… 52 6.2 経路合法化を広げています… 56 7 アルゴリズムサポート… 57 7.1の一方向ハッシュは機能します… 57 7.1 .1 MD2の一方向ハッシュ関数… 57 7.1 .2 MD5の一方向ハッシュ関数… 58 7.1 .3 SHA-1の一方向ハッシュ関数… 58 7.2 署名アルゴリズム… 58 7.2 .1RSA署名アルゴリズム… 59 7.2 .2DSA署名アルゴリズム… 60 7.3 対象の公開鍵アルゴリズム… 60 7.3 .1 RSAキー… 61 7.3 .2のディフィー-ヘルマンの主要な交換キー… 61
Housley, et. al. Standards Track [Page 3] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[3ページ]。
7.3.3 DSA Signature Keys ...................................... 63 8 References .................................................. 64 9 Intellectual Property Rights ................................ 66 10 Security Considerations .................................... 67 Appendix A. ASN.1 Structures and OIDs ......................... 70 A.1 Explicitly Tagged Module, 1988 Syntax ...................... 70 A.2 Implicitly Tagged Module, 1988 Syntax ...................... 84 Appendix B. 1993 ASN.1 Structures and OIDs .................... 91 B.1 Explicitly Tagged Module, 1993 Syntax ...................... 91 B.2 Implicitly Tagged Module, 1993 Syntax ...................... 108 Appendix C. ASN.1 Notes ....................................... 116 Appendix D. Examples .......................................... 117 D.1 Certificate ............................................... 117 D.2 Certificate ............................................... 120 D.3 End-Entity Certificate Using RSA .......................... 123 D.4 Certificate Revocation List ............................... 126 Appendix E. Authors' Addresses ................................ 128 Appendix F. Full Copyright Statement .......................... 129
7.3.3 DSA署名キー… 63 8つの参照箇所… 64 9知的所有権はまっすぐになります… 66 10のセキュリティ問題… 67付録A.ASN.1構造とOIDs… 70 A.1は明らかにモジュール、1988年の構文にタグ付けをしました… 70 A.2はそれとなくモジュール、1988年の構文にタグ付けをしました… 84付録B.1993ASN.1構造とOIDs… 91 B.1は明らかにモジュール、1993年の構文にタグ付けをしました… 91 B.2はそれとなくモジュール、1993年の構文にタグ付けをしました… 108 付録C.ASN.1注意… 116 付録D.の例… 117D.1証明書… 117D.2証明書… RSAを使用する120D.3終わり実体証明書… 123 D.4は取消しリストを証明します… 126 付録E.作者のアドレス… 128 付録のF.の完全な著作権宣言文… 129
Housley, et. al. Standards Track [Page 4] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[4ページ]。
1 Introduction
1つの序論
This specification is one part of a family of standards for the X.509 Public Key Infrastructure (PKI) for the Internet. This specification is a standalone document; implementations of this standard may proceed independent from the other parts.
この仕様はインターネットへのX.509公開鍵暗号基盤(PKI)の規格のファミリーの一部です。 この仕様はスタンドアロンドキュメントです。 この規格の実装は他の部品から独立者を続かせるかもしれません。
This specification profiles the format and semantics of certificates and certificate revocation lists for the Internet PKI. Procedures are described for processing of certification paths in the Internet environment. Encoding rules are provided for popular cryptographic algorithms. Finally, ASN.1 modules are provided in the appendices for all data structures defined or referenced.
この仕様は証明書と証明書失効リストの形式と意味論のインターネットPKIに輪郭を描きます。 手順はインターネット環境における、証明経路の処理のために説明されます。 ポピュラーな暗号アルゴリズムに符号化規則を提供します。最終的に、データ構造が定義したか、または参照をつけたすべてのためにASN.1モジュールを付録に提供します。
The specification describes the requirements which inspire the creation of this document and the assumptions which affect its scope in Section 2. Section 3 presents an architectural model and describes its relationship to previous IETF and ISO/IEC/ITU standards. In particular, this document's relationship with the IETF PEM specifications and the ISO/IEC/ITU X.509 documents are described.
仕様はこのドキュメントの作成を奮い立たせる要件とセクション2で範囲に影響する仮定について説明します。 セクション3は、前のIETFとISO/IEC/ITU規格に建築モデルを提示して、関係について説明します。 特に、IETF PEM仕様とのこのドキュメントの関係とISO/IEC/ITU X.509ドキュメントは説明されます。
The specification profiles the X.509 version 3 certificate in Section 4, and the X.509 version 2 certificate revocation list (CRL) in Section 5. The profiles include the identification of ISO/IEC/ITU and ANSI extensions which may be useful in the Internet PKI. The profiles are presented in the 1988 Abstract Syntax Notation One (ASN.1) rather than the 1994 syntax used in the ISO/IEC/ITU standards.
仕様は、セクション4でX.509バージョン3証明書の輪郭を描いて、セクション5でX.509バージョン2証明書失効リスト(CRL)の輪郭を描きます。 プロフィールはISO/IEC/ITUとインターネットPKIで役に立つかもしれないANSI拡張子の識別を含んでいます。 プロフィールはISO/IEC/ITU規格に使用される1994年の構文よりむしろ1988の抽象的なSyntax Notation One(ASN.1)に提示されます。
This specification also includes path validation procedures in Section 6. These procedures are based upon the ISO/IEC/ITU definition, but the presentation assumes one or more self-signed trusted CA certificates. Implementations are required to derive the same results but are not required to use the specified procedures.
また、この仕様はセクション6の経路合法化手順を含んでいます。 これらの手順はISO/IEC/ITU定義に基づいていますが、プレゼンテーションは、1つ以上が、信じられたカリフォルニアが証明書であると自己に署名したと仮定します。 実装は、同じ結果を引き出すのが必要ですが、指定された手順を用いるのに必要ではありません。
Section 7 of the specification describes procedures for identification and encoding of public key materials and digital signatures. Implementations are not required to use any particular cryptographic algorithms. However, conforming implementations which use the identified algorithms are required to identify and encode the public key materials and digital signatures as described.
仕様のセクション7は公開鍵の材料とデジタル署名の識別とコード化のための手順について説明します。 実装は、どんな特定の暗号アルゴリズムも使用するのに必要ではありません。しかしながら、特定されたアルゴリズムを使用する従う実装が、説明されるように公開鍵の材料とデジタル署名を特定して、コード化するのに必要です。
Finally, four 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 Abstract Syntax Notation One (ASN.1) rather than the 1994 syntax. Appendix B contains the same information in the 1994 ASN.1 notation as a service to implementers using updated toolsets. However, Appendix A takes precedence in case of conflict. Appendix C contains
最終的に、implementersを支援するために4個の付録を提供します。 付録Aはこの仕様の中で定義されたか、または参照をつけられたすべてのASN.1構造を含んでいます。 同じくらい上では、1994年の構文よりむしろ1988の抽象的なSyntax Notation One(ASN.1)で材料を寄贈します。 implementers使用に対するサービスがツールセットをアップデートしたので、付録Bは1994ASN.1記法による同じ情報を含んでいます。 しかしながら、Appendix Aは闘争の場合に優先します。 Cが含む付録
Housley, et. al. Standards Track [Page 5] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[5ページ]。
notes on less familiar features of the ASN.1 notation used within this specification. Appendix D contains examples of a conforming certificate and a conforming CRL.
この仕様の中で使用されたASN.1記法のそれほど身近でない特徴に関する注。 付録Dは従っている証明書と従っているCRLに関する例を含んでいます。
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 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の接続性も、または高い接続の有用性なしでユーザをサポートします。 さらに、プロフィールは何らかのファイアウォールの存在のためにフィルターにかけることのコミュニケーションを許容します。
Housley, et. al. Standards Track [Page 6] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[6ページ]。
This profile does not assume the deployment of an X.500 Directory system. The profile does not prohibit the use of an X.500 Directory, but other means of distributing certificates and certificate revocation lists (CRLs) may be used.
このプロフィールはX.500ディレクトリシステムの展開を仮定しません。 プロフィールはX.500ディレクトリの使用を禁止しませんが、証明書と証明書失効リスト(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 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 which shield the user from many malicious actions, and applications which sensibly automate validation functions.
インターネットPKIのユーザは、クライアントソフトウェアを使用する人々とプロセスであり、証明書で指定された対象です。 これらの用途はルータの中にIPsecの電子メールの読者と作家、WWWブラウザのためのクライアント、WWWサーバ、および主要なマネージャを含んでいます。 このプロフィールはこれらのユーザが使うプラットホームの制限とユーザ自身の洗練と注意深さにおける制限を認識します。 これは最小量のユーザ構成責任(例えば、カリフォルニアキー、規則を信じる)、証明書、多くの悪意がある行為からユーザを保護する証明経路規制、および分別よく合法化機能を自動化するアプリケーションの中の明白なプラットホーム用法規制で現れます。
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 shall 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 PKIX specifications.
以下に、PKIX仕様によって思われた建築モデルの簡易型の視点があります。
Housley, et. al. Standards Track [Page 7] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[7ページ]。
+---+
| C | +------------+
| e | <-------------------->| End entity |
| r | Operational +------------+
| t | transactions ^
| | and management | Management
| / | transactions | transactions
| | | PKI users
| C | v
| R | -------------------+--+-----------+----------------
| L | ^ ^
| | | | PKI management
| | v | entities
| R | +------+ |
| e | <---------------------| RA | <---+ |
| p | Publish certificate +------+ | |
| o | | |
| s | | |
| I | v v
| t | +------------+
| o | <------------------------------| CA |
| r | Publish certificate +------------+
| y | Publish CRL ^
| | |
+---+ Management |
transactions |
v
+------+
| CA |
+------+
+---+ | C| +------------+ | e| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 終わりの実体| | r| 操作上の+------------+ | t| トランザクション^| | そして、管理| 管理| / | トランザクション| トランザクション| | | PKIユーザ| C| v| R| -------------------+--+-----------+---------------- | L| ^ ^ | | | | PKI管理| | v| 実体| R| +------+ | | e| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| RA| <--+ | | p| 証明書+を発表してください。------+ | | | o | | | | s| | | | I| vに対して| t| +------------+ | o | <------------------------------| カリフォルニア| | r| 証明書+を発表してください。------------+ | y| CRL^を発行してください。| | | +---+ 管理| トランザクション| +に対して------+ | カリフォルニア| +------+
Figure 1 - PKI Entities
図1--PKI実体
The components in this model are:
このモデルのコンポーネントは以下の通りです。
end entity: user of PKI certificates and/or end user system that
is the subject of a certificate;
CA: certification authority;
RA: registration authority, i.e., an optional system to
which a CA delegates certain management functions;
repository: a system or collection of distributed systems that
store certificates and CRLs and serves as a means of
distributing these certificates and CRLs to end
entities.
実体を終わらせてください: 証明書の対象であるPKI証明書、そして/または、エンドユーザシステムのユーザ。 カリフォルニア: 証明権威。 RA: すなわち、登録局、カリフォルニアが、ある管理機能を代表として派遣する任意のシステム。 倉庫: 実体を終わらせるこれらの証明書とCRLsを配布する手段として証明書、CRLs、およびサーブを保存する分散システムのシステムか収集。
Housley, et. al. Standards Track [Page 8] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[8ページ]。
3.1 X.509 Version 3 Certificate
3.1 X.509バージョン3証明書
Users of a public key shall be confident 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 posession 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 untrusted communications and server systems, and can be cached in unsecured storage in certificate-using systems.
公開鍵のユーザは暗号化かデジタル署名メカニズムが使用される正しいリモート対象(人かシステム)によって関連秘密鍵が所有されていると確信するでしょう。 公開鍵証明書の使用でこの信用を得ます。(証明書は公開鍵値を対象に縛るデータ構造です)。 信じられたカリフォルニアを各証明書にデジタルに署名させることによって、結合は断言されます。 カリフォルニアは、対象で技術手段(通称挑戦応答プロトコルを通したposessionの証拠)でのこの主張、秘密鍵のプレゼンテーションを基礎づけるか、または主張に関してそうするかもしれません。 証明書には、署名しているコンテンツで示される限られた有効な寿命があります。 証明書を使用するクライアントが独自に証明書の署名とタイムリーさであるのをチェックできるので、証明書を信頼されていないコミュニケーションとサーバシステムで分配できて、証明書を使用するシステムで非機密保護しているストレージでキャッシュできます。
ITU-T X.509 (formerly CCITT X.509) or ISO/IEC/ITU 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. These two fields may be used to support directory access control.
ITU-T X.509(以前CCITT X.509)かISO/IEC/ITU9594-8(1988年に最初に、X.500ディレクトリ推薦の一部として発行された)が標準の証明書書式[X.509]を定義します。 1988年の規格における証明書形式はバージョン1(v1)形式と呼ばれます。 X.500が1993年に改訂されたとき、バージョン2(v2)形式をもたらして、もう2つの分野が加えられました。 これらの2つの分野が、ディレクトリアクセスがコントロールであるとサポートするのに使用されるかもしれません。
The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, include specifications for a public key infrastructure based on X.509 v1 certificates [RFC 1422]. The experience gained in attempts to deploy RFC 1422 made it clear that the v1 and v2 certificate formats are deficient in several respects. Most importantly, more fields were needed to carry information which PEM design and implementation experience has proven necessary. In response to these new requirements, ISO/IEC/ITU 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とANSI X9はX.509バージョン3(v3)証明書形式を発生しました。 v3形式は、追加拡大分野への支給を加えることによって、v2形式を広げています。 特定の拡大フィールド・タイプは、どんな組織や共同体によっても規格で指定されるか、定義されて、または示されるかもしれません。 1996年6月に、基本的なv3形式の標準化は終了しました[X.509]。
ISO/IEC/ITU 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とANSI X9はv3拡大分野[X.509][X9.55]での使用のための標準の拡大を発生しました。 これらの拡大は追加対象の識別情報、主要な属性情報、方針情報、および証明経路規制のようなデータを伝えることができます。
Housley, et. al. Standards Track [Page 9] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[9ページ]。
However, the ISO/IEC/ITU 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と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 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.
一般に、公開鍵に関する知識を必要とするセキュリティー・サービスのユーザは、必要な公開鍵を含む証明書を得て、有効にする必要があります。 公開鍵ユーザが既に、証明書に署名したカリフォルニアの公開鍵の確実なコピー、CAの名前、および関連する情報(規制という有効期間か名前などの)を保持しないなら、それは、その公開鍵を得るために追加証明書を必要とするかもしれません。 一般に、複数の証明書のチェーンが必要であったかもしれません、公開鍵所有者(終わりの実体)の証明書を包括するのは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)は、法的に拘束力があるデジタル署名要件を満たすように、より厳しい方針を設計させるかもしれません。
Housley, et. al. Standards Track [Page 10] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[10ページ]。
(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がそれらが公認できる下位の実体のセットに関して分別よく抑制されるのを確実にします(例えば、組織のためのカリフォルニアはその組織名木で実体を公認できるだけです)。 証明書ユーザシステムは、名前従属規則に従ってあるのを機械的にチェックできます。
The RFC 1422 uses the X.509 v1 certificate formats. 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 may 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) 証明経路はユーザの自己のドメインのカリフォルニア、または階層構造の最上部の公開鍵で公開鍵から始まるかもしれません。 ユーザの自己のドメインでカリフォルニアの公開鍵から始まるのにおいて、ある利点があります。 いくつかの環境で、局所領域は最も信じているものです。
Housley, et. al. Standards Track [Page 11] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[11ページ]。
(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 certificate chain
processing.
(c) 方針拡大と方針マッピングはPCA概念に取って代わります。(それは、より大きい度合いのオートメーションを可能にします)。 アプリケーションは、証明経路がPCAsに関する先験的な知識の代わりに証明書のコンテンツに基づいて許容できるかどうか決定できます。 これは証明書チェーン処理のオートメーションを可能にします。
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 which is signed by a CA 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 CA issues a new CRL 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 may be removed from the CRL after appearing on one regularly scheduled CRL issued beyond the revoked certificate's validity period.
X.509は証明書取消しの1つのメソッドを定義します。 このメソッドは定期的に証明書失効リスト(CRL)と呼ばれる署名しているデータ構造を発行する各カリフォルニアを伴います。 CRLは取り消された証明書を特定する時間の押し込まれたリストです(カリフォルニアによって署名されて、公共の倉庫で自由に利用可能にされます)。 それぞれの取り消された証明書はCRLで証明書通し番号によって特定されます。 証明書を使用するシステムが証明書(例えば、リモート・ユーザーのデジタル署名について確かめるための)を使用すると、そのシステムは、証明書署名と正当性をチェックするだけではなく、適当に最近のCRLを獲得して、証明書通し番号がそのCRLにないのをチェックもします。 「適当に最近」の意味はローカルの方針で異なるかもしれませんが、通常、それは、大部分が最近CRLを発行したことを意味します。 カリフォルニアが通常周期的ベースで新しいCRLを発行する、(例えば、1時間ごと、毎日、または毎週、) エントリーは取消しの通知に続く次のアップデートの一部としてCRLに加えられます。 取り消された証明書の有効期間に発行された1定期的に予定されているCRLに現れた後に、CRLからエントリーを取り除くかもしれません。
An advantage of this revocation method is that CRLs may be distributed by exactly the same means as certificates themselves, namely, via untrusted communications and server systems.
この取消しメソッドの利点はすなわち、信頼されていないことを通して自分たちでコミュニケーションとサーバシステムを証明するとき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 revocation is reported now, that revocation will not be reliably
CRL取消しメソッドの1つの制限(信頼されていないコミュニケーションを使用して、サーバ)は、取消しの時間粒状がCRL問題の期間まで制限されるということです。 例えば、取消しが現在報告されるなら、その取消しは確かに報告しなくなるでしょう。
Housley, et. al. Standards Track [Page 12] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[12ページ]。
notified to certificate-using systems until the next periodic CRL is issued -- this may be up to one hour, one day, or one week depending on the frequency that the CA issues CRLs.
--次の周期的なCRLが発行されるまで証明書を使用するシステムに通知されて、これは最大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 CAs to issue CRLs. Message formats and protocols supporting on-line revocation notification may be 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 the 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 shall trust the on-line validation service while the repository does not need to be trusted.
X.509 v3証明書形式のように、X.509 v2 CRL形式は、複数のベンダーから共同利用できる実装を容易にするのにインターネットの利用のために輪郭を描かれる必要があります。 それはそのプロフィールを指定するこのドキュメントの1つの目標です。 しかしながら、このプロフィールは、CAsが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. Provision is 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 which cross-certify each other. The set of functions which 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を通した)にそれ自体を明らかにするプロセスです、そのユーザのために証明書か証明書を発行するそのカリフォルニアの前に。
Housley, et. al. Standards Track [Page 13] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[13ページ]。
(b) initialization: Before a client system can operate securely
it is necessary to install key materials which 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.
Furthermore, a client typically needs to be initialized with its
own key pair(s).
(b)初期化: クライアントシステムがしっかりと作動できる前に、インフラストラクチャにおけるほかの場所に保存されるキーとの適切な関係を持っている主要資材をインストールするのが必要です。 例えば、クライアントは信じられたカリフォルニアの公開鍵と他の確実な情報でしっかりと初期化されて、証明書経路を有効にする際に使用される必要があります。 その上、クライアントは、通常それ自身の主要な組と共に初期化される必要があります。
(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 which 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回のプロトコル交換に結合できます。
The PKIX series of specifications may define a set of standard message formats supporting the above functions in future specifications. In that case, the protocols for conveying these messages in different environments (e.g., on-line, file transfer, e- mail, and WWW) will also be described in those specifications.
仕様のPKIXシリーズは将来の仕様で上の機能をサポートする1セットの標準のメッセージ・フォーマットを定義するかもしれません。 その場合、異なった環境におけるこれらのメッセージを伝えるためのプロトコル、(例えば、オンラインである、ファイル転送、電子メール、およびWWW) また、それらの仕様では、説明されるでしょう。
Housley, et. al. Standards Track [Page 14] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[14ページ]。
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/ITU documents use the 1993 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ドキュメントは1993年の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 certificate is encoded using the ASN.1 distinguished encoding rules (DER) [X.208]. ASN.1 DER encoding is a tag, length, value encoding system for each element.
X.509 v3の証明書の基本的な構文は以下の通りです。 署名計算において、証明書は、規則(DER)[X.208]をコード化しながら区別された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 shall be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version shall be v2 or v3
extensions [3] EXPLICIT Extensions OPTIONAL
-- If present, version shall be v3
}
TBSCertificate:、:= 系列バージョン[0]EXPLICITバージョンDEFAULT v1、serialNumber CertificateSerialNumber、署名AlgorithmIdentifier、発行人Name(正当性Validity)はNameをかけます、subjectPublicKeyInfo SubjectPublicKeyInfo、issuerUniqueID[1]IMPLICIT UniqueIdentifier OPTIONAL--プレゼント、バージョンは、v2かIMPLICIT UniqueIdentifier OPTIONALにv3 subjectUniqueID[2]なるでしょう--存在しているなら、存在しているならバージョンがv2かv3EXPLICIT Extensions OPTIONALに拡大[3]なると、バージョンはv3になるでしょう。
Housley, et. al. Standards Track [Page 15] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[15ページ]。
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 }
拡大:、:= 系列extnID OBJECT IDENTIFIER、重要なBOOLEAN DEFAULT FALSE、extnValue OCTET STRING
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です。 分野は以下の小区分で詳細に説明されます。
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 may also include 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. Section 7.2 lists the supported signature algorithms.
signatureAlgorithm分野はこの証明書に署名するのにカリフォルニアによって使用された暗号アルゴリズムのための識別子を含んでいます。 セクション7.2はサポートしている署名アルゴリズムを記載します。
An algorithm identifier is defined by the following ASN.1 structure:
アルゴリズム識別子は以下のASN.1構造によって定義されます:
Housley, et. al. Standards Track [Page 16] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[16ページ]。
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. Section 7.2 lists the supported algorithms for this specification.
アルゴリズム識別子は、暗号アルゴリズムを特定するのに使用されます。 OBJECT IDENTIFIERの部品はアルゴリズム(SHA-1とDSAなどの)を特定します。 特定されたアルゴリズムによると、任意のパラメタ分野のコンテンツは異なるでしょう。 セクション7.2はこの仕様のためにサポートしているアルゴリズムを記載します。
This field MUST contain the same algorithm identifier as the signature field in the sequence tbsCertificate (see sec. 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 then ASN.1 encoded as a BIT STRING and included in the Certificate's signature field. The details of this process are specified for each of the supported algorithms in Section 7.2.
計算されて、signatureValue分野はデジタル署名を含んでいます。ASN.1DERはtbsCertificateをコード化しました。 署名への入力が機能するので、ASN.1DERは使用されるtbsCertificateをコード化しました。 そして、この署名値はBIT STRINGとしてコード化されて、Certificateの署名分野に含まれていたASN.1です。 このプロセスの細部はセクション7.2のそれぞれのサポートしているアルゴリズムに指定されます。
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 who issued it. Every TBSCertificate contains the names of the subject and issuer, a public 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 may also include extensions. Extensions for the Internet PKI are described in Section 4.2.
系列TBSCertificateはそれを発行した証明書とカリフォルニアの対象に関連している情報を含んでいます。 あらゆるTBSCertificateが対象と発行人の名前を含んでいます、対象、有効期間、バージョン番号、および通し番号に関連している公開鍵。 或るものは任意のユニークな識別子分野を含むかもしれません。 このセクションの残りはこれらの分野の構文と意味論について説明します。 また、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, use X.509 version 3 (value is 2). If no extensions are present, but a UniqueIdentifier is present, use version 2 (value is 1). If only basic fields are present, use version 1 (the value is omitted from the certificate as the default value).
この分野はコード化された証明書のバージョンについて説明します。 拡大がこのプロフィールで予想されるように使用されているときには、X.509バージョン3を使用してください(値は2です)。 どんな拡大も存在していませんが、UniqueIdentifierが存在しているなら、バージョン2を使用してください(値は1です)。 基礎体だけが存在しているなら、バージョン1を使用してください(値はデフォルト値として証明書から省略されます)。
Housley, et. al. Standards Track [Page 17] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[17ページ]。
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 is an 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).
通し番号はカリフォルニアによって各証明書に割り当てられた整数です。 与えられたカリフォルニアによって発行された各証明書に、それはユニークであるに違いありません(すなわち、発行人名と通し番号はユニークな証明書を特定します)。
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 (see sec. 4.1.1.2). The contents of the optional parameters field will vary according to the algorithm identified. Section 7.2 lists the supported signature algorithms.
この分野は系列CertificateのsignatureAlgorithm分野と同じアルゴリズム識別子を含まなければなりません。(秒に遭遇してください。 4.1.1.2). 特定されたアルゴリズムによると、任意のパラメタ分野のコンテンツは異なるでしょう。 セクション7.2はサポートしている署名アルゴリズムを記載します。
4.1.2.4 Issuer
4.1.2.4 発行人
The issuer field identifies the entity who 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 {
RDNSequence }
以下を命名してください:= 選択RDNSequence
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RDNSequence:、:= RelativeDistinguishedNameの系列
RelativeDistinguishedName ::=
SET OF AttributeTypeAndValue
RelativeDistinguishedName:、:= AttributeTypeAndValueのセット
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
AttributeTypeAndValue:、:= 系列AttributeType、値のAttributeValueをタイプしてください。
AttributeType ::= OBJECT IDENTIFIER
AttributeType:、:= オブジェクト識別子
AttributeValue ::= ANY DEFINED BY AttributeType
AttributeValue:、:= 何でもAttributeTypeによって定義されます。
Housley, et. al. Standards Track [Page 18] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[18ページ]。
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つの最大))、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. The UTF8String encoding is the preferred encoding, and all certificates issued after December 31, 2003 MUST use the UTF8String encoding of DirectoryString (except as noted below). Until that date, conforming CAs MUST choose from the following options when creating a distinguished name, including their own:
DirectoryStringタイプはPrintableString、TeletexString、BMPString、UTF8String、およびUniversalStringの選択と定義されます。 UTF8Stringコード化は、都合のよいコード化と、すべて、2003年12月31日がDirectoryString(以下に述べられるのを除いた)のUTF8Stringコード化を使用しなければならなかった後に発行された証明書です。 それら自身のを含む分類名を作成するとき、その日付まで、CAsを従わせるのは以下のオプションから選ばれなければなりません:
(a) if the character set is sufficient, the string MAY be
represented as a PrintableString;
(a) 文字集合が十分であるなら、ストリングはPrintableStringとして表されるかもしれません。
(b) failing (a), if the BMPString character set is sufficient the
string MAY be represented as a BMPString; and
(b) (a)に失敗して、BMPString文字集合が十分であるなら、ストリングはBMPStringとして表されるかもしれません。 そして
(c) failing (a) and (b), the string MUST be represented as a
UTF8String. If (a) or (b) is satisfied, the CA MAY still choose
to represent the string as a UTF8String.
(c) (a)と(b)に失敗して、UTF8Stringとしてストリングを表さなければなりません。 (a)か(b)が満たされているなら、カリフォルニアは、UTF8Stringとしてストリングを表すのをまだ選んでいるかもしれません。
Exceptions to the December 31, 2003 UTF8 encoding requirements are as follows:
要件をコード化する2003年12月31日UTF8への例外は以下の通りです:
(a) CAs MAY issue "name rollover" certificates to support an
orderly migration to UTF8String encoding. Such certificates would
include the CA's UTF8String encoded name as issuer and and the old
name encoding as subject, or vice-versa.
(a) CAsは、UTF8Stringコード化に規則的な移行をサポートするために「名前ロールオーバー」証明書を発行するかもしれません。 そして、そのような証明書が発行人として名義でコード化されたCAのUTF8Stringを含んでいるだろう、そして、対象として逆もまた同様にコード化される旧名。
(b) As stated in section 4.1.2.6, the subject field MUST be
populated with a non-empty distinguished name matching the
contents of the issuer field in all certificates issued by the
subject CA regardless of encoding.
(b) セクション4.1.2で.6、対象の分野がそうしなければならないと述べるように、非空の分類名がコード化にかかわらず対象のカリフォルニアによって発行されたすべての証明書の発行人分野のコンテンツに合っていて、居住されてください。
The TeletexString 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. Certificate users SHOULD be prepared to receive certificates with these types.
TeletexStringとUniversalStringを後方の互換性のために含んで、新しい対象のための証明書に使用するべきではありません。 しかしながら、これらのタイプは名前が以前に確立された証明書で使用されるかもしれません。 これらのタイプで証明書を受け取るために準備されていて、ユーザSHOULDを証明してください。
Housley, et. al. Standards Track [Page 19] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[19ページ]。
In addition, many legacy implementations support names encoded in the ISO 8859-1 character set (Latin1String) but tag them as TeletexString. The Latin1String includes characters used in Western European countries which are not part of the TeletexString charcter set. Implementations that process TeletexString SHOULD be prepared to handle the entire ISO 8859-1 character set.[ISO 8859-1]
さらに、多くのレガシー実装が、ISO8859-1文字集合(Latin1String)でコード化された名前をサポートしますが、TeletexStringとしてそれらにタグ付けをします。 Latin1StringはTeletexString charcterセットの一部でない西洋の欧州諸国で使用されるキャラクタを含んでいます。 全体のISO8859-1文字集合を扱うために準備されていて、TeletexString SHOULDを処理する実装。[ISO8859-1]
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 also recommends support for additional attribute types.
上で述べたように、分類名は属性で構成されます。 この仕様は名前に現れるかもしれない属性タイプのセットを制限しません。 しかしながら、発行人名が以下で定義された属性タイプのセットを含んでいて証明書を受け取るように実装を従わせるのを準備しなければなりません。 また、この仕様は追加属性タイプのサポートを推薦します。
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 names: country, organization, organizational-unit, distinguished name qualifier, state or province name, and common name (e.g., "Susan Housley"). In addition, implementations of this specification SHOULD be prepared to receive the following standard attribute types in issuer names: locality, title, surname, given name, initials, and generation qualifier (e.g., "Jr.", "3rd", or "IV"). The syntax and associated object identifiers (OIDs) for these attribute types are provided in the ASN.1 modules in Appendices A and B.
属性の標準セットは仕様のX.500シリーズで定義されました。発行人名で以下の標準の属性タイプを受けるようにこの仕様の[X.520]実装を準備しなければなりません: 国か組織か組織的なユニットか分類名資格を与える人か州か州名と、一般名(例えば、「スーザンHousley」)。 追加、実装、この仕様SHOULDでは、準備されていて、以下の標準の属性を受けるのは発行人名で以下をタイプします。 場所、タイトル、姓、名、イニシャル、および世代資格を与える人(例えば、「Jr.」、「3番目」、または「IV」)。 これらの属性タイプへの構文と関連オブジェクト識別子(OIDs)をAppendices AとBのASN.1モジュールに提供します。
In addition, implementations of this specification MUST be prepared to receive the domainComponent attribute, as defined in [RFC 2247]. The Domain (Nameserver) System (DNS) provides a hierarchical resource labeling system. This attribute provides is 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 field. Implementations are not required to convert such names into DNS names. The syntax and associated OID for this attribute type is provided in the ASN.1 modules in Appendices A and B.
追加、仕様を準備しなければならないこの実装では、[RFC2247]で定義されるようにdomainComponent属性を受けてください。 Domain(ネームサーバ)システム(DNS)は階層的なリソースラベリングシステムを提供します。 属性が提供するこれは彼らのDNS名に沿うDNsを使用したがっている組織に、便利なメカニズムです。 これは代替名分野のdNSNameの部品へのリプレースメントではありません。 実装は、そのような名前をDNS名に変換するのに必要ではありません。 Appendices AとBのASN.1モジュールにこの属性タイプのための構文の、そして、関連しているOIDを提供します。
Certificate users MUST be prepared to process the issuer distinguished name and subject distinguished name (see sec. 4.1.2.6) fields to perform name chaining for certification path validation (see section 6). Name chaining is performed by matching the issuer distinguished name in one certificate with the subject name in a CA certificate.
証明書ユーザは発行人分類名と対象の分類名を処理する用意ができていなければなりません。(秒に遭遇してください。 4.1.2.6) 実行する分野は証明経路合法化のための推論を命名します(セクション6を見てください)。 名前推論は、1通の証明書の発行人分類名をカリフォルニア証明書の対象の名前に合わせることによって、実行されます。
This specification requires only a subset of the name comparison functionality specified in the X.500 series of specifications. The requirements for conforming implementations are as follows:
この仕様は仕様のX.500シリーズで指定された名前比較の機能性の部分集合だけを必要とします。 実装を従わせるための要件は以下の通りです:
Housley, et. al. Standards Track [Page 20] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[20ページ]。
(a) attribute values encoded in different types (e.g.,
PrintableString and BMPString) may be assumed to represent
different strings;
(a) 異なったタイプ(例えば、PrintableStringとBMPString)でコード化された属性値が異なったストリングを表すと思われるかもしれません。
(b) attribute values in types other than PrintableString are case
sensitive (this permits matching of attribute values as binary
objects);
(b) PrintableString以外のタイプによる属性値は大文字と小文字を区別しています(これは、2進のオブジェクトとして属性値を合わせることを許可します)。
(c) attribute values in PrintableString are not case sensitive
(e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and
(c) PrintableStringの属性値は大文字と小文字を区別していません(例えば、「マリアンエ・スワンソン」は「マリアンエ・スワンソン」と同じです)。 そして
(d) attribute values in PrintableString are compared after
removing leading and trailing white space and converting internal
substrings of one or more consecutive white space characters to a
single space.
(d) 主で引きずっている余白を取り除いて、1つ以上の連続した白い間隔文字の内部のサブストリングを変換した後に、PrintableStringの属性値はシングルスペースと比較されます。
These name comparison rules permit a certificate user to validate certificates issued using languages or encodings unfamiliar to the certificate user.
これらの名前比較規則は、証明書ユーザが言語を使用することで発行された証明書か証明書ユーザにとって、なじみのないencodingsを有効にすることを許可します。
In addition, implementations of this specification MAY use these comparison rules to process unfamiliar attribute types for name chaining. This allows implementations to process certificates with unfamiliar attributes in the issuer name.
さらに、この仕様の実装は、名前推論のためのなじみのない属性タイプを処理するのにこれらの比較規則を使用するかもしれません。 これで、なじみのない属性が発行人名にある状態で、実装は証明書を処理できます。
Note that the comparison rules defined in the X.500 series of specifications indicate that the character sets used to encode data in distinguished names are irrelevant. The characters themselves are compared without regard to encoding. Implementations of the profile are permitted to use the comparison algorithm defined in the X.500 series. Such an implementation will recognize a superset of name matches recognized by the algorithm specified above.
仕様のX.500シリーズで定義された比較規則が、分類名でデータを暗号化するのに使用される文字集合が無関係であることを示すことに注意してください。 キャラクタ自体は関係なしでコード化と比較されます。 プロフィールの実装がX.500シリーズで定義された比較アルゴリズムを使用することが許可されています。 そのような実装は上で指定されたアルゴリズムで認識された名前マッチのスーパーセットを認識するでしょう。
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.
このプロフィールに従うCAsはUTCTimeとしていつも証明書使用期限から2049年をコード化しなければなりません。 2050か後でGeneralizedTimeとして証明書使用期限をコード化しなければなりません。
Housley, et. al. Standards Track [Page 21] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[21ページ]。
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 international applications where local time alone is not adequate. 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 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年は19YYとして解釈されるものとします。 そして
Where YY is less than 50, the year shall be interpreted as 20YY.
YYが50歳未満であるところでは、1年は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 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 4.2.1.10, 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 (see sec. 4.1.2.4) in all certificates issued by the subject CA. 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.
対象の分野は対象の公開鍵分野に保存される公開鍵に関連している実体を特定します。 対象の名前は対象の分野、そして/または、subjectAltName拡張子で運ばれるかもしれません。 対象がカリフォルニアである、(例えば、中で議論するとしての基本的な規制拡大、4.2、.1、.10、cAのプレゼントと値がTRUEであるということである、)、そして、非空の分類名が発行人分野のコンテンツに合っていて、対象の分野に居住しなければなりません。(秒に遭遇してください。 4.1.2.4) 対象のカリフォルニアによって発行されたすべての証明書で。 対象の命名情報がsubjectAltName拡張子だけで存在しているなら(例えばキーはEメールアドレスかURIだけに固まりました)、対象の名前は空の系列であるに違いありません、そして、subjectAltName拡張子は重要であるに違いありません。
Housley, et. al. Standards Track [Page 22] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[22ページ]。
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 name 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 name field is defined as the X.501 type Name. Implementation requirements for this field are those defined for the issuer field (see sec. 4.1.2.4). When encoding attribute values of type DirectoryString, the encoding rules for the issuer field MUST be implemented. 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 Appendices A and B. Implementations of this specification MAY use these comparison rules to process unfamiliar attribute types (i.e., for name chaining). This allows implementations to process certificates with unfamiliar attributes in the subject name.
対象の名前欄はX.501タイプNameと定義されます。 この分野のための実装要件は発行人分野と定義されたものです。(秒に遭遇してください。 4.1.2.4). タイプDirectoryStringの属性値をコード化するとき、発行人分野への符号化規則を実装しなければなりません。 発行人分野に必要である属性タイプを含む対象の名前を受け取るようにこの仕様の実装を準備しなければなりません。 実装、この仕様SHOULDでは、発行人分野のためのお勧めの属性タイプを含む対象の名前を受け取るように用意してください。 これらの属性タイプへの構文と関連オブジェクト識別子(OIDs)はASNでは、この仕様のAppendices AとB.Implementationsの.1のモジュールがなじみのない属性タイプ(すなわち、名前推論のための)を処理するのにこれらの比較規則を使用するかもしれないかどうかということです。 これで、なじみのない属性が対象の名前にある状態で、実装は証明書を処理できます。
In addition, legacy implementations exist where an RFC 822 name is embedded in the subject distinguished name as an EmailAddress attribute. 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., "fanfeedback@redsox.com" is the same as "FANFEEDBACK@REDSOX.COM").
さらに、レガシー実装はRFC822名がEmailAddress属性として対象の分類名に埋め込まれているところに存在しています。 EmailAddressのための属性値は、キャラクタ'@'の包含を可能にするためにはタイプIA5Stringのものです。(包含はPrintableString文字集合の一部ではありません)。 EmailAddress属性値は大文字と小文字を区別していません(例えば、" fanfeedback@redsox.com "は" FANFEEDBACK@REDSOX.COM "と同じです)。
Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name field (see sec. 4.2.1.7) 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.7) そのようなアイデンティティについて説明するために。 レガシー実装をサポートする対象の分類名での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. 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 section 7.3.
この分野は、公開鍵を運んで、キーが使用されているアルゴリズムを特定するのに使用されます。 アルゴリズムは、セクション4.1.1で.2に指定されたAlgorithmIdentifier構造を使用することで特定されます。 サポートしているアルゴリズムのためのオブジェクト識別子と公開鍵の材料(公開鍵とパラメタ)をコード化するためのメソッドはセクション7.3で指定されます。
Housley, et. al. Standards Track [Page 23] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[23ページ]。
4.1.2.8 Unique Identifiers
4.1.2.8 ユニークな識別子
These fields may only appear if the version is 2 or 3 (see sec. 4.1.2.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 SHOULD NOT generate certificates with unique identifiers. Applications conforming to this profile SHOULD be capable of parsing unique identifiers and making comparisons.
これらの野原はバージョンが2か3である場合にだけ現れるかもしれません。(秒に遭遇してください。 4.1.2.1). 対象と発行人のユニークな識別子は時間がたつにつれて対象、そして/または、発行人名の再利用の可能性を扱う証明書に存在しています。 このプロフィールは、名前が異なった実体のために再利用されないで、またインターネット証明書がユニークな識別子を利用しないことを勧めます。 このプロフィールSHOULD NOTに従うCAsがユニークな識別子で証明書を作ります。 これに従うアプリケーションはユニークな識別子を分析できて、比較をするSHOULDの輪郭を描きます。
4.1.2.9 Extensions
4.1.2.9 拡大
This field may only appear if the version is 3 (see sec. 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 is defined in section 4.2.
この野原はバージョンが3である場合にだけ現れるかもしれません。(秒に遭遇してください。 4.1.2.1). 存在しているなら、この分野は1つ以上の証明書拡張子のSEQUENCEです。 インターネットPKIの証明書拡張子の書式と内容はセクション4.2で定義されます。
4.2 Standard 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 the certification hierarchy. 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 may be designated as critical or non-critical. A certificate using system MUST reject the certificate if it encounters a critical extension it does not recognize; however, a non-critical extension may be ignored if it is not 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 should be exercised in adopting any critical extensions in certificates which might prevent use in a general context.
X.509 v3証明書のために定義された拡大は追加属性をユーザか公開鍵に関連づけて、証明階層構造を管理するためのメソッドを提供します。 また、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 encoded structure is the value of the octet string extnValue. Only one instance of a particular extension may appear in a particular certificate. For example, a certificate may contain only one authority key identifier extension (see sec. 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.
各拡大はOIDとASN.1構造を含んでいます。 拡大が証明書に現れるとき、分野extnIDと対応するASN.1のコード化された構造が八重奏ストリングextnValueの値であるので、OIDは現れます。 特定の拡大の1つのインスタンスだけが特定の証明書に現れるかもしれません。 例えば、証明書は1つの権威の主要な識別子拡張子だけを含むかもしれません。(秒に遭遇してください。 4.2.1.1). 拡大はFALSEのデフォルト値で重要な論理演算子を含んでいます。 各拡大のためのテキストは臨界磁場に許容値を指定します。
Housley, et. al. Standards Track [Page 24] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[24ページ]。
Conforming CAs MUST support key identifiers (see sec. 4.2.1.1 and 4.2.1.2), basic constraints (see sec. 4.2.1.10), key usage (see sec. 4.2.1.3), and certificate policies (see sec. 4.2.1.5) extensions. If the CA issues certificates with an empty sequence for the subject field, the CA MUST support the subject alternative name extension (see sec. 4.2.1.7). Support for the remaining extensions is OPTIONAL. Conforming CAs may support extensions that are not identified within this specification; certificate issuers are cautioned that marking such extensions as critical may inhibit interoperability.
CAsを従わせると、主要な識別子はサポートしなければなりません。(秒に遭遇してください。 4.2.1.1、4.2、.1、.2), 基本的な規制(秒に遭遇してください。 4.2.1.10), 主要な用法(秒に遭遇してください。 4.2.1.3), そして、方針を証明してください。(秒に遭遇してください。 4.2.1.5) 拡大。 カリフォルニアが空の系列で対象の分野に証明書を発行するなら、カリフォルニアは、対象が代替の名前拡大であるとサポートしなければなりません。(秒に遭遇してください。 4.2.1.7). 残っている拡大のサポートはOPTIONALです。 CAsを従わせると、この仕様の中で特定されない拡大はサポートするかもしれません。 証明書発行人は重要であるような拡大をマークすると相互運用性が禁止されるかもしれないと警告されます。
At a minimum, applications conforming to this profile MUST recognize the extensions which must or may be critical in this specification. These extensions are: key usage (see sec. 4.2.1.3), certificate policies (see sec. 4.2.1.5), the subject alternative name (see sec. 4.2.1.7), basic constraints (see sec. 4.2.1.10), name constraints (see sec. 4.2.1.11), policy constraints (see sec. 4.2.1.12), and extended key usage (see sec. 4.2.1.13).
最小限では、このプロフィールに従うアプリケーションは重要でなければならないか、またはこの仕様で重要であるかもしれない拡大を認識しなければなりません。 これらの拡大は以下の通りです。 主要な用法(秒に遭遇してください。 4.2.1.3), 証明書方針(秒に遭遇してください。 4.2.1.5), 対象の代替名(秒に遭遇してください。 4.2.1.7), 基本的な規制(秒に遭遇してください。 4.2.1.10), 名前規制(秒に遭遇してください。 4.2.1.11), 方針規制(秒に遭遇してください。 4.2.1.12), そして、拡張主要な用法(秒に遭遇してください。 4.2.1.13).
In addition, this profile RECOMMENDS application support for the authority and subject key identifier (see sec. 4.2.1.1 and 4.2.1.2) extensions.
追加、権威と対象の主要な識別子のこのプロフィールRECOMMENDSアプリケーションサポートで(秒に遭遇してください。 4.2.1.1、4.2、.1、.2) 拡大。
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 on 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 chain building. 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. In this case, the subject and authority key identifiers would be identical.
チェーンビルを容易にするためにCAsを従わせることによって作られたすべての証明書にauthorityKeyIdentifier拡張子のkeyIdentifier分野を含まなければなりません。 1つの例外があります。 カリフォルニアが「自己によって署名している」証明書の形で公開鍵を分配するところでは、権威の主要な識別子は省略されるかもしれません。 この場合、対象と権威重要識別子は同じでしょう。
Housley, et. al. Standards Track [Page 25] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[25ページ]。
The value of the keyIdentifier field SHOULD be derived from the public key used to verify the certificate's signature or a method that generates unique values. Two common methods for generating key identifiers from the public key are described in (sec. 4.2.1.2). One common method for generating unique values isdescribed in (sec. 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.
keyIdentifierの値は証明書の署名について確かめるのに使用される公開鍵かユニークな値を生成するメソッドから派生していた状態でSHOULDをさばきます。 公開鍵からの主要な識別子が説明される生成する2つの共通方法(秒 4.2.1.2). ユニークな値を生成するための一般的なメソッドがisdescribedした1(秒 4.2.1.2). 主要な識別子が以前に確立されていないところでは、この仕様はこれらのメソッドの1つのkeyIdentifiersを生成する使用を推薦します。
This profile recommends support for the key identifier method by all certificate users.
このプロフィールはすべての証明書ユーザで主要な識別子メソッドのサポートを推薦します。
This extension MUST NOT be marked critical.
重要であるとこの拡大をマークしてはいけません。
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 chain building, this extension MUST appear in all con- forming CA certificates, that is, all certificates including the basic constraints extension (see sec. 4.2.1.10) where the value of cA is TRUE. The value of the subject key identifier MUST be the value placed in the key identifier field of the Authority Key Identifier extension (see sec. 4.2.1.1) of certificates issued by the subject of this certificate.
チェーンビルを容易にするために、カリフォルニア証明書、すなわち、基本的な規制拡大を含むすべての証明書を形成して、この拡大はすべてのまやかしに現れなければなりません。(秒に遭遇してください。 4.2.1.10) cAの値がTRUEであるところ。 対象の主要な識別子の値はAuthority Key Identifier拡張子の主要な識別子分野に置かれた値でなければなりません。(秒に遭遇してください。 4.2.1.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ハッシュで構成されます。
(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.
(2) keyIdentifierはBIT STRING subjectPublicKeyの価値のSHA-1ハッシュの最も重要でない60ビットに従って0100が続いた値で4ビット型分野から構成されます。
Housley, et. al. Standards Track [Page 26] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[26ページ]。
One common method for generating unique values is a monotomically increasing sequence of integers.
ユニークな値を生成するための1つの共通方法が整数のmonotomically増加する系列です。
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 identificiation the appropriate end entity certificate, this extension SHOULD be included in all end entity certificates.
終わりの実体証明書のために、対象の主要な識別子拡張子はアプリケーションで使用される特定の公開鍵を含む証明書を特定するための手段を提供します。 終わりの実体が特に複数のCAsから複数の証明書を入手したところに、対象の主要な識別子はすぐに特定の公開鍵を含む証明書のセットを特定する手段を提供します。 適切な終わりの実体が証明するidentificiation、この拡大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 identifed above.
終わりの実体証明書に関しては、公開鍵から派生していた状態で主要な識別子SHOULDをかけてください。 公開鍵からの主要な識別子を生成するための2つの共通方法が上でidentifedされます。
Where a key identifier has not been previously established, this specification recommends use of one of these methods for generating keyIdentifiers.
主要な識別子が以前に確立されていないところでは、この仕様はこれらのメソッドの1つのkeyIdentifiersを生成する使用を推薦します。
This extension MUST NOT be marked critical.
重要であるとこの拡大をマークしてはいけません。
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 for signing, 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. When used, this extension SHOULD be marked critical.
主要な用法拡大は証明書に含まれたキーの目的(例えば、暗号文、署名は署名を証明する)を定義します。 1つ以上の操作に使用できたキーが制限されることになっているとき、用法制限は使われるかもしれません。 RSAキーが署名にだけ使用されるべきであるとき、例えば、digitalSignature、そして/または、nonRepudiationビットは断言されるでしょう。 RSAキーがかぎ管理にだけ使用されるべきであるとき、同様に、keyEnciphermentビットは断言されるでしょう。 使用されるいつ、この拡大SHOULD、重要であるとマークされてくださいか。
id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
イドCe keyUsage、オブジェクト識別子:、:= イドCe15
KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1),
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5),
KeyUsage:、:= ビット列、digitalSignature(0)、nonRepudiation(1)、keyEncipherment(2)、dataEncipherment(3)、keyAgreement(4)、keyCertSign(5)
Housley, et. al. Standards Track [Page 27] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[27ページ]。
cRLSign (6),
encipherOnly (7),
decipherOnly (8) }
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 with a digital signature mechanism to support security
services other than non-repudiation (bit 1), certificate signing
(bit 5), or revocation information signing (bit 6). Digital
signature mechanisms are often used for entity authentication and
data origin authentication with integrity.
対象の公開鍵がセキュリティが非拒否(ビット1)((ビット5)、または取消しが(ビット6)に署名する情報であると署名する証明書)以外のサービスであるとサポートするのにデジタル署名メカニズムと共に使用されるとき、digitalSignatureビットは断言されます。 デジタル署名メカニズムは保全がある実体認証とデータ発生源認証にしばしば使用されます。
The nonRepudiation bit is asserted when the subject public key is
used to verify digital signatures used to provide a non-
repudiation service which protects against the signing entity
falsely denying some action, excluding certificate or CRL signing.
対象の公開鍵が間違って署名実体から守る非拒否しているサービスを提供するのに何らかの動作を否定しながら使用されるデジタル署名について確かめるのに使用されるとき、nonRepudiationビットは断言されます、証明書かCRL署名を除いて。
The keyEncipherment bit is asserted when the subject public key is
used for key transport. For example, when an RSA key is to be
used for key management, then this bit shall asserted.
対象の公開鍵が主要な輸送に使用されるとき、keyEnciphermentビットは断言されます。 例えば、RSAキーがかぎ管理に使用されることになっているとき、そして、断言されて、このビットは使用になることになっているでしょう。
The dataEncipherment bit is asserted when the subject public key
is used for enciphering user data, other than cryptographic keys.
対象の公開鍵が暗号化キー以外の利用者データを暗号化するのに使用されるとき、dataEnciphermentビットは断言されます。
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 shall asserted.
対象の公開鍵が主要な協定に使用されるとき、keyAgreementビットは断言されます。 例えば、ディフィー-ヘルマンキーがかぎ管理に使用されることになっているとき、そして、断言されて、このビットは使用になることになっているでしょう。
The keyCertSign bit is asserted when the subject public key is
used for verifying a signature on certificates. This bit may only
be asserted in CA certificates.
対象の公開鍵が証明書の上に署名について確かめるのに使用されるとき、keyCertSignビットは断言されます。 このビットはカリフォルニア証明書で断言されるだけであるかもしれません。
The cRLSign bit is asserted when the subject public key is used
for verifying a signature on revocation information (e.g., a CRL).
対象の公開鍵が取消し情報(例えば、CRL)で署名について確かめるのに使用されるとき、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ビットが設定されるとき、対象の公開鍵は、主要な協定を実行している間、データを解読するのにだけ使用されるかもしれません。
Housley, et. al. Standards Track [Page 28] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[28ページ]。
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 section 7.3.
このプロフィールはkeyUsage拡張子の具体化で設定されるかもしれないビットの組み合わせを制限しません。 しかしながら、特定のアルゴリズムのためのkeyUsage拡張子のための適切な値はセクション7.3で指定されます。
4.2.1.4 Private Key Usage Period
4.2.1.4 秘密鍵用法の期間
This profile recommends against the use of this extension. CAs conforming to this profile MUST NOT generate certificates with critical private key usage period extensions.
このプロフィールはこれの使用に対して拡大を推薦します。 このプロフィールに従うCAsは重要な秘密鍵用法期間の延期がある証明書を作ってはいけません。
The private key usage period extension allows the certificate issuer to specify a different validity period for the private key than the certificate. This extension is intended for use with digital signature keys. This extension consists of two optional components, notBefore and notAfter. The private key associated with the certificate should not be used to sign objects before or after the times specified by the two components, respectively. CAs conforming to this profile MUST NOT generate certificates with private key usage period extensions unless at least one of the two components is present.
秘密鍵用法期間の延期で、証明書発行人は証明書と異なった有効期間を秘密鍵に指定できます。 この拡大は使用のためにデジタル署名キーで意図します。 この拡大は2つの任意のコンポーネント、notBefore、およびnotAfterから成ります。 2つのコンポーネントによってそれぞれ指定された回前または後にオブジェクトに署名するのに証明書に関連している秘密鍵を使用するべきではありません。 少なくとも2つのコンポーネントの1つが存在していない場合、このプロフィールに従うCAsは秘密鍵用法期間の延期がある証明書を作ってはいけません。
Where used, notBefore and notAfter are represented as GeneralizedTime and MUST be specified and interpreted as defined in section 4.1.2.5.2.
使用されるところでは、セクション4.1.2で.2に.5を定義するとき、notBeforeとnotAfterはGeneralizedTimeとして表されて、指定していなければならなくて、解釈されます。
id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 }
イドCe privateKeyUsagePeriod、オブジェクト識別子:、:= イドCe16
PrivateKeyUsagePeriod ::= SEQUENCE {
notBefore [0] GeneralizedTime OPTIONAL,
notAfter [1] GeneralizedTime OPTIONAL }
PrivateKeyUsagePeriod:、:= 系列notBefore[0]GeneralizedTime任意であって、notAfter[1]GeneralizedTime任意です。
4.2.1.5 Certificate Policies
4.2.1.5 証明書方針
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. These policy information terms indicate the policy under which the certificate has been issued and the purposes for which the certificate may be used. Optional qualifiers, which may be present, are not expected to change the definition of the policy.
証明書方針拡張子はより多くのある方針情報用語の系列を含んでいます。それはオブジェクト識別子(OID)と任意の資格を与える人からそれぞれ成ります。 これらの方針情報用語は証明書が発行された方針と証明書が使用されるかもしれない目的を示します。 任意の資格を与える人(出席しているかもしれません)が方針の定義を変えないと予想されます。
Applications with specific policy requirements are expected to have a list of those policies which 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をそのリストと比較すると予想されます。 この拡大が重要であるなら、経路合法化ソフトウェアは、この拡大(任意の資格を与える人を含んでいる)を解釈できなければならないか、または証明書を拒絶しなければなりません。
Housley, et. al. Standards Track [Page 29] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[29ページ]。
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 use of qualifiers be limited to those identified in this section.
相互運用性を促進するために、その方針情報用語のこのプロフィールRECOMMENDSはOIDだけから成ります。 OIDだけが不十分であるところでは、このプロフィールは、資格を与える人の使用がこのセクションで特定されたものに制限されることを強く勧めます。
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.
CPS Pointer資格を与える人はカリフォルニアによって発行されたCertification Practice Statement(CPS)に指針を含みます。 指針がURIの形にあります。
User notice is intended for display to a relying party when a certificate is used. The application software SHOULD display all user notices in all certificates of the certification path used, except that if a notice is 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.
証明書が使用されているとき、ユーザ通知はディスプレイのために信用パーティーに意図します。 アプリケーション・ソフトSHOULDは証明経路のすべての証明書における通知が使用したすべてのユーザを表示します、通知をコピーするならコピー1部だけを表示しなければならないのを除いて。 そのような複製、この資格を与える人SHOULDを防ぐには、終わり実体証明書と他の組織に発行されたカリフォルニア証明書に単に存在してください。
The user notice has two optional fields: the noticeRef field and the explicitText field.
ユーザ通知には、2つの任意の分野があります: noticeRef分野とexplicitText分野。
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.
explicitText分野は直接証明書に原文の声明を含んでいます。 explicitText分野は200のキャラクタの最大サイズがあるストリングです。
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オプションで示された通知テキストの場所を見つけることができるなら、そのテキストを表示するべきです。 さもなければ、explicitTextストリングを表示するべきです。
id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
イドCe certificatePolicies、オブジェクト識別子:、:= イドCe32
certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
certificatePolicies:、:= PolicyInformationの系列サイズ(1..MAX)
Housley, et. al. Standards Track [Page 30] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[30ページ]。
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 {
visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200)) }
DisplayText:、:= 選択visibleString VisibleString(サイズ(1 .200))、bmpString BMPString(サイズ(1 .200))、utf8String UTF8String(サイズ(1 .200))
4.2.1.6 Policy Mappings
4.2.1.6 方針マッピング
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に同等であると考えるのを示します。
Housley, et. al. Standards Track [Page 31] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[31ページ]。
The issuing CA's users may accept an issuerDomainPolicy for certain applications. The policy mapping tells the issuing CA's users which policies associated with the subject CA are comparable to the policy they accept.
発行CAのユーザはあるアプリケーションのためにissuerDomainPolicyを受け入れるかもしれません。 方針マッピングは、対象のカリフォルニアに関連しているどの方針がそれらが受け入れる方針に匹敵しているかを発行CAのユーザに言います。
This extension may be supported by CAs and/or applications, and it MUST be non-critical.
この拡大はCAs、そして/または、アプリケーションでサポートされるかもしれません、そして、それは非臨界であるに違いありません。
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.7 Subject Alternative Name
4.2.1.7 対象の代替名
The subject alternative names extension allows additional identities to be bound to the subject of the certificate. Defined options include an Internet electronic mail 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.
対象の代替名拡大で、追加アイデンティティは証明書の対象に付きます。 定義されたオプションはインターネット電子メールアドレス、DNS名、IPアドレス、および一定のリソース識別子(URI)を含んでいます。 完全に地方の定義を含んでいて、別の選択肢は存在しています。 複数の名前フォーム、およびそれぞれの名前フォームの複数のインスタンスが含まれるかもしれません。 証明書に縛られるそのようなアイデンティティがことであるときはいつも、拡大という対象の代替名(または、発行人代替名)を使用しなければなりません。
Because the subject alternative name is considered to be definitiviely bound to the public key, all parts of the subject alternative name MUST be verified by the CA.
対象の代替名によってdefinitivielyに公開鍵に縛られると考えられるので、カリフォルニアは対象の代替名のすべての部分について確かめなければなりません。
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, the subjectAltName extension MUST be marked critical.
さらに、対象の分類名は証明書にアイデンティティを含んでいる唯一の対象が代替名フォーム(例えば、電子メールアドレス)であるなら空でなければなりません、そして、(空の系列)subjectAltName拡張子は存在していなければなりません。 対象の分野が空の系列を含んでいるなら、重要であるとsubjectAltName拡張子をマークしなければなりません。
When the subjectAltName extension contains an Internet mail address, the address MUST be included as an rfc822Name. The format of an rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An addr-spec has the form "local-part@domain". Note that an addr-spec 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 ">". Note that while upper and lower case letters are allowed in an RFC 822 addr-spec, no significance is attached to the case.
subjectAltName拡張子がインターネット郵便の宛先を含むとき、rfc822Nameとしてアドレスを含まなければなりません。 rfc822Nameの形式はRFC822[RFC822]で定義されるように「addr-仕様」です。 addr-仕様には、フォーム" local-part@domain "があります。 addr-仕様がそれの前に句(一般名などの)を全く持たないで、またそれの後にノーコメント(括弧で囲まれたテキスト)を持って、"<"と">"によって囲まれないことに注意してください。 大文字と小文字手紙がRFC822addr-仕様に許容されている間意味が全くケースに付けられていないことに注意してください。
When the subjectAltName extension contains a iPAddress, the address MUST be stored in the octet string in "network byte order," as specified in RFC 791 [RFC 791]. The least significant bit (LSB) of
subjectAltName拡張子がiPAddressを含むとき、八重奏ストリングに「ネットワークバイトオーダー」でアドレスを保存しなければなりません、RFC791[RFC791]で指定されるように。 最下位ビット(LSB)
Housley, et. al. Standards Track [Page 32] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[32ページ]。
each octet is the LSB of the corresponding byte in the network address. For IP Version 4, as specified in RFC 791, the octet string MUST contain exactly four octets. For IP Version 6, as specified in RFC 1883, the octet string MUST contain exactly sixteen octets [RFC 1883].
各八重奏はネットワーク・アドレスの対応するバイトのLSBです。 IPバージョン4のために、RFC791で指定されるように、八重奏ストリングはまさに4つの八重奏を含まなければなりません。 IPバージョン6のために、RFC1883で指定されるように、八重奏ストリングはまさに16の八重奏[RFC1883]を含まなければなりません。
When the subjectAltName extension contains a domain name service label, the domain name MUST be stored in the dNSName (an IA5String). The name MUST be in the "preferred name syntax," as specified by RFC 1034 [RFC 1034]. Note that while upper and lower case letters are allowed in domain names, no signifigance is attached to the case. In addition, while the string " " is a legal domain name, subjectAltName extensions with a dNSName " " are not permitted. Finally, the use of the DNS representation for Internet mail addresses (wpolk.nist.gov instead of wpolk@nist.gov) is not permitted; such identities are to be encoded as rfc822Name.
subjectAltName拡張子がドメイン名サービスラベルを含むとき、dNSName(IA5String)にドメイン名を保存しなければなりません。 RFC1034[RFC1034]によって指定されるように名前が「都合のよい名前構文」であるに違いありません。 大文字と小文字手紙がドメイン名で許容されていますが、signifiganceが全くケースに取り付けられないことに注意してください。 さらに、ストリングをゆったり過ごしてください、「「法的なドメイン名、subjectAltNameはdNSNameとの拡大である」、「受入れられない、」 最終的に、インターネット郵便の宛先( wpolk@nist.gov の代わりにwpolk.nist.gov)のDNS表現の使用は受入れられません。 そのようなアイデンティティはrfc822Nameとしてコード化されることです。
When the subjectAltName extension contains a URI, the name MUST be stored in the uniformResourceIdentifier (an IA5String). The name MUST be a non-relative URL, and MUST follow the URL syntax and encoding rules specified in [RFC 1738]. The name must include both a scheme (e.g., "http" or "ftp") and a scheme-specific-part. The scheme- specific-part must include a fully qualified domain name or IP address as the host.
subjectAltName拡張子がURIを含むとき、uniformResourceIdentifier(IA5String)に名前を保存しなければなりません。 名前は、非親類URLでなければならなく、[RFC1738]で指定されたURL構文と符号化規則に従わなければなりません。 名前は体系(例えば、"http"か"ftp")と体系の特定の部分の両方を含まなければなりません。 体系の特定の部分はホストとして完全修飾ドメイン名かIPアドレスを含まなければなりません。
As specified in [RFC 1738], the scheme name is not case-sensitive (e.g., "http" is equivalent to "HTTP"). The host part is also not case-sensitive, but other components of the scheme-specific-part may be case-sensitive. When comparing URIs, conforming implementations MUST compare the scheme and host without regard to case, but assume the remainder of the scheme-specific-part is case sensitive.
[RFC1738]で指定されるように、体系名は大文字と小文字を区別していません(例えば、"http"は「HTTP」に同等です)。 また、ホスト部分も大文字と小文字を区別していませんが、体系の特定の部分の他のコンポーネントは大文字と小文字を区別しているかもしれません。 特定の部分を計画しているのがURI、実装がケースに入れる関係なしで体系とホストを比較しますが、残りを仮定しなければならない従うことを突き合わせて大文字と小文字を区別しているとき。
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.11.
対象の代替名は、セクション4.2.1で.11に説明されるように名前規制拡張子を使用しながら、対象の分類名と同じ方法で抑制されるかもしれません。
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 that encounter such a certificate when processing a certificication path is not defined by this profile.
subjectAltName拡張子が存在しているなら、系列は少なくとも1つのエントリーを含まなければなりません。 対象の分野と異なって、CAsを従わせると、subjectAltNamesが人影のないGeneralName分野を含んでいる証明書は発行されてはいけません。 例えば、rfc822NameはIA5Stringとして表されます。 空のストリングが有効なIA5Stringである間、そのようなrfc822Nameはこのプロフィールによって受入れられません。 certificication経路を処理するときそのような証明書に遭遇するクライアントの振舞いはこのプロフィールによって定義されません。
Housley, et. al. Standards Track [Page 33] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[33ページ]。
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 shall 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.8 Issuer Alternative Names
4.2.1.8 発行人代替名
As with 4.2.1.7, this extension is used to associate Internet style identities with the certificate issuer. Issuer alternative names MUST be encoded as in 4.2.1.7.
4.2 .1 .7 この拡張子は、インターネットスタイルのアイデンティティを証明書発行人に関連づけるのに使用されます。 4.2のように発行人代替名をコード化しなければなりません。.1 .7。
Where present, this extension SHOULD NOT be marked critical.
現在のどこ、この拡大SHOULD NOT、重要であるとマークされてくださいか。
id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
イドCe issuerAltName、オブジェクト識別子:、:= イドCe18
IssuerAltName ::= GeneralNames
IssuerAltName:、:= GeneralNames
4.2.1.9 Subject Directory Attributes
4.2.1.9 テーマ別ディレクトリ属性
The subject directory attributes extension is not recommended as an essential part of this profile, but it may be used in local environments. This extension MUST be non-critical.
テーマ別ディレクトリ属性拡張子はこのプロフィールの不可欠の部分として推薦されませんが、それは地方の環境で使用されるかもしれません。 この拡大は非臨界であるに違いありません。
Housley, et. al. Standards Track [Page 34] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[34ページ]。
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
イドCe subjectDirectoryAttributes、オブジェクト識別子:、:= イドCe9
SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
SubjectDirectoryAttributes:、:= 属性の系列サイズ(1..MAX)
4.2.1.10 Basic Constraints
4.2.1.10 基本的な規制
The basic constraints extension identifies whether the subject of the certificate is a CA and how deep a certification path may exist through that CA.
基本的な規制拡大は証明書の対象がカリフォルニアであるかどうかと、どれくらい深い証明経路がそのカリフォルニアを通って存在するかもしれないかを特定します。
The pathLenConstraint field is meaningful only if cA is set to TRUE. In this case, it gives the maximum number of CA certificates that may follow this certificate in a certification path. A value of zero indicates that only an end-entity certificate may follow in the path. Where it appears, the pathLenConstraint field MUST be greater than or equal to zero. Where pathLenConstraint does not appear, there is no limit to the allowed length of the certification path.
cAがTRUEに用意ができている場合にだけ、pathLenConstraint分野は重要です。 この場合、それは証明経路でこの証明書に従うかもしれないカリフォルニア証明書の最大数を与えます。 ゼロの値は、終わり実体証明書だけが経路で従うかもしれないのを示します。 現れるところでは、pathLenConstraint分野はゼロ以上であるに違いありません。 pathLenConstraintが見えないところには、証明経路の許容長さへの限界が全くありません。
This extension MUST appear as a critical extension in all CA certificates. This extension SHOULD NOT appear in end entity certificates.
この拡大はすべてのカリフォルニア証明書における重要な拡大として現れなければなりません。 この拡大SHOULD NOTは終わりの実体証明書に現れます。
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.11 Name Constraints
4.2.1.11 名前規制
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 shall be located. Restrictions may apply to the subject distinguished name or 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.
名前規制拡張子(カリフォルニア証明書だけで使用しなければならない)は証明経路のその後の証明書のすべての対象の名前が位置するものとする名前スペースを示します。 制限は対象の分類名か対象の代替名に適用されるかもしれません。 形成という指定された名前が存在しているときだけ、制限は適用されます。 タイプの名前が全く証明書にないなら、証明書は許容できます。
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. This extension MUST be critical.
制限は受入れられたか除かれた名前下位木で定義されます。 excludedSubtrees分野で制限に合っているどんな名前もpermittedSubtreesに現れる情報にかかわらず無効です。 この拡大は重要であるに違いありません。
Within this profile, the minimum and maximum fields are not used with any name forms, thus minimum is always zero, and maximum is always absent.
このプロフィールの中では、最小の、そして、最大の分野はどんな名前フォームと共にも使用されません、そして、いつもその結果、最小であるのが、ゼロであり、最大はいつも欠けています。
Housley, et. al. Standards Track [Page 35] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[35ページ]。
For URIs, the constraint applies to the host part of the name. The constraint may specify a host or a domain. Examples would be "foo.bar.com"; and ".xyz.com". When the the constraint begins with a period, it may be expanded with one or more subdomains. That is, the constraint ".xyz.com" is satisfied by both abc.xyz.com and abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied by "xyz.com". When the constraint does not begin with a period, it specifies a host.
URIのために、規制は名前のホスト部分に適用されます。 規制はホストかドメインを指定するかもしれません。 例は"foo.bar.com"でしょう。 そして、".xyz.com"。 規制が期間で始まるとき、それは1つ以上のサブドメインで広げられるかもしれません。 すなわち、規制".xyz.com"はabc.xyz.comとabc.def.xyz.comの両方で満足しています。 しかしながら、規制".xyz.com"は"xyz.com"で満足していません。 規制が期間で始まらないと、それはホストを指定します。
A name constraint for Internat 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@xyz.com" indicates the root mailbox on the host "xyz.com". To indicate all Internet mail addresses on a particular host, the constraint is specified as the host name. For example, the constraint "xyz.com" is satisfied by any mail address at the host "xyz.com". To specify any address within a domain, the constraint is specified with a leading period (as with URIs). For example, ".xyz.com" indicates all the Internet mail addresses in the domain "xyz.com", but Internet mail addresses on the host "xyz.com".
Internat郵便の宛先の名前規制は特定のメールボックス、特定のホストのすべてのアドレス、またはドメインのすべてのメールボックスを指定するかもしれません。 特定のメールボックスを示すために、規制は完全な郵便の宛先です。 例えば、" root@xyz.com "はホスト"xyz.com"の根のメールボックスを示します。 特定のホストに関するすべてのインターネット郵便の宛先を示すために、規制はホスト名として指定されます。 例えば、規制"xyz.com"はホスト"xyz.com"のどんな郵便の宛先でも満足しています。 ドメインの中のどんなアドレスも指定するために、規制は主な期間で指定されます(URIのように)。 例えば、".xyz.com"は、すべてのインターネット・メールがそのドメインで"xyz.com"を扱うのを示しますが、インターネット・メールはホストの上で"xyz.com"を扱います。
DNS name restrictions are expressed as foo.bar.com. Any subdomain satisfies the name constraint. For example, www.foo.bar.com would satisfy the constraint but bigfoo.bar.com would not.
DNS名前制限はfoo.bar.comとして表されます。 どんなサブドメインも規制という名前を満たします。 例えば、www.foo.bar.comは規制を満たすでしょうが、bigfoo.bar.comは満たさないでしょう。
Legacy implementations exist where an RFC 822 name is embedded in the subject distinguished name in an attribute of type EmailAddress (see sec. 4.1.2.6). When rfc822 names are constrained, but the certificate does not include a subject alternative name, the rfc822 name 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 and B.
レガシー実装はRFC822名がタイプEmailAddressの属性で対象の分類名に埋め込まれているところに存在しています。(秒に遭遇してください。 4.1.2.6). rfc822名が制約つきですが、証明書が対象の代替名を含んでいないとき、対象の分類名における、タイプEmailAddressの属性に規制というrfc822名を適用しなければなりません。 Appendix AとBでEmailAddressのためのASN.1構文と対応するOIDを供給します。
Restrictions of the form directoryName MUST be applied to the subject field in the certificate and to the subjectAltName extensions of type directoryName. Restrictions of the form x400Address MUST be applied to subjectAltName extensions of type x400Address.
証明書の対象の分野と、そして、タイプdirectoryNameのsubjectAltName拡張子にフォームdirectoryNameの制限を適用しなければなりません。 タイプx400AddressのsubjectAltName拡張子にフォーム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 4.1.2.4. 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 shall be stated identically to the encoding used in the subject field or subjectAltName extension.
フォームdirectoryNameの制限を適用するとき、実装はDN属性を比較しなければなりません。 最小限では、実装はセクション4.1.2で.4に指定されたDN比較規則を実行しなければなりません。 フォームdirectoryName SHOULDの制限で証明書を発行するCAsが完全なISO DN名前比較アルゴリズムの実装を当てにしません。 これは、名前制限が同様に対象の分野かsubjectAltName拡張子に使用されるコード化に述べられるのを含意します。
Housley, et. al. Standards Track [Page 36] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[36ページ]。
The syntax of iPAddress MUST be as described in section 4.2.1.7 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 1519 (CIDR) to represent an address range.[RFC 1519] For IPv6 addresses, the ipAddress field MUST contain 32 octets similarly encoded. For example, a name constraint for "class C" subnet 10.9.8.0 shall be represented as the octets 0A 09 08 00 FF FF FF 00, representing the CIDR notation 10.9.8.0/255.255.255.0.
iPAddressの構文が特にName Constraintsのために以下の追加でセクション4.2.1で.7について説明するようにあるに違いありません。 IPv4アドレスのために、generalNameのipAddress分野はアドレスの範囲を表すためにRFC1519(CIDR)のスタイルでコード化された8(8)八重奏を含まなければなりません。IPv6アドレスのための[RFC1519]、ipAddress分野は同様にコード化された32の八重奏を含まなければなりません。 例えば、「クラスC」サブネットの名前規制、10.9、.8、.0、八重奏0A09 08 00FF FF FF00として、.0にCIDR記法10.9.8.0/255.255.255を表して、表されるでしょう。
The syntax and semantics for name constraints for otherName, ediPartyName, and registeredID are not defined by this specification.
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)
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.12 Policy Constraints
4.2.1.12 方針規制
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, subsequent certificates shall include an acceptable policy identifier. The value of requireExplicitPolicy indicates the number of additional certificates that may appear in the path before an explicit policy is required. An acceptable policy identifier is the identifier of a
requireExplicitPolicy分野が存在しているなら、その後の証明書は許容できる方針識別子を含んでいるものとします。 requireExplicitPolicyの値は明白な方針が必要である前に経路に現れるかもしれない追加証明書の数を示します。 許容できる方針識別子はaに関する識別子です。
Housley, et. al. Standards Track [Page 37] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[37ページ]。
policy required by the user of the certification path or the identifier of a policy which has been declared equivalent through policy mapping.
方針が方針マッピングを通して同等であると宣言された証明経路のユーザか方針に関する識別子が必要です。
Conforming CAs MUST NOT issue certificates where policy constraints is a null sequence. That is, at least one of the inhibitPolicyMapping field or the requireExplicitPolicy field MUST be present. The behavior of clients that encounter a null policy constraints field is not addressed in this profile.
CAsを従わせると、方針規制が零列である証明書は発行されてはいけません。 すなわち、少なくともinhibitPolicyMapping分野かrequireExplicitPolicy分野の1つは存在していなければなりません。 ヌル方針規制分野に遭遇するクライアントの振舞いはこのプロフィールで扱われません。
This extension may be critical or non-critical.
この拡大は、重要であるか、または非臨界であるかもしれません。
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.13 Extended key usage field
4.2.1.13 拡張主要な用法分野
This field 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 field. This field 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 shall be assigned in accordance with IANA or ITU-T Rec. X.660 | ISO/IEC/ITU 9834-1.
主要な目的は必要性があるどんな組織によっても定義されるかもしれません。 IANAかITU-T Recによると、主要な目的を特定するのに使用されるオブジェクト識別子は割り当てられるものとします。 X.660| ISO/IEC/ITU9834-1。
This extension may, at the option of the certificate issuer, be either critical or non-critical.
証明書発行人の選択のときに、この拡大は、重要であるか、または非臨界であるかもしれません。
If the extension is flagged critical, then the certificate MUST be used only for one of the purposes indicated.
拡大が旗を揚げられるなら、重要であることで、示された目的の1つにだけ証明書を使用しなければなりません。
If the extension is flagged non-critical, then it indicates the intended purpose or purposes of the key, and may be used in finding the correct key/certificate of an entity that has multiple keys/certificates. It is an advisory field and does not imply that usage of the key is restricted by the certification authority to the
拡大が旗を揚げられるなら、非臨界であり、キーについて意図が目標とするか、または目標とするのを示します、そして、複数のキー/証明書を持っている実体の正しいキー/証明書を見つける際に使用されるかもしれません。 それは、顧問分野であり、キーの使用法が証明権威によって制限されるのを含意しません。
Housley, et. al. Standards Track [Page 38] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[38ページ]。
purpose indicated. Certificate using applications may nevertheless require that a particular purpose be indicated in order for the certificate to be acceptable to that application.
示された目的。 それにもかかわらず、アプリケーションを使用する証明書は、特定の目的が証明書がそのアプリケーションに許容できるために示されるのを必要とするかもしれません。
If a certificate contains both a critical key usage field and a critical extended key usage field, then both fields MUST be processed independently and the certificate MUST only be used for a purpose consistent with both fields. If there is no purpose consistent with both fields, then the certificate MUST NOT be used for any purpose.
証明書が重要な主要な用法分野と重要な拡張主要な用法分野の両方を含んでいるなら、独自に両方の分野を処理しなければなりません、そして、両方の分野と一致した目的に証明書を使用するだけでよいです。 両方の分野と一致したどんな目的もなければ、どんな目的にも証明書を使用してはいけません。
The following key usage purposes are defined by this profile:
以下の主要な用法目的はこのプロフィールによって定義されます:
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
イド-kp OBJECT IDENTIFIER:、:= イド-pkix3
id-kp-serverAuth OBJECT IDENTIFIER ::= {id-kp 1}
-- TLS Web server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
--
id-kp-clientAuth OBJECT IDENTIFIER ::= {id-kp 2}
-- TLS Web client authentication
-- Key usage bits that may be consistent: 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
--
id-kp-emailProtection OBJECT IDENTIFIER ::= {id-kp 4}
-- E-mail protection
-- Key usage bits that may be consistent: digitalSignature,
-- nonRepudiation, and/or (keyEncipherment
-- or keyAgreement)
--
id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
-- Binding the hash of an object to a time from an agreed-upon time
-- source. Key usage bits that may be consistent: digitalSignature,
-- nonRepudiation
イド-kp-serverAuthオブジェクト識別子:、:= イド-kp1--TLSウェブサーバ証明--一貫するかもしれない主要な用法ビット: digitalSignature--keyEnciphermentかkeyAgreement--イド-kp-clientAuthオブジェクト識別子:、:= イド-kp2--TLSウェブクライアント認証--一貫するかもしれない主要な用法ビット: digitalSignature、そして/または、--keyAgreement--イド-kp-codeSigningオブジェクト識別子:、:= イド-kp3--ダウンローダブルな実行コードの署名--一貫するかもしれない主要な用法ビット: digitalSignature--イド-kp-emailProtectionオブジェクト識別子:、:= イド-kp4--電子メール保護--一貫するかもしれない主要な用法ビット: digitalSignature--nonRepudiation、そして/または、(keyEncipherment or keyAgreement)--イド-kp-timeStampingオブジェクト識別子:、:= イド-kp8--同意している時間からの時間までオブジェクトのハッシュを縛ります--ソース。 一貫するかもしれない主要な用法ビット: digitalSignature--nonRepudiation
4.2.1.14 CRL Distribution Points
4.2.1.14 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は非臨界ですが、これのためにCAsとアプリケーションで拡大をサポートしますこのプロフィールが、勧める。 CRL管理のさらなる議論はセクション5に含まれています。
Housley, et. al. Standards Track [Page 39] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[39ページ]。
If the cRLDistributionPoints extension contains a DistributionPointName 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. The expected values for the URI are those defined in 4.2.1.7. Processing rules for other values are not defined by this specification. If the distributionPoint omits reasons, the CRL MUST include revocations for all reasons. If the distributionPoint omits cRLIssuer, the CRL MUST be issued by the CA that issued the certificate.
cRLDistributionPoints拡張子がタイプURIのDistributionPointNameを含んでいるなら、以下の意味論を想定しなければなりません: URIは、関連理由による現在のCRLへの指針であり、関連cRLIssuerによって発行されるでしょう。 URIのための期待値はものが4.2で.7に.1を定義したということです。 他の値のための処理規則はこの仕様で定義されません。 distributionPointが理由を省略するなら、CRL MUSTはすべての理由で取消しを含んでいます。 distributionPointはcRLIssuer、CRL MUSTを省略します。証明書を発行したカリフォルニアによって発行されます。
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 }
イドCe cRLDistributionPoints、オブジェクト識別子:、:= イドCe31
cRLDistributionPoints ::= {
CRLDistPointsSyntax }
cRLDistributionPoints:、:= CRLDistPointsSyntax
CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
CRLDistPointsSyntax:、:= 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
ReasonFlags ::= BIT STRING {
unused (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6) }
ReasonFlags:、:= ビット列未使用の(0)(keyCompromise(1)、cACompromise(2)、affiliationChanged(3))は(4)、cessationOfOperation(5)、certificateHold(6)に取って代わりました。
4.2.2 Private Internet Extensions
4.2.2 個人的なインターネット拡大
This section defines one new extension for use in the Internet Public Key Infrastructure. This extension may be used to direct applications to identify an on-line validation service supporting the issuing CA. As the information may be available in multiple forms, each extension is a sequence of IA5String values, each of which represents a URI. The URI implicitly specifies the location and format of the information and the method for obtaining the information.
このセクションはインターネット公開鍵暗号基盤における使用のために1つの新しい拡大を定義します。 この拡張子は、発行にカリフォルニアをサポートするオンライン合法化サービスを特定するようアプリケーションに指示するのに使用されるかもしれません。 情報が複数のフォームで利用可能であるかもしれないので、各拡大はIA5String値の系列です。それはそれぞれURIを表します。 URIはそれとなく情報の位置と形式と情報を得るためのメソッドを指定します。
Housley, et. al. Standards Track [Page 40] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[40ページ]。
An object identifier is defined for the private extension. The object identifier associated with the private extension is defined under the arc id-pe within the id-pkix name space. Any future extensions defined for the Internet PKI will also be defined under the arc id-pe.
オブジェクト識別子は個人的な拡大のために定義されます。 個人的な拡大に関連しているオブジェクト識別子はスペースというイド-pkix名の中でアークイド-peの下で定義されます。 また、インターネットPKIと定義されたどんな今後の拡大もアークイド-peの下で定義されるでしょう。
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 CA 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 subject or CA certificates, and it MUST be non-critical.
権威情報アクセス拡張子は拡大が現れる証明書の発行人のためにカリフォルニア情報とサービスにアクセスする方法を示します。 情報とサービスはオンライン合法化サービスとカリフォルニア方針データを含むかもしれません。 (CRLsの位置はこの拡大で指定されません; cRLDistributionPoints拡張子で情報を提供します。) この拡大は対象かカリフォルニア証明書に含まれるかもしれません、そして、それは非臨界であるに違いありません。
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
Each entry in the sequence AuthorityInfoAccessSyntax describes the format and location of additional information about the CA who issued the certificate in which this extension appears. The type and format of the information is 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 one OID for accessMethod. The id-ad-caIssuers OID is used when the additional information lists CAs that have issued certificates superior to the CA that issued the certificate
このプロフィールはaccessMethodのために1OIDを定義します。 イド広告caIssuers OID、追加情報が証明書を発行したカリフォルニアより優れた証明書を発行したCAsを記載するとき、使用されています。
Housley, et. al. Standards Track [Page 41] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[41ページ]。
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.
この拡大を含んでいます。 参照をつけられたカリフォルニアのIssuers記述が証明書ユーザによって信じられたポイントで終わる証明経路の選択で証明書ユーザを支援することを意図します。
When id-ad-caIssuers appears as accessInfoType, 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. Where the information is available via http, ftp, or ldap, accessLocation MUST be a uniformResourceIdentifier. Where the information is available via the directory access protocol (dap), accessLocation MUST be a directoryName. When the information is available via electronic mail, accessLocation MUST be an rfc822Name. The semantics of other name forms of accessLocation (when accessMethod is id-ad-caIssuers) are not defined by this specification.
いつ、イド広告caIssuers、accessInfoType、accessLocation分野が参照をつけられた記述サーバについて説明して、アクセスが参照をつけられた記述を得るために議定書を作るのに従って、現れるか。 accessLocation分野はGeneralNameと定義されます。(GeneralNameは数個の形を取ることができます)。accessLocationは情報がhttp、ftp、またはldapを通して利用可能であるところのuniformResourceIdentifierであるに違いありません。 情報がディレクトリアクセス・プロトコルで利用可能であるところでは(ちょと浸してください)、accessLocationはdirectoryNameであるに違いありません。 情報が電子メールを通して利用可能であるときに、accessLocationはrfc822Nameであるに違いありません。 accessLocationの他の名前フォームの意味論、(accessMethodがいつか、イド広告caIssuers、)、この仕様で、定義されません。
Additional access descriptors may be defined in other PKIX specifications.
追加アクセス記述子は他のPKIX仕様に基づき定義されるかもしれません。
5 CRL and CRL Extensions Profile
5のCRLとCRL拡大プロフィール
As described 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 baseline 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で予想できる情報の基線セットを定義します。 また、プロフィールはこれらの属性の共通表現と同様に頻繁に使用された属性のためにCRLの中で一般的な位置を定義します。
This profile does not define any private Internet CRL extensions or CRL entry extensions.
このプロフィールは少しの個人的なインターネット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. Conforming CAs that issue CRLs MUST issue version 2 CRLs, and CAs MUST include the date by which the next CRL will be issued in the nextUpdate field (see
他の取消しか証明書状態メカニズムを提供するなら、従うCAsはCRLsを発行するのが必要ではありません。 CRLsを発行するCAsを従わせるとバージョン2CRLsが発行されなければならなくて、CAsが日付を次のCRLがnextUpdate分野で発行される含まなければならない、(見る。
Housley, et. al. Standards Track [Page 42] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[42ページ]。
sec. 5.1.2.5), the CRL number extension (see sec. 5.2.3) and the authority key identifier extension (see sec. 5.2.1). Conforming applications are required to process version 1 and 2 CRLs.
秒 5.1.2.5、)、CRL数の拡張子(秒に遭遇してください。 5.2.3、)、権威の主要な識別子拡張子(秒に遭遇してください。 5.2.1). 従うアプリケーションが、バージョン1と2CRLsを処理するのに必要です。
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コード化はタグ、長さ、それぞれの要素のシステムをコード化する値です。
CertificateList ::= SEQUENCE {
tbsCertList TBSCertList,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
CertificateList:、:= 系列tbsCertList TBSCertList、signatureAlgorithm AlgorithmIdentifier、signatureValueビット列
TBSCertList ::= SEQUENCE {
version Version OPTIONAL,
-- if present, shall be v2
signature AlgorithmIdentifier,
issuer Name,
thisUpdate Time,
nextUpdate Time OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate Time,
crlEntryExtensions Extensions OPTIONAL
-- if present, shall be v2
} OPTIONAL,
crlExtensions [0] EXPLICIT Extensions OPTIONAL
-- if present, shall 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です。 分野は以下の小区分で詳細に説明されます。
Housley, et. al. Standards Track [Page 43] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[43ページ]。
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 list of revoked certificates, and optional CRL extensions. Further, 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拡張子です。 さらに、取り消された証明書リストの上の各エントリーはユーザー証明書通し番号、取消し期日、および任意のCRLエントリー拡張子の系列によって定義されます。
5.1.1.2 signatureAlgorithm
5.1.1.2 signatureAlgorithm
The signatureAlgorithm field contains the algorithm identifier for the algorithm used by the CA to sign the CertificateList. The field is of type AlgorithmIdentifier, which is defined in section 4.1.1.2. Section 7.2 lists the supported algorithms for this specification. Conforming CAs MUST use the algorithm identifiers presented in section 7.2 when signing with a supported signature algorithm.
signatureAlgorithm分野はCertificateListに署名するのにカリフォルニアによって使用されたアルゴリズムのためのアルゴリズム識別子を含んでいます。 タイプAlgorithmIdentifierには分野があります。(AlgorithmIdentifierはセクション4.1.1で.2に定義されます)。 セクション7.2はこの仕様のためにサポートしているアルゴリズムを記載します。 CAsを従わせると、サポートしている署名アルゴリズムと契約するときセクション7.2に提示されたアルゴリズム識別子は使用されなければなりません。
This field MUST contain the same algorithm identifier as the signature field in the sequence tbsCertList (see sec. 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 then ASN.1 encoded as a BIT STRING and included in the CRL's signatureValue field. The details of this process are specified for each of the supported algorithms in section 7.2.
計算されて、signatureValue分野はデジタル署名を含んでいます。ASN.1DERはtbsCertListをコード化しました。 署名への入力が機能するので、ASN.1DERは使用されるtbsCertListをコード化しました。 そして、この署名値はBIT STRINGとしてコード化されて、CRLのsignatureValue分野に含まれていたASN.1です。 このプロセスの細部はセクション7.2のそれぞれのサポートしているアルゴリズムに指定されます。
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, the date and time the CRL was issued, and the date and time by which the CA will issue the next CRL.
署名される証明書リスト、またはTBSCertListが必要で任意の分野のSEQUENCEです。 必須項目はCRL発行人、CRLに署名するのに使用されるアルゴリズム、CRLが発行された日時、および日時をカリフォルニアが次のCRLを発行する特定します。
Optional fields include 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. The profile requires conforming CAs to use the CRL extension cRLNumber in all CRLs issued.
任意の分野は取り消された証明書とCRL拡張子のリストを含んでいます。 取り消された証明書リストは、カリフォルニアがそれが発行したどんな満期になっていない証明書も取り消していないケースを支えるために任意です。 プロフィールは、すべてのCRLsのcRLNumberが発行したCRL拡張子を使用するためにCAsを従わせるのを必要とします。
Housley, et. al. Standards Track [Page 44] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[44ページ]。
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. Section 7.2 lists OIDs for the most popular signature algorithms used in the Internet PKI.
この分野はCRLに署名するのに使用されるアルゴリズムのためのアルゴリズム識別子を含んでいます。 セクション7.2 最もポピュラーな署名アルゴリズムのためのリストOIDsはインターネットでPKIを使用しました。
This field MUST contain the same algorithm identifier as the signatureAlgorithm field in the sequence CertificateList (see section 5.1.1.2).
セクション5.1を見てください。この分野が系列CertificateListのsignatureAlgorithm分野と同じアルゴリズム識別子を含まなければならない、(.1 .2)。
5.1.2.3 Issuer Name
5.1.2.3 発行人名
The issuer name identifies the entity who has signed and issued the CRL. The issuer identity is carried in the issuer name field. Alternative name forms may also appear in the issuerAltName extension (see sec. 5.2.2). The issuer name field MUST contain an X.500 distinguished name (DN). The issuer name field is defined as the X.501 type Name, and MUST follow the encoding rules for the issuer name field in the certificate (see sec. 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としてコード化されるかもしれません。
CAs conforming to this profile that issue CRLs MUST encode thisUpdate as UTCTime for dates through the year 2049. CAs conforming to this profile that issue CRLs MUST encode thisUpdate as GeneralizedTime for dates in the year 2050 or later.
その問題CRLsをこのプロフィールに従わせるCAsは日付から2049年のUTCTimeとしてthisUpdateをコード化しなければなりません。 その問題CRLsをこのプロフィールに従わせるCAsは2050年か後で日付にGeneralizedTimeとしてthisUpdateをコード化しなければなりません。
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. CAs 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を発行できましたが、示された期日より遅いいずれもそれに発行されないでしょう。 CAs SHOULDはUTCTimeとしての等しいかnextUpdate時間前のすべてのCRLs. nextUpdateがコード化されるかもしれないより後半かGeneralizedTimeと共にCRLsを発行します。
Housley, et. al. Standards Track [Page 45] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[45ページ]。
This profile requires inclusion of nextUpdate in all CRLs issued by conforming CAs. 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 which omit nextUpdate is not specified by this profile.
このプロフィールはCAsを従わせることによって発行されたすべてのCRLsでのnextUpdateの包含を必要とします。 TBSCertListのASN.1構文がこの野原をOPTIONALとして記述することに注意してください。(OPTIONALは[X.509]で定義されるASN.1構造と一致しています)。 nextUpdateを省略するクライアント処理CRLsの動きはこのプロフィールによって指定されません。
CAs conforming to this profile that issue CRLs MUST encode nextUpdate as UTCTime for dates through the year 2049. CAs conforming to this profile that issue CRLs MUST encode nextUpdate as GeneralizedTime for dates in the year 2050 or later.
その問題CRLsをこのプロフィールに従わせるCAsは日付から2049年のUTCTimeとしてnextUpdateをコード化しなければなりません。 その問題CRLsをこのプロフィールに従わせるCAsは2050年か後で日付にGeneralizedTimeとしてnextUpdateをコード化しなければなりません。
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 取り消された証明書
Revoked certificates are listed. The revoked certificates are named 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エントリー拡張子について議論します。
5.1.2.7 Extensions
5.1.2.7 拡大
This field may only appear if the version is 2 (see sec. 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拡張子のSEQUENCEです。 セクション5.2でCRL拡張子について議論します。
5.2 CRL Extensions
5.2 CRL拡張子
The extensions defined by ANSI X9 and ISO/IEC/ITU 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. A CRL validation MUST fail if it encounters a critical extension which it does not know how to process. However, an unrecognized non-critical extension may be ignored. The following subsections present those extensions used within Internet CRLs. Communities may elect to include extensions in CRLs which are not defined in this specification. However, caution should be exercised in adopting any critical extensions in CRLs which might be used in a general context.
X.509 v2 CRLs[X.509][X9.55]のためのANSI X9とISO/IEC/ITUによって定義された拡大は追加属性を関連づけるためのメソッドにCRLsを提供します。 また、X.509 v2 CRL形式で、共同体は、それらの共同体にユニークな情報を運ぶために個人的な拡大を定義できます。 CRLでの各拡大は重要であるか非重要であるとして指定されるかもしれません。 どのようにが処理するかを知らない重要な拡大に遭遇するなら、CRL合法化は失敗しなければなりません。 しかしながら、認識されていない非臨界拡大は無視されるかもしれません。 以下の小区分はインターネットCRLsの中で使用されたそれらの拡張子を提示します。 共同体は、この仕様に基づき定義されないCRLsに拡大を含んでいるのを選ぶかもしれません。 しかしながら、警告は一般情勢で使用されるかもしれないCRLsでのどんな重要な拡大も採用するのに訓練されるべきです。
Housley, et. al. Standards Track [Page 46] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[46ページ]。
Conforming CAs that issue CRLs are required to include the authority key identifier (see sec. 5.2.1) and the CRL number (see sec. 5.2.3) extensions in all CRLs issued.
CAsを従わせて、その問題CRLsは権威の主要な識別子を含まなければなりません。(秒に遭遇してください。 5.2.1) そして、CRL番号(秒に遭遇してください。 5.2.3) CRLsが発行したすべてでの拡大。
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 on 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 CAs MUST use the key identifier method, and MUST include this extension in all CRLs issued.
CAsを従わせると、主要な識別子メソッドが使用されなければならなくて、この拡大は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 names extension allows additional identities to be associated with the issuer of the CRL. Defined options include an rfc822 name (electronic mail address), a DNS name, an IP address, and a URI. Multiple instances of a name and multiple name forms may be included. Whenever such identities are used, the issuer alternative name extension MUST be used.
発行人代替名拡大は、追加アイデンティティがCRLの発行人に関連しているのを許容します。 定義されたオプションはrfc822名(電子メールアドレス)、DNS名、IPアドレス、およびURIを含んでいます。 名前の複数のインスタンスと複数の名前フォームが含まれるかもしれません。 そのようなアイデンティティが使用されているときはいつも、拡大という発行人代替名を使用しなければなりません。
The issuerAltName extension SHOULD NOT be marked critical.
issuerAltName拡張子SHOULD NOT、重要であるとマークされてください。
The OID and syntax for this CRL extension are defined in section 4.2.1.8.
このCRL拡張子のためのOIDと構文はセクション4.2.1で.8に定義されます。
5.2.3 CRL Number
5.2.3 CRL番号
The CRL number is a non-critical CRL extension which conveys a monotonically increasing sequence number for each CRL issued by a CA. This extension allows users to easily determine when a particular CRL supersedes another CRL. CAs conforming to this profile MUST include this extension in all CRLs.
CRL番号はカリフォルニアによって発行された各CRLのために単調に増加する一連番号を伝える非臨界CRL拡張子です。 この拡大で、ユーザは、特定のCRLがいつ別のCRLに取って代わるかを容易に決心できます。 このプロフィールに従うCAsはすべてのCRLsにこの拡大を含まなければなりません。
id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
イドCe cRLNumber、オブジェクト識別子:、:= イドCe20
cRLNumber ::= INTEGER (0..MAX)
cRLNumber:、:= 整数(0..MAX)
Housley, et. al. Standards Track [Page 47] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[47ページ]。
5.2.4 Delta CRL Indicator
5.2.4 デルタCRLインディケータ
The delta CRL indicator is a critical CRL extension that identifies a delta-CRL. The use of delta-CRLs can significantly improve processing time for applications which store revocation information in a format other than the CRL structure. This allows changes to be added to the local database while ignoring unchanged information that is already in the local database.
デルタCRLインディケータはデルタ-CRLを特定する重要なCRL拡張子です。 デルタ-CRLsの使用はCRL構造以外の形式で取消し情報を保存するアプリケーションのための処理時間をかなり改良できます。 これは、ローカルのデータベースに既にある変わりのない情報を無視している間、変化がローカルのデータベースに追加されるのを許容します。
When a delta-CRL is issued, the CAs MUST also issue a complete CRL.
また、デルタ-CRLが発行されるとき、CAsは完全なCRLを発行しなければなりません。
The value of BaseCRLNumber identifies the CRL number of the base CRL that was used as the starting point in the generation of this delta- CRL. The delta-CRL contains the changes between the base CRL and the current CRL issued along with the delta-CRL. It is the decision of a CA as to whether to provide delta-CRLs. Again, a delta-CRL MUST NOT be issued without a corresponding complete CRL. The value of CRLNumber for both the delta-CRL and the corresponding complete CRL MUST be identical.
BaseCRLNumberの値はこのCRLデルタの世代における出発点として使用されたベースCRLのCRL番号を特定します。 デルタ-CRLはデルタ-CRLと共に発行されたベースCRLと現在のCRLの間に変化を含んでいます。 それはデルタ-CRLsを提供するかどうかに関するカリフォルニアの決定です。 再びデルタ-CRL MUST NOT、対応する完全なCRLなしで発行されてください。 デルタ-CRLと対応の両方のためのCRLNumberの値はCRL MUSTを完成します。同じであってください。
A CRL user constructing a locally held CRL from delta-CRLs MUST consider the constructed CRL incomplete and unusable if the CRLNumber of the received delta-CRL is more than one greater than the CRLnumber of the delta-CRL last processed.
デルタ-CRLsから局所的に保持されたCRLを組み立てているCRLユーザは、不完全で使用不可能な組み立てられたCRLが容認されたデルタ-CRLのCRLNumberがデルタ-CRL最終CRLnumberよりすばらしい1つ以上なら処理したと考えなければなりません。
id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
イドCe deltaCRLIndicator、オブジェクト識別子:、:= イドCe27
deltaCRLIndicator ::= BaseCRLNumber
deltaCRLIndicator:、:= BaseCRLNumber
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 for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA certificates only, or a limitied set of reason codes. Although the extension is critical, conforming implementations are not required to support this extension.
発行している分配ポイントは特定のCRLのためにCRL分配ポイントを特定する重要なCRL拡張子です、そして、CRLが終わりの実体証明書だけのための取消しをカバーするかどうかを示します、カリフォルニア証明書だけ、またはlimitiedセットの理由コード。 拡大は重要ですが、従う実装は、この拡大をサポートするのに必要ではありません。
The CRL is signed using the CA'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 than the Directory entry of the CA.
CAの秘密鍵を使用することでCRLは署名されます。 CRL Distribution Pointsには、それら自身の主要な組がありません。 CRLがX.500ディレクトリで保存されるなら、それはカリフォルニアのディレクトリエントリーと異なるかもしれないCRL分配ポイントに対応するディレクトリエントリーに保存されます。
Housley, et. al. Standards Track [Page 48] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[48ページ]。
The reason codes associated with a distribution point shall be specified in onlySomeReasons. If onlySomeReasons does not appear, the distribution point shall 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) and cACompromise (2) 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)との取消しはコードがもう1分配ポイントに現れる他の理由と共に1分配ポイント、および取消しに現れます。
Where the issuingDistributionPoint extension contains a URL, the following semantics MUST be assumed: the object is a pointer to the most current CRL issued by this CA. The URI schemes ftp, http, mailto [RFC1738] and ldap [RFC1778] are defined for this purpose. The URI MUST be an absolute, not relative, pathname and MUST specify the host.
issuingDistributionPoint拡張子がURLを含んでいるところでは、以下の意味論を想定しなければなりません: オブジェクトはこのカリフォルニアによって発行された中で最も現在のCRLへの指針です。 URI体系のftp、http、mailto[RFC1738]、およびldap[RFC1778]はこのために定義されます。 URIは、親類、パス名ではなく、絶対的なものでなければならなく、ホストを指定しなければなりません。
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 }
issuingDistributionPoint:、:= 系列distributionPoint[0]DistributionPointName任意です、onlyContainsUserCertsの論理演算子のデフォルトの誤って、onlyContainsCACerts[2]ブールのデフォルト誤って、onlySomeReasons[3]ReasonFlags任意の[1]indirectCRL[4]論理演算子は虚偽でデフォルトとします。
5.3 CRL Entry Extensions
5.3 CRLエントリー拡張子
The CRL entry extensions already defined by ANSI X9 and ISO/IEC/ITU 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. A CRL validation MUST fail if it encounters a critical CRL entry extension which it does not know how to process. However, an unrecognized non-critical CRL entry extension may be ignored. 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 extensions in CRL entries which might be used in a general context.
X.509 v2 CRLsのためのANSI X9とISO/IEC/ITUによって既に定義されたCRLエントリー拡張子はCRLエントリー[X.509][X9.55]を追加属性を関連づけるためのメソッドに提供します。 また、X.509 v2 CRL形式で、共同体は、それらの共同体にユニークな情報を運ぶために個人的なCRLエントリー拡張子を定義できます。 CRLエントリーにおける各拡大は重要であるか非臨界であるとして指定されるかもしれません。 どのようにが処理するかを知らない重要なCRLエントリー拡張子に遭遇するなら、CRL合法化は失敗しなければなりません。 しかしながら、認識されていない非臨界CRLエントリー拡張子は無視されるかもしれません。 以下の小区分プレゼントは情報にインターネットCRLエントリーと標準の位置の中で使用された拡張子を推薦しました。 共同体は、追加CRLエントリー拡張子を使用するのを選ぶかもしれません。 しかしながら、警告は一般情勢で使用されるかもしれないCRLエントリーにおけるどんな重要な拡大も採用するのに訓練されるべきです。
All CRL entry extensions used in this specification are non-critical. Support for these extensions is optional for conforming CAs and applications. However, CAs that issue CRLs SHOULD include reason codes (see sec. 5.3.1) and invalidity dates (see sec. 5.3.3) whenever this information is available.
この仕様で使用されるすべてのCRLエントリー拡張子が非臨界です。 CAsとアプリケーションを従わせるのに、これらの拡大のサポートは任意です。 しかしながら、問題CRLs SHOULDが含んでいるCAsはコードを推論します。(秒に遭遇してください。 5.3.1) そして、無効はデートします。(秒に遭遇してください。 5.3.3) この情報が利用可能であるときはいつも。
Housley, et. al. Standards Track [Page 49] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[49ページ]。
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. CAs 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エントリー拡張子です。 CAsがCRLエントリーに重要な理由コードを含んでいるよう強く奨励されます。 しかしながら、理由はCRLエントリー拡張子SHOULDをコード化します。不特定の(0)reasonCode価値を使用することの代わりに、休んでください。
id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 }
イドCe cRLReason、オブジェクト識別子:、:= イドCe21
-- reasonCode ::= { CRLReason }
-- reasonCode:、:= CRLReason
CRLReason ::= ENUMERATED {
unspecified (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
removeFromCRL (8) }
CRLReason:、:= 列挙されます。removeFromCRL(8)、不特定の(0)(keyCompromise(1)、cACompromise(2)、affiliationChanged(3))は(4)、cessationOfOperation(5)、certificateHold(6)に取って代わりました。
5.3.2 Hold Instruction Code
5.3.2 命令コードを保持してください。
The hold instruction code is a non-critical CRL entry extension that provides a registered instruction identifier which indicates the action to be taken after encountering a certificate that has been placed on hold.
保持命令コードは保持に置かれた証明書に遭遇しながら似られるように動作を示す登録された指示識別子を提供する非臨界CRLエントリー拡張子です。
id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }
イドCe holdInstructionCode、オブジェクト識別子:、:= イドCe23
holdInstructionCode ::= OBJECT IDENTIFIER
holdInstructionCode:、:= オブジェクト識別子
The following instruction codes have been defined. Conforming applications that process this extension MUST recognize the following instruction codes.
以下の命令コードは定義されました。 この拡大を処理するアプリケーションを従わせると、以下の命令コードは認識されなければなりません。
holdInstruction OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) x9-57(10040) 2 }
holdInstructionオブジェクト識別子:、:= iso(1)は(2) 私たち(840)x9-57(10040)2をメンバーと同じくらい具体化させます。
id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1}
id-holdinstruction-callissuer
OBJECT IDENTIFIER ::= {holdInstruction 2}
id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}
イドholdinstruction、なにも、OBJECT IDENTIFIER:、:= holdInstruction1イド-holdinstruction-callissuer OBJECT IDENTIFIER:、:= holdInstruction2イドholdinstruction廃棄物OBJECT IDENTIFIER:、:= holdInstruction3
Conforming applications which encounter an id-holdinstruction- callissuer MUST call the certificate issuer or reject the certificate. Conforming applications which encounter an id-
イド-holdinstruction- callissuerに遭遇するアプリケーションを従わせるのは、証明書発行人と呼ばなければならないか、または証明書を拒絶しなければなりません。 イドに遭遇するアプリケーションを従わせます。
Housley, et. al. Standards Track [Page 50] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[50ページ]。
holdinstruction-reject MUST reject the certificate. The hold instruction id-holdinstruction-none is semantically equivalent to the absence of a holdInstructionCode, and its use is strongly deprecated for the Internet PKI.
holdinstruction-廃棄物は証明書を拒絶しなければなりません。 holdInstructionCode、およびその使用の欠如と同等物は意味的に、そうです。保持命令、イドholdinstruction、なにも、インターネットPKIには強く推奨しないです。
5.3.3 Invalidity Date
5.3.3 無効日付
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 CA 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, CAs are strongly encouraged to share it with CRL users.
無効日付は秘密鍵が感染されたか、またはそうでなければ、証明書が無効になったと知られているか、または疑われる日付を提供する非臨界CRLエントリー拡張子です。 この日付は取消し日付より早くCRLエントリーにあるかもしれません。(それは、カリフォルニアが取消しを処理した日付です)。 取消しが最初にCRLにカリフォルニアによって掲示されるとき、無効日付は以前のCRLsの発行日に先行するかもしれませんが、取消し日付SHOULD NOTは以前のCRLsの発行日に先行します。 この情報が利用可能であるときはいつも、CAsが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.4 Certificate Issuer
5.3.4 証明書発行人
This CRL entry extension identifies the certificate issuer associated with an entry in an indirect CRL, i.e. a CRL that has the indirectCRL indicator set in its issuing distribution point extension. If this extension is not present on the first entry in an indirect CRL, the certificate issuer defaults to the CRL issuer. On 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エントリー拡張子は間接的なCRLのエントリーに関連している証明書発行人を特定します、すなわち、それが分配ポイント拡大を発行する際にindirectCRLインディケータを設定させるCRL。 この拡大が間接的なCRLの初記入のときに存在していないなら、証明書発行人はCRL発行人をデフォルトとします。 間接的なCRLのその後のエントリーでは、この拡大が存在していないなら、エントリーへの証明書発行人が前のエントリーへのそれと同じです。 この分野は以下の通り定義されます:
id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
イドCe certificateIssuer、オブジェクト識別子:、:= イドCe29
certificateIssuer ::= GeneralNames
certificateIssuer:、:= GeneralNames
If used by conforming CAs that issue CRLs, this extension is always critical. If an implementation ignored this extension it could not correctly attribute CRL entries to certificates. This specification RECOMMENDS that implementations recognize this extension.
CRLsを発行するCAsを従わせることによって使用されるなら、この拡大はいつも重要です。 実装がこの拡大を無視するなら、それは正しくCRLエントリーを証明書の結果と考えることができないでしょうに。 この仕様RECOMMENDS、実装はこの拡大を認識します。
Housley, et. al. Standards Track [Page 51] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[51ページ]。
6 Certification Path Validation
6 証明経路合法化
Certification path validation procedures for the Internet PKI are based on section 12.4.3 of [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 which are specified in the certificates which comprise the path. The basic constraints and policy constraints extensions allow the certification path processing logic to automate the decision making process.
インターネットPKIへの証明経路合法化手順は.3セクション12.4[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 be functionally 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. This text assumes that all valid paths begin with certificates issued by a single "most-trusted CA". The algorithm requires the public key of the CA, the CA's name, the validity period of the public key, and any constraints upon the set of paths which may be validated using this key.
セクション6.1で、テキストは基本的な経路合法化について説明します。 本稿は、証明書が単一の「最も信じられたカリフォルニア」によって発行されている状態ですべての有効な経路が始まると仮定します。 アルゴリズムは、このキーを使用することでカリフォルニアの公開鍵、CAの名前、公開鍵の有効期間、および有効にされるかもしれない経路のセットでの規制を必要とします。
The "most-trusted CA" is a matter of policy: it could be a root 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 validation procedure is the same regardless of the choice of "most- trusted CA."
「最も信じられたカリフォルニア」は方針の問題です: それは階層的なPKIの根のカリフォルニアであるかもしれません。 検証の自身の証明書を発行したカリフォルニア。 または、ネットワークPKIのいかなる他のカリフォルニア。 経路合法化手順は「大部分はカリフォルニアを信じたこと」の選択にかかわらず同じです。
section 6.2 describes extensions to the basic path validation algorithm. Two specific cases are discussed: the case where paths may begin with one of several trusted CAs; and where compatibility with the PEM architecture is required.
セクション6.2は基本的な経路合法化アルゴリズムに拡大について説明します。 2つの特定のケースについて議論します: 経路が数個の信じられたCAsの1つと共に始まるかもしれないケース。 そして、どこで、互換性がPEMアーキテクチャで必要であるか。
6.1 Basic Path Validation
6.1 基本的な経路合法化
The text assumes that the trusted public key (and related information) is contained in a "self-signed" certificate. This simplifies the description of the path processing procedure. Note that the signature on the self-signed certificate does not provide any security services. The trusted public key (and related information) may be obtained in other formats; the information is trusted because of other procedures used to obtain and protect it.
テキストは、信じられた公開鍵(そして、情報について話す)が「自己によって署名している」証明書に含まれていると仮定します。 これは経路現像処理の記述を簡素化します。 自己署名入りの証書における署名が少しのセキュリティー・サービスも提供しないことに注意してください。 他の形式で信じられた公開鍵(そして、情報について話す)を得るかもしれません。 情報はそれを得て、保護するのに用いられた他の手順のために信じられます。
Housley, et. al. Standards Track [Page 52] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[52ページ]。
The goal of path validation is to verify the binding between a subject distinguished name or subject alternative name and subject public key, as represented in the "end entity" certificate, based on the public key of the "most-trusted CA". This requires obtaining a sequence of certificates that support that binding. The procedures performed to obtain this sequence is outside the scope of this section.
経路合法化の目標は対象の分類名か対象の代替名と対象の公開鍵の間の結合について確かめることです、「最も信じられたカリフォルニア」の公開鍵に基づいて「終わりの実体」証明書に表されるように。 これは、系列を得るのをその結合をサポートする証明書を要求します。 このセクションの範囲の外にこの系列を得るために実行された手順があります。
The following text also assumes that certificates do not use subject or unique identifier fields or private critical extensions, as recommended within this profile. However, if these components appear in certificates, they MUST be processed. Finally, policy qualifiers are also neglected for the sake of clarity.
また、以下のテキストは、証明書が受けることがあるかユニークな識別子分野か個人的な重要な拡張子を使用しないと仮定します、このプロフィールの中に推薦されるように。 しかしながら、これらのコンポーネントが証明書に現れるなら、それらを処理しなければなりません。 また、最終的に、方針資格を与える人は明快のために無視されます。
A certification path is a sequence of n certificates where:
証明経路はnの系列がどこを証明するかということです:
* for all x in {1,(n-1)}, the subject of certificate x is the
issuer of certificate x+1.
* certificate x=1 is the the self-signed certificate, and
* certificate x=n is the end entity certificate.
* 1、(n-1)のすべてのxに関しては、証明書xの対象は+1に証明書xの発行人です。 * *証明書x=1は自己署名入りの証書です、そして、証明書x=nは終わりの実体証明書です。
This section assumes the following inputs are provided to the path processing logic:
このセクションは、以下の入力が経路処理論理に提供されると仮定します:
(a) a certification path of length n;
(a) 長さnの証明経路。
(b) a set of initial policy identifiers (each comprising a
sequence of policy element identifiers), which identifies one or
more certificate policies, any one of which would be acceptable
for the purposes of certification path processing, or the special
value "any-policy";
(b) それのいくらか1つが証明経路処理の目的のために許容できるだろう1つ以上の証明書方針を特定する1セットの初期の方針識別子(それぞれ、方針要素識別子の系列を含む)か特別な値、「いくらか、-、方針、」、。
(c) the current date/time (if not available internally to the
certification path processing module); and
(c)現在の日付/時間、(利用可能である、内部的である、証明経路処理モジュール)、。 そして
(d) the time, T, for which the validity of the path should be
determined. (This may be the current date/time, or some point in
the past.)
(d) 時間、T。(経路の正当性はそのTに関して決定しているべきです)。 (これは、現在の日付/時間、または過去の何らかのポイントであるかもしれません。)
From the inputs, the procedure intializes five state variables:
入力から、手順は5つの州の変数をintializesします:
(a) acceptable policy set: A set of certificate policy
identifiers comprising the policy or policies recognized by the
public key user together with policies deemed equivalent through
policy mapping. The initial value of the acceptable policy set is
the special value "any-policy".
(a) 許容できる方針はセットしました: 方針マッピングを通して同等であると考えられた方針と共に公開鍵ユーザによって認められた方針か方針を包括する1セットの証明書方針識別子。 許容できる方針セットの初期の値が特別な値である、「いくらか、-、方針、」
Housley, et. al. Standards Track [Page 53] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[53ページ]。
(b) constrained subtrees: A set of root names defining a set of
subtrees within which all subject names in subsequent certificates
in the certification path shall fall. The initial value is
"unbounded".
(b) 制約つき下位木: 証明経路のその後の証明書のすべての対象の名前が下がるものとする1セットの下位木を定義する1セットの根の名。 初期の値は「限りないです」。
(c) excluded subtrees: A set of root names defining a set of
subtrees within which no subject name in subsequent certificates
in the certification path may fall. The initial value is "empty".
(c)の除かれた下位木: 証明経路のその後の証明書でどんな対象の名前も下がらないかもしれない1セットの下位木を定義する1セットの根の名。 初期の値は「空です」。
(d) explicit policy: an integer which indicates if an explicit
policy identifier is required. The integer indicates the first
certificate in the path where 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 explicit policy
identifiers, a later certificate can not remove this requirement.)
The initial value is n+1.
(d)の明白な方針: 明白な方針識別子がそうであるかどうかを示す整数が必要です。 整数はこの要件が課される経路における最初の証明書を示します。 いったん設定されると、この変数は、減少しますが、増強されないかもしれません。 (すなわち、経路の証明書が明白な方針識別子を必要とするなら、後の証明書はこの要件を取り除くことができません。) 初期の値はn+1です。
(e) policy mapping: an integer which indicates if policy mapping
is permitted. The integer indicates the last certificate on which
policy mapping may be applied. Once set, this variable may be
decreased, but may not be increased. (That is, if a certificate in
the path specifies policy mapping is not permitted, it can not be
overriden by a later certificate.) The initial value is n+1.
(e) 方針マッピング: 方針マッピングが受入れられるかどうかを示す整数。 整数は方針マッピングが適用されるかもしれない最後の証明書を示します。 いったん設定されると、この変数は、減少しますが、増強されないかもしれません。 (すなわち、経路の証明書が指定するなら、方針マッピングは受入れられないで、それは後の証明書でoverridenであるはずがありません。) 初期の値はn+1です。
The actions performed by the path processing software for each certificate i=1 through n are described below. The self-signed certificate is certificate i=1, the end entity certificate is i=n. The processing is performed sequentially, so that processing certificate i affects the state variables for processing certificate (i+1). Note that actions (h) through (m) are not applied to the end entity certificate (certificate n).
nを通してそれぞれの証明書i=1であることの経路処理ソフトウェアによって実行された動作は以下で説明されます。 自己署名入りの証書が証明書i=1である、終わりの実体証明書はi=nです。 処理が連続して実行されるので、処理証明書iは処理証明書(i+1)のための州の変数に影響します。 動作(h)から(m)が終わりの実体証明書(証明書n)に適用されないことに注意してください。
The path processing actions to be performed are:
実行されるべき経路処理動作は以下の通りです。
(a) Verify the basic certificate information, including:
(a) 基本の証明書情報、包含について確かめてください:
(1) the certificate was signed using the subject public key
from certificate i-1 (in the special case i=1, this step may be
omitted; if not, use the subject public key from the same
certificate),
(1) 証明書i-1から対象の公開鍵を使用することで証明書は署名されました(特別なケースi=1では、このステップは省略されるかもしれません; そうでなければ、同じ証明書から対象の公開鍵を使用してください)。
(2) the certificate validity period includes time T,
(2) 証明書有効期間は時間Tを含んでいます。
(3) the certificate had not been revoked at time T and is not
currently on hold status that commenced before time T, (this
may be determined by obtaining the appropriate CRL or status
information, or by out-of-band mechanisms), and
そして(3) 証明書が時Tに取り消されていなくて、また現在時Tの前に始まった保留状態でない、(これは適切なCRLか状態情報を入手するか、またはバンドの外による決定しているメカニズムであるかもしれません)。
Housley, et. al. Standards Track [Page 54] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[54ページ]。
(4) the subject and issuer names chain correctly (that is, the
issuer of this certificate was the subject of the previous
certificate.)
(4) 対象と発行人名は正しく鎖を作ります。(すなわち、この証明書の発行人は前の証明書の対象でした。)
(b) Verify that the subject name and subjectAltName extension
(critical or noncritical) is consistent with the constrained
subtrees state variables.
(b) 対象の名前とsubjectAltName拡張子(重要であるか非臨界である)が制約つき下位木州の変数と一致していることを確かめてください。
(c) Verify that the subject name and subjectAltName extension
(critical or noncritical) is consistent with the excluded subtrees
state variables.
(c) 対象の名前とsubjectAltName拡張子(重要であるか非臨界である)が除かれた下位木州の変数と一致していることを確かめてください。
(d) Verify that policy information is consistent with the initial
policy set:
(d) 方針情報が初期の方針セットと一致していることを確かめてください:
(1) if the explicit policy state variable is less than or equal
to i, a policy identifier in the certificate shall be in the
initial policy set; and
(1) 明白な政策ポジション変数が、よりi以下であるなら、初期の方針セットに証明書の方針識別子があるものとします。 そして
(2) if the policy mapping variable is less than or equal to i,
the policy identifier may not be mapped.
(2) 方針マッピング変数が、よりi以下であるなら、方針識別子は写像されないかもしれません。
(e) Verify that policy information is consistent with the
acceptable policy set:
(e) 方針情報が許容できる方針セットと一致していることを確かめてください:
(1) if the certificate policies extension is marked critical,
the intersection of the policies extension and the acceptable
policy set shall be non-null;
(1) 証明書方針拡張子が重要であるとマークされると、拡大と許容できる方針が設定する方針の交差点は非ヌルになるでしょう。
(2) the acceptable policy set is assigned the resulting
intersection as its new value.
(2) 結果として起こる交差点は新しい値として許容できる方針セットに配属されます。
(g) Verify that the intersection of the acceptable policy set and
the initial policy set is non-null.
(g) 許容できる方針の交差点がセットして、初期の方針セットが非ヌルであることを確かめてください。
(h) Recognize and process any other critical extension present in
the certificate.
(h) 証明書の現在のいかなる他の重要な拡大も認識して、処理してください。
(i) Verify that the certificate is a CA certificate (as specified
in a basicConstraints extension or as verified out-of-band).
(i) 証明書がカリフォルニア証明書(basicConstraints拡張子かバンドの外で確かめられるのと同じくらい指定された)であることを確かめてください。
(j) If permittedSubtrees is present in the certificate, set the
constrained subtrees state variable to the intersection of its
previous value and the value indicated in the extension field.
(j) permittedSubtreesが証明書に存在しているなら、前の値と価値の交差点への州の変数が拡大分野で示した制約つき下位木を設定してください。
(k) 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.
(k) excludedSubtreesが証明書に存在しているなら、前の値と価値の組合への州の変数が拡大分野で示した除かれた下位木を設定してください。
Housley, et. al. Standards Track [Page 55] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[55ページ]。
(l) If a policy constraints extension is included in the
certificate, modify the explicit policy and policy mapping state
variables as follows:
(l) 方針規制拡大が証明書に含まれているなら、以下の州の変数を写像する明白な方針と方針を変更してください:
(1) If requireExplicitPolicy is present and has value r, the
explicit policy state variable is set to the minimum of its
current value and the sum of r and i (the current certificate
in the sequence).
(1) requireExplicitPolicyが存在していて、値rを持っているなら、明白な政策ポジション変数は現行価値の最小限とrとiの合計(系列の現在の証明書)に設定されます。
(2) If inhibitPolicyMapping is present and has value q, the
policy mapping state variable is set to the minimum of its
current value and the sum of q and i (the current certificate
in the sequence).
(2) inhibitPolicyMappingが存在していて、値qを持っているなら、方針マッピング州の変数は現行価値の最小限とqとiの合計(系列の現在の証明書)に設定されます。
(m) If a key usage extension is marked critical, ensure the
keyCertSign bit is set.
(m) 主要な用法拡大が重要であるとマークされるなら、keyCertSignビットが設定されるのを確実にしてください。
If any one of the above checks fail, the procedure terminates, returning a failure indication and an appropriate reason. If none of the above checks fail on the end-entity certificate, the procedure terminates, returning a success indication together with the set of all policy qualifier values encountered in the set of certificates.
上のチェックのどれかが失敗するなら、手順は終わって、失敗指示と適切な理由を返します。 上のチェックのいずれも終わり実体証明書で失敗しないなら、手順は終わります、証明書のセットで遭遇するすべての方針資格を与える人値のセットと共に成功指示を返して。
6.2 Extending Path Validation
6.2 経路合法化を広げること。
The path validation algorithm presented in 6.1 is based on several simplifying assumptions (e.g., a single trusted CA that starts all valid paths). This algorithm may be extended for cases where the assumptions do not hold.
6.1で提示された経路合法化アルゴリズムは、仮定を簡素化しながら、数個に基づいています(例えば、シングルはすべての有効な経路を始めるカリフォルニアを信じました)。 このアルゴリズムは仮定が成立しないケースのために広げられるかもしれません。
This procedure may be extended for multiple trusted CAs by providing a set of self-signed certificates to the validation module. In this case, a valid path could begin with any one of the self-signed certificates. Limitations in the trust paths for any particular key may be incorporated into the self-signed certificate's extensions. In this way, the self-signed certificates permit the path validation module to automatically incorporate local security policy and requirements.
この手順は、複数の信じられたCAsのために1セットの自己署名入りの証書を合法化モジュールに提供することによって、広げられるかもしれません。 この場合、有効な経路は自己署名入りの証書のいずれでも始まることができました。 どんな特定のキーのための信頼経路での制限も自己署名入りの証書の拡大に組み入れられるかもしれません。 このように、自己署名入りの証書は、経路合法化モジュールが自動的にローカルの安全保障政策と要件を取り入れるのを可能にします。
It is also possible to specify an extended version of the above certification path processing procedure which results in default behavior identical to the rules of PEM [RFC 1422]. In this extended version, additional inputs to the procedure are a list of one or more Policy Certification Authorities (PCAs) names and an indicator of the position in the certification path where the PCA is expected. At the nominated PCA position, the CA name is compared against this list. If a recognized PCA name is found, then a constraint of SubordinateToCA is implicitly assumed for the remainder of the
また、PEM[RFC1422]の規則と同じデフォルトの振舞いをもたらす上の証明経路現像処理の拡張版を指定するのも可能です。 この拡張版では、手順への追加入力は、1Policy Certification Authorities(PCAs)の名前のリストとPCAが予想される証明経路の位置のインディケータです。 指名PCA位置では、カリフォルニア名がこのリストに対してたとえられます。 認識されたPCA名が見つけられるなら、SubordinateToCAの規制は残りのためにそれとなく想定されます。
Housley, et. al. Standards Track [Page 56] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[56ページ]。
certification path and processing continues. If no valid PCA name is found, and if the certification path cannot be validated on the basis of identified policies, then the certification path is considered invalid.
証明経路と処理は続きます。 特定された方針に基づいて証明経路を有効にすることができないならどんな妥当なPCA名も見つけられないなら、証明経路は無効であると考えられます。
7 Algorithm Support
7 アルゴリズムサポート
This section describes cryptographic algorithms which may be used with this profile. The section describes one-way hash functions and digital signature algorithms which may be used to sign certificates and CRLs, and identifies OIDs for public keys contained in a certificate.
このセクションはこのプロフィールと共に使用されるかもしれない暗号アルゴリズムを説明します。 セクションは、証明書とCRLsに署名するのに使用されるかもしれない一方向ハッシュ関数とデジタル署名アルゴリズムを説明して、証明書に含まれた公開鍵のためにOIDsを特定します。
Conforming CAs and applications are not required to support the algorithms or algorithm identifiers described in this section. However, conforming CAs and applications that use the algorithms identified here MUST support them as specified.
CAsを従わせて、アプリケーションは、アルゴリズムかアルゴリズムがこのセクションで説明された識別子であるとサポートするのに必要ではありません。 しかしながら、ここで特定されたアルゴリズムを使用するCAsとアプリケーションを従わせると、それらは指定されるとしてサポートしなければなりません。
7.1 One-way Hash Functions
7.1 一方向ハッシュ関数
This section identifies one-way hash functions for use in the Internet PKI. One-way hash functions are also called message digest algorithms. SHA-1 is the preferred one-way hash function for the Internet PKI. However, PEM uses MD2 for certificates [RFC 1422] [RFC 1423] and MD5 is used in other legacy applications. For this reason, MD2 and MD5 are included in this profile.
このセクションはインターネットPKIでの使用のために一方向ハッシュ関数を特定します。 また、一方向ハッシュ関数はメッセージダイジェストアルゴリズムと呼ばれます。SHA-1はインターネットPKIに、都合のよい一方向ハッシュ関数です。 しかしながら、PEMは証明書[RFC1422][RFC1423]にMD2を使用します、そして、MD5は他のレガシーアプリケーションで使用されます。 この理由で、MD2とMD5はこのプロフィールに含まれています。
7.1.1 MD2 One-way Hash Function
7.1.1 MD2の一方向ハッシュ関数
MD2 was developed by Ron Rivest for RSA Data Security. RSA Data Security has not placed the MD2 algorithm in the public domain. Rather, RSA Data Security has granted license to use MD2 for non- commercial Internet Privacy-Enhanced Mail. For this reason, MD2 may continue to be used with PEM certificates, but SHA-1 is preferred. MD2 produces a 128-bit "hash" of the input. MD2 is fully described in RFC 1319 [RFC 1319].
MD2はRSA Data SecurityのためにロンRivestによって開発されました。 RSA Data SecurityはMD2アルゴリズムを公共の場に置いていません。 むしろ、RSA Data Securityは非商業のインターネットPrivacyによって高められたメールにMD2を使用するライセンスを与えました。 この理由で、MD2は、PEM証明書と共に使用され続けるかもしれませんが、SHA-1は好まれます。 MD2は入力の128ビットの「ハッシュ」を生産します。 MD2はRFC1319[RFC1319]で完全に説明されます。
At the Selected Areas in Cryptography '95 conference in May 1995, Rogier and Chauvaud presented an attack on MD2 that can nearly find collisions [RC95]. Collisions occur when one can find two different messages that generate the same message digest. A checksum operation in MD2 is the only remaining obstacle to the success of the attack. For this reason, the use of MD2 for new applications is discouraged. It is still reasonable to use MD2 to verify existing signatures, as the ability to find collisions in MD2 does not enable an attacker to find new messages having a previously computed hash value.
1995年5月のCryptography95年の会議におけるSelected Areasでは、ロジエとChauvaudは衝突が[RC95]であるとほとんど見つけることができるMD2に対する攻撃を提示しました。 人が同じメッセージダイジェストを生成する2つの異なったメッセージを見つけることができるとき、衝突は起こります。 MD2でのチェックサム操作は攻撃の成功への唯一の残っている障害です。 この理由で、MD2の新しいアプリケーションの使用はお勧めできないです。 既存の署名について確かめるのにMD2を使用するのはまだ妥当です、MD2で衝突を見つける能力が、攻撃者が、新しいメッセージには以前に計算されたハッシュ値があるのがわかるのを可能にしないとき。
Housley, et. al. Standards Track [Page 57] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[57ページ]。
7.1.2 MD5 One-way Hash Function
7.1.2 MD5の一方向ハッシュ関数
MD5 was developed by Ron Rivest for RSA Data Security. RSA Data Security has placed the MD5 algorithm in the public domain. MD5 produces a 128-bit "hash" of the input. MD5 is fully described in RFC 1321 [RFC 1321].
MD5はRSA Data SecurityのためにロンRivestによって開発されました。 RSA Data SecurityはMD5アルゴリズムを公共の場に置きました。 MD5は入力の128ビットの「ハッシュ」を生産します。 MD5はRFC1321[RFC1321]で完全に説明されます。
Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5, but there are no other known cryptanalytic results. The use of MD5 for new applications is discouraged. It is still reasonable to use MD5 to verify existing signatures.
書斎ボーア人とBosselaers[DB94]はMD5に関して疑似衝突を見つけましたが、他の知られているcryptanalytic結果が全くありません。 MD5の新しいアプリケーションの使用はお勧めできないです。 既存の署名について確かめるのにMD5を使用するのはまだ妥当です。
7.1.3 SHA-1 One-way Hash Function
7.1.3 SHA-1の一方向ハッシュ関数
SHA-1 was developed by the U.S. Government. SHA-1 produces a 160-bit "hash" of the input. SHA-1 is fully described in FIPS 180-1 [FIPS 180-1].
SHA-1は米国政府によって開発されました。 SHA-1は入力の160ビットの「ハッシュ」を生産します。 SHA-1はFIPS180-1[FIPS180-1]で完全に説明されます。
SHA-1 is the one-way hash function of choice for use with both the RSA and DSA signature algorithms (see sec. 7.2).
SHA-1はRSAとDSA署名アルゴリズムの両方がある使用のための選択の一方向ハッシュ関数です。(秒に遭遇してください。 7.2).
7.2 Signature Algorithms
7.2 署名アルゴリズム
Certificates and CRLs described by this standard may be signed with any public key signature algorithm. The certificate or CRL indicates the algorithm through an algorithm identifier which appears in the signatureAlgorithm field in a Certificate or CertificateList. This algorithm identifier is an OID and has optionally associated parameters. This section identifies algorithm identifiers and parameters that shall be used in the signatureAlgorithm field in a Certificate or CertificateList.
この規格によって説明された証明書とCRLsはどんな公開鍵署名アルゴリズムも契約されるかもしれません。 証明書かCRLがCertificateかCertificateListのsignatureAlgorithm分野に現れるアルゴリズム識別子を通してアルゴリズムを示します。 このアルゴリズム識別子は、OIDであり、任意に関連しているパラメタを持っています。 このセクションはCertificateかCertificateListのsignatureAlgorithm分野で使用されるものとするアルゴリズム識別子とパラメタを特定します。
RSA and DSA are the most popular signature algorithms used in the Internet. Signature algorithms are always used in conjunction with a one-way hash function identified in section 7.1.
RSAとDSAはインターネットで使用される中で最もポピュラーな署名アルゴリズムです。 署名アルゴリズムはいつもセクション7.1で特定された一方向ハッシュ関数に関連して使用されます。
The signature algorithm and one-way hash function used to sign a certificate or CRL is indicated by use of an algorithm identifier. An algorithm identifier is an OID, and may include associated parameters. This section identifies OIDS for RSA and DSA. The contents of the parameters component for each algorithm vary; details are provided for each algorithm.
署名アルゴリズムと一方向ハッシュ関数は以前はよく証明書に署名していたか、またはCRLがアルゴリズム識別子の使用で示されます。 アルゴリズム識別子は、OIDであり、関連パラメタを含むかもしれません。 このセクションはRSAとDSAのためにOIDSを特定します。 各アルゴリズムのためのパラメタコンポーネントの内容は異なります。 詳細は各アルゴリズムに明らかにされます。
The data to be signed (e.g., the one-way hash function output value) is formatted for the signature algorithm to be used. Then, a private key operation (e.g., RSA encryption) is performed to generate the
署名されるデータ(例えば、一方向ハッシュ関数出力価値)は、署名アルゴリズムが使用されるためにフォーマットされます。 そして、秘密鍵操作(例えば、RSA暗号化)は、生成するために実行されます。
Housley, et. al. Standards Track [Page 58] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[58ページ]。
signature value. This signature value is then ASN.1 encoded as a BIT STRING and included in the Certificate or CertificateList in the signature field.
署名値。 そして、この署名値は署名分野にBIT STRINGとしてコード化されて、CertificateかCertificateListに含まれていたASN.1です。
7.2.1 RSA Signature Algorithm
7.2.1 RSA署名アルゴリズム
A patent statement regarding the RSA algorithm can be found at the end of this profile.
このプロフィールの端でRSAアルゴリズムに関する特許声明を見つけることができます。
The RSA algorithm is named for its inventors: Rivest, Shamir, and Adleman. This profile includes three signature algorithms based on the RSA asymmetric encryption algorithm. The signature algorithms combine RSA with either the MD2, MD5, or the SHA-1 one-way hash functions.
RSAアルゴリズムは発明者にちなんで命名されます: 最もRivest、シャミル、およびAdleman。 このプロフィールはRSAの非対称の暗号化アルゴリズムに基づく3つの署名アルゴリズムを含んでいます。 署名アルゴリズムはMD2、MD5かSHA-1の一方向ハッシュ関数のどちらかにRSAを結合します。
The signature algorithm with MD2 and the RSA encryption algorithm is defined in PKCS #1 [RFC 2313]. As defined in RFC 2313, the ASN.1 OID used to identify this signature algorithm is:
MD2とRSA暗号化アルゴリズムがある署名アルゴリズムはPKCS#1[RFC2313]で定義されます。 RFC2313で定義されるように、この署名アルゴリズムを特定するのに使用されるASN.1OIDは以下の通りです。
md2WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 2 }
md2WithRSAEncryptionオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-1(1)2をメンバーと同じくらい具体化させます。
The signature algorithm with MD5 and the RSA encryption algorithm is defined in PKCS #1 [RFC 2313]. As defined in RFC 2313, the ASN.1 OID used to identify this signature algorithm is:
MD5とRSA暗号化アルゴリズムがある署名アルゴリズムはPKCS#1[RFC2313]で定義されます。 RFC2313で定義されるように、この署名アルゴリズムを特定するのに使用されるASN.1OIDは以下の通りです。
md5WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 4 }
md5WithRSAEncryptionオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-1(1)4をメンバーと同じくらい具体化させます。
The signature algorithm with SHA-1 and the RSA encryption algorithm is implemented using the padding and encoding conventions described in PKCS #1 [RFC 2313]. The message digest is computed using the SHA-1 hash algorithm. The ASN.1 object identifier used to identify this signature algorithm is:
SHA-1とRSA暗号化アルゴリズムがある署名アルゴリズムは、詰め物を使用して、PKCS#1[RFC2313]で説明されたコンベンションをコード化しながら、実装されます。 メッセージダイジェストは、SHA-1ハッシュアルゴリズムを使用することで計算されます。 この署名アルゴリズムを特定するのに使用されるASN.1オブジェクト識別子は以下の通りです。
sha-1WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 5 }
sha-1WithRSAEncryptionオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-1(1)5をメンバーと同じくらい具体化させます。
When any of these three OIDs appears within the ASN.1 type AlgorithmIdentifier, the parameters component of that type shall be the ASN.1 type NULL.
これらの3OIDsのどれかがASN.1タイプAlgorithmIdentifierの中に現れるとき、そのタイプのパラメタ成分はASN.1タイプNULLになるでしょう。
The RSA signature generation process and the encoding of the result is described in detail in RFC 2313.
RSA署名発生経過と結果のコード化はRFC2313で詳細に説明されます。
Housley, et. al. Standards Track [Page 59] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[59ページ]。
7.2.2 DSA Signature Algorithm
7.2.2 DSA署名アルゴリズム
A patent statement regarding the DSA can be found at the end of this profile.
このプロフィールの端でDSAに関する特許声明を見つけることができます。
The Digital Signature Algorithm (DSA) is also called the Digital Signature Standard (DSS). DSA was developed by the U.S. Government, and DSA is used in conjunction with the the SHA-1 one-way hash function. DSA is fully described in FIPS 186 [FIPS 186]. The ASN.1 OIDs used to identify this signature algorithm are:
また、Digital Signature Algorithm(DSA)はデジタル署名基準(DSS)と呼ばれます。 DSAは米国政府によって開発されました、そして、DSAはSHA-1の一方向ハッシュ関数に関連して使用されます。 DSAはFIPS186[FIPS186]で完全に説明されます。 この署名アルゴリズムを特定するのに使用されるASN.1OIDsは以下の通りです。
id-dsa-with-sha1 ID ::= {
iso(1) member-body(2) us(840) x9-57 (10040)
x9cm(4) 3 }
sha1とイドdsa ID:、:= iso(1)は(2) 私たち(840)x9-57(10040)x9cm(4)3をメンバーと同じくらい具体化させます。
Where the id-dsa-with-sha1 algorithm identifier appears as the algorithm field in an AlgorithmIdentifier, the encoding shall omit the parameters field. That is, the AlgorithmIdentifier shall be a SEQUENCE of one component - the OBJECT IDENTIFIER id-dsa-with-sha1.
sha1とイドdsaアルゴリズム識別子がAlgorithmIdentifierのアルゴリズム分野として現れるところでは、コード化はパラメタ分野を省略するものとします。 すなわち、AlgorithmIdentifierは1つのコンポーネントのSEQUENCEになるでしょう--sha1とOBJECT IDENTIFIERイドdsa。
The DSA parameters in the subjectPublicKeyInfo field of the certificate of the issuer shall apply to the verification of the signature.
発行人の証明書のsubjectPublicKeyInfo分野のDSAパラメタは署名の検証に適用されるものとします。
When signing, the DSA algorithm generates two values. These values are commonly referred to as r and s. To easily transfer these two values as one signature, they shall be ASN.1 encoded using the following ASN.1 structure:
署名するとき、DSAアルゴリズムは2つの値を生成します。 これらの値は一般的にrとsと呼ばれます。 1つの署名として容易にこれらの2つの値を移すために、以下のASN.1構造を使用することでコード化されたASNにな.1るでしょう:
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
以下をDss-Sig評価してください:= 系列r整数、s整数
7.3 Subject Public Key Algorithms
7.3 対象の公開鍵アルゴリズム
Certificates described by this profile may convey a public key for any public key algorithm. The certificate indicates the algorithm through an algorithm identifier. This algorithm identifier is an OID and optionally associated parameters.
このプロフィールによって説明された証明書はどんな公開鍵アルゴリズムのためにも公開鍵を伝えるかもしれません。 証明書はアルゴリズム識別子を通してアルゴリズムを示します。 このアルゴリズム識別子は、OIDと任意に関連しているパラメタです。
This section identifies preferred OIDs and parameters for the RSA, DSA, and Diffie-Hellman algorithms. Conforming CAs shall use the identified OIDs when issuing certificates containing public keys for these algorithms. Conforming applications supporting any of these algorithms shall, at a minimum, recognize the OID identified in this section.
RSA、DSA、およびディフィー-ヘルマンアルゴリズムのための都合のよいOIDsとパラメタはこのセクションは特定されます。これらのアルゴリズムのために公開鍵を含む証明書を発行するとき、CAsを従わせると、特定されたOIDsは使用されるものとします。これらのアルゴリズムのいずれかもサポートするアプリケーションを従わせると、最小限で、このセクションで特定されたOIDは認識されるものとします。
Housley, et. al. Standards Track [Page 60] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[60ページ]。
7.3.1 RSA Keys
7.3.1 RSAキー
The OID rsaEncryption identifies RSA public keys.
OID rsaEncryptionはRSA公開鍵を特定します。
pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) 1 }
pkcs-1 OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1)1をメンバーと同じくらい具体化させます。
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1}
rsaEncryptionオブジェクト識別子:、:= pkcs-1 1
The rsaEncryption OID is intended to be used in the algorithm field of a value of type AlgorithmIdentifier. The parameters field shall have ASN.1 type NULL for this algorithm identifier.
タイプAlgorithmIdentifierの価値のアルゴリズム分野でrsaEncryption OIDが使用されることを意図します。 パラメタ分野で、ASN.1はこのアルゴリズム識別子のためにNULLをタイプするものとします。
The RSA public key shall be encoded using the ASN.1 type RSAPublicKey:
RSA公開鍵はASN.1タイプRSAPublicKeyを使用することでコード化されるものとします:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e -- }
RSAPublicKey:、:= 系列係数INTEGER(n publicExponent INTEGER)e--
where modulus is the modulus n, and publicExponent is the public exponent e. The DER encoded RSAPublicKey is the value of the BIT STRING subjectPublicKey.
係数が係数nであり、publicExponentが公共の解説者eであるところ。 DER、コード化されたRSAPublicKeyはBIT STRING subjectPublicKeyの値です。
This OID is used in public key certificates for both RSA signature keys and RSA encryption keys. The intended application for the key may be indicated in the key usage field (see sec. 4.2.1.3). The use of a single key for both signature and encryption purposes is not recommended, but is not forbidden.
このOIDはRSA署名キーとRSA暗号化キーの両方に公開鍵証明書で使用されます。 キーの意図しているアプリケーションは主要な用法分野で示されるかもしれません。(秒に遭遇してください。 4.2.1.3). 単一のキーの署名と暗号化目的の両方の使用は、推薦されませんが、禁じられません。
If the keyUsage extension is present in an end entity certificate which conveys an RSA public key, any combination of the following values may be present: digitalSignature; nonRepudiation; keyEncipherment; and dataEncipherment. If the keyUsage extension is present in a CA certificate which conveys an RSA public key, any combination of the following values may be present: digitalSignature; nonRepudiation; keyEncipherment; dataEncipherment; keyCertSign; and cRLSign. However, this specification RECOMMENDS that if keyCertSign or cRLSign is present, both keyEncipherment and dataEncipherment should not be present.
keyUsage拡張子がRSA公開鍵を伝える終わりの実体証明書に存在しているなら、以下の値のどんな組み合わせも存在しているかもしれません: digitalSignature。 nonRepudiation。 keyEncipherment。 そして、dataEncipherment。 keyUsage拡張子がRSA公開鍵を伝えるカリフォルニア証明書に存在しているなら、以下の値のどんな組み合わせも存在しているかもしれません: digitalSignature。 nonRepudiation。 keyEncipherment。 dataEncipherment。 keyCertSign。 そして、cRLSign。 しかしながら、keyCertSignかcRLSignであるなら存在しているこの仕様RECOMMENDSであり、keyEnciphermentとdataEnciphermentの両方が存在しているべきではありません。
7.3.2 Diffie-Hellman Key Exchange Key
7.3.2 ディフィー-ヘルマンの主要な交換キー
The Diffie-Hellman OID supported by this profile is defined by ANSI X9.42 [X9.42].
このプロフィールによってサポートされたディフィー-ヘルマンOIDはANSI X9.42[X9.42]によって定義されます。
dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 }
dhpublicnumber OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)ansi-x942(10046)No.タイプ(2)1をメンバーと同じくらい具体化させます。
Housley, et. al. Standards Track [Page 61] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[61ページ]。
The dhpublicnumber OID is intended to be used in the algorithm field of a value of type AlgorithmIdentifier. The parameters field of that type, which has the algorithm-specific syntax ANY DEFINED BY algorithm, have the ASN.1 type DomainParameters for this algorithm.
タイプAlgorithmIdentifierの価値のアルゴリズム分野でdhpublicnumber OIDが使用されることを意図します。 ASN.1はこのアルゴリズムのためにそのタイプのパラメタ分野でDomainParametersをタイプします。(タイプはアルゴリズム特有の構文ANY DEFINED BYアルゴリズムを持っています)。
DomainParameters ::= SEQUENCE {
p INTEGER, -- odd prime, p=jq +1
g INTEGER, -- generator, g
q INTEGER, -- factor of p-1
j INTEGER OPTIONAL, -- subgroup factor
validationParms ValidationParms OPTIONAL }
DomainParameters:、:= 系列p INTEGER--奇素数、+1gのINTEGER(ジェネレータ、g q INTEGER)が因数分解するp-1j INTEGER OPTIONALのp=jq--サブグループ要素validationParms ValidationParms OPTIONAL
ValidationParms ::= SEQUENCE {
seed BIT STRING,
pgenCounter INTEGER }
ValidationParms:、:= 系列種子BIT STRING、pgenCounter INTEGER
The fields of type DomainParameters have the following meanings:
タイプDomainParametersの分野には、以下の意味があります:
p identifies the prime p defining the Galois field;
pはガロア分野を定義しながら、第1pを特定します。
g specifies the generator of the multiplicative subgroup of order
g;
gはオーダーgの乗法的なサブグループのジェネレータを指定します。
q specifies the prime factor of p-1;
qはp-1に関する主要因を指定します。
j optionally specifies the value that satisfies the equation
p=jq+1 to support the optional verification of group parameters;
jは任意にグループパラメタの任意の検証をサポートするために方程式p=jq+1を満たす値を指定します。
seed optionally specifies the bit string parameter used as the
seed for the system parameter generation process; and
種子は任意にシステム・パラメータ発生経過に種子として使用されるビット列パラメタを指定します。 そして
pgenCounter optionally specifies the integer value output as part
of the of the system parameter prime generation process.
pgenCounterが任意に部分としての整数値の出力を指定する、システム・パラメータでは、発生経過を用意してください。
If either of the parameter generation components (pgencounter or seed) is provided, the other shall be present as well.
パラメタ世代コンポーネント(pgencounterか種子)のどちらかを提供すると、また、もう片方も存在するでしょう。
The Diffie-Hellman public key shall be ASN.1 encoded as an INTEGER; this encoding shall be used as the contents (i.e., the value) of the subjectPublicKey component (a BIT STRING) of the subjectPublicKeyInfo data element.
ディフィー-ヘルマン公開鍵はINTEGERとしてコード化されたASNにな.1るでしょう。 このコード化はsubjectPublicKeyInfoデータ要素のsubjectPublicKeyの部品(BIT STRING)のコンテンツ(すなわち、値)として使用されるものとします。
DHPublicKey ::= INTEGER -- public key, y = g^x mod p
DHPublicKey:、:= INTEGER--公開鍵、yはg^xモッズpと等しいです。
Housley, et. al. Standards Track [Page 62] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[62ページ]。
If the keyUsage extension is present in a certificate which conveys a DH public key, the following values may be present: keyAgreement; encipherOnly; and decipherOnly. At most one of encipherOnly and decipherOnly shall be asserted in keyUsage extension.
keyUsage拡張子がDH公開鍵を伝える証明書に存在しているなら、以下の値は存在しているかもしれません: keyAgreement。 encipherOnly。 そして、decipherOnly。 高々、encipherOnlyとdecipherOnlyの1つはkeyUsage拡張子で断言されるものとします。
7.3.3 DSA Signature Keys
7.3.3 DSA署名キー
The Digital Signature Algorithm (DSA) is also known as the Digital Signature Standard (DSS). The DSA OID supported by this profile is
また、Digital Signature Algorithm(DSA)はデジタル署名基準(DSS)として知られています。 このプロフィールによってサポートされたDSA OIDはそうです。
id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040)
x9cm(4) 1 }
イド-dsa ID:、:= iso(1)は(2) 私たち(840)x9-57(10040) x9cm(4)1をメンバーと同じくらい具体化させます。
The id-dsa algorithm syntax includes optional parameters. These parameters are commonly referred to as p, q, and g. When omitted, the parameters component shall be omitted entirely. That is, the AlgorithmIdentifier shall be a SEQUENCE of one component - the OBJECT IDENTIFIER id-dsa.
イド-dsaアルゴリズム構文は任意のパラメタを含んでいます。 これらのパラメタは一般的にp、q、およびgと呼ばれます。 省略されると、パラメタコンポーネントは完全に省略されるものとします。 すなわち、AlgorithmIdentifierは1つのコンポーネントのSEQUENCEになるでしょう--OBJECT IDENTIFIERイド-dsa。
If the DSA algorithm parameters are present in the subjectPublicKeyInfo AlgorithmIdentifier, the parameters are included using the following ASN.1 structure:
DSAアルゴリズムパラメタがsubjectPublicKeyInfo AlgorithmIdentifierに存在しているなら、パラメタは以下のASN.1構造を使用することで含まれています:
Dss-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER }
Dss-Parms:、:= 系列p INTEGER、q INTEGER、g INTEGER
If the DSA algorithm parameters are absent from the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject certificate using DSA, then the certificate issuer's DSA parameters apply to the subject's DSA key. If the DSA algorithm parameters are absent from the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject certificate using a signature algorithm other than DSA, then the subject's DSA parameters are distributed by other means. If the subjectPublicKeyInfo AlgorithmIdentifier field omits the parameters component and the CA signed the subject with a signature algorithm other than DSA, then clients shall reject the certificate.
DSAアルゴリズムパラメタがDSAを使用することで対象の証明書であると署名されるsubjectPublicKeyInfo AlgorithmIdentifierとカリフォルニアから欠けるなら、証明書発行人のDSAパラメタは対象のDSAキーに適用されます。 DSAアルゴリズムパラメタがDSA以外の署名アルゴリズムを使用することで対象の証明書であると署名されるsubjectPublicKeyInfo AlgorithmIdentifierとカリフォルニアから欠けるなら、対象のDSAパラメタは他の手段で分配されます。 subjectPublicKeyInfo AlgorithmIdentifier分野がDSA以外の署名アルゴリズムでパラメタコンポーネントと対象であると署名されるカリフォルニアを省略するなら、クライアントは証明書を拒絶するものとします。
When signing, DSA algorithm generates two values. These values are commonly referred to as r and s. To easily transfer these two values as one signature, they are ASN.1 encoded using the following ASN.1 structure:
署名するとき、DSAアルゴリズムは2つの値を生成します。 これらの値は一般的にrとsと呼ばれます。 1つの署名として容易にこれらの2つの値を移すために、それらは以下のASN.1構造を使用することでコード化されたASN.1です:
Housley, et. al. Standards Track [Page 63] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[63ページ]。
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
以下をDss-Sig評価してください:= 系列r整数、s整数
The encoded signature is conveyed as the value of the BIT STRING signature in a Certificate or CertificateList.
コード化された署名はCertificateかCertificateListのBIT STRING署名の値として伝えられます。
The DSA public key shall be ASN.1 DER encoded as an INTEGER; this encoding shall be used as the contents (i.e., the value) of the subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo data element.
DSA公開鍵はINTEGERとしてコード化されたASN.1DERになるでしょう。 このコード化はSubjectPublicKeyInfoデータ要素のsubjectPublicKeyの部品(BIT STRING)のコンテンツ(すなわち、値)として使用されるものとします。
DSAPublicKey ::= INTEGER -- public key, Y
DSAPublicKey:、:= INTEGER--公開鍵、Y
If the keyUsage extension is present in an end entity certificate which conveys a DSA public key, any combination of the following values may be present: digitalSignature; and nonRepudiation.
keyUsage拡張子がDSA公開鍵を伝える終わりの実体証明書に存在しているなら、以下の値のどんな組み合わせも存在しているかもしれません: digitalSignature。 そして、nonRepudiation。
If the keyUsage extension is present in an CA certificate which conveys a DSA public key, any combination of the following values may be present: digitalSignature; nonRepudiation; keyCertSign; and cRLSign.
keyUsage拡張子がDSA公開鍵を伝えるカリフォルニア証明書に存在しているなら、以下の値のどんな組み合わせも存在しているかもしれません: digitalSignature。 nonRepudiation。 keyCertSign。 そして、cRLSign。
8 References
8つの参照箇所
[FIPS 180-1] Federal Information Processing Standards Publication
(FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
[Supersedes FIPS PUB 180 dated 11 May 1993.]
[FIPS180-1] 連邦政府の情報処理規格公表(FIPSパブ)180-1、安全なハッシュ規格、1995年4月17日。 [1993年5月11日が日付を入れられたFIPS PUB180に取って代わります。]
[FIPS 186] Federal Information Processing Standards Publication
(FIPS PUB) 186, Digital Signature Standard, 18 May
1994.
[FIPS186] 連邦政府の情報処理規格公表(FIPSパブ)186、デジタル署名基準、1994年5月18日。
[RC95] Rogier, N. and Chauvaud, P., "The compression function
of MD2 is not collision free," Presented at Selected
Areas in Cryptography '95, May 1995.
Cryptography95年、1995年5月のSelected Areasの[RC95]ロジエとN.と「MD2の圧縮機能には、衝突がないというわけではない」Chauvaud、P.、Presented。
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC 822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
[RFC822] クロッカー、D.、「ARPAインターネット・テキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[RFC 1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
Mockapetris、[RFC1034]P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC 1319] Kaliski, B., "The MD2 Message-Digest Algorithm," RFC
1319, April 1992.
[RFC1319] Kaliski、B.、「MD2メッセージダイジェストアルゴリズム」、RFC1319、1992年4月。
Housley, et. al. Standards Track [Page 64] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[64ページ]。
[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC
1321, April 1992.
[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[RFC 1422] 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月。
[RFC 1423] Balenson, D., "Privacy Enhancement for Internet
Electronic Mail: Part III: Algorithms, Modes, and
Identifiers," RFC 1423, February 1993.
Balenson、[RFC1423]D.、「インターネット電子メールのためのプライバシー増進:」 パートIII: 「アルゴリズム、モード、および識別子」、RFC1423、2月1993日
[RFC 1519] Fuller, V., Li, T., Yu, J. and K. Varadhan. "Classless
Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993.
[RFC1519] フラー、V.、李、T.、ユー、J.、およびK.Varadhan。 「以下を掘る(CIDR)階級のない相互ドメイン」 「アドレス課題と集合戦略」、RFC1519、9月1993日
[RFC 1738] Berners-Lee, T., Masinter L., and M. McCahill.
"Uniform Resource Locators (URL)", RFC 1738, December
1994.
[RFC1738] バーナーズ・リー、T.、Masinter L.、およびM.McCahill。 「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[RFC 1778] Howes, T., Kille S., Yeong, W. and C. Robbins. "The
String Representation of Standard Attribute Syntaxes,"
RFC 1778, March 1995.
[RFC1778] ハウズ、T.、Kille S.、Yeong、W.、およびC.ロビンス。 「標準の属性構文のストリング表現」、RFC1778、1995年3月。
[RFC 1883] Deering, S. and R. Hinden. "Internet Protocol, Version
6 (IPv6) Specification", RFC 1883, December 1995.
[RFC1883] デアリング、S.、およびR.Hinden。 「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC1883、12月1995日
[RFC 2119] 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月。
[RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
Sataluri. "Using Domains in LDAP/X.500 Distinguished
Names", RFC 2247, January 1998.
[RFC2247] Kille、S.、ウォール、M.、グリムスター、A.、ヒューバー、R.、およびS.Sataluri。 「LDAP/X.500分類名にドメインを使用します」、RFC2247、1998年1月。
[RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、RFC2277、1998年1月。
[RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[RFC2279] Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
[RFC 2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC
2313, March 1998.
Kaliski、[RFC2313]B.、「PKCS#1:」 1.5インチ(RFC2313)が1998に行進させるRSA暗号化バージョン
[SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A
1997-02-06.
[SDN.701] SDN.701、「メッセージセキュリティは4インチについて議定書の中で述べて、改正は1997年2月6日です」。
[X.208] CCITT Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1), 1988.
[X.208]CCITT推薦X.208: 抽象構文記法1(ASN.1)の仕様、1988。
Housley, et. al. Standards Track [Page 65] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[65ページ]。
[X.501] ITU-T Recommendation X.501: Information Technology -
Open Systems Interconnection - The Directory: Models,
1993.
[X.501]ITU-T推薦X.501: 情報技術--オープン・システム・インターコネクション--ディレクトリ: モデル、1993。
[X.509] ITU-T Recommendation X.509 (1997 E): Information
Technology - Open Systems Interconnection - The
Directory: Authentication Framework, June 1997.
[X.509]ITU-T推薦X.509(1997E): 情報技術--オープン・システム・インターコネクション--ディレクトリ: 1997年6月の認証フレームワーク。
[X.520] ITU-T Recommendation X.520: Information Technology -
Open Systems Interconnection - The Directory: Selected
Attribute Types, 1993.
[X.520]ITU-T推薦X.520: 情報技術--オープン・システム・インターコネクション--ディレクトリ: 属性タイプ、1993を選択しました。
[X9.42] ANSI X9.42-199x, Public Key Cryptography for The
Financial Services Industry: Agreement of Symmetric
Algorithm Keys Using Diffie-Hellman (Working Draft),
December 1997.
[X9.42]ANSI X9.42-199x、金融サービス業界のための公開鍵暗号: 1997年12月のディフィー-ヘルマン(作業草案)を使用する左右対称のアルゴリズムキーの協定。
[X9.55] ANSI X9.55-1995, Public Key Cryptography For The
Financial Services Industry: Extensions To Public Key
Certificates And Certificate Revocation Lists, 8
December, 1995.
[X9.55]ANSI X9.55-1995、金融サービス業界のための公開鍵暗号: 1995年12月8日の公開鍵証明書と証明書失効リストへの拡大。
[X9.57] ANSI X9.57-199x, Public Key Cryptography For The
Financial Services Industry: Certificate Management
(Working Draft), 21 June, 1996.
[X9.57]ANSI X9.57-199x、金融サービス業界のための公開鍵暗号: (作業草案)、1996年6月21日に管理を証明してください。
9 Intellectual Property Rights
9 知的所有権
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 公表に利用可能にされた権利のクレームと利用可能に作られるべきライセンスのどんな保証か、された試みの結果もコピーされます。
Housley, et. al. Standards Track [Page 66] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[66ページ]。
obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
作成者によるそのような所有権の使用に一般的なライセンスか許可を得てください。さもないと、IETF事務局からこの仕様のユーザを得ることができます。
10 Security Considerations
10 セキュリティ問題
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 that should be considered by implementors, administrators, and users.
しかしながら、この仕様の範囲の外のセキュリティ要素はユーザを証明するために提供された保証に影響するでしょう。 このセクションは作成者、管理者、およびユーザによって考えられるべきである重要な問題を強調します。
The procedures performed by CAs and RAs to validate the binding of the subject's identity of their public key greatly affect the assurance that should be placed in the certificate. Relying parties may wish to review the CA's certificate practice statement. This may be particularly important when issuing certificates to other CAs.
彼らの公開鍵に関する対象のアイデンティティの結合を有効にするためにCAsとRAsによって実行された手順は証明書に置かれるべきである保証に大いに影響します。 信用パーティーは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., SSL) use a single key pair for signature and key management.
主要な1組の署名と他の目的の両方の使用は強くお勧めできないです。 別々の主要な組の署名とかぎ管理の使用はユーザへのいくつかの利益を提供します。 署名キーの損失か公開に関連している分岐はかぎ管理キーの損失か公開と異なっています。 別々の主要な組を使用すると、バランスのとれていてフレキシブルな応答は可能にします。 同様に、それぞれの主要な組単位の異なった有効期間かキー長がいくつかのアプリケーション環境で適切であるかもしれません。 残念ながら、いくつかのレガシーアプリケーション(例えば、SSL)が署名とかぎ管理に主要な1組を使用します。
The protection afforded private keys is a critical factor in maintaining security. 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 the compromise is detected, all certificates issued to the CA shall 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
秘密鍵が提供された保護は警備を維持することにおいて重要な要素です。 小規模に、攻撃者がそれらのふりをすることを許可するか、またはユーザが彼らの秘密鍵を保護しないと、それらの個人情報を解読するでしょう。 より大きいスケールでは、CAの個人的な署名キーの感染は壊滅的な効果を持っているかもしれません。 攻撃者が目だたない状態で秘密鍵を得るなら、攻撃者はにせの証明書とCRLsを発行するかもしれません。 にせの証明書とCRLsの存在はシステムにおける信用を損ねるでしょう。 感染が検出されるなら、カリフォルニアに発行されたすべての証明書が取り消されるものとします、他のCAsのユーザとユーザの間のサービスを防いで。 CAsが強い技術的な程度(例えば、耐タンパー性の暗号のモジュール)の組み合わせを実装するようにアドバイスされて、そのような感染が問題が多くなるので適切になった後に再建
Housley, et. al. Standards Track [Page 67] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[67ページ]。
management procedures (e.g., separation of duties) to avoid such an incident.
そのようなインシデントを避ける管理手順(例えば、義務の分離)。
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 are advised to maintain secure backup for signing keys. The security of the key backup procedures is a critical factor in avoiding key compromise.
また、CAの個人的な署名キーの損失も問題が多いかもしれません。 カリフォルニアは、CRLsを生産できませんし、正常な主要なロールオーバーを実行できないでしょう。CAsが署名キーのために安全なバックアップを維持するようにアドバイスされます。 主要なバックアップ手順のセキュリティは主要な感染を避けることにおいて重要な要素です。
The availability and freshness of revocation information will affect the degree of assurance that should be placed in a certificate. While certificates expire naturally, events may occur during its natural lifetime which 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. Similarly, implementations of the Path Validation mechanism described in section 6 that omit revocation checking provide less assurance than those that support it.
取消し情報の有用性と新しさは証明書に置かれるべきである保証の度合いに影響するでしょう。 証明書は自然に期限が切れますが、イベントは生まれながらの生涯起こるかもしれません(対象と公開鍵の間の結合を否定します)。 取消し情報がタイミングが悪いか、または入手できないなら、結合に関連している保証は明確に抑えられます。 同様に、取消しの照合を省略するセクション6で説明されたPath Validationメカニズムの実装はそれをサポートするものより少ない保証を提供します。
The 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 will make the trusted CA information difficult to maintain. On the other hand, selection of only one trusted CA may limit users to a closed community of users until a global PKI emerges.
さらに、主要な感染かカリフォルニアの失敗が信じられたカリフォルニアに起こるところでは、ユーザは、経路合法化ルーチンに提供された情報を変更する必要があるでしょう。 あまりに多くの信じられたCAsの品揃えは信じられたカリフォルニアを維持するのが難しい情報にするでしょう。 他方では、グローバルなPKIが現れるまで、1だけの信じられたカリフォルニアの選択はユーザをユーザの閉じている共同体に制限するかもしれません。
The quality of implementations that process certificates may also affect 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が強い暗号のテクニックを使うことができるように暗号理論における進歩に注意するよう奨励されます。 発行する追加、CAsが証明書を断るはずであるコネ
Housley, et. al. Standards Track [Page 68] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[68ページ]。
CAs or end entities that generate weak signatures.
弱い署名を生成するCAsか終わりの実体。
Inconsistent application of name comparison rules may 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 require comparison of strings without regard 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.
名前比較規則の無節操な適用は無効のX.509証明経路の承認、または有効なものの拒絶をもたらすかもしれません。 仕様のX.500シリーズは分類名が、関係のないストリングの比較がケースに入れるのを必要とする比較、文字集合、マルチキャラクタ余白サブストリング、または主で引きずっている余白と規則を定義します。 2進の比較に最小限で支持を要して、この仕様はこれらの要件を弛緩します。
CAs shall 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 the latter CA. If CAs use different encodings, implementations of this specification may 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 shall be stated identically to the encoding used in the subject field or subjectAltName extension. If not, (1) name constraints stated as excludedSubTrees will not match and invalid paths will be accepted and (2) 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 where ever possible.
さらに、分類名の名前規制は同様に対象の分野かsubjectAltName拡張子に使用されるコード化に述べられているものとします。 (2) (1) そうでなければ、excludedSubTreesが合わないので述べられた名前規制と無効の経路を受け入れるでしょう、そして、permittedSubtreesが合わないので言い表された名前規制と有効な経路を拒絶するでしょう。 無効の経路の承認を避けるために、CAsはpermittedSubtreesとして可能であるいったいどこに分類名の名前規制を述べるはずであるか。
Housley, et. al. Standards Track [Page 69] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[69ページ]。
Appendix A. Psuedo-ASN.1 Structures and OIDs
付録A.のPsuedo-ASN.1構造とOIDs
This section 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 defintions for the UNIVERSAL Types with the 1988 catch-all "ANY".
この付録は、「少しも」UNIVERSAL Typesのためのdefintionsを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-88(1)}
PKIX1Explicit88iso(1)の特定された組織(3)のdod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)のイドのpkix1の明白な88(1)
DEFINITIONS EXPLICIT TAGS ::=
定義、明白なタグ:、:=
BEGIN
始まってください。
-- EXPORTS ALL --
-- すべてをエクスポートします--
-- IMPORTS NONE --
-- なにもインポートしません--
-- UNIVERSAL Types defined in '93 and '98 ASN.1 -- but required by this specification
-- UNIVERSAL Typesが93年と98年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/ITU 10646-1
BMPString:、:= [UNIVERSAL30] ISO/IEC/ITU10646-1のBMPStringがUniversalStringとモデルの「副-タイプ」であるというIMPLICIT OCTET STRING基本多言語水準
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The content of this type conforms to RFC 2279.
UTF8String:、:= [UNIVERSAL12] IMPLICIT OCTET STRING--このタイプの内容はRFC2279に従います。
-- -- PKIX specific OIDs
-- -- PKIXの特定のOIDs
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
イド-pkix OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)のインターネット(1)
Housley, et. al. Standards Track [Page 70] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[70ページ]。
security(5) mechanisms(5) pkix(7) }
-- PKIX arcs
セキュリティ(5)メカニズム(5)pkix(7) -- 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 }
イド広告ocsp OBJECT IDENTIFIER、:、:= イド広告1、イド広告caIssuers OBJECT IDENTIFIER、:、:= イド広告2
-- attribute data types --
-- データ型を結果と考えてください--
Attribute ::= SEQUENCE {
type AttributeType,
values SET OF AttributeValue
-- at least one value is required -- }
以下を結果と考えてください:= 系列AttributeType、値のSET OF AttributeValueをタイプしてください(少なくとも1つの値が必要です)。
AttributeType ::= OBJECT IDENTIFIER
AttributeType:、:= オブジェクト識別子
AttributeValue ::= ANY
AttributeValue:、:= 少しも
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のために定義をタイプしてください
--Arc for standard naming attributes
id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4}
--標準の命名属性のためのアーク、イド、-、OBJECT IDENTIFIER:、:= 共同iso-ccitt(2) ds(5)4
Housley, et. al. Standards Track [Page 71] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[71ページ]。
-- Attributes of type NameDirectoryString
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}
-- タイプNameDirectoryString名前におけるイドAttributeTypeの属性:、:= イド、-、41、姓におけるイドAttributeType:、:= イド、-、4、givenName AttributeTypeのイド:、:= イド、-、42、イニシャルにおけるイドAttributeType:、:= イド、-、43、generationQualifier AttributeTypeのイド:、:= イド、-、44
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:、:= 選択teletexString TeletexString(サイズ(1..ub-名前))、printableString PrintableString(サイズ(1..ub-名前))、universalString UniversalString(サイズ(1..ub-名前))、utf8String UTF8String(サイズ(1..ub-名前))、bmpString BMPString(サイズ(1..ub-名前))
--
--
id-at-commonName AttributeType ::= {id-at 3}
commonName AttributeTypeのイド:、:= イド、-、3
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:、:= 選択teletexString TeletexString(サイズ(1..ub-一般名))、printableString PrintableString(サイズ(1..ub-一般名))、universalString UniversalString(サイズ(1..ub-一般名))、utf8String UTF8String(サイズ(1..ub-一般名))、bmpString BMPString(サイズ(1..ub-一般名))
--
--
id-at-localityName AttributeType ::= {id-at 7}
localityName AttributeTypeのイド:、:= イド、-、7
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:、:= 選択teletexString TeletexString(サイズ(1..ub場所名))、printableString PrintableString(サイズ(1..ub場所名))、universalString UniversalString(サイズ(1..ub場所名))、utf8String UTF8String(サイズ(1..ub場所名))、bmpString BMPString(サイズ(1..ub場所名))
--
--
id-at-stateOrProvinceName AttributeType ::= {id-at 8}
stateOrProvinceName AttributeTypeのイド:、:= イド、-、8
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:、:= 選択teletexString TeletexString(サイズ(1..ub州の名))、printableString PrintableString(サイズ(1..ub州の名))、universalString UniversalString(サイズ(1..ub州の名))、utf8String UTF8String(サイズ(1..ub州の名))、bmpString BMPString(サイズ(1..ub州の名))
--
--
Housley, et. al. Standards Track [Page 72] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[72ページ]。
id-at-organizationName AttributeType ::= {id-at 10}
organizationName AttributeTypeのイド:、:= イド、-、10
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:、:= 選択teletexString TeletexString(サイズ(組織が命名する1..ub))、printableString PrintableString(サイズ(組織が命名する1..ub))、universalString UniversalString(サイズ(組織が命名する1..ub))、utf8String UTF8String(サイズ(組織が命名する1..ub))、bmpString BMPString(サイズ(組織が命名する1..ub))
--
--
id-at-organizationalUnitName AttributeType ::= {id-at 11}
organizationalUnitName AttributeTypeのイド:、:= イド、-、11
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:、:= 選択teletexString TeletexString(サイズ(組織的なユニットが命名する1..ub))、printableString PrintableString(サイズ(組織的なユニットが命名する1..ub))、universalString UniversalString(サイズ(組織的なユニットが命名する1..ub))、utf8String UTF8String(サイズ(組織的なユニットが命名する1..ub))、bmpString BMPString(サイズ(組織的なユニットが命名する1..ub))
--
--
id-at-title AttributeType ::= {id-at 12}
タイトルにおけるイドAttributeType:、:= イド、-、12
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:、:= 選択teletexString TeletexString(サイズ(1..ub-タイトル))、printableString PrintableString(サイズ(1..ub-タイトル))、universalString UniversalString(サイズ(1..ub-タイトル))、utf8String UTF8String(サイズ(1..ub-タイトル))、bmpString BMPString(サイズ(1..ub-タイトル))
--
--
id-at-dnQualifier AttributeType ::= {id-at 46}
X520dnQualifier ::= PrintableString
dnQualifier AttributeTypeのイド:、:= イド、-、46、X520dnQualifier:、:= PrintableString
id-at-countryName AttributeType ::= {id-at 6}
X520countryName ::= PrintableString (SIZE (2)) -- IS 3166 codes
countryName AttributeTypeのイド:、:= イド、-、6、X520countryName:、:= PrintableString、(SIZE(2))--、3166のコードです。
-- 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をメンバーと同じくらい具体化させます。
emailAddress AttributeType ::= { pkcs-9 1 }
emailAddress AttributeType:、:= pkcs-9 1
Housley, et. al. Standards Track [Page 73] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[73ページ]。
Pkcs9email ::= IA5String (SIZE (1..ub-emailaddress-length))
Pkcs9email:、:= 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つの最大)を設定してください。
-- 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
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 shall be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version shall be v2 or v3
extensions [3] Extensions OPTIONAL
-- If present, version shall be v3 -- }
TBSCertificate:、:= 系列バージョン[0]バージョンDEFAULT v1、serialNumber CertificateSerialNumber、署名AlgorithmIdentifier、発行人Name(正当性Validity)はNameをかけます、subjectPublicKeyInfo SubjectPublicKeyInfo、issuerUniqueID[1]IMPLICIT UniqueIdentifier OPTIONAL(プレゼント、バージョンは、v2かIMPLICIT UniqueIdentifier OPTIONALにv3 subjectUniqueID[2]なるでしょう--存在しているなら、存在しているならバージョンがv2かv3拡大[3]拡大OPTIONALになると、バージョンはv3になるでしょう)
Version ::= INTEGER { v1(0), v2(1), v3(2) }
バージョン:、:= 整数v1(0)、v2(1)、v3(2)
CertificateSerialNumber ::= INTEGER
CertificateSerialNumber:、:= 整数
Housley, et. al. Standards Track [Page 74] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[74ページ]。
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 }
拡大:、:= 系列extnID OBJECT IDENTIFIER、重要なBOOLEAN DEFAULT FALSE、extnValue OCTET STRING
-- 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, shall be v2
signature AlgorithmIdentifier,
issuer Name,
thisUpdate Time,
nextUpdate Time OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate Time,
crlEntryExtensions Extensions OPTIONAL
-- if present, shall be v2
} OPTIONAL,
crlExtensions [0] Extensions OPTIONAL
-- if present, shall 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]拡大OPTIONALプレゼントがv2になるなら
-- Version, Time, CertificateSerialNumber, and Extensions were -- defined earlier for use in the certificate structure
-- バージョン、Time、CertificateSerialNumber、およびExtensionsはそうでした--証明書構造の使用のために、より早く定義されます。
AlgorithmIdentifier ::= SEQUENCE {
AlgorithmIdentifier:、:= 系列
Housley, et. al. Standards Track [Page 75] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[75ページ]。
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
-- contains a value of the type
-- registered for use with the
-- algorithm object identifier value
アルゴリズムOBJECT IDENTIFIER、パラメタANY DEFINED BYアルゴリズムOPTIONAL -- タイプ--使用に登録するa値を含んでいる、--、アルゴリズム物の識別子価値
-- Algorithm OIDs and parameter structures
-- アルゴリズムOIDsとパラメタ構造
pkcs-1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }
pkcs-1 OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1)1をメンバーと同じくらい具体化させます。
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
rsaEncryption物の識別子:、:= pkcs-1 1
md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 }
md2WithRSAEncryption物の識別子:、:= pkcs-1 2
md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 }
md5WithRSAEncryption物の識別子:、:= pkcs-1 4
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 }
sha1WithRSAEncryption物の識別子:、:= pkcs-1 5
id-dsa-with-sha1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 }
sha1 OBJECT IDENTIFIERとイドdsa:、:= iso(1)は(2) 私たち(840)x9-57(10040)x9algorithm(4)3をメンバーと同じくらい具体化させます。
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
以下をDss-Sig評価してください:= 系列r整数、s整数
dhpublicnumber OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }
dhpublicnumber OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)ansi-x942(10046)No.タイプ(2)1をメンバーと同じくらい具体化させます。
DomainParameters ::= SEQUENCE {
p INTEGER, -- odd prime, p=jq +1
g INTEGER, -- generator, g
q INTEGER, -- factor of p-1
j INTEGER OPTIONAL, -- subgroup factor, j>= 2
validationParms ValidationParms OPTIONAL }
DomainParameters:、:= 系列p INTEGER--奇素数、p=jqの+1gのINTEGER--ジェネレータ、g q INTEGER--p-1j INTEGER OPTIONALの要素--サブグループ要素、j>は2validationParms ValidationParms OPTIONALと等しいです。
ValidationParms ::= SEQUENCE {
seed BIT STRING,
pgenCounter INTEGER }
ValidationParms:、:= 系列種子BIT STRING、pgenCounter INTEGER
id-dsa OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }
イド-dsa OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)x9-57(10040) x9algorithm(4)1をメンバーと同じくらい具体化させます。
Dss-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER }
Dss-Parms:、:= 系列p INTEGER、q INTEGER、g INTEGER
Housley, et. al. Standards Track [Page 76] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[76ページ]。
-- x400 address syntax starts here -- OR Names
-- ここのx400アドレス構文始め--OR Names
ORAddress ::= SEQUENCE {
built-in-standard-attributes BuiltInStandardAttributes,
built-in-domain-defined-attributes
BuiltInDomainDefinedAttributes OPTIONAL,
-- see also teletex-domain-defined-attributes
extension-attributes ExtensionAttributes OPTIONAL }
-- The OR-address is semantically absent from the OR-name if the
-- built-in-standard-attribute sequence is empty and the
-- built-in-domain-defined-attributes and extension-attributes are
-- both omitted.
ORAddress:、:= そして、SEQUENCE、内蔵の標準の属性BuiltInStandardAttributes、内蔵のドメインが属性を定義しているBuiltInDomainDefinedAttributes OPTIONAL--また、テレテックスのドメインの定義された属性拡大属性ExtensionAttributes OPTIONALを見てください--OR-アドレスがOR-名前から意味的に欠けている、--、内蔵の標準の属性系列が空である--拡大属性はそうです--内蔵のドメインは属性を定義して、ともに省略されます。
-- Built-in Standard Attributes
-- 内蔵の標準の属性
BuiltInStandardAttributes ::= SEQUENCE {
country-name CountryName OPTIONAL,
administration-domain-name AdministrationDomainName OPTIONAL,
network-address [0] NetworkAddress OPTIONAL,
-- see also extended-network-address
terminal-identifier [1] TerminalIdentifier OPTIONAL,
private-domain-name [2] PrivateDomainName OPTIONAL,
organization-name [3] OrganizationName OPTIONAL,
-- see also teletex-organization-name
numeric-user-identifier [4] NumericUserIdentifier OPTIONAL,
personal-name [5] PersonalName OPTIONAL,
-- see also teletex-personal-name
organizational-unit-names [6] OrganizationalUnitNames OPTIONAL
-- see also teletex-organizational-unit-names -- }
BuiltInStandardAttributes:、:= 系列{ 国名のCountryName OPTIONAL、管理ドメイン名AdministrationDomainName OPTIONAL、ネットワーク・アドレス0NetworkAddress OPTIONAL--また、端末の識別子1拡張ネットワーク・アドレスTerminalIdentifier OPTIONAL、個人的なドメイン名2PrivateDomainName OPTIONAL、組織名の3OrganizationName OPTIONALを見てください; また、テレテックス組織名の数値ユーザ識別子4NumericUserIdentifier OPTIONALを見てください、個人名5PersonalName OPTIONAL--また、テレテックス個人名組織的なユニット名の6OrganizationalUnitNames 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 {
PrivateDomainName:、:= 特選
Housley, et. al. Standards Track [Page 77] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[77ページ]。
numeric NumericString (SIZE (1..ub-domain-name-length)), printable PrintableString (SIZE (1..ub-domain-name-length)) }
数値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の数値ユーザイドの長さ))
PersonalName ::= SET {
surname [0] PrintableString (SIZE (1..ub-surname-length)),
given-name [1] PrintableString
(SIZE (1..ub-given-name-length)) OPTIONAL,
initials [2] PrintableString (SIZE (1..ub-initials-length)) OPTIONAL,
generation-qualifier [3] PrintableString
(SIZE (1..ub-generation-qualifier-length)) OPTIONAL }
-- see also teletex-personal-name
PersonalName:、:= SET、姓[0]PrintableString(SIZE(1..ub姓の長さ))(名[1]PrintableString(SIZE(1..ub当然のことの名前の長さ))OPTIONAL)は[2] PrintableString(SIZE(1..ubは長さに頭文字をつける))OPTIONALに頭文字をつけます、世代資格を与える人[3]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] INTEGER (0..ub-extension-attributes),
extension-attribute-value [1]
ANY DEFINED BY extension-attribute-type }
ExtensionAttribute:、:= 系列拡大属性タイプ[0]INTEGER(0..ub拡大属性)、拡大属性値[1]ANY DEFINED BY拡大属性タイプ
Housley, et. al. Standards Track [Page 78] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[78ページ]。
-- Extension types and attribute values --
-- 拡大タイプと属性値--
common-name INTEGER ::= 1
一般名INTEGER:、:= 1
CommonName ::= PrintableString (SIZE (1..ub-common-name-length))
CommonName:、:= PrintableString(サイズ(1..ubの一般的な名前の長さ))
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
TeletexOrganizationName ::=
TeletexString (SIZE (1..ub-organization-name-length))
TeletexOrganizationName:、:= TeletexString(サイズ(1..ub組織名前の長さ))
teletex-personal-name INTEGER ::= 4
テレテックス個人名INTEGER:、:= 4
TeletexPersonalName ::= SET {
surname [0] TeletexString (SIZE (1..ub-surname-length)),
given-name [1] TeletexString
(SIZE (1..ub-given-name-length)) OPTIONAL,
initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL,
generation-qualifier [3] TeletexString (SIZE
(1..ub-generation-qualifier-length)) OPTIONAL }
TeletexPersonalName:、:= セットします。姓[0]TeletexString(SIZE(1..ub姓の長さ))(名[1]TeletexString(SIZE(名前の長さが与えられた1..ub))OPTIONAL)は[2] TeletexString(SIZE(1..ubは長さに頭文字をつける))OPTIONALに頭文字をつけます、世代資格を与える人[3]TeletexString(SIZE(1..ub世代資格を与える人の長さ))OPTIONAL
teletex-organizational-unit-names INTEGER ::= 5
テレテックスの組織的なユニット名のINTEGER:、:= 5
TeletexOrganizationalUnitNames ::= SEQUENCE SIZE
(1..ub-organizational-units) OF TeletexOrganizationalUnitName
TeletexOrganizationalUnitNames:、:= (1..ubの組織的なユニット)の系列サイズTeletexOrganizationalUnitName
TeletexOrganizationalUnitName ::= TeletexString
(SIZE (1..ub-organizational-unit-name-length))
TeletexOrganizationalUnitName:、:= TeletexString(サイズ(1..ubの組織的なユニットは長さを命名します))
pds-name INTEGER ::= 7
pds-名前INTEGER:、:= 7
PDSName ::= PrintableString (SIZE (1..ub-pds-name-length))
PDSName:、:= PrintableString(サイズ(1..ub-pds名前の長さ))
physical-delivery-country-name INTEGER ::= 8
物理的な配送国の名のINTEGER:、:= 8
PhysicalDeliveryCountryName ::= CHOICE {
x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)),
iso-3166-alpha2-code PrintableString
(SIZE (ub-country-name-alpha-length)) }
PhysicalDeliveryCountryName:、:= 選択x121-dcc-コードNumericString(SIZE(ubの国の名前の数値長さ))、iso-3166-alpha2-コードPrintableString(SIZE(ub国の名前アルファの長さ))
postal-code INTEGER ::= 9
郵便番号INTEGER:、:= 9
PostalCode ::= CHOICE {
PostalCode:、:= 特選
Housley, et. al. Standards Track [Page 79] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[79ページ]。
numeric-code NumericString (SIZE (1..ub-postal-code-length)), printable-code PrintableString (SIZE (1..ub-postal-code-length)) }
数字コードNumericString(SIZE(1..ubの郵便のコードの長さ))、印刷可能なコードPrintableString(SIZE(1..ubの郵便のコードの長さ))
physical-delivery-office-name INTEGER ::= 10
物理的な配送オフィス名のINTEGER:、:= 10
PhysicalDeliveryOfficeName ::= PDSParameter
PhysicalDeliveryOfficeName:、:= PDSParameter
physical-delivery-office-number INTEGER ::= 11
物理的な配送局番号INTEGER:、:= 11
PhysicalDeliveryOfficeNumber ::= PDSParameter
PhysicalDeliveryOfficeNumber:、:= PDSParameter
extension-OR-address-components INTEGER ::= 12
拡大かアドレス構成要素整数:、:= 12
ExtensionORAddressComponents ::= PDSParameter
ExtensionORAddressComponents:、:= PDSParameter
physical-delivery-personal-name INTEGER ::= 13
物理的な配送個人名INTEGER:、:= 13
PhysicalDeliveryPersonalName ::= PDSParameter
PhysicalDeliveryPersonalName:、:= PDSParameter
physical-delivery-organization-name INTEGER ::= 14
物理的な配送組織名のINTEGER:、:= 14
PhysicalDeliveryOrganizationName ::= PDSParameter
PhysicalDeliveryOrganizationName:、:= PDSParameter
extension-physical-delivery-address-components INTEGER ::= 15
拡大身体検査配送アドレス構成要素INTEGER:、:= 15
ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter
ExtensionPhysicalDeliveryAddressComponents:、:= PDSParameter
unformatted-postal-address INTEGER ::= 16
非フォーマットされた郵便の宛先INTEGER:、:= 16
UnformattedPostalAddress ::= SET {
printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF
PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL,
teletex-string TeletexString
(SIZE (1..ub-unformatted-address-length)) OPTIONAL }
UnformattedPostalAddress:、:= セットします。印刷可能なアドレスSEQUENCE SIZE(1..ub-pdsの物理的なアドレス記入欄)OF PrintableString(SIZE(1..ub-pdsパラメタの長さ))OPTIONAL、テレテックスストリングTeletexString(SIZE(1..ub-unformattedアドレスの長さ))OPTIONAL
street-address INTEGER ::= 17
住所INTEGER:、:= 17
StreetAddress ::= PDSParameter
StreetAddress:、:= PDSParameter
post-office-box-address INTEGER ::= 18
郵便の箱のアドレスINTEGER:、:= 18
PostOfficeBoxAddress ::= PDSParameter
PostOfficeBoxAddress:、:= PDSParameter
poste-restante-address INTEGER ::= 19
poste-restante-アドレスINTEGER:、:= 19
PosteRestanteAddress ::= PDSParameter
PosteRestanteAddress:、:= PDSParameter
unique-postal-name INTEGER ::= 20
ユニークな郵便の名前INTEGER:、:= 20
Housley, et. al. Standards Track [Page 80] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[80ページ]。
UniquePostalName ::= PDSParameter
UniquePostalName:、:= PDSParameter
local-postal-attributes INTEGER ::= 21
地方の郵便の属性INTEGER:、:= 21
LocalPostalAttributes ::= PDSParameter
LocalPostalAttributes:、:= PDSParameter
PDSParameter ::= SET {
printable-string PrintableString
(SIZE(1..ub-pds-parameter-length)) OPTIONAL,
teletex-string TeletexString
(SIZE(1..ub-pds-parameter-length)) OPTIONAL }
PDSParameter:、:= セットします。印刷可能なストリングPrintableString(SIZE(1..ub-pdsパラメタの長さ))OPTIONAL、テレテックスストリングTeletexString(SIZE(1..ub-pdsパラメタの長さ))OPTIONAL
extended-network-address INTEGER ::= 22
拡張ネットワーク・アドレスINTEGER:、:= 22
ExtendedNetworkAddress ::= CHOICE {
e163-4-address SEQUENCE {
number [0] NumericString (SIZE (1..ub-e163-4-number-length)),
sub-address [1] NumericString
(SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL },
psap-address [0] PresentationAddress }
ExtendedNetworkAddress:、:= 選択e163 4アドレスSEQUENCE数[0]NumericString(SIZE(1..ub-e163 4数の長さ))の、そして、サブアドレスの[1]NumericString(SIZE(1..ub-e163の4のサブアドレスの長さ))OPTIONAL、psap-アドレス[0]PresentationAddress
PresentationAddress ::= SEQUENCE {
pSelector [0] EXPLICIT OCTET STRING OPTIONAL,
sSelector [1] EXPLICIT OCTET STRING OPTIONAL,
tSelector [2] EXPLICIT OCTET STRING OPTIONAL,
nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING }
PresentationAddress:、:= 系列八重奏ストリングのpSelectorの明白な八重奏ストリング任意の、そして、[1]の明白な八重奏ストリング任意の、そして、tSelectorの[2]の明白な八重奏ストリング任意のsSelector nAddresses[3]明白なセット[0]サイズ(1..MAX)
terminal-type INTEGER ::= 23
端末のタイプINTEGER:、:= 23
TerminalType ::= INTEGER {
telex (3),
teletex (4),
g3-facsimile (5),
g4-facsimile (6),
ia5-terminal (7),
videotex (8) } (0..ub-integer-options)
TerminalType:、:= INTEGERは(3)、テレテックス(4)、g3-ファクシミリ(5)、g4-ファクシミリ(6)、ia5-端末(7)、ビデオテックス(8)をテレックスで送信します。(0..ub整数オプション)
-- Extension Domain-defined Attributes
-- 拡大のドメインで定義された属性
teletex-domain-defined-attributes INTEGER ::= 6
テレテックスのドメインの定義された属性INTEGER:、:= 6
TeletexDomainDefinedAttributes ::= SEQUENCE SIZE (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute
TeletexDomainDefinedAttributes:、:= TeletexDomainDefinedAttributeの系列サイズ(1..ubドメインは属性を定義しました)
TeletexDomainDefinedAttribute ::= SEQUENCE {
type TeletexString
(SIZE (1..ub-domain-defined-attribute-type-length)),
value TeletexString
TeletexDomainDefinedAttribute:、:= SEQUENCE、値のTeletexString、TeletexString(SIZE(1..ubドメインは属性タイプの長さを定義した))をタイプしてください。
Housley, et. al. Standards Track [Page 81] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[81ページ]。
(SIZE (1..ub-domain-defined-attribute-value-length)) }
(サイズ(1..ubドメインは属性値の長さを定義しました))
-- specifications of Upper Bounds shall be regarded as mandatory -- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter -- Upper Bounds
-- Upper Boundsの仕様が、より上にMTS ParameterのITU-T X.411 Reference DefinitionのAnnex Bから義務的であると見なされるものとする、Bounds
-- Upper Bounds ub-name INTEGER ::= 32768 ub-common-name INTEGER ::= 64 ub-locality-name INTEGER ::= 128 ub-state-name INTEGER ::= 128 ub-organization-name INTEGER ::= 64 ub-organizational-unit-name INTEGER ::= 64 ub-title INTEGER ::= 64 ub-match INTEGER ::= 128
-- 上側のBounds ub-名前INTEGER:、:= 32768 ub-一般名INTEGER:、:= 64 ub場所名のINTEGER:、:= 128 ub州の名のINTEGER:、:= 128 ub組織名のINTEGER:、:= 64 組織的なユニットが命名するub INTEGER:、:= 64 ub-タイトルINTEGER:、:= 64 ub-マッチINTEGER:、:= 128
ub-emailaddress-length INTEGER ::= 128
ub-emailaddress-長さのINTEGER:、:= 128
ub-common-name-length INTEGER ::= 64 ub-country-name-alpha-length INTEGER ::= 2 ub-country-name-numeric-length INTEGER ::= 3 ub-domain-defined-attributes INTEGER ::= 4 ub-domain-defined-attribute-type-length INTEGER ::= 8 ub-domain-defined-attribute-value-length INTEGER ::= 128 ub-domain-name-length INTEGER ::= 16 ub-extension-attributes INTEGER ::= 256 ub-e163-4-number-length INTEGER ::= 15 ub-e163-4-sub-address-length INTEGER ::= 40 ub-generation-qualifier-length INTEGER ::= 3 ub-given-name-length INTEGER ::= 16 ub-initials-length INTEGER ::= 5 ub-integer-options INTEGER ::= 256 ub-numeric-user-id-length INTEGER ::= 32 ub-organization-name-length INTEGER ::= 64 ub-organizational-unit-name-length INTEGER ::= 32 ub-organizational-units INTEGER ::= 4 ub-pds-name-length INTEGER ::= 16 ub-pds-parameter-length INTEGER ::= 30 ub-pds-physical-address-lines INTEGER ::= 6 ub-postal-code-length INTEGER ::= 16 ub-surname-length INTEGER ::= 40 ub-terminal-id-length INTEGER ::= 24 ub-unformatted-address-length INTEGER ::= 180 ub-x121-address-length INTEGER ::= 16
ubの一般的な名前の長さのINTEGER:、:= 64 ub国の名前アルファの長さのINTEGER:、:= 2 ubの国の名義の数値長さのINTEGER:、:= 3 ubドメインが属性を定義しているINTEGER:、:= 4 ubドメインが属性タイプの長さを定義しているINTEGER:、:= 8 ubドメインが属性値の長さを定義しているINTEGER:、:= 128 ubドメイン名前の長さのINTEGER:、:= 16 ub拡大属性INTEGER:、:= 256 ub-e163 4数の長さのINTEGER:、:= 15 ub-e163の4のサブアドレスの長さのINTEGER:、:= 40 ub世代資格を与える人の長さのINTEGER:、:= 3 ubに与えられた名前の長さのINTEGER:、:= 16 ubが長さに頭文字をつけているINTEGER:、:= 5 ub整数オプションINTEGER:、:= 256 ubの数値ユーザイドの長さのINTEGER:、:= 32 ub組織名前の長さのINTEGER:、:= 64 ubの組織的なユニットが長さを命名しているINTEGER:、:= 32 ubの組織的なユニットINTEGER:、:= 4 ub-pds名前の長さのINTEGER:、:= 16 ub-pdsパラメタの長さのINTEGER:、:= 30 ub-pds身体検査がアドレスで立ち並んでいるINTEGER:、:= 6 ubの郵便のコードの長さのINTEGER:、:= 16 ub姓の長さのINTEGER:、:= 40 ubの端末のイドの長さのINTEGER:、:= 24 ub-unformattedアドレスの長さのINTEGER:、:= 180 ub-x121アドレスの長さのINTEGER:、:= 16
-- Note - upper bounds on string types, such as TeletexString, are -- measured in characters. Excepting PrintableString or IA5String, a -- significantly greater number of octets will be required to hold
-- 注意--TeletexStringなどのストリングタイプの上の上限があります--キャラクタでは、測定されます。 PrintableStringかIA5String、aを除きます--かなり大きい数の八重奏が、成立するのに必要でしょう。
Housley, et. al. Standards Track [Page 82] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[82ページ]。
-- such a value. As a minimum, 16 octets, or twice the specified upper -- bound, whichever is the larger, should be allowed for TeletexString. -- For UTF8String or UniversalString at least four times the upper -- bound should be allowed.
-- そのような値。 最小限として、16の八重奏、または指定された覚醒剤の2倍--どれがさらに大きいかならバウンドしているのはTeletexStringのために許されるべきです。 -- UTF8StringかUniversalStringに関しては、上側の少なくとも4倍、バウンドは許容されるべきです。
END
終わり
Housley, et. al. Standards Track [Page 83] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[83ページ]。
A.2 Implicitly Tagged Module, 1988 Syntax
A.2はそれとなくモジュール、1988年の構文にタグ付けをしました。
PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}
PKIX1Implicit88iso(1)の特定された組織(3)のdod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)のイドのpkix1の内在している88(2)
DEFINITIONS IMPLICIT TAGS ::=
定義、内在しているタグ:、:=
BEGIN
始まってください。
-- EXPORTS ALL --
-- すべてを輸出します--
IMPORTS
id-pkix, id-pe, id-qt, id-kp, id-qt-unotice, id-qt-cps,
id-ad, id-ad-ocsp, id-ad-caIssuers,
-- delete following line if "new" types are supported --
BMPString, UniversalString, UTF8String, -- end "new" types
ORAddress, Name, RelativeDistinguishedName,
CertificateSerialNumber,
CertificateList, AlgorithmIdentifier, ub-name,
Attribute, DirectoryString
FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(1)};
IMPORTSイド-pkix、イド-pe、イド-qt、イド-kp、イド-qt-unotice、イド-qt-cps、イド広告、イド広告ocsp、イド広告caIssuers、--「新しい」タイプが支持されるなら--BMPString、UniversalString、UTF8String--「新しい」状態で終わるのはORAddressをタイプします、Name、RelativeDistinguishedName、CertificateSerialNumber、CertificateList、AlgorithmIdentifier、ub-名前、Attribute、DirectoryString FROM PKIX1Explicit88のiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1明白な(1);次の線を削除してください
-- ISO arc for standard certificate and CRL extensions
-- 標準の証明書とCRL拡張子のためのISOアーク
id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29}
イドCe OBJECT IDENTIFIER:、:= 共同iso-ccitt(2) ds(5)29
-- authority key identifier OID and syntax
-- 権威の主要な識別子OIDと構文
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 }
-- authorityCertIssuer and authorityCertSerialNumber shall both
-- be present or both be absent
AuthorityKeyIdentifier:、:= SEQUENCE、keyIdentifier[0]KeyIdentifier OPTIONAL、authorityCertIssuer[1]GeneralNames OPTIONAL、authorityCertSerialNumber[2]CertificateSerialNumber OPTIONAL--authorityCertIssuerとauthorityCertSerialNumberはともにそうするでしょう--、存在しているか、またはともに休みます。
KeyIdentifier ::= OCTET STRING
KeyIdentifier:、:= 八重奏ストリング
-- subject key identifier OID and syntax
-- 対象の主要な識別子OIDと構文
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
イドCe subjectKeyIdentifier、物の識別子:、:= イドCe14
SubjectKeyIdentifier ::= KeyIdentifier
SubjectKeyIdentifier:、:= KeyIdentifier
Housley, et. al. Standards Track [Page 84] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[84ページ]。
-- key usage extension OID and syntax
-- 主要な用法拡大OIDと構文
id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
イドCe keyUsage、物の識別子:、:= イドCe15
KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1),
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5),
cRLSign (6),
encipherOnly (7),
decipherOnly (8) }
KeyUsage:、:= ビット列digitalSignature(0)、nonRepudiation(1)、keyEncipherment(2)、dataEncipherment(3)、keyAgreement(4)、keyCertSign(5)、cRLSign(6)、encipherOnly(7)、decipherOnly(8)
-- private key usage period extension OID and syntax
-- 秘密鍵用法期間の延期OIDと構文
id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 }
イドCe privateKeyUsagePeriod、物の識別子:、:= イドCe16
PrivateKeyUsagePeriod ::= SEQUENCE {
notBefore [0] GeneralizedTime OPTIONAL,
notAfter [1] GeneralizedTime OPTIONAL }
-- either notBefore or notAfter shall be present
PrivateKeyUsagePeriod:、:= SEQUENCE、notBefore[0]GeneralizedTime OPTIONAL、notAfter[1]GeneralizedTime OPTIONAL--、notBeforeかnotAfterのどちらかが存在するでしょう。
-- certificate policies extension OID and syntax
-- 証明書方針拡張子OIDと構文
id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
イドCe certificatePolicies、物の識別子:、:= イドCe32
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
-- Implementations that recognize additional policy qualifiers shall -- augment the following definition for PolicyQualifierId
-- 追加方針資格を与える人がそうすると認めてください実現--PolicyQualifierIdのために以下の定義を増大させてください。
PolicyQualifierId ::=
OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
PolicyQualifierId:、:= 物の識別子(イド-qt-cps| イド-qt-unotice)
-- CPS pointer qualifier
-- CPSポインタ資格を与える人
Housley, et. al. Standards Track [Page 85] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[85ページ]。
CPSuri ::= IA5String
CPSuri:、:= IA5String
-- user notice qualifier
-- ユーザ通知資格を与える人
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 {
visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200)) }
DisplayText:、:= 選択visibleString VisibleString(サイズ(1 .200))、bmpString BMPString(サイズ(1 .200))、utf8String UTF8String(サイズ(1 .200))
-- policy mapping extension OID and syntax
-- 方針マッピング拡張子OIDと構文
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
-- subject alternative name extension OID and syntax
-- 対象の代替名拡大OIDと構文
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] AnotherName,
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]AnotherName、rfc822Name[1]IA5String、dNSName[2]IA5String、x400Address[3]ORAddress、directoryName[4]名、ediPartyName[5]EDIPartyName、uniformResourceIdentifier[6]IA5String、iPAddress[7]八重奏ストリング、registeredID[8]物の識別子
-- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax
-- AnotherNameはOTHER-NAMEを取り替えます:、:= TYPE-IDENTIFIER、--TYPE-IDENTIFIERが88年のASN.1構文で支持されない
AnotherName ::= SEQUENCE {
AnotherName:、:= 系列
Housley, et. al. Standards Track [Page 86] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[86ページ]。
type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id }
タイプイドOBJECT IDENTIFIER、値[0]EXPLICIT ANY DEFINED BYタイプイド
EDIPartyName ::= SEQUENCE {
nameAssigner [0] DirectoryString OPTIONAL,
partyName [1] DirectoryString }
EDIPartyName:、:= 系列任意のnameAssigner[0]DirectoryString partyName[1]DirectoryString
-- issuer alternative name extension OID and syntax
-- 発行人代替名拡大OIDと構文
id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
イドCe issuerAltName、物の識別子:、:= イドCe18
IssuerAltName ::= GeneralNames
IssuerAltName:、:= GeneralNames
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
イドCe subjectDirectoryAttributes、物の識別子:、:= イドCe9
SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
SubjectDirectoryAttributes:、:= 属性の系列サイズ(1..MAX)
-- basic constraints extension OID and syntax
-- 基本的な規制拡大OIDと構文
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)任意の状態でデフォルトとします。
-- name constraints extension OID and syntax
-- 名前規制拡大OIDと構文
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)
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)
-- policy constraints extension OID and syntax
-- 方針規制拡大OIDと構文
id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }
イドCe policyConstraints、物の識別子:、:= イドCe36
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
PolicyConstraints:、:= 系列、requireExplicitPolicy[0]SkipCerts任意です。
Housley, et. al. Standards Track [Page 87] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[87ページ]。
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
inhibitPolicyMapping[1]SkipCerts任意
SkipCerts ::= INTEGER (0..MAX)
SkipCerts:、:= 整数(0..MAX)
-- CRL distribution points extension OID and syntax
-- CRL分配は拡大OIDと構文を示します。
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31}
イドCe cRLDistributionPoints、オブジェクト識別子:、:= イドCe31
CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
CRLDistPointsSyntax:、:= 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
ReasonFlags ::= BIT STRING {
unused (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6) }
ReasonFlags:、:= ビット列未使用の(0)(keyCompromise(1)、cACompromise(2)、affiliationChanged(3))は(4)、cessationOfOperation(5)、certificateHold(6)に取って代わりました。
-- extended key usage extension OID and syntax
-- 拡張主要な用法拡大OIDと構文
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:、:= オブジェクト識別子
-- extended key purpose OIDs
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 }
id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 }
id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 }
id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
-- 敷衍された主要な目的OIDsイド-kp-serverAuth OBJECT IDENTIFIER:、:= イド-kp1、イド-kp-clientAuth OBJECT IDENTIFIER:、:= イド-kp2、イド-kp-codeSigning OBJECT IDENTIFIER:、:= イド-kp3、イド-kp-emailProtection OBJECT IDENTIFIER:、:= イド-kp4、イド-kp-ipsecEndSystem OBJECT IDENTIFIER:、:= イド-kp5、イド-kp-ipsecTunnel OBJECT IDENTIFIER:、:= イド-kp6、イド-kp-ipsecUser OBJECT IDENTIFIER:、:= イド-kp7、イド-kp-timeStamping OBJECT IDENTIFIER:、:= イド-kp8
-- authority info access
-- 権威インフォメーションアクセス
Housley, et. al. Standards Track [Page 88] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[88ページ]。
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
-- CRL number extension OID and syntax
-- CRL数の拡張子OIDと構文
id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
イドCe cRLNumber、オブジェクト識別子:、:= イドCe20
CRLNumber ::= INTEGER (0..MAX)
CRLNumber:、:= 整数(0..MAX)
-- issuing distribution point extension OID and syntax
-- 分配ポイント拡大OIDと構文を発行します。
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 }
IssuingDistributionPoint:、:= 系列distributionPoint[0]DistributionPointName任意です、onlyContainsUserCertsの論理演算子のデフォルトの誤って、onlyContainsCACerts[2]ブールのデフォルト誤って、onlySomeReasons[3]ReasonFlags任意の[1]indirectCRL[4]論理演算子は虚偽でデフォルトとします。
id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
イドCe deltaCRLIndicator、オブジェクト識別子:、:= イドCe27
-- deltaCRLIndicator ::= BaseCRLNumber
-- deltaCRLIndicator:、:= BaseCRLNumber
BaseCRLNumber ::= CRLNumber
BaseCRLNumber:、:= CRLNumber
-- CRL reasons extension OID and syntax
-- CRL理由拡張子OIDと構文
id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }
イドCe cRLReasons、オブジェクト識別子:、:= イドCe21
CRLReason ::= ENUMERATED {
unspecified (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
removeFromCRL (8) }
CRLReason:、:= 列挙されます。removeFromCRL(8)、不特定の(0)(keyCompromise(1)、cACompromise(2)、affiliationChanged(3))は(4)、cessationOfOperation(5)、certificateHold(6)に取って代わりました。
-- certificate issuer CRL entry extension OID and syntax
-- 証明書発行人CRLエントリー拡張子OIDと構文
Housley, et. al. Standards Track [Page 89] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[89ページ]。
id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
イドCe certificateIssuer、オブジェクト識別子:、:= イドCe29
CertificateIssuer ::= GeneralNames
CertificateIssuer:、:= GeneralNames
-- hold instruction extension OID and syntax
-- 指示拡大OIDと構文を保持してください。
id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }
イドCe holdInstructionCode、オブジェクト識別子:、:= イドCe23
HoldInstructionCode ::= OBJECT IDENTIFIER
HoldInstructionCode:、:= オブジェクト識別子
-- ANSI x9 holdinstructions
-- ANSI x9 holdinstructions
-- ANSI x9 arc holdinstruction arc
holdInstruction OBJECT IDENTIFIER ::=
{joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2}
-- ANSI x9アークholdinstructionアークholdInstruction OBJECT IDENTIFIER:、:= 共同iso-itu t(2)は(2) 私たち(840)x9cm(10040)2をメンバーと同じくらい具体化させます。
-- ANSI X9 holdinstructions referenced by this standard
id-holdinstruction-none OBJECT IDENTIFIER ::=
{holdInstruction 1} -- deprecated
id-holdinstruction-callissuer OBJECT IDENTIFIER ::=
{holdInstruction 2}
id-holdinstruction-reject OBJECT IDENTIFIER ::=
{holdInstruction 3}
-- ANSI X9 holdinstructionsがこの規格で参照をつけた、イドholdinstruction、なにも、OBJECT IDENTIFIER:、:= holdInstruction1--推奨しないイド-holdinstruction-callissuer OBJECT IDENTIFIER:、:= holdInstruction2イドholdinstruction廃棄物OBJECT IDENTIFIER:、:= holdInstruction3
-- invalidity date CRL entry extension OID and syntax
-- 無効日付のCRLエントリー拡張子OIDと構文
id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
イドCe invalidityDate、オブジェクト識別子:、:= イドCe24
InvalidityDate ::= GeneralizedTime
InvalidityDate:、:= GeneralizedTime
END
終わり
Housley, et. al. Standards Track [Page 90] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[90ページ]。
Appendix B. 1993 ASN.1 Structures and OIDs
付録B.の1993ASN.1構造とOIDs
B.1 Explicitly Tagged Module, 1993 Syntax
B.1は明らかにモジュール、1993年の構文にタグ付けをしました。
PKIX1Explicit93 {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-93(3)}
PKIX1Explicit93iso(1)の特定された組織(3)のdod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)のイドのpkix1の明白な93(3)
DEFINITIONS EXPLICIT TAGS ::=
定義、明白なタグ:、:=
BEGIN
始まってください。
-- EXPORTS ALL --
-- すべてをエクスポートします--
IMPORTS
authorityKeyIdentifier, subjectKeyIdentifier, keyUsage,
extendedKeyUsage, privateKeyUsagePeriod, certificatePolicies,
policyMappings, subjectAltName, issuerAltName,
basicConstraints, nameConstraints, policyConstraints,
cRLDistributionPoints, subjectDirectoryAttributes,
cRLNumber, reasonCode, instructionCode, invalidityDate,
issuingDistributionPoint, certificateIssuer,
deltaCRLIndicator, authorityInfoAccess, id-ce
FROM PKIX1Implicit93 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-implicit-93(4)} ;
authorityKeyIdentifier、subjectKeyIdentifier、keyUsage、extendedKeyUsage、privateKeyUsagePeriod、certificatePolicies、policyMappings、subjectAltName、issuerAltName、basicConstraints、nameConstraints、policyConstraints、cRLDistributionPoints、subjectDirectoryAttributes、cRLNumberをインポートします; reasonCode、instructionCode、invalidityDate、issuingDistributionPoint、certificateIssuer、deltaCRLIndicator、authorityInfoAccess、イドCeのFROM PKIX1Implicit93のiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ風の(0)イドpkix1内在している93(4)。
--
-- Locally defined OIDs --
-- -- 局所的に、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)
-- PKIX arcs
-- arc for private certificate extensions
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
-- arc for policy qualifier types
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
-- arc for extended key purpose OIDS
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
-- arc for access descriptors
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
-- PKIXアーク--兵卒のためのアークは拡大イド-pe OBJECT IDENTIFIERを証明します:、:= イド-pkix1--方針資格を与える人のためのアークはイド-qt OBJECT IDENTIFIERをタイプします:、:= イド-pkix2--拡張キーのためのアークはOIDSイド-kp OBJECT IDENTIFIERを目標とします:、:= イド-pkix3--、アクセス記述子イド広告OBJECT IDENTIFIERのためのアーク:、:= イド-pkix48
-- policyQualifierIds for Internet policy qualifiers
id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
-- OID for CPS qualifier
-- インターネット方針資格を与える人イド-qt-cps OBJECT IDENTIFIERのためのpolicyQualifierIds:、:= イド-qt1--CPS資格を与える人のためのOID
Housley, et. al. Standards Track [Page 91] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[91ページ]。
id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
-- OID for user notice qualifier
イド-qt-unotice OBJECT IDENTIFIER:、:= イド-qt2--ユーザ通知資格を与える人のためのOID
-- based on excerpts from AuthenticationFramework
-- {joint-iso-ccitt ds(5) modules(1) authenticationFramework(7) 2}
-- AuthenticationFrameworkからの抜粋に基づいています--共同iso-ccitt ds(5)モジュール(1)authenticationFramework(7)2
-- Public Key Certificate --
-- 公開鍵証明書--
Certificate ::= SIGNED { SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL,
---if present, version shall be v2 or v3--
subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL,
---if present, version shall be v2 or v3--
extensions [3] Extensions OPTIONAL
--if present, version shall be v3--} }
以下を証明してください:= 署名されます。SEQUENCE、バージョン[0] ----プレゼント、バージョンはv2になるだろうか、そして、v3--拡大[3]拡大OPTIONAL--バージョンDEFAULT v1、serialNumber CertificateSerialNumber、署名AlgorithmIdentifier、発行人Name、正当性Validity、対象のName、subjectPublicKeyInfo SubjectPublicKeyInfo、issuerUniqueIdentifier[1]IMPLICIT UniqueIdentifier OPTIONAL、--プレゼント、バージョンはv2になるだろうか、そして、v3--subjectUniqueIdentifier[2]IMPLICIT UniqueIdentifier OPTIONAL、プレゼント、バージョンがそうするなら、v3になってください--
UniqueIdentifier ::= BIT STRING
UniqueIdentifier:、:= ビット列
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
SubjectPublicKeyInfo ::= SEQUENCE{
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING}
SubjectPublicKeyInfo:、:= 系列アルゴリズムAlgorithmIdentifier、subjectPublicKey BIT STRING
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
拡大:、:= 拡大の系列サイズ(1..MAX)
Extension ::= SEQUENCE {
extnId EXTENSION.&id ({ExtensionSet}),
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING }
-- contains a DER encoding of a value of type
拡大:、:= SEQUENCE、extnId EXTENSIONイド(ExtensionSet)、重要なBOOLEAN DEFAULT FALSE、extnValue OCTET STRING--、タイプの価値をコード化するDERを含んでいます。
Housley, et. al. Standards Track [Page 92] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[92ページ]。
-- &ExtnType for the
-- extension object identified by extnId --
-- ExtnType、--extnIdによって特定された拡大オブジェクト--
-- The following information object set is defined to constrain the -- set of legal certificate extensions.
-- 以下の情報オブジェクトセットが抑制するために定義される、--法的な証明書拡張子のセット。
ExtensionSet EXTENSION ::= { authorityKeyIdentifier |
subjectKeyIdentifier |
keyUsage |
extendedKeyUsage |
privateKeyUsagePeriod |
certificatePolicies |
policyMappings |
subjectAltName |
issuerAltName |
basicConstraints |
nameConstraints |
policyConstraints |
cRLDistributionPoints |
subjectDirectoryAttributes |
authorityInfoAccess }
ExtensionSet拡張子:、:= authorityKeyIdentifier|subjectKeyIdentifier|keyUsage|extendedKeyUsage|privateKeyUsagePeriod|certificatePolicies|policyMappings|subjectAltName|issuerAltName|basicConstraints|nameConstraints|policyConstraints|cRLDistributionPoints|subjectDirectoryAttributes|authorityInfoAccess
EXTENSION ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&ExtnType }
WITH SYNTAX {
SYNTAX &ExtnType
IDENTIFIED BY &id }
拡大:、:= クラス、イドオブジェクト識別子ユニークである、ExtnType、構文構文、特定されたExtnType、およびイド
-- Certificate Revocation List --
-- 取消しリストを証明してください--
CertificateList ::= SIGNED { SEQUENCE {
version Version OPTIONAL, -- if present, shall be v2
signature AlgorithmIdentifier,
issuer Name,
thisUpdate Time,
nextUpdate Time OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate Time,
crlEntryExtensions EntryExtensions OPTIONAL } OPTIONAL,
crlExtensions [0] CRLExtensions OPTIONAL }}
CertificateList:、:= 署名されます。SEQUENCE、バージョンバージョンOPTIONAL--、v2が署名AlgorithmIdentifier、発行人NameであるつもりであったならuserCertificate CertificateSerialNumber、revocationDate Time、crlEntryExtensions EntryExtensions OPTIONALをthisUpdate Time、nextUpdate Time OPTIONAL、revokedCertificates SEQUENCE OF SEQUENCEに寄贈してください、OPTIONAL、crlExtensions[0]CRLExtensions OPTIONAL
CRLExtensions ::= SEQUENCE SIZE (1..MAX) OF CRLExtension
CRLExtensions:、:= CRLExtensionの系列サイズ(1..MAX)
CRLExtension ::= SEQUENCE {
extnId EXTENSION.&id ({CRLExtensionSet}),
critical BOOLEAN DEFAULT FALSE,
CRLExtension:、:= SEQUENCE、extnId EXTENSIONイド(CRLExtensionSet)、重要なBOOLEAN DEFAULT FALSE
Housley, et. al. Standards Track [Page 93] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[93ページ]。
extnValue OCTET STRING }
-- contains a DER encoding of a value of type
-- &ExtnType for the
-- extension object identified by extnId --
extnValue八重奏ストリング -- タイプの価値をコード化するDER、およびExtnTypeを含んでいる、--extnIdによって特定された拡大オブジェクト--
-- The following information object set is defined to constrain the -- set of legal CRL extensions.
-- 以下の情報オブジェクトセットが抑制するために定義される、--法的なCRL拡張子のセット。
CRLExtensionSet EXTENSION ::= { authorityKeyIdentifier |
issuerAltName |
cRLNumber |
deltaCRLIndicator |
issuingDistributionPoint }
CRLExtensionSet拡張子:、:= authorityKeyIdentifier|issuerAltName|cRLNumber|deltaCRLIndicator|issuingDistributionPoint
-- EXTENSION defined above for certificates
-- 証明書のために上で定義されたEXTENSION
EntryExtensions ::= SEQUENCE SIZE (1..MAX) OF EntryExtension
EntryExtensions:、:= EntryExtensionの系列サイズ(1..MAX)
EntryExtension ::= SEQUENCE {
extnId EXTENSION.&id ({EntryExtensionSet}),
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING }
-- contains a DER encoding of a value of type
-- &ExtnType for the
-- extension object identified by extnId --
EntryExtension:、:= SEQUENCE、extnId EXTENSIONイド(EntryExtensionSet)、重要なBOOLEAN DEFAULT FALSE、extnValue OCTET STRING--タイプの価値をコード化するDERを含んでいます--、ExtnType、--extnIdによって特定された拡大オブジェクト--
-- The following information object set is defined to constrain the -- set of legal CRL entry extensions.
-- 以下の情報オブジェクトセットが抑制するために定義される、--法的なCRLエントリー拡張子のセット。
EntryExtensionSet EXTENSION ::= { reasonCode |
instructionCode |
invalidityDate |
certificateIssuer }
EntryExtensionSet拡張子:、:= reasonCode|instructionCode|invalidityDate| certificateIssuer
-- information object classes used in the defintion --
-- of certificates and CRLs --
-- defintionで使用される情報オブジェクトのクラス----証明書とCRLsについて--
-- Parameterized Type SIGNED --
-- Parameterizedタイプは署名しました--
SIGNED { ToBeSigned } ::= SEQUENCE {
toBeSigned ToBeSigned,
algorithm AlgorithmIdentifier,
signature BIT STRING
}
署名しているToBeSigned:、:= 系列toBeSigned ToBeSigned、アルゴリズムAlgorithmIdentifier、署名BIT STRING
-- Definition of AlgorithmIdentifier -- ISO definition was: --
-- AlgorithmIdentifierの定義--ISO定義は以下の通りでした。 --
Housley, et. al. Standards Track [Page 94] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[94ページ]。
-- AlgorithmIdentifier ::= SEQUENCE {
-- algorithm ALGORITHM.&id({SupportedAlgorithms}),
-- parameters ALGORITHM.&Type({SupportedAlgorithms}
-- { @algorithm}) OPTIONAL }
-- Definition of ALGORITHM
-- ALGORITHM ::= TYPE-IDENTIFIER
-- AlgorithmIdentifier:、:= SEQUENCE、--アルゴリズムALGORITHMイド(SupportedAlgorithms)--パラメタALGORITHM Type(SupportedAlgorithms--@algorithm)OPTIONAL--ALGORITHMの定義--ALGORITHM:、:= タイプ識別子
-- The following PKIX definition replaces the X.509 definition --
-- 以下のPKIX定義はX.509定義に取って代わります--
AlgorithmIdentifier ::= SEQUENCE {
algorithm ALGORITHM-ID.&id({SupportedAlgorithms}),
parameters ALGORITHM-ID.&Type({SupportedAlgorithms}
{ @algorithm}) OPTIONAL }
AlgorithmIdentifier:、:= 系列パラメタALGORITHM-IDアルゴリズムALGORITHM-IDイド(SupportedAlgorithms)、Type、(SupportedAlgorithms、@algorithm) OPTIONAL
-- Definition of ALGORITHM-ID
-- ALGORITHM IDの定義
ALGORITHM-ID ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL
}
WITH SYNTAX { OID &id [PARMS &Type] }
ALGORITHM ID:、:= 属してください、イドが識別子ユニークであって、タイプ任意の状態で反対する、構文OIDとイド[PARMSとタイプ]
-- The definition of SupportedAlgorithms may be modified as this -- document does not specify a mandatory algorithm set. In addition, -- the set is specified as extensible, since additional algorithms -- may be supported
-- SupportedAlgorithmsの定義はこれとして変更されるかもしれません--ドキュメントは義務的なアルゴリズムセットを指定しません。 さらに、セットは広げることができると追加アルゴリズム--サポートされるかもしれなくて以来指定されます。
SupportedAlgorithms ALGORITHM-ID ::= { ..., -- extensible
rsaPublicKey |
rsaSHA-1 |
rsaMD5 |
rsaMD2 |
dssPublicKey |
dsaSHA-1 |
dhPublicKey }
SupportedAlgorithms ALGORITHM ID:、:= …--広げることができるrsaPublicKey| rsaSHA-1|rsaMD5|rsaMD2|dssPublicKey|dsaSHA-1|、dhPublicKey
-- OIDs and parameter structures for ALGORITHM-IDs used -- in this specification
-- この仕様で中古のALGORITHM-IDのためのOIDsとパラメタ構造
rsaPublicKey ALGORITHM-ID ::= { OID rsaEncryption PARMS NULL }
rsaPublicKey ALGORITHM ID:、:= OID rsaEncryption PARMSヌル
rsaSHA-1 ALGORITHM-ID ::= { OID sha1WithRSAEncryption PARMS NULL }
rsaSHA-1ALGORITHM ID:、:= OID sha1WithRSAEncryption PARMSヌル
rsaMD5 ALGORITHM-ID ::= { OID md5WithRSAEncryption PARMS NULL }
rsaMD5ALGORITHM ID:、:= OID md5WithRSAEncryption PARMSヌル
rsaMD2 ALGORITHM-ID ::= { OID md2WithRSAEncryption PARMS NULL }
rsaMD2ALGORITHM ID:、:= OID md2WithRSAEncryption PARMSヌル
Housley, et. al. Standards Track [Page 95] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[95ページ]。
dssPublicKey ALGORITHM-ID ::= { OID id-dsa PARMS Dss-Parms }
dssPublicKey ALGORITHM ID:、:= OIDイド-dsa PARMS Dss-Parms
dsaSHA-1 ALGORITHM-ID ::= { OID id-dsa-with-sha1 }
dsaSHA-1ALGORITHM ID:、:= sha1とOIDイドdsa
dhPublicKey ALGORITHM-ID ::= {OID dhpublicnumber PARMS DomainParameters}
dhPublicKey ALGORITHM ID:、:= OID dhpublicnumber PARMS DomainParameters
-- algorithm identifiers and parameter structures
-- アルゴリズム識別子とパラメタ構造
pkcs-1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }
pkcs-1 OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1)1をメンバーと同じくらい具体化させます。
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
rsaEncryptionオブジェクト識別子:、:= pkcs-1 1
md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 }
md2WithRSAEncryptionオブジェクト識別子:、:= pkcs-1 2
md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 }
md5WithRSAEncryptionオブジェクト識別子:、:= pkcs-1 4
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 }
sha1WithRSAEncryptionオブジェクト識別子:、:= pkcs-1 5
id-dsa-with-sha1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 }
sha1 OBJECT IDENTIFIERとイドdsa:、:= iso(1)は(2) 私たち(840)x9-57(10040)x9algorithm(4)3をメンバーと同じくらい具体化させます。
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
以下をDss-Sig評価してください:= 系列r整数、s整数
dhpublicnumber OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }
dhpublicnumber OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)ansi-x942(10046)No.タイプ(2)1をメンバーと同じくらい具体化させます。
DomainParameters ::= SEQUENCE {
p INTEGER, -- odd prime, p=jq +1
g INTEGER, -- generator, g
q INTEGER, -- factor of p-1
j INTEGER OPTIONAL, -- subgroup factor, j>= 2
validationParms ValidationParms OPTIONAL }
DomainParameters:、:= 系列p INTEGER--奇素数、p=jqの+1gのINTEGER--ジェネレータ、g q INTEGER--p-1j INTEGER OPTIONALの要素--サブグループ要素、j>は2validationParms ValidationParms OPTIONALと等しいです。
ValidationParms ::= SEQUENCE {
seed BIT STRING,
pgenCounter INTEGER }
ValidationParms:、:= 系列種子BIT STRING、pgenCounter INTEGER
id-dsa OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }
イド-dsa OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)x9-57(10040) x9algorithm(4)1をメンバーと同じくらい具体化させます。
Dss-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER }
Dss-Parms:、:= 系列p INTEGER、q INTEGER、g INTEGER
Housley, et. al. Standards Track [Page 96] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[96ページ]。
-- The ASN.1 in this section supports the Name type
-- and the directoryAttribute extension
-- このセクションのASN.1は、Nameがタイプと、directoryAttribute拡張子であるとサポートします。
-- attribute data types --
-- データ型を結果と考えてください--
Attribute ::= SEQUENCE {
type ATTRIBUTE.&id ({SupportedAttributes}),
values SET SIZE (1 .. MAX) OF ATTRIBUTE.&Type
({SupportedAttributes}{@type})}
以下を結果と考えてください:= 系列値のSET SIZE(1 マックス)OF ATTRIBUTE ATTRIBUTEイド(SupportedAttributes)、Typeをタイプしてください、(SupportedAttributes、@type)
AttributeTypeAndValue ::= SEQUENCE {
type ATTRIBUTE.&id ({SupportedAttributes}),
value ATTRIBUTE.&Type ({SupportedAttributes}{@type})}
AttributeTypeAndValue:、:= 系列ATTRIBUTE ATTRIBUTEイド(SupportedAttributes)、値のTypeをタイプしてください、(SupportedAttributes、@type)
-- naming data types --
-- データ型を命名します--
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つの最大)を設定してください。
ID ::= OBJECT IDENTIFIER
ID:、:= オブジェクト識別子
-- ATTRIBUTE information object class specification -- Note: This has been greatly simplified for PKIX !!
-- ATTRIBUTE情報オブジェクトクラス仕様--以下に注意してください。 これはPKIXのために大いに簡素化されました!
ATTRIBUTE ::= CLASS {
&Type,
&id OBJECT IDENTIFIER UNIQUE }
WITH SYNTAX {
WITH SYNTAX &Type ID &id }
以下を結果と考えてください:= クラスでタイプ、およびイドオブジェクト識別子ユニークである、構文構文とタイプIDとイド
-- 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.
-- 以下の情報オブジェクトセットの定義がそうであるという提案された命名属性は、地方の必要条件を満たすために増大しました。 削除して、それに注意してください--セットのメンバーは防ぐかもしれません。実装を従わせて、相互運用性を防ぎます。
SupportedAttributes ATTRIBUTE ::= {
name | commonName | surname | givenName | initials |
generationQualifier | dnQualifier | countryName |
localityName | stateOrProvinceName | organizationName |
organizationalUnitName | title | pkcs9email }
SupportedAttributesは以下を結果と考えます:= 名前|commonName|姓|givenName|イニシャル|generationQualifier|dnQualifier|countryName|localityName|stateOrProvinceName|organizationName| organizationalUnitName|タイトル|pkcs9email
name ATTRIBUTE ::= {
ATTRIBUTEを命名してください:、:= {
Housley, et. al. Standards Track [Page 97] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[97ページ]。
WITH SYNTAX DirectoryString { ub-name }
ID id-at-name }
名前におけるWITH SYNTAX DirectoryString ub-名前IDイド
commonName ATTRIBUTE ::= {
WITH SYNTAX DirectoryString {ub-common-name}
ID id-at-commonName }
commonNameは以下を結果と考えます:= commonNameの構文DirectoryString ub-一般名IDイド
surname ATTRIBUTE ::= {
WITH SYNTAX DirectoryString {ub-name}
ID id-at-surname }
姓のATTRIBUTE:、:= 姓におけるWITH SYNTAX DirectoryString ub-名前IDイド
givenName ATTRIBUTE ::= {
WITH SYNTAX DirectoryString {ub-name}
ID id-at-givenName }
givenNameは以下を結果と考えます:= 構文DirectoryStringと共にgivenNameのイドとIDをub命名してください。
initials ATTRIBUTE ::= {
WITH SYNTAX DirectoryString {ub-name}
ID id-at-initials }
イニシャルATTRIBUTE:、:= イニシャルにおけるWITH SYNTAX DirectoryString ub-名前IDイド
generationQualifier ATTRIBUTE ::= {
WITH SYNTAX DirectoryString {ub-name}
ID id-at-generationQualifier}
generationQualifierは以下を結果と考えます:= 構文DirectoryStringと共にgenerationQualifierのイドとIDをub命名してください。
dnQualifier ATTRIBUTE ::= {
WITH SYNTAX PrintableString
ID id-at-dnQualifier }
dnQualifierは以下を結果と考えます:= dnQualifierの構文PrintableString IDイド
countryName ATTRIBUTE ::= {
WITH SYNTAX PrintableString (SIZE (2))
-- IS 3166 codes only
ID id-at-countryName }
countryNameは以下を結果と考えます:= WITH SYNTAX PrintableString、(SIZE(2))、--唯一の3166のコードIDがcountryNameのイドである
localityName ATTRIBUTE ::= {
WITH SYNTAX DirectoryString {ub-locality-name}
ID id-at-localityName }
localityNameは以下を結果と考えます:= localityNameの構文DirectoryString ub場所名のIDイド
stateOrProvinceName ATTRIBUTE ::= {
WITH SYNTAX DirectoryString {ub-state-name}
ID id-at-stateOrProvinceName }
stateOrProvinceNameは以下を結果と考えます:= stateOrProvinceNameの構文DirectoryString ub州の名のIDイド
organizationName ATTRIBUTE ::= {
WITH SYNTAX DirectoryString {ub-organization-name}
ID id-at-organizationName }
organizationNameは以下を結果と考えます:= organizationNameの構文DirectoryString ub組織名のIDイド
organizationalUnitName ATTRIBUTE ::= {
WITH SYNTAX DirectoryString {ub-organizational-unit-name}
ID id-at-organizationalUnitName }
organizationalUnitNameは以下を結果と考えます:= organizationalUnitNameの構文DirectoryString組織的なユニットが命名するub IDイド
Housley, et. al. Standards Track [Page 98] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[98ページ]。
title ATTRIBUTE ::= {
WITH SYNTAX DirectoryString {ub-title}
ID id-at-title }
タイトルATTRIBUTE:、:= タイトルにおけるWITH SYNTAX DirectoryString ub-タイトルIDイド
-- Legacy attributes
-- レガシー属性
pkcs9email ATTRIBUTE ::= {
WITH SYNTAX PHGString,
ID emailAddress }
pkcs9email ATTRIBUTE:、:= 構文PHGString、ID emailAddress
PHGString ::= IA5String (SIZE(1..ub-emailaddress-length))
PHGString:、:= IA5String(サイズ(1..ub-emailaddress-長さ))
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をメンバーと同じくらい具体化させます。
emailAddress OBJECT IDENTIFIER ::= { pkcs-9 1 }
emailAddressオブジェクト識別子:、:= pkcs-9 1
-- object identifiers for Name type and directory attribute support
-- Nameタイプとディレクトリ属性サポートのためのオブジェクト識別子
-- Object identifier assignments --
-- オブジェクト識別子課題--
id-at OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 4}
イド、-、OBJECT IDENTIFIER:、:= 共同iso-ccitt(2) ds(5)4
-- Attributes --
-- 属性--
id-at-commonName OBJECT IDENTIFIER ::= {id-at 3}
id-at-surname OBJECT IDENTIFIER ::= {id-at 4}
id-at-countryName OBJECT IDENTIFIER ::= {id-at 6}
id-at-localityName OBJECT IDENTIFIER ::= {id-at 7}
id-at-stateOrProvinceName OBJECT IDENTIFIER ::= {id-at 8}
id-at-organizationName OBJECT IDENTIFIER ::= {id-at 10}
id-at-organizationalUnitName OBJECT IDENTIFIER ::= {id-at 11}
id-at-title OBJECT IDENTIFIER ::= {id-at 12}
id-at-name OBJECT IDENTIFIER ::= {id-at 41}
id-at-givenName OBJECT IDENTIFIER ::= {id-at 42}
id-at-initials OBJECT IDENTIFIER ::= {id-at 43}
id-at-generationQualifier OBJECT IDENTIFIER ::= {id-at 44}
id-at-dnQualifier OBJECT IDENTIFIER ::= {id-at 46}
commonNameのイドオブジェクト識別子:、:= イド、-、3、姓におけるイドOBJECT IDENTIFIER:、:= イド、-、4、countryNameのイドオブジェクト識別子:、:= イド、-、6、localityNameのイドオブジェクト識別子:、:= イド、-、7、stateOrProvinceNameのイドオブジェクト識別子:、:= イド、-、8、organizationNameのイドオブジェクト識別子:、:= イド、-、10、organizationalUnitNameのイドオブジェクト識別子:、:= イド、-、11、タイトルにおけるイドOBJECT IDENTIFIER:、:= イド、-、12、名前におけるイドOBJECT IDENTIFIER:、:= イド、-、41、givenNameのイドオブジェクト識別子:、:= イド、-、42、イニシャルにおけるイドOBJECT IDENTIFIER:、:= イド、-、43、generationQualifierのイドオブジェクト識別子:、:= イド、-、44、dnQualifierのイドオブジェクト識別子:、:= イド、-、46
-- Directory string type, used extensively in Name types --
-- Nameタイプで手広く使用されるディレクトリストリングタイプ--
DirectoryString { INTEGER:maxSize } ::= CHOICE {
teletexString TeletexString (SIZE (1..maxSize)),
printableString PrintableString (SIZE (1..maxSize)),
universalString UniversalString (SIZE (1..maxSize)),
bmpString BMPString (SIZE(1..maxSize)),
utf8String UTF8String (SIZE(1..maxSize))
}
DirectoryString、整数: maxSize:、:= 選択teletexString TeletexString(サイズ(1..maxSize))、printableString PrintableString(サイズ(1..maxSize))、universalString UniversalString(サイズ(1..maxSize))、bmpString BMPString(サイズ(1..maxSize))、utf8String UTF8String(サイズ(1..maxSize))
Housley, et. al. Standards Track [Page 99] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[99ページ]。
-- End of ASN.1 for Name type and directory attribute support --
-- Nameタイプとディレクトリ属性サポートのためのASN.1の端--
-- The ASN.1 in this section supports X.400 style names --
-- for implementations that use the x400Address component --
-- of GeneralName. --
-- このセクションのASN.1は、X.400スタイルがGeneralNameという名前であると----実装に、それがx400Addressの部品を使用する--サポートします。 --
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を見てください。
-- The OR-address is semantically absent from the OR-name if the -- built-in-standard-attribute sequence is empty and the -- built-in-domain-defined-attributes and extension-attributes are -- both omitted.
-- そして、OR-アドレスがOR-名前から意味的に欠けている、--、内蔵の標準の属性系列が空である--拡大属性はそうです--内蔵のドメインは属性を定義して、ともに省略されます。
-- Built-in Standard Attributes
-- 内蔵の標準の属性
BuiltInStandardAttributes ::= SEQUENCE {
country-name CountryName OPTIONAL,
administration-domain-name AdministrationDomainName OPTIONAL,
network-address [0] NetworkAddress OPTIONAL,
-- see also extended-network-address
terminal-identifier [1] TerminalIdentifier OPTIONAL,
private-domain-name [2] PrivateDomainName OPTIONAL,
organization-name [3] OrganizationName OPTIONAL,
-- see also teletex-organization-name
numeric-user-identifier [4] NumericUserIdentifier OPTIONAL,
personal-name [5] PersonalName OPTIONAL,
-- see also teletex-personal-name
organizational-unit-names [6] OrganizationalUnitNames OPTIONAL
-- see also teletex-organizational-unit-names -- }
BuiltInStandardAttributes:、:= 系列{ 国名のCountryName OPTIONAL、管理ドメイン名AdministrationDomainName OPTIONAL、ネットワーク・アドレス0NetworkAddress OPTIONAL--また、端末の識別子1拡張ネットワーク・アドレスTerminalIdentifier OPTIONAL、個人的なドメイン名2PrivateDomainName OPTIONAL、組織名の3OrganizationName OPTIONALを見てください; また、テレテックス組織名の数値ユーザ識別子4NumericUserIdentifier OPTIONALを見てください、個人名5PersonalName OPTIONAL--また、テレテックス個人名組織的なユニット名の6OrganizationalUnitNames 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--また、拡張ネットワーク・アドレスを見てください。
Housley, et. al. Standards Track [Page 100] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[100ページ]。
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の数値ユーザイドの長さ))
PersonalName ::= SET {
surname [0] PrintableString (SIZE (1..ub-surname-length)),
given-name [1] PrintableString
(SIZE (1..ub-given-name-length)) OPTIONAL,
initials [2] PrintableString
(SIZE (1..ub-initials-length)) OPTIONAL,
generation-qualifier [3] PrintableString
(SIZE (1..ub-generation-qualifier-length)) OPTIONAL}
-- see also teletex-personal-name
PersonalName:、:= SET、姓[0]PrintableString(SIZE(1..ub姓の長さ))(名[1]PrintableString(SIZE(1..ub当然のことの名前の長さ))OPTIONAL)は[2] PrintableString(SIZE(1..ubは長さに頭文字をつける))OPTIONALに頭文字をつけます、世代資格を与える人[3]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
ExtensionAttribute ::= SEQUENCE {
ExtensionAttributes:、:= ExtensionAttribute ExtensionAttributeのサイズ(1..ub拡大属性)を設定してください:、:= 系列
Housley, et. al. Standards Track [Page 101] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[101ページ]。
extension-attribute-type [0] EXTENSION-ATTRIBUTE.&id
({ExtensionAttributeTable}),
extension-attribute-value [1] EXTENSION-ATTRIBUTE.&Type
({ExtensionAttributeTable} {@extension-attribute-type}) }
[1] EXTENSION-ATTRIBUTE拡大属性タイプ[0] EXTENSION-ATTRIBUTEイド(ExtensionAttributeTable)、拡大属性値Type、(ExtensionAttributeTable、@extension属性タイプ)
EXTENSION-ATTRIBUTE ::= CLASS {
&id INTEGER (0..ub-extension-attributes) UNIQUE,
&Type }
WITH SYNTAX {&Type IDENTIFIED BY &id}
以下を拡大して結果と考えてください:= クラス、イド整数(0..ub拡大属性)ユニークである、タイプしてください、構文特定されたタイプとイド
ExtensionAttributeTable EXTENSION-ATTRIBUTE ::= {
common-name |
teletex-common-name |
teletex-organization-name |
teletex-personal-name |
teletex-organizational-unit-names |
teletex-domain-defined-attributes |
pds-name |
physical-delivery-country-name |
postal-code |
physical-delivery-office-name |
physical-delivery-office-number |
extension-OR-address-components |
physical-delivery-personal-name |
physical-delivery-organization-name |
extension-physical-delivery-address-components |
unformatted-postal-address |
street-address |
post-office-box-address |
poste-restante-address |
unique-postal-name |
local-postal-attributes |
extended-network-address |
terminal-type }
ExtensionAttributeTableは以下を拡大して結果と考えます:= { 一般名| テレテックス一般名| テレテックス組織名| テレテックス個人名| テレテックスの組織的なユニット名| テレテックスのドメインの定義された属性| pds-名前| 物理的な配送国の名| 郵便番号| 物理的な配送オフィス名| 物理的な配送局番号| 拡大ORアドレス構成要素; | 物理的な配送個人名| 組織が命名する物理的な配送| 拡大の物理的な配送アドレス構成要素| 非フォーマットされた郵便の宛先| 住所| 郵便の箱のアドレス| poste-restante-アドレス| ユニークな郵便の名前| 地方の郵便の属性| 拡張ネットワーク・アドレス| 端末のタイプ; }
-- Extension Standard Attributes
-- 拡大の標準の属性
common-name EXTENSION-ATTRIBUTE ::= {CommonName IDENTIFIED BY 1}
一般名EXTENSION-ATTRIBUTE:、:= 1時までに特定されたCommonName
CommonName ::= PrintableString (SIZE (1..ub-common-name-length))
CommonName:、:= PrintableString(サイズ(1..ubの一般的な名前の長さ))
teletex-common-name EXTENSION-ATTRIBUTE ::=
{TeletexCommonName IDENTIFIED BY 2}
テレテックス一般名EXTENSION-ATTRIBUTE:、:= 2時までに特定されたTeletexCommonName
TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length))
TeletexCommonName:、:= TeletexString(サイズ(1..ubの一般的な名前の長さ))
teletex-organization-name EXTENSION-ATTRIBUTE ::=
{TeletexOrganizationName IDENTIFIED BY 3}
テレテックス組織名のEXTENSION-ATTRIBUTE:、:= 3時までに特定されたTeletexOrganizationName
Housley, et. al. Standards Track [Page 102] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[102ページ]。
TeletexOrganizationName ::=
TeletexString (SIZE (1..ub-organization-name-length))
TeletexOrganizationName:、:= TeletexString(サイズ(1..ub組織名前の長さ))
teletex-personal-name EXTENSION-ATTRIBUTE ::=
{TeletexPersonalName IDENTIFIED BY 4}
テレテックス個人名EXTENSION-ATTRIBUTE:、:= 4時までに特定されたTeletexPersonalName
TeletexPersonalName ::= SET {
surname [0] TeletexString (SIZE (1..ub-surname-length)),
given-name [1] TeletexString
(SIZE (1..ub-given-name-length)) OPTIONAL,
initials [2] TeletexString (SIZE (1..ub-initials-length)) OPTIONAL,
generation-qualifier [3] TeletexString (SIZE
(1..ub-generation-qualifier-length)) OPTIONAL }
TeletexPersonalName:、:= セットします。姓[0]TeletexString(SIZE(1..ub姓の長さ))(名[1]TeletexString(SIZE(名前の長さが与えられた1..ub))OPTIONAL)は[2] TeletexString(SIZE(1..ubは長さに頭文字をつける))OPTIONALに頭文字をつけます、世代資格を与える人[3]TeletexString(SIZE(1..ub世代資格を与える人の長さ))OPTIONAL
teletex-organizational-unit-names EXTENSION-ATTRIBUTE ::=
{TeletexOrganizationalUnitNames IDENTIFIED BY 5}
テレテックスの組織的なユニット名のEXTENSION-ATTRIBUTE:、:= 5時までに特定されたTeletexOrganizationalUnitNames
TeletexOrganizationalUnitNames ::= SEQUENCE SIZE
(1..ub-organizational-units) OF TeletexOrganizationalUnitName
TeletexOrganizationalUnitNames:、:= (1..ubの組織的なユニット)の系列サイズTeletexOrganizationalUnitName
TeletexOrganizationalUnitName ::= TeletexString
(SIZE (1..ub-organizational-unit-name-length))
TeletexOrganizationalUnitName:、:= TeletexString(サイズ(1..ubの組織的なユニットは長さを命名します))
pds-name EXTENSION-ATTRIBUTE ::= {PDSName IDENTIFIED BY 7}
pds-名前EXTENSION-ATTRIBUTE:、:= 7時までに特定されたPDSName
PDSName ::= PrintableString (SIZE (1..ub-pds-name-length))
PDSName:、:= PrintableString(サイズ(1..ub-pds名前の長さ))
physical-delivery-country-name EXTENSION-ATTRIBUTE ::=
{PhysicalDeliveryCountryName IDENTIFIED BY 8}
物理的な配送国の名のEXTENSION-ATTRIBUTE:、:= 8時までに特定されたPhysicalDeliveryCountryName
PhysicalDeliveryCountryName ::= CHOICE {
x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)),
iso-3166-alpha2-code PrintableString
(SIZE (ub-country-name-alpha-length)) }
PhysicalDeliveryCountryName:、:= 選択x121-dcc-コードNumericString(SIZE(ubの国の名前の数値長さ))、iso-3166-alpha2-コードPrintableString(SIZE(ub国の名前アルファの長さ))
postal-code EXTENSION-ATTRIBUTE ::= {PostalCode IDENTIFIED BY 9}
郵便番号EXTENSION-ATTRIBUTE:、:= 9時までに特定されたPostalCode
PostalCode ::= CHOICE {
numeric-code NumericString (SIZE (1..ub-postal-code-length)),
printable-code PrintableString (SIZE (1..ub-postal-code-length)) }
PostalCode:、:= 選択数字コードNumericString(SIZE(1..ubの郵便のコードの長さ))、印刷可能なコードPrintableString(SIZE(1..ubの郵便のコードの長さ))
physical-delivery-office-name EXTENSION-ATTRIBUTE ::=
{PhysicalDeliveryOfficeName IDENTIFIED BY 10}
物理的な配送オフィス名のEXTENSION-ATTRIBUTE:、:= 10時までに特定されたPhysicalDeliveryOfficeName
PhysicalDeliveryOfficeName ::= PDSParameter
PhysicalDeliveryOfficeName:、:= PDSParameter
physical-delivery-office-number EXTENSION-ATTRIBUTE ::=
{PhysicalDeliveryOfficeNumber IDENTIFIED BY 11}
物理的な配送局番号EXTENSION-ATTRIBUTE:、:= 11時までに特定されたPhysicalDeliveryOfficeNumber
Housley, et. al. Standards Track [Page 103] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[103ページ]。
PhysicalDeliveryOfficeNumber ::= PDSParameter
PhysicalDeliveryOfficeNumber:、:= PDSParameter
extension-OR-address-components EXTENSION-ATTRIBUTE ::=
{ExtensionORAddressComponents IDENTIFIED BY 12}
拡大かアドレス構成要素が以下を拡大して結果と考えます:= 12時までに特定されたExtensionORAddressComponents
ExtensionORAddressComponents ::= PDSParameter
ExtensionORAddressComponents:、:= PDSParameter
physical-delivery-personal-name EXTENSION-ATTRIBUTE ::=
{PhysicalDeliveryPersonalName IDENTIFIED BY 13}
物理的な配送個人名EXTENSION-ATTRIBUTE:、:= 13時までに特定されたPhysicalDeliveryPersonalName
PhysicalDeliveryPersonalName ::= PDSParameter
PhysicalDeliveryPersonalName:、:= PDSParameter
physical-delivery-organization-name EXTENSION-ATTRIBUTE ::=
{PhysicalDeliveryOrganizationName IDENTIFIED BY 14}
物理的な配送組織名のEXTENSION-ATTRIBUTE:、:= 14時までに特定されたPhysicalDeliveryOrganizationName
PhysicalDeliveryOrganizationName ::= PDSParameter
PhysicalDeliveryOrganizationName:、:= PDSParameter
extension-physical-delivery-address-components EXTENSION-ATTRIBUTE ::=
{ExtensionPhysicalDeliveryAddressComponents IDENTIFIED BY 15}
拡大身体検査配送アドレス構成要素EXTENSION-ATTRIBUTE:、:= 15時までに特定されたExtensionPhysicalDeliveryAddressComponents
ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter
ExtensionPhysicalDeliveryAddressComponents:、:= PDSParameter
unformatted-postal-address EXTENSION-ATTRIBUTE ::=
{UnformattedPostalAddress IDENTIFIED BY 16}
非フォーマットされた郵便の宛先EXTENSION-ATTRIBUTE:、:= 16時までに特定されたUnformattedPostalAddress
UnformattedPostalAddress ::= SET {
printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) OF
PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL,
teletex-string TeletexString (SIZE
(1..ub-unformatted-address-length)) OPTIONAL }
UnformattedPostalAddress:、:= セットします。印刷可能なアドレスSEQUENCE SIZE(1..ub-pdsの物理的なアドレス記入欄)OF PrintableString(SIZE(1..ub-pdsパラメタの長さ))OPTIONAL、テレテックスストリングTeletexString(SIZE(1..ub-unformattedアドレスの長さ))OPTIONAL
street-address EXTENSION-ATTRIBUTE ::=
{StreetAddress IDENTIFIED BY 17}
住所EXTENSION-ATTRIBUTE:、:= 17時までに特定されたStreetAddress
StreetAddress ::= PDSParameter
StreetAddress:、:= PDSParameter
post-office-box-address EXTENSION-ATTRIBUTE ::=
{PostOfficeBoxAddress IDENTIFIED BY 18}
郵便の箱のアドレスEXTENSION-ATTRIBUTE:、:= 18時までに特定されたPostOfficeBoxAddress
PostOfficeBoxAddress ::= PDSParameter
PostOfficeBoxAddress:、:= PDSParameter
poste-restante-address EXTENSION-ATTRIBUTE ::=
{PosteRestanteAddress IDENTIFIED BY 19}
poste-restante-アドレスEXTENSION-ATTRIBUTE:、:= 19時までに特定されたPosteRestanteAddress
PosteRestanteAddress ::= PDSParameter
PosteRestanteAddress:、:= PDSParameter
unique-postal-name EXTENSION-ATTRIBUTE ::=
{UniquePostalName IDENTIFIED BY 20}
ユニークな郵便の名前EXTENSION-ATTRIBUTE:、:= 20時までに特定されたUniquePostalName
Housley, et. al. Standards Track [Page 104] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[104ページ]。
UniquePostalName ::= PDSParameter
UniquePostalName:、:= PDSParameter
local-postal-attributes EXTENSION-ATTRIBUTE ::=
{LocalPostalAttributes IDENTIFIED BY 21}
地方の郵便の属性EXTENSION-ATTRIBUTE:、:= 21時までに特定されたLocalPostalAttributes
LocalPostalAttributes ::= PDSParameter
LocalPostalAttributes:、:= PDSParameter
PDSParameter ::= SET {
printable-string PrintableString
(SIZE(1..ub-pds-parameter-length)) OPTIONAL,
teletex-string TeletexString
(SIZE(1..ub-pds-parameter-length)) OPTIONAL }
PDSParameter:、:= セットします。印刷可能なストリングPrintableString(SIZE(1..ub-pdsパラメタの長さ))OPTIONAL、テレテックスストリングTeletexString(SIZE(1..ub-pdsパラメタの長さ))OPTIONAL
extended-network-address EXTENSION-ATTRIBUTE ::=
{ExtendedNetworkAddress IDENTIFIED BY 22}
拡張ネットワーク・アドレスEXTENSION-ATTRIBUTE:、:= 22時までに特定されたExtendedNetworkAddress
ExtendedNetworkAddress ::= CHOICE {
e163-4-address SEQUENCE {
number [0] NumericString
(SIZE (1..ub-e163-4-number-length)),
sub-address [1] NumericString
(SIZE (1..ub-e163-4-sub-address-length)) OPTIONAL},
psap-address [0] PresentationAddress }
ExtendedNetworkAddress:、:= 選択e163 4アドレスSEQUENCE数[0]NumericString(SIZE(1..ub-e163 4数の長さ))の、そして、サブアドレスの[1]NumericString(SIZE(1..ub-e163の4のサブアドレスの長さ))OPTIONAL、psap-アドレス[0]PresentationAddress
PresentationAddress ::= SEQUENCE {
pSelector [0] EXPLICIT OCTET STRING OPTIONAL,
sSelector [1] EXPLICIT OCTET STRING OPTIONAL,
tSelector [2] EXPLICIT OCTET STRING OPTIONAL,
nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING}
PresentationAddress:、:= 系列八重奏ストリングのpSelectorの明白な八重奏ストリング任意の、そして、[1]の明白な八重奏ストリング任意の、そして、tSelectorの[2]の明白な八重奏ストリング任意のsSelector nAddresses[3]明白なセット[0]サイズ(1..MAX)
terminal-type EXTENSION-ATTRIBUTE ::= {TerminalType IDENTIFIED BY 23}
端末のタイプEXTENSION-ATTRIBUTE:、:= 23時までに特定されたTerminalType
TerminalType ::= INTEGER {
telex (3),
teletex (4),
g3-facsimile (5),
g4-facsimile (6),
ia5-terminal (7),
videotex (8) } (0..ub-integer-options)
TerminalType:、:= INTEGERは(3)、テレテックス(4)、g3-ファクシミリ(5)、g4-ファクシミリ(6)、ia5-端末(7)、ビデオテックス(8)をテレックスで送信します。(0..ub整数オプション)
-- Extension Domain-defined Attributes
-- 拡大のドメインで定義された属性
teletex-domain-defined-attributes EXTENSION-ATTRIBUTE ::=
{TeletexDomainDefinedAttributes IDENTIFIED BY 6}
テレテックスのドメインの定義された属性EXTENSION-ATTRIBUTE:、:= 6時までに特定されたTeletexDomainDefinedAttributes
TeletexDomainDefinedAttributes ::= SEQUENCE SIZE (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute
TeletexDomainDefinedAttributes:、:= TeletexDomainDefinedAttributeの系列サイズ(1..ubドメインは属性を定義しました)
Housley, et. al. Standards Track [Page 105] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[105ページ]。
TeletexDomainDefinedAttribute ::= SEQUENCE {
type TeletexString
(SIZE (1..ub-domain-defined-attribute-type-length)),
value TeletexString
(SIZE (1..ub-domain-defined-attribute-value-length)) }
TeletexDomainDefinedAttribute:、:= 系列TeletexString(SIZE(1..ubドメインは属性タイプの長さを定義した))、値のTeletexString(SIZE(1..ubドメインは属性値の長さを定義した))をタイプしてください。
-- specifications of Upper Bounds -- shall be regarded as mandatory -- from Annex B of ITU-T X.411 -- Reference Definition of MTS Parameter Upper Bounds
-- ITU-T X.411のAnnex BからのUpper Bounds(義務的であると見なされる)の仕様--MTS Parameter Upper Boundsの参照Definition
-- Upper Bounds ub-name INTEGER ::= 32768 ub-common-name INTEGER ::= 64 ub-locality-name INTEGER ::= 128 ub-state-name INTEGER ::= 128 ub-organization-name INTEGER ::= 64 ub-organizational-unit-name INTEGER ::= 64 ub-title INTEGER ::= 64 ub-match INTEGER ::= 128
-- 上側のBounds ub-名前INTEGER:、:= 32768 ub-一般名INTEGER:、:= 64 ub場所名のINTEGER:、:= 128 ub州の名のINTEGER:、:= 128 ub組織名のINTEGER:、:= 64 組織的なユニットが命名するub INTEGER:、:= 64 ub-タイトルINTEGER:、:= 64 ub-マッチINTEGER:、:= 128
ub-emailaddress-length INTEGER ::= 128
ub-emailaddress-長さのINTEGER:、:= 128
ub-common-name-length INTEGER ::= 64 ub-country-name-alpha-length INTEGER ::= 2 ub-country-name-numeric-length INTEGER ::= 3 ub-domain-defined-attributes INTEGER ::= 4 ub-domain-defined-attribute-type-length INTEGER ::= 8 ub-domain-defined-attribute-value-length INTEGER ::= 128 ub-domain-name-length INTEGER ::= 16 ub-extension-attributes INTEGER ::= 256 ub-e163-4-number-length INTEGER ::= 15 ub-e163-4-sub-address-length INTEGER ::= 40 ub-generation-qualifier-length INTEGER ::= 3 ub-given-name-length INTEGER ::= 16 ub-initials-length INTEGER ::= 5 ub-integer-options INTEGER ::= 256 ub-numeric-user-id-length INTEGER ::= 32 ub-organization-name-length INTEGER ::= 64 ub-organizational-unit-name-length INTEGER ::= 32 ub-organizational-units INTEGER ::= 4 ub-pds-name-length INTEGER ::= 16 ub-pds-parameter-length INTEGER ::= 30 ub-pds-physical-address-lines INTEGER ::= 6 ub-postal-code-length INTEGER ::= 16 ub-surname-length INTEGER ::= 40 ub-terminal-id-length INTEGER ::= 24 ub-unformatted-address-length INTEGER ::= 180
ubの一般的な名前の長さのINTEGER:、:= 64 ub国の名前アルファの長さのINTEGER:、:= 2 ubの国の名義の数値長さのINTEGER:、:= 3 ubドメインが属性を定義しているINTEGER:、:= 4 ubドメインが属性タイプの長さを定義しているINTEGER:、:= 8 ubドメインが属性値の長さを定義しているINTEGER:、:= 128 ubドメイン名前の長さのINTEGER:、:= 16 ub拡大属性INTEGER:、:= 256 ub-e163 4数の長さのINTEGER:、:= 15 ub-e163の4のサブアドレスの長さのINTEGER:、:= 40 ub世代資格を与える人の長さのINTEGER:、:= 3 ubに与えられた名前の長さのINTEGER:、:= 16 ubが長さに頭文字をつけているINTEGER:、:= 5 ub整数オプションINTEGER:、:= 256 ubの数値ユーザイドの長さのINTEGER:、:= 32 ub組織名前の長さのINTEGER:、:= 64 ubの組織的なユニットが長さを命名しているINTEGER:、:= 32 ubの組織的なユニットINTEGER:、:= 4 ub-pds名前の長さのINTEGER:、:= 16 ub-pdsパラメタの長さのINTEGER:、:= 30 ub-pds身体検査がアドレスで立ち並んでいるINTEGER:、:= 6 ubの郵便のコードの長さのINTEGER:、:= 16 ub姓の長さのINTEGER:、:= 40 ubの端末のイドの長さのINTEGER:、:= 24 ub-unformattedアドレスの長さのINTEGER:、:= 180
Housley, et. al. Standards Track [Page 106] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[106ページ]。
ub-x121-address-length INTEGER ::= 16
ub-x121アドレスの長さのINTEGER:、:= 16
-- Note - upper bounds on TeletexString are measured in characters. -- A significantly greater number of octets will be required to hold -- such a value. As a minimum, 16 octets, or twice the specified upper -- bound, whichever is the larger, should be allowed.
-- 注意--TeletexStringの上の上限はキャラクタで測定されます。 -- かなり大きい数の八重奏が成立するのに必要でしょう--そのような値。 最小限として、16の八重奏、または指定された覚醒剤の2倍--どれがさらに大きいかならバウンドしているのは許されるべきです。
END
終わり
Housley, et. al. Standards Track [Page 107] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[107ページ]。
B.2 Implicitly Tagged Module, 1993 Syntax
B.2はそれとなくモジュール、1993年の構文にタグ付けをしました。
PKIX1Implicit93 {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-93(4)}
PKIX1Implicit93iso(1)の特定された組織(3)のdod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)のイドのpkix1の内在している93(4)
DEFINITIONS IMPLICIT TAGS::=
定義、内在しているタグ:、:=
BEGIN
始まってください。
--EXPORTS ALL --
--すべてを輸出します--
IMPORTS
id-pe, id-qt, id-kp, id-ad, id-qt-unotice,
ORAddress, Name, RelativeDistinguishedName,
CertificateSerialNumber, CertificateList,
AlgorithmIdentifier, ub-name, DirectoryString,
Attribute, EXTENSION
FROM PKIX1Explicit93 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit-93(3)};
IMPORTSイド-pe、イド-qt、イド-kp、イド広告、イド-qt-unotice、ORAddress、Name、RelativeDistinguishedName、CertificateSerialNumber、CertificateList、AlgorithmIdentifier、ub-名前、DirectoryString、Attribute、EXTENSION FROM PKIX1Explicit93のiso(1)の特定された組織(3)dod(6)のインターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ風の(0)イドpkix1明白な93(3)。
-- Key and policy information extensions --
-- キーと方針情報拡張子--
authorityKeyIdentifier EXTENSION ::= {
SYNTAX AuthorityKeyIdentifier
IDENTIFIED BY id-ce-authorityKeyIdentifier }
authorityKeyIdentifier拡張子:、:= 構文AuthorityKeyIdentifierが特定した、イドCe authorityKeyIdentifier
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNames OPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
( WITH COMPONENTS {..., authorityCertIssuer PRESENT,
authorityCertSerialNumber PRESENT} |
WITH COMPONENTS {..., authorityCertIssuer ABSENT,
authorityCertSerialNumber ABSENT} )
AuthorityKeyIdentifier:、:= 系列、keyIdentifier[0]KeyIdentifierの任意の、そして、authorityCertIssuer[1]GeneralNames任意のauthorityCertSerialNumber[2]CertificateSerialNumber任意(コンポーネント、…、authorityCertSerialNumberが提示するauthorityCertIssuerプレゼント|、…で、authorityCertIssuer欠けていて、authorityCertSerialNumber欠けているコンポーネント、)
KeyIdentifier ::= OCTET STRING
KeyIdentifier:、:= 八重奏ストリング
subjectKeyIdentifier EXTENSION ::= {
SYNTAX SubjectKeyIdentifier
IDENTIFIED BY id-ce-subjectKeyIdentifier }
subjectKeyIdentifier拡張子:、:= 構文SubjectKeyIdentifierが特定した、イドCe subjectKeyIdentifier
SubjectKeyIdentifier ::= KeyIdentifier
SubjectKeyIdentifier:、:= KeyIdentifier
keyUsage EXTENSION ::= {
SYNTAX KeyUsage
IDENTIFIED BY id-ce-keyUsage }
keyUsage拡張子:、:= 構文KeyUsageが特定した、イドCe keyUsage
Housley, et. al. Standards Track [Page 108] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[108ページ]。
KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1),
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5),
cRLSign (6),
encipherOnly (7),
decipherOnly (8) }
KeyUsage:、:= ビット列digitalSignature(0)、nonRepudiation(1)、keyEncipherment(2)、dataEncipherment(3)、keyAgreement(4)、keyCertSign(5)、cRLSign(6)、encipherOnly(7)、decipherOnly(8)
extendedKeyUsage EXTENSION ::= {
SYNTAX SEQUENCE SIZE (1..MAX) OF KeyPurposeId
IDENTIFIED BY id-ce-extKeyUsage }
extendedKeyUsage拡張子:、:= KeyPurposeIdの構文系列サイズ(1..MAX)が特定した、イドCe extKeyUsage
KeyPurposeId ::= OBJECT IDENTIFIER
KeyPurposeId:、:= 物の識別子
-- PKIX-defined extended key purpose OIDs
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
id-kp-ipsecEndSystem OBJECT IDENTIFIER ::= { id-kp 5 }
id-kp-ipsecTunnel OBJECT IDENTIFIER ::= { id-kp 6 }
id-kp-ipsecUser OBJECT IDENTIFIER ::= { id-kp 7 }
id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
-- PKIXによって定義された敷衍された主要な目的OIDsイド-kp-serverAuth OBJECT IDENTIFIER:、:= イド-kp1、イド-kp-clientAuth OBJECT IDENTIFIER:、:= イド-kp2、イド-kp-codeSigning OBJECT IDENTIFIER:、:= イド-kp3、イド-kp-emailProtection OBJECT IDENTIFIER:、:= イド-kp4、イド-kp-ipsecEndSystem OBJECT IDENTIFIER:、:= イド-kp5、イド-kp-ipsecTunnel OBJECT IDENTIFIER:、:= イド-kp6、イド-kp-ipsecUser OBJECT IDENTIFIER:、:= イド-kp7、イド-kp-timeStamping OBJECT IDENTIFIER:、:= イド-kp8
privateKeyUsagePeriod EXTENSION ::= {
SYNTAX PrivateKeyUsagePeriod
IDENTIFIED BY { id-ce-privateKeyUsagePeriod } }
privateKeyUsagePeriod拡張子:、:= 構文PrivateKeyUsagePeriodが特定した、イドCe privateKeyUsagePeriod
PrivateKeyUsagePeriod ::= SEQUENCE {
notBefore [0] GeneralizedTime OPTIONAL,
notAfter [1] GeneralizedTime OPTIONAL }
( WITH COMPONENTS {..., notBefore PRESENT} |
WITH COMPONENTS {..., notAfter PRESENT} )
PrivateKeyUsagePeriod:、:= 系列、notBefore[0]GeneralizedTime任意で、notAfter[1]GeneralizedTime任意(コンポーネント、…、notBeforeプレゼント|、コンポーネント、…、notAfterプレゼント)
certificatePolicies EXTENSION ::= {
SYNTAX CertificatePoliciesSyntax
IDENTIFIED BY id-ce-certificatePolicies }
certificatePolicies拡張子:、:= 構文CertificatePoliciesSyntaxが特定した、イドCe certificatePolicies
CertificatePoliciesSyntax ::=
SEQUENCE SIZE (1..MAX) OF PolicyInformation
CertificatePoliciesSyntax:、:= PolicyInformationの系列サイズ(1..MAX)
PolicyInformation ::= SEQUENCE {
policyIdentifier CertPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL }
PolicyInformation:、:= 系列policyIdentifier CertPolicyId、PolicyQualifierInfo任意のpolicyQualifiers系列サイズ(1..MAX)
Housley, et. al. Standards Track [Page 109] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[109ページ]。
CertPolicyId ::= OBJECT IDENTIFIER
CertPolicyId:、:= 物の識別子
PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId CERT-POLICY-QUALIFIER.&id
({SupportedPolicyQualifiers}),
qualifier CERT-POLICY-QUALIFIER.&Qualifier
({SupportedPolicyQualifiers}
{@policyQualifierId})OPTIONAL }
PolicyQualifierInfo:、:= 系列資格を与える人CERT-POLICY-QUALIFIER policyQualifierId CERT-POLICY-QUALIFIERイド(SupportedPolicyQualifiers)、Qualifier、(SupportedPolicyQualifiers、@policyQualifierId) OPTIONAL
SupportedPolicyQualifiers CERT-POLICY-QUALIFIER ::= { noticeToUser |
pointerToCPS }
SupportedPolicyQualifiers本命方針資格を与える人:、:= noticeToUser| pointerToCPS
CERT-POLICY-QUALIFIER ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Qualifier OPTIONAL }
WITH SYNTAX {
POLICY-QUALIFIER-ID &id
[QUALIFIER-TYPE &Qualifier] }
本命方針資格を与える人:、:= 属してください、イドが識別子ユニークであって、資格を与える人任意の状態で反対する、構文方針資格を与える人IDとイド[資格を与える人タイプと資格を与える人]
policyMappings EXTENSION ::= {
SYNTAX PolicyMappingsSyntax
IDENTIFIED BY id-ce-policyMappings }
policyMappings拡張子:、:= 構文PolicyMappingsSyntaxが特定した、イドCe policyMappings
PolicyMappingsSyntax ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
issuerDomainPolicy CertPolicyId,
subjectDomainPolicy CertPolicyId }
PolicyMappingsSyntax:、:= 系列の系列サイズ(1..MAX)issuerDomainPolicy CertPolicyId、subjectDomainPolicy CertPolicyId
-- Certificate subject and certificate issuer attributes extensions --
-- 対象と証明書発行人属性拡張子を証明してください--
subjectAltName EXTENSION ::= {
SYNTAX GeneralNames
IDENTIFIED BY id-ce-subjectAltName }
subjectAltName拡張子:、:= 構文GeneralNamesが特定した、イドCe subjectAltName
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralNames:、:= GeneralNameの系列サイズ(1..MAX)
GeneralName ::= CHOICE {
otherName [0] INSTANCE OF OTHER-NAME,
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:、:= 選択他の名前、rfc822Name[1]IA5String、dNSName[2]IA5String、x400Address[3]ORAddress、directoryName[4]名、ediPartyName[5]EDIPartyName、uniformResourceIdentifier[6]IA5String、iPAddress[7]八重奏ストリング、registeredID[8]物の識別子のotherName[0]例
OTHER-NAME ::= TYPE-IDENTIFIER
以下をもう一方で命名してください:= タイプ識別子
Housley, et. al. Standards Track [Page 110] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[110ページ]。
EDIPartyName ::= SEQUENCE {
nameAssigner [0] DirectoryString {ub-name} OPTIONAL,
partyName [1] DirectoryString {ub-name} }
EDIPartyName:、:= 系列任意のnameAssigner[0]DirectoryString ub-名前partyName[1]DirectoryString ub-名
issuerAltName EXTENSION ::= {
SYNTAX GeneralNames
IDENTIFIED BY id-ce-issuerAltName }
issuerAltName拡張子:、:= 構文GeneralNamesが特定した、イドCe issuerAltName
subjectDirectoryAttributes EXTENSION ::= {
SYNTAX AttributesSyntax
IDENTIFIED BY id-ce-subjectDirectoryAttributes }
subjectDirectoryAttributes拡張子:、:= 構文AttributesSyntaxが特定した、イドCe subjectDirectoryAttributes
AttributesSyntax ::= SEQUENCE SIZE (1..MAX) OF Attribute
AttributesSyntax:、:= 属性の系列サイズ(1..MAX)
-- Certification path constraints extensions --
-- 証明経路規制拡大--
basicConstraints EXTENSION ::= {
SYNTAX BasicConstraintsSyntax
IDENTIFIED BY id-ce-basicConstraints }
basicConstraints拡張子:、:= 構文BasicConstraintsSyntaxが特定した、イドCe basicConstraints
BasicConstraintsSyntax ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
BasicConstraintsSyntax:、:= 系列cA論理演算子は誤っていて、pathLenConstraint整数(0..MAX)任意の状態でデフォルトとします。
nameConstraints EXTENSION ::= {
SYNTAX NameConstraintsSyntax
IDENTIFIED BY id-ce-nameConstraints }
nameConstraints拡張子:、:= 構文NameConstraintsSyntaxが特定した、イドCe nameConstraints
NameConstraintsSyntax ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
NameConstraintsSyntax:、:= 系列permittedSubtrees[0]GeneralSubtrees任意であって、excludedSubtrees[1]GeneralSubtrees任意です。
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtrees:、:= GeneralSubtreeの系列サイズ(1..MAX)
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)
policyConstraints EXTENSION ::= {
SYNTAX PolicyConstraintsSyntax
IDENTIFIED BY id-ce-policyConstraints }
policyConstraints拡張子:、:= 構文PolicyConstraintsSyntaxが特定した、イドCe policyConstraints
PolicyConstraintsSyntax ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
PolicyConstraintsSyntax:、:= 系列requireExplicitPolicy[0]SkipCerts任意であって、inhibitPolicyMapping[1]SkipCerts任意です。
Housley, et. al. Standards Track [Page 111] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[111ページ]。
SkipCerts ::= INTEGER (0..MAX)
SkipCerts:、:= 整数(0..MAX)
-- Basic CRL extensions --
-- 基本的なCRL拡張子--
cRLNumber EXTENSION ::= {
SYNTAX CRLNumber
IDENTIFIED BY id-ce-cRLNumber }
cRLNumber拡張子:、:= 構文CRLNumberが特定した、イドCe cRLNumber
CRLNumber ::= INTEGER (0..MAX)
CRLNumber:、:= 整数(0..MAX)
reasonCode EXTENSION ::= {
SYNTAX CRLReason
IDENTIFIED BY id-ce-reasonCode }
reasonCode拡張子:、:= 構文CRLReasonが特定した、イドCe reasonCode
CRLReason ::= ENUMERATED {
unspecified (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
removeFromCRL (8) }
CRLReason:、:= 列挙されます。removeFromCRL(8)、不特定の(0)(keyCompromise(1)、cACompromise(2)、affiliationChanged(3))は(4)、cessationOfOperation(5)、certificateHold(6)に取って代わりました。
instructionCode EXTENSION ::= {
SYNTAX HoldInstruction
IDENTIFIED BY id-ce-instructionCode }
instructionCode拡張子:、:= 構文HoldInstructionが特定した、イドCe instructionCode
HoldInstruction ::= OBJECT IDENTIFIER
HoldInstruction:、:= 物の識別子
-- holdinstructions described in this specification, from ANSI x9
-- ANSI x9からのこの仕様で説明されたholdinstructions
-- ANSI x9 arc holdinstruction arc
holdInstruction OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) member-body(2) us(840) x9cm(10040) 2}
-- ANSI x9アークholdinstructionアークholdInstruction OBJECT IDENTIFIER:、:= 共同iso-ccitt(2)は(2) 私たち(840)x9cm(10040)2をメンバーと同じくらい具体化させます。
-- ANSI X9 holdinstructions referenced by this standard
id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1}
id-holdinstruction-callissuer OBJECT IDENTIFIER ::= {holdInstruction 2}
id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}
-- ANSI X9 holdinstructionsがこの規格で参照をつけた、イドholdinstruction、なにも、OBJECT IDENTIFIER:、:= holdInstruction1イド-holdinstruction-callissuer OBJECT IDENTIFIER:、:= holdInstruction2イドholdinstruction廃棄物OBJECT IDENTIFIER:、:= holdInstruction3
invalidityDate EXTENSION ::= {
SYNTAX GeneralizedTime
IDENTIFIED BY id-ce-invalidityDate }
invalidityDate拡張子:、:= 構文GeneralizedTimeが特定した、イドCe invalidityDate
-- CRL distribution points and delta-CRL extensions --
-- CRL分配ポイントとデルタ-CRL拡張子--
cRLDistributionPoints EXTENSION ::= {
cRLDistributionPoints拡張子:、:= {
Housley, et. al. Standards Track [Page 112] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[112ページ]。
SYNTAX CRLDistPointsSyntax
IDENTIFIED BY id-ce-cRLDistributionPoints }
構文CRLDistPointsSyntaxが特定した、イドCe cRLDistributionPoints
CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
CRLDistPointsSyntax:、:= 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
ReasonFlags ::= BIT STRING {
unused (0),
keyCompromise (1),
caCompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6) }
ReasonFlags:、:= ビット列未使用の(0)(keyCompromise(1)、caCompromise(2)、affiliationChanged(3))は(4)、cessationOfOperation(5)、certificateHold(6)に取って代わりました。
issuingDistributionPoint EXTENSION ::= {
SYNTAX IssuingDistPointSyntax
IDENTIFIED BY id-ce-issuingDistributionPoint }
issuingDistributionPoint拡張子:、:= 構文IssuingDistPointSyntaxが特定した、イドCe issuingDistributionPoint
IssuingDistPointSyntax ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
onlySomeReasons [3] ReasonFlags OPTIONAL,
indirectCRL [4] BOOLEAN DEFAULT FALSE }
IssuingDistPointSyntax:、:= 系列distributionPoint[0]DistributionPointName任意です、onlyContainsUserCertsの論理演算子のデフォルトの誤って、onlyContainsCACerts[2]ブールのデフォルト誤って、onlySomeReasons[3]ReasonFlags任意の[1]indirectCRL[4]論理演算子は虚偽でデフォルトとします。
certificateIssuer EXTENSION ::= {
SYNTAX GeneralNames
IDENTIFIED BY id-ce-certificateIssuer }
certificateIssuer拡張子:、:= 構文GeneralNamesが特定した、イドCe certificateIssuer
deltaCRLIndicator EXTENSION ::= {
SYNTAX BaseCRLNumber
IDENTIFIED BY id-ce-deltaCRLIndicator }
deltaCRLIndicator拡張子:、:= 構文BaseCRLNumberが特定した、イドCe deltaCRLIndicator
BaseCRLNumber ::= CRLNumber
BaseCRLNumber:、:= CRLNumber
-- Object identifier assignments for ISO certificate extensions --
id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29}
-- ISO証明書拡張子のための物の識別子課題--イドCe OBJECT IDENTIFIER:、:= 共同iso-ccitt(2) ds(5)29
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= {id-ce 9}
イドCe subjectDirectoryAttributes、物の識別子:、:= イドCe9
Housley, et. al. Standards Track [Page 113] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[113ページ]。
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 14}
id-ce-keyUsage OBJECT IDENTIFIER ::= {id-ce 15}
id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= {id-ce 16}
id-ce-subjectAltName OBJECT IDENTIFIER ::= {id-ce 17}
id-ce-issuerAltName OBJECT IDENTIFIER ::= {id-ce 18}
id-ce-basicConstraints OBJECT IDENTIFIER ::= {id-ce 19}
id-ce-cRLNumber OBJECT IDENTIFIER ::= {id-ce 20}
id-ce-reasonCode OBJECT IDENTIFIER ::= {id-ce 21}
id-ce-instructionCode OBJECT IDENTIFIER ::= {id-ce 23}
id-ce-invalidityDate OBJECT IDENTIFIER ::= {id-ce 24}
id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= {id-ce 27}
id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= {id-ce 28}
id-ce-certificateIssuer OBJECT IDENTIFIER ::= {id-ce 29}
id-ce-nameConstraints OBJECT IDENTIFIER ::= {id-ce 30}
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31}
id-ce-certificatePolicies OBJECT IDENTIFIER ::= {id-ce 32}
id-ce-policyMappings OBJECT IDENTIFIER ::= {id-ce 33}
id-ce-policyConstraints OBJECT IDENTIFIER ::= {id-ce 36}
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 35}
id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37}
イドCe subjectKeyIdentifier、物の識別子:、:= イドCe14、イドCe keyUsage、物の識別子:、:= イドCe15、イドCe privateKeyUsagePeriod、物の識別子:、:= イドCe16、イドCe subjectAltName、物の識別子:、:= イドCe17、イドCe issuerAltName、物の識別子:、:= イドCe18、イドCe basicConstraints、物の識別子:、:= イドCe19、イドCe cRLNumber、物の識別子:、:= イドCe20、イドCe reasonCode、物の識別子:、:= イドCe21、イドCe instructionCode、物の識別子:、:= イドCe23、イドCe invalidityDate、物の識別子:、:= イドCe24、イドCe deltaCRLIndicator、物の識別子:、:= イドCe27、イドCe issuingDistributionPoint、物の識別子:、:= イドCe28、イドCe certificateIssuer、物の識別子:、:= イドCe29、イドCe nameConstraints、物の識別子:、:= イドCe30、イドCe cRLDistributionPoints、物の識別子:、:= イドCe31、イドCe certificatePolicies、物の識別子:、:= イドCe32、イドCe policyMappings、物の識別子:、:= イドCe33、イドCe policyConstraints、物の識別子:、:= イドCe36、イドCe authorityKeyIdentifier、物の識別子:、:= イドCe35、イドCe extKeyUsage、物の識別子:、:= イドCe37
-- PKIX 1 extensions
-- PKIX1拡張子
authorityInfoAccess EXTENSION ::= {
SYNTAX AuthorityInfoAccessSyntax
IDENTIFIED BY id-pe-authorityInfoAccess }
authorityInfoAccess拡張子:、:= イド-pe-authorityInfoAccessによって特定された構文AuthorityInfoAccessSyntax
AuthorityInfoAccessSyntax ::=
SEQUENCE SIZE (1..MAX) OF AccessDescription
AuthorityInfoAccessSyntax:、:= AccessDescriptionの系列サイズ(1..MAX)
AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER,
accessLocation GeneralName }
AccessDescription:、:= 系列accessMethod物の識別子、accessLocation GeneralName
id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
イド-pe-authorityInfoAccess物の識別子:、:= イド-pe1
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
イド広告ocsp OBJECT IDENTIFIER、:、:= イド広告1、イド広告caIssuers OBJECT IDENTIFIER、:、:= イド広告2
-- PKIX policy qualifier definitions
-- PKIX方針資格を与える人定義
noticeToUser CERT-POLICY-QUALIFIER ::= {
POLICY-QUALIFIER-ID id-qt-cps QUALIFIER-TYPE CPSuri}
noticeToUser本命方針資格を与える人:、:= POLICY-QUALIFIER-IDイド-qt-cps QUALIFIER-TYPE CPSuri
pointerToCPS CERT-POLICY-QUALIFIER ::= {
POLICY-QUALIFIER-ID id-qt-unotice QUALIFIER-TYPE UserNotice}
pointerToCPS本命方針資格を与える人:、:= POLICY-QUALIFIER-IDイド-qt-unotice QUALIFIER-TYPE UserNotice
id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
イド-qt-cps OBJECT IDENTIFIER:、:= イド-qt1
Housley, et. al. Standards Track [Page 114] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[114ページ]。
id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
イド-qt-unotice OBJECT IDENTIFIER:、:= イド-qt2
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 {
visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200)) }
DisplayText:、:= 選択visibleString VisibleString(サイズ(1 .200))、bmpString BMPString(サイズ(1 .200))、utf8String UTF8String(サイズ(1 .200))
END
終わり
Housley, et. al. Standards Track [Page 115] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[115ページ]。
Appendix C. ASN.1 Notes
ASN.1が注意する付録C.
The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 constructs. A valid ASN.1 sequence will have zero or more entries. The SIZE (1..MAX) construct constrains the sequence to have at least one entry. MAX indicates the upper bound is unspecified. Implementations are free to choose an upper bound that suits their environment.
構造物が「サイズ(1..MAX)を配列する」、いくつかのASN.1構造物では、現れます。 有効なASN.1系列には、ゼロか、より多くのエントリーがあるでしょう。 (1..MAX)が組み立てるSIZEは、系列には少なくとも1つのエントリーがあるのを抑制します。 MAXは、上限が不特定であることを示します。 実現は無料で彼らの環境に合う上限を選ぶことができます。
The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt as a subtype of INTEGER containing integers greater than or equal to zero. The upper bound is unspecified. Implementations are free to select an upper bound that suits their environment.
構造物、「positiveInt:、:、」= 「INTEGER(0..MAX)」はゼロ以上の整数を含むINTEGERの「副-タイプ」とpositiveIntを定義します。 上限は不特定です。 実現は無料で彼らの環境に合う上限を選択できます。
The character string type PrintableString supports a very basic Latin character set: the lower case letters 'a' through 'z', upper case letters 'A' through 'Z', the digits '0' through '9', eleven special characters ' " ( ) + , - . / : ? and space.
文字列タイプPrintableStringは非常に基本的なラテン語の文字の組をサポートします: 'z'を通して手紙'a'をケースに入れてください、より低く''から'Z'、'9'、11の特殊文字を通したケタ'0''という大文字手紙、「( )+--. /:、」、' ? そして、スペース。
The character string type TeletexString is a superset of PrintableString. TeletexString supports a fairly standard (ascii- like) Latin character set, Latin characters with non-spacing accents and Japanese characters.
文字列タイプTeletexStringはPrintableStringのスーパーセットです。 TeletexStringは非スペースアクセントと日本人のキャラクタと共にかなり標準(ASCII同類)のラテン語の文字の組、ラテン語のキャラクタを支持します。
The character string type UniversalString supports any of the characters allowed by ISO 10646-1. ISO 10646 is the Universal multiple-octet coded Character Set (UCS). ISO 10646-1 specifes the architecture and the "basic multilingual plane" - a large standard character set which includes all major world character standards.
文字列タイプUniversalStringはISO10646-1によって許容されたキャラクタのいずれも支持します。 ISO10646はUniversalの複数の八重奏コード化された文字コード(UCS)です。 ISO10646-1specifes構造と「基本多言語面」--すべての主要な世界キャラクタ規格を含んでいる大きい標準文字セット。
The character string type UTF8String will be introduced in the 1998 version of ASN.1. UTF8String is a universal type and has been assigned tag number 12. The content of UTF8String was defined by RFC 2044 and updated in RFC 2279, "UTF-8, a transformation Format of ISP 10646." ISO is expected to formally add UTF8String to the list of choices for DirectoryString in 1998 as well.
1998年のASN.1のバージョンで文字列タイプUTF8Stringを導入するでしょう。 UTF8Stringは普遍的なタイプであり、タグNo.12を割り当ててあります。 UTF8Stringの内容をRFC2044が定義して、RFC2279、「UTF-8、ISP10646の変化Format」でアップデートしました。 ISOがまた、1998年にDirectoryStringのために正式に選択のリストにUTF8Stringを追加すると予想されます。
In anticipation of these changes, and in conformance with IETF Best Practices codified in RFC 2277, IETF Policy on Character Sets and Languages, this document includes UTF8String as a choice in DirectoryString and the CPS qualifier extensions.
IETF Best PracticesがRFC2277で成文化されている順応、文字コードのIETF Policy、およびこれらの変化を予測したLanguagesでは、このドキュメントは選択としてDirectoryStringとCPS資格を与える人拡張子でUTF8Stringを含んでいます。
Housley, et. al. Standards Track [Page 116] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[116ページ]。
Appendix D. Examples
付録D.の例
This section contains four examples: three certificates and a CRL. The first two certificates and the CRL comprise a minimal certification path.
このセクションは4つの例を含みます: 3通の証明書とCRL。 最初の2通の証明書とCRLは最小量の証明経路を包括します。
Section D.1 contains an annotated hex dump of a "self-signed" certificate issued by a CA whose distinguished name is cn=us,o=gov,ou=nist. The certificate contains a DSA public key with parameters, and is signed by the corresponding DSA private key.
セクションD.1は分類名がcnであるカリフォルニア=私たちによって発行された、「自己によってサインされた」証明書、o=gov、ou=nistの注釈された十六進法ダンプを含んでいます。 証明書は、パラメタでDSA公開鍵を含んでいて、対応するDSA秘密鍵によってサインされます。
Section D.2 contains an annotated hex dump of an end-entity certificate. The end entity certificate contains a DSA public key, and is signed by the private key corresponding to the "self-signed" certificate in section D.1.
セクションD.2は終わり実体証明書の注釈された十六進法ダンプを含んでいます。 終わりの実体証明書は、DSA公開鍵を含んでいて、セクションD.1の「自己によってサインされた」証明書に対応する秘密鍵によってサインされます。
Section D.3 contains a dump of an end entity certificate which contains an RSA public key and is signed with RSA and MD5. This certificate is not part of the minimal certification path.
セクションD.3はRSA公開鍵を含んでいて、RSAとMD5を契約される終わりの実体証明書のダンプを含んでいます。 この証明書は最小量の証明経路の一部ではありません。
Section D.4 contains an annotated hex dump of a CRL. The CRL is issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and the list of revoked certificates includes the end entity certificate presented in D.2.
セクションD.4はCRLの注釈された十六進法ダンプを含んでいます。 CRLは分類名がcn=私たちであるカリフォルニアによって発行されて、o=gov、ou=nist、および取り消された証明書のリストはD.2に提示された終わりの実体証明書を含んでいます。
D.1 Certificate
D.1証明書
This section contains an annotated hex dump of a 699 byte version 3 certificate. The certificate contains the following information: (a) the serial number is 17 (11 hex); (b) the certificate is signed with DSA and the SHA-1 hash algorithm; (c) the issuer's distinguished name is OU=nist; O=gov; C=US (d) and the subject's distinguished name is OU=nist; O=gov; C=US (e) the certificate was issued on June 30, 1997 and will expire on December 31, 1997; (f) the certificate contains a 1024 bit DSA public key with parameters; (g) the certificate contains a subject key identifier extension; and (h) the certificate is a CA certificate (as indicated through the basic constraints extension.)
このセクションは699バイトのバージョン3証明書の注釈された十六進法ダンプを含みます。 証明書は以下の情報を含んでいます: (a) 通し番号は17(11十六進法)です。 (b) 証明書はDSAとSHA-1細切れ肉料理アルゴリズムを契約されます。 (c) 発行人の分類名はOU=nistです。 O=gov。 CはU.S.(d)と等しいです、そして、対象の分類名はOU=nistです。 O=gov。 Cは証明書が1997年6月30日に発行されて、1997年12月31日に吐き出す米国(e)と等しいです。 (f) 証明書はパラメタがある1024年のビットのDSA公開鍵を含んでいます。 (g) 証明書は対象の主要な識別子拡張子を含んでいます。 (h) そして、証明書はカリフォルニア証明書です。(基本的な規制拡大で示されるように。)
0000 30 82 02 b7 695: SEQUENCE
0004 30 82 02 77 631: . SEQUENCE tbscertificate
0008 a0 03 3: . . [0]
0010 02 01 1: . . . INTEGER 2
: 02
0013 02 01 1: . . INTEGER 17
: 11
0000 30 82 02b7 695: 系列0004 30 82 02 77 631: . SEQUENCE tbscertificate0008a0 03 3: . . [0] 0010 02 01 1: . . . 整数2: 02 0013 02 01 1: . . 整数17: 11
Housley, et. al. Standards Track [Page 117] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[117ページ]。
0016 30 09 9: . . SEQUENCE
0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha
: 2a 86 48 ce 38 04 03
0027 30 2a 42: . . SEQUENCE
0029 31 0b 11: . . . SET
0031 30 09 9: . . . . SEQUENCE
0033 06 03 3: . . . . . OID 2.5.4.6: C
: 55 04 06
0038 13 02 2: . . . . . PrintableString 'US'
: 55 53
0042 31 0c 12: . . . SET
0044 30 0a 10: . . . . SEQUENCE
0046 06 03 3: . . . . . OID 2.5.4.10: O
: 55 04 0a
0051 13 03 3: . . . . . PrintableString 'gov'
: 67 6f 76
0056 31 0d 13: . . . SET
0058 30 0b 11: . . . . SEQUENCE
0060 06 03 3: . . . . . OID 2.5.4.11: OU
: 55 04 0b
0065 13 04 4: . . . . . PrintableString 'nist'
: 6e 69 73 74
0071 30 1e 30: . . SEQUENCE
0073 17 0d 13: . . . UTCTime '970630000000Z'
: 39 37 30 36 33 30 30 30 30 30 30 30 5a
0088 17 0d 13: . . . UTCTime '971231000000Z'
: 39 37 31 32 33 31 30 30 30 30 30 30 5a
0103 30 2a 42: . . SEQUENCE
0105 31 0b 11: . . . SET
0107 30 09 9: . . . . SEQUENCE
0109 06 03 3: . . . . . OID 2.5.4.6: C
: 55 04 06
0114 13 02 2: . . . . . PrintableString 'US'
: 55 53
0118 31 0c 12: . . . SET
0120 30 0a 10: . . . . SEQUENCE
0122 06 03 3: . . . . . OID 2.5.4.10: O
: 55 04 0a
0127 13 03 3: . . . . . PrintableString 'gov'
: 67 6f 76
0132 31 0d 13: . . . SET
0134 30 0b 11: . . . . SEQUENCE
0136 06 03 3: . . . . . OID 2.5.4.11: OU
: 55 04 0b
0141 13 04 4: . . . . . PrintableString 'nist'
: 6e 69 73 74
0147 30 82 01 b4 436: . . SEQUENCE
0151 30 82 01 29 297: . . . SEQUENCE
0016 30 09 9: . . 系列0018 06 07 7: . . . OID1.2.840、.10040、.4、.3: shaとdsa: 2a86 48Ce38 04 03 0027 30 2a42: . . 系列0029 31 0b11: . . . セット0031 30 09 9: . . . . 系列0033 06 03 3: . . . . . OID2.5.4、.6: C: 55 04 06 0038 13 02 2: . . . . . PrintableString'米国': 55 53 0042 31 0c12: . . . セット0044 30 0a10: . . . . 系列0046 06 03 3: . . . . . OID2.5.4、.10: O: 55 04 0a0051 13 03 3: . . . . . PrintableString'gov': 67 6f76 0056 31 0d13: . . . セット0058 30 0b11: . . . . 系列0060 06 03 3: . . . . . OID2.5.4、.11: OU: 55 04 0b0065 13 04 4: . . . . . PrintableString'nist': 6e69 73 74 0071 30 1e30: . . 系列0073 17 0d13: . . . UTCTime'970630000000Z': 39 37 30 36 33 30 30 30 30 30 30 30 5a0088 17 0d13: . . . UTCTime'971231000000Z': 39 37 31 32 33 31 30 30 30 30 30 30 5a0103 30 2a42: . . 系列0105 31 0b11: . . . セット0107 30 09 9: . . . . 系列0109 06 03 3: . . . . . OID2.5.4、.6: C: 55 04 06 0114 13 02 2: . . . . . PrintableString'米国': 55 53 0118 31 0c12: . . . セット0120 30 0a10: . . . . 系列0122 06 03 3: . . . . . OID2.5.4、.10: O: 55 04 0a0127 13 03 3: . . . . . PrintableString'gov': 67 6f76 0132 31 0d13: . . . セット0134 30 0b11: . . . . 系列0136 06 03 3: . . . . . OID2.5.4、.11: OU: 55 04 0b0141 13 04 4: . . . . . PrintableString'nist': 6e69 73 74 0147 30 82 01b4 436: . . 系列0151 30 82 01 29 297: . . . 系列
Housley, et. al. Standards Track [Page 118] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[118ページ]。
0155 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa
: 2a 86 48 ce 38 04 01
0164 30 82 01 1c 284: . . . . SEQUENCE
0168 02 81 80 128: . . . . . INTEGER
: d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3
: 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2
: 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03
: 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6
: 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a
: 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be
: 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d
: f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d
0299 02 14 20: . . . . . INTEGER
: a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83
: 51 0d dc dd
0321 02 81 80 128: . . . . . INTEGER
: 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca
: 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90
: d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5
: a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb
: ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d
: a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42
: 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90
: cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d
0452 03 81 84 132: . . . BIT STRING (0 unused bits)
: 02 81 80 aa 98 ea 13 94 a2 db f1 5b 7f 98 2f 78
: e7 d8 e3 b9 71 86 f6 80 2f 40 39 c3 da 3b 4b 13
: 46 26 ee 0d 56 c5 a3 3a 39 b7 7d 33 c2 6b 5c 77
: 92 f2 55 65 90 39 cd 1a 3c 86 e1 32 eb 25 bc 91
: c4 ff 80 4f 36 61 bd cc e2 61 04 e0 7e 60 13 ca
: c0 9c dd e0 ea 41 de 33 c1 f1 44 a9 bc 71 de cf
: 59 d4 6e da 44 99 3c 21 64 e4 78 54 9d d0 7b ba
: 4e f5 18 4d 5e 39 30 bf e0 d1 f6 f4 83 25 4f 14
: aa 71 e1
0587 a3 32 50: . . [3]
0589 30 30 48: . . . SEQUENCE
0591 30 0f 9: . . . . SEQUENCE
0593 06 03 3: . . . . . OID 2.5.29.19: basicConstraints
: 55 1d 13
0598 01 01 1: . . . . . TRUE
: ff
0601 04 05 5: . . . . . OCTET STRING
: 30 03 01 01 ff
0608 30 1d 29: . SEQUENCE
0610 06 03 3: . . . . . OID 2.5.29.14: subjectKeyIdentifier
: 55 1d 0e
0615 04 16 22: . . . . . OCTET STRING
: 04 14 e7 26 c5 54 cd 5b a3 6f 35 68 95 aa d5 ff
0155 06 07 7: . . . . OID1.2.840、.10040、.4、.1: dsa: 2a86 48Ce38 04 01 0164 30 82 01 1c284: . . . . 系列0168 02 81 80 128: . . . . . 整数: d4 38 02c5 35 7b d5 0b a1 7e 5d72 59 63 55d3: 45 56ea e2 25 1a 6b c5 a4腹筋aa 0b d4 62b4 d2: 21 b1 95a2 c6 01c9 c3ファ01 6f79 86 83 3d03: 61 e1 f1 92ac bc03 4e89a3 c9 53 4a f7 e2 a6: 48Cf42 1e21b1 5c 2b 3a 7f Ba、6b 5a f7 0aになってください: 26d8 8e 1b eb ec bf 1e 5a 3f45c0 bd31 23、あります: 69 71a7 c2 90fe a5 d6 80b5 24dc44 9c eb 4d: f9 da f0 c8 e8 a2 4c99 07 5c 8e35 2b 7d57 8d0299 02 14 20: . . . . . 整数: a7 83 9b f3 bd 2c20 07fc 4c e7 e8 9f f3 39 83: 51 0d dc dd0321 02 81 80 128: . . . . . 整数: 0e 3b46 31 8a 0a58 86 40 84e3 a1 22 0d88ca: 90 88 57 64 9f01 21e0 15 05 94 24 82e2 10 90: d9 e1 4e10 5c e7 54 6b d4 0c 2b 1b59 0a a0 b5: a1 7d b5 07e3 65 7c ea90d8 8e30 42e4 85bb: acファ4e76 4b78 0e df 6c e5 a6 e1 bd59 77 7d: a6 97 59c5 29a7 b3 3f95 3e 9d f1 59 2d f7 42: 87 62 3f f1 b8 6f c7 3d 4b b8 8d74c4 ca44 90: Cf67db de14 60 97 4a d1 f7 6d 9e09 94c4 0d0452 03 81 84 132: . . . BIT STRING(未使用の0ビット): 02 81 80aa98ea13 94a2 db f1 5b 7f98 2f78: e7 d8 e3 b9 71 86f6 80 2f40 39c3 da 3b 4b13: 46 26ee 0d56c5 a3 3a39b7 7d33c2 6b 5c77: 92 f2 55 65 90 39cd 1a 3c86e1 32eb25bc91: c4ff80 4f36 61bd cc e2 61 04e0 7e60 13ca: c0 9c dd e0 ea41de33c1 f1 44a9 bc71de Cf: 59 d4 6e da44 99 3c21 64e4 78 54 9d d0 7b Ba: 4e f5 18 4d 5e39 30bf e0 d1 f6 f4 83 25 4f14: aa71e1 0587a3 32 50: . . [3] 0589 30 30 48: . . . 系列0591 30 0f9: . . . . 系列0593 06 03 3: . . . . . OID2.5.29、.19: basicConstraints: 55 1d13 0598 01 01 1: . . . . . 本当: ff0601 04 05 5: . . . . . 八重奏ストリング: 30 03 01 01ff0608 30 1d29: . 系列0610 06 03 3: . . . . . OID2.5.29、.14: subjectKeyIdentifier: 55 1d 0e0615 04 16 22: . . . . . 八重奏ストリング: 04 14e7 26c5 54cd 5b a3 6f35 68 95aa d5ff
Housley, et. al. Standards Track [Page 119] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[119ページ]。
: 1c 21 e4 22 75 d6
0639 30 09 9: . SEQUENCE
0641 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha
: 2a 86 48 ce 38 04 03
0650 03 2f 47: . BIT STRING (0 unused bits)
: 30 2c 02 14 a0 66 c1 76 33 99 13 51 8d 93 64 2f
: ca 13 73 de 79 1a 7d 33 02 14 5d 90 f6 ce 92 4a
: bf 29 11 24 80 28 a6 5a 8e 73 b6 76 02 68
: 1c21e4 22 75d6 0639 30 09 9: . 系列0641 06 07 7: . . OID1.2.840、.10040、.4、.3: shaとdsa: 2a86 48Ce38 04 03 0650 03 2f47: . BIT STRING(未使用の0ビット): 30 2c02 14a0 66c1 76 33 99 13 51 8d93 64 2f: ca13 73de79 1a 7d33 02 14 5d90f6Ce92 4a: bf29 11 24 80 28a6 5a 8e73b6 76 02 68
D.2 Certificate
D.2証明書
This section contains an annotated hex dump of a 730 byte version 3 certificate. The certificate contains the following information: (a) the serial number is 18 (12 hex); (b) the certificate is signed with DSA and the SHA-1 hash algorithm; (c) the issuer's distinguished name is OU=nist; O=gov; C=US (d) and the subject's distinguished name is CN=Tim Polk; OU=nist; O=gov; C=US (e) the certificate was valid from July 30, 1997 through December 1, 1997; (f) the certificate contains a 1024 bit DSA public key; (g) the certificate is an end entity certificate, as the basic constraints extension is not present; (h) the certificate contains an authority key identifier extension; and (i) the certificate includes one alternative name - an RFC 822 address.
このセクションは730バイトのバージョン3証明書の注釈された十六進法ダンプを含みます。 証明書は以下の情報を含んでいます: (a) 通し番号は18(12十六進法)です。 (b) 証明書はDSAとSHA-1細切れ肉料理アルゴリズムを契約されます。 (c) 発行人の分類名はOU=nistです。 O=gov。 CはU.S.(d)と等しいです、そして、対象の分類名はティム・CN=ポークです。 OU=nist。 O=gov。 Cは1997年7月30日から1997年12月1日まで証明書が有効であった米国(e)と等しいです。 (f) 証明書は1024年のビットのDSA公開鍵を含んでいます。 (g) 基本的な規制拡大が存在していないとき、証明書は終わりの実体証明書です。 (h) 証明書は権威の主要な識別子拡張子を含んでいます。 (i) そして、証明書は1つの代替名を含んでいます--RFC822アドレス。
0000 30 82 02 d6 726: SEQUENCE
0004 30 82 02 96 662: . SEQUENCE
0008 a0 03 3: . . [0]
0010 02 01 1: . . . INTEGER 2
: 02
0013 02 01 1: . . INTEGER 18
: 12
0016 30 09 9: . . SEQUENCE
0018 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha
: 2a 86 48 ce 38 04 03
0027 30 2a 42: . . SEQUENCE
0029 31 0b 11: . . . SET
0031 30 09 9: . . . . SEQUENCE
0033 06 03 3: . . . . . OID 2.5.4.6: C
: 55 04 06
0038 13 02 2: . . . . . PrintableString 'US'
: 55 53
0042 31 0c 12: . . . SET
0044 30 0a 10: . . . . SEQUENCE
0046 06 03 3: . . . . . OID 2.5.4.10: O
0000 30 82 02d6 726: 系列0004 30 82 02 96 662: . SEQUENCE0008a0 03 3: . . [0] 0010 02 01 1: . . . 整数2: 02 0013 02 01 1: . . 整数18: 12 0016 30 09 9: . . 系列0018 06 07 7: . . . OID1.2.840、.10040、.4、.3: shaとdsa: 2a86 48Ce38 04 03 0027 30 2a42: . . 系列0029 31 0b11: . . . セット0031 30 09 9: . . . . 系列0033 06 03 3: . . . . . OID2.5.4、.6: C: 55 04 06 0038 13 02 2: . . . . . PrintableString'米国': 55 53 0042 31 0c12: . . . セット0044 30 0a10: . . . . 系列0046 06 03 3: . . . . . OID2.5.4、.10: O
Housley, et. al. Standards Track [Page 120] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[120ページ]。
: 55 04 0a
0051 13 03 3: . . . . . PrintableString 'gov'
: 67 6f 76
0056 31 0d 13: . . . SET
0058 30 0b 11: . . . . SEQUENCE
0060 06 03 3: . . . . . OID 2.5.4.11: OU
: 55 04 0b
0065 13 04 4: . . . . . PrintableString 'nist'
: 6e 69 73 74
0071 30 1e 30: . . SEQUENCE
0073 17 0d 13: . . . UTCTime '970730000000Z'
: 39 37 30 37 33 30 30 30 30 30 30 30 5a
0088 17 0d 13: . . . UTCTime '971201000000Z'
: 39 37 31 32 30 31 30 30 30 30 30 30 5a
0103 30 3d 61: . . SEQUENCE
0105 31 0b 11: . . . SET
0107 30 09 9: . . . . SEQUENCE
0109 06 03 3: . . . . . OID 2.5.4.6: C
: 55 04 06
0114 13 02 2: . . . . . PrintableString 'US'
: 55 53
0118 31 0c 12: . . . SET
0120 30 0a 10: . . . . SEQUENCE
0122 06 03 3: . . . . . OID 2.5.4.10: O
: 55 04 0a
0127 13 03 3: . . . . . PrintableString 'gov'
: 67 6f 76
0132 31 0d 13: . . . SET
0134 30 0b 11: . . . . SEQUENCE
0136 06 03 3: . . . . . OID 2.5.4.11: OU
: 55 04 0b
0141 13 04 4: . . . . . PrintableString 'nist'
: 6e 69 73 74
0147 31 11 17: . . . SET
0149 30 0f 15: . . . . SEQUENCE
0151 06 03 3: . . . . . OID 2.5.4.3: CN
: 55 04 03
0156 13 08 8: . . . . . PrintableString 'Tim Polk'
: 54 69 6d 20 50 6f 6c 6b
0166 30 82 01 b4 436: . . SEQUENCE
0170 30 82 01 29 297: . . . SEQUENCE
0174 06 07 7: . . . . OID 1.2.840.10040.4.1: dsa
: 2a 86 48 ce 38 04 01
0183 30 82 01 1c 284: . . . . SEQUENCE
0187 02 81 80 128: . . . . . INTEGER
: d4 38 02 c5 35 7b d5 0b a1 7e 5d 72 59 63 55 d3
: 45 56 ea e2 25 1a 6b c5 a4 ab aa 0b d4 62 b4 d2
: 21 b1 95 a2 c6 01 c9 c3 fa 01 6f 79 86 83 3d 03
: 55 04 0a0051 13 03 3: . . . . . PrintableString'gov': 67 6f76 0056 31 0d13: . . . セット0058 30 0b11: . . . . 系列0060 06 03 3: . . . . . OID2.5.4、.11: OU: 55 04 0b0065 13 04 4: . . . . . PrintableString'nist': 6e69 73 74 0071 30 1e30: . . 系列0073 17 0d13: . . . UTCTime'970730000000Z': 39 37 30 37 33 30 30 30 30 30 30 30 5a0088 17 0d13: . . . UTCTime'971201000000Z': 39 37 31 32 30 31 30 30 30 30 30 30 5a0103 30 3d61: . . 系列0105 31 0b11: . . . セット0107 30 09 9: . . . . 系列0109 06 03 3: . . . . . OID2.5.4、.6: C: 55 04 06 0114 13 02 2: . . . . . PrintableString'米国': 55 53 0118 31 0c12: . . . セット0120 30 0a10: . . . . 系列0122 06 03 3: . . . . . OID2.5.4、.10: O: 55 04 0a0127 13 03 3: . . . . . PrintableString'gov': 67 6f76 0132 31 0d13: . . . セット0134 30 0b11: . . . . 系列0136 06 03 3: . . . . . OID2.5.4、.11: OU: 55 04 0b0141 13 04 4: . . . . . PrintableString'nist': 6e69 73 74 0147 31 11 17: . . . セット0149 30 0f15: . . . . 系列0151 06 03 3: . . . . . OID2.5.4、.3: CN: 55 04 03 0156 13 08 8: . . . . . PrintableString'ティム・ポーク': 54 69 6d20 50 6f 6c 6b0166 30 82 01b4 436: . . 系列0170 30 82 01 29 297: . . . 系列0174 06 07 7: . . . . OID1.2.840、.10040、.4、.1: dsa: 2a86 48Ce38 04 01 0183 30 82 01 1c284: . . . . 系列0187 02 81 80 128: . . . . . 整数: d4 38 02c5 35 7b d5 0b a1 7e 5d72 59 63 55d3: 45 56ea e2 25 1a 6b c5 a4腹筋aa 0b d4 62b4 d2: 21 b1 95a2 c6 01c9 c3ファ01 6f79 86 83 3d03
Housley, et. al. Standards Track [Page 121] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[121ページ]。
: 61 e1 f1 92 ac bc 03 4e 89 a3 c9 53 4a f7 e2 a6
: 48 cf 42 1e 21 b1 5c 2b 3a 7f ba be 6b 5a f7 0a
: 26 d8 8e 1b eb ec bf 1e 5a 3f 45 c0 bd 31 23 be
: 69 71 a7 c2 90 fe a5 d6 80 b5 24 dc 44 9c eb 4d
: f9 da f0 c8 e8 a2 4c 99 07 5c 8e 35 2b 7d 57 8d
0318 02 14 20: . . . . . INTEGER
: a7 83 9b f3 bd 2c 20 07 fc 4c e7 e8 9f f3 39 83
: 51 0d dc dd
0340 02 81 80 128: . . . . . INTEGER
: 0e 3b 46 31 8a 0a 58 86 40 84 e3 a1 22 0d 88 ca
: 90 88 57 64 9f 01 21 e0 15 05 94 24 82 e2 10 90
: d9 e1 4e 10 5c e7 54 6b d4 0c 2b 1b 59 0a a0 b5
: a1 7d b5 07 e3 65 7c ea 90 d8 8e 30 42 e4 85 bb
: ac fa 4e 76 4b 78 0e df 6c e5 a6 e1 bd 59 77 7d
: a6 97 59 c5 29 a7 b3 3f 95 3e 9d f1 59 2d f7 42
: 87 62 3f f1 b8 6f c7 3d 4b b8 8d 74 c4 ca 44 90
: cf 67 db de 14 60 97 4a d1 f7 6d 9e 09 94 c4 0d
0471 03 81 84 132: . . . BIT STRING (0 unused bits)
: 02 81 80 a8 63 b1 60 70 94 7e 0b 86 08 93 0c 0d
: 08 12 4a 58 a9 af 9a 09 38 54 3b 46 82 fb 85 0d
: 18 8b 2a 77 f7 58 e8 f0 1d d2 18 df fe e7 e9 35
: c8 a6 1a db 8d 3d 3d f8 73 14 a9 0b 39 c7 95 f6
: 52 7d 2d 13 8c ae 03 29 3c 4e 8c b0 26 18 b6 d8
: 11 1f d4 12 0c 13 ce 3f f1 c7 05 4e df e1 fc 44
: fd 25 34 19 4a 81 0d dd 98 42 ac d3 b6 91 0c 7f
: 16 72 a3 a0 8a d7 01 7f fb 9c 93 e8 99 92 c8 42
: 47 c6 43
0606 a3 3e 62: . . [3]
0608 30 3c 60: . . . SEQUENCE
0610 30 19 25: . . . . SEQUENCE
0612 06 03 3: . . . . . OID 2.5.29.17: subjectAltName
: 55 1d 11
0617 04 12 18: . . . . . OCTET STRING
: 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67
: 6f 76
0637 30 1f 31: . . . . SEQUENCE
0639 06 03 3: . . . . . OID 2.5.29.35: subjectAltName
: 55 1d 23
0644 04 18 24: . . . . . OCTET STRING
: 30 16 80 14 e7 26 c5 54 cd 5b a3 6f 35 68 95 aa
: d5 ff 1c 21 e4 22 75 d6
0670 30 09 9: . SEQUENCE
0672 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha
: 2a 86 48 ce 38 04 03
0681 03 2f 47: . BIT STRING (0 unused bits)
: 30 2c 02 14 3c 02 e0 ab d9 5d 05 77 75 15 71 58
: 92 29 48 c4 1c 54 df fc 02 14 5b da 53 98 7f c5
: 33 df c6 09 b2 7a e3 6f 97 70 1e 14 ed 94
: 61 e1 f1 92ac bc03 4e89a3 c9 53 4a f7 e2 a6: 48Cf42 1e21b1 5c 2b 3a 7f Ba、6b 5a f7 0aになってください: 26d8 8e 1b eb ec bf 1e 5a 3f45c0 bd31 23、あります: 69 71a7 c2 90fe a5 d6 80b5 24dc44 9c eb 4d: f9 da f0 c8 e8 a2 4c99 07 5c 8e35 2b 7d57 8d0318 02 14 20: . . . . . 整数: a7 83 9b f3 bd 2c20 07fc 4c e7 e8 9f f3 39 83: 51 0d dc dd0340 02 81 80 128: . . . . . 整数: 0e 3b46 31 8a 0a58 86 40 84e3 a1 22 0d88ca: 90 88 57 64 9f01 21e0 15 05 94 24 82e2 10 90: d9 e1 4e10 5c e7 54 6b d4 0c 2b 1b59 0a a0 b5: a1 7d b5 07e3 65 7c ea90d8 8e30 42e4 85bb: acファ4e76 4b78 0e df 6c e5 a6 e1 bd59 77 7d: a6 97 59c5 29a7 b3 3f95 3e 9d f1 59 2d f7 42: 87 62 3f f1 b8 6f c7 3d 4b b8 8d74c4 ca44 90: Cf67db de14 60 97 4a d1 f7 6d 9e09 94c4 0d0471 03 81 84 132: . . . BIT STRING(未使用の0ビット): 02 81 80a8 63b1 60 70 94 7e 0b86 08 93 0c 0d: 08 12 4a58a9 af 9a09 38 54 3b46 82fb85 0d: 18 8b 2a77f7 58e8 f0 1d d2 18df fe e7 e9 35: c8 a6 1a db 8d 3d 3d f8 73 14a9 0b39c7 95f6: 52 7d 2d13 8c ae03 29 3c 4e 8c b0 26 18b6 d8: 11 1f d4 12 0c13Ce3f f1 c7 05 4e df e1 fc44: fd25 34 19 4a81 0d dd98 42ac d3 b6 91 0c 7f: 16 72a3 a0 8a d7 01 7f fb 9c93e8 99 92c8 42: 47 c6 43 0606a3 3e62: . . [3] 0608 30 3c60: . . . 系列0610 30 19 25: . . . . 系列0612 06 03 3: . . . . . OID2.5.29、.17: subjectAltName: 55 1d11 0617 04 12 18: . . . . . 八重奏ストリング: 30 10 81 0e77 70 6f 6c 6b40 6e69 73 74 2e67: 6f76 0637 30 1f31: . . . . 系列0639 06 03 3: . . . . . OID2.5.29、.35: subjectAltName: 55 1d23 0644 04 18 24: . . . . . 八重奏ストリング: 30 16 80 14e7 26c5 54cd 5b a3 6f35 68 95aa: d5ff1c21e4 22 75d6 0670 30 09 9: . 系列0672 06 07 7: . . OID1.2.840、.10040、.4、.3: shaとdsa: 2a86 48Ce38 04 03 0681 03 2f47: . BIT STRING(未使用の0ビット): 30 2c02 14 3c02e0腹筋d9 5d05 77 75 15 71 58: 92 29 48c4 1c54df fc02 14 5b da53 98 7f c5: 33 df c6 09b2 7a e3 6f97 70 1e14教育94
Housley, et. al. Standards Track [Page 122] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[122ページ]。
D.3 End-Entity Certificate Using RSA
RSAを使用するD.3終わり実体証明書
This section contains an annotated hex dump of a 675 byte version 3 certificate. The certificate contains the following information: (a) the serial number is 256; (b) the certificate is signed with RSA and the MD2 hash algorithm; (c) the issuer's distinguished name is OU=Dept. Arquitectura de Computadors; O=Universitat Politecnica de Catalunya; C=ES (d) and the subject's distinguished name is CN=Francisco Jordan; OU=Dept. Arquitectura de Computadors; O=Universitat Politecnica de Catalunya; C=ES (e) the certificate was issued on May 21, 1996 and expired on May 21, 1997; (f) the certificate contains a 768 bit RSA public key; (g) the certificate is an end entity certificate (not a CA certificate); (h) the certificate includes an alternative subject name and an alternative issuer name - bothe are URLs; (i) the certificate include an authority key identifier and certificate policies extensions; and (j) the certificate includes a critical key usage extension specifying the public is intended for generation of digital signatures.
このセクションは675バイトのバージョン3証明書の注釈された十六進法ダンプを含みます。 証明書は以下の情報を含んでいます: (a) 通し番号は256です。 (b) 証明書はRSAとMD2細切れ肉料理アルゴリズムを契約されます。 (c) 発行人の分類名はOU=部です。 Arquitectura de Computadors。 O=Universitat Politecnica deカタルニア。 CはES(d)と等しいです、そして、対象の分類名はフランシスコCN=ジョーダンです。 OUは部と等しいです。 Arquitectura de Computadors。 O=Universitat Politecnica deカタルニア。 Cは1997年5月21日の証明書が1996年5月21日に発行されて、吐き出されたES(e)と等しいです。 (f) 証明書は768ビットのRSA公開鍵を含んでいます。 (g) 証明書は終わりの実体証明書(カリフォルニア証明書でない)です。 (h) 証明書は代替の対象の名前と代替の発行人名を含んでいます--botheはURLです。 (i) 証明書は権威の主要な識別子と証明書方針拡張子を含んでいます。 (j) そして、証明書は公衆を指定する主要な用法拡大がデジタル署名の世代のために意図することに批判的なaを含んでいます。
0000 30 80 : SEQUENCE (size undefined)
0002 30 82 02 40 576: . SEQUENCE
0006 a0 03 3: . . [0]
0008 02 01 1: . . . INTEGER 2
: 02
0011 02 02 2: . . INTEGER 256
: 01 00
0015 30 0d 13: . . SEQUENCE
0017 06 09 9: . . . OID 1.2.840.113549.1.1.2:
MD2WithRSAEncryption
: 2a 86 48 86 f7 0d 01 01 02
0028 05 00 0: . . . NULL
0030 30 68 88: . . SEQUENCE
0032 31 0b 11: . . . SET
0034 30 09 9: . . . . SEQUENCE
0036 06 03 3: . . . . . OID 2.5.4.6: C
: 55 04 06
0041 13 02 2: . . . . . PrintableString 'ES'
: 45 53
0045 31 2d 45: . . . SET
0047 30 2b 43: . . . . SEQUENCE
0049 06 03 3: . . . . . OID 2.5.4.10: O
: 55 04 0a
0054 13 24 36: . . . . . PrintableString
0000 30 80 : SEQUENCE(サイズ未定義の)0002 30 82 02 40 576: . SEQUENCE0006a0 03 3: . . [0] 0008 02 01 1: . . . 整数2: 02 0011 02 02 2: . . 整数256: 01 00 0015 30 0d13: . . 系列0017 06 09 9: . . . OID1.2.840、.113549、.1、.1、.2: MD2WithRSAEncryption: 2a86 48 86f7 0d01 01 02 0028 05 00 0: . . . ヌル0030 30 68 88: . . 系列0032 31 0b11: . . . セット0034 30 09 9: . . . . 系列0036 06 03 3: . . . . . OID2.5.4、.6: C: 55 04 06 0041 13 02 2: . . . . . PrintableString'ES': 45 53 0045 31 2d45: . . . セット0047 30 2b43: . . . . 系列0049 06 03 3: . . . . . OID2.5.4、.10: O: 55 04 0a0054 13 24 36: . . . . . PrintableString
Housley, et. al. Standards Track [Page 123] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[123ページ]。
'Universitat Politecnica de Catalunya'
: 55 6e 69 76 65 72 73 69 74 61 74 20 50 6f 6c 69
: 74 65 63 6e 69 63 61 20 64 65 20 43 61 74 61 6c
: 75 6e 79 61
0092 31 2a 42: . . . SET
0094 30 28 40: . . . . SEQUENCE
0096 06 03 3: . . . . . OID 2.5.4.11: OU
: 55 04 0b
0101 13 21 33: . . . . . PrintableString
'OU=Dept. Arquitectura de Computadors'
: 44 65 70 74 2e 20 41 72 71 75 69 74 65 63 74 75
: 72 61 20 64 65 20 43 6f 6d 70 75 74 61 64 6f 72
: 73
0136 30 1e 30: . . SEQUENCE
0138 17 0d 13: . . . UTCTime '960521095826Z'
: 39 36 30 37 32 32 31 37 33 38 30 32 5a
0153 17 0d 13: . . . UTCTime '979521095826Z'
: 39 37 30 37 32 32 31 37 33 38 30 32 5a
0168 30 81 83 112: . . SEQUENCE
0171 31 0b 11: . . . SET
0173 30 09 9: . . . . SEQUENCE
0175 06 03 3: . . . . . OID 2.5.4.6: C
: 55 04 06
0180 13 02 2: . . . . . PrintableString 'ES'
: 45 53
0184 31 2d 12: . . . SET
0186 30 2b 16: . . . . SEQUENCE
0188 06 03 3: . . . . . OID 2.5.4.10: O
: 55 04 0a
0193 13 24 36: . . . . . PrintableString
'Universitat Politecnica de Catalunya'
: 55 6e 69 76 65 72 73 69 74 61 74 20 50 6f 6c 69
: 74 65 63 6e 69 63 61 20 64 65 20 43 61 74 61 6c
: 75 6e 79 61
0231 31 2a 42: . . . SET
0233 30 28 40: . . . . SEQUENCE
0235 06 03 3: . . . . . OID 2.5.4.11: OU
: 55 04 0b
0240 13 21 33: . . . . . PrintableString
'Dept. Arquitectura de Computadors'
: 44 65 70 74 2e 20 41 72 71 75 69 74 65 63 74 75
: 72 61 20 64 65 20 43 6f 6d 70 75 74 61 64 6f 72
: 73
0275 31 19 22: . . . SET
0277 30 17 20: . . . . SEQUENCE
0279 06 03 3: . . . . . OID 2.5.4.3: CN
: 55 04 03
0284 13 10 16: . . . . . PrintableString 'Francisco Jordan'
'Universitat Politecnica deカタルニア': 55 6e69 76 65 72 73 69 74 61 74 20 50 6f 6c69: 74 65 63 6e69 63 61 20 64 65 20 43 61 74 61 6c: 75 6e79 61 0092 31 2a42: . . . セット0094 30 28 40: . . . . 系列0096 06 03 3: . . . . . OID2.5.4、.11: OU: 55 04 0b0101 13 21 33: . . . . . PrintableString'OU=部' Arquitectura de Computadors: 44 65 70 74 2e20 41 72 71 75 69 74 65 63 74 75: 72 61 20 64 65 20 43 6f 6d70 75 74 61 64 6f72: 73 0136 30 1e30: . . 系列0138 17 0d13: . . . UTCTime'960521095826Z': 39 36 30 37 32 32 31 37 33 38 30 32 5a0153 17 0d13: . . . UTCTime'979521095826Z': 39 37 30 37 32 32 31 37 33 38 30 32 5a0168 30 81 83 112: . . 系列0171 31 0b11: . . . セット0173 30 09 9: . . . . 系列0175 06 03 3: . . . . . OID2.5.4、.6: C: 55 04 06 0180 13 02 2: . . . . . PrintableString'ES': 45 53 0184 31 2d12: . . . セット0186 30 2b16: . . . . 系列0188 06 03 3: . . . . . OID2.5.4、.10: O: 55 04 0a0193 13 24 36: . . . . . PrintableString'Universitat Politecnica deカタルニア': 55 6e69 76 65 72 73 69 74 61 74 20 50 6f 6c69: 74 65 63 6e69 63 61 20 64 65 20 43 61 74 61 6c: 75 6e79 61 0231 31 2a42: . . . セット0233 30 28 40: . . . . 系列0235 06 03 3: . . . . . OID2.5.4、.11: OU: 55 04 0b0240 13 21 33: . . . . . PrintableString'部' Arquitectura de Computadors: 44 65 70 74 2e20 41 72 71 75 69 74 65 63 74 75: 72 61 20 64 65 20 43 6f 6d70 75 74 61 64 6f72: 73 0275 31 19 22: . . . セット0277 30 17 20: . . . . 系列0279 06 03 3: . . . . . OID2.5.4、.3: CN: 55 04 03 0284 13 10 16: . . . . . PrintableString'フランシスコジョーダン'
Housley, et. al. Standards Track [Page 124] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[124ページ]。
: 46 72 61 6e 63 69 73 63 6f 20 4a 6f 72 64 61 6e
0302 30 7c 2: . . SEQUENCE
0304 30 0d 13: . . . SEQUENCE
0306 06 09 9: . . . . OID 1.2.840.113549.1.1.1: RSAEncryption
: 2a 86 48 86 f7 0d 01 01 01
0317 05 00 0: . . . . NULL
0319 03 6b 107: . . . BIT STRING
: 00 (0 unused bits)
: 30 68 02 61 00 be aa 8b 77 54 a3 af ca 77 9f 2f
: b0 cf 43 88 ff a6 6d 79 55 5b 61 8c 68 ec 48 1e
: 8a 86 38 a4 fe 19 b8 62 17 1d 9d 0f 47 2c ff 63
: 8f 29 91 04 d1 52 bc 7f 67 b6 b2 8f 74 55 c1 33
: 21 6c 8f ab 01 95 24 c8 b2 73 93 9d 22 61 50 a9
: 35 fb 9d 57 50 32 ef 56 52 50 93 ab b1 88 94 78
: 56 15 c6 1c 8b 02 03 01 00 01
0428 a3 81 97 151: . . [3]
0431 30 3c 60: . . . SEQUENCE
0433 30 1f 31: . . . . SEQUENCE
0435 06 03 3: . . . . . OID 2.5.29.35: authorityKeyIdentifier
: 55 1d 23
0440 04 14 22: . . . . . OCTET STRING
: 30 12 80 10 0e 6b 3a bf 04 ea 04 c3 0e 6b 3a bf
: 04 ea 04 c3
0464 30 19 25: . . . . SEQUENCE
0466 06 03 3: . . . . . OID 2.5.29.15: keyUsage
: 55 1d 0f
0471 01 01 1: . . . . . TRUE
0474 04 04 4: . . . . . OCTET STRING
: 03 02 07 80
0480 30 19 25: . . . . SEQUENCE
0482 06 03 3: . . . . . OID 2.5.29.32: certificatePolicies
: 55 1d 20
0487 04 21 33: . . . . . OCTET STRING
: 30 1f 30 1d 06 04 2a 84 80 00 30 15 30 07 06 05
: 2a 84 80 00 01 30 0a 06 05 2a 84 80 00 02 02 01
: 0a
0522 30 1c 28: . . . . SEQUENCE
0524 06 03 3: . . . . . OID 2.5.29.17: subjectAltName
: 55 1d 11
0529 04 15 21: . . . . . OCTET STRING
: 30 13 86 11 68 74 74 70 3a 2f 2f 61 63 2e 75 70
: 63 2e 65 73 2f
0552 30 19 25: . . . . SEQUENCE
0554 06 03 3: . . . . . OID 2.5.29.18: issuerAltName
: 55 1d 12
0559 04 12 18: . . . . . OCTET STRING
: 30 14 86 12 68 74 74 70 3a 2f 2f 77 77 77 2e 75
: 70 63 2e 65
: 46 72 61 6e63 69 73 63 6f20 4a 6f72 64 61 6e0302 30 7c2: . . 系列0304 30 0d13: . . . 系列0306 06 09 9: . . . . OID1.2.840、.113549、.1、.1、.1: RSAEncryption: 2a86 48 86f7 0d01 01 01 0317 05 00 0: . . . . ヌル0319 03 6b107: . . . ビット列: 00 (未使用の0ビット): 30 68 02 61 00、aa 8b77 54a3 af ca77 9f 2fになってください: b0Cf43 88ff a6 6d79 55 5b61 8c68ec48 1e: 8a86 38a4 fe19b8 62 17 1d 9d 0f47 2c ff63: 8f29 91 04d1 52bc 7f67b6 b2 8f74 55c1 33: 21 6c 8f腹筋01 95 24c8 b2 73 93 9d22 61 50a9: 35 fb 9d57 50 32ef56 52 50 93腹筋b1 88 94 78: 56 15c6 1c 8b02 03 01 00 01 0428a3 81 97 151: . . [3] 0431 30 3c60: . . . 系列0433 30 1f31: . . . . 系列0435 06 03 3: . . . . . OID2.5.29、.35: authorityKeyIdentifier: 55 1d23 0440 04 14 22: . . . . . 八重奏ストリング: 30 12 80 10 0e 6b 3a bf04ea04c3 0e 6b 3a bf: 04 ea04c3 0464 30 19 25: . . . . 系列0466 06 03 3: . . . . . OID2.5.29、.15: keyUsage: 55 1d 0f0471 01 01 1: . . . . . 本当の0474 04 04、4: . . . . . 八重奏ストリング: 03 02 07 80 0480 30 19 25: . . . . 系列0482 06 03 3: . . . . . OID2.5.29、.32: certificatePolicies: 55 1d20 0487 04 21 33: . . . . . 八重奏ストリング: 30 1f30 1d06 04 2a84 80 00 30 15 30 07 06 05: 2a84 80 00 01 30 0a06 05 2a84 80 00 02 02 01: 0a0522 30 1c28: . . . . 系列0524 06 03 3: . . . . . OID2.5.29、.17: subjectAltName: 55 1d11 0529 04 15 21: . . . . . 八重奏ストリング: 30 13 86 11 68 74 74 70 3a 2f 2f61 63 2e75 70: 63 2e65 73 2f0552 30 19 25: . . . . 系列0554 06 03 3: . . . . . OID2.5.29、.18: issuerAltName: 55 1d12 0559 04 12 18: . . . . . 八重奏ストリング: 30 14 86 12 68 74 74 70 3a 2f 2f77 77 77 2e75: 70 63 2e65
Housley, et. al. Standards Track [Page 125] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[125ページ]。
0579 30 80 : . SEQUENCE (indefinite length)
0581 06 07 7: . . OID
0583 05 00 0: . . NULL
0585 00 00 0: . . end of contents marker
0587 03 81 81 47: . BIT STRING
: 00 (0 unused bits)
: 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04 ea
: 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a ab
: eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c 91
: a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6 50
: 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04 ea
: 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a ab
: eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c 91
: a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6 50
0637 00 00 0: . . end of contents marker
0579 30 80 : . SEQUENCE(無期長さ)0581 06 07 7: . . OID0583 05 00 0: . . ヌル0585 00 00 0: . . コンテンツマーカー0587 03 81 81 47の端: . ビット列: 00 (未使用の0ビット): 5c01bd b5 41 88 87 7a 0e d3 0e 6b 3a bf04ea: 04 cb 5f61 72 3c a3 bd78f5 66 17fe37 3a腹筋: eb67bf b7 da a8 38f6 33 15 71 75 2f b9 8c91: a0 e4 87Ba4b43a0 22 8f d3 a9 86 43 89e6 50: 5c01bd b5 41 88 87 7a 0e d3 0e 6b 3a bf04ea: 04 cb 5f61 72 3c a3 bd78f5 66 17fe37 3a腹筋: eb67bf b7 da a8 38f6 33 15 71 75 2f b9 8c91: a0 e4 87Ba4b43a0 22 8f d3 a9 86 43 89e6 50 0637 00 00 0: . . コンテンツマーカーの端
D.4 Certificate Revocation List
D.4証明書取消しリスト
This section contains an annotated hex dump of a version 2 CRL with one extension (cRLNumber). The CRL was issued by OU=nist;O=gov;C=us on July 7, 1996; the next scheduled issuance was August 7, 1996. The CRL includes one revoked certificates: serial number 18 (12 hex). The CRL itself is number 18, and it was signed with DSA and SHA-1.
このセクションは1つの拡大(cRLNumber)によるバージョン2CRLの注釈された十六進法ダンプを含みます。 CRLは1996年7月7日にOU=nist; O=gov; C=私たちによって発行されました。 次の予定されている発行は1996年8月7日でした。 CRLは1通の取り消された証明書を含んでいます: 通し番号18(12十六進法)。 CRL自身はNo.18です、そして、それはDSAとSHA-1を契約されました。
0000 30 81 ba 186: SEQUENCE
0003 30 7c 124: . SEQUENCE
0005 02 01 1: . . INTEGER 1
: 01
0008 30 09 9: . . SEQUENCE
0010 06 07 7: . . . OID 1.2.840.10040.4.3: dsa-with-sha
: 2a 86 48 ce 38 04 03
0019 30 2a 42: . . SEQUENCE
0021 31 0b 11: . . . SET
0023 30 09 9: . . . . SEQUENCE
0025 06 03 3: . . . . . OID 2.5.4.6: C
: 55 04 06
0030 13 02 2: . . . . . PrintableString 'US'
: 55 53
0034 31 0c 12: . . . SET
0036 30 0a 10: . . . . SEQUENCE
0038 06 03 3: . . . . . OID 2.5.4.10: O
: 55 04 0a
0043 13 03 3: . . . . . PrintableString 'gov'
: 67 6f 76
0048 31 0d 13: . . . SET
0050 30 0b 11: . . . . SEQUENCE
0052 06 03 3: . . . . . OID 2.5.4.11: OU
: 55 04 0b
0000 30 81Ba186: 系列0003 30 7c124: . 系列0005 02 01 1: . . 整数1: 01 0008 30 09 9: . . 系列0010 06 07 7: . . . OID1.2.840、.10040、.4、.3: shaとdsa: 2a86 48Ce38 04 03 0019 30 2a42: . . 系列0021 31 0b11: . . . セット0023 30 09 9: . . . . 系列0025 06 03 3: . . . . . OID2.5.4、.6: C: 55 04 06 0030 13 02 2: . . . . . PrintableString'米国': 55 53 0034 31 0c12: . . . セット0036 30 0a10: . . . . 系列0038 06 03 3: . . . . . OID2.5.4、.10: O: 55 04 0a0043 13 03 3: . . . . . PrintableString'gov': 67 6f76 0048 31 0d13: . . . セット0050 30 0b11: . . . . 系列0052 06 03 3: . . . . . OID2.5.4、.11: OU: 55 04 0b
Housley, et. al. Standards Track [Page 126] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[126ページ]。
0057 13 04 4: . . . . . PrintableString 'nist'
: 6e 69 73 74
0063 17 0d 13: . . UTCTime '970801000000Z'
: 39 37 30 38 30 31 30 30 30 30 30 30 5a
0078 17 0d 13: . . UTCTime '970808000000Z'
: 39 37 30 38 30 38 30 30 30 30 30 30 5a
0093 30 22 34: . . SEQUENCE
0095 30 20 32: . . . SEQUENCE
0097 02 01 1: . . . . INTEGER 18
: 12
0100 17 0d 13: . . . . UTCTime '970731000000Z'
: 39 37 30 37 33 31 30 30 30 30 30 30 5a
0115 30 0c 12: . . . . SEQUENCE
0117 30 0a 10: . . . . . SEQUENCE
0119 06 03 3: . . . . . . OID 2.5.29.21: reasonCode
: 55 1d 15
0124 04 03 3: . . . . . . OCTET STRING
: 0a 01 01
0129 30 09 9: . SEQUENCE
0131 06 07 7: . . OID 1.2.840.10040.4.3: dsa-with-sha
: 2a 86 48 ce 38 04 03
0140 03 2f 47: . BIT STRING (0 unused bits)
: 30 2c 02 14 9e d8 6b c1 7d c2 c4 02 f5 17 84 f9
: 9f 46 7a ca cf b7 05 8a 02 14 9e 43 39 85 dc ea
: 14 13 72 93 54 5d 44 44 e5 05 fe 73 9a b2
0057 13 04 4: . . . . . PrintableString'nist': 6e69 73 74 0063 17 0d13: . . UTCTime'970801000000Z': 39 37 30 38 30 31 30 30 30 30 30 30 5a0078 17 0d13: . . UTCTime'970808000000Z': 39 37 30 38 30 38 30 30 30 30 30 30 5a0093 30 22 34: . . 系列0095 30 20 32: . . . 系列0097 02 01 1: . . . . 整数18: 12 0100 17 0d13: . . . . UTCTime'970731000000Z': 39 37 30 37 33 31 30 30 30 30 30 30 5a0115 30 0c12: . . . . 系列0117 30 0a10: . . . . . 系列0119 06 03 3: . . . . . . OID2.5.29、.21: reasonCode: 55 1d15 0124 04 03 3: . . . . . . 八重奏ストリング: 0a01 01 0129 30 09 9: . 系列0131 06 07 7: . . OID1.2.840、.10040、.4、.3: shaとdsa: 2a86 48Ce38 04 03 0140 03 2f47: . BIT STRING(未使用の0ビット): 30 2c02 14 9e d8 6b c1 7d c2 c4 02f5 17 84f9: 9f46 7a ca Cf b7 05 8a02 14 9e43 39 85dc ea: 14 13 72 93 54 5d44 44e5 05fe73 9a b2
Housley, et. al. Standards Track [Page 127] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[127ページ]。
Appendix E. Authors' Addresses
付録E.作者のアドレス
Russell Housley SPYRUS 381 Elden Street Suite 1120 Herndon, VA 20170 USA
ラッセルHousley SPYRUS381エルデン・通りスイート1120ヴァージニア20170ハーンドン(米国)
EMail: housley@spyrus.com
メール: housley@spyrus.com
Warwick Ford VeriSign, Inc. One Alewife Center Cambridge, MA 02140 USA
ウォリックフォードベリサインエールワイフセンターケンブリッジ、Inc.1つのMA02140米国
EMail: wford@verisign.com
メール: wford@verisign.com
Tim Polk NIST Building 820, Room 426 Gaithersburg, MD 20899 USA
MD20899ゲイザースバーグ(米国)を820、部屋426に造るティムポークNIST
EMail: wpolk@nist.gov
メール: wpolk@nist.gov
David Solo Citicorp 666 Fifth Ave, 3rd Floor New York, NY 10103 USA
デヴィッドのソロのシティコープ666第5Ave、第3Floorニューヨーク、ニューヨーク10103米国
EMail: david.solo@citicorp.com
メール: david.solo@citicorp.com
Housley, et. al. Standards Track [Page 128] RFC 2459 Internet X.509 Public Key Infrastructure January 1999
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤1999年1月にRFC2459を追跡します[128ページ]。
Appendix F. Full Copyright Statement
付録のF.の完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Housley, et. al. Standards Track [Page 129]
et Housley、アル。 標準化過程[129ページ]
一覧
スポンサーリンク
