RFC3280 日本語訳
3280 Internet X.509 Public Key Infrastructure Certificate andCertificate Revocation List (CRL) Profile. R. Housley, W. Polk, W.Ford, D. Solo. April 2002. (Format: TXT=295556 bytes) (Obsoletes RFC2459) (Obsoleted by RFC5280) (Updated by RFC4325, RFC4630) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Housley
Request for Comments: 3280 RSA Laboratories
Obsoletes: 2459 W. Polk
Category: Standards Track NIST
W. Ford
VeriSign
D. Solo
Citigroup
April 2002
Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3280のRSA研究所が以下を時代遅れにします。 2459年のW.ポークカテゴリ: 規格はシティグループ2002年4月にNIST W.フォードのベリサインのD.独奏を追跡します。
Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (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 (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This memo profiles the X.509 v3 certificate and X.509 v2 Certificate Revocation List (CRL) for use in the Internet. An overview of this approach and model 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. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail, and required extensions are defined. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices.
このメモはインターネットでの使用のために、X.509 v3証明書とX.509 v2 Certificate Revocation List(CRL)の輪郭を描きます。 序論としてこのアプローチとモデルの概観を提供します。 X.509 v3証明書形式はインターネット名前フォームの形式と意味論に関する追加情報で詳細に説明されます。標準の証明書拡張子は説明されます、そして、2つのインターネット特有の拡大が定義されます。 1セットの必要な証明書拡張子は指定されます。 X.509 v2 CRL形式は詳細に説明されます、そして、必要な拡大は定義されます。 X.509証明経路合法化のためのアルゴリズムは説明されます。 ASN.1モジュールと例を付録に提供します。
Table of Contents
目次
1 Introduction . . . . . . . . . . . . . . . . . . . . . . 4 2 Requirements and Assumptions . . . . . . . . . . . . . . 5 2.1 Communication and Topology . . . . . . . . . . . . . . 6 2.2 Acceptability Criteria . . . . . . . . . . . . . . . . 6 2.3 User Expectations . . . . . . . . . . . . . . . . . . . 7 2.4 Administrator Expectations . . . . . . . . . . . . . . 7 3 Overview of Approach . . . . . . . . . . . . . . . . . . 7
1つの序論. . . . . . . . . . . . . . . . . . . . . . 4 2の要件と仮定. . . . . . . . . . . . . . 5 2.1コミュニケーションとトポロジー.62.2のロット判定基準. . . . . . . . . . . . . . . . 6 2.3ユーザ期待. . . . . . . . . . . . . . . . . . . 7 2.4管理者期待、アプローチ. . . . . . . . . . . . . . . . . . 7の.7 3概観
Housley, et. al. Standards Track [Page 1] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[1ページ]。
3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . 8 3.2 Certification Paths and Trust . . . . . . . . . . . . . 9 3.3 Revocation . . . . . . . . . . . . . . . . . . . . . . 11 3.4 Operational Protocols . . . . . . . . . . . . . . . . . 13 3.5 Management Protocols . . . . . . . . . . . . . . . . . 13 4 Certificate and Certificate Extensions Profile . . . . . 14 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 . . . . . . . . . . . . . . . . . . 16 4.1.2 TBSCertificate . . . . . . . . . . . . . . . . . . . 17 4.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 17 4.1.2.2 Serial number . . . . . . . . . . . . . . . . . . . 17 4.1.2.3 Signature . . . . . . . . . . . . . . . . . . . . . 18 4.1.2.4 Issuer . . . . . . . . . . . . . . . . . . . . . . 18 4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . 22 4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . 22 4.1.2.5.2 GeneralizedTime . . . . . . . . . . . . . . . . . 22 4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . 23 4.1.2.7 Subject Public Key Info . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . 26 4.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . 27 4.2.1.3 Key Usage . . . . . . . . . . . . . . . . . . . . . 28 4.2.1.4 Private Key Usage Period . . . . . . . . . . . . . 29 4.2.1.5 Certificate Policies . . . . . . . . . . . . . . . 30 4.2.1.6 Policy Mappings . . . . . . . . . . . . . . . . . . 33 4.2.1.7 Subject Alternative Name . . . . . . . . . . . . . 33 4.2.1.8 Issuer Alternative Name . . . . . . . . . . . . . . 36 4.2.1.9 Subject Directory Attributes . . . . . . . . . . . 36 4.2.1.10 Basic Constraints . . . . . . . . . . . . . . . . 36 4.2.1.11 Name Constraints . . . . . . . . . . . . . . . . . 37 4.2.1.12 Policy Constraints . . . . . . . . . . . . . . . . 40 4.2.1.13 Extended Key Usage . . . . . . . . . . . . . . . . 40 4.2.1.14 CRL Distribution Points . . . . . . . . . . . . . 42 4.2.1.15 Inhibit Any-Policy . . . . . . . . . . . . . . . . 44 4.2.1.16 Freshest CRL . . . . . . . . . . . . . . . . . . . 44 4.2.2 Internet Certificate Extensions . . . . . . . . . . . 45 4.2.2.1 Authority Information Access . . . . . . . . . . . 45 4.2.2.2 Subject Information Access . . . . . . . . . . . . 46 5 CRL and CRL Extensions Profile . . . . . . . . . . . . . 48 5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . 49 5.1.1 CertificateList Fields . . . . . . . . . . . . . . . 50 5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . 50
3.1のX.509バージョン3証明書. . . . . . . . . . . . . . 8 3.2証明経路と信用. . . . . . . . . . . . . 9 3.3取消し. . . . . . . . . . . . . . . . . . . . . . 11 3.4の操作上のプロトコル. . . . . . . . . . . . . . . . . 13 3.5管理プロトコル. . . . . . . . . . . . . . . . . 13 4証明書と証明書拡張子が.144.1の基本的な証明書分野. . . . . . . . . . . . . . . 15 4.1.1の証明書分野の輪郭を描く、.164.1、.1; 1 tbsCertificate. . . . . . . . . . . . . . . . . . 16 4.1.1.2signatureAlgorithm. . . . . . . . . . . . . . . . 16 4.1.1.3signatureValue. . . . . . . . . . . . . . . . . . 16 4.1.2TBSCertificate. . . . . . . . . . . . . . . . . . . 17 4.1.2.1バージョン; . . . . . . . . . . . . . . . . . . . . . 17 4.1.2.2 通し番号. . . . . . . . . . . . . . . . . . . 17 4.1.2.3Signature. . . . . . . . . . . . . . . . . . . . . 18 4.1.2.4Issuer. . . . . . . . . . . . . . . . . . . . . . 18 4.1.2、.5Validity… . . . . . . . . . . . . . . . . . 22 4.1.2.5.1UTCTime. . . . . . . . . . . . . . . . . . . . . 22 4.1.2の.5の.2のGeneralizedTime.224.1.2.6対象. . . . . . . . . . . . . . . . . . . . . . 23 4.1.2の.7の対象の公開鍵、インフォメーション. . . . . . . . . . . . . . 24 4.1.2、.9の拡大. . . . . . . . . . . . . . . . . . . . . 24 4.2の.8のユニークな識別子. . . . . . . . . . . . . . . . 24 4.1.2の証明書拡張子. . . . . . . . . . . . . . . . 24 4.2.1の標準の拡大、.254.2、.1; 1 権威の主要な識別子. . . . . . . . . . . . . 26 4.2.1の.2の対象の主要な識別子. . . . . . . . . . . . . . 27 4.2.1の.3の主要な用法. . . . . . . . . . . . . . . . . . . . . 28 4.2.1.4秘密鍵用法の期間. . . . . . . . . . . . . 29 4.2の.1の.5の証明書方針. . . . . . . . . . . . . . . 30 4.2.1の.6の方針マッピング. . . . . . . . . . . . . . . . . . 33 4.2.1の.7の対象の代替名. . . . . . . . . . . . . 33 4.2.1.8発行人代替名. . . . . . . . . . . . . . 36 4.2.1.9Subjectディルectory Attributes. . . . . . . . . . . 36 4.2.1の.10基本的なConstraints. . . . . . . . . . . . . . . . 36 4.2.1の.11名前Constraints. . . . . . . . . . . . . . . . . 37 4.2.1の.12方針Constraints. . . . . . . . . . . . . . . . 40 4.2.1の.13の拡張Key Usage. . . . . . . . . . . . . . . . 40 4.2.1.14CRL Distribution Points、.424.2、.1、.15、Any-方針を禁止してください、.444.2 .1 .16 最も新鮮なCRL…; . . . . . . . . . . 44 4.2.2 インターネット証明書拡張子. . . . . . . . . . . 45 4.2.2.1権威情報アクセス. . . . . . . . . . . 45 4.2.2の.2の対象の情報アクセス. . . . . . . . . . . . 46 5CRLとCRL拡張子プロフィール. . . . . . . . . . . . . 48 5.1CRL分野. . . . . . . . . . . . . . . . . . . . . . 49 5.1.1CertificateList分野. . . . . . . . . . . . . . . 50 5.1.1.1tbsCertList. . . . . . . . . . . . . . . . . . . . 50
Housley, et. al. Standards Track [Page 2] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[2ページ]。
5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 50 5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 51 5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . 51 5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 52 5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . 52 5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . 52 5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . 52 5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . 53 5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . 53 5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . 53 5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . 53 5.2.1 Authority Key Identifier . . . . . . . . . . . . . . 54 5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . 54 5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . 55 5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . 55 5.2.5 Issuing Distribution Point . . . . . . . . . . . . . 58 5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . 59 5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . 60 5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . 60 5.3.2 Hold Instruction Code . . . . . . . . . . . . . . . . 61 5.3.3 Invalidity Date . . . . . . . . . . . . . . . . . . . 62 5.3.4 Certificate Issuer . . . . . . . . . . . . . . . . . 62 6 Certificate Path Validation . . . . . . . . . . . . . . . 62 6.1 Basic Path Validation . . . . . . . . . . . . . . . . . 63 6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . 66 6.1.2 Initialization . . . . . . . . . . . . . . . . . . . 67 6.1.3 Basic Certificate Processing . . . . . . . . . . . . 70 6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . 75 6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . 78 6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . 80 6.2 Extending Path Validation . . . . . . . . . . . . . . . 80 6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . 81 6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . 82 6.3.2 Initialization and Revocation State Variables . . . . 82 6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . 83 7 References . . . . . . . . . . . . . . . . . . . . . . . 86 8 Intellectual Property Rights . . . . . . . . . . . . . . 88 9 Security Considerations . . . . . . . . . . . . . . . . . 89 Appendix A. ASN.1 Structures and OIDs . . . . . . . . . . . 92 A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . 92 A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . 105 Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . 112 Appendix C. Examples . . . . . . . . . . . . . . . . . . . 115 C.1 DSA Self-Signed Certificate . . . . . . . . . . . . . . 115 C.2 End Entity Certificate Using DSA . . . . . . . . . . . 119 C.3 End Entity Certificate Using RSA . . . . . . . . . . . 122 C.4 Certificate Revocation List . . . . . . . . . . . . . . 126 Author Addresses . . . . . . . . . . . . . . . . . . . . . . 128
5.1.1.2 signatureAlgorithm. . . . . . . . . . . . . . . . 50 5.1.1.3signatureValue. . . . . . . . . . . . . . . . . . 51 5.1.2が「サインされるために」リスト.515.1.2.1バージョン. . . . . . . . . . . . . . . . . . . . . . 52 5.1.2.2署名. . . . . . . . . . . . . . . . . . . . . 52 5.1.2.3発行人名を証明する、.525.1、.2、.4、この次のアップデート. . . . . . . . . . . . . . . . . . . . 52 5.1.2.5アップデート、.535.1、.2; 6は発行する中で分配ポイント. . . . . . . . . . . . . 58 5.2.6CRL最も新鮮である.7の拡大. . . . . . . . . . . . . . . . . . . . 53 5.2の証明書. . . . . . . . . . . . . . . 53 5.1.2のCRL拡張子. . . . . . . . . . . . . . . . . . . . 53 5.2.1の権威の主要な識別子. . . . . . . . . . . . . . 54 5.2.2発行人代替名. . . . . . . . . . . . . . . 54 5.2.3CRL No.. . . . . . . . . . . . . . . . . . . . . 55 5.2.4デルタCRLインディケータ. . . . . . . . . . . . . . . . . 55 5.2.5を取り消しました。 . . . . . . . . . . . . . . . . . . . 59 5.3 CRLエントリー拡張子. . . . . . . . . . . . . . . . . 60 5.3.1理由コード. . . . . . . . . . . . . . . . . . . . . 60 5.3.2は命令コード. . . . . . . . . . . . . . . . 61 5.3.3無効日付. . . . . . . . . . . . . . . . . . . 62 5.3の.4証明書発行人. . . . . . . . . . . . . . . . . 62 6証明書経路合法化. . . . . . . . . . . . . . . 62 6.1の基本的な経路合法化. . . . . . . . . . . . . . . . . 63 6.1.1の入力. . . . . . . . . . . . . . . . . . . . . . . 66 6.1を保持します; Certificate i+1.756.1のために、.5は手順をWrap上げます。2、初期設定. . . . . . . . . . . . . . . . . . . 67 6.1.3Basic Certificate Processing、.706.1、.4Preparation、.786.1.6Outputs; .806.2 経路合法化. . . . . . . . . . . . . . . 80 6.3CRL合法化. . . . . . . . . . . . . . . . . . . . 81 6.3.1の取消し入力. . . . . . . . . . . . . . . . . . 82 6.3.2Initializatioを広げること。nとRevocation州Variables. . . . 82 6.3.3CRL Processing. . . . . . . . . . . . . . . . . . . 83 7References. . . . . . . . . . . . . . . . . . . . . . . 86 8Intellectual Property Rights. . . . . . . . . . . . . . 88 9Security Considerations. . . . . . . . . . . . . . . . . 89Appendix A. ASN.1StructuresとOIDs.92A.1 Explicitly Tagged Module、1988、Syntax.92A.2 Implicitly Tagged Module(1988Syntax); .105 RSA. . . . . . . . . . . 122C.4証明書失効リスト. . . . . . . . . . . . . . 126作者アドレス. . . . . . . . . . . . . . . . . . . . . . 128を使用することでDSA. . . . . . . . . . . 119C.3終わりの実体証明書を使用する付録B.ASN.1注意. . . . . . . . . . . . . . . . . . 112付録C.の例. . . . . . . . . . . . . . . . . . . 115のC.1 DSA自己署名入りの証書.115C.2終わりの実体証明書
Housley, et. al. Standards Track [Page 3] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[3ページ]。
Full Copyright Statement . . . . . . . . . . . . . . . . . . 129
完全な著作権宣言文. . . . . . . . . . . . . . . . . . 129
1 Introduction
1つの序論
This specification is one part of a family of standards for the X.509 Public Key Infrastructure (PKI) for the Internet.
この仕様はインターネットへのX.509公開鍵暗号基盤(PKI)の規格の家族の一部です。
This specification profiles the format and semantics of certificates and certificate revocation lists (CRLs) for the Internet PKI. Procedures are described for processing of certification paths in the Internet environment. Finally, ASN.1 modules are provided in the appendices for all data structures defined or referenced.
この仕様は証明書と証明書失効リスト(CRLs)の形式と意味論のインターネットPKIに輪郭を描きます。 手順はインターネット環境における、証明経路の処理のために説明されます。 最終的に、データ構造が定義したか、または参照をつけたすべてのためにASN.1モジュールを付録に提供します。
Section 2 describes Internet PKI requirements, and the assumptions which affect the scope of this document. Section 3 presents an architectural model and describes its relationship to previous IETF and ISO/IEC/ITU-T standards. In particular, this document's relationship with the IETF PEM specifications and the ISO/IEC/ITU-T X.509 documents are described.
セクション2はインターネットPKI要件、およびこのドキュメントの範囲に影響する仮定について説明します。 セクション3は、前のIETFとITU ISO/IEC/T規格に建築モデルを提示して、関係について説明します。 特に、IETF PEM仕様とのこのドキュメントの関係とITU ISO/IEC/T X.509ドキュメントは説明されます。
Section 4 profiles the X.509 version 3 certificate, and section 5 profiles the X.509 version 2 CRL. The profiles include the identification of ISO/IEC/ITU-T and ANSI extensions which may be useful in the Internet PKI. The profiles are presented in the 1988 Abstract Syntax Notation One (ASN.1) rather than the 1997 ASN.1 syntax used in the most recent ISO/IEC/ITU-T standards.
セクション4はX.509バージョン3証明書の輪郭を描きます、そして、セクション5はX.509バージョン2CRLの輪郭を描きます。 プロフィールはITU ISO/IEC/TとインターネットPKIで役に立つかもしれないANSI拡張子の識別を含んでいます。 プロフィールは最新のITU ISO/IEC/T規格に使用される1997ASN.1構文よりむしろ1988の抽象的なSyntax Notation One(ASN.1)に提示されます。
Section 6 includes certification path validation procedures. These procedures are based upon the ISO/IEC/ITU-T definition. Implementations are REQUIRED to derive the same results but are not required to use the specified procedures.
セクション6は証明経路合法化手順を含めます。 これらの手順はITU ISO/IEC/T定義に基づいています。 実現は、同じ結果を引き出すREQUIREDですが、指定された手順を用いるのに必要ではありません。
Procedures for identification and encoding of public key materials and digital signatures are defined in [PKIXALGS]. Implementations of this specification are not required to use any particular cryptographic algorithms. However, conforming implementations which use the algorithms identified in [PKIXALGS] MUST identify and encode the public key materials and digital signatures as described in that specification.
公開鍵の材料とデジタル署名の識別とコード化のための手順は[PKIXALGS]で定義されます。 この仕様の実現は、どんな特定の暗号アルゴリズムも使用するのに必要ではありません。しかしながら、[PKIXALGS]で特定されたアルゴリズムを使用する実現を従わせるのは、その仕様で説明されるように公開鍵の材料とデジタル署名を特定して、コード化しなければなりません。
Finally, three appendices are provided to aid implementers. Appendix A contains all ASN.1 structures defined or referenced within this specification. As above, the material is presented in the 1988 ASN.1. Appendix B contains notes on less familiar features of the ASN.1 notation used within this specification. Appendix C contains examples of a conforming certificate and a conforming CRL.
最終的に、implementersを支援するために3個の付録を提供します。 付録Aはこの仕様の中で定義されたか、または参照をつけられたすべてのASN.1構造を含んでいます。 同じくらい上では、1988ASN.1で材料を寄贈します。 付録Bはこの仕様の中で使用されたASN.1記法のそれほど身近でない特徴に関する注を含んでいます。 付録Cは従っている証明書と従っているCRLに関する例を含んでいます。
Housley, et. al. Standards Track [Page 4] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[4ページ]。
This specification obsoletes RFC 2459. This specification differs from RFC 2459 in five basic areas:
この仕様はRFC2459を時代遅れにします。 この仕様は5つの基本的な領域でRFC2459と異なっています:
* To promote interoperable implementations, a detailed algorithm
for certification path validation is included in section 6.1 of
this specification; RFC 2459 provided only a high-level
description of path validation.
* 共同利用できる実現を促進するために、証明経路合法化のための詳細なアルゴリズムはこの仕様のセクション6.1に含まれています。 RFC2459は経路合法化のハイレベルの記述だけを提供しました。
* An algorithm for determining the status of a certificate using
CRLs is provided in section 6.3 of this specification. This
material was not present in RFC 2459.
* CRLsを使用することで証明書の状態を決定するためのアルゴリズムをこの仕様のセクション6.3に提供します。 この材料はRFC2459に存在していませんでした。
* To accommodate new usage models, detailed information describing
the use of delta CRLs is provided in Section 5 of this
specification.
* 新しい用法モデルに対応するために、デルタCRLsの使用について説明する詳細な情報をこの仕様のセクション5に提供します。
* Identification and encoding of public key materials and digital
signatures are not included in this specification, but are now
described in a companion specification [PKIXALGS].
* 公開鍵の材料とデジタル署名の識別とコード化は、この仕様に含まれていませんが、現在、仲間仕様[PKIXALGS]で説明されます。
* Four additional extensions are specified: three certificate
extensions and one CRL extension. The certificate extensions are
subject info access, inhibit any-policy, and freshest CRL. The
freshest CRL extension is also defined as a CRL extension.
* 4つの追加拡大が指定されます: 3は拡大と1つのCRL拡張子を証明します。 証明書拡張子が対象のインフォメーションアクセスである、禁止、いくらか、-、方針、そして、最も新鮮なCRL。 また、最も新鮮なCRL拡張子はCRL拡張子と定義されます。
* Throughout the specification, clarifications have been
introduced to enhance consistency with the ITU-T X.509
specification. X.509 defines the certificate and CRL format as
well as many of the extensions that appear in this specification.
These changes were introduced to improve the likelihood of
interoperability between implementations based on this
specification with implementations based on the ITU-T
specification.
* 仕様中では、ITU-T X.509仕様で一貫性を高めるために明確化を導入しました。 X.509はこの仕様に現れる拡大の多くと同様に証明書とCRL書式を定義します。 ITU-T仕様に基づく実現でこの仕様に基づく実現の間の相互運用性の見込みを改良するためにこれらの変化を導入しました。
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で説明されるように本書では解釈されることであるべきです。
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
この仕様の目標はX.509技術を利用したがっているそれらの共同体のためのインターネットアプリケーションの中のX.509証明書の使用を容易にするためにプロフィールを開発することです。 そのようなアプリケーションはWWW、電子メール、ユーザー認証、およびIPsecを含むかもしれません。 X.509を使用するのに障害のいくつかを救います。
Housley, et. al. Standards Track [Page 5] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[5ページ]。
certificates, this document defines a profile to promote the development of certificate management systems; development of application tools; and interoperability determined by policy.
証明書であり、このドキュメントは証明書マネージメントシステムの開発を促進するためにプロフィールを定義します。 アプリケーションツールの開発。 そして、方針によって決定している相互運用性。
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の接続性も、または高い接続の有用性なしでユーザを支持します。 さらに、プロフィールは何らかのファイアウォールの存在のためにフィルターにかけることのコミュニケーションを許容します。
This profile does not assume the deployment of an X.500 Directory system or a LDAP directory system. The profile does not prohibit the use of an X.500 Directory or a LDAP directory; however, any means of distributing certificates and certificate revocation lists (CRLs) may be used.
このプロフィールはX.500ディレクトリシステムかLDAPディレクトリシステムの展開を仮定しません。 プロフィールはX.500ディレクトリかLDAPディレクトリの使用を禁止しません。 しかしながら、証明書と証明書失効リスト(CRLs)を配布するどんな手段も使用されるかもしれません。
2.2 Acceptability Criteria
2.2 受容性評価基準
The goal of the Internet Public Key Infrastructure (PKI) is to meet the needs of deterministic, automated identification, authentication, access control, and authorization functions. Support for these services determines the attributes contained in the certificate as well as the ancillary control information in the certificate such as policy data and certification path constraints.
インターネット公開鍵暗号基盤(PKI)の目標は決定論的で、自動化された識別、認証、アクセス管理、および認可機能の需要を満たすことです。 これらのサービスのサポートは付属の制御情報と同様に証明書の方針データなどの証明書に含まれた属性と証明経路規制を決定します。
Housley, et. al. Standards Track [Page 6] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[6ページ]。
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 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仕様によって思われた建築モデルの簡易型の視点があります。
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;
CRL issuer: an optional system to which a CA delegates the
publication of certificate revocation lists;
repository: a system or collection of distributed systems that stores
certificates and CRLs and serves as a means of
distributing these certificates and CRLs to end entities.
実体を終わらせてください: 証明書の対象であるPKI証明書、そして/または、エンドユーザシステムのユーザ。 カリフォルニア: 証明権威。 RA: すなわち、登録局、カリフォルニアが、ある管理機能を代表として派遣する任意のシステム。 CRL発行人: カリフォルニアが証明書失効リストの公表を代表として派遣する任意のシステム。 倉庫: 証明書とCRLsを格納して、実体を終わらせるこれらの証明書とCRLsを配布する手段として機能する分散システムのシステムか収集。
Note that an Attribute Authority (AA) might also choose to delegate the publication of CRLs to a CRL issuer.
また、Attribute Authority(AA)が、CRLsの公表をCRL発行人へ代表として派遣するのを選ぶかもしれないことに注意してください。
Housley, et. al. Standards Track [Page 7] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[7ページ]。
+---+ | C | +------------+ | e | <-------------------->| End entity | | r | Operational +------------+ | t | transactions ^ | i | and management | Management | f | transactions | transactions PKI | i | | users | c | v | a | ======================= +--+------------+ ============== | t | ^ ^ | e | | | PKI | | v | management | & | +------+ | entities | | <---------------------| RA |<----+ | | C | Publish certificate +------+ | | | R | | | | L | | | | | v v | R | +------------+ | e | <------------------------------| CA | | p | Publish certificate +------------+ | o | Publish CRL ^ ^ | s | | | Management | i | +------------+ | | transactions | t | <--------------| CRL Issuer |<----+ | | o | Publish CRL +------------+ v | r | +------+ | y | | CA | +---+ +------+
+---+ | C| +------------+ | e| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 終わりの実体| | r| 操作上の+------------+ | t| 取引^| i| そして、管理| 管理| f| 取引| 取引PKI| i| | ユーザ| c| v| a| ======================= +--+------------+ ============== | t| ^ ^ | e| | | PKI| | v| 管理| & | +------+ | 実体| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| RA| <、-、-、--+ | | C| 証明書+を発表してください。------+ | | | R| | | | L| | | | | vに対して| R| +------------+ | e| <------------------------------| カリフォルニア| | p| 証明書+を発表してください。------------+ | o | CRL^ ^を発行してください。| s| | | 管理| i| +------------+ | | 取引| t| <、-、-、-、-、-、-、-、-、-、-、-、-、--、| CRL発行人| <、-、-、--+ | | o | CRL+を発行してください。------------+ v| r| +------+ | y| | カリフォルニア| +---+ +------+
Figure 1 - PKI Entities
図1--PKI実体
3.1 X.509 Version 3 Certificate
3.1 X.509バージョン3証明書
Users of a public key require confidence that the associated private key is owned by the correct remote subject (person or system) with which an encryption or digital signature mechanism will be used. This confidence is obtained through the use of public key certificates, which are data structures that bind public key values to subjects. The binding is asserted by having a trusted CA digitally sign each certificate. The CA may base this assertion upon technical means (a.k.a., proof of possession through a challenge- response protocol), presentation of the private key, or on an assertion by the subject. A certificate has a limited valid lifetime which is indicated in its signed contents. Because a certificate's signature and timeliness can be independently checked by a certificate-using client, certificates can be distributed via
公開鍵のユーザは暗号化かデジタル署名メカニズムが使用される正しいリモート対象(人かシステム)によって関連秘密鍵が所有されているという信用を必要とします。 公開鍵証明書の使用でこの信用を得ます。(証明書は公開鍵値を対象に縛るデータ構造です)。 信じられたカリフォルニアを各証明書にデジタルにサインさせることによって、結合は断言されます。 カリフォルニアは、対象で技術手段(通称挑戦応答プロトコルを通した所有物の証拠)でのこの主張、秘密鍵のプレゼンテーションを基礎づけるか、または主張に関してそうするかもしれません。 証明書には、サインされたコンテンツで示される限られた有効な寿命があります。 を通して証明書を使用するクライアントが独自に証明書の署名とタイムリーさであるのをチェックできるので、証明書を配布できる。
Housley, et. al. Standards Track [Page 8] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[8ページ]。
untrusted communications and server systems, and can be cached in unsecured storage in certificate-using systems.
信頼されていないコミュニケーションとサーバシステム、証明書を使用するシステムにおけるキャッシュされた中で非安全にされた格納はそうであることができます。
ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 9594-8, which was first published in 1988 as part of the X.500 Directory recommendations, defines a standard certificate format [X.509]. The certificate format in the 1988 standard is called the version 1 (v1) format. When X.500 was revised in 1993, two more fields were added, resulting in the version 2 (v2) format.
ITU-T X.509(以前CCITT X.509)かISO/IEC9594-8(1988年に最初に、X.500ディレクトリ推薦の一部として発行されました)が標準の証明書書式[X.509]を定義します。 1988年の規格における証明書形式はバージョン1(v1)形式と呼ばれます。 X.500が1993年に改訂されたとき、バージョン2(v2)形式をもたらして、もう2つの分野が加えられました。
The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, include specifications for a public key infrastructure based on X.509 v1 certificates [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 had proven necessary. In response to these new requirements, ISO/IEC, ITU-T and ANSI X9 developed the X.509 version 3 (v3) certificate format. The v3 format extends the v2 format by adding provision for additional extension fields. Particular extension field types may be specified in standards or may be defined and registered by any organization or community. In June 1996, standardization of the basic v3 format was completed [X.509].
1993年に発行されたインターネットPrivacy Enhancedメール(PEM)RFCsはX.509 v1証明書[RFC1422]に基づく公開鍵認証基盤のための仕様を含んでいます。 RFC1422を配備する試みで行われた経験は、v1とv2証明書形式がいくつかの点で不完全であると断言しました。 最も重要に、より多くの分野が、どのPEM設計と実装経験が必要であると判明したかという情報を運ぶのに必要でした。 これらの新しい要件に対応して、ISO/IEC、ITU-T、およびANSI X9はX.509バージョン3(v3)証明書形式を発生しました。 v3形式は、追加拡大分野への支給を加えることによって、v2形式を広げています。 特定の拡大フィールド・タイプは、どんな組織や共同体によっても規格で指定されるか、定義されて、または示されるかもしれません。 1996年6月に、基本的なv3形式の標準化は終了しました[X.509]。
ISO/IEC, ITU-T, and ANSI X9 have also developed standard extensions for use in the v3 extensions field [X.509][X9.55]. These extensions can convey such data as additional subject identification information, key attribute information, policy information, and certification path constraints.
また、ISO/IEC、ITU-T、およびANSI X9はv3拡大分野[X.509][X9.55]での使用のための標準の拡大を発生しました。 これらの拡大は追加対象の識別情報、主要な属性情報、方針情報、および証明経路規制のようなデータを伝えることができます。
However, the ISO/IEC, ITU-T, and ANSI X9 standard extensions are very broad in their applicability. In order to develop interoperable implementations of X.509 v3 systems for Internet use, it is necessary to specify a profile for use of the X.509 v3 extensions tailored for the Internet. It is one goal of this document to specify a profile for Internet WWW, electronic mail, and IPsec applications. Environments with additional requirements may build on this profile or may replace it.
しかしながら、ISO/IEC、ITU-T、およびANSI X9の標準の拡張子は彼らの適用性で非常に広いです。 インターネットの利用のX.509 v3システムの共同利用できる実現を開発するために、インターネットに適合したX.509 v3拡張子の使用のためのプロフィールを指定するのが必要です。 それはインターネットWWW、電子メール、およびIPsecアプリケーションのためのプロフィールを指定するこのドキュメントの1つの目標です。 追加要件がある環境は、このプロフィールの上に建てるか、またはそれを取り替えるかもしれません。
3.2 Certification Paths and Trust
3.2 証明経路と信用
A user of a security service requiring knowledge of a public key generally needs to obtain and validate a certificate containing the required public key. If the public key user does not already hold an assured copy of the public key of the CA that signed the certificate, the CA's name, and related information (such as the validity period or name constraints), then it might need an additional certificate to obtain that public key. In general, a chain of multiple certificates
一般に、公開鍵に関する知識を必要とするセキュリティー・サービスのユーザは、必要な公開鍵を含む証明書を得て、有効にする必要があります。 公開鍵ユーザが既に、証明書に署名したカリフォルニアの公開鍵の確実なコピー、CAの名前、および関連する情報(規制という有効期間か名前などの)を保持しないなら、それは、その公開鍵を得るために追加証明書を必要とするかもしれません。 一般に、aは複数の証明書をチェーニングします。
Housley, et. al. Standards Track [Page 9] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[9ページ]。
may be needed, comprising a certificate of the public key owner (the end entity) signed by one CA, and zero or more additional certificates of CAs signed by other CAs. Such chains, called certification paths, are required because a public key user is only initialized with a limited number of assured CA public keys.
必要であったかもしれない、公開鍵所有者(終わりの実体)の証明書を包括するのは1カリフォルニア、およびゼロで署名したか、またはCAsの、より多くの追加証明書が他のCAsで署名しました。 公開鍵ユーザが限られた数の確実なカリフォルニア公開鍵で初期化されるだけであるので、証明経路と呼ばれるそのようなチェーンが必要です。
There are different ways in which CAs might be configured in order for public key users to be able to find certification paths. For PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There are three types of PEM certification authority:
公開鍵ユーザが証明経路を見つけることができるようにCAsが構成されるかもしれない異なった方法があります。 PEMに関しては、RFC1422はCAsの堅い階層構造を定義しました。 PEM証明権威の3つのタイプがあります:
(a) Internet Policy Registration Authority (IPRA): This
authority, operated under the auspices of the Internet Society,
acts as the root of the PEM certification hierarchy at level 1.
It issues certificates only for the next level of authorities,
PCAs. All certification paths start with the IPRA.
(a) インターネット方針登録局(IPRA): インターネット協会の前兆で操作されたこの権威はレベル1におけるPEM証明階層構造の根として機能します。 それは当局、PCAsの次のレベルのためだけの証明書を発行します。 すべての証明経路がIPRAから始まります。
(b) Policy Certification Authorities (PCAs): PCAs are at level 2
of the hierarchy, each PCA being certified by the IPRA. A PCA
shall establish and publish a statement of its policy with respect
to certifying users or subordinate certification authorities.
Distinct PCAs aim to satisfy different user needs. For example,
one PCA (an organizational PCA) might support the general
electronic mail needs of commercial organizations, and another PCA
(a high-assurance PCA) might have a more stringent policy designed
for satisfying legally binding digital signature requirements.
(b) 方針証明当局(PCAs): 各PCAがIPRAによって公認されて、PCAsは階層構造のレベル2においてそうです。 PCAはユーザか下位の証明当局を公認することに関して方針の声明を確立して、発表するものとします。 異なったPCAsは、異なったユーザ需要を満たすことを目指します。 例えば、1PCA(組織的なPCA)が営利団体の一般的な電子メールの必要性をサポートするかもしれません、そして、別のPCA(高保証PCA)は、法的に拘束力があるデジタル署名要件を満たすように、より厳しい方針を設計させるかもしれません。
(c) Certification Authorities (CAs): CAs are at level 3 of the
hierarchy and can also be at lower levels. Those at level 3 are
certified by PCAs. CAs represent, for example, particular
organizations, particular organizational units (e.g., departments,
groups, sections), or particular geographical areas.
(c) 証明当局(CAs): CAsは階層構造のレベル3にあって、また、下のレベルにあることができます。 レベル3におけるものはPCAsによって公認されます。 CAsは例えば、特定の組織、特定の組織的なユニット(例えば、部、グループ、セクション)、または特定の地理的な領域を代表します。
RFC 1422 furthermore has a name subordination rule which requires that a CA can only issue certificates for entities whose names are subordinate (in the X.500 naming tree) to the name of the CA itself. The trust associated with a PEM certification path is implied by the PCA name. The name subordination rule ensures that CAs below the PCA are sensibly constrained as to the set of subordinate entities they can certify (e.g., a CA for an organization can only certify entities in that organization's name tree). Certificate user systems are able to mechanically check that the name subordination rule has been followed.
RFC1422には、その上、カリフォルニアが名前がカリフォルニア自体の名前に下位である(X.500命名木の)実体のための証明書を発行できるだけであるのを必要とする名前従属規則があります。 PEM証明経路に関連している信頼はPCA名によって含意されます。 名前従属規則は、PCAの下のCAsがそれらが公認できる下位の実体のセットに関して分別よく抑制されるのを確実にします(例えば、組織のためのカリフォルニアはその組織名木で実体を公認できるだけです)。 証明書ユーザシステムは、名前従属規則に従ってあるのを機械的にチェックできます。
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の限界は、明確に方針情報を関連づけるか、または証明書に関するユーティリティを制限するためにいくつかの構造的な制限の賦課を必要としました。 これらの制限は:だった
Housley, et. al. Standards Track [Page 10] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[10ページ]。
(a) a pure top-down hierarchy, with all certification paths
starting from IPRA;
(a) すべての証明経路がIPRAから始めている純粋なトップダウン階層構造。
(b) a naming subordination rule restricting the names of a CA's
subjects; and
(b) CAの対象の名前を制限する命名従属規則。 そして
(c) use of the PCA concept, which requires knowledge of
individual PCAs to be built into certificate chain verification
logic. Knowledge of individual PCAs was required to determine if
a chain could be accepted.
(c) PCA概念の使用。(それは、証明書チェーン検証論理が個々のPCAsに関する知識に組み込まれるのを必要とします)。 個々のPCAsに関する知識が、チェーンを受け入れることができるかどうか決定するのに必要でした。
With X.509 v3, most of the requirements addressed by RFC 1422 can be addressed using certificate extensions, without a need to restrict the CA structures used. In particular, the certificate extensions relating to certificate policies obviate the need for PCAs and the constraint extensions obviate the need for the name subordination rule. As a result, this document supports a more flexible architecture, including:
X.509 v3と共に、証明書拡張子を使用することでRFC1422によって扱われた要件の大部分を扱うことができます、構造が使用したカリフォルニアを制限する必要性なしで。 特に、証明書方針に関連する証明書拡張子はPCAsの必要性を取り除きます、そして、規制拡大は名前従属規則の必要性を取り除きます。 その結果、このドキュメントは、よりフレキシブルなアーキテクチャ、包含をサポートします:
(a) Certification paths start with a public key of a CA in a
user's own domain, or with the public key of the top of a
hierarchy. Starting with the public key of a CA in a user's own
domain has certain advantages. In some environments, the local
domain is the most trusted.
(a) 証明経路はユーザの自己のドメインのカリフォルニア、または階層構造の最上部の公開鍵で公開鍵から始まります。 ユーザの自己のドメインでカリフォルニアの公開鍵から始まるのにおいて、ある利点があります。 いくつかの環境で、局所領域は最も信じているものです。
(b) Name constraints may be imposed through explicit inclusion of
a name constraints extension in a certificate, but are not
required.
(b) 名前規制は、証明書での名前規制拡大の明白な包含で課されるかもしれませんが、必要ではありません。
(c) Policy extensions and policy mappings replace the PCA
concept, which permits a greater degree of automation. The
application can determine if the certification path is acceptable
based on the contents of the certificates instead of a priori
knowledge of PCAs. This permits automation of certification path
processing.
(c) 方針拡大と方針マッピングはPCA概念に取って代わります。(それは、より大きい度合いのオートメーションを可能にします)。 アプリケーションは、証明経路がPCAsに関する先験的な知識の代わりに証明書のコンテンツに基づいて許容できるかどうか決定できます。 これは証明経路処理のオートメーションを可能にします。
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.
証明書を発行するとき、全体の有効期間の間、使用中であるとそれを予想します。 しかしながら、様々な事情によって、証明書は有効期間の満了の前に無効になるかもしれません。 そのような事情は名前の変化、対象と、カリフォルニア(例えば、従業員は組織との雇用を終える)と、感染との協会の変化または対応する秘密鍵の疑われた感染を含んでいます。 これでは、カリフォルニアは、証明書を取り消す必要があります。
Housley, et. al. Standards Track [Page 11] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[11ページ]。
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 or CRL issuer and made freely available in a public repository. Each revoked certificate is identified in a CRL by its certificate serial number. When a certificate-using system uses a certificate (e.g., for verifying a remote user's digital signature), that system not only checks the certificate signature and validity but also acquires a suitably-recent CRL and checks that the certificate serial number is not on that CRL. The meaning of "suitably-recent" may vary with local policy, but it usually means the most recently-issued CRL. A new CRL is issued on a regular periodic basis (e.g., hourly, daily, or weekly). An entry is added to the CRL as part of the next update following notification of revocation. An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyond the revoked certificate's validity period.
X.509は証明書取消しの1つのメソッドを定義します。 このメソッドは定期的に証明書失効リスト(CRL)と呼ばれる署名しているデータ構造を発行する各カリフォルニアを伴います。 CRLは取り消された証明書を特定する時間の押し込まれたリストです(カリフォルニアかCRL発行人によって署名されて、公共の倉庫で自由に利用可能にされます)。 それぞれの取り消された証明書はCRLで証明書通し番号によって特定されます。 証明書を使用するシステムが証明書(例えば、リモート・ユーザーのデジタル署名について確かめるための)を使用すると、そのシステムは、証明書署名と正当性をチェックするだけではなく、適当に最近のCRLを獲得して、証明書通し番号がそのCRLにないのをチェックもします。 「適当に最近」の意味はローカルの方針で異なるかもしれませんが、通常、それは、大部分が最近CRLを発行したことを意味します。 新しいCRLが通常周期的ベースで発行される、(例えば、1時間ごと、毎日、または毎週、) エントリーは取消しの通知に続く次のアップデートの一部としてCRLに加えられます。 CRLからエントリーを取り消された証明書の有効期間に発行された1定期的に予定されているCRLに現れるまで取り除いてはいけません。
An advantage of this revocation method is that CRLs may be distributed by exactly the same means as certificates themselves, namely, via untrusted servers and untrusted communications.
この取消しメソッドの利点はすなわち、信頼されていないことを通して自分たちでサーバと信頼されていないコミュニケーションを証明するときCRLsがまさに同じ手段で分配されるかもしれないということです。
One limitation of the CRL revocation method, using untrusted communications and servers, is that the time granularity of revocation is limited to the CRL issue period. For example, if a revocation is reported now, that revocation will not be reliably notified to certificate-using systems until all currently issued CRLs are updated -- this may be up to one hour, one day, or one week depending on the frequency that CRLs are issued.
CRL取消しメソッドの1つの制限(信頼されていないコミュニケーションを使用して、サーバ)は、取消しの時間粒状がCRL問題の期間まで制限されるということです。 例えば、取消しが現在報告されると、その取消しは証明書を使用するシステムに確かにすべての現在発行されたCRLsをアップデートするまで通知されないでしょう--これは最大1時間であるかもしれません、ある日、または1週間CRLsが発行される頻度によって。
As with the X.509 v3 certificate format, in order to facilitate interoperable implementations from multiple vendors, the X.509 v2 CRL format needs to be profiled for Internet use. It is one goal of this document to specify that profile. However, this profile does not require the issuance of CRLs. Message formats and protocols supporting on-line revocation notification are defined in other PKIX specifications. On-line methods of revocation notification may be applicable in some environments as an alternative to the X.509 CRL. On-line revocation checking may significantly reduce the latency between a revocation report and the distribution of the information to relying parties. Once the CA accepts a revocation report as authentic and valid, any query to the on-line service will correctly reflect the certificate validation impacts of the revocation. However, these methods impose new security requirements: the certificate validator needs to trust the on-line validation service while the repository does not need to be trusted.
X.509 v3証明書形式のように、X.509 v2 CRL形式は、複数のベンダーから共同利用できる実装を容易にするのにインターネットの利用のために輪郭を描かれる必要があります。 それはそのプロフィールを指定するこのドキュメントの1つの目標です。 しかしながら、このプロフィールはCRLsの発行を必要としません。 オンライン取消しが通知であるとサポートするメッセージ・フォーマットとプロトコルが他のPKIX仕様に基づき定義されます。 X.509 CRLに代わる手段として取消し通知のオンラインメソッドはいくつかの環境で適切であるかもしれません。 オンライン取消しの照合は取消しレポートと情報の分配の間のレイテンシを信用パーティーにかなり減少させるかもしれません。 カリフォルニアが、取消しレポートが正統であって、有効であるといったん受け入れると、パソコン通信へのどんな質問も正しく取消しの証明書合法化影響を反映するでしょう。 しかしながら、これらのメソッドは新しいセキュリティ要件を課します: 証明書validatorは、倉庫が信じられる必要はありませんが、オンライン合法化サービスを信じる必要があります。
Housley, et. al. Standards Track [Page 12] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[12ページ]。
3.4 Operational Protocols
3.4 操作上のプロトコル
Operational protocols are required to deliver certificates and CRLs (or status information) to certificate using client systems. Provisions are needed for a variety of different means of certificate and CRL delivery, including distribution procedures based on LDAP, HTTP, FTP, and X.500. Operational protocols supporting these functions are defined in other PKIX specifications. These specifications may include definitions of message formats and procedures for supporting all of the above operational environments, including definitions of or references to appropriate MIME content types.
操作上のプロトコルが、クライアントシステムを使用することで証明書とCRLs(または、状態情報)を証明書に提供するのに必要です。条項が証明書とCRL配送のさまざまな異なった手段に必要です、LDAP、HTTP、FTP、およびX.500に基づく分配手順を含んでいて。 これらの機能をサポートする操作上のプロトコルが他のPKIX仕様に基づき定義されます。 これらの仕様は上の運用環境のすべてをサポートするためのメッセージ・フォーマットと手順の定義を含むかもしれません、適切なMIME content typeの定義か指示するものを含んでいて。
3.5 Management Protocols
3.5 管理プロトコル
Management protocols are required to support on-line interactions between PKI user and management entities. For example, a management protocol might be used between a CA and a client system with which a key pair is associated, or between two CAs 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を通した)にそれ自体を明らかにするプロセスです、そのユーザのために証明書か証明書を発行するそのカリフォルニアの前に。
(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.
(b)初期化: クライアントシステムがしっかりと作動できる前に、インフラストラクチャにおけるほかの場所に保存されるキーとの適切な関係を持っている主要資材をインストールするのが必要です。 例えば、クライアントは信じられたカリフォルニアの公開鍵と他の確実な情報でしっかりと初期化されて、証明書経路を有効にする際に使用される必要があります。
Furthermore, a client typically needs to be initialized with its
own key pair(s).
その上、クライアントは、通常それ自身の主要な組と共に初期化される必要があります。
(c) certification: This is the process in which a CA issues a
certificate for a user's public key, and returns that certificate
to the user's client system and/or posts that certificate in a
repository.
(c)証明: これはカリフォルニアが倉庫でユーザのクライアントシステムへのその証明書をユーザの公開鍵、およびリターンのための証明書に発行する、そして/または、その証明書をポストに発行するプロセスです。
(d) key pair recovery: As an option, user client key materials
(e.g., a user's private key used for encryption purposes) may be
backed up by a CA or a key backup system. If a user needs to
recover these backed up key materials (e.g., as a result of a
forgotten password or a lost key chain file), an on-line protocol
exchange may be needed to support such recovery.
(d) 主要な組回復: オプションとして、ユーザクライアント主要資材(例えば暗号化目的に使用されるユーザの秘密鍵)はカリフォルニアか主要なバックアップ・システムによって支援されるかもしれません。 ユーザが、主要資材で支持されたこれら(例えば、忘れられたパスワードか無くなっているキーチェーンファイルの結果、)を回復する必要があるなら、オンラインプロトコル交換が、そのような回復をサポートするのに必要であるかもしれません。
Housley, et. al. Standards Track [Page 13] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[13ページ]。
(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 defines a set of standard message formats supporting the above functions. The protocols for conveying these messages in different environments (e.g., e-mail, file transfer, and WWW) are described in those specifications.
仕様のPKIXシリーズは上の機能をサポートする1セットの標準のメッセージ・フォーマットを定義します。 異なった環境(例えば、メール、ファイル転送、およびWWW)におけるこれらのメッセージを伝えるためのプロトコルはそれらの仕様で説明されます。
4 Certificate and Certificate Extensions Profile
4の証明書と証明書拡大プロフィール
This section presents a profile for public key certificates that will foster interoperability and a reusable PKI. This section is based upon the X.509 v3 certificate format and the standard certificate extensions defined in [X.509]. The ISO/IEC and ITU-T documents use the 1997 version of ASN.1; while this document uses the 1988 ASN.1 syntax, the encoded certificate and standard extensions are equivalent. This section also defines private extensions required to support a PKI for the Internet community.
このセクションは相互運用性を伸ばす公開鍵証明書と再利用できるPKIのためのプロフィールを提示します。 このセクションは[X.509]で定義されたX.509 v3証明書書式と標準の証明書拡張子に基づいています。 ISO/IECとITU-Tドキュメントは1997年のASN.1のバージョンを使用します。 このドキュメントは1988ASN.1構文を使用しますが、コード化された証明書と標準の拡大は同等です。 また、このセクションはインターネットコミュニティのためにPKIをサポートするのに必要である個人的な拡大を定義します。
Certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability and limited special purpose requirements. In particular, the emphasis will be on supporting the use of X.509 v3 certificates for informal Internet electronic mail, IPsec, and WWW applications.
証明書は相互運用性目標の広いスペクトルと操作上と保証要件の、より広いスペクトルを含んでいるさまざまなアプリケーションと環境で使用されるかもしれません。 このドキュメントの目標は広い相互運用性と限られた専用要件を必要とする一般的適用のために一般的な基線を確立することです。 特に、強調がX.509 v3証明書の非公式のインターネット電子メール、IPsec、およびWWWアプリケーションの使用をサポートするところにあるでしょう。
Housley, et. al. Standards Track [Page 14] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[14ページ]。
4.1 Basic Certificate Fields
4.1 基本的な証明書分野
The X.509 v3 certificate basic syntax is as follows. For signature calculation, the data that is to be signed is encoded using the ASN.1 distinguished encoding rules (DER) [X.690]. ASN.1 DER encoding is a tag, length, value encoding system for each element.
X.509 v3の証明書の基本的な構文は以下の通りです。 署名計算において、署名されることになっているデータは、規則(DER)[X.690]をコード化しながら区別されたASN.1を使用することでコード化されます。 ASN.1DERコード化はタグ、長さ、それぞれの要素のシステムをコード化する値です。
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
以下を証明してください:= 系列tbsCertificate TBSCertificate、signatureAlgorithm AlgorithmIdentifier、signatureValueビット列
TBSCertificate ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier,
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
extensions [3] EXPLICIT Extensions OPTIONAL
-- If present, version MUST be v3
}
TBSCertificate:、:= 系列バージョン[0]EXPLICITバージョンDEFAULT v1、serialNumber CertificateSerialNumber、署名AlgorithmIdentifier、発行人Name(正当性Validity)はNameをかけます、subjectPublicKeyInfo SubjectPublicKeyInfo、issuerUniqueID[1]IMPLICIT UniqueIdentifier OPTIONAL--プレゼント、バージョンは、v2かv3 subjectUniqueID[2]IMPLICIT UniqueIdentifier OPTIONALであるに違いありません--存在しているなら、存在しているなら、バージョンがv2かv3拡大[3]EXPLICIT Extensions OPTIONALであるに違いないなら、バージョンはv3であるに違いありません。
Version ::= INTEGER { v1(0), v2(1), v3(2) }
バージョン:、:= 整数v1(0)、v2(1)、v3(2)
CertificateSerialNumber ::= INTEGER
CertificateSerialNumber:、:= 整数
Validity ::= SEQUENCE {
notBefore Time,
notAfter Time }
正当性:、:= 系列notBefore時間、notAfter時間
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
以下を調節してください:= 選択utcTime UTCTime、generalTime GeneralizedTime
UniqueIdentifier ::= BIT STRING
UniqueIdentifier:、:= ビット列
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
SubjectPublicKeyInfo:、:= 系列アルゴリズムAlgorithmIdentifier、subjectPublicKey BIT STRING
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
拡大:、:= 拡大の系列サイズ(1..MAX)
Housley, et. al. Standards Track [Page 15] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[15ページ]。
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 usually includes extensions which are described in section 4.2.
分野は対象、有効期間、および他の関連情報に関連している公開鍵という対象と発行人の名前を含んでいます。 分野はセクション4.1.2で詳細に説明されます。 通常、tbsCertificateはセクション4.2で説明される拡大を含んでいます。
4.1.1.2 signatureAlgorithm
4.1.1.2 signatureAlgorithm
The signatureAlgorithm field contains the identifier for the cryptographic algorithm used by the CA to sign this certificate. [PKIXALGS] lists supported signature algorithms, but other signature algorithms MAY also be supported.
signatureAlgorithm分野はこの証明書に署名するのにカリフォルニアによって使用された暗号アルゴリズムのための識別子を含んでいます。 [PKIXALGS]リストは署名アルゴリズムをサポートしましたが、また、他の署名アルゴリズムはサポートされるかもしれません。
An algorithm identifier is defined by the following ASN.1 structure:
アルゴリズム識別子は以下のASN.1構造によって定義されます:
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
AlgorithmIdentifier:、:= 系列アルゴリズムOBJECT IDENTIFIER、パラメタANY DEFINED BYアルゴリズムOPTIONAL
The algorithm identifier is used to identify a cryptographic algorithm. The OBJECT IDENTIFIER component identifies the algorithm (such as DSA with SHA-1). The contents of the optional parameters field will vary according to the algorithm identified.
アルゴリズム識別子は、暗号アルゴリズムを特定するのに使用されます。 OBJECT IDENTIFIERの部品はアルゴリズム(SHA-1とDSAなどの)を特定します。 特定されたアルゴリズムによると、任意のパラメタ分野のコンテンツは異なるでしょう。
This field MUST contain the same algorithm identifier as the signature field in the sequence tbsCertificate (section 4.1.2.3).
この分野が系列tbsCertificateの署名分野と同じアルゴリズム識別子を含まなければならない、(セクション4.1 .2 .3)。
4.1.1.3 signatureValue
4.1.1.3 signatureValue
The signatureValue field contains a digital signature computed upon the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded tbsCertificate is used as the input to the signature function. This
計算されて、signatureValue分野はデジタル署名を含んでいます。ASN.1DERはtbsCertificateをコード化しました。 署名への入力が機能するので、ASN.1DERは使用されるtbsCertificateをコード化しました。 これ
Housley, et. al. Standards Track [Page 16] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[16ページ]。
signature value is encoded as a BIT STRING and included in the signature field. The details of this process are specified for each of algorithms listed in [PKIXALGS].
署名値は、BIT STRINGとしてコード化されて、署名分野に含まれています。 このプロセスの細部は[PKIXALGS]に記載されたそれぞれのアルゴリズムに指定されます。
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 usually includes 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, version MUST be 3 (value is 2). If no extensions are present, but a UniqueIdentifier is present, the version SHOULD be 2 (value is 1); however version MAY be 3. If only basic fields are present, the version SHOULD be 1 (the value is omitted from the certificate as the default value); however the version MAY be 2 or 3.
この分野はコード化された証明書のバージョンについて説明します。 拡大がこのプロフィールで予想されるように使用されているとき、バージョンは3であるに違いありません(値は2です)。 拡大はいいえなら存在していますが、UniqueIdentifierは存在していて、バージョンはSHOULDです。2(値は1である)になってください。 しかしながら、バージョンは3であるかもしれません。 基礎体が存在してさえいる場合、よかったでしょう、バージョンSHOULD。1(値はデフォルト値として証明書から省略される)になってください。 しかしながら、バージョンは、2か3であるかもしれません。
Implementations SHOULD be prepared to accept any version certificate. At a minimum, conforming implementations MUST recognize version 3 certificates.
実装SHOULD、あらゆるバージョン証明書を受け入れるように用意してください。 最小限では、実装を従わせると、バージョン3証明書は認識されなければなりません。
Generation of version 2 certificates is not expected by implementations based on this profile.
バージョン2証明書の世代はこのプロフィールに基づく実装によって予想されません。
4.1.2.2 Serial number
4.1.2.2 通し番号
The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer.
通し番号はカリフォルニアによって各証明書に割り当てられた正の整数であるに違いありません。 与えられたカリフォルニアによって発行された各証明書に、それはユニークであるに違いありません(すなわち、発行人名と通し番号はユニークな証明書を特定します)。 CAsは、serialNumberが非負の整数であることを強制しなければなりません。
Housley, et. al. Standards Track [Page 17] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[17ページ]。
Given the uniqueness requirements above, serial numbers can be expected to contain long integers. Certificate users MUST be able to handle serialNumber values up to 20 octets. Conformant CAs MUST NOT use serialNumber values longer than 20 octets.
上記のユニークさの要件を考えて、通し番号が長整数型を含むと予想できます。 証明書ユーザはserialNumber値を20の八重奏まで扱うことができなければなりません。 Conformant CAsは20の八重奏より長い間、serialNumber値を使用してはいけません。
Note: Non-conforming CAs may issue certificates with serial numbers that are negative, or zero. Certificate users SHOULD be prepared to gracefully handle such certificates.
以下に注意してください。 非の従うCAsは負の通し番号、またはゼロで証明書を発行するかもしれません。 優雅にそのような証明書を扱うために準備されていて、ユーザSHOULDを証明してください。
4.1.2.3 Signature
4.1.2.3 署名
This field contains the algorithm identifier for the algorithm used by the CA to sign the certificate.
この分野は証明書に署名するのにカリフォルニアによって使用されたアルゴリズムのためのアルゴリズム識別子を含んでいます。
This field MUST contain the same algorithm identifier as the signatureAlgorithm field in the sequence Certificate (section 4.1.1.2). The contents of the optional parameters field will vary according to the algorithm identified. [PKIXALGS] lists the supported signature algorithms, but other signature algorithms MAY also be supported.
この分野が系列CertificateのsignatureAlgorithm分野と同じアルゴリズム識別子を含まなければならない、(セクション4.1 .1 .2)。 特定されたアルゴリズムによると、任意のパラメタ分野のコンテンツは異なるでしょう。 [PKIXALGS]はサポートしている署名アルゴリズムを記載しますが、また、他の署名アルゴリズムはサポートされるかもしれません。
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 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[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..MAX))、bmpString BMPString(サイズ(1..MAX))
The Name describes a hierarchical name composed of attributes, such as country name, and corresponding values, such as US. The type of the component AttributeValue is determined by the AttributeType; in general it will be a DirectoryString.
Nameは国の名などの属性で構成された、階層的な名前、および米国などの換算値について説明します。 コンポーネントAttributeValueのタイプはAttributeTypeによって決定されます。 一般に、それはDirectoryStringになるでしょう。
The DirectoryString type is defined as a choice of PrintableString, TeletexString, BMPString, UTF8String, and UniversalString. The UTF8String encoding [RFC 2279] 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の選択と定義されます。 [RFC2279]をコード化する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 NOTのために含まれています。新しい対象のための証明書のために、使用されます。 しかしながら、これらのタイプは名前が以前に確立された証明書で使用されるかもしれません。 これらのタイプで証明書を受け取るために準備されていて、ユーザSHOULDを証明してください。
Housley, et. al. Standards Track [Page 19] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[19ページ]。
In addition, many legacy implementations support names encoded in the ISO 8859-1 character set (Latin1String) [ISO 8859-1] but tag them as TeletexString. TeletexString encodes a larger character set than ISO 8859-1, but it encodes some characters differently. Implementations SHOULD be prepared to handle both encodings.
さらに、多くのレガシー実装が、ISO8859-1文字集合(Latin1String)[ISO8859-1]でコード化された名前をサポートしますが、TeletexStringとしてそれらにタグ付けをします。 TeletexStringはISO8859-1より大きい文字集合をコード化しますが、それは何人かのキャラクタを異なってコード化します。 実装SHOULD、両方のencodingsを扱うように用意してください。
As noted above, distinguished names are composed of attributes. This specification does not restrict the set of attribute types that may appear in names. However, conforming implementations MUST be prepared to receive certificates with issuer names containing the set of attribute types defined below. This specification RECOMMENDS support for additional attribute types.
上で述べたように、分類名は属性で構成されます。 この仕様は名前に現れるかもしれない属性タイプのセットを制限しません。 しかしながら、発行人名が以下で定義された属性タイプのセットを含んでいて証明書を受け取るように実装を従わせるのを準備しなければなりません。 この仕様RECOMMENDSは追加属性のためにタイプをサポートします。
Standard sets of attributes have been defined in the X.500 series of specifications [X.520]. Implementations of this specification MUST be prepared to receive the following standard attribute types in issuer and subject (section 4.1.2.6) names:
属性の標準セットは仕様[X.520]のX.500シリーズで定義されました。 標準の属性が発行人でタイプする以下と対象を受け取るようにこの仕様の実装を準備しなければなりません。(4.1の.2.6)名を区分してください:
* country,
* organization,
* organizational-unit,
* distinguished name qualifier,
* state or province name,
* common name (e.g., "Susan Housley"), and
* serial number.
* 国、組織、*組織的なユニット、*分類名資格を与える人、*州または州が命名する*、*一般名(例えば、「スーザンHousley」)、および*通し番号。
In addition, implementations of this specification SHOULD be prepared to receive the following standard attribute types in issuer and subject names:
追加、実装、この仕様SHOULDでは、準備されていて、以下の標準の属性を受けるのは発行人と対象名で以下をタイプします。
* locality,
* title,
* surname,
* given name,
* initials,
* pseudonym, and
* generation qualifier (e.g., "Jr.", "3rd", or "IV").
* 場所、*タイトル、*姓、*与えられた名、*イニシャル、*匿名、および*世代資格を与える人(例えば、「Jr.」、「3番目」、または「IV」)。
The syntax and associated object identifiers (OIDs) for these attribute types are provided in the ASN.1 modules in Appendix A.
これらの属性タイプへの構文と関連オブジェクト識別子(OIDs)をAppendix AのASN.1モジュールに提供します。
In addition, implementations of this specification MUST be prepared to receive the domainComponent attribute, as defined in [RFC 2247]. The Domain Name System (DNS) provides a hierarchical resource labeling system. This attribute provides a convenient mechanism for organizations that wish to use DNs that parallel their DNS names. This is not a replacement for the dNSName component of the
追加、仕様を準備しなければならないこの実装では、[RFC2247]で定義されるようにdomainComponent属性を受けてください。 ドメインネームシステム(DNS)は階層的なリソースラベリングシステムを提供します。 この属性は彼らのDNS名に沿うDNsを使用したがっている組織に便利なメカニズムを提供します。 これ、dNSNameとの交換はコンポーネントではありません。
Housley, et. al. Standards Track [Page 20] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[20ページ]。
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 Appendix A.
代替名分野。 実装は、そのような名前をDNS名に変換するのに必要ではありません。 この属性タイプのための構文の、そして、関連しているOIDをAppendix AのASN.1モジュールに提供します。
Certificate users MUST be prepared to process the issuer distinguished name and subject distinguished name (section 4.1.2.6) fields to perform name chaining for certification path validation (section 6). Name chaining is performed by matching the issuer distinguished name in one certificate with the subject name in a CA certificate.
証明書ユーザが発行人分類名と対象の分類名を処理する用意ができていなければならない、(セクション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. Conforming implementations are REQUIRED to implement the following name comparison rules:
この仕様は仕様のX.500シリーズで指定された名前比較の機能性の部分集合だけを必要とします。 従う実装は以下の名前が比較規則であると実装するREQUIREDです:
(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 this 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シリーズで定義された比較アルゴリズムを使用することが許可されています。 そのような実装は上で指定されたアルゴリズムで認識された名前マッチのスーパーセットを認識するでしょう。
Housley, et. al. Standards Track [Page 21] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[21ページ]。
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として証明書使用期限をコード化しなければなりません。
The validity period for a certificate is the period of time from notBefore through notAfter, inclusive.
証明書のための有効期間はnotBeforeからnotAfterの期間です。包括的。
4.1.2.5.1 UTCTime
4.1.2.5.1 UTCTime
The universal time type, UTCTime, is a standard ASN.1 type intended for representation of dates and time. UTCTime specifies the year through the two low order digits and time is specified to the precision of one minute or one second. UTCTime includes either Z (for Zulu, or Greenwich Mean Time) or a time differential.
ユニバーサルタイムタイプ(UTCTime)は日付と時間の表現のために意図する標準のASN.1タイプです。 UTCTimeは2つの下位桁を通して1年を指定します、そして、時間は微小な1秒か1秒の精度に指定されます。 UTCTimeはZ(ズールー族、またはグリニッジ標準時の間の)か時間デフ装置のどちらかを含んでいます。
For the purposes of this profile, UTCTime values MUST be expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming systems MUST interpret the year field (YY) as follows:
このプロフィールの目的のために、UTCTime値は、言い表されたグリニッジ標準時でなければならなく(ズールー族)、秒を含まなければなりません(すなわち、回はYYMMDDHHMMSSZです)、秒数がゼロでさえあるところで。 従うシステムは以下の1年の分野(YY)を解釈しなければなりません:
Where YY is greater than or equal to 50, the year SHALL be
interpreted as 19YY; and
どこYYは50以上、1年のSHALLであるか。19YYとして、解釈されてください。 そして
Where YY is less than 50, the year SHALL be interpreted as 20YY.
YYが50、1年のSHALL以下であるところでは、20YYとして解釈されてください。
4.1.2.5.2 GeneralizedTime
4.1.2.5.2 GeneralizedTime
The generalized time type, GeneralizedTime, is a standard ASN.1 type for variable precision representation of time. Optionally, the GeneralizedTime field can include a representation of the time differential between local and Greenwich Mean Time.
一般化された時間タイプ(GeneralizedTime)は時間の可変精度表現のための標準のASN.1タイプです。 任意に、GeneralizedTime分野は地方の間で特異な時間とグリニッジ標準時の表現を含むことができます。
For the purposes of this profile, GeneralizedTime values MUST be expressed 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値は断片的な秒を含んではいけません。
Housley, et. al. Standards Track [Page 22] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[22ページ]。
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 (section 4.1.2.4) in all certificates issued by the subject CA. If the subject is a CRL issuer (e.g., the key usage extension, as discussed in 4.2.1.3, is present and the value of cRLSign is TRUE) then the subject field MUST be populated with a non-empty distinguished name matching the contents of the issuer field (section 4.1.2.4) in all CRLs issued by the subject CRL issuer. If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical.
対象の分野は対象の公開鍵分野に保存される公開鍵に関連している実体を特定します。 対象の名前は対象の分野、そして/または、subjectAltName拡張子で運ばれるかもしれません。 対象がカリフォルニアである、(例えば、中で議論するとしての基本的な規制拡大、4.2、.1、.10、cAのプレゼントと値がTRUEであるということである、)、次に、非空の分類名が発行人分野のコンテンツに合っていて対象の分野に居住しなければならない、(セクション4.1 .2 .4) 対象のカリフォルニアによって発行されたすべての証明書で。 対象がCRL発行人である、(例えば、中で議論するとしての主要な用法拡大、4.2、.1、.3、cRLSignのプレゼントと値である、TRUE) 対象の分野に居住しなければならないその時が発行人分野のコンテンツに合っている非空の分類名である、(セクション4.1 .2 .4) 対象のCRL発行人によって発行されたすべてのCRLsで。 対象の命名情報がsubjectAltName拡張子だけで存在しているなら(例えばキーはEメールアドレスかURIだけに固まりました)、対象の名前は空の系列であるに違いありません、そして、subjectAltName拡張子は重要であるに違いありません。
Where it is non-empty, the subject field MUST contain an X.500 distinguished name (DN). The DN MUST be unique for each subject entity certified by the one CA as defined by the issuer 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 (section 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 Appendix A. 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では、この仕様のAppendix A.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 "と同じです)。
Housley, et. al. Standards Track [Page 23] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[23ページ]。
Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name field (section 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 (e.g., RSA, DSA, or Diffie-Hellman). The algorithm is identified using the AlgorithmIdentifier structure specified in section 4.1.1.2. The object identifiers for the supported algorithms and the methods for encoding the public key materials (public key and parameters) are specified in [PKIXALGS].
この分野は、公開鍵を運んで、キーが使用されているアルゴリズム(例えば、RSA、DSA、またはディフィー-ヘルマン)を特定するのに使用されます。 アルゴリズムは、セクション4.1.1で.2に指定されたAlgorithmIdentifier構造を使用することで特定されます。 サポートしているアルゴリズムのためのオブジェクト識別子と公開鍵の材料(公開鍵とパラメタ)をコード化するためのメソッドは[PKIXALGS]で指定されます。
4.1.2.8 Unique Identifiers
4.1.2.8 ユニークな識別子
These fields MUST only appear if the version is 2 or 3 (section 4.1.2.1). These fields MUST NOT appear if the version is 1. The subject and issuer unique identifiers are present in the certificate to handle the possibility of reuse of subject and/or issuer names over time. This profile RECOMMENDS that names not be reused for different entities and that Internet certificates not make use of unique identifiers. CAs conforming to this profile SHOULD NOT generate certificates with unique identifiers. Applications conforming to this profile SHOULD be capable of parsing unique identifiers.
これらの野原がバージョンが2か3であるなら現れるだけでよい、(セクション4.1 .2 .1)。 これらの野原はバージョンが1であるなら現れてはいけません。 対象と発行人のユニークな識別子は時間がたつにつれて対象、そして/または、発行人名の再利用の可能性を扱う証明書に存在しています。 これは名前がないRECOMMENDSの証明書がユニークな識別子の使用を作らない異なった実体とそのインターネットに再利用されていた状態で輪郭を描きます。 このプロフィールSHOULD NOTに従うCAsがユニークな識別子で証明書を作ります。 これに従うアプリケーションはSHOULDの輪郭を描きます。構文解析のユニークな識別子では、できてください。
4.1.2.9 Extensions
4.1.2.9 拡大
This field MUST only appear if the version is 3 (section 4.1.2.1). If present, this field is a SEQUENCE of one or more certificate extensions. The format and content of certificate extensions in the Internet PKI is defined in section 4.2.
この野原がバージョンが3であるなら現れるだけでよい、(セクション4.1 .2 .1)。 存在しているなら、この分野は1つ以上の証明書拡張子のSEQUENCEです。 インターネットPKIの証明書拡張子の書式と内容はセクション4.2で定義されます。
4.2 Certificate Extensions
4.2 証明書拡張子
The extensions defined for X.509 v3 certificates provide methods for associating additional attributes with users or public keys and for managing a 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 is designated as either critical or non-critical. A certificate using system MUST reject the certificate if it encounters a critical extension it does not recognize; however, a non-critical extension MAY be ignored if it is not recognized. The following sections present recommended extensions used within Internet
X.509 v3証明書のために定義された拡大は追加属性をユーザか公開鍵に関連づけて、証明階層構造を管理するためのメソッドを提供します。 また、X.509 v3証明書形式で、共同体は、それらの共同体にユニークな情報を運ぶために個人的な拡大を定義できます。 証明書における各拡大は重要であるか非臨界であるとして指定されます。 認識しない重要な拡大に遭遇するなら、証明書使用システムは証明書を拒絶しなければなりません。 しかしながら、それが認識されないなら、非臨界拡大は無視されるかもしれません。 現在のお勧めの拡大がインターネットの中で使用した以下のセクション
Housley, et. al. Standards Track [Page 24] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[24ページ]。
certificates and standard locations for information. Communities may elect to use additional extensions; however, caution ought to be exercised in adopting any critical extensions in certificates which might prevent use in a general context.
情報のための証明書と標準の位置。 共同体は、追加拡張子を使用するのを選ぶかもしれません。 しかしながら、警告は一般情勢における使用を防ぐかもしれない証明書におけるどんな重要な拡大も採用するのに訓練されるべきです。
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. A certificate MUST NOT include more than one instance of a particular extension. For example, a certificate may contain only one authority key identifier extension (section 4.2.1.1). An extension includes the boolean critical, with a default value of FALSE. The text for each extension specifies the acceptable values for the critical field.
各拡大はOIDとASN.1構造を含んでいます。 拡大が証明書に現れるとき、分野extnIDと対応するASN.1のコード化された構造が八重奏ストリングextnValueの値であるので、OIDは現れます。 証明書は特定の拡大の1つ以上のインスタンスを含んではいけません。 例えば、証明書が1つの権威の主要な識別子拡張子だけを含むかもしれない、(セクション4.2 .1 .1)。 拡大はFALSEのデフォルト値で重要な論理演算子を含んでいます。 各拡大のためのテキストは臨界磁場に許容値を指定します。
Conforming CAs MUST support key identifiers (sections 4.2.1.1 and 4.2.1.2), basic constraints (section 4.2.1.10), key usage (section 4.2.1.3), and certificate policies (section 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 (section 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.
4.2の.1の.3、)および証明書方針を区分してください。CAsを従わせると主要な識別子がサポートしなければならない、(セクション4.2.1、.1と4.2、.1、.2、)基本的な規制、(セクション4.2 .1 .10、)主要な用法、((セクション4.2.1の.5)拡大。 カリフォルニアが空の系列で対象の分野に証明書を発行するなら、カリフォルニアが、対象が代替の名前拡大であるとサポートしなければならない、(セクション4.2 .1 .7)。 残っている拡大のサポートはOPTIONALです。 CAsを従わせると、この仕様の中で特定されない拡大はサポートするかもしれません。 証明書発行人は重要であるような拡大をマークすると相互運用性が禁止されるかもしれないと警告されます。
At a minimum, applications conforming to this profile MUST recognize the following extensions: key usage (section 4.2.1.3), certificate policies (section 4.2.1.5), the subject alternative name (section 4.2.1.7), basic constraints (section 4.2.1.10), name constraints (section 4.2.1.11), policy constraints (section 4.2.1.12), extended key usage (section 4.2.1.13), and inhibit any-policy (section 4.2.1.15).
最小限では、このプロフィールに従うアプリケーションは以下の拡大を認識しなければなりません: 主要な用法、(セクション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、)禁止、いくらか、-、方針、(セクション4.2 .1 .15)。
In addition, applications conforming to this profile SHOULD recognize the authority and subject key identifier (sections 4.2.1.1 and 4.2.1.2), and policy mapping (section 4.2.1.6) extensions.
さらに、このプロフィールSHOULDに従うアプリケーションが権威と対象の主要な識別子を認識する、(セクション4.2.1、.1と4.2の.1の.2、)および方針マッピング、(セクション4.2.1の.6)拡大。
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
Housley, et. al. Standards Track [Page 25] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[25ページ]。
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 certification path construction. There is one exception; where a CA distributes its public key in the form of a "self-signed" certificate, the authority key identifier MAY be omitted. The signature on a self-signed certificate is generated with the private key associated with the certificate's subject public key. (This proves that the issuer possesses both the public and private keys.) In this case, the subject and authority key identifiers would be identical, but only the subject key identifier is needed for certification path building.
証明経路工事を容易にするためにCAsを従わせることによって作られたすべての証明書にauthorityKeyIdentifier拡張子のkeyIdentifier分野を含まなければなりません。 1つの例外があります。 カリフォルニアが「自己によって署名している」証明書の形で公開鍵を分配するところでは、権威の主要な識別子は省略されるかもしれません。 自己署名入りの証書における署名は証明書の対象の公開鍵に関連している秘密鍵で生成されます。 (これは、発行人には公衆と秘密鍵の両方があると立証します。) この場合、対象と権威重要識別子は同じでしょうが、対象の主要な識別子だけが証明経路ビルに必要です。
The value of the keyIdentifier field SHOULD be derived from the public key used to verify the certificate's signature or a method that generates unique values. Two common methods for generating key identifiers from the public key, and one common method for generating unique values, are described in section 4.2.1.2. Where a key identifier has not been previously established, this specification RECOMMENDS use of one of these methods for generating keyIdentifiers. Where a key identifier has been previously established, the CA SHOULD use the previously established identifier.
keyIdentifierの値は証明書の署名について確かめるのに使用される公開鍵かユニークな値を生成するメソッドから派生していた状態でSHOULDをさばきます。 公開鍵からの主要な識別子を生成するための2つの共通方法、およびユニークな値を生成するための1つの共通方法がセクション4.2.1で.2に説明されます。 主要な識別子が以前に確立されていないところでは、これらのメソッドの1つをkeyIdentifiersを生成するこの仕様RECOMMENDS使用します。 主要な識別子が以前に確立されたところでは、CA SHOULDは以前に確立した識別子を使用します。
This profile RECOMMENDS support for the key identifier method by all certificate users.
このプロフィールRECOMMENDSは主要な識別子メソッドのためにすべての証明書でユーザをサポートします。
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:、:= 八重奏ストリング
Housley, et. al. Standards Track [Page 26] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[26ページ]。
4.2.1.2 Subject Key Identifier
4.2.1.2 対象の主要な識別子
The subject key identifier extension provides a means of identifying certificates that contain a particular public key.
対象の主要な識別子拡張子は特定の公開鍵を含む証明書を特定する手段を提供します。
To facilitate certification path construction, this extension MUST appear in all conforming CA certificates, that is, all certificates including the basic constraints extension (section 4.2.1.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 (section 4.2.1.1) of certificates issued by the subject of this certificate.
カリフォルニア証明書、すなわち、すべての証明書を従わせて、基本的な規制拡大を含んでいて、証明経路工事を容易にするために、この拡大がすべてに現れなければならない、(セクション4.2 .1 .10) cAの値がTRUEであるところ。 対象の主要な識別子の値はAuthority Key Identifier拡張子の主要な識別子分野に置かれた値でなければなりません。(.1通の証明書が)この証明書の対象で発行したセクション4.2.1。
For CA certificates, subject key identifiers SHOULD be derived from the public key or a method that generates unique values. Two common methods for generating key identifiers from the public key are:
カリフォルニア証明書に関しては、ユニークな値を生成する公開鍵かメソッドから派生していた状態で主要な識別子SHOULDをかけてください。 公開鍵からの主要な識別子を生成するための2つの共通方法は以下の通りです。
(1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
value of the BIT STRING subjectPublicKey (excluding the tag,
length, and number of unused bits).
(1) keyIdentifierはBIT STRING subjectPublicKey(未使用のビットのタグ、長さ、および数を除いた)の価値の160ビットのSHA-1ハッシュで構成されます。
(2) The keyIdentifier is composed of a four bit type field with
the value 0100 followed by the least significant 60 bits of the
SHA-1 hash of the value of the BIT STRING subjectPublicKey
(excluding the tag, length, and number of unused bit string bits).
(2) keyIdentifierはBIT STRING subjectPublicKey(未使用のビット列ビットのタグ、長さ、および数を除いた)の価値のSHA-1ハッシュの最も重要でない60ビットに従って0100が続いた値で4ビット型分野から構成されます。
One common method for generating unique values is a monotonically increasing sequence of integers.
ユニークな値を生成するための1つの共通方法が整数の単調に増加する系列です。
For end entity certificates, the subject key identifier extension provides a means for identifying certificates containing the particular public key used in an application. Where an end entity has obtained multiple certificates, especially from multiple CAs, the subject key identifier provides a means to quickly identify the set of certificates containing a particular public key. To assist applications in identifying the appropriate end entity certificate, this extension SHOULD be included in all end entity certificates.
終わりの実体証明書のために、対象の主要な識別子拡張子はアプリケーションで使用される特定の公開鍵を含む証明書を特定するための手段を提供します。 終わりの実体が特に複数のCAsから複数の証明書を入手したところに、対象の主要な識別子はすぐに特定の公開鍵を含む証明書のセットを特定する手段を提供します。 適切な終わりの実体証明書、この拡大SHOULDを特定するのにアプリケーションを助けるには、すべての終わりの実体証明書で含められてください。
For end entity certificates, subject key identifiers SHOULD be derived from the public key. Two common methods for generating key identifiers from the public key are identified above.
終わりの実体証明書に関しては、公開鍵から派生していた状態で主要な識別子SHOULDをかけてください。 公開鍵からの主要な識別子を生成するための2つの共通方法が上で特定されます。
Where a key identifier has not been previously established, this specification RECOMMENDS use of one of these methods for generating keyIdentifiers. Where a key identifier has been previously established, the CA SHOULD use the previously established identifier.
主要な識別子が以前に確立されていないところでは、これらのメソッドの1つをkeyIdentifiersを生成するこの仕様RECOMMENDS使用します。 主要な識別子が以前に確立されたところでは、CA SHOULDは以前に確立した識別子を使用します。
This extension MUST NOT be marked critical.
重要であるとこの拡大をマークしてはいけません。
Housley, et. al. Standards Track [Page 27] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[27ページ]。
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
イドCe subjectKeyIdentifier、オブジェクト識別子:、:= イドCe14
SubjectKeyIdentifier ::= KeyIdentifier
SubjectKeyIdentifier:、:= KeyIdentifier
4.2.1.3 Key Usage
4.2.1.3 主要な用法
The key usage extension defines the purpose (e.g., encipherment, signature, certificate signing) of the key contained in the certificate. The usage restriction might be employed when a key that could be used for more than one operation is to be restricted. For example, when an RSA key should be used only to verify signatures on objects other than public key certificates and CRLs, the digitalSignature and/or nonRepudiation bits would be asserted. Likewise, when an RSA key should be used only for key management, the keyEncipherment bit would be asserted.
主要な用法拡大は証明書に含まれたキーの目的(例えば、暗号文、署名は署名を証明する)を定義します。 1つ以上の操作に使用できたキーが制限されることになっているとき、用法制限は使われるかもしれません。 例えば、RSAキーが使用されるべきですが、公開鍵証明書とCRLs以外のオブジェクトの上に署名について確かめるとき、digitalSignature、そして/または、nonRepudiationビットは断言されるでしょう。 RSAキーがかぎ管理にだけ使用されるべきであるとき、同様に、keyEnciphermentビットは断言されるでしょう。
This extension MUST appear in certificates that contain public keys that are used to validate digital signatures on other public key certificates or CRLs. When this extension appears, it SHOULD be marked critical.
この拡大は他の公開鍵の証明書かCRLsでデジタル署名を有効にするのに使用される公開鍵を含む証明書に現れなければなりません。 これであるときに、拡大は現れて、それは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),
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)
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 certificate signing (bit 5), or CRL signing
(bit 6). Digital signature mechanisms are often used for entity
authentication and data origin authentication with integrity.
対象の公開鍵がセキュリティが証明書署名(ビット5)以外のサービス、または(ビット6)に署名するCRLであるとサポートするのにデジタル署名メカニズムと共に使用されるとき、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.
In the case of later conflict, a reliable third party may
determine the authenticity of the signed data.
対象の公開鍵が間違って署名実体から守る非拒否しているサービスを提供するのに何らかの動作を否定しながら使用されるデジタル署名について確かめるのに使用されるとき、nonRepudiationビットは断言されます、証明書かCRL署名を除いて。 後の闘争の場合では、頼もしい第三者は署名しているデータの信憑性を決定するかもしれません。
Housley, et. al. Standards Track [Page 28] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[28ページ]。
Further distinctions between the digitalSignature and
nonRepudiation bits may be provided in specific certificate
policies.
digitalSignatureとnonRepudiationビットのさらなる区別を特定の証明書方針に提供するかもしれません。
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 is set.
対象の公開鍵が主要な輸送に使用されるとき、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 is set.
対象の公開鍵が主要な協定に使用されるとき、keyAgreementビットは断言されます。 例えば、そして、ディフィー-ヘルマンキーがかぎ管理に使用されることになっているとき、このビットは設定されます。
The keyCertSign bit is asserted when the subject public key is
used for verifying a signature on public key certificates. If the
keyCertSign bit is asserted, then the cA bit in the basic
constraints extension (section 4.2.1.10) MUST also be asserted.
対象の公開鍵が公開鍵証明書の上に署名について確かめるのに使用されるとき、keyCertSignビットは断言されます。 keyCertSignビットが断言されるならcAが基本的な規制拡大で噛み付いた、(セクション4.2 .1 また、.10について)断言しなければなりません。
The cRLSign bit is asserted when the subject public key is used
for verifying a signature on certificate revocation list (e.g., a
CRL, delta CRL, or an ARL). This bit MUST be asserted in
certificates that are used to verify signatures on CRLs.
対象の公開鍵が証明書失効リスト(例えば、CRL、デルタCRL、またはARL)で署名について確かめるのに使用されるとき、cRLSignビットは断言されます。 CRLsで署名について確かめるのに使用される証明書でこのビットについて断言しなければなりません。
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ビットが設定されるとき、対象の公開鍵は、主要な協定を実行している間、データを解読するのにだけ使用されるかもしれません。
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 [PKIXALGS].
このプロフィールはkeyUsage拡張子の具体化で設定されるかもしれないビットの組み合わせを制限しません。 しかしながら、特定のアルゴリズムのためのkeyUsage拡張子のための適切な値は[PKIXALGS]で指定されます。
4.2.1.4 Private Key Usage Period
4.2.1.4 秘密鍵用法の期間
This extension SHOULD NOT be used within the Internet PKI. CAs conforming to this profile MUST NOT generate certificates that include a critical private key usage period extension.
この拡大SHOULD NOT、インターネットPKIの中で使用されてください。 このプロフィールに従うCAsは重要な秘密鍵用法期間の延期を含んでいる証明書を作ってはいけません。
Housley, et. al. Standards Track [Page 29] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[29ページ]。
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 and the extension is non-critical.
秘密鍵用法期間の延期で、証明書発行人は証明書と異なった有効期間を秘密鍵に指定できます。 この拡大は使用のためにデジタル署名キーで意図します。 この拡大は2つの任意のコンポーネント、notBefore、およびnotAfterから成ります。 回前または後にオブジェクトに署名するのに使用される証明書SHOULD NOTに関連している秘密鍵は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. Optional qualifiers, which MAY be present, are not expected to change the definition of the policy.
証明書方針拡張子はより多くのある方針情報用語の系列を含んでいます。それはオブジェクト識別子(OID)と任意の資格を与える人からそれぞれ成ります。 任意の資格を与える人(出席しているかもしれません)が方針の定義を変えないと予想されます。
In an end entity certificate, these policy information terms indicate
the policy under which the certificate has been issued and the
purposes for which the certificate may be used. In a CA certificate,
these policy information terms limit the set of policies for
certification paths which include this certificate. When a CA does
not wish to limit the set of policies for certification paths which
include this certificate, it MAY assert the special policy anyPolicy,
with a value of { 2 5 29 32 0 }.
終わりの実体証明書では、これらの方針情報用語は証明書が発行された方針と証明書が使用されるかもしれない目的を示します。 カリフォルニア証明書では、これらの方針情報用語は方針のセットをこの証明書を含んでいる証明経路に制限します。 カリフォルニアは方針のセットをこの証明書を含んでいる証明経路に制限したがっていなくて、個別保険証券がanyPolicyであると断言するかもしれません、値でいつで2 5、29 32、0
Applications with specific policy requirements are expected to have a list of those policies 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をそのリストと比較すると予想されます。 この拡大が重要であるなら、経路合法化ソフトウェアは、この拡大(任意の資格を与える人を含んでいる)を解釈できなければならないか、または証明書を拒絶しなければなりません。
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
相互運用性を促進するために、その方針情報用語のこのプロフィールRECOMMENDSはOIDだけから成ります。 OIDだけが不十分であるところでは、このプロフィールは強く資格を与える人のその使用を推薦します。
Housley, et. al. Standards Track [Page 30] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[30ページ]。
be limited to those identified in this section. When qualifiers are used with the special policy anyPolicy, they MUST be limited to the qualifiers identified in this section.
このセクションで特定されたものに制限されてください。 資格を与える人が個別保険証券anyPolicyで使用されるとき、彼らをこのセクションで特定された資格を与える人に制限しなければなりません。
This specification defines two policy qualifier types for use by certificate policy writers and certificate issuers. The qualifier types are the CPS Pointer and User Notice qualifiers.
この仕様は証明書方針作家と証明書発行人による使用のために2つの方針資格を与える人タイプを定義します。 資格を与える人タイプは、CPS PointerとUser Notice資格を与える人です。
The CPS Pointer qualifier contains a pointer to a Certification Practice Statement (CPS) published by the CA. The pointer is in the form of a URI. Processing requirements for this qualifier are a local matter. No action is mandated by this specification regardless of the criticality value asserted for the extension.
CPS Pointer資格を与える人はカリフォルニアによって発行されたCertification Practice Statement(CPS)に指針を含みます。 指針がURIの形にあります。 この資格を与える人のための処理所要は地域にかかわる事柄です。 動作は全く拡大のために断言された臨界値にかかわらずこの仕様で強制されません。
User notice is intended for display to a relying party when a certificate is used. 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オプションで示された通知テキストの場所を見つけてください、テキストSHOULDを表示するその時。 さもなければ、explicitTextはSHOULDを結びます。表示します。
Note: While the explicitText has a maximum size of 200 characters, some non-conforming CAs exceed this limit. Therefore, certificate users SHOULD gracefully handle explicitText with more than 200 characters.
以下に注意してください。 explicitTextには200のキャラクタの最大サイズがある間、いくつかの非の従うCAsがこの限界を超えています。 したがって、証明書ユーザSHOULDは200以上のキャラクタと共にexplicitTextを優雅に扱います。
Housley, et. al. Standards Track [Page 31] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[31ページ]。
id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
イドCe certificatePolicies、オブジェクト識別子:、:= イドCe32
anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 }
anyPolicyオブジェクト識別子:、:= イドCe証明書方針0
certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
certificatePolicies:、:= PolicyInformationの系列サイズ(1..MAX)
PolicyInformation ::= SEQUENCE {
policyIdentifier CertPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL }
PolicyInformation:、:= 系列policyIdentifier CertPolicyId、PolicyQualifierInfo任意のpolicyQualifiers系列サイズ(1..MAX)
CertPolicyId ::= OBJECT IDENTIFIER
CertPolicyId:、:= オブジェクト識別子
PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId,
qualifier ANY DEFINED BY policyQualifierId }
PolicyQualifierInfo:、:= 系列policyQualifierId PolicyQualifierId、資格を与える人いずれもDEFINED BY policyQualifierId
-- policyQualifierIds for Internet policy qualifiers
-- インターネット方針資格を与える人のためのpolicyQualifierIds
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
イド-qt OBJECT IDENTIFIER:、:= イド-pkix2、イド-qt-cps OBJECT IDENTIFIER:、:= イド-qt1、イド-qt-unotice OBJECT IDENTIFIER:、:= イド-qt2
PolicyQualifierId ::=
OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
PolicyQualifierId:、:= オブジェクト識別子(イド-qt-cps| イド-qt-unotice)
Qualifier ::= CHOICE {
cPSuri CPSuri,
userNotice UserNotice }
資格を与える人:、:= 選択cPSuri CPSuri、userNotice UserNotice
CPSuri ::= IA5String
CPSuri:、:= IA5String
UserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL,
explicitText DisplayText OPTIONAL}
UserNotice:、:= 系列noticeRef NoticeReference任意であって、explicitText DisplayText任意です。
NoticeReference ::= SEQUENCE {
organization DisplayText,
noticeNumbers SEQUENCE OF INTEGER }
NoticeReference:、:= 系列組織DisplayText、noticeNumbers SEQUENCE OF INTEGER
DisplayText ::= CHOICE {
ia5String IA5String (SIZE (1..200)),
visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200)) }
DisplayText:、:= 選択ia5String IA5String(サイズ(1 .200))、visibleString VisibleString(サイズ(1 .200))、bmpString BMPString(サイズ(1 .200))、utf8String UTF8String(サイズ(1 .200))
Housley, et. al. Standards Track [Page 32] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[32ページ]。
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に同等であると考えるのを示します。
The issuing CA's users might accept an issuerDomainPolicy for certain applications. The policy mapping defines the list of policies associated with the subject CA that may be accepted as comparable to the issuerDomainPolicy.
発行CAのユーザはあるアプリケーションのためにissuerDomainPolicyを受け入れるかもしれません。 方針マッピングはissuerDomainPolicyに匹敵すると認められるかもしれない対象のカリフォルニアに関連している方針のリストを定義します。
Each issuerDomainPolicy named in the policy mapping extension SHOULD also be asserted in a certificate policies extension in the same certificate. Policies SHOULD NOT be mapped either to or from the special value anyPolicy (section 4.2.1.5).
各issuerDomainPolicyは方針でマッピング拡張子をSHOULDと命名しました、また、同じ証明書における証明書方針拡張子で断言されてください。 方針SHOULD NOT、anyPolicy、または、特別な値のanyPolicyから写像されてください、(セクション4.2 .1 .5)。
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; however, a DNS name MAY be represented in the subject field using the domainComponent attribute as described in section 4.1.2.4.
対象の代替名拡大で、追加アイデンティティは証明書の対象に付きます。 定義されたオプションはインターネット電子メールアドレス、DNS名、IPアドレス、および一定のリソース識別子(URI)を含んでいます。 完全に地方の定義を含んでいて、別の選択肢は存在しています。 複数の名前フォーム、およびそれぞれの名前フォームの複数のインスタンスが含まれるかもしれません。 証明書に縛られるそのようなアイデンティティがことであるときはいつも、拡大という対象の代替名(または、発行人代替名)を使用しなければなりません。 しかしながら、DNS名はセクション4.1.2で.4に説明されるようにdomainComponent属性を使用する対象の分野に表されるかもしれません。
Because the subject alternative name is considered to be definitively bound to the public key, all parts of the subject alternative name MUST be verified by the CA.
対象の代替名によって決定的に公開鍵に縛られると考えられるので、カリフォルニアは対象の代替名のすべての部分について確かめなければなりません。
Further, if the only subject identity included in the certificate is an alternative name form (e.g., an electronic mail address), then the subject distinguished name MUST be empty (an empty sequence), and the
そしてさらに、対象の分類名が証明書にアイデンティティを含んでいる唯一の対象が代替名フォーム(例えば、電子メールアドレス)であるなら空でなければならない、(空の系列)。
Housley, et. al. Standards Track [Page 33] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[33ページ]。
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 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].
subjectAltName拡張子がiPAddressを含むとき、八重奏ストリングに「ネットワークバイトオーダー」でアドレスを保存しなければなりません、RFC791[RFC791]で指定されるように。 それぞれの八重奏の最下位ビット(LSB)はネットワーク・アドレスの対応するバイトのLSBです。 IPバージョン4のために、RFC791で指定されるように、八重奏ストリングはまさに4つの八重奏を含まなければなりません。 IPバージョン6のために、RFC1883で指定されるように、八重奏ストリングはまさに16の八重奏[RFC1883]を含まなければなりません。
When the subjectAltName extension contains a domain name system label, the domain name MUST be stored in the dNSName (an IA5String). The name MUST be in the "preferred name syntax," as specified by 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 of " " MUST NOT be used. Finally, the use of the DNS representation for Internet mail addresses (wpolk.nist.gov instead of wpolk@nist.gov) MUST NOT be used; such identities are to be encoded as rfc822Name.
subjectAltName拡張子がドメイン名システムラベルを含むとき、dNSName(IA5String)にドメイン名を保存しなければなりません。 RFC1034[RFC1034]によって指定されるように名前が「都合のよい名前構文」であるに違いありません。 大文字と小文字手紙がドメイン名で許容されていますが、signifiganceが全くケースに取り付けられないことに注意してください。 さらに、ストリングをゆったり過ごしてください、「「法的なドメイン名、subjectAltNameは」 「使用されてはいけない」dNSNameとの拡大です。 最終的に、インターネット郵便の宛先( wpolk@nist.gov の代わりにwpolk.nist.gov)のDNS表現の使用を使用してはいけません。 そのようなアイデンティティはrfc822Nameとしてコード化されることです。
Note: work is currently underway to specify domain names in international character sets. Such names will likely not be accommodated by IA5String. Once this work is complete, this profile will be revisited and the appropriate functionality will be added.
以下に注意してください。 仕事は、現在、国際的な人物セットでドメイン名を指定するために進行中です。 そのような名前はIA5Stringによっておそらく対応されないでしょう。 この仕事がいったん完全になると、このプロフィールは再訪するでしょう、そして、適切な機能性は加えられるでしょう。
When the subjectAltName extension contains a URI, the name MUST be stored in the uniformResourceIdentifier (an IA5String). The name MUST NOT be a relative URL, and it 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であるはずがありません、そして、URL構文と符号化規則が[RFC1738]で指定したということにならなければなりません。 名前は体系(例えば、"http"か"ftp")と体系の特定の部分の両方を含まなければなりません。 特定の部分を計画しているのはホストとして完全修飾ドメイン名かIPアドレスを含まなければなりません。
Housley, et. al. Standards Track [Page 34] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[34ページ]。
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、実装がケースに入れる関係なしで体系とホストを比較しますが、残りを仮定しなければならない従うことを突き合わせて大文字と小文字を区別しているとき。
When the subjectAltName extension contains a DN in the directoryName, 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.
subjectAltName拡張子はdirectoryNameにDNを含んでいます、DN MUST。いつ、発行人名前欄によって定義されるようにもののカリフォルニアによって公認されたそれぞれの対象実体において、ユニークであってくださいか。 カリフォルニアは同じDNと共に同じ対象の実体に1通以上の証明書を発行するかもしれません。
The subjectAltName MAY carry additional name types through the use of the otherName field. The format and semantics of the name are indicated through the OBJECT IDENTIFIER in the type-id field. The name itself is conveyed as value field in otherName. For example, Kerberos [RFC 1510] format names can be encoded into the otherName, using using a Kerberos 5 principal name OID and a SEQUENCE of the Realm and the PrincipalName.
subjectAltNameはotherName分野の使用で追加名前タイプを運ぶかもしれません。 名前の形式と意味論はタイプイド分野のOBJECT IDENTIFIERを通して示されます。 名前自体はotherNameの値の分野として伝えられます。 例えば、ケルベロス[RFC1510]形式名をotherNameにコード化できます、ケルベロス5の主要な名前OIDを使用して、RealmとPrincipalNameのSEQUENCEを使用して。
Subject alternative names MAY be constrained in the same manner as subject distinguished names using the name constraints extension as described in section 4.2.1.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経路を処理するときそのような証明書に遭遇するクライアントの振舞いはこのプロフィールによって定義されません。
Finally, the semantics of subject alternative names that include wildcard characters (e.g., as a placeholder for a set of names) are not addressed by this specification. Applications with specific requirements MAY use such names, but they must define the semantics.
最終的に、ワイルドカードキャラクタ(例えば、1セットの名前のためのプレースホルダとしての)を含んでいる対象の代替名の意味論はこの仕様で扱われません。 決められた一定の要求があるアプリケーションはそのような名前を使用するかもしれませんが、それらは意味論を定義しなければなりません。
id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
イドCe subjectAltName、オブジェクト識別子:、:= イドCe17
SubjectAltName ::= GeneralNames
SubjectAltName:、:= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralNames:、:= GeneralNameの系列サイズ(1..MAX)
Housley, et. al. Standards Track [Page 35] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[35ページ]。
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 used to convey identification attributes (e.g., nationality) of the subject. The extension is defined as a sequence of one or more attributes. This extension MUST be non-critical.
テーマ別ディレクトリ属性拡張子は、対象の識別属性(例えば、国籍)を伝えるのに使用されます。 拡大は1つ以上の属性の系列と定義されます。 この拡大は非臨界であるに違いありません。
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 the maximum depth of valid certification paths that include this certificate.
基本的な規制拡大は、証明書の対象がこの証明書を含んでいる有効な証明経路のカリフォルニアと最大の深さであるかどうか特定します。
Housley, et. al. Standards Track [Page 36] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[36ページ]。
The cA boolean indicates whether the certified public key belongs to a CA. If the cA boolean is not asserted, then the keyCertSign bit in the key usage extension MUST NOT be asserted.
cA論理演算子は、公認された公開鍵がカリフォルニアに属すかどうかを示します。 cA論理演算子が断言されないなら、主要な用法拡大におけるkeyCertSignビットについて断言してはいけません。
The pathLenConstraint field is meaningful only if the cA boolean is asserted and the key usage extension asserts the keyCertSign bit (section 4.2.1.3). In this case, it gives the maximum number of non- self-issued intermediate certificates that may follow this certificate in a valid certification path. A certificate is self- issued if the DNs that appear in the subject and issuer fields are identical and are not empty. (Note: The last certificate in the certification path is not an intermediate certificate, and is not included in this limit. Usually, the last certificate is an end entity certificate, but it can be a CA certificate.) A pathLenConstraint of zero indicates that only one more certificate may follow in a valid certification path. Where it appears, the pathLenConstraint field MUST be greater than or equal to zero. Where pathLenConstraint does not appear, no limit is imposed.
cA論理演算子が断言される場合にだけpathLenConstraint分野が重要であり、主要な用法拡大がkeyCertSignビットについて断言する、(セクション4.2 .1 .3)。 この場合、それは有効な証明経路でこの証明書に従うかもしれない自己によって非発行された中間的証明書の最大数を与えます。 証明書は対象と発行人分野に現れるDNsが同じであり、空でないなら発行された自己です。 (以下に注意してください。 証明経路における最後の証明書は、中間的証明書でなく、またこの限界に含まれていません。 通常、最後の証明書は終わりの実体証明書ですが、それはカリフォルニア証明書であるかもしれません。) ゼロのpathLenConstraintは、もうひとつの証明書だけが有効な証明経路で従うかもしれないのを示します。 現れるところでは、pathLenConstraint分野はゼロ以上であるに違いありません。 pathLenConstraintが現れないところでは、限界は全く課されません。
This extension MUST appear as a critical extension in all CA certificates that contain public keys used to validate digital signatures on certificates. This extension MAY appear as a critical or non-critical extension in CA certificates that contain public keys used exclusively for purposes other than validating digital signatures on certificates. Such CA certificates include ones that contain public keys used exclusively for validating digital signatures on CRLs and ones that contain key management public keys used with certificate enrollment protocols. This extension MAY appear as a critical or non-critical extension in end entity certificates.
公開鍵を含むすべてのカリフォルニア証明書における重要な拡大が以前は証明書の上によくデジタル署名を有効にしていたとき、この拡大は現れなければなりません。 この拡大は排他的な証明書の上にデジタル署名を有効にするのを除いた目的に使用される公開鍵を含むカリフォルニア証明書における重要であるか非臨界である拡大として現れるかもしれません。 そのようなカリフォルニア証明書はCRLsで排他的にデジタル署名を有効にするのに使用される公開鍵を含むものと証明書登録プロトコルと共に使用されるかぎ管理公開鍵を含むものを含んでいます。 この拡大は終わりの実体証明書における重要であるか非臨界である拡大として現れるかもしれません。
CAs MUST NOT include the pathLenConstraint field unless the cA boolean is asserted and the key usage extension asserts the keyCertSign bit.
cA論理演算子が断言されて、主要な用法拡大がkeyCertSignビットは断言しない場合、CAsがpathLenConstraint分野を含んではいけません。
id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
イドCe basicConstraints、オブジェクト識別子:、:= イドCe19
BasicConstraints ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
BasicConstraints:、:= 系列cA論理演算子は誤っていて、pathLenConstraint整数(0..MAX)任意の状態でデフォルトとします。
4.2.1.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 MUST be located. Restrictions apply to the subject distinguished name and apply to subject alternative names. Restrictions apply only when the
名前規制拡張子(カリフォルニア証明書だけで使用しなければならない)は証明経路のその後の証明書のすべての対象の名前が位置しなければならない名前スペースを示します。 制限は、対象の分類名に適用して、対象の代替名に適用されます。 制限はいつだけを当てはまるか。
Housley, et. al. Standards Track [Page 37] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[37ページ]。
specified name form is present. If no name of the type is in the certificate, the certificate is acceptable.
指定された名前フォームは存在しています。 タイプの名前が全く証明書にないなら、証明書は許容できます。
Name constraints are not applied to certificates whose issuer and subject are identical (unless the certificate is the final certificate in the path). (This could prevent CAs that use name constraints from employing self-issued certificates to implement key rollover.)
名前規制は発行人と対象が同じである証明書に適用されません(証明書が経路の確定品質証明書でないなら)。 (これは、名前規制を使用するCAsが主要なロールオーバーを実装するのに自己によって発行された証明書を使うのを防ぐかもしれません。)
Restrictions are defined in terms of permitted or excluded name subtrees. Any name matching a restriction in the excludedSubtrees field is invalid regardless of information appearing in the permittedSubtrees. This extension MUST be critical.
制限は受入れられたか除かれた名前下位木で定義されます。 excludedSubtrees分野で制限に合っているどんな名前もpermittedSubtreesに現れる情報にかかわらず無効です。 この拡大は重要であるに違いありません。
Within this profile, the minimum and maximum fields are not used with any name forms, thus minimum MUST be zero, and maximum MUST be absent.
このプロフィールの中では、最小の、そして、最大の分野はどんな名前フォームと共にも使用されません、そして、その結果、最小であるのが、ゼロであるに違いなく、最大は欠けているに違いありません。
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 Internet mail addresses MAY specify a particular mailbox, all addresses at a particular host, or all mailboxes in a domain. To indicate a particular mailbox, the constraint is the complete mail address. For example, "root@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 not Internet mail addresses on the host "xyz.com".
インターネット郵便の宛先の名前規制は特定のメールボックス、特定のホストのすべてのアドレス、またはドメインのすべてのメールボックスを指定するかもしれません。 特定のメールボックスを示すために、規制は完全な郵便の宛先です。 例えば、" 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 DNS name that can be constructed by simply adding to the left hand side of the name satisfies the name constraint. For example, www.foo.bar.com would satisfy the constraint but foo1.bar.com would not.
DNS名前制限はfoo.bar.comとして表されます。 単に名前の左側に加えることによって構成できるどんなDNS名も規制という名前を満たします。 例えば、www.foo.bar.comは規制を満たすでしょうが、foo1.bar.comは満たさないでしょう。
Legacy implementations exist where an RFC 822 name is embedded in the subject distinguished name in an attribute of type EmailAddress (section 4.1.2.6). When rfc822 names are constrained, but the
レガシー実装がRFC822名がタイプEmailAddressの属性で対象の分類名に埋め込まれているところに存在している、(セクション4.1 .2 .6)。 しかしrfc822名は抑制されます。
Housley, et. al. Standards Track [Page 38] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[38ページ]。
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.
証明書は対象の代替名を含まないで、対象の分類名における、タイプEmailAddressの属性に規制というrfc822名を適用しなければなりません。 Appendix Aで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 MUST 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拡張子に使用されるコード化に名前制限を述べなければならないのを含意します。
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 is 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]を表すためにRFC1519(CIDR)のスタイルでコード化された8(8)八重奏を含まなければなりません。 IPv6アドレスのために、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)
Housley, et. al. Standards Track [Page 39] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[39ページ]。
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, the value of requireExplicitPolicy indicates the number of additional certificates that may appear in the path before an explicit policy is required for the entire path. When an explicit policy is required, it is necessary for all certificates in the path to contain an acceptable policy identifier in the certificate policies extension. An acceptable policy identifier is the identifier of a policy required by the user of the certification path or the identifier of a policy which has been declared equivalent through policy mapping.
requireExplicitPolicy分野が存在しているなら、requireExplicitPolicyの値は明白な方針が全体の経路に必要である前に経路に現れるかもしれない追加証明書の数を示します。 明白な方針が必要であるときに、経路のすべての証明書が証明書方針拡張子に許容できる方針識別子を含むのが必要です。 許容できる方針識別子は、証明経路のユーザによって必要とされた方針に関する識別子か方針マッピングを通して同等であると宣言された方針に関する識別子です。
Conforming CAs MUST NOT issue certificates where policy constraints is a empty sequence. That is, at least one of the inhibitPolicyMapping field or the requireExplicitPolicy field MUST be present. The behavior of clients that encounter a empty 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
4.2.1.13 拡張主要な用法
This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension. In general, this extension will appear only in end entity certificates. This extension is defined as follows:
この拡大は公認された公開鍵が目的か主要な用法拡大で示された基本的な目的に代わって使用されるかもしれない1つ以上の目的を示します。 一般に、この拡大は終わりの実体証明書だけに現れるでしょう。 この拡大は以下の通り定義されます:
Housley, et. al. Standards Track [Page 40] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[40ページ]。
id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
イドCe extKeyUsage、オブジェクト識別子:、:= イドCe37
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
ExtKeyUsageSyntax:、:= KeyPurposeIdの系列サイズ(1..MAX)
KeyPurposeId ::= OBJECT IDENTIFIER
KeyPurposeId:、:= オブジェクト識別子
Key purposes may be defined by any organization with a need. Object identifiers used to identify key purposes MUST be assigned in accordance with IANA or ITU-T Recommendation X.660 [X.660].
主要な目的は必要性があるどんな組織によっても定義されるかもしれません。 IANAかITU-T Recommendation X.660[X.660]によると、主要な目的を特定するのに使用されるオブジェクト識別子を割り当てなければなりません。
This extension MAY, at the option of the certificate issuer, be either critical or non-critical.
証明書発行人の選択のときに、この拡大は、重要であるか、または非臨界であるかもしれません。
If the extension is present, then the certificate MUST only be used for one of the purposes indicated. If multiple purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present. Certificate using applications MAY require that a particular purpose be indicated in order for the certificate to be acceptable to that application.
拡大が存在しているなら、示された目的の1つに証明書を使用するだけでよいです。 複数の目的が示されるなら、アプリケーションは目的が示したすべてを認識する必要はありません、本来の目的が存在している限り。 アプリケーションを使用する証明書は、特定の目的が証明書がそのアプリケーションに許容できるために示されるのを必要とするかもしれません。
If a CA includes extended key usages to satisfy such applications, but does not wish to restrict usages of the key, the CA can include the special keyPurposeID anyExtendedKeyUsage. If the anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT be critical.
カリフォルニアがそのようなアプリケーションを満たすために拡張主要な用法を含んでいますが、キーの使用法を制限したくないなら、カリフォルニアは特別なkeyPurposeID anyExtendedKeyUsageを含むことができます。 anyExtendedKeyUsage keyPurposeIDであるなら、プレゼント、拡張子はSHOULD NOTです。重要であってください。
If a certificate contains both a key usage extension and an extended key usage extension, then both extensions MUST be processed independently and the certificate MUST only be used for a purpose consistent with both extensions. If there is no purpose consistent with both extensions, then the certificate MUST NOT be used for any purpose.
証明書が主要な用法拡大と拡張主要な用法拡大の両方を含んでいるなら、独自に両方の拡大を処理しなければなりません、そして、両方の拡大と一致した目的に証明書を使用するだけでよいです。 両方の拡大と一致したどんな目的もなければ、どんな目的にも証明書を使用してはいけません。
The following key usage purposes are defined:
以下の主要な用法目的は定義されます:
anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
anyExtendedKeyUsageオブジェクト識別子:、:= イドCe extKeyUsage、0
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
イド-kp OBJECT IDENTIFIER:、:= イド-pkix3
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
イド-kp-serverAuthオブジェクト識別子:、:= イド-kp1--TLS WWWサーバ証明--一貫するかもしれない主要な用法ビット: digitalSignature--keyEnciphermentかkeyAgreement
id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
-- TLS WWW client authentication
-- Key usage bits that may be consistent: digitalSignature
-- and/or keyAgreement
イド-kp-clientAuthオブジェクト識別子:、:= イド-kp2--TLS WWWクライアント認証--一貫するかもしれない主要な用法ビット: digitalSignature and/or keyAgreement
Housley, et. al. Standards Track [Page 41] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[41ページ]。
id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
-- Signing of downloadable executable code
-- Key usage bits that may be consistent: digitalSignature
イド-kp-codeSigningオブジェクト識別子:、:= イド-kp3--ダウンローダブルな実行コードの署名--一貫するかもしれない主要な用法ビット: digitalSignature
id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
-- E-mail protection
-- Key usage bits that may be consistent: digitalSignature,
-- nonRepudiation, and/or (keyEncipherment or keyAgreement)
イド-kp-emailProtectionオブジェクト識別子:、:= イド-kp4--電子メール保護--一貫するかもしれない主要な用法ビット: そして/またはdigitalSignature--nonRepudiation。(keyEnciphermentかkeyAgreement)
id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
-- Binding the hash of an object to a time
-- Key usage bits that may be consistent: digitalSignature
-- and/or nonRepudiation
イド-kp-timeStampingオブジェクト識別子:、:= イド-kp8--時間までオブジェクトのハッシュを縛ります--一貫するかもしれない主要な用法ビット: digitalSignature and/or nonRepudiation
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
-- Signing OCSP responses
-- Key usage bits that may be consistent: digitalSignature
-- and/or nonRepudiation
イド-kp-OCSPSigningオブジェクト識別子:、:= イド-kp9--署名OCSP応答--一貫するかもしれない主要な用法ビット: digitalSignature and/or nonRepudiation
4.2.1.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、非臨界であり、このプロフィールRECOMMENDSだけがこれのためにCAsとアプリケーションで拡大をサポートするということになってください。 CRL管理のさらなる議論はセクション5に含まれています。
The cRLDistributionPoints extension is a SEQUENCE of DistributionPoint. A DistributionPoint consists of three fields, each of which is optional: distributionPoint, reasons, and cRLIssuer. While each of these fields is optional, a DistributionPoint MUST NOT consist of only the reasons field; either distributionPoint or cRLIssuer MUST be present. If the certificate issuer is not the CRL issuer, then the cRLIssuer field MUST be present and contain the Name of the CRL issuer. If the certificate issuer is also the CRL issuer, then the cRLIssuer field MUST be omitted and the distributionPoint field MUST be present. If the distributionPoint field is omitted, cRLIssuer MUST be present and include a Name corresponding to an X.500 or LDAP directory entry where the CRL is located.
cRLDistributionPoints拡張子はDistributionPointのSEQUENCEです。 DistributionPointは3つの分野から成ります:それはそれぞれ任意です。 distributionPoint、理由、およびcRLIssuer。 それぞれのこれらの分野が任意である間、DistributionPointは理由分野だけから成ってはいけません。 distributionPointかcRLIssuerのどちらかが存在していなければなりません。 証明書発行人がCRL発行人でないなら、cRLIssuer分野は、存在していて、CRL発行人のNameを含まなければなりません。 また、証明書発行人がCRL発行人であるなら、cRLIssuer分野を省略しなければなりません、そして、distributionPoint分野は存在していなければなりません。 distributionPoint分野が省略されるなら、cRLIssuerは存在していて、CRLが位置しているX.500かLDAPディレクトリエントリに対応するNameを含まなければなりません。
When the distributionPoint field is present, it contains either a SEQUENCE of general names or a single value, nameRelativeToCRLIssuer. If the cRLDistributionPoints extension contains a general name of type URI, the following semantics MUST be assumed: the URI is a pointer to the current CRL for the associated reasons and will be issued by the associated cRLIssuer. 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.
nameRelativeToCRLIssuer、distributionPoint分野が存在しているとき、それは一般名のSEQUENCEかただ一つの値のどちらかを含んでいます。 cRLDistributionPoints拡張子がタイプURIの一般名を含んでいるなら、以下の意味論を想定しなければなりません: URIは、関連理由による現在のCRLへの指針であり、関連cRLIssuerによって発行されるでしょう。 URIのための期待値はものが4.2で.7に.1を定義したということです。 他の値のための処理規則はこの仕様で定義されません。
Housley, et. al. Standards Track [Page 42] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[42ページ]。
If the DistributionPointName contains multiple values, each name describes a different mechanism to obtain the same CRL. For example, the same CRL could be available for retrieval through both LDAP and HTTP.
DistributionPointNameが複数の値を含んでいるなら、各名前は、同じCRLを入手するために異なったメカニズムについて説明します。 例えば、LDAPとHTTPの両方のを通した検索について、同じCRLがあるかもしれません。
If the DistributionPointName contains the single value nameRelativeToCRLIssuer, the value provides a distinguished name fragment. The fragment is appended to the X.500 distinguished name of the CRL issuer to obtain the distribution point name. If the cRLIssuer field in the DistributionPoint is present, then the name fragment is appended to the distinguished name that it contains; otherwise, the name fragment is appended to the certificate issuer distinguished name. The DistributionPointName MUST NOT use the nameRealtiveToCRLIssuer alternative when cRLIssuer contains more than one distinguished name.
DistributionPointNameが独身の値のnameRelativeToCRLIssuerを含んでいるなら、値は分類名断片を提供します。 分配ポイント名を得るためにCRL発行人のX.500分類名に断片を追加します。 DistributionPointのcRLIssuer分野が存在しているなら、それが含む分類名に名前断片を追加します。 さもなければ、証明書発行人分類名に名前断片を追加します。 cRLIssuerが1つ以上の分類名を含んでいると、DistributionPointNameはnameRealtiveToCRLIssuer代替手段を使用してはいけません。
If the DistributionPoint omits the reasons field, the CRL MUST include revocation information for all reasons.
DistributionPointが理由分野を省略するなら、CRL MUSTはすべての理由で取消し情報を含んでいます。
The cRLIssuer identifies the entity who signs and issues the CRL. If present, the cRLIssuer MUST contain at least one an X.500 distinguished name (DN), and MAY also contain other name forms. Since the cRLIssuer is compared to the CRL issuer name, the X.501 type Name MUST follow the encoding rules for the issuer name field in the certificate (section 4.1.2.4).
cRLIssuerはCRLに署名して、発行する実体を特定します。 存在しているなら、cRLIssuerは少なくともX.500分類名(DN)あたり1つを含まなければならなくて、また、他の名前フォームを含むかもしれません。cRLIssuerがCRL発行人名と比べるのでX.501タイプNameが証明書の発行人名前欄への符号化規則に従わなければならない、(セクション4.1 .2 .4)。
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 }
イドCe cRLDistributionPoints、オブジェクト識別子:、:= イドCe31
CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
CRLDistributionPoints:、:= DistributionPointの系列サイズ(1..MAX)
DistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
reasons [1] ReasonFlags OPTIONAL,
cRLIssuer [2] GeneralNames OPTIONAL }
DistributionPoint:、:= 系列distributionPoint[0]DistributionPointName OPTIONAL、理由[1]ReasonFlags OPTIONAL、cRLIssuer[2]GeneralNames OPTIONAL
DistributionPointName ::= CHOICE {
fullName [0] GeneralNames,
nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
DistributionPointName:、:= 選択fullName[0]GeneralNames、nameRelativeToCRLIssuer[1]RelativeDistinguishedName
Housley, et. al. Standards Track [Page 43] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[43ページ]。
ReasonFlags ::= BIT STRING {
unused (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
privilegeWithdrawn (7),
aACompromise (8) }
ReasonFlags:、:= ビット列未使用の(0)(keyCompromise(1)、cACompromise(2)、affiliationChanged(3))は(4)、cessationOfOperation(5)、certificateHold(6)、privilegeWithdrawn(7)、aACompromise(8)に取って代わりました。
4.2.1.15 Inhibit Any-Policy
4.2.1.15、禁止、いくらか、-、方針
The inhibit any-policy extension can be used in certificates issued
to CAs. The inhibit any-policy indicates that the special anyPolicy
OID, with the value { 2 5 29 32 0 }, is not considered an explicit
match for other certificate policies. The value indicates the number
of additional certificates that may appear in the path before
anyPolicy is no longer permitted. For example, a value of one
indicates that anyPolicy may be processed in certificates issued by
the subject of this certificate, but not in additional certificates
in the path.
禁止、いくらか、-、方針、CAsに発行された証明書で拡張子を使用できます。 禁止、いくらか、-、方針、それを示す、値がある特別なanyPolicy OID、2 5、29 32、0、他の証明書方針のための明白なマッチであることは考えられません。 値はanyPolicyがもう受入れられない前に経路に現れるかもしれない追加証明書の数を示します。 例えば、1の値は、anyPolicyが経路でこの証明書の対象によって発行された証明書で処理されますが、追加証明書で処理されるかもしれないというわけではないのを示します。
This extension MUST be critical.
この拡大は重要であるに違いありません。
id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }
イドCe inhibitAnyPolicy、オブジェクト識別子:、:= イドCe54
InhibitAnyPolicy ::= SkipCerts
InhibitAnyPolicy:、:= SkipCerts
SkipCerts ::= INTEGER (0..MAX)
SkipCerts:、:= 整数(0..MAX)
4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point)
4.2.1.16 最も新鮮なCRL(通称デルタCRL分配ポイント)
The freshest CRL extension identifies how delta CRL information is obtained. The extension MUST be non-critical. Further discussion of CRL management is contained in section 5.
最も新鮮なCRL拡張子はどうデルタCRL情報を得るかを特定します。 拡大は非臨界であるに違いありません。 CRL管理のさらなる議論はセクション5に含まれています。
The same syntax is used for this extension and the cRLDistributionPoints extension, and is described in section 4.2.1.14. The same conventions apply to both extensions.
同じ構文は、この拡大とcRLDistributionPoints拡張子に使用されて、セクション4.2.1で.14に説明されます。 同じコンベンションは両方の拡大に適用されます。
id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
イドCe freshestCRL、オブジェクト識別子:、:= イドCe46
FreshestCRL ::= CRLDistributionPoints
FreshestCRL:、:= CRLDistributionPoints
Housley, et. al. Standards Track [Page 44] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[44ページ]。
4.2.2 Private Internet Extensions
4.2.2 個人的なインターネット拡大
This section defines two extensions for use in the Internet Public Key Infrastructure. These extensions may be used to direct applications to on-line information about the issuing CA or the subject. 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.
このセクションはインターネット公開鍵暗号基盤における使用のために2つの拡大を定義します。 これらの拡張子は、発行カリフォルニアかこの件のオンライン情報にアプリケーションを向けるのに使用されるかもしれません。 情報が複数のフォームで利用可能であるかもしれないので、各拡大はIA5String値の系列です。それはそれぞれURIを表します。 URIはそれとなく情報の位置と形式と情報を得るためのメソッドを指定します。
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 arc id-pkix. Any future extensions defined for the Internet PKI are also expected to be defined under the arc id-pe.
オブジェクト識別子は個人的な拡大のために定義されます。 個人的な拡大に関連しているオブジェクト識別子はアークイド-pkixの中のアークイド-peの下で定義されます。 また、アークイド-peの下でインターネットPKIと定義されたどんな今後の拡大も定義されると予想されます。
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
イド-pkix OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
イド-pe OBJECT IDENTIFIER:、:= イド-pkix1
4.2.2.1 Authority Information Access
4.2.2.1 権威情報アクセス
The authority information access extension indicates how to access 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 end entity 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
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
イド広告ocsp OBJECT IDENTIFIER、:、:= イド広告1
Housley, et. al. Standards Track [Page 45] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[45ページ]。
Each entry in the sequence AuthorityInfoAccessSyntax describes the format and location of additional information provided by the CA that 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 two accessMethod OIDs: id-ad-caIssuers and id-ad-ocsp.
このプロフィールは2accessMethod OIDsを定義します: イド広告caIssuers、そして、イド広告ocsp。
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 containing this extension. The referenced CA issuers description is intended to aid certificate users in the selection of a certification path that terminates at a point trusted by the certificate user.
イド広告caIssuers OID、追加情報がこの拡大を含む証明書を発行したカリフォルニアより優れた証明書を発行したCAsを記載するとき、使用されます。 参照をつけられたカリフォルニアの発行人記述が証明書ユーザによって信じられたポイントで終わる証明経路の選択で証明書ユーザを支援することを意図します。
When id-ad-caIssuers appears as accessMethod, the accessLocation field describes the referenced description server and the access protocol to obtain the referenced description. The accessLocation field is defined as a GeneralName, which can take several forms. 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. The entry for that directoryName contains CA certificates in the crossCertificatePair attribute. When the information is available via electronic mail, accessLocation MUST be an rfc822Name. The semantics of other id-ad-caIssuers accessLocation name forms are not defined.
いつ、イド広告caIssuers、accessMethod、accessLocation分野が参照をつけられた記述サーバについて説明して、アクセスが参照をつけられた記述を得るために議定書を作るのに従って、現れるか。 accessLocation分野はGeneralNameと定義されます。(GeneralNameは数個の形を取ることができます)。accessLocationは情報がhttp、ftp、またはldapを通して利用可能であるところのuniformResourceIdentifierであるに違いありません。 情報がディレクトリAccessプロトコル(DAP)で利用可能であるところでは、accessLocationはdirectoryNameであるに違いありません。 そのdirectoryNameのためのエントリーはcrossCertificatePair属性にカリフォルニア証明書を含んでいます。 情報が電子メールを通して利用可能であるときに、accessLocationはrfc822Nameであるに違いありません。 他の意味論、イド広告caIssuers accessLocation、名前書式は定義されません。
The id-ad-ocsp OID is used when revocation information for the certificate containing this extension is available using the Online Certificate Status Protocol (OCSP) [RFC 2560].
イド広告ocsp OID、この拡大を含む証明書のための取消し情報がOnline Certificate Statusプロトコル(OCSP)[RFC2560]を使用することで利用可能であるときに、使用されます。
When id-ad-ocsp appears as accessMethod, the accessLocation field is the location of the OCSP responder, using the conventions defined in [RFC 2560].
イド広告ocspがaccessMethodとして現れるとき、accessLocation分野はOCSP応答者の位置です、[RFC2560]で定義されたコンベンションを使用して。
Additional access descriptors may be defined in other PKIX specifications.
追加アクセス記述子は他のPKIX仕様に基づき定義されるかもしれません。
4.2.2.2 Subject Information Access
4.2.2.2 対象の情報アクセス
The subject information access extension indicates how to access information and services for the subject of the certificate in which the extension appears. When the subject is a CA, information and services may include certificate validation services and CA policy
対象の情報アクセス拡張子は拡大が現れる証明書の対象のための情報とサービスにアクセスする方法を示します。 対象がカリフォルニアであるときに、情報とサービスは証明書合法化サービスとカリフォルニア方針を含むかもしれません。
Housley, et. al. Standards Track [Page 46] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[46ページ]。
data. When the subject is an end entity, the information describes the type of services offered and how to access them. In this case, the contents of this extension are defined in the protocol specifications for the suported services. This extension may be included in subject or CA certificates, and it MUST be non-critical.
データ。 対象が終わりの実体であるときに、情報は提供されたサービスとどうそれらにアクセスするかに関するタイプについて説明します。 この場合、この拡大の内容はsuportedサービスのためのプロトコル仕様に基づき定義されます。 この拡大は対象かカリフォルニア証明書に含まれるかもしれません、そして、それは非臨界であるに違いありません。
id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
イド-pe-subjectInfoAccessオブジェクト識別子:、:= イド-pe11
SubjectInfoAccessSyntax ::=
SEQUENCE SIZE (1..MAX) OF AccessDescription
SubjectInfoAccessSyntax:、:= AccessDescriptionの系列サイズ(1..MAX)
AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER,
accessLocation GeneralName }
AccessDescription:、:= 系列accessMethodオブジェクト識別子、accessLocation GeneralName
Each entry in the sequence SubjectInfoAccessSyntax describes the format and location of additional information provided by the subject of the certificate in which this extension appears. The type and format of the information 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.
系列SubjectInfoAccessSyntaxにおける各エントリーはこの拡大が現れる証明書の対象によって提供された追加情報の形式と位置について説明します。 情報のタイプと形式はaccessMethod分野によって指定されます。 accessLocation分野は情報の位置を指定します。 回収機構は、accessMethodによって含意されるか、またはaccessLocationによって指定されるかもしれません。
This profile defines one access method to be used when the subject is a CA, and one access method to be used when the subject is an end entity. Additional access methods may be defined in the future in the protocol specifications for other services.
このプロフィールは1つの対象がカリフォルニアであるときに使用されるべきアクセスメソッド、および1つの対象が終わりの実体であるときに使用されるべきアクセスメソッドを定義します。 追加アクセス法は将来、他のサービスのためのプロトコル仕様に基づき定義されるかもしれません。
The id-ad-caRepository OID is used when the subject is a CA, and publishes its certificates and CRLs (if issued) in a repository. 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 of accessLocation (when accessMethod is id-ad-caRepository) are not defined by this specification.
イド広告caRepository OID、対象がカリフォルニアであるときに、使用されていて、倉庫でその証明書とCRLs(発行されるなら)を発表します。 accessLocation分野はGeneralNameと定義されます。(GeneralNameは数個の形を取ることができます)。accessLocationは情報がhttp、ftp、またはldapを通して利用可能であるところのuniformResourceIdentifierであるに違いありません。 情報がディレクトリアクセス・プロトコルで利用可能であるところでは(ちょと浸してください)、accessLocationはdirectoryNameであるに違いありません。 情報が電子メールを通して利用可能であるときに、accessLocationはrfc822Nameであるに違いありません。 他の名前の意味論がaccessLocationを形成する、(accessMethodがいつか、イド広告caRepository、)、この仕様で、定義されません。
The id-ad-timeStamping OID is used when the subject offers timestamping services using the Time Stamp Protocol defined in [PKIXTSA]. Where the timestamping services are available via http or ftp, accessLocation MUST be a uniformResourceIdentifier. Where the timestamping services are available via electronic mail, accessLocation MUST be an rfc822Name. Where timestamping services
イド広告timeStamping OID、対象が[PKIXTSA]で定義されたTime Stampプロトコルを使用することでサービスをtimestampingに提供するとき、使用されます。 timestampingサービスがhttpかftpを通して利用可能であるところでは、accessLocationはuniformResourceIdentifierであるに違いありません。 timestampingサービスが電子メールを通して利用可能であるところでは、accessLocationはrfc822Nameであるに違いありません。 サービスをtimestampingします。
Housley, et. al. Standards Track [Page 47] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[47ページ]。
are available using TCP/IP, the dNSName or ipAddress name forms may be used. The semantics of other name forms of accessLocation (when accessMethod is id-ad-timeStamping) are not defined by this specification.
利用可能な使用はTCP/IP、dNSNameであるかipAddress名前フォームが使用されるかもしれません。 accessLocationの他の名前フォームの意味論、(accessMethodがいつか、イド広告timeStamping、)、この仕様で、定義されません。
Additional access descriptors may be defined in other PKIX specifications.
追加アクセス記述子は他のPKIX仕様に基づき定義されるかもしれません。
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
イド広告OBJECT IDENTIFIER:、:= イド-pkix48
id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
イド広告caRepository、オブジェクト識別子:、:= イド広告5
id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
イド広告timeStamping、オブジェクト識別子:、:= イド広告3
5 CRL and CRL Extensions Profile
5のCRLとCRL拡大プロフィール
As discussed above, one goal of this X.509 v2 CRL profile is to foster the creation of an interoperable and reusable Internet PKI. To achieve this goal, guidelines for the use of extensions are specified, and some assumptions are made about the nature of information included in the CRL.
上で議論するように、このX.509 v2 CRLプロフィールの1つの目標は共同利用できて再利用できるインターネットPKIの作成を伸ばすことです。 この目標を達成するために、拡張子の使用のためのガイドラインは指定されます、そして、いくつかの仮定がCRLに情報を含む自然に関してされます。
CRLs may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and an even broader spectrum of operational and assurance requirements. This profile establishes a common baseline for generic applications requiring broad interoperability. The profile defines a set of information that can be expected in every CRL. Also, the profile defines common locations within the CRL for frequently used attributes as well as common representations for these attributes.
CRLsは相互運用性目標の広いスペクトルと操作上と保証要件のさらに広いスペクトルを含んでいるさまざまなアプリケーションと環境で使用されるかもしれません。 このプロフィールは広い相互運用性を必要とする一般的適用のために一般的な基線を確立します。 プロフィールはあらゆるCRLで予想できる1セットの情報を定義します。 また、プロフィールはこれらの属性の共通表現と同様に頻繁に使用された属性のためにCRLの中で一般的な位置を定義します。
CRL issuers issue CRLs. In general, the CRL issuer is the CA. CAs publish CRLs to provide status information about the certificates they issued. However, a CA may delegate this responsibility to another trusted authority. Whenever the CRL issuer is not the CA that issued the certificates, the CRL is referred to as an indirect CRL.
CRL発行人はCRLsを発行します。 一般に、CRL発行人はカリフォルニアです。 CAsは、それらが発行した証明書の状態情報を提供するためにCRLsを発行します。 しかしながら、カリフォルニアは別の信じられた権威へこの責任を代表として派遣するかもしれません。 CRL発行人が証明書を発行したカリフォルニアでないときはいつも、CRLは間接的なCRLと呼ばれます。
Each CRL has a particular scope. The CRL scope is the set of certificates that could appear on a given CRL. For example, the scope could be "all certificates issued by CA X", "all CA certificates issued by CA X", "all certificates issued by CA X that have been revoked for reasons of key compromise and CA compromise", or could be a set of certificates based on arbitrary local information, such as "all certificates issued to the NIST employees located in Boulder".
各CRLには、特定の範囲があります。 CRL範囲は与えられたCRLに現れることができた証明書のセットです。 範囲は、例えば、「カリフォルニアXによって発行されたすべての証明書」、「カリフォルニアXによって発行されたすべてのカリフォルニア証明書」、「主要な感染の理由で取り消されたカリフォルニアXによって発行されたすべての証明書とカリフォルニアは妥協するかもしれない」か、任意のローカルの情報に基づく、1セットの証明書であるかもしれません、「ボウルダーに位置するNIST従業員に発行されたすべての証明書」などのように。
Housley, et. al. Standards Track [Page 48] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[48ページ]。
A complete CRL lists all unexpired certificates, within its scope, that have been revoked for one of the revocation reasons covered by the CRL scope. The CRL issuer MAY also generate delta CRLs. A delta CRL only lists those certificates, within its scope, whose revocation status has changed since the issuance of a referenced complete CRL. The referenced complete CRL is referred to as a base CRL. The scope of a delta CRL MUST be the same as the base CRL that it references.
完全なCRLは範囲の中のCRL範囲でカバーされた取消し理由の1つで取り消されたすべての満期になっていない証明書をリストアップします。 また、CRL発行人は、デルタがCRLsであると生成するかもしれません。 CRLデルタはそれらの証明書をリストアップするだけです、範囲の中で。参照をつけられた完全なCRLの発行以来範囲の取消し状態は変化しています。 参照をつけられた完全なCRLはベースCRLと呼ばれます。 CRL MUSTデルタでは、それが参照をつけるベース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. When CRLs are issued, the CRLs MUST be version 2 CRLs, include the date by which the next CRL will be issued in the nextUpdate field (section 5.1.2.5), include the CRL number extension (section 5.2.3), and include the authority key identifier extension (section 5.2.1). Conforming applications that support CRLs are REQUIRED to process both version 1 and version 2 complete CRLs that provide revocation information for all certificates issued by one CA. Conforming applications are NOT REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs with a scope other than all certificates issued by one CA.
他の取消しか証明書状態メカニズムを提供するなら、従うCAsはCRLsを発行するのが必要ではありません。 CRLsが発行されるとき、CRLsがバージョン2CRLsであるに違いなく、インクルードが日付である、次のCRLがnextUpdate分野で発行される(セクション5.1 .2 .5) CRL数の拡張子(セクション5.2.3)を含めてください。そうすれば、インクルードは権威の主要な識別子拡張子(セクション5.2.1)を含めます。 CRLsをサポートする従うアプリケーションは1カリフォルニアによって発行されたすべての証明書のための取消し情報を提供するバージョン1とバージョン2の完全なCRLsの両方を処理するREQUIREDです。 従うアプリケーションはデルタCRLsのサポート処理、間接的なCRLs、またはCRLsへの1カリフォルニアによって発行されたすべての証明書以外の範囲があるNOT REQUIREDです。
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ビット列
Housley, et. al. Standards Track [Page 49] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[49ページ]。
TBSCertList ::= SEQUENCE {
version Version OPTIONAL,
-- if present, MUST be v2
signature AlgorithmIdentifier,
issuer Name,
thisUpdate Time,
nextUpdate Time OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate Time,
crlEntryExtensions Extensions OPTIONAL
-- if present, MUST be v2
} OPTIONAL,
crlExtensions [0] EXPLICIT Extensions OPTIONAL
-- if present, MUST be v2
}
TBSCertList:、:= 系列バージョンバージョンOPTIONAL--、発行人v2署名がAlgorithmIdentifierであったに違いないならNameを寄贈してください、thisUpdate Time、nextUpdate Time OPTIONAL、revokedCertificates SEQUENCE OF SEQUENCE、userCertificate CertificateSerialNumber、revocationDate Time、crlEntryExtensions Extensions OPTIONAL--存在している、v2でなければならない、OPTIONAL、crlExtensions[0]EXPLICIT Extensions OPTIONAL--存在している、v2でなければなりません。
-- Version, Time, CertificateSerialNumber, and Extensions -- are all defined in the ASN.1 in section 4.1
-- バージョン、Time、CertificateSerialNumber、およびExtensions--セクション4.1のASN.1ですべて定義されます。
-- AlgorithmIdentifier is defined in section 4.1.1.2
-- AlgorithmIdentifier、定義されたコネセクション4.1.1は.2です。
The following items describe the use of the X.509 v2 CRL in the Internet PKI.
以下の項目はインターネットPKIでのX.509 v2 CRLの使用について説明します。
5.1.1 CertificateList Fields
5.1.1 CertificateList分野
The CertificateList is a SEQUENCE of three required fields. The fields are described in detail in the following subsections.
CertificateListは3つの必須項目のSEQUENCEです。 分野は以下の小区分で詳細に説明されます。
5.1.1.1 tbsCertList
5.1.1.1 tbsCertList
The first field in the sequence is the tbsCertList. This field is itself a sequence containing the name of the issuer, issue date, issue date of the next list, the optional list of revoked certificates, and optional CRL extensions. When there are no revoked certificates, the revoked certificates list is absent. When one or more certificates are revoked, each entry on the revoked certificate list is defined by a sequence of user certificate serial number, revocation date, and optional CRL entry extensions.
系列における最初の分野はtbsCertListです。 この分野は、それ自体で発行人の名前、問題日付、次のリストの問題日付、取り消された証明書の任意のリストを含む系列と任意のCRL拡張子です。 証明書が取り消されないとき、取り消された証明書リストは欠けています。 1通以上の証明書が取り消されるとき、取り消された証明書リストの上の各エントリーはユーザー証明書通し番号、取消し期日、および任意のCRLエントリー拡張子の系列によって定義されます。
5.1.1.2 signatureAlgorithm
5.1.1.2 signatureAlgorithm
The signatureAlgorithm field contains the algorithm identifier for the algorithm used by the CRL issuer to sign the CertificateList. The field is of type AlgorithmIdentifier, which is defined in section 4.1.1.2. [PKIXALGS] lists the supported algorithms for this specification, but other signature algorithms MAY also be supported.
signatureAlgorithm分野はCertificateListにサインするのにCRL発行人によって使用されたアルゴリズムのためのアルゴリズム識別子を含んでいます。 タイプAlgorithmIdentifierには分野があります。(AlgorithmIdentifierはセクション4.1.1で.2に定義されます)。 [PKIXALGS]はこの仕様のために支持されたアルゴリズムを記載しますが、また、他の署名アルゴリズムは支持されるかもしれません。
Housley, et. al. Standards Track [Page 50] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[50ページ]。
This field MUST contain the same algorithm identifier as the signature field in the sequence tbsCertList (section 5.1.2.2).
この分野が系列tbsCertListの署名分野と同じアルゴリズム識別子を含まなければならない、(セクション5.1 .2 .2)。
5.1.1.3 signatureValue
5.1.1.3 signatureValue
The signatureValue field contains a digital signature computed upon the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList is used as the input to the signature function. This signature value is encoded as a BIT STRING and included in the CRL signatureValue field. The details of this process are specified for each of the supported algorithms in [PKIXALGS].
計算されて、signatureValue分野はデジタル署名を含んでいます。ASN.1DERはtbsCertListをコード化しました。 署名への入力が機能するので、ASN.1DERは使用されるtbsCertListをコード化しました。 この署名値は、BIT STRINGとしてコード化されて、CRL signatureValue分野に含まれています。 この過程の詳細は[PKIXALGS]のそれぞれの支持されたアルゴリズムに指定されます。
CAs that are also CRL issuers MAY use one private key to digitally sign certificates and CRLs, or MAY use separate private keys to digitally sign certificates and CRLs. When separate private keys are employed, each of the public keys associated with these private keys is placed in a separate certificate, one with the keyCertSign bit set in the key usage extension, and one with the cRLSign bit set in the key usage extension (section 4.2.1.3). When separate private keys are employed, certificates issued by the CA contain one authority key identifier, and the corresponding CRLs contain a different authority key identifier. The use of separate CA certificates for validation of certificate signatures and CRL signatures can offer improved security characteristics; however, it imposes a burden on applications, and it might limit interoperability. Many applications construct a certification path, and then validate the certification path (section 6). CRL checking in turn requires a separate certification path to be constructed and validated for the CA's CRL signature validation certificate. Applications that perform CRL checking MUST support certification path validation when certificates and CRLs are digitally signed with the same CA private key. These applications SHOULD support certification path validation when certificates and CRLs are digitally signed with different CA private keys.
またCRL発行人であるCAsは、証明書とCRLsにデジタルにサインするのに1つの秘密鍵を使用するか、または証明書とCRLsにデジタルにサインするのに別々の秘密鍵を使用するかもしれません。 別々の秘密鍵が採用しているとき、これらの秘密鍵に関連づけられたそれぞれの公開鍵は別々の証明書に置かれます、主要な用法拡大で設定されたkeyCertSignビットがある1、cRLSignビットがある1つが主要な用法拡大でセットした、(セクション4.2 .1 .3)。 別々の秘密鍵が採用しているとき、カリフォルニアによって発行された証明書は1つの権威の主要な識別子を含んでいます、そして、対応するCRLsは異なった権威主要な識別子を含んでいます。 別々のカリフォルニア証明書の証明書署名とCRL署名の合法化の使用は改良されたセキュリティの特性を提供できます。 しかしながら、アプリケーションのときに、負担をかけます、そして、相互運用性を制限するかもしれません。 多くのアプリケーションが、証明経路を構成して、次に、証明経路(セクション6)を有効にします。 順番にチェックするCRLは、別々の証明経路がCAのCRL署名合法化証明書のために組み立てられて、有効にされるのを必要とします。 証明書とCRLsが同じカリフォルニア秘密鍵をデジタルに契約されるとき、CRLの照合を実行するアプリケーションは証明経路合法化を支持しなければなりません。 これらのアプリケーションの証明書であることのSHOULDサポート証明経路合法化とCRLsは異なったカリフォルニア秘密鍵をデジタルに契約されます。
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 CRL issuer will issue the next CRL.
サインされるべき証明書リスト、またはTBSCertListが必要で任意の分野の系列です。 必須項目はCRL発行人、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
任意の分野は取り消された証明書とCRL拡張子のリストを含んでいます。 取り消された証明書リストがカリフォルニアがどんな満期になっていない証明書も取り消していないケースを支えるために任意である、それ、それ
Housley, et. al. Standards Track [Page 51] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[51ページ]。
has issued. The profile requires conforming CRL issuers to use the CRL number and authority key identifier CRL extensions in all CRLs issued.
発行させます。 プロフィールは、すべてのCRLsのCRL拡張子が発行したCRL番号と権威の主要な識別子を使用するためにCRL発行人を従わせるのを必要とします。
5.1.2.1 Version
5.1.2.1 バージョン
This optional field describes the version of the encoded CRL. When extensions are used, as required by this profile, this field MUST be present and MUST specify version 2 (the integer value is 1).
この任意の分野はコード化されたCRLのバージョンについて説明します。 拡張子が必要に応じてこのプロフィールによって使用されるとき、この分野は、存在していなければならなくて、バージョン2を指定しなければなりません(整数値は1です)。
5.1.2.2 Signature
5.1.2.2 署名
This field contains the algorithm identifier for the algorithm used to sign the CRL. [PKIXALGS] lists OIDs for the most popular signature algorithms used in the Internet PKI.
この分野はCRLにサインするのに使用されるアルゴリズムのためのアルゴリズム識別子を含んでいます。 最もポピュラーな署名アルゴリズムのための[PKIXALGS]リストOIDsはインターネットでPKIを使用しました。
This field MUST contain the same algorithm identifier as the signatureAlgorithm field in the sequence CertificateList (section 5.1.1.2).
この分野が系列CertificateListのsignatureAlgorithm分野と同じアルゴリズム識別子を含まなければならない、(セクション5.1 .1 .2)。
5.1.2.3 Issuer Name
5.1.2.3 発行人名
The issuer name identifies the entity 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 (section 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 (section 4.1.2.4).
サインされて、CRLが発行されて、発行人名はそうした実体を特定します。 発行人のアイデンティティは発行人名前欄で運ばれます。 また、代替名フォームはissuerAltName拡張子(セクション5.2.2)に現れるかもしれません。 発行人名前欄はX.500分類名(DN)を含まなければなりません。 発行人名前欄がX.501タイプNameと定義されて、証明書の発行人名前欄に符号化規則に従わなければならない、(セクション4.1 .2 .4)。
5.1.2.4 This Update
5.1.2.4 このアップデート
This field indicates the issue date of this CRL. ThisUpdate may be encoded as UTCTime or GeneralizedTime.
この分野はこのCRLの問題日付を示します。 ThisUpdateはUTCTimeかGeneralizedTimeとしてコード化されるかもしれません。
CRL issuers conforming to this profile MUST encode thisUpdate as UTCTime for dates through the year 2049. CRL issuers conforming to this profile MUST encode thisUpdate as GeneralizedTime for dates in the year 2050 or later.
このプロフィールに従うCRL発行人は日付から2049年のUTCTimeとしてthisUpdateをコード化しなければなりません。 このプロフィールに従うCRL発行人は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を定義しました。
Housley, et. al. Standards Track [Page 52] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[52ページ]。
5.1.2.5 Next Update
5.1.2.5 次のアップデート
This field indicates the date by which the next CRL will be issued. The next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date. CRL issuers SHOULD issue CRLs with a nextUpdate time equal to or later than all previous CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime.
この分野は日付を次のCRLが発行される示します。 示された日以前、次のCRLを発行できましたが、示された期日より遅いいずれもそれに発行されないでしょう。 CRL発行人SHOULDはUTCTimeとしての等しいかnextUpdate時間前のすべてのCRLs. nextUpdateがコード化されるかもしれないより後半かGeneralizedTimeと共にCRLsを発行します。
This profile requires inclusion of nextUpdate in all CRLs issued by conforming CRL issuers. 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.
このプロフィールはCRL発行人を従わせることによって発行されたすべてのCRLsでのnextUpdateの包含を必要とします。 TBSCertListのASN.1構文がこの野原をOPTIONALとして記述することに注意してください。(OPTIONALは[X.509]で定義されるASN.1構造と一致しています)。 nextUpdateを省略するクライアント処理CRLsの動きはこのプロフィールによって指定されません。
CRL issuers conforming to this profile MUST encode nextUpdate as UTCTime for dates through the year 2049. CRL issuers conforming to this profile MUST encode nextUpdate as GeneralizedTime for dates in the year 2050 or later.
このプロフィールに従うCRL発行人は日付から2049年のUTCTimeとしてnextUpdateをコード化しなければなりません。 このプロフィールに従うCRL発行人は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 取り消された証明書
When there are no revoked certificates, the revoked certificates list MUST be absent. Otherwise, revoked certificates are listed by their serial numbers. Certificates revoked by the CA are uniquely identified by the certificate serial number. The date on which the revocation occurred is specified. The time for revocationDate MUST be expressed as described in section 5.1.2.4. Additional information may be supplied in CRL entry extensions; CRL entry extensions are discussed in section 5.3.
証明書が取り消されないとき、取り消された証明書リストは欠けているに違いありません。 さもなければ、取り消された証明書はそれらの通し番号によってリストアップされます。 カリフォルニアによって取り消された証明書は証明書通し番号によって唯一特定されます。 取消しが起こった日付は指定されます。 セクション5.1.2で.4について説明するとき、revocationDateのための時間を言い表さなければなりません。 CRLエントリー拡張子で追加情報を提供するかもしれません。 セクション5.3でCRLエントリー拡張子について議論します。
5.1.2.7 Extensions
5.1.2.7 拡大
This field may only appear if the version is 2 (section 5.1.2.1). If present, this field is a sequence of one or more CRL extensions. CRL extensions are discussed in section 5.2.
この野原がバージョンが2である場合にだけ現れるかもしれない、(セクション5.1 .2 .1)。 存在しているなら、この分野は1つ以上のCRL拡張子の系列です。 セクション5.2でCRL拡張子について議論します。
5.2 CRL Extensions
5.2 CRL拡張子
The extensions defined by ANSI X9, ISO/IEC, and ITU-T for X.509 v2 CRLs [X.509] [X9.55] provide methods for associating additional attributes with CRLs. The X.509 v2 CRL format also allows communities to define private extensions to carry information unique to those communities. Each extension in a CRL may be designated as
X.509 v2 CRLs[X.509][X9.55]のためのANSI X9、ISO/IEC、およびITU-Tによって定義された拡大は追加属性を関連づけるための方法にCRLsを提供します。 また、X.509 v2 CRL形式で、共同体は、それらの共同体にユニークな情報を運ぶために個人的な拡大を定義できます。 CRLでの各拡大は任じられるかもしれません。
Housley, et. al. Standards Track [Page 53] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[53ページ]。
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.
批判的であるか、または非臨界です。 どのようにが処理するかを知らない批判的な拡大に遭遇するなら、CRL合法化は失敗しなければなりません。 しかしながら、認識されていない非臨界拡大は無視されるかもしれません。 以下の小区分はインターネットCRLsの中で使用されたそれらの拡張子を提示します。 共同体は、この仕様に基づき定義されないCRLsに拡大を含んでいるのを選ぶかもしれません。 しかしながら、警告は一般情勢で使用されるかもしれないCRLsでのどんな批判的な拡大も採用するのに訓練されるべきです。
Conforming CRL issuers are REQUIRED to include the authority key identifier (section 5.2.1) and the CRL number (section 5.2.3) extensions in all CRLs issued.
従っているCRL発行人は、権威の主要な識別子(セクション5.2.1)を含むREQUIREDとすべてのCRLsでの数(セクション5.2.3)の拡大が発行したCRLです。
5.2.1 Authority Key Identifier
5.2.1 権威の主要な識別子
The authority key identifier extension provides a means of identifying the public key corresponding to the private key used to sign a CRL. The identification can be based on either the key identifier (the subject key identifier in the CRL signer's certificate) or 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 CRL issuers MUST use the key identifier method, and MUST include this extension in all CRLs issued.
CRL発行人を従わせると、主要な識別子方法が使用されなければならなくて、この拡大はCRLsが発行したすべてに含まれなければなりません。
The syntax for this CRL extension is defined in section 4.2.1.1.
このCRL拡張子のための構文はセクション4.2.1で.1に定義されます。
5.2.2 Issuer Alternative Name
5.2.2 発行人代替名
The issuer alternative 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; however, a DNS name MAY be represented in the issuer field using the domainComponent attribute as described in section 4.1.2.4.
発行人代替名拡大は、追加アイデンティティがCRLの発行人に関連しているのを許容します。 定義されたオプションはrfc822名(電子メールアドレス)、DNS名、IPアドレス、およびURIを含んでいます。 名前の複数の例と複数の名前フォームが含まれるかもしれません。 そのようなアイデンティティが使用されているときはいつも、拡大という発行人代替名を使用しなければなりません。 しかしながら、DNS名はセクション4.1.2で.4に説明されるようにdomainComponent属性を使用する発行人分野に表されるかもしれません。
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に定義されます。
Housley, et. al. Standards Track [Page 54] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[54ページ]。
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 a given CRL scope and CRL issuer. This extension allows users to easily determine when a particular CRL supersedes another CRL. CRL numbers also support the identification of complementary complete CRLs and delta CRLs. CRL issuers conforming to this profile MUST include this extension in all CRLs.
CRL番号は与えられたCRL範囲とCRL発行人のために単調に増加する一連番号を伝える非臨界CRL拡張子です。 この拡大で、ユーザは、特定のCRLがいつ別のCRLに取って代わるかを容易に決心できます。 また、CRL番号は補足的な完全なCRLsとデルタCRLsの識別を支持します。 このプロフィールに従うCRL発行人はすべてのCRLsにこの拡大を含まなければなりません。
If a CRL issuer generates delta CRLs in addition to complete CRLs for a given scope, the complete CRLs and delta CRLs MUST share one numbering sequence. If a delta CRL and a complete CRL that cover the same scope are issued at the same time, they MUST have the same CRL number and provide the same revocation information. That is, the combination of the delta CRL and an acceptable complete CRL MUST provide the same revocation information as the simultaneously issued complete CRL.
CRL発行人が与えられた範囲への完全なCRLsに加えてデルタCRLsを発生させるなら、CRLsの完全なCRLsとデルタは1つの付番系列を共有しなければなりません。 同じ範囲を覆うCRLデルタと完全なCRLが同時に発行されるなら、彼らは、同じCRL番号を持って、同じ取消し情報を提供しなければなりません。 すなわち、CRLデルタの組み合わせと許容できる完全なCRL MUSTは同時に発行された完全なCRLと同じ取消し情報を提供します。
If a CRL issuer generates two CRLs (two complete CRLs, two delta CRLs, or a complete CRL and a delta CRL) for the same scope at different times, the two CRLs MUST NOT have the same CRL number. That is, if the this update field (section 5.1.2.4) in the two CRLs are not identical, the CRL numbers MUST be different.
CRL発行人がいろいろな時間に2CRLs(2完全なCRLsか、2デルタCRLsか、完全なCRLとCRLデルタ)を同じ範囲に発生させるなら、2CRLsには、同じCRL番号があってはいけません。 すなわち、このアップデート分野、(セクション5.1 .2 .4) 2が、CRLsは同じでない、CRL番号が異なっているに違いありません。
Given the requirements above, CRL numbers can be expected to contain long integers. CRL verifiers MUST be able to handle CRLNumber values up to 20 octets. Conformant CRL issuers MUST NOT use CRLNumber values longer than 20 octets.
上記の要件を考えて、CRL番号が長整数型を含むと予想できます。 CRL検証はCRLNumber値を20の八重奏まで扱うことができなければなりません。 Conformant CRL発行人は20の八重奏より長い間、CRLNumber値を使用してはいけません。
id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
イドCe cRLNumber、物の識別子:、:= イドCe20
CRLNumber ::= INTEGER (0..MAX)
CRLNumber:、:= 整数(0..MAX)
5.2.4 Delta CRL Indicator
5.2.4 デルタCRLインディケータ
The delta CRL indicator is a critical CRL extension that identifies a CRL as being a delta CRL. Delta CRLs contain updates to revocation information previously distributed, rather than all the information that would appear in a complete CRL. The use of delta CRLs can significantly reduce network load and processing time in some environments. Delta CRLs are generally smaller than the CRLs they update, so applications that obtain delta CRLs consume less network bandwidth than applications that obtain the corresponding complete CRLs. Applications which store revocation information in a format other than the CRL structure can add new revocation information to the local database without reprocessing information.
デルタCRLインディケータはCRLデルタであるとしてCRLを特定する批判的なCRL拡張子です。 デルタCRLsは以前に完全なCRLに現れるすべての情報よりむしろ分配された取消し情報にアップデートを含んでいます。 デルタCRLsの使用はいくつかの環境でネットワーク負荷と処理時間をかなり短縮できます。 デルタCRLsが彼らがアップデートするCRLsより一般に小さいので、デルタCRLsを入手するアプリケーションが対応する完全なCRLsを入手するアプリケーションより少ないネットワーク回線容量を消費します。 CRL構造以外の形式で取消し情報を格納するアプリケーションは再処理情報なしで新しい取消し情報をローカルのデータベースに追加できます。
Housley, et. al. Standards Track [Page 55] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[55ページ]。
The delta CRL indicator extension contains the single value of type BaseCRLNumber. The CRL number identifies the CRL, complete for a given scope, that was used as the starting point in the generation of this delta CRL. A conforming CRL issuer MUST publish the referenced base CRL as a complete CRL. The delta CRL contains all updates to the revocation status for that same scope. The combination of a delta CRL plus the referenced base CRL is equivalent to a complete CRL, for the applicable scope, at the time of publication of the delta CRL.
デルタCRLインディケータ拡張子はタイプBaseCRLNumberのただ一つの値を含んでいます。 CRL番号はこのCRLデルタの世代における出発点として使用された与えられた範囲に、完全なCRLを特定します。 従っているCRL発行人は完全なCRLとして参照をつけられたベースCRLを発行しなければなりません。 CRLデルタはその同じ範囲への取消し状態にすべてのアップデートを含んでいます。 CRLデルタの組み合わせと参照をつけられたベースCRLは完全なCRLに同等です、適用範囲に、CRLデルタの公表時点で。
When a conforming CRL issuer generates a delta CRL, the delta CRL MUST include a critical delta CRL indicator extension.
従っているCRL発行人がCRLデルタを発生させるとき、デルタCRL MUSTは批判的なデルタCRLインディケータ拡張子を含んでいます。
When a delta CRL is issued, it MUST cover the same set of reasons and the same set of certificates that were covered by the base CRL it references. That is, the scope of the delta CRL MUST be the same as the scope of the complete CRL referenced as the base. The referenced base CRL and the delta CRL MUST omit the issuing distribution point extension or contain identical issuing distribution point extensions. Further, the CRL issuer MUST use the same private key to sign the delta CRL and any complete CRL that it can be used to update.
CRLデルタが発行されるとき、それはそれが参照をつけるベースCRLで含まれていた同じセットの理由と同じセットの証明書を含まなければなりません。 それはそうです、範囲。CRL MUSTデルタでは、ベースとして参照をつけられる完全CRLの範囲と同じにしてください。 参照をつけられたベースCRLとCRL MUSTデルタは、発行している分配ポイント拡大を省略するか、または同じ発行している分配ポイント拡大を含んでいます。 さらに、CRL発行人は、アップデートするのにそれを使用できるCRLデルタとどんな完全なCRLにもサインするのに同じ秘密鍵を使用しなければなりません。
An application that supports delta CRLs can construct a CRL that is complete for a given scope by combining a delta CRL for that scope with either an issued CRL that is complete for that scope or a locally constructed CRL that is complete for that scope.
デルタCRLsを支持するアプリケーションは与えられた範囲に、その範囲に、完全な発行されたCRLかその範囲に、完全な局所的に組み立てられたCRLのどちらかと共にCRLデルタをその範囲に結合することによって完全なCRLを組み立てることができます。
When a delta CRL is combined with a complete CRL or a locally constructed CRL, the resulting locally constructed CRL has the CRL number specified in the CRL number extension found in the delta CRL used in its construction. In addition, the resulting locally constructed CRL has the thisUpdate and nextUpdate times specified in the corresponding fields of the delta CRL used in its construction. In addition, the locally constructed CRL inherits the issuing distribution point from the delta CRL.
CRLデルタが完全なCRLか局所的に組み立てられたCRLに結合されるとき、結果として起こる局所的に組み立てられたCRLは構造に使用されるCRLデルタの中で見つけられたCRL数の拡張子でCRL番号を指定させます。 さらに、結果として起こる局所的に組み立てられたCRLは構造に使用されるCRLデルタの対応する野原の中でthisUpdateとnextUpdate回を指定させます。 さらに、局所的に組み立てられたCRLはCRLデルタから発行している分配ポイントを引き継ぎます。
A complete CRL and a delta CRL MAY be combined if the following four conditions are satisfied:
以下の4つの条件が満たされているなら、Aは結合されたCRL MAYのCRLとデルタを完成します:
(a) The complete CRL and delta CRL have the same issuer.
(a) CRLの完全なCRLとデルタには、同じ発行人があります。
(b) The complete CRL and delta CRL have the same scope. The two
CRLs have the same scope if either of the following conditions are
met:
(b) CRLの完全なCRLとデルタには、同じ範囲があります。 2CRLsには、以下の条件のどちらかが会われるなら、同じ範囲があります:
(1) The issuingDistributionPoint extension is omitted from
both the complete CRL and the delta CRL.
(1) issuingDistributionPoint拡張子は完全なCRLとCRLデルタの両方から省略されます。
Housley, et. al. Standards Track [Page 56] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[56ページ]。
(2) The issuingDistributionPoint extension is present in both
the complete CRL and the delta CRL, and the values for each of
the fields in the extensions are the same in both CRLs.
(2) issuingDistributionPoint拡張子は完全なCRLとCRLデルタの両方に存在しています、そして、拡大における、それぞれの分野への値は両方のCRLsで同じです。
(c) The CRL number of the complete CRL is equal to or greater
than the BaseCRLNumber specified in the delta CRL. That is, the
complete CRL contains (at a minimum) all the revocation
information held by the referenced base CRL.
(c) CRLデルタの中では、完全なCRLのCRL数は、等しいか、またはBaseCRLNumberが指定したより大きいです。 すなわち、完全なCRLは参照をつけられたベースCRLによって保持されたすべての取消し情報を含んでいます(最小限で)。
(d) The CRL number of the complete CRL is less than the CRL
number of the delta CRL. That is, the delta CRL follows the
complete CRL in the numbering sequence.
(d) 完全なCRLのCRL番号はCRLデルタのCRL番号より少ないです。 すなわち、CRLデルタは付番系列で完全なCRLに続きます。
CRL issuers MUST ensure that the combination of a delta CRL and any appropriate complete CRL accurately reflects the current revocation status. The CRL issuer MUST include an entry in the delta CRL for each certificate within the scope of the delta CRL whose status has changed since the generation of the referenced base CRL:
CRL発行人は、CRLデルタとどんな適切な完全なCRLの組み合わせも正確に現在の取消し状態を反映するのを確実にしなければなりません。 CRL発行人は参照をつけられたベースCRLの世代以来状態が変化しているCRLデルタの範囲の中の各証明書のためのCRLデルタにエントリーを含まなければなりません:
(a) If the certificate is revoked for a reason included in the
scope of the CRL, list the certificate as revoked.
(a) 証明書がCRLの範囲に理由を含むように取り消されるなら、取り消されるように証明書をリストアップしてください。
(b) If the certificate is valid and was listed on the referenced
base CRL or any subsequent CRL with reason code certificateHold,
and the reason code certificateHold is included in the scope of
the CRL, list the certificate with the reason code removeFromCRL.
(b) 証明書が有効であり、理由コードcertificateHoldと共に参照をつけられたベースCRLかどんなその後のCRLにもリストアップされて、理由コードcertificateHoldがCRLの範囲で含められているなら、理由コードremoveFromCRLと共に証明書をリストアップしてください。
(c) If the certificate is revoked for a reason outside the scope
of the CRL, but the certificate was listed on the referenced base
CRL or any subsequent CRL with a reason code included in the scope
of this CRL, list the certificate as revoked but omit the reason
code.
(c) 証明書がCRLの範囲の外の理由で取り消されましたが、理由コードがこのCRLの範囲に含まれている状態で証明書が参照をつけられたベースCRLかどんなその後のCRLにもリストアップされたなら、取り消されるように証明書をリストアップしなさい、ただし、理由コードを省略してください。
(d) If the certificate is revoked for a reason outside the scope
of the CRL and the certificate was neither listed on the
referenced base CRL nor any subsequent CRL with a reason code
included in the scope of this CRL, do not list the certificate on
this CRL.
(d) 証明書がCRLの範囲の外の理由で取り消されて、このCRLの範囲で参照をつけられたベースCRLに記載されていて、理由コードがあるどんなその後のCRLも含めて、証明書がどちらもでなかった、このCRLに証明書をリストアップしないでください。
The status of a certificate is considered to have changed if it is revoked, placed on hold, released from hold, or if its revocation reason changes.
証明書の状態が、それが保持からリリースされた保持に取り消されて、置かれるかどうか、または取消し理由が変化するかどうかを変えたと考えられます。
It is appropriate to list a certificate with reason code removeFromCRL on a delta CRL even if the certificate was not on hold in the referenced base CRL. If the certificate was placed on hold in
証明書がオンでなかったとしてもCRLデルタのコードremoveFromCRLが参照をつけられたベースCRLで成立する理由で証明書をリストアップするのは適切です。 証明書が中に保持に置かれたなら
Housley, et. al. Standards Track [Page 57] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[57ページ]。
any CRL issued after the base but before this delta CRL and then released from hold, it MUST be listed on the delta CRL with revocation reason removeFromCRL.
ベースの後にもかかわらず、次に、このCRLデルタであって保持からリリースされている前を除いて、発行されたCRL、いくらか、取消し理由removeFromCRLと共にCRLデルタにそれを記載しなければなりません。
A CRL issuer MAY optionally list a certificate on a delta CRL with reason code removeFromCRL if the notAfter time specified in the certificate precedes the thisUpdate time specified in the delta CRL and the certificate was listed on the referenced base CRL or in any CRL issued after the base but before this delta CRL.
CRL発行人は任意に証明書で指定されたnotAfter時間がCRLデルタと証明書で指定されたthisUpdate時間に先行するならコードremoveFromCRLが参照をつけられたベースCRLの上、または、ベースの後に発行されたどんなCRLにも記載された理由にもかかわらず、このCRLデルタの前のCRLデルタに証明書をリストアップするかもしれません。
If a certificate revocation notice first appears on a delta CRL, then it is possible for the certificate validity period to expire before the next complete CRL for the same scope is issued. In this case, the revocation notice MUST be included in all subsequent delta CRLs until the revocation notice is included on at least one explicitly issued complete CRL for this scope.
証明書取消し通知が最初にCRLデルタに現れるなら、同じ範囲への次の完全なCRLが発行される前に期限が切れるのは証明書有効期間の間、可能です。 この場合、取消し通知がこの範囲への少なくとも1明らかに発行された完全なCRLに含まれるまで、すべてのCRLsのその後のデルタに取消し通知を含まなければなりません。
An application that supports delta CRLs MUST be able to construct a current complete CRL by combining a previously issued complete CRL and the most current delta CRL. An application that supports delta CRLs MAY also be able to construct a current complete CRL by combining a previously locally constructed complete CRL and the current delta CRL. A delta CRL is considered to be the current one if the current time is between the times contained in the thisUpdate and nextUpdate fields. Under some circumstances, the CRL issuer may publish one or more delta CRLs before indicated by the nextUpdate field. If more than one current delta CRL for a given scope is encountered, the application SHOULD consider the one with the latest value in thisUpdate to be the most current one.
デルタCRLsを支持するアプリケーションは、以前に発行された完全なCRLとCRLの最も現在のデルタを結合することによって、現在の完全なCRLを組み立てることができなければなりません。 また、デルタCRLsを支持するアプリケーションは、以前に局所的に組み立てられた完全なCRLとCRLの現在のデルタを結合することによって、現在の完全なCRLを組み立てることができるかもしれません。 thisUpdateとnextUpdate分野に保管されていた回の間には、現在の時間があるなら、CRLデルタは現在のものであると考えられます。 いくつかの状況で、nextUpdate分野によって示される前にCRL発行人は1つ以上のデルタのCRLsを発行するかもしれません。 与えられた範囲への1つ以上の電流のデルタCRLが遭遇するなら、アプリケーションSHOULDは、最新の値がthisUpdateにある1つが最も現在のものであると考えます。
id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
イドCe deltaCRLIndicator、物の識別子:、:= イドCe27
BaseCRLNumber ::= CRLNumber
BaseCRLNumber:、:= CRLNumber
5.2.5 Issuing Distribution Point
5.2.5 分配ポイントを発行すること。
The issuing distribution point is a critical CRL extension that identifies the CRL distribution point and scope for a particular CRL, and it indicates whether the CRL covers revocation for end entity certificates only, CA certificates only, attribute certificates only,
発行している分配ポイントは特定のCRLのためにCRL分配ポイントと範囲を特定する批判的なCRL拡張子です、そして、CRLが終わりの実体証明書だけのための取消しをカバーするかどうかを示します、カリフォルニア証明書だけ、属性証明書専用
or a limited set of reason codes. Although the extension is critical, conforming implementations are not required to support this extension.
または、限られたセットの理由コード。 拡大は批判的ですが、従う実現は、この拡大を支持するのに必要ではありません。
Housley, et. al. Standards Track [Page 58] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[58ページ]。
The CRL is signed using the CRL issuer's private key. CRL Distribution Points do not have their own key pairs. If the CRL is stored in the X.500 Directory, it is stored in the Directory entry corresponding to the CRL distribution point, which may be different than the Directory entry of the CRL issuer.
CRL発行人の秘密鍵を使用することでCRLはサインされます。 CRL Distribution Pointsには、それら自身の主要な組がありません。 CRLがX.500ディレクトリに格納されるなら、それはCRL発行人のディレクトリエントリーと異なるかもしれないCRL分配ポイントに対応するディレクトリエントリーに格納されます。
The reason codes associated with a distribution point MUST be specified in onlySomeReasons. If onlySomeReasons does not appear, the distribution point MUST contain revocations for all reason codes. CAs may use CRL distribution points to partition the CRL on the basis of compromise and routine revocation. In this case, the revocations with reason code keyCompromise (1), cACompromise (2), and aACompromise (8) appear in one distribution point, and the revocations with other reason codes appear in another distribution point.
onlySomeReasonsで分配ポイントに関連している理由コードを指定しなければなりません。 onlySomeReasonsが現れないなら、分配ポイントはすべての理由コードのための取消しを含まなければなりません。 CAsは、妥協と通常の取消しに基づいてCRLを仕切るのにCRL分配ポイントを使用するかもしれません。 この場合、理由コードkeyCompromise(1)、cACompromise(2)、およびaACompromise(8)との取消しはコードがもう1分配ポイントに現れる他の理由と共に1分配ポイント、および取消しに現れます。
If the distributionPoint field is present and contains a URI, the following semantics MUST be assumed: the object is a pointer to the most current CRL issued by this CRL issuer. The URI schemes ftp, http, mailto [RFC1738] and ldap [RFC1778] are defined for this purpose. The URI MUST be an absolute pathname, not a relative pathname, and MUST specify the host.
distributionPoint分野が存在していて、URIを含んでいるなら、以下の意味論を想定しなければなりません: 物はこのCRL発行人によって発行された中で最も現在のCRLへのポインタです。 URI計画のftp、http、mailto[RFC1738]、およびldap[RFC1778]はこのために定義されます。 URIは、相対的なパス名ではなく、絶対パス名でなければならなく、ホストを指定しなければなりません。
If the distributionPoint field is absent, the CRL MUST contain entries for all revoked unexpired certificates issued by the CRL issuer, if any, within the scope of the CRL.
distributionPoint分野が欠けるなら、CRL MUSTはCRL発行人によって発行されたすべての取り消された満期になっていない証明書のためのエントリーを含んでいます、もしあれば、CRLの範囲の中で。
The CRL issuer MUST assert the indirectCRL boolean, if the scope of the CRL includes certificates issued by authorities other than the CRL issuer. The authority responsible for each entry is indicated by the certificate issuer CRL entry extension (section 5.3.4).
CRL発行人はindirectCRL論理演算子について断言しなければなりません、CRLの範囲がCRL発行人以外の当局によって発行された証明書を含んでいるなら。 証明書発行人CRLエントリー拡張子(セクション5.3.4)で各エントリーに原因となる権威は示されます。
id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
イドCe issuingDistributionPoint、物の識別子:、:= イドCe28
issuingDistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
onlySomeReasons [3] ReasonFlags OPTIONAL,
indirectCRL [4] BOOLEAN DEFAULT FALSE,
onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
issuingDistributionPoint:、:= 系列distributionPoint[0]DistributionPointName任意です、誤ったonlyContainsUserCertsのデフォルト誤って、[2]のブールデフォルト誤って、onlySomeReasons[3]ReasonFlags任意のonlyContainsCACerts indirectCRL[4]ブールのデフォルトonlyContainsAttributeCerts[5][1]論理演算子論理演算子は虚偽でデフォルトとします。
5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point)
5.2.6 最も新鮮なCRL(通称デルタCRL分配ポイント)
The freshest CRL extension identifies how delta CRL information for this complete CRL is obtained. The extension MUST be non-critical. This extension MUST NOT appear in delta CRLs.
最も新鮮なCRL拡張子はどうこの完全なCRLのためのデルタCRL情報を得るかを特定します。 拡大は非臨界であるに違いありません。 この拡大はデルタCRLsに現れてはいけません。
Housley, et. al. Standards Track [Page 59] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[59ページ]。
The same syntax is used for this extension as the cRLDistributionPoints certificate extension, and is described in section 4.2.1.14. However, only the distribution point field is meaningful in this context. The reasons and CRLIssuer fields MUST be omitted from this CRL extension.
同じ構文は、cRLDistributionPointsが拡大を証明するときこの拡大に使用されて、セクション4.2.1で.14に説明されます。 しかしながら、分配ポイント分野だけがこのような関係においては重要です。 このCRL拡張子から理由とCRLIssuer分野を省略しなければなりません。
Each distribution point name provides the location at which a delta CRL for this complete CRL can be found. The scope of these delta CRLs MUST be the same as the scope of this complete CRL. The contents of this CRL extension are only used to locate delta CRLs; the contents are not used to validate the CRL or the referenced delta CRLs. The encoding conventions defined for distribution points in section 4.2.1.14 apply to this extension.
それぞれの分配ポイント名はこの完全なCRLのためのCRLデルタを見つけることができる位置を提供します。 これらのCRLsデルタの範囲はこの完全なCRLの範囲と同じであるに違いありません。 このCRL拡張子の内容はデルタCRLsの場所を見つけるのに使用されるだけです。 内容は、CRLかCRLsの参照をつけられたデルタを有効にするのに使用されません。 コンベンションが分配のために定義したコード化は.14がこの拡大に適用するセクション4.2.1で指します。
id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
イドCe freshestCRL、物の識別子:、:= イドCe46
FreshestCRL ::= CRLDistributionPoints
FreshestCRL:、:= CRLDistributionPoints
5.3 CRL Entry Extensions
5.3 CRLエントリー拡張子
The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9 for X.509 v2 CRLs provide methods for associating additional attributes with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also allows communities to define private CRL entry extensions to carry information unique to those communities. Each extension in a CRL entry may be designated as critical or non-critical. 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のためにISO/IEC、ITU-T、およびANSI X9によって定義された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 CRL issuers and applications. However, CRL issuers SHOULD include reason codes (section 5.3.1) and invalidity dates (section 5.3.3) whenever this information is available.
この仕様で使用されるすべてのCRLエントリー拡張子が非臨界です。 CRL発行人とアプリケーションを従わせるのに、これらの拡大のサポートは任意です。 しかしながら、この情報が利用可能であるときはいつも、CRL発行人SHOULDは理由コード(セクション5.3.1)と無効日付(セクション5.3.3)を含んでいます。
5.3.1 Reason Code
5.3.1 理由コード
The reasonCode is a non-critical CRL entry extension that identifies the reason for the certificate revocation. CRL issuers are strongly encouraged to include meaningful reason codes in CRL entries; however, the reason code CRL entry extension SHOULD be absent instead of using the unspecified (0) reasonCode value.
reasonCodeは証明書取消しの理由を特定する非臨界CRLエントリー拡張子です。 CRL発行人がCRLエントリーに重要な理由コードを含んでいるよう強く奨励されます。 しかしながら、理由はCRLエントリー拡張子SHOULDをコード化します。不特定の(0)reasonCode価値を使用することの代わりに、休んでください。
Housley, et. al. Standards Track [Page 60] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[60ページ]。
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),
privilegeWithdrawn (9),
aACompromise (10) }
CRLReason:、:= 列挙されます。不特定の(0)、keyCompromise(1)、cACompromise(2)(affiliationChanged(3))は(4)に取って代わりました、cessationOfOperation(5)、certificateHold(6)、removeFromCRL(8)、privilegeWithdrawn(9)、aACompromise(10)
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-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- callissuerに遭遇するアプリケーションを従わせるのは、証明書発行人と呼ばなければならないか、または証明書を拒絶しなければなりません。 イドholdinstruction-廃棄物に遭遇するアプリケーションを従わせると、証明書は拒絶されなければなりません。 holdInstructionCode、およびその使用の欠如と同等物は意味的に、そうです。保持命令、イドholdinstruction、なにも、インターネットPKIには強く推奨しないです。
Housley, et. al. Standards Track [Page 61] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[61ページ]。
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 CRL issuer in a CRL, the invalidity date may precede the date of issue of earlier CRLs, but the revocation date SHOULD NOT precede the date of issue of earlier CRLs. Whenever this information is available, CRL issuers are strongly encouraged to share it with CRL users.
無効日付は秘密鍵が感染されたか、またはそうでなければ、証明書が無効になったと知られているか、または疑われる日付を提供する非臨界CRLエントリー拡張子です。 この日付は取消し日付より早くCRLエントリーにあるかもしれません。(それは、カリフォルニアが取消しを処理した日付です)。 取消しが最初にCRLにCRL発行人によって掲示されるとき、無効日付は以前のCRLsの発行日に先行するかもしれませんが、取消し日付SHOULD NOTは以前のCRLsの発行日に先行します。 この情報が利用可能であるときはいつも、CRL発行人がCRLユーザとそれを共有するよう強く奨励されます。
The GeneralizedTime values included in this field MUST be expressed in Greenwich Mean Time (Zulu), and MUST be specified and interpreted as defined in section 4.1.2.5.2.
この分野に値を含んでいるのをグリニッジ標準時(ズールー族)に言い表されて、指定していなければならなくて、解釈しなければならないGeneralizedTimeはセクション4.1.2で.2に.5を定義しました。
id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
イドCe invalidityDate、オブジェクト識別子:、:= イドCe24
invalidityDate ::= GeneralizedTime
invalidityDate:、:= GeneralizedTime
5.3.4 Certificate Issuer
5.3.4 証明書発行人
This CRL entry extension identifies the certificate issuer associated with an entry in an indirect CRL, that is, a CRL that has the indirectCRL indicator set in its issuing distribution point extension. 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 CRL issuers, this extension MUST always be critical. If an implementation ignored this extension it could not correctly attribute CRL entries to certificates. This specification RECOMMENDS that implementations recognize this extension.
CRL発行人を従わせることによって使用されるなら、この拡大はいつも重要であるに違いありません。 実装がこの拡大を無視するなら、それは正しくCRLエントリーを証明書の結果と考えることができないでしょうに。 この仕様RECOMMENDS、実装はこの拡大を認識します。
6 Certification Path Validation
6 証明経路合法化
Certification path validation procedures for the Internet PKI are based on the algorithm supplied in [X.509]. Certification path processing verifies the binding between the subject distinguished name and/or subject alternative name and subject public key. The binding is limited by constraints which are specified in the
インターネットPKIへの証明経路合法化手順は[X.509]で供給されたアルゴリズムに基づいています。 証明経路処理は対象の分類名、そして/または、対象の代替名と対象の公開鍵の間の結合について確かめます。 結合は指定される規制で制限されます。
Housley, et. al. Standards Track [Page 62] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[62ページ]。
certificates which comprise the path and inputs which are specified by the relying party. The basic constraints and policy constraints extensions allow the certification path processing logic to automate the decision making process.
経路を包括する証明書と指定される入力は信用でパーティーへ行きます。 基本的な規制と方針規制拡大で、証明経路処理論理は意志決定プロセスを自動化できます。
This section describes an algorithm for validating certification paths. Conforming implementations of this specification are not required to implement this algorithm, but MUST provide functionality equivalent to the external behavior resulting from this procedure. Any algorithm may be used by a particular implementation so long as it derives the correct result.
このセクションは証明経路を有効にするためのアルゴリズムを説明します。 この仕様の従う実装は、このアルゴリズムを実装するのが必要ではありませんが、この手順から生じる外部の振舞いに同等な機能性を提供しなければなりません。 正しい結果を引き出す限り、どんなアルゴリズムも特定の実装によって使用されるかもしれません。
In section 6.1, the text describes basic path validation. Valid paths begin with certificates issued by a trust anchor. The algorithm requires the public key of the CA, the CA's name, and any constraints upon the set of paths which may be validated using this key.
セクション6.1で、テキストは基本的な経路合法化について説明します。 証明書が信頼アンカーによって発行されている状態で、有効な経路は始まります。 アルゴリズムはこのキーを使用することで有効にされるかもしれない経路のセットでのカリフォルニアの公開鍵、CAの名前、および規制を必要とします。
The selection of a trust anchor is a matter of policy: it could be the top CA in a hierarchical PKI; the CA that issued the verifier's own certificate(s); or any other CA in a network PKI. The path validation procedure is the same regardless of the choice of trust anchor. In addition, different applications may rely on different trust anchor, or may accept paths that begin with any of a set of trust anchor.
信頼アンカーの選択は方針の問題です: それは階層的なPKIの先頭のカリフォルニアであるかもしれません。 検証の自身の証明書を発行したカリフォルニア。 または、ネットワークPKIのいかなる他のカリフォルニア。 経路合法化手順は信頼アンカーの選択にかかわらず同じです。 さらに、異なったアプリケーションは、異なった信頼アンカーに頼るか、またはいずれでも1セットの信頼アンカーに始まる経路を受け入れるかもしれません。
Section 6.2 describes methods for using the path validation algorithm in specific implementations. 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アーキテクチャで必要であるか。
Section 6.3 describes the steps necessary to determine if a certificate is revoked or on hold status when CRLs are the revocation mechanism used by the certificate issuer.
CRLsが証明書発行人によって使用された取消しメカニズムであるときに、セクション6.3は証明書が取り消されるかどうか決定するのに必要なステップか保留状態について説明します。
6.1 Basic Path Validation
6.1 基本的な経路合法化
This text describes an algorithm for X.509 path processing. A conformant implementation MUST include an X.509 path processing procedure that is functionally equivalent to the external behavior of this algorithm. However, support for some of the certificate extensions processed in this algorithm are OPTIONAL for compliant implementations. Clients that do not support these extensions MAY omit the corresponding steps in the path validation algorithm.
本稿はX.509経路処理のためのアルゴリズムを説明します。 conformant実装はこのアルゴリズムの外部の振舞いに機能上同等なX.509経路現像処理を含まなければなりません。 しかしながら、このアルゴリズムで処理されたいくつかの証明書拡張子のサポートは対応する実装のためのOPTIONALです。 これらの拡大をサポートしないクライアントは経路合法化アルゴリズムで対応するステップを省略するかもしれません。
Housley, et. al. Standards Track [Page 63] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[63ページ]。
For example, clients are NOT REQUIRED to support the policy mapping extension. Clients that do not support this extension MAY omit the path validation steps where policy mappings are processed. Note that clients MUST reject the certificate if it contains an unsupported critical extension.
例えば、クライアントは拡大を写像する方針をサポートするNOT REQUIREDです。 この拡大をサポートしないクライアントは方針マッピングが処理される経路合法化ステップを省略するかもしれません。 サポートされない重要な拡大を含むならクライアントが証明書を拒絶しなければならないことに注意してください。
The algorithm presented in this section validates the certificate with respect to the current date and time. A conformant implementation MAY also support validation with respect to some point in the past. Note that mechanisms are not available for validating a certificate with respect to a time outside the certificate validity period.
このセクションに提示されたアルゴリズムは現在の日時に関して証明書を有効にします。 また、conformant実装は過去に何らかのポイントに関して合法化をサポートするかもしれません。 メカニズムが証明書有効期間に時間に関して証明書を有効にするのに利用可能でないことに注意してください。
The trust anchor is an input to the algorithm. There is no requirement that the same trust anchor be used to validate all certification paths. Different trust anchors MAY be used to validate different paths, as discussed further in Section 6.2.
信頼アンカーはアルゴリズムへの入力です。 同じ信頼アンカーがすべての証明経路を有効にするのに使用されるという要件が全くありません。 異なった信頼アンカーはセクション6.2で、より詳しく議論するように異なった経路を有効にするのにおいて使用されているかもしれません。
The primary goal of path validation is to verify the binding between a subject distinguished name or a subject alternative name and subject public key, as represented in the end entity certificate, based on the public key of the trust anchor. This requires obtaining a sequence of certificates that support that binding. The procedure performed to obtain this sequence of certificates is outside the scope of this specification.
経路合法化のプライマリ目標は対象の分類名か対象の代替名と対象の公開鍵の間の結合について確かめることです、終わりの実体証明書に表されるように、信頼アンカーの公開鍵に基づいて。 これは、系列を得るのをその結合をサポートする証明書を要求します。 この仕様の範囲の外に証明書のこの系列を得るために実行された手順があります。
To meet this goal, the path validation process verifies, among other things, that a prospective certification path (a sequence of n certificates) satisfies the following conditions:
この目標を達成するために、経路合法化プロセスは、将来の証明経路(n証明書の系列)が以下の条件を満たすことを特に確かめます:
(a) for all x in {1, ..., n-1}, the subject of certificate x is
the issuer of certificate x+1;
(a) 1、…、n-1のすべてのxに関して、証明書xの対象は+1に証明書xの発行人です。
(b) certificate 1 is issued by the trust anchor;
(b) 証明書1は信頼アンカーによって発行されます。
(c) certificate n is the certificate to be validated; and
(c) 証明書nは有効にされるべき証明書です。 そして
(d) for all x in {1, ..., n}, the certificate was valid at the
time in question.
(d) 1、…、nのすべてのxに関して、証明書は問題の時に有効でした。
When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path. Information about trust anchors are provided as inputs to the certification path validation algorithm (section 6.1.1).
自己署名入りの証書の形に信頼アンカーを提供するとき、将来の証明経路の一部としてこの自己署名入りの証書を含んでいません。 入力として証明経路合法化アルゴリズム(セクション6.1.1)に信頼アンカーに関する情報を提供します。
Housley, et. al. Standards Track [Page 64] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[64ページ]。
A particular certification path may not, however, be appropriate for all applications. Therefore, an application MAY augment this algorithm to further limit the set of valid paths. The path validation process also determines the set of certificate policies that are valid for this path, based on the certificate policies extension, policy mapping extension, policy constraints extension, and inhibit any-policy extension. To achieve this, the path validation algorithm constructs a valid policy tree. If the set of certificate policies that are valid for this path is not empty, then the result will be a valid policy tree of depth n, otherwise the result will be a null valid policy tree.
しかしながら、すべてのアプリケーションには、特定の証明経路は適切でないかもしれません。 したがって、アプリケーションは、さらに有効な経路のセットを制限するためにこのアルゴリズムを増大させるかもしれません。 また、経路合法化プロセスはこの経路に、有効な証明書方針のセットを決定します、証明書方針拡張子に基づいて、方針マッピング拡張子、方針規制拡大、禁止、いくらか、-、方針、拡大 これを達成するために、経路合法化アルゴリズムは有効な方針木を組み立てます。 この経路に、有効な証明書方針のセットが空でないなら結果が深さnの有効な方針木になる、さもなければ、結果はヌル有効な方針木になるでしょう。
A certificate is self-issued if the DNs that appear in the subject and issuer fields are identical and are not empty. In general, the issuer and subject of the certificates that make up a path are different for each certificate. However, a CA may issue a certificate to itself to support key rollover or changes in certificate policies. These self-issued certificates are not counted when evaluating path length or name constraints.
対象と発行人分野に現れるDNsが同じであり、空でないなら、自己に証明書を発行します。 一般に、各証明書において、経路を作る証明書の発行人と対象は異なっています。 しかしながら、カリフォルニアは、証明書方針で主要なロールオーバーか変化をサポートするためにそれ自体に証明書を下付するかもしれません。 経路の長さか名前規制を評価するとき、これらの自己によって発行された証明書は数えられません。
This section presents the algorithm in four basic steps: (1) initialization, (2) basic certificate processing, (3) preparation for the next certificate, and (4) wrap-up. Steps (1) and (4) are performed exactly once. Step (2) is performed for all certificates in the path. Step (3) is performed for all certificates in the path except the final certificate. Figure 2 provides a high-level flowchart of this algorithm.
このセクションは以下の基本的な4ステップにおけるアルゴリズムを提示します: (1) 初期化、(2)の基本的な証明書処理、次の証明書、および(4)結論のための(3)準備。 ステップ(1)と(4)はまさに一度実行されます。 ステップ(2)は経路のすべての証明書のために実行されます。 ステップ(3)は確定品質証明書以外の経路のすべての証明書のために実行されます。 図2はこのアルゴリズムのハイレベルのフローチャートを提供します。
Housley, et. al. Standards Track [Page 65] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[65ページ]。
+-------+
| START |
+-------+
|
V
+----------------+
| Initialization |
+----------------+
|
+<--------------------+
| |
V |
+----------------+ |
| Process Cert | |
+----------------+ |
| |
V |
+================+ |
| IF Last Cert | |
| in Path | |
+================+ |
| | |
THEN | | ELSE |
V V |
+----------------+ +----------------+ |
| Wrap up | | Prepare for | |
+----------------+ | Next Cert | |
| +----------------+ |
V | |
+-------+ +--------------+
| STOP |
+-------+
+-------+ | 始め| +-------+ | +に対して----------------+ | 初期設定| +----------------+ | + <。--------------------+ | | V| +----------------+ | | プロセス本命| | +----------------+ | | | V| +================+ | | 最後の本命です。| | | 経路で| | +================+ | | | | その時| | ほか| V V| +----------------+ +----------------+ | | 包装は上昇します。| | 用意をします。| | +----------------+ | 次の本命| | | +----------------+ | V| | +-------+ +--------------+ | 停止| +-------+
Figure 2. Certification Path Processing Flowchart
図2。 証明経路処理フローチャート
6.1.1 Inputs
6.1.1 入力
This algorithm assumes the following seven inputs are provided to the path processing logic:
このアルゴリズムは、以下の7つの入力が経路処理論理に提供されると仮定します:
(a) a prospective certification path of length n.
(a) 長さnの将来の証明経路。
(b) the current date/time.
(b)現在の日付/時間。
Housley, et. al. Standards Track [Page 66] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[66ページ]。
(c) user-initial-policy-set: A set of certificate policy
identifiers naming the policies that are acceptable to the
certificate user. The user-initial-policy-set contains the
special value any-policy if the user is not concerned about
certificate policy.
(c) ユーザの初期の方針はセットしました: 証明書ユーザにとって、方針をそれと命名する1セットの証明書方針識別子は許容できます。 ユーザの初期の方針セットが含んでいる、特別な値、いくらか、-、方針、ユーザが証明書方針に関して心配していないなら。
(d) trust anchor information, describing a CA that serves as a
trust anchor for the certification path. The trust anchor
information includes:
(d) 証明経路のために信頼アンカーとして役立つカリフォルニアを記述して、アンカー情報を信じてください。 信頼アンカー情報は:
(1) the trusted issuer name,
(1) 信じられた発行人名
(2) the trusted public key algorithm,
(2) 信じられた公開鍵アルゴリズム
(3) the trusted public key, and
そして(3) 信じられた公開鍵。
(4) optionally, the trusted public key parameters associated
with the public key.
任意に、信じられた公開鍵パラメタが公開鍵に関連づけた(4)。
The trust anchor information may be provided to the path
processing procedure in the form of a self-signed certificate.
The trusted anchor information is trusted because it was delivered
to the path processing procedure by some trustworthy out-of-band
procedure. If the trusted public key algorithm requires
parameters, then the parameters are provided along with the
trusted public key.
自己署名入りの証書の形で信頼アンカー情報を経路現像処理に提供するかもしれません。 それが何らかの信頼できるバンドで出ている手順で経路現像処理に提供されたので、信じられたアンカー情報は信じられます。 信じられた公開鍵アルゴリズムがパラメタを必要とするなら、信じられた公開鍵と共にパラメタを提供します。
(e) initial-policy-mapping-inhibit, which indicates if policy
mapping is allowed in the certification path.
(e) マッピングが禁止する初期の方針。(その方針は、方針マッピングが証明経路に許容されているかどうかを示します)。
(f) initial-explicit-policy, which indicates if the path must be
valid for at least one of the certificate policies in the user-
initial-policy-set.
(f) 初期の明白な方針。(その方針は少なくとも証明書方針の1つに、経路がユーザの初期の方針セットで有効であるに違いないかどうかを示します)。
(g) initial-any-policy-inhibit, which indicates whether the
anyPolicy OID should be processed if it is included in a
certificate.
(g) 方針が禁止するいずれにも頭文字をつけてください、そして、どれが、anyPolicy OIDがそれであるなら処理されるべきであるかどうかを示すか証明書に含まれています。
6.1.2 Initialization
6.1.2 初期設定
This initialization phase establishes eleven state variables based upon the seven inputs:
この初期設定段階は7つの入力に基づく11の州の変数を確立します:
(a) valid_policy_tree: A tree of certificate policies with their
optional qualifiers; each of the leaves of the tree represents a
valid policy at this stage in the certification path validation.
If valid policies exist at this stage in the certification path
validation, the depth of the tree is equal to the number of
(a) 有効な_方針_木: 彼らの任意の資格を与える人がいる証明書方針の木。 それぞれの木の葉は現在のところ、証明経路合法化で有効な方針を表します。 有効な方針が現在のところ証明経路合法化で存在するなら、木の深さは数と等しいです。
Housley, et. al. Standards Track [Page 67] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[67ページ]。
certificates in the chain that have been processed. If valid
policies do not exist at this stage in the certification path
validation, the tree is set to NULL. Once the tree is set to
NULL, policy processing ceases.
チェーンにおける処理された証明書。 有効な方針が現在のところ証明経路合法化で存在しないなら、木はNULLに設定されます。 木がいったんNULLに設定されると、方針処理はやみます。
Each node in the valid_policy_tree includes four data objects: the
valid policy, a set of associated policy qualifiers, a set of one
or more expected policy values, and a criticality indicator. If
the node is at depth x, the components of the node have the
following semantics:
有効な_方針_木の各ノードは4個のデータ・オブジェクトを含んでいます: 有効な方針、1セットの関連方針資格を与える人、1セットのより多くのひとりは保険価額、および臨界インディケータを予想しました。 ノードが深さxにあるなら、ノードの成分には、以下の意味論があります:
(1) The valid_policy is a single policy OID representing a
valid policy for the path of length x.
(1) 有効な_方針は長さxの経路に有効な方針を表すただ一つの方針OIDです。
(2) The qualifier_set is a set of policy qualifiers associated
with the valid policy in certificate x.
(2) 資格を与える人_セットは証明書xの有効な方針に関連している方針資格を与える人のセットです。
(3) The criticality_indicator indicates whether the
certificate policy extension in certificate x was marked as
critical.
(3) 臨界_インディケータは、証明書xにおける証明書方針拡張子が重要であるとしてマークされたかどうかを示します。
(4) The expected_policy_set contains one or more policy OIDs
that would satisfy this policy in the certificate x+1.
(4) 予想された_方針_セットは+1に証明書xのこの方針を満たす1つ以上の方針のOIDsを含んでいます。
The initial value of the valid_policy_tree is a single node with
valid_policy anyPolicy, an empty qualifier_set, an
expected_policy_set with the single value anyPolicy, and a
criticality_indicator of FALSE. This node is considered to be at
depth zero.
有効な_方針_木の初期の値は、有効な_方針anyPolicyとのただ一つのノードと、空の資格を与える人_セットと、独身の値のanyPolicyがある予想された_方針_セットと、FALSEの臨界_インディケータです。 このノードが深さゼロにあると考えられます。
Figure 3 is a graphic representation of the initial state of the
valid_policy_tree. Additional figures will use this format to
describe changes in the valid_policy_tree during path processing.
図3は有効な_方針_木の初期状態のグラフィック表示です。 追加数字は、経路処理の間、有効な_方針_木における変化について説明するのにこの形式を使用するでしょう。
+----------------+
| anyPolicy | <---- valid_policy
+----------------+
| {} | <---- qualifier_set
+----------------+
| FALSE | <---- criticality_indicator
+----------------+
| {anyPolicy} | <---- expected_policy_set
+----------------+
+----------------+ | anyPolicy| <、-、-、-- 有効な_方針+----------------+ | {} | <、-、-、-- 資格を与える人_セット+----------------+ | 誤る| <、-、-、-- 臨界_インディケータ+----------------+ | anyPolicy| <、-、-、-- 予想された_方針_セット+----------------+
Figure 3. Initial value of the valid_policy_tree state variable
図3。 有効な_方針_木の州の変数の初期の値
Housley, et. al. Standards Track [Page 68] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[68ページ]。
(b) permitted_subtrees: A set of root names for each name type
(e.g., X.500 distinguished names, email addresses, or ip
addresses) defining a set of subtrees within which all subject
names in subsequent certificates in the certification path MUST
fall. This variable includes a set for each name type: the
initial value for the set for Distinguished Names is the set of
all Distinguished names; the initial value for the set of RFC822
names is the set of all RFC822 names, etc.
(b) 受入れられた_下位木: 各名前のための1セットの根の名は、証明経路のその後の証明書のすべての対象の名前が下がらなければならない1セットの下位木を定義しながら、(例えば、X.500分類名、Eメールアドレス、またはipアドレス)をタイプします。 この変数はそれぞれの名前タイプのためのセットを含んでいます: Distinguished Namesのためのセットのための初期の値はすべてのDistinguished名のセットです。 RFC822名のセットのための初期の値はすべてのRFC822名などのセットです。
(c) excluded_subtrees: A set of root names for each name type
(e.g., X.500 distinguished names, email addresses, or ip
addresses) defining a set of subtrees within which no subject name
in subsequent certificates in the certification path may fall.
This variable includes a set for each name type, and the initial
value for each set is empty.
(c) 除かれた_下位木: 各名前のための1セットの根の名は、証明経路のその後の証明書でどんな対象の名前も下がらないかもしれない1セットの下位木を定義しながら、(例えば、X.500分類名、Eメールアドレス、またはipアドレス)をタイプします。 この変数はそれぞれの名前タイプのためのセットを含んでいます、そして、各セットのための初期の値は空です。
(d) explicit_policy: an integer which indicates if a non-NULL
valid_policy_tree is required. The integer indicates the number of
non-self-issued certificates to be processed before this
requirement is imposed. Once set, this variable may be decreased,
but may not be increased. That is, if a certificate in the path
requires a non-NULL valid_policy_tree, a later certificate can not
remove this requirement. If initial-explicit-policy is set, then
the initial value is 0, otherwise the initial value is n+1.
(d) 明白な_方針: 非NULLの有効な_方針_木がそうであるかどうかを示す整数が必要です。 整数は、この要件が課される前に処理されるために発行された非自己証明書の数を示します。 いったん設定されると、この変数は、減少しますが、増強されないかもしれません。 すなわち、経路の証明書が非NULLの有効な_方針_木を必要とするなら、後の証明書はこの要件を取り除くことができません。 初期の明白な方針が設定されるなら初期の値が0である、さもなければ、初期の値はn+1です。
(e) inhibit_any-policy: an integer which indicates whether the
anyPolicy policy identifier is considered a match. The integer
indicates the number of non-self-issued certificates to be
processed before the anyPolicy OID, if asserted in a certificate,
is ignored. Once set, this variable may be decreased, but may not
be increased. That is, if a certificate in the path inhibits
processing of anyPolicy, a later certificate can not permit it.
If initial-any-policy-inhibit is set, then the initial value is 0,
otherwise the initial value is n+1.
(e) _いずれも禁止してください、-、方針: anyPolicy方針識別子がマッチであると考えられるかどうかを示す整数。 整数は、証明書で断言されるならanyPolicy OIDが無視される前に処理されるために発行された非自己証明書の数を示します。 いったん設定されると、この変数は、減少しますが、増強されないかもしれません。 すなわち、経路の証明書がanyPolicyの処理を抑制するなら、後の証明書はそれを可能にすることができません。 方針が禁止する初期のいずれか設定されるなら初期の値が0である、さもなければ、初期の値はn+1です。
(f) policy_mapping: an integer which indicates if policy mapping
is permitted. The integer indicates the number of non-self-issued
certificates to be processed before policy mapping is inhibited.
Once set, this variable may be decreased, but may not be
increased. That is, if a certificate in the path specifies policy
mapping is not permitted, it can not be overridden by a later
certificate. If initial-policy-mapping-inhibit is set, then the
initial value is 0, otherwise the initial value is n+1.
(f) 方針_マッピング: 方針マッピングが受入れられるかどうかを示す整数。 整数は、方針マッピングが抑制的になる前に処理されるために発行された非自己証明書の数を示します。 いったん設定されると、この変数は、減少しますが、増強されないかもしれません。 すなわち、経路の証明書が指定するなら、方針マッピングを受入れないで、後の証明書はそれをくつがえすことができません。 マッピングが禁止する初期の方針が設定されるなら初期の値が0である、さもなければ、初期の値はn+1です。
(g) working_public_key_algorithm: the digital signature algorithm
used to verify the signature of a certificate. The
working_public_key_algorithm is initialized from the trusted
public key algorithm provided in the trust anchor information.
(g) 働く_公共の_主要な_アルゴリズム: デジタル署名アルゴリズムは以前はよく証明書の署名について確かめていました。 働く_公共の_主要な_アルゴリズムは信頼アンカー情報に提供された信じられた公開鍵アルゴリズムから初期化されます。
Housley, et. al. Standards Track [Page 69] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[69ページ]。
(h) working_public_key: the public key used to verify the
signature of a certificate. The working_public_key is initialized
from the trusted public key provided in the trust anchor
information.
(h) 働く_公共の_キー: 公開鍵は以前はよく証明書の署名について確かめていました。 働く_公共の_キーは信頼アンカー情報に提供された信じられた公開鍵から初期化されます。
(i) working_public_key_parameters: parameters associated with the
current public key, that may be required to verify a signature
(depending upon the algorithm). The working_public_key_parameters
variable is initialized from the trusted public key parameters
provided in the trust anchor information.
(i) 働く_公共の_主要な_パラメタ: 現在の公開鍵に関連しているパラメタであり、それが、署名について確かめるのに必要であるかもしれません(アルゴリズムによって)。 働く_の公共の_主要な_パラメタ変数は信頼アンカー情報に提供された信じられた公開鍵パラメタから初期化されます。
(j) working_issuer_name: the issuer distinguished name expected
in the next certificate in the chain. The working_issuer_name is
initialized to the trusted issuer provided in the trust anchor
information.
(j) 働く_発行人_名: 次の証明書でチェーンで予想された発行人分類名。 働く_発行人_名は信頼アンカー情報に提供された信じられた発行人に初期化されます。
(k) max_path_length: this integer is initialized to n, is
decremented for each non-self-issued certificate in the path, and
may be reduced to the value in the path length constraint field
within the basic constraints extension of a CA certificate.
(k) _経路_長さに最大限にしてください: この整数は、nに初期化されて、それぞれの発行された非自己証明書のために経路で減少して、カリフォルニア証明書の基本的な規制拡大の中で経路長さの規制分野で値に減少するかもしれません。
Upon completion of the initialization steps, perform the basic certificate processing steps specified in 6.1.3.
初期化ステップの完成に、6.1で.3に指定された基本的な証明書処理ステップを実行してください。
6.1.3 Basic Certificate Processing
6.1.3 基本的な証明書処理
The basic path processing actions to be performed for certificate i (for all i in [1..n]) are listed below.
証明書iのために実行されるべき基本的な経路処理動作は以下に記載されています([1..n]のすべてのiのために)。
(a) Verify the basic certificate information. The certificate
MUST satisfy each of the following:
(a) 基本の証明書情報について確かめてください。 証明書はそれぞれの以下を満たさなければなりません:
(1) The certificate was signed with the
working_public_key_algorithm using the working_public_key and
the working_public_key_parameters.
(1) 証明書は、働く_公共の_キーと働く_公共の_主要な_パラメタを使用することで働く_公共の_主要な_アルゴリズムを契約されました。
(2) The certificate validity period includes the current time.
(2) 証明書有効期間は現在の時間を含んでいます。
(3) At the current time, the certificate is not revoked and is
not on hold status. This may be determined by obtaining the
appropriate CRL (section 6.3), status information, or by out-
of-band mechanisms.
(3) 証明書は、現在の時間に、取り消されないで、また保留状態ではありません。 これは、適切なCRL(セクション6.3)、状態情報、または外によるバンドのメカニズムを入手することによって、決定するかもしれません。
(4) The certificate issuer name is the working_issuer_name.
(4) 証明書発行人名は働く_発行人_名です。
Housley, et. al. Standards Track [Page 70] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[70ページ]。
(b) If certificate i is self-issued and it is not the final
certificate in the path, skip this step for certificate i.
Otherwise, verify that the subject name is within one of the
permitted_subtrees for X.500 distinguished names, and verify that
each of the alternative names in the subjectAltName extension
(critical or non-critical) is within one of the permitted_subtrees
for that name type.
(b) 自己に証明書iを発行して、それが経路の確定品質証明書でないなら、証明書iのためのこのステップをサボってください。 さもなければ、X.500分類名のための受入れられた_下位木の1つの中に対象の名前があることを確かめてください、そして、その名前タイプのための受入れられた_下位木の1つの中にsubjectAltName拡張子(重要であるか非臨界である)における、それぞれの代替名があることを確かめてください。
(c) If certificate i is self-issued and it is not the final
certificate in the path, skip this step for certificate i.
Otherwise, verify that the subject name is not within one of the
excluded_subtrees for X.500 distinguished names, and verify that
each of the alternative names in the subjectAltName extension
(critical or non-critical) is not within one of the
excluded_subtrees for that name type.
(c) 自己に証明書iを発行して、それが経路の確定品質証明書でないなら、証明書iのためのこのステップをサボってください。 さもなければ、X.500分類名のための除かれた_下位木の1つの中に対象の名前がないことを確かめてください、そして、その名前タイプのための除かれた_下位木の1つの中にsubjectAltName拡張子(重要であるか非臨界である)における、それぞれの代替名がないことを確かめてください。
(d) If the certificate policies extension is present in the
certificate and the valid_policy_tree is not NULL, process the
policy information by performing the following steps in order:
(d) 証明書方針拡張子が証明書に存在していて、有効な_方針_木がNULLでないなら、整然とした状態で以下のステップを実行することによって、方針情報を処理してください:
(1) For each policy P not equal to anyPolicy in the
certificate policies extension, let P-OID denote the OID in
policy P and P-Q denote the qualifier set for policy P.
Perform the following steps in order:
(1) 証明書方針拡張子においてanyPolicyと等しくないそれぞれの方針Pのために、P-OIDに方針PでOIDを指示させてください。そうすれば、P-Qは整然とした状態で以下が踏む方針P.Performに用意ができている資格を与える人を指示します:
(i) If the valid_policy_tree includes a node of depth i-1
where P-OID is in the expected_policy_set, create a child
node as follows: set the valid_policy to OID-P; set the
qualifier_set to P-Q, and set the expected_policy_set to
{P-OID}.
(i) 有効な_方針_木が予想された_方針_セットにP-OIDがある深さi-1のノードを含んでいるなら、以下の子供ノードを作成してください: 有効な_方針をOID-Pに設定してください。 資格を与える人_セットをP-Qに設定してください、そして、予想された_方針_セットをP-OIDに設定してください。
For example, consider a valid_policy_tree with a node of
depth i-1 where the expected_policy_set is {Gold, White}.
Assume the certificate policies Gold and Silver appear in
the certificate policies extension of certificate i. The
Gold policy is matched but the Silver policy is not. This
rule will generate a child node of depth i for the Gold
policy. The result is shown as Figure 4.
例えば、予想された_方針_がセットした深さi-1のノードがある有効な_方針_木が金、ホワイトであると考えてください。 証明書がGoldとシルヴァーが証明書iの証明書方針拡張子で見える方針であると仮定してください。 Gold方針は取り組んでいますが、シルヴァー方針は取り組むというわけではありません。 この規則はGold方針のために深さiの子供ノードを作るでしょう。 結果は図4として示されます。
Housley, et. al. Standards Track [Page 71] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[71ページ]。
+-----------------+
| Red |
+-----------------+
| {} |
+-----------------+ node of depth i-1
| FALSE |
+-----------------+
| {Gold, White} |
+-----------------+
|
|
|
V
+-----------------+
| Gold |
+-----------------+
| {} |
+-----------------+ node of depth i
| uninitialized |
+-----------------+
| {Gold} |
+-----------------+
+-----------------+ | 赤| +-----------------+ | {} | +-----------------+ 深さi-1のノード| 誤る| +-----------------+ | 金、ホワイト| +-----------------+ | | | +に対して-----------------+ | 金| +-----------------+ | {} | +-----------------+ 深さiのノード| 非初期化しました。| +-----------------+ | 金| +-----------------+
Figure 4. Processing an exact match
図4。 完全な一致を処理します。
(ii) If there was no match in step (i) and the
valid_policy_tree includes a node of depth i-1 with the
valid policy anyPolicy, generate a child node with the
following values: set the valid_policy to P-OID; set the
qualifier_set to P-Q, and set the expected_policy_set to
{P-OID}.
(ii) マッチが全くステップ(i)になくて、有効な_方針_木が有効な方針anyPolicyで深さi-1のノードを含んでいるなら、以下の値で子供ノードを作ってください: 有効な_方針をP-OIDに設定してください。 資格を与える人_セットをP-Qに設定してください、そして、予想された_方針_セットをP-OIDに設定してください。
For example, consider a valid_policy_tree with a node of
depth i-1 where the valid_policy is anyPolicy. Assume the
certificate policies Gold and Silver appear in the
certificate policies extension of certificate i. The Gold
policy does not have a qualifier, but the Silver policy has
the qualifier Q-Silver. If Gold and Silver were not matched
in (i) above, this rule will generate two child nodes of
depth i, one for each policy. The result is shown as Figure
5.
例えば、有効な_方針がanyPolicyである深さi-1のノードで有効な_方針_木を考えてください。 証明書がGoldとシルヴァーが証明書iの証明書方針拡張子で見える方針であると仮定してください。 Gold方針には、資格を与える人がいませんが、シルヴァー方針に資格を与える人Q-Silverがあります。Goldとシルヴァーが上で(i)で合わせられなかったなら、この規則は深さiの2つの子供ノードを作るでしょう、各方針あたり1つ。 結果は図5として示されます。
Housley, et. al. Standards Track [Page 72] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[72ページ]。
+-----------------+
| anyPolicy |
+-----------------+
| {} |
+-----------------+ node of depth i-1
| FALSE |
+-----------------+
| {anyPolicy} |
+-----------------+
/ \
/ \
/ \
/ \
+-----------------+ +-----------------+
| Gold | | Silver |
+-----------------+ +-----------------+
| {} | | {Q-Silver} |
+-----------------+ nodes of +-----------------+
| uninitialized | depth i | uninitialized |
+-----------------+ +-----------------+
| {Gold} | | {Silver} |
+-----------------+ +-----------------+
+-----------------+ | anyPolicy| +-----------------+ | {} | +-----------------+ 深さi-1のノード| 誤る| +-----------------+ | anyPolicy| +-----------------+ / \ / \ / \ / \ +-----------------+ +-----------------+ | 金| | 銀| +-----------------+ +-----------------+ | {} | | Q-銀| +-----------------+ +のノード-----------------+ | 非初期化しました。| 深さi| 非初期化しました。| +-----------------+ +-----------------+ | 金| | 銀| +-----------------+ +-----------------+
Figure 5. Processing unmatched policies when a leaf node
specifies anyPolicy
図5。 葉のノードがanyPolicyを指定するとき、優れた方針を処理します。
(2) If the certificate policies extension includes the policy
anyPolicy with the qualifier set AP-Q and either (a)
inhibit_any-policy is greater than 0 or (b) i<n and the
certificate is self-issued, then:
(2) 証明書方針拡張子が資格を与える人セットAP-Qとどちらかの(a)とanyPolicyが禁止する方針を含んでいる、_いくらか、-、方針、0以上か(b)i<がnです、そして、自己に証明書を発行します、そして:
For each node in the valid_policy_tree of depth i-1, for each
value in the expected_policy_set (including anyPolicy) that
does not appear in a child node, create a child node with the
following values: set the valid_policy to the value from the
expected_policy_set in the parent node; set the qualifier_set
to AP-Q, and set the expected_policy_set to the value in the
valid_policy from this node.
深さi-1の有効な_方針_木の各ノード、子供ノードに現れない予想された_方針_セット(anyPolicyを含んでいる)における各値には、以下の値で子供ノードを作成してください: 親ノードで用意ができている予想された_方針_から値に有効な_方針を設定してください。 資格を与える人_セットをAP-Qに設定してください、そして、このノードから値に有効な_方針で予想された_方針_セットを設定してください。
For example, consider a valid_policy_tree with a node of depth
i-1 where the expected_policy_set is {Gold, Silver}. Assume
anyPolicy appears in the certificate policies extension of
certificate i, but Gold and Silver do not. This rule will
generate two child nodes of depth i, one for each policy. The
result is shown below as Figure 6.
例えば、予想された_方針_がセットした深さi-1のノードがある有効な_方針_木が金、シルヴァーであると考えてください。 anyPolicyがしかし、証明書i、Goldの証明書方針拡張子に現れて、シルヴァーがそうしないと仮定してください。 この規則は深さiの2つの子供ノード、各方針あたり1つを発生させるでしょう。 結果は図6として以下に示されます。
Housley, et. al. Standards Track [Page 73] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[73ページ]。
+-----------------+
| Red |
+-----------------+
| {} |
+-----------------+ node of depth i-1
| FALSE |
+-----------------+
| {Gold, Silver} |
+-----------------+
/ \
/ \
/ \
/ \
+-----------------+ +-----------------+
| Gold | | Silver |
+-----------------+ +-----------------+
| {} | | {} |
+-----------------+ nodes of +-----------------+
| uninitialized | depth i | uninitialized |
+-----------------+ +-----------------+
| {Gold} | | {Silver} |
+-----------------+ +-----------------+
+-----------------+ | 赤| +-----------------+ | {} | +-----------------+ 深さi-1のノード| 誤る| +-----------------+ | 金、銀| +-----------------+ / \ / \ / \ / \ +-----------------+ +-----------------+ | 金| | 銀| +-----------------+ +-----------------+ | {} | | {} | +-----------------+ +のノード-----------------+ | 非初期化しました。| 深さi| 非初期化しました。| +-----------------+ +-----------------+ | 金| | 銀| +-----------------+ +-----------------+
Figure 6. Processing unmatched policies when the certificate
policies extension specifies anyPolicy
図6。 証明書方針拡張子がanyPolicyを指定するとき、優れた方針を処理します。
(3) If there is a node in the valid_policy_tree of depth i-1
or less without any child nodes, delete that node. Repeat this
step until there are no nodes of depth i-1 or less without
children.
(3) ノードが深さi-1か以下の有効な_方針_木に少しも子供ノードなしであれば、そのノードを削除してください。 深さi-1か以下のノードが全く子供なしでないまで、このステップを繰り返してください。
For example, consider the valid_policy_tree shown in Figure 7
below. The two nodes at depth i-1 that are marked with an 'X'
have no children, and are deleted. Applying this rule to the
resulting tree will cause the node at depth i-2 that is marked
with an 'Y' to be deleted. The following application of the
rule does not cause any nodes to be deleted, and this step is
complete.
例えば、以下の図7で見せられた有効な_方針_木を考えてください。 深さi-1の'X'と共にマークされる2つのノードが、子供が全くいないで、削除されます。 この規則を結果として起こる木に適用するのに、'Y'と共にマークされる深さi-2のノードを削除するでしょう。 規則の以下の適用でどんなノードも削除しません、そして、このステップは完了しています。
Housley, et. al. Standards Track [Page 74] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[74ページ]。
+-----------+
| | node of depth i-3
+-----------+
/ | \
/ | \
/ | \
+-----------+ +-----------+ +-----------+
| | | | | Y | nodes of
+-----------+ +-----------+ +-----------+ depth i-2
/ \ | |
/ \ | |
/ \ | |
+-----------+ +-----------+ +-----------+ +-----------+ nodes of
| | | X | | | | X | depth
+-----------+ +-----------+ +-----------+ +-----------+ i-1
| / | \
| / | \
| / | \
+-----------+ +-----------+ +-----------+ +-----------+ nodes of
| | | | | | | | depth
+-----------+ +-----------+ +-----------+ +-----------+ i
+-----------+ | | 深さi-3+のノード-----------+ / | \ / | \ / | \ +-----------+ +-----------+ +-----------+ | | | | | Y| +のノード-----------+ +-----------+ +-----------+ 深さi-2/\| | / \ | | / \ | | +-----------+ +-----------+ +-----------+ +-----------+ ノード| | | X| | | | X| 深さ+-----------+ +-----------+ +-----------+ +-----------+ i-1| / | \ | / | \ | / | \ +-----------+ +-----------+ +-----------+ +-----------+ ノード| | | | | | | | 深さ+-----------+ +-----------+ +-----------+ +-----------+ i
Figure 7. Pruning the valid_policy_tree
図7。 有効な_方針_木を剪定します。
(4) If the certificate policies extension was marked as
critical, set the criticality_indicator in all nodes of depth i
to TRUE. If the certificate policies extension was not marked
critical, set the criticality_indicator in all nodes of depth i
to FALSE.
(4) 証明書方針拡張子が批判的であるとしてマークされたなら、TRUEへの深さiのすべてのノードに臨界_インディケータをはめ込んでください。 証明書方針拡張子が批判的であることはマークされなかったなら、FALSEへの深さiのすべてのノードに臨界_インディケータをはめ込んでください。
(e) If the certificate policies extension is not present, set the
valid_policy_tree to NULL.
(e) 証明書方針拡張子が存在していないなら、有効な_方針_木をNULLに設定してください。
(f) Verify that either explicit_policy is greater than 0 or the
valid_policy_tree is not equal to NULL;
(f) 明白な_方針が0以上であるか有効な_方針_木がNULLと等しくないことを確かめてください。
If any of steps (a), (b), (c), or (f) fails, the procedure terminates, returning a failure indication and an appropriate reason.
ステップ(a)、(b)、(c)、または(f)のどれかが失敗するなら、手順は終わります、失敗指示と適切な理由を返して。
If i is not equal to n, continue by performing the preparatory steps listed in 6.1.4. If i is equal to n, perform the wrap-up steps listed in 6.1.5.
iがnと等しくないなら、6.1で.4に記載された準備段階を実行することによって、続いてください。 iがnと等しいなら、6.1で.5に記載された結論ステップを実行してください。
6.1.4 Preparation for Certificate i+1
6.1.4 Certificate i+1のための準備
To prepare for processing of certificate i+1, perform the following steps for certificate i:
+1 証明書iの処理の用意をするには、証明書iのための以下のステップを実行してください:
Housley, et. al. Standards Track [Page 75] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[75ページ]。
(a) If a policy mapping extension is present, verify that the
special value anyPolicy does not appear as an issuerDomainPolicy
or a subjectDomainPolicy.
(a) 拡大を写像する方針が存在しているなら、特別な値のanyPolicyがissuerDomainPolicyかsubjectDomainPolicyとして現れないことを確かめてください。
(b) If a policy mapping extension is present, then for each
issuerDomainPolicy ID-P in the policy mapping extension:
(b) 拡大を写像する方針がそして、拡大を写像する方針によるそれぞれのissuerDomainPolicy ID-Pのために存在しているなら:
(1) If the policy_mapping variable is greater than 0, for each
node in the valid_policy_tree of depth i where ID-P is the
valid_policy, set expected_policy_set to the set of
subjectDomainPolicy values that are specified as equivalent to
ID-P by the policy mapping extension.
(1) 方針_マッピング変数が0以上であるなら、ID-Pが有効な_方針である深さiの有効な_方針_木の各ノードに関して、セットは、_方針_が拡大を写像する方針でID-Pに同じくらい同等な状態で指定されるsubjectDomainPolicy値のセットにセットしたと予想しました。
If no node of depth i in the valid_policy_tree has a
valid_policy of ID-P but there is a node of depth i with a
valid_policy of anyPolicy, then generate a child node of the
node of depth i-1 that has a valid_policy of anyPolicy as
follows:
有効な_方針_木の深さiのどんなノードにもID-Pの有効な_方針がありませんが、深さiのノードがanyPolicyの有効な_方針であれば、anyPolicyの有効な_方針を以下の通りにする深さi-1のノードの子供ノードを作ってください:
(i) set the valid_policy to ID-P;
(i) ID-Pに有効な_方針を設定してください。
(ii) set the qualifier_set to the qualifier set of the
policy anyPolicy in the certificate policies extension of
certificate i;
(ii) 証明書iの証明書方針拡張子で方針anyPolicyの資格を与える人セットに資格を与える人_セットを設定してください。
(iii) set the criticality_indicator to the criticality of
the certificate policies extension of certificate i;
(iii) 証明書iの証明書方針拡張子の臨界に臨界_インディケータを設定してください。
(iv) and set the expected_policy_set to the set of
subjectDomainPolicy values that are specified as equivalent
to ID-P by the policy mappings extension.
(iv)と予想された_方針_が方針マッピング拡張子でID-Pに同じくらい同等な状態で指定されるsubjectDomainPolicy値のセットに設定するセット。
(2) If the policy_mapping variable is equal to 0:
(2) 方針_マッピング変数が0と等しいなら:
(i) delete each node of depth i in the valid_policy_tree
where ID-P is the valid_policy.
(i) 有効な_方針_木のID-Pが有効な_方針である深さiの各ノードを削除してください。
(ii) If there is a node in the valid_policy_tree of depth
i-1 or less without any child nodes, delete that node.
Repeat this step until there are no nodes of depth i-1 or
less without children.
(ii) ノードが深さi-1か以下の有効な_方針_木に少しも子供ノードなしであれば、そのノードを削除してください。 深さi-1か以下のノードが全く子供なしでないまで、このステップを繰り返してください。
(c) Assign the certificate subject name to working_issuer_name.
(c) 働く_発行人_名に証明書対象名を割り当ててください。
(d) Assign the certificate subjectPublicKey to
working_public_key.
(d) 働く_公共の_キーに証明書subjectPublicKeyを割り当ててください。
Housley, et. al. Standards Track [Page 76] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[76ページ]。
(e) If the subjectPublicKeyInfo field of the certificate contains
an algorithm field with non-null parameters, assign the parameters
to the working_public_key_parameters variable.
(e) 証明書のsubjectPublicKeyInfo分野が非ヌルパラメタがあるアルゴリズム分野を含むなら、働く_の公共の_主要な_パラメタ変数にパラメタを割り当ててください。
If the subjectPublicKeyInfo field of the certificate contains an
algorithm field with null parameters or parameters are omitted,
compare the certificate subjectPublicKey algorithm to the
working_public_key_algorithm. If the certificate subjectPublicKey
algorithm and the working_public_key_algorithm are different, set
the working_public_key_parameters to null.
証明書のsubjectPublicKeyInfo分野がヌルパラメタがあるアルゴリズム分野を含んでいるか、またはパラメタが省略されるなら、働く_公共の_主要な_アルゴリズムに証明書subjectPublicKeyアルゴリズムをたとえてください。 証明書subjectPublicKeyアルゴリズムと働く_公共の_主要な_アルゴリズムが異なるなら、働く_公共の_主要な_パラメタをヌルに設定してください。
(f) Assign the certificate subjectPublicKey algorithm to the
working_public_key_algorithm variable.
(f) 働く_の公共の_主要な_アルゴリズム変数に証明書subjectPublicKeyアルゴリズムを割り当ててください。
(g) If a name constraints extension is included in the
certificate, modify the permitted_subtrees and excluded_subtrees
state variables as follows:
(g) 名前規制拡大が証明書に含まれているなら、受入れられた_下位木を変更してください。そうすれば、除かれた_下位木は以下の変数を述べます:
(1) If permittedSubtrees is present in the certificate, set
the permitted_subtrees state variable to the intersection of
its previous value and the value indicated in the extension
field. If permittedSubtrees does not include a particular name
type, the permitted_subtrees state variable is unchanged for
that name type. For example, the intersection of nist.gov and
csrc.nist.gov is csrc.nist.gov. And, the intersection of
nist.gov and rsasecurity.com is the empty set.
(1) permittedSubtreesが証明書に存在しているなら、前の値と価値の交差点への州の変数が拡大分野で示した受入れられた_下位木を設定してください。 permittedSubtreesが特定の名前タイプを含んでいないなら、受入れられた_下位木は、その名前タイプに、変数が変わりがないと述べます。 例えば、nist.govとcsrc.nist.govの交差点はcsrc.nist.govです。 そして、nist.govとrsasecurity.comの交差点は空集合です。
(2) If excludedSubtrees is present in the certificate, set the
excluded_subtrees state variable to the union of its previous
value and the value indicated in the extension field. If
excludedSubtrees does not include a particular name type, the
excluded_subtrees state variable is unchanged for that name
type. For example, the union of the name spaces nist.gov and
csrc.nist.gov is nist.gov. And, the union of nist.gov and
rsasecurity.com is both name spaces.
(2) excludedSubtreesが証明書に存在しているなら、前の値と価値の組合への州の変数が拡大分野で示した除かれた_下位木を設定してください。 excludedSubtreesが特定の名前タイプを含んでいないなら、除かれた_下位木は、その名前タイプに、変数が変わりがないと述べます。 例えば、名前空間のnist.govとcsrc.nist.govの組合はnist.govです。 そして、nist.govとrsasecurity.comの組合は両方の名前空間です。
(h) If the issuer and subject names are not identical:
(h) 発行人と対象の名前が同じでないなら:
(1) If explicit_policy is not 0, decrement explicit_policy by
1.
(1) 明白な_方針が0でないなら、明白な_方針を1つ減少させてください。
(2) If policy_mapping is not 0, decrement policy_mapping by 1.
(2) 方針_マッピングが0でないなら、方針_マッピングを1つ減少させてください。
(3) If inhibit_any-policy is not 0, decrement inhibit_any-
policy by 1.
(3)、禁止、_-方針がいくらか、0、減少が_いずれも禁止するということでない、-、1の方針
Housley, et. al. Standards Track [Page 77] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[77ページ]。
(i) If a policy constraints extension is included in the
certificate, modify the explicit_policy and policy_mapping state
variables as follows:
(i) 方針規制拡大が証明書に含まれているなら、以下の明白な_方針と方針_マッピング州の変数を変更してください:
(1) If requireExplicitPolicy is present and is less than
explicit_policy, set explicit_policy to the value of
requireExplicitPolicy.
(1) requireExplicitPolicyが存在していて、明白な_方針以下であるなら、明白な_方針をrequireExplicitPolicyの値に設定してください。
(2) If inhibitPolicyMapping is present and is less than
policy_mapping, set policy_mapping to the value of
inhibitPolicyMapping.
(2) inhibitPolicyMappingが存在していて、方針_マッピング以下であるなら、方針_マッピングをinhibitPolicyMappingの値に設定してください。
(j) If the inhibitAnyPolicy extension is included in the
certificate and is less than inhibit_any-policy, set inhibit_any-
policy to the value of inhibitAnyPolicy.
-(j) inhibitAnyPolicy拡張子は_を禁止するほど証明書に含まれていて、ないならいくらか、方針、セットが_いずれも禁止する、-、inhibitAnyPolicyの値への方針。
(k) Verify that the certificate is a CA certificate (as specified
in a basicConstraints extension or as verified out-of-band).
(k) 証明書がカリフォルニア証明書(basicConstraints拡張子かバンドの外で確かめられるのと同じくらい指定された)であることを確かめてください。
(l) If the certificate was not self-issued, verify that
max_path_length is greater than zero and decrement max_path_length
by 1.
(l) 証明書が自己に発行されなかったなら、最大_経路_の長さが1時までにゼロと減少最大_経路_の長さより大きいことを確かめてください。
(m) If pathLengthConstraint is present in the certificate and is
less than max_path_length, set max_path_length to the value of
pathLengthConstraint.
(m) pathLengthConstraintが証明書に存在していて、最大_経路_の長さ以下であるなら、最大_経路_の長さをpathLengthConstraintの値に設定してください。
(n) If a key usage extension is present, verify that the
keyCertSign bit is set.
(n) 主要な用法拡大が存在しているなら、keyCertSignビットが設定されることを確かめてください。
(o) Recognize and process any other critical extension present in
the certificate. Process any other recognized non-critical
extension present in the certificate.
(o)は、証明書の現在のいかなる他の批判的な拡大も認識して、処理します。 証明書の現在のいかなる他の認識された非臨界拡大も処理してください。
If check (a), (k), (l), (n) or (o) fails, the procedure terminates, returning a failure indication and an appropriate reason.
チェック(a)、(k)、(l)、(n)または(o)が失敗するなら、手順は終わって、失敗指示と適切な理由を返します。
If (a), (k), (l), (n) and (o) have completed successfully, increment i and perform the basic certificate processing specified in 6.1.3.
(k)、(n)と(o)が持っている(l)が首尾よく完成して、(a)であるなら、iを増加してくださいといって、処理が指定した基本の証明書を実行してください、6.1、.3
6.1.5 Wrap-up procedure
6.1.5 結論手順
To complete the processing of the end entity certificate, perform the following steps for certificate n:
終わりの実体証明書の処理を終了するには、証明書nのための以下のステップを実行してください:
(a) If certificate n was not self-issued and explicit_policy is
not 0, decrement explicit_policy by 1.
(a) 証明書nが自己に発行されないで、また明白な_方針が0でないなら、明白な_方針を1つ減少させてください。
Housley, et. al. Standards Track [Page 78] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[78ページ]。
(b) If a policy constraints extension is included in the
certificate and requireExplicitPolicy is present and has a value
of 0, set the explicit_policy state variable to 0.
(b) 方針規制拡大が証明書に含まれていて、requireExplicitPolicyが存在していて、0の値を持っているなら、明白な_政策ポジション変数を0に設定してください。
(c) Assign the certificate subjectPublicKey to
working_public_key.
(c) 働く_公共の_キーに証明書subjectPublicKeyを割り当ててください。
(d) If the subjectPublicKeyInfo field of the certificate contains
an algorithm field with non-null parameters, assign the parameters
to the working_public_key_parameters variable.
(d) 証明書のsubjectPublicKeyInfo分野が非ヌルパラメタがあるアルゴリズム分野を含むなら、働く_の公共の_主要な_パラメタ変数にパラメタを割り当ててください。
If the subjectPublicKeyInfo field of the certificate contains an
algorithm field with null parameters or parameters are omitted,
compare the certificate subjectPublicKey algorithm to the
working_public_key_algorithm. If the certificate subjectPublicKey
algorithm and the working_public_key_algorithm are different, set
the working_public_key_parameters to null.
証明書のsubjectPublicKeyInfo分野がヌルパラメタがあるアルゴリズム分野を含んでいるか、またはパラメタが省略されるなら、働く_公共の_主要な_アルゴリズムに証明書subjectPublicKeyアルゴリズムをたとえてください。 証明書subjectPublicKeyアルゴリズムと働く_公共の_主要な_アルゴリズムが異なるなら、働く_公共の_主要な_パラメタをヌルに設定してください。
(e) Assign the certificate subjectPublicKey algorithm to the
working_public_key_algorithm variable.
(e) 働く_の公共の_主要な_アルゴリズム変数に証明書subjectPublicKeyアルゴリズムを割り当ててください。
(f) Recognize and process any other critical extension present in
the certificate n. Process any other recognized non-critical
extension present in certificate n.
(f) 証明書nの現在のいかなる他の批判的な拡大も認識して、処理してください。 証明書nの現在のいかなる他の認識された非臨界拡大も処理してください。
(g) Calculate the intersection of the valid_policy_tree and the
user-initial-policy-set, as follows:
(g) 以下の通り有効な_方針_木とユーザの初期の方針セットの交差点について計算してください:
(i) If the valid_policy_tree is NULL, the intersection is
NULL.
(i) 有効な_方針_木がNULLであるなら、交差点はNULLです。
(ii) If the valid_policy_tree is not NULL and the user-
initial-policy-set is any-policy, the intersection is the
entire valid_policy_tree.
有効な_方針_木であるなら(ii)がNULLでなく、ユーザの初期の方針セットがNULLである、いくらか、-、方針、交差点は全体の有効な_方針_木です。
(iii) If the valid_policy_tree is not NULL and the user-
initial-policy-set is not any-policy, calculate the
intersection of the valid_policy_tree and the user-initial-
policy-set as follows:
有効な_方針_木であるなら(iii)がNULLでなく、またユーザの初期の方針セットがNULLでない、いくらか、-、方針、以下の有効な_方針_木であってユーザ初期に方針への設定にされるのの交差点について計算してください:
1. Determine the set of policy nodes whose parent nodes
have a valid_policy of anyPolicy. This is the
valid_policy_node_set.
1. 親ノードにはanyPolicyの有効な_方針がある方針ノードのセットを決定してください。 これは有効な_方針_ノード_セットです。
2. If the valid_policy of any node in the
valid_policy_node_set is not in the user-initial-policy-set
and is not anyPolicy, delete this node and all its children.
2. 有効な_方針_ノード_セットにおけるどんなノードの有効な_方針もユーザの初期の方針セットになくて、またanyPolicyでないなら、このノードとそのすべての子供を削除してください。
Housley, et. al. Standards Track [Page 79] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[79ページ]。
3. If the valid_policy_tree includes a node of depth n with
the valid_policy anyPolicy and the user-initial-policy-set
is not any-policy perform the following steps:
3. 有効な_方針_木が深さのノードを含んでいるなら有効な_方針anyPolicyとユーザの初期の方針セットがあるnがそうでない、いくらか、-、方針、以下のステップを実行してください:
a. Set P-Q to the qualifier_set in the node of depth n
with valid_policy anyPolicy.
a。 有効な_方針anyPolicyで深さnのノードで用意ができている資格を与える人_にP-Qを設定してください。
b. For each P-OID in the user-initial-policy-set that is
not the valid_policy of a node in the
valid_policy_node_set, create a child node whose parent
is the node of depth n-1 with the valid_policy anyPolicy.
Set the values in the child node as follows: set the
valid_policy to P-OID; set the qualifier_set to P-Q; copy
the criticality_indicator from the node of depth n with
the valid_policy anyPolicy; and set the
expected_policy_set to {P-OID}.
b。 有効な_方針_ノード_セットにおけるノードの有効な_方針でないユーザの初期の方針セットにおける各P-OIDに関しては、有効な_方針anyPolicyで親が深さn-1のノードである子供ノードを作成してください。 以下の子供ノードに値をはめ込んでください: 有効な_方針をP-OIDに設定してください。 資格を与える人_セットをP-Qに設定してください。 深さnのノードから有効な_方針anyPolicyで臨界_インディケータをコピーしてください。 そして、予想された_方針_セットをP-OIDに設定してください。
c. Delete the node of depth n with the valid_policy
anyPolicy.
c。 有効な_方針anyPolicyで深さnのノードを削除してください。
4. If there is a node in the valid_policy_tree of depth n-1
or less without any child nodes, delete that node. Repeat
this step until there are no nodes of depth n-1 or less
without children.
4. ノードが深さn-1か以下の有効な_方針_木に少しも子供ノードなしであれば、そのノードを削除してください。 深さn-1か以下のノードが全く子供なしでないまで、このステップを繰り返してください。
If either (1) the value of explicit_policy variable is greater than zero, or (2) the valid_policy_tree is not NULL, then path processing has succeeded.
(1) 明白な_政策変数の値がゼロ以上であるか(2) 有効な_方針_木がNULLでないなら、経路処理は成功しました。
6.1.6 Outputs
6.1.6 出力
If path processing succeeds, the procedure terminates, returning a success indication together with final value of the valid_policy_tree, the working_public_key, the working_public_key_algorithm, and the working_public_key_parameters.
経路処理が成功するなら、手順は終わります、有効な_方針_木、働く_公共の_キー、働く_公共の_主要な_アルゴリズム、および働く_公共の_主要な_パラメタの検査値と共に成功指示を返して。
6.2 Using the Path Validation Algorithm
6.2 経路合法化アルゴリズムを使用すること。
The path validation algorithm describes the process of validating a single certification path. While each certification path begins with a specific trust anchor, there is no requirement that all certification paths validated by a particular system share a single trust anchor. An implementation that supports multiple trust anchors MAY augment the algorithm presented in section 6.1 to further limit the set of valid certification paths which begin with a particular trust anchor. For example, an implementation MAY modify the algorithm to apply name constraints to a specific trust anchor during the initialization phase, or the application MAY require the presence
経路合法化アルゴリズムはただ一つの証明経路を有効にする過程について説明します。 それぞれの証明経路は特定の信用アンカーと共に始まりますが、特定のシステムによって有効にされたすべての証明経路が独身の信用アンカーを共有するという要件が全くありません。 複数の信用アンカーを支持する実現はさらに特定の信用アンカーと共に始まる有効な証明経路のセットを制限するためにセクション6.1に提示されたアルゴリズムを増大させるかもしれません。 例えば、実現が初期設定段階の間、特定の信用アンカーに名前規制を適用するようにアルゴリズムを変更するかもしれませんか、またはアプリケーションは存在を必要とするかもしれません。
Housley, et. al. Standards Track [Page 80] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[80ページ]。
of a particular alternative name form in the end entity certificate, or the application MAY impose requirements on application-specific extensions. Thus, the path validation algorithm presented in section 6.1 defines the minimum conditions for a path to be considered valid.
特定の代替名では、終わりの実体証明書で形成してください。さもないと、アプリケーションはアプリケーション特有の拡大に要件を課すかもしれません。 したがって、セクション6.1に提示された経路合法化アルゴリズムは経路が有効であると考えられる最小の状態を定義します。
The selection of one or more trusted CAs is a local decision. A system may provide any one of its trusted CAs as the trust anchor for a particular path. The inputs to the path validation algorithm may be different for each path. The inputs used to process a path may reflect application-specific requirements or limitations in the trust accorded a particular trust anchor. For example, a trusted CA may only be trusted for a particular certificate policy. This restriction can be expressed through the inputs to the path validation procedure.
1かさらに信じられたCAsの品揃えはローカルの決定です。 システムは特定の経路への信用アンカーとして信じられたCAsのいずれも提供するかもしれません。 各経路において、経路合法化アルゴリズムへの入力は異なっているかもしれません。 経路を処理するのに使用される入力は特定の信用アンカーに与えられた信用におけるアプリケーション決められた一定の要求か制限を反映するかもしれません。 例えば、信じられたカリフォルニアは特定の証明書方針のために信じられるだけであるかもしれません。 経路合法化手順への入力でこの制限を表すことができます。
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 Authority (PCA) 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 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.
また、PEM[RFC1422]の規則と同じデフォルトの振舞いをもたらす上の証明経路現像処理の拡張版を指定するのも可能です。 この拡張版では、手順への追加入力は、1つ以上のPolicy認証局(PCA)名のリストとPCAが予想される証明経路の位置のインディケータです。 指名PCA位置では、カリフォルニア名がこのリストに対してたとえられます。 認識されたPCA名が見つけられるなら、SubordinateToCAの規制は証明経路の残りのためにそれとなく想定されます、そして、処理は続きます。 特定された方針に基づいて証明経路を有効にすることができないならどんな妥当なPCA名も見つけられないなら、証明経路は無効であると考えられます。
6.3 CRL Validation
6.3 CRL合法化
This section describes the steps necessary to determine if a certificate is revoked or on hold status when CRLs are the revocation mechanism used by the certificate issuer. Conforming implementations that support CRLs are not required to implement this algorithm, but they MUST be functionally equivalent to the external behavior resulting from this procedure. Any algorithm may be used by a particular implementation so long as it derives the correct result.
CRLsが証明書発行人によって使用された取消しメカニズムであるときに、このセクションは証明書が取り消されるかどうか決定するのに必要なステップか保留状態について説明します。 CRLsを支持する従う実現はこのアルゴリズムを実行するのに必要ではありませんが、彼らはこの手順から生じる外部の振舞いに機能上同等でなければなりません。 正しい結果を引き出す限り、どんなアルゴリズムも特定の実現で使用されるかもしれません。
This algorithm assumes that all of the needed CRLs are available in a local cache. Further, if the next update time of a CRL has passed, the algorithm assumes a mechanism to fetch a current CRL and place it in the local CRL cache.
このアルゴリズムは、必要なCRLsのすべてがローカルなキャッシュで利用可能であると仮定します。 さらに、CRLの次のアップデート時間が過ぎたなら、アルゴリズムは、現在のCRLをとって来て、ローカルなCRLキャッシュにそれを置くためにメカニズムを仮定します。
This algorithm defines a set of inputs, a set of state variables, and processing steps that are performed for each certificate in the path. The algorithm output is the revocation status of the certificate.
このアルゴリズムは経路の各証明書のために実行される1セットの1セットの入力、州の変数、および処理ステップを定義します。 アルゴリズム出力は証明書の取消し状態です。
Housley, et. al. Standards Track [Page 81] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[81ページ]。
6.3.1 Revocation Inputs
6.3.1 取消し入力
To support revocation processing, the algorithm requires two inputs:
取消し処理を支持するために、アルゴリズムは2つの入力を必要とします:
(a) certificate: The algorithm requires the certificate serial
number and issuer name to determine whether a certificate is on a
particular CRL. The basicConstraints extension is used to
determine whether the supplied certificate is associated with a CA
or an end entity. If present, the algorithm uses the
cRLDistributionsPoint and freshestCRL extensions to determine
revocation status.
(a) 以下を証明してください。 アルゴリズムは、証明書が特定のCRLにあるかを決定するために証明書通し番号と発行人名を必要とします。 basicConstraints拡張子は、供給された証明書がカリフォルニアか終わりの実体に関連しているかどうか決定するのに使用されます。 存在しているなら、アルゴリズムは、取消し状態を決定するのにcRLDistributionsPointとfreshestCRL拡張子を使用します。
(b) use-deltas: This boolean input determines whether delta CRLs
are applied to CRLs.
(b)、デルタを使用する、: この論理演算子入力は、デルタCRLsがCRLsに適用されるかどうか決定します。
Note that implementations supporting legacy PKIs, such as RFC 1422
and X.509 version 1, will need an additional input indicating
whether the supplied certificate is associated with a CA or an end
entity.
レガシーがPKIsであるとサポートするRFC1422やX.509バージョン1などの実装が供給された証明書がカリフォルニアか終わりの実体に関連しているかどうかを示す追加入力を必要とすることに注意してください。
6.3.2 Initialization and Revocation State Variables
6.3.2 初期設定と取消し州の変数
To support CRL processing, the algorithm requires the following state variables:
CRLが処理であるとサポートするために、アルゴリズムは以下の州の変数を必要とします:
(a) reasons_mask: This variable contains the set of revocation
reasons supported by the CRLs and delta CRLs processed so far.
The legal members of the set are the possible revocation reason
values: unspecified, keyCompromise, caCompromise,
affiliationChanged, superseded, cessationOfOperation,
certificateHold, privilegeWithdrawn, and aACompromise. The
special value all-reasons is used to denote the set of all legal
members. This variable is initialized to the empty set.
(a) 理由_マスク: この変数は今までのところ処理されているCRLsのCRLsとデルタによってサポートされた取消し理由のセットを含んでいます。 セットの法的なメンバーは可能な取消し理由値です: 不特定である、keyCompromise、affiliationChangedであって、取って代わられたcaCompromise、cessationOfOperation、certificateHold、privilegeWithdrawn、およびaACompromise。 特別番組は、すべての法的なメンバーのセットを指示するのに使用されます値が、オール推論する。 この変数は空集合に初期化されます。
(b) cert_status: This variable contains the status of the
certificate. This variable may be assigned one of the following
values: unspecified, keyCompromise, caCompromise,
affiliationChanged, superseded, cessationOfOperation,
certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise,
the special value UNREVOKED, or the special value UNDETERMINED.
This variable is initialized to the special value UNREVOKED.
(b)本命_状態: この変数は証明書の状態を含んでいます。 以下の値の1つはこの変数に割り当てられるかもしれません: 不特定であることで、keyCompromise、caCompromise、affiliationChangedが取って代わられて、cessationOfOperation、certificateHold、removeFromCRL、privilegeWithdrawn、aACompromise、特別な値のUNREVOKED、または特別番組がUNDETERMINEDを評価します。 この変数は特別な値のUNREVOKEDに初期化されます。
(c) interim_reasons_mask: This contains the set of revocation
reasons supported by the CRL or delta CRL currently being
processed.
(c) 当座の_は_マスクを推論します: これは処理される現在CRLのCRLかデルタによってサポートされている取消し理由のセットを含んでいます。
Housley, et. al. Standards Track [Page 82] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[82ページ]。
Note: In some environments, it is not necessary to check all reason codes. For example, some environments are only concerned with caCompromise and keyCompromise for CA certificates. This algorithm checks all reason codes. Additional processing and state variables may be necessary to limit the checking to a subset of the reason codes.
以下に注意してください。 いくつかの環境で、すべての理由コードをチェックするのは必要ではありません。 例えば、いくつかの環境がカリフォルニア証明書のためのcaCompromiseとkeyCompromiseに関係があるだけです。 このアルゴリズムはすべての理由コードをチェックします。 追加処理と州の変数が、照合を理由コードの部分集合に制限するのに必要であるかもしれません。
6.3.3 CRL Processing
6.3.3 CRL処理
This algorithm begins by assuming the certificate is not revoked. The algorithm checks one or more CRLs until either the certificate status is determined to be revoked or sufficient CRLs have been checked to cover all reason codes.
証明書が取り消されないと仮定することによって、このアルゴリズムは始まります。 証明書状態が取り消されることを決定しているか、または十分なCRLsがすべての理由コードをカバーするためにチェックされるまで、アルゴリズムは1CRLsをチェックします。
For each distribution point (DP) in the certificate CRL distribution points extension, for each corresponding CRL in the local CRL cache, while ((reasons_mask is not all-reasons) and (cert_status is UNREVOKED)) perform the following:
それぞれの分配ポイントに、証明書CRL分配における(DP)は、(_マスクがオール理由でない理由)である間、それぞれの対応するCRLのためにローカルなCRLキャッシュで拡大を指して、以下を実行します(本命_状態はUNREVOKEDです):
(a) Update the local CRL cache by obtaining a complete CRL, a
delta CRL, or both, as required:
(a) 必要に応じて完全なCRL、CRLデルタ、または両方を入手することによって、ローカルなCRLキャッシュをアップデートしてください:
(1) If the current time is after the value of the CRL next
update field, then do one of the following:
(1) 現在の時間がCRLの値の後に次にあるなら、分野をアップデートしてください、そして、次に、以下の1つをしてください:
(i) If use-deltas is set and either the certificate or the
CRL contains the freshest CRL extension, obtain a delta CRL
with the a next update value that is after the current time
and can be used to update the locally cached CRL as
specified in section 5.2.4.
デルタを使用するなら(i)が設定していて、セクション5.2.4で指定されるように証明書かCRLのどちらかは最も新鮮なCRL拡張子を含んでいて、次のアップデートが評価する現在の時間の後に、あるaでCRLデルタを得て、局所的にキャッシュされたCRLをアップデートするのに使用できます。
(ii) Update the local CRL cache with a current complete
CRL, verify that the current time is before the next update
value in the new CRL, and continue processing with the new
CRL. If use-deltas is set, then obtain the current delta
CRL that can be used to update the new locally cached
complete CRL as specified in section 5.2.4.
(ii) 現在の完全なCRLと共にローカルなCRLキャッシュをアップデートしてください、そして、現在の時間が次のアップデート値の前に新しいCRLにあることを確かめてください、そして、新しいCRLと共に処理し続けてください。 デルタを使用する、.4にセクション5.2の指定されるとしての新しい局所的にキャッシュされた完全なCRLをアップデートするのに使用できるCRLの現在のデルタを設定して、次に、得ることです。
(2) If the current time is before the value of the next update
field and use-deltas is set, then obtain the current delta CRL
that can be used to update the locally cached complete CRL as
specified in section 5.2.4.
現在の時間が次のアップデート分野の値の前に、あって、デルタを使用するなら、(2)はセクション5.2.4における指定されるとしての局所的にキャッシュされた完全なCRLをアップデートするのに使用できるCRLの現在のデルタを設定して、次に、得ることです。
(b) Verify the issuer and scope of the complete CRL as follows:
(b) 以下の完全なCRLの発行人と範囲について確かめてください:
Housley, et. al. Standards Track [Page 83] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[83ページ]。
(1) If the DP includes cRLIssuer, then verify that the issuer
field in the complete CRL matches cRLIssuer in the DP and that
the complete CRL contains an issuing distribution point
extension with the indrectCRL boolean asserted. Otherwise,
verify that the CRL issuer matches the certificate issuer.
(1) DPがcRLIssuerを含んでいるなら、完全なCRLの発行人分野がDPでcRLIssuerに合って、完全なCRLがindrectCRL論理演算子があるポイント拡大が断言した発行分配を含むことを確かめてください。 さもなければ、CRL発行人が証明書発行人に合っていることを確かめてください。
(2) If the complete CRL includes an issuing distribution point
(IDP) CRL extension check the following:
(2) 完全なCRLが発行している分配ポイント(IDP)CRL拡張子を含んでいるなら、以下をチェックしてください:
(i) If the distribution point name is present in the IDP
CRL extension and the distribution field is present in the
DP, then verify that one of the names in the IDP matches one
of the names in the DP. If the distribution point name is
present in the IDP CRL extension and the distribution field
is omitted from the DP, then verify that one of the names in
the IDP matches one of the names in the cRLIssuer field of
the DP.
(i) 存在というIDP CRL拡張子と分配分野の現在の分配ポイント名がDPに存在しているなら、IDPの名前の1つがDPの名前の1つに合っていることを確かめてください。 存在というIDP CRL拡張子と分配分野の現在の分配ポイント名がDPから省略されるなら、IDPの名前の1つがDPのcRLIssuer分野で名前の1つに合っていることを確かめてください。
(ii) If the onlyContainsUserCerts boolean is asserted in
the IDP CRL extension, verify that the certificate does not
include the basic constraints extension with the cA boolean
asserted.
(ii) onlyContainsUserCerts論理演算子がIDP CRL拡張子で断言されるなら、証明書がcA論理演算子が断言されている基本的な規制拡大を含んでいないことを確かめてください。
(iii) If the onlyContainsCACerts boolean is asserted in the
IDP CRL extension, verify that the certificate includes the
basic constraints extension with the cA boolean asserted.
(iii) onlyContainsCACerts論理演算子がIDP CRL拡張子で断言されるなら、証明書がcA論理演算子が断言されている基本的な規制拡大を含んでいることを確かめてください。
(iv) Verify that the onlyContainsAttributeCerts boolean is
not asserted.
(iv) onlyContainsAttributeCerts論理演算子が断言されないことを確かめてください。
(c) If use-deltas is set, verify the issuer and scope of the
delta CRL as follows:
デルタを使用するなら、(c)はセットであり、以下のCRLデルタの発行人と範囲について確かめてください:
(1) Verify that the delta CRL issuer matches complete CRL
issuer.
(1) デルタCRL発行人が完全なCRL発行人に合っていることを確かめてください。
(2) If the complete CRL includes an issuing distribution point
(IDP) CRL extension, verify that the delta CRL contains a
matching IDP CRL extension. If the complete CRL omits an IDP
CRL extension, verify that the delta CRL also omits an IDP CRL
extension.
(2) 完全なCRLが発行分配を含んでいるなら、(IDP)CRL拡張子を指してください、そして、CRLデルタが合っているIDP CRL拡張子を含むことを確かめてください。 完全なCRLがIDP CRL拡張子を省略するなら、また、CRLデルタがIDP CRL拡張子を省略することを確かめてください。
(3) Verify that the delta CRL authority key identifier
extension matches complete CRL authority key identifier
extension.
(3) デルタのCRLの権威の主要な識別子拡張子が完全なCRL権威主要な識別子拡張子に合っていることを確かめてください。
Housley, et. al. Standards Track [Page 84] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[84ページ]。
(d) Compute the interim_reasons_mask for this CRL as follows:
(d) 以下のこのCRLのために当座の_理由_マスクを計算してください:
(1) If the issuing distribution point (IDP) CRL extension is
present and includes onlySomeReasons and the DP includes
reasons, then set interim_reasons_mask to the intersection of
reasons in the DP and onlySomeReasons in IDP CRL extension.
(1) 発行分配であるなら、ポイント(IDP)CRL拡張子は、存在していて、onlySomeReasonsを含んでいます、そして、DPはIDP CRL拡張子で理由、当時のセット当座_理由_マスクをDPとonlySomeReasonsの理由の交差点に含めます。
(2) If the IDP CRL extension includes onlySomeReasons but the
DP omits reasons, then set interim_reasons_mask to the value of
onlySomeReasons in IDP CRL extension.
(2) IDP CRL拡張子がonlySomeReasonsを含んでいますが、DPが理由を省略するなら、当座の_理由_マスクをIDP CRL拡張子における、onlySomeReasonsの値に設定してください。
(3) If the IDP CRL extension is not present or omits
onlySomeReasons but the DP includes reasons, then set
interim_reasons_mask to the value of DP reasons.
(3) IDP CRL拡張子が存在していないか、またはonlySomeReasonsを省略しますが、DPが理由を含んでいるなら、セット当座_理由_はDPの値に理由にマスクをかけます。
(4) If the IDP CRL extension is not present or omits
onlySomeReasons and the DP omits reasons, then set
interim_reasons_mask to the special value all-reasons.
(4) IDP CRL拡張子が存在していないか、またはonlySomeReasonsを省略して、DPが理由を省略するなら、セット当座_理由_は特別な値にオール理由にマスクをかけます。
(e) Verify that interim_reasons_mask includes one or more reasons that is not included in the reasons_mask.
(e) 当座の_理由_マスクがそれが理由_マスクに含まれていない1つ以上の理由を含んでいることを確かめてください。
(f) Obtain and validate the certification path for the complete CRL issuer. If a key usage extension is present in the CRL issuer's certificate, verify that the cRLSign bit is set.
(f) 完全なCRL発行人のために証明経路を得て、有効にしてください。 主要な用法拡大がCRL発行人の証明書に存在しているなら、cRLSignビットが設定されることを確かめてください。
(g) Validate the signature on the complete CRL using the public key validated in step (f).
(g) ステップ(f)で有効にされた公開鍵を使用して、完全なCRLで署名を有効にしてください。
(h) If use-deltas is set, then validate the signature on the delta CRL using the public key validated in step (f).
デルタを使用するなら、(h)はセットして、次に、CRLデルタでステップ(f)で有効にされた公開鍵を使用することで署名を有効にすることです。
(i) If use-deltas is set, then search for the certificate on the delta CRL. If an entry is found that matches the certificate issuer and serial number as described in section 5.3.4, then set the cert_status variable to the indicated reason as follows:
デルタを使用するなら(i)がセットである、CRLはその時、デルタの証明書を探します。 セクション5.3.4で説明されるように証明書発行人と通し番号に合っているエントリーが見つけられるなら、本命_状態変数を以下の示された理由に設定してください:
(1) If the reason code CRL entry extension is present, set the
cert_status variable to the value of the reason code CRL entry
extension.
(1) 理由コードCRLエントリー拡張子が存在しているなら、理由コードCRLエントリー拡張子の値に本命_状態変数を設定してください。
(2) If the reason code CRL entry extension is not present, set
the cert_status variable to the value unspecified.
(2) 理由コードCRLエントリー拡張子が存在していないなら、本命_状態変数を不特定の状態で値に設定してください。
Housley, et. al. Standards Track [Page 85] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[85ページ]。
(j) If (cert_status is UNREVOKED), then search for the
certificate on the complete CRL. If an entry is found that
matches the certificate issuer and serial number as described in
section 5.3.4, then set the cert_status variable to the indicated
reason as described in step (i).
(j)、(本命_状態はUNREVOKEDです)、そして、完全なCRLの上の証明書を検索してください。 セクション5.3.4で説明されるように証明書発行人と通し番号に合っているエントリーが見つけられるなら、ステップ(i)で説明されるように本命_状態変数を示された理由に設定してください。
(k) If (cert_status is removeFromCRL), then set cert_status to
UNREVOKED.
(k)、(本命_状態はremoveFromCRLです)、UNREVOKEDへの本命_状態はその時、セットしました。
If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)), then the revocation status has been determined, so return cert_status.
取消し状態が((_マスクがオール理由である理由)OR(本命_状態はUNREVOKEDでない))であるなら決定しているので、本命_に状態を返してください。
If the revocation status has not been determined, repeat the process above with any available CRLs not specified in a distribution point but issued by the certificate issuer. For the processing of such a CRL, assume a DP with both the reasons and the cRLIssuer fields omitted and a distribution point name of the certificate issuer. That is, the sequence of names in fullName is generated from the certificate issuer field as well as the certificate issuerAltName extension. If the revocation status remains undetermined, then return the cert_status UNDETERMINED.
取消し状態が決定していないなら、分配ポイントで指定されませんが、証明書発行人によって発行されているどんな利用可能なCRLsでの上のプロセスも繰り返してください。 そのようなCRLの処理には、理由とcRLIssuer分野の両方が省略されているDPと証明書発行人の分配ポイント名を仮定してください。 すなわち、fullNameの名前の系列は証明書issuerAltName拡張子と同様に証明書発行人分野から生成されます。 取消し状態が非決定したままで残っているなら、本命_状態UNDETERMINEDを返してください。
7 References
7つの参照箇所
[ISO 10646] ISO/IEC 10646-1:1993. International Standard --
Information technology -- Universal Multiple-Octet Coded
Character Set (UCS) -- Part 1: Architecture and Basic
Multilingual Plane.
[ISO10646] ISO/IEC10646-1:1993。 国際規格--情報技術--普遍的なMultiple-八重奏Coded文字コード(UCS)--第1部: アーキテクチャと基本多言語水準。
[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 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日
Housley, et. al. Standards Track [Page 86] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[86ページ]。
[RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)," RFC 1510, September 1993.
[RFC1510] コールとJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。
[RFC 1519] Fuller, V., T. Li, J. Yu 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., L. Masinter and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738] バーナーズ・リーとT.とL.MasinterとM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[RFC 1778] Howes, T., S. Kille, W. Yeong and C. Robbins, "The String
Representation of Standard Attribute Syntaxes," RFC 1778,
March 1995.
[RFC1778] ハウズとT.とS.KilleとW.Yeongと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 2044] F. Yergeau, F., "UTF-8, a transformation format of
Unicode and ISO 10646", RFC 2044, October 1996.
[RFC2044] F.Yergeau、1996年10月のF.、「UTF-8、ユニコードとISO10646の変換形式」RFC2044。
[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., M. Wahl, A. Grimstad, R. Huber 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 2252] Wahl, M., A. Coulbeck, T. Howes and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
[RFC2252] ウォール、M.、A.Coulbeck、T.ハウズ、およびS.Kille、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「属性構文定義」、RFC2252、1997年12月。
[RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、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 2459] Housley, R., W. Ford, W. Polk and D. Solo, "Internet
X.509 Public Key Infrastructure: Certificate and CRL
Profile", RFC 2459, January 1999.
[RFC2459] Housley、R.、W.フォード、W.ポーク、およびD.が独奏される、「インターネットX.509公開鍵基盤:」 「証明書とCRLプロフィール」、RFC2459、1月1999日
[RFC 2560] Myers, M., R. Ankney, A. Malpani, S. Galperin and C.
Adams, "Online Certificate Status Protocal - OCSP", June
1999.
[RFC2560] マイアーズ、M.、R.Ankney、A.Malpani、S.ガリペリン、およびC.アダムス、「オンライン証明書状態Protocal--、OCSP、」、6月1999日
[SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A,
1997-02-06.
[SDN.701] SDN.701、「メッセージセキュリティは1997年2月6日に4インチ、改正Aについて議定書の中で述べます」。
Housley, et. al. Standards Track [Page 87] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[87ページ]。
[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を選択しました。
[X.660] ITU-T Recommendation X.660 Information Technology - ASN.1
encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER), 1997.
[X.660]ITU-T Recommendation X.660情報Technology--ASN.1符号化規則: 基本的な符号化規則(BER)、正準な符号化規則(CER)、および顕著なコード化の仕様は(DER)、1997を統治します。
[X.690] ITU-T Recommendation X.690 Information Technology - Open
Systems Interconnection - Procedures for the operation of
OSI Registration Authorities: General procedures, 1992.
[X.690]ITU-T Recommendation X.690情報Technology--オープン・システム・インターコネクション--OSI Registration Authoritiesの操作のための手順: 基本手順、1992。
[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日の公開鍵証明書と証明書失効リストへの拡大。
[PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
Lists (CRL) Profile", RFC 3279, April 2002.
[PKIXALGS]Bassham、L.、ポーク、W.、およびR.Housley、「インターネットX.509公開鍵暗号基盤のためのアルゴリズムと識別子は、リスト(CRL)が輪郭を描く取消しを証明して、証明します」、RFC3279、2002年4月。
[PKIXTSA] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, August 2001.
[PKIXTSA] アダムスとC.とカインとP.とピンカスとD.とR.Zuccherato、「インターネットX.509公開鍵暗号基盤タイムスタンププロトコル(ティースプーンフル)」、RFC3161、2001年8月。
8 Intellectual Property Rights
8 知的所有権
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 (see http://www.ietf.org/ipr.html).
IETFは本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください( http://www.ietf.org/ipr.html を見てください)。
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
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 そして標準化過程の権利に関するIETFの手順に関する情報。
Housley, et. al. Standards Track [Page 88] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[88ページ]。
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 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.
BCP11で規格関連のドキュメンテーションを見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
9 Security Considerations
9 セキュリティ問題
The majority of this specification is devoted to the format and content of certificates and CRLs. Since certificates and CRLs are digitally signed, no additional integrity service is necessary. Neither certificates nor CRLs need be kept secret, and unrestricted and anonymous access to certificates and CRLs has no security implications.
この仕様の大部分が証明書とCRLsの形式と内容に専念します。 証明書とCRLsがデジタルに署名されるので、どんな追加保全サービスも必要ではありません。 証明書もCRLsも秘密にされる必要はありません、そして、証明書とCRLsへの無制限で匿名のアクセスには、セキュリティ意味が全くありません。
However, security factors outside the scope of this specification will affect the assurance provided to certificate users. This section highlights critical issues to be considered by implementers, administrators, and users.
しかしながら、この仕様の範囲の外のセキュリティ要素はユーザを証明するために提供された保証に影響するでしょう。 implementers、管理者、およびユーザによって考えられるように、このセクションは重要な問題を強調します。
The procedures performed by CAs and RAs to validate the binding of the subject's identity to their public key greatly affect the assurance that ought to be placed in the certificate. Relying parties might wish to review the CA's certificate practice statement. This is 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 security factor. On a small scale, failure of users to protect their private keys will permit an attacker to masquerade as them, or decrypt their personal information. On a larger scale, compromise of a CA's private signing key may have a catastrophic effect. If an attacker obtains the private key unnoticed, the attacker may issue bogus certificates and CRLs. Existence of bogus certificates and CRLs will undermine confidence in the system. If such a compromise is detected, all certificates issued to the compromised CA MUST be revoked, preventing
秘密鍵が提供された保護はきわどいセキュリティ要素です。 小規模に、攻撃者がそれらのふりをすることを許可するか、またはユーザが彼らの秘密鍵を保護しないと、それらの個人情報を解読するでしょう。 より大きいスケールでは、CAの個人的な署名キーの感染は壊滅的な効果を持っているかもしれません。 攻撃者が目だたない状態で秘密鍵を得るなら、攻撃者はにせの証明書とCRLsを発行するかもしれません。 にせの証明書とCRLsの存在はシステムにおける信用を損ねるでしょう。 そのような感染が検出されるなら、防いで、感染しているカリフォルニアに発行されたすべての証明書を取り消さなければなりません。
Housley, et. al. Standards Track [Page 89] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[89ページ]。
services between its users and users of other CAs. Rebuilding after such a compromise will be problematic, so CAs are advised to implement a combination of strong technical measures (e.g., tamper- resistant cryptographic modules) and appropriate management procedures (e.g., separation of duties) to avoid such an incident.
他のCAsのユーザとユーザの間のサービス。 そのような感染が問題が多くなった後に再建によって、CAsがそのようなインシデントを避けるために強い技術的な程度(例えば、耐タンパーの暗号のモジュール)と適切な管理手順(例えば、義務の分離)の組み合わせを実装するようにアドバイスされます。
Loss of a CA's private signing key may also be problematic. The CA would not be able to produce CRLs or perform normal key rollover. CAs SHOULD maintain secure backup for signing keys. The security of the key backup procedures is a critical factor in avoiding key compromise.
また、CAの個人的な署名キーの損失も問題が多いかもしれません。 カリフォルニアは、CRLsを生産できませんし、正常な主要なロールオーバーを実行できないでしょう。CAs SHOULDは署名キーのために安全なバックアップを維持します。 主要なバックアップ手順のセキュリティは主要な感染を避けることにおいて重要な要素です。
The availability and freshness of revocation information affects the degree of assurance that ought to be placed in a certificate. While certificates expire naturally, events may occur during its natural lifetime 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. Relying parties might not be able to process every critical extension that can appear in a CRL. CAs SHOULD take extra care when making revocation information available only through CRLs that contain critical extensions, particularly if support for those extensions is not mandated by this profile. For example, if revocation information is supplied using a combination of delta CRLs and full CRLs, and the delta CRLs are issued more frequently than the full CRLs, then relying parties that cannot handle the critical extensions related to delta CRL processing will not be able to obtain the most recent revocation information. Alternatively, if a full CRL is issued whenever a delta CRL is issued, then timely revocation information will be available to all relying parties. Similarly, implementations of the certification path validation mechanism described in section 6 that omit revocation checking provide less assurance than those that support it.
取消し情報の有用性と新しさは証明書に置かれるべきである保証の度合いに影響します。 証明書は自然に期限が切れますが、イベントは生まれながらの生涯起こるかもしれません(対象と公開鍵の間の結合を否定します)。 取消し情報がタイミングが悪いか、または入手できないなら、結合に関連している保証は明確に抑えられます。 信用パーティーはCRLに現れることができるあらゆる重要な拡大を処理できるかもしれないというわけではありません。 取消し情報を重要な拡大を含むCRLsだけを通して利用可能にするとき、CAs SHOULDは付加的な注意を払います、特にそれらの拡大のサポートがこのプロフィールによって強制されないなら。 例えば、デルタCRLsと完全なCRLsの組み合わせを使用することで取消し情報を提供して、完全なCRLsより頻繁にデルタCRLsを発行すると、デルタCRL処理に関連する重要な拡大を扱うことができない信用パーティーは最新の取消し情報を得ることができないでしょう。 あるいはまた、CRLデルタが発行されるときはいつも、完全なCRLが発行されると、タイムリーな取消し情報は当てにしているパーティーに皆、利用可能になるでしょう。 同様に、取消しの照合を省略するセクション6で説明された証明経路合法化メカニズムの実装はそれをサポートするものより少ない保証を提供します。
The certification path validation algorithm depends on the certain knowledge of the public keys (and other information) about one or more trusted CAs. The decision to trust a CA is an important decision as it ultimately determines the trust afforded a certificate. The authenticated distribution of trusted CA public keys (usually in the form of a "self-signed" certificate) is a security critical out-of-band process that is beyond the scope of this specification.
証明経路合法化アルゴリズムは公開鍵(そして、他の情報)のおよそ1かさらに信じられたCAsに関する、ある知識によります。 結局証明書が提供された信頼を決定するとき、カリフォルニアを信じるという決定は重要な決定です。 信じられたカリフォルニア公開鍵(通常、「自己によって署名している」証明書の形の)の認証された分配はこの仕様の範囲にあるセキュリティの重要なバンドで出ているプロセスです。
In addition, where a key compromise or CA failure occurs for a trusted CA, the user will need to modify the information provided to the path validation routine. Selection of too many trusted CAs makes
さらに、主要な感染かカリフォルニアの失敗が信じられたカリフォルニアに起こるところでは、ユーザは、経路合法化ルーチンに提供された情報を変更する必要があるでしょう。 多く過ぎることの選択は、CAsが作ると信じました。
Housley, et. al. Standards Track [Page 90] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[90ページ]。
the trusted CA information difficult to maintain. On the other hand, selection of only one trusted CA could limit users to a closed community of users.
維持するのが難しい信じられたカリフォルニア情報。 他方では、1だけの信じられたカリフォルニアの選択はユーザをユーザの閉じている共同体に制限するかもしれません。
The quality of implementations that process certificates also affects the degree of assurance provided. The path validation algorithm described in section 6 relies upon the integrity of the trusted CA information, and especially the integrity of the public keys associated with the trusted CAs. By substituting public keys for which an attacker has the private key, an attacker could trick the user into accepting false certificates.
また、証明書を処理する実装の品質は提供された保証の度合いに影響します。 セクション6で説明された経路合法化アルゴリズムは信じられたカリフォルニア情報の保全、および特に信じられたCAsに関連している公開鍵の保全を当てにします。 攻撃者が秘密鍵を持っている公開鍵を代入することによって、攻撃者は、ユーザが偽の証明書を受け入れるようにだますことができるでしょう。
The binding between a key and certificate subject cannot be stronger than the cryptographic module implementation and algorithms used to generate the signature. Short key lengths or weak hash algorithms will limit the utility of a certificate. CAs are encouraged to note advances in cryptology so they can employ strong cryptographic techniques. In addition, CAs SHOULD decline to issue certificates to CAs or end entities that generate weak signatures.
キーと証明書対象の間の結合は暗号のモジュール実装とアルゴリズムが以前はよく署名を生成していたより強いはずがありません。 短いキー長か弱いハッシュアルゴリズムが証明書に関するユーティリティを制限するでしょう。 CAsが強い暗号のテクニックを使うことができるように暗号理論における進歩に注意するよう奨励されます。 さらに、CAs SHOULDは、弱い署名を生成するCAsか終わりの実体に証明書を発行するのを断ります。
Inconsistent application of name comparison rules can result in acceptance of invalid X.509 certification paths, or rejection of valid ones. The X.500 series of specifications defines rules for comparing distinguished names that require comparison of strings without regard 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 MUST encode the distinguished name in the subject field of a CA certificate identically to the distinguished name in the issuer field in certificates issued by that CA. If CAs use different encodings, implementations might fail to recognize name chains for paths that include this certificate. As a consequence, valid paths could be rejected.
CAsは同様にカリフォルニア証明書の対象の分野でそのカリフォルニアによって発行された証明書の発行人分野の分類名に分類名をコード化しなければなりません。 CAsが異なったencodingsを使用するなら、実装はこの証明書を含んでいる経路として名前チェーンを認識しないかもしれません。 結果として、有効な経路を拒絶できました。
In addition, name constraints for distinguished names MUST be stated identically to the encoding used in the subject field or subjectAltName extension. If not, then name constraints stated as excludedSubTrees will not match and invalid paths will be accepted and name constraints expressed as permittedSubtrees will not match and valid paths will be rejected. To avoid acceptance of invalid paths, CAs SHOULD state name constraints for distinguished names as permittedSubtrees wherever possible.
さらに、同様に対象の分野かsubjectAltName拡張子に使用されるコード化に分類名の名前規制を述べなければなりません。 そうでなければ、次に、excludedSubTreesが合わないので述べられた名前規制と無効の経路を受け入れるでしょう、そして、permittedSubtreesが合わないので言い表された名前規制と有効な経路を拒絶するでしょう。 無効の経路の承認を避けるために、CAs SHOULDはpermittedSubtreesとしてどこでも、可能であるところに分類名の名前規制を述べます。
Housley, et. al. Standards Track [Page 91] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[91ページ]。
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 definitions for the UNIVERSAL Types with the 1988 catch-all "ANY".
この付録は、「少しも」UNIVERSAL Typesのための定義を1988年のキャッチにすべて、取り替えることによって、1988ASN.1に変換されるかもしれません。
A.1 Explicitly Tagged Module, 1988 Syntax
A.1は明らかにモジュール、1988年の構文にタグ付けをしました。
PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) }
PKIX1Explicit88iso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1明白な(18)
DEFINITIONS EXPLICIT TAGS ::=
定義、明白なタグ:、:=
BEGIN
始まってください。
-- EXPORTS ALL --
-- すべてを輸出します--
-- IMPORTS NONE --
-- なにも輸入しません--
-- UNIVERSAL Types defined in 1993 and 1998 ASN.1 -- and required by this specification
-- UNIVERSAL Typesは1993年と1998年にASN.1を定義しました--そして、この仕様が必要です。
UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
-- UniversalString is defined in ASN.1:1993
UniversalString:、:= [UNIVERSAL28]IMPLICIT OCTET STRING--UniversalStringは1993年にASN.1:定義されます。
BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
-- BMPString is the subtype of UniversalString and models
-- the Basic Multilingual Plane of ISO/IEC/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)
security(5) mechanisms(5) pkix(7) }
イド-pkix OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)
Housley, et. al. Standards Track [Page 92] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[92ページ]。
-- PKIX arcs
-- PKIXアーク
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
-- arc for private certificate extensions
id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
-- arc for policy qualifier types
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
-- arc for extended key purpose OIDS
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
-- arc for access descriptors
イド-pe OBJECT IDENTIFIER:、:= イド-pkix1--兵卒のためのアークは拡大イド-qt OBJECT IDENTIFIERを証明します:、:= イド-pkix2--方針資格を与える人のためのアークはイド-kp OBJECT IDENTIFIERをタイプします:、:= イド-pkix3--拡張キーのためのアークはOIDSイド広告OBJECT IDENTIFIERを目標とします:、:= イド-pkix48--アクセス記述子のためのアーク
-- policyQualifierIds for Internet policy qualifiers
-- インターネット方針資格を与える人のためのpolicyQualifierIds
id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 }
-- OID for CPS qualifier
id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 }
-- OID for user notice qualifier
イド-qt-cps OBJECT IDENTIFIER:、:= イド-qt1--、CPS資格を与える人イド-qt-unotice OBJECT IDENTIFIERのためのOID:、:= イド-qt2--ユーザ通知資格を与える人のためのOID
-- access descriptor definitions
-- アクセス記述子定義
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
イド広告ocsp OBJECT IDENTIFIER、:、:= イド広告1、イド広告caIssuers OBJECT IDENTIFIER、:、:= イド広告2、イド広告timeStamping OBJECT IDENTIFIER、:、:= イド広告3、イド広告caRepository OBJECT IDENTIFIER、:、:= イド広告5
-- attribute data types
-- 属性データ型
Attribute ::= SEQUENCE {
type AttributeType,
values SET OF AttributeValue }
-- at least one value is required
以下を結果と考えてください:= SEQUENCEはAttributeType、値のSET OF AttributeValueをタイプします--少なくとも1つの値が必要です。
AttributeType ::= OBJECT IDENTIFIER
AttributeType:、:= 物の識別子
AttributeValue ::= ANY
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
--Arc for standard naming attributes
id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
-- 提案された命名属性: 以下の定義--情報物のセットは地方で会うために増大するかもしれません--要件。 セットのメンバーを削除するのがそうするかもしれないことに注意してください--実現を従わせるのに相互運用性を防いでください。 -- 組で提示される: AttributeTypeが標準の命名属性のために--対応するAttributeValueのための型定義--アークで続いた、イド、-、OBJECT IDENTIFIER:、:= 共同iso-ccitt(2) ds(5)4
Housley, et. al. Standards Track [Page 93] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[93ページ]。
-- Naming attributes of type X520name
-- タイプの属性をX520nameと命名します。
id-at-name AttributeType ::= { id-at 41 }
id-at-surname AttributeType ::= { id-at 4 }
id-at-givenName AttributeType ::= { id-at 42 }
id-at-initials AttributeType ::= { id-at 43 }
id-at-generationQualifier AttributeType ::= { id-at 44 }
名前におけるイドAttributeType:、:= イド、-、41、姓におけるイドAttributeType:、:= イド、-、4、givenName AttributeTypeのイド:、:= イド、-、42、イニシャルにおけるイドAttributeType:、:= イド、-、43、generationQualifier AttributeTypeのイド:、:= イド、-、44
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-名前))
-- Naming attributes of type X520CommonName
-- タイプの属性をX520CommonNameと命名します。
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-一般名))
-- Naming attributes of type X520LocalityName
-- タイプの属性をX520LocalityNameと命名します。
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場所名))
-- Naming attributes of type X520StateOrProvinceName
-- タイプの属性をX520StateOrProvinceNameと命名します。
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 94] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[94ページ]。
-- Naming attributes of type X520OrganizationName
-- タイプの属性をX520OrganizationNameと命名します。
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))
-- Naming attributes of type X520OrganizationalUnitName
-- タイプの属性をX520OrganizationalUnitNameと命名します。
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))
-- Naming attributes of type X520Title
-- タイプの属性をX520Titleと命名します。
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-タイトル))
-- Naming attributes of type X520dnQualifier
-- タイプの属性をX520dnQualifierと命名します。
id-at-dnQualifier AttributeType ::= { id-at 46 }
dnQualifier AttributeTypeのイド:、:= イド、-、46
X520dnQualifier ::= PrintableString
X520dnQualifier:、:= PrintableString
Housley, et. al. Standards Track [Page 95] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[95ページ]。
-- Naming attributes of type X520countryName (digraph from IS 3166)
-- タイプの属性をX520countryNameと命名します。(連字、3166です)。
id-at-countryName AttributeType ::= { id-at 6 }
countryName AttributeTypeのイド:、:= イド、-、6
X520countryName ::= PrintableString (SIZE (2))
X520countryName:、:= PrintableString(サイズ(2))
-- Naming attributes of type X520SerialNumber
-- タイプの属性をX520SerialNumberと命名します。
id-at-serialNumber AttributeType ::= { id-at 5 }
serialNumber AttributeTypeのイド:、:= イド、-、5
X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number))
X520SerialNumber:、:= PrintableString(サイズ(1..ub-通し番号))
-- Naming attributes of type X520Pseudonym
-- タイプの属性をX520Pseudonymと命名します。
id-at-pseudonym AttributeType ::= { id-at 65 }
匿名におけるイドAttributeType:、:= イド、-、65
X520Pseudonym ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-pseudonym)),
printableString PrintableString (SIZE (1..ub-pseudonym)),
universalString UniversalString (SIZE (1..ub-pseudonym)),
utf8String UTF8String (SIZE (1..ub-pseudonym)),
bmpString BMPString (SIZE (1..ub-pseudonym)) }
X520Pseudonym:、:= 選択teletexString TeletexString(サイズ(1..ub-匿名))、printableString PrintableString(サイズ(1..ub-匿名))、universalString UniversalString(サイズ(1..ub-匿名))、utf8String UTF8String(サイズ(1..ub-匿名))、bmpString BMPString(サイズ(1..ub-匿名))
-- Naming attributes of type DomainComponent (from RFC 2247)
-- タイプの属性をDomainComponentと命名します。(RFC2247からの)
id-domainComponent AttributeType ::=
{ 0 9 2342 19200300 100 1 25 }
イド-domainComponent AttributeType:、:= { 0 9 2342 19200300 100 1 25 }
DomainComponent ::= IA5String
DomainComponent:、:= IA5String
-- Legacy attributes
-- 遺産属性
pkcs-9 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 }
pkcs-9 OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1)9をメンバーと同じくらい具体化させます。
id-emailAddress AttributeType ::= { pkcs-9 1 }
イド-emailAddress AttributeType:、:= pkcs-9 1
EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length))
EmailAddress:、:= IA5String(サイズ(1..ub-emailaddress-長さ))
-- naming data types --
-- データ型を命名します--
Name ::= CHOICE { -- only one possibility for now --
rdnSequence RDNSequence }
以下を命名してください:= 選択--当分間の1つの可能性だけ--rdnSequence RDNSequence
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RDNSequence:、:= RelativeDistinguishedNameの系列
DistinguishedName ::= RDNSequence
DistinguishedName:、:= RDNSequence
Housley, et. al. Standards Track [Page 96] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[96ページ]。
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 MUST be v2 or v3
subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version MUST be v2 or v3
extensions [3] Extensions OPTIONAL
-- If present, version MUST be v3 -- }
TBSCertificate:、:= 系列バージョン[0]バージョンDEFAULT v1、serialNumber CertificateSerialNumber、署名AlgorithmIdentifier、発行人Name(正当性Validity)はNameをかけます、subjectPublicKeyInfo SubjectPublicKeyInfo、issuerUniqueID[1]IMPLICIT UniqueIdentifier OPTIONAL(プレゼント、バージョンは、v2かv3 subjectUniqueID[2]IMPLICIT UniqueIdentifier OPTIONALであるに違いありません--存在しているなら、存在しているなら、バージョンがv2かv3拡大[3]拡大OPTIONALであるに違いないなら、バージョンはv3であるに違いありません)
Version ::= INTEGER { v1(0), v2(1), v3(2) }
バージョン:、:= 整数v1(0)、v2(1)、v3(2)
CertificateSerialNumber ::= INTEGER
CertificateSerialNumber:、:= 整数
Validity ::= SEQUENCE {
notBefore Time,
notAfter Time }
正当性:、:= 系列notBefore時間、notAfter時間
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
以下を調節してください:= 選択utcTime UTCTime、generalTime GeneralizedTime
UniqueIdentifier ::= BIT STRING
UniqueIdentifier:、:= ビット列
Housley, et. al. Standards Track [Page 97] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[97ページ]。
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, MUST be v2
signature AlgorithmIdentifier,
issuer Name,
thisUpdate Time,
nextUpdate Time OPTIONAL,
revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate Time,
crlEntryExtensions Extensions OPTIONAL
-- if present, MUST be v2
} OPTIONAL,
crlExtensions [0] Extensions OPTIONAL }
-- if present, MUST be v2
TBSCertList:、:= SEQUENCE、バージョンバージョンOPTIONAL--、発行人v2署名がAlgorithmIdentifierであったに違いないならNameを寄贈してください、thisUpdate Time、nextUpdate Time OPTIONAL、revokedCertificates SEQUENCE OF SEQUENCE、userCertificate CertificateSerialNumber、revocationDate Time、crlEntryExtensions Extensions OPTIONAL--存在している、v2でなければならない、OPTIONAL、crlExtensions[0]拡大OPTIONAL、プレゼントはv2であるに違いありません。
-- Version, Time, CertificateSerialNumber, and Extensions were -- defined earlier for use in the certificate structure
-- バージョン、Time、CertificateSerialNumber、およびExtensionsはそうでした--証明書構造の使用のために、より早く定義されます。
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
-- contains a value of the type
-- registered for use with the
-- algorithm object identifier value
AlgorithmIdentifier:、:= SEQUENCE、アルゴリズムOBJECT IDENTIFIER、パラメタANY DEFINED BYアルゴリズムOPTIONAL--タイプの値を含んでいます--、使用のために登録する、--、アルゴリズム物の識別子価値
-- X.400 address syntax starts here
-- X.400アドレス構文はここから始まります。
Housley, et. al. Standards Track [Page 98] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[98ページ]。
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を見てください。
-- Built-in Standard Attributes
-- 内蔵の標準の属性
BuiltInStandardAttributes ::= SEQUENCE {
country-name CountryName OPTIONAL,
administration-domain-name AdministrationDomainName OPTIONAL,
network-address [0] IMPLICIT NetworkAddress OPTIONAL,
-- see also extended-network-address
terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL,
private-domain-name [2] PrivateDomainName OPTIONAL,
organization-name [3] IMPLICIT OrganizationName OPTIONAL,
-- see also teletex-organization-name
numeric-user-identifier [4] IMPLICIT NumericUserIdentifier
OPTIONAL,
personal-name [5] IMPLICIT PersonalName OPTIONAL,
-- see also teletex-personal-name
organizational-unit-names [6] IMPLICIT OrganizationalUnitNames
OPTIONAL }
-- see also teletex-organizational-unit-names
BuiltInStandardAttributes:、:= 系列 { 国名のCountryName OPTIONAL、管理ドメイン名AdministrationDomainName OPTIONAL、ネットワーク・アドレス0IMPLICIT NetworkAddress OPTIONAL--また、端末の識別子1拡張ネットワーク・アドレスIMPLICIT TerminalIdentifier OPTIONAL、個人的なドメイン名2PrivateDomainName OPTIONAL、組織名の3IMPLICIT OrganizationName OPTIONALを見てください; また、テレテックス組織名の数値ユーザ識別子4IMPLICIT NumericUserIdentifier OPTIONALを見てください、個人名5IMPLICIT PersonalName OPTIONAL--また、テレテックス個人名組織的なユニット名の6IMPLICIT OrganizationalUnitNames OPTIONALを見てください; } また、テレテックスの組織的なユニット名を見てください。
CountryName ::= [APPLICATION 1] CHOICE {
x121-dcc-code NumericString
(SIZE (ub-country-name-numeric-length)),
iso-3166-alpha2-code PrintableString
(SIZE (ub-country-name-alpha-length)) }
CountryName:、:= [アプリケーション1] 選択x121-dcc-コードNumericString(SIZE(ubの国の名前の数値長さ))、iso-3166-alpha2-コードPrintableString(SIZE(ub国の名前アルファの長さ))
AdministrationDomainName ::= [APPLICATION 2] CHOICE {
numeric NumericString (SIZE (0..ub-domain-name-length)),
printable PrintableString (SIZE (0..ub-domain-name-length)) }
AdministrationDomainName:、:= [アプリケーション2] 選択数値NumericString(SIZE(0..ubドメイン名前の長さ))、印刷可能なPrintableString(SIZE(0..ubドメイン名前の長さ))
NetworkAddress ::= X121Address -- see also extended-network-address
NetworkAddress:、:= X121Address--また、拡張ネットワーク・アドレスを見てください。
X121Address ::= NumericString (SIZE (1..ub-x121-address-length))
X121Address:、:= NumericString(サイズ(1..ub-x121アドレスの長さ))
TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length))
TerminalIdentifier:、:= PrintableString(サイズ(1..ubの端末のイドの長さ))
PrivateDomainName ::= CHOICE {
numeric NumericString (SIZE (1..ub-domain-name-length)),
printable PrintableString (SIZE (1..ub-domain-name-length)) }
PrivateDomainName:、:= 選択数値NumericString(SIZE(1..ubドメイン名前の長さ))、印刷可能なPrintableString(SIZE(1..ubドメイン名前の長さ))
Housley, et. al. Standards Track [Page 99] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[99ページ]。
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] IMPLICIT PrintableString
(SIZE (1..ub-surname-length)),
given-name [1] IMPLICIT PrintableString
(SIZE (1..ub-given-name-length)) OPTIONAL,
initials [2] IMPLICIT PrintableString
(SIZE (1..ub-initials-length)) OPTIONAL,
generation-qualifier [3] IMPLICIT PrintableString
(SIZE (1..ub-generation-qualifier-length))
OPTIONAL }
-- see also teletex-personal-name
PersonalName:、:= SET、姓[0]IMPLICIT PrintableString(SIZE(1..ub姓の長さ))(名[1]IMPLICIT PrintableString(SIZE(1..ub当然のことの名前の長さ))OPTIONAL)は[2] IMPLICIT PrintableString(SIZE(1..ubは長さに頭文字をつける))OPTIONALに頭文字をつけます、世代資格を与える人[3]IMPLICIT PrintableString(SIZE(1..ub世代資格を与える人の長さ))OPTIONAL--また、テレテックス個人名を見てください。
OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units)
OF OrganizationalUnitName
-- see also teletex-organizational-unit-names
OrganizationalUnitNames:、:= SEQUENCE SIZE(1..ubの組織的なユニット)OF OrganizationalUnitName--また、テレテックスの組織的なユニット名を見てください。
OrganizationalUnitName ::= PrintableString (SIZE
(1..ub-organizational-unit-name-length))
OrganizationalUnitName:、:= PrintableString(サイズ(1..ubの組織的なユニットは長さを命名します))
-- Built-in Domain-defined Attributes
-- 内蔵のドメインで定義された属性
BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE
(1..ub-domain-defined-attributes) OF
BuiltInDomainDefinedAttribute
BuiltInDomainDefinedAttributes:、:= BuiltInDomainDefinedAttributeの系列サイズ(1..ubドメインは属性を定義しました)
BuiltInDomainDefinedAttribute ::= SEQUENCE {
type PrintableString (SIZE
(1..ub-domain-defined-attribute-type-length)),
value PrintableString (SIZE
(1..ub-domain-defined-attribute-value-length)) }
BuiltInDomainDefinedAttribute:、:= 系列PrintableString(SIZE(1..ubドメインは属性タイプの長さを定義した))、値のPrintableString(SIZE(1..ubドメインは属性値の長さを定義した))をタイプしてください。
-- Extension Attributes
-- 拡大属性
ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF
ExtensionAttribute
ExtensionAttributes:、:= ExtensionAttributeのサイズ(1..ub拡大属性)を設定してください。
ExtensionAttribute ::= SEQUENCE {
extension-attribute-type [0] IMPLICIT INTEGER
(0..ub-extension-attributes),
extension-attribute-value [1]
ANY DEFINED BY extension-attribute-type }
ExtensionAttribute:、:= 系列拡大属性タイプ[0]IMPLICIT INTEGER(0..ub拡大属性)、拡大属性値[1]ANY DEFINED BY拡大属性タイプ
Housley, et. al. Standards Track [Page 100] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[100ページ]。
-- 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] IMPLICIT TeletexString
(SIZE (1..ub-surname-length)),
given-name [1] IMPLICIT TeletexString
(SIZE (1..ub-given-name-length)) OPTIONAL,
initials [2] IMPLICIT TeletexString
(SIZE (1..ub-initials-length)) OPTIONAL,
generation-qualifier [3] IMPLICIT TeletexString
(SIZE (1..ub-generation-qualifier-length))
OPTIONAL }
TeletexPersonalName:、:= セットします。姓[0]IMPLICIT TeletexString(SIZE(1..ub姓の長さ))(名[1]IMPLICIT TeletexString(SIZE(名前の長さが与えられた1..ub))OPTIONAL)は[2] IMPLICIT TeletexString(SIZE(1..ubは長さに頭文字をつける))OPTIONALに頭文字をつけます、世代資格を与える人[3]IMPLICIT 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国の名前アルファの長さ))
Housley, et. al. Standards Track [Page 101] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[101ページ]。
postal-code INTEGER ::= 9
郵便番号INTEGER:、:= 9
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 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
Housley, et. al. Standards Track [Page 102] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[102ページ]。
PosteRestanteAddress ::= PDSParameter
PosteRestanteAddress:、:= PDSParameter
unique-postal-name INTEGER ::= 20
ユニークな郵便の名前INTEGER:、:= 20
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] IMPLICIT NumericString
(SIZE (1..ub-e163-4-number-length)),
sub-address [1] IMPLICIT NumericString
(SIZE (1..ub-e163-4-sub-address-length))
OPTIONAL },
psap-address [0] IMPLICIT PresentationAddress }
ExtendedNetworkAddress:、:= 選択e163 4アドレスSEQUENCE数[0]IMPLICIT NumericString(SIZE(1..ub-e163 4数の長さ))の、そして、サブアドレスの[1]IMPLICIT NumericString(SIZE(1..ub-e163の4のサブアドレスの長さ))OPTIONAL、psap-アドレス[0]IMPLICIT 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
Housley, et. al. Standards Track [Page 103] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[103ページ]。
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
(SIZE (1..ub-domain-defined-attribute-value-length)) }
TeletexDomainDefinedAttribute:、:= 系列TeletexString(SIZE(1..ubドメインは属性タイプの長さを定義した))、値のTeletexString(SIZE(1..ubドメインは属性値の長さを定義した))をタイプしてください。
-- specifications of Upper Bounds MUST 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-serial-number INTEGER ::= 64 ub-match INTEGER ::= 128 ub-emailaddress-length 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-pseudonym INTEGER ::= 128 ub-surname-length INTEGER ::= 40
-- 上側のBounds ub-名前INTEGER:、:= 32768 ub-一般名INTEGER:、:= 64 ub場所名のINTEGER:、:= 128 ub州の名のINTEGER:、:= 128 ub組織名のINTEGER:、:= 64 組織的なユニットが命名するub INTEGER:、:= 64 ub-タイトルINTEGER:、:= 64 ub-通し番号INTEGER:、:= 64 ub-マッチINTEGER:、:= 128 ub-emailaddress-長さのINTEGER:、:= 128 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:、:= 128 ub姓の長さのINTEGER:、:= 40
Housley, et. al. Standards Track [Page 104] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[104ページ]。
ub-terminal-id-length INTEGER ::= 24 ub-unformatted-address-length INTEGER ::= 180 ub-x121-address-length INTEGER ::= 16
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 -- 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.
-- 注意--TeletexStringなどのストリングタイプの上の上限があります--キャラクタでは、測定されます。 PrintableStringかIA5String、aを除きます--かなり大きい数の八重奏が成立するのに必要でしょう--そのような値。 最小限、16の八重奏、または指定の2倍--より大きいです、考慮されるべきであるということである上限--TeletexStringとして。 少なくとも4のUTF8StringかUniversalString--回上限が許容されるべきである。
END
終わり
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(19) }
PKIX1Implicit88iso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1暗黙の(19)
DEFINITIONS IMPLICIT TAGS ::=
定義、内在しているタグ:、:=
BEGIN
始まってください。
-- EXPORTS ALL --
-- すべてを輸出します--
IMPORTS
id-pe, id-kp, id-qt-unotice, id-qt-cps,
-- delete following line if "new" types are supported --
BMPString, UTF8String, -- end "new" types --
ORAddress, Name, RelativeDistinguishedName,
CertificateSerialNumber, 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(18) };
IMPORTSイド-pe、イド-kp、イド-qt-unotice、イド-qt-cps--「新しい」タイプが支持されるなら、線に従います--BMPString、UTF8String--「新しい」タイプを終わらせます--ORAddress、Nameを削除してください、RelativeDistinguishedName、CertificateSerialNumber、Attribute、DirectoryString FROM PKIX1Explicit88のiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1明白な(18)。
-- 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
Housley, et. al. Standards Track [Page 105] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[105ページ]。
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNames OPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
-- authorityCertIssuer and authorityCertSerialNumber MUST 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
-- 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 MUST 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
anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }
anyPolicy物の識別子:、:= イドCe certificatePolicies、0
CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
CertificatePolicies:、:= PolicyInformationの系列サイズ(1..MAX)
PolicyInformation ::= SEQUENCE {
PolicyInformation:、:= 系列
Housley, et. al. Standards Track [Page 106] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[106ページ]。
policyIdentifier CertPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL }
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 MUST -- 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ポインタ資格を与える人
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 {
ia5String IA5String (SIZE (1..200)),
visibleString VisibleString (SIZE (1..200)),
bmpString BMPString (SIZE (1..200)),
utf8String UTF8String (SIZE (1..200)) }
DisplayText:、:= 選択ia5String IA5String(サイズ(1 .200))、visibleString VisibleString(サイズ(1 .200))、bmpString BMPString(サイズ(1 .200))、utf8String UTF8String(サイズ(1 .200))
-- 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
Housley, et. al. Standards Track [Page 107] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[107ページ]。
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 {
type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id }
AnotherName:、:= 系列タイプイド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
Housley, et. al. Standards Track [Page 108] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[108ページ]。
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,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
PolicyConstraints:、:= 系列requireExplicitPolicy[0]SkipCerts任意であって、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
CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
CRLDistributionPoints:、:= DistributionPointの系列サイズ(1..MAX)
DistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
reasons [1] ReasonFlags OPTIONAL,
cRLIssuer [2] GeneralNames OPTIONAL }
DistributionPoint:、:= 系列distributionPoint[0]DistributionPointName OPTIONAL、理由[1]ReasonFlags OPTIONAL、cRLIssuer[2]GeneralNames OPTIONAL
DistributionPointName ::= CHOICE {
fullName [0] GeneralNames,
nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
DistributionPointName:、:= 選択fullName[0]GeneralNames、nameRelativeToCRLIssuer[1]RelativeDistinguishedName
ReasonFlags ::= BIT STRING {
unused (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
privilegeWithdrawn (7),
aACompromise (8) }
ReasonFlags:、:= ビット列未使用の(0)(keyCompromise(1)、cACompromise(2)、affiliationChanged(3))は(4)、cessationOfOperation(5)、certificateHold(6)、privilegeWithdrawn(7)、aACompromise(8)に取って代わりました。
Housley, et. al. Standards Track [Page 109] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[109ページ]。
-- 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:、:= 物の識別子
-- permit unspecified key uses
-- 不特定の主要な用途を可能にしてください。
anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
anyExtendedKeyUsage物の識別子:、:= イドCe extKeyUsage、0
-- extended key purpose OIDs
-- 敷衍された主要な目的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-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
イド-kp-serverAuth物の識別子:、:= イド-kp1、イド-kp-clientAuth OBJECT IDENTIFIER:、:= イド-kp2、イド-kp-codeSigning OBJECT IDENTIFIER:、:= イド-kp3、イド-kp-emailProtection OBJECT IDENTIFIER:、:= イド-kp4、イド-kp-timeStamping OBJECT IDENTIFIER:、:= イド-kp8、イド-kp-OCSPSigning OBJECT IDENTIFIER:、:= イド-kp9
-- inhibit any policy OID and syntax
-- どんな方針OIDと構文も禁止してください。
id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }
イドCe inhibitAnyPolicy、物の識別子:、:= イドCe54
InhibitAnyPolicy ::= SkipCerts
InhibitAnyPolicy:、:= SkipCerts
-- freshest (delta)CRL extension OID and syntax
-- 最も新鮮な(デルタ)CRL拡張子OIDと構文
id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
イドCe freshestCRL、物の識別子:、:= イドCe46
FreshestCRL ::= CRLDistributionPoints
FreshestCRL:、:= CRLDistributionPoints
-- authority info access
-- 権威インフォメーションアクセス
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
-- subject info access
-- 対象のインフォメーションアクセス
id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
イド-pe-subjectInfoAccess物の識別子:、:= イド-pe11
Housley, et. al. Standards Track [Page 110] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[110ページ]。
SubjectInfoAccessSyntax ::=
SEQUENCE SIZE (1..MAX) OF AccessDescription
SubjectInfoAccessSyntax:、:= AccessDescriptionの系列サイズ(1..MAX)
-- 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,
onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
IssuingDistributionPoint:、:= 系列distributionPoint[0]DistributionPointName任意です、誤ったonlyContainsUserCertsのデフォルト誤って、[2]のブールデフォルト誤って、onlySomeReasons[3]ReasonFlags任意のonlyContainsCACerts indirectCRL[4]ブールのデフォルトonlyContainsAttributeCerts[5][1]論理演算子論理演算子は虚偽でデフォルトとします。
id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
イドCe deltaCRLIndicator、物の識別子:、:= イドCe27
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),
privilegeWithdrawn (9),
aACompromise (10) }
CRLReason:、:= 列挙されます。不特定の(0)、keyCompromise(1)、cACompromise(2)(affiliationChanged(3))は(4)に取って代わりました、cessationOfOperation(5)、certificateHold(6)、removeFromCRL(8)、privilegeWithdrawn(9)、aACompromise(10)
-- certificate issuer CRL entry extension OID and syntax
-- 証明書発行人CRLエントリー拡張子OIDと構文
id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
イドCe certificateIssuer、物の識別子:、:= イドCe29
CertificateIssuer ::= GeneralNames
CertificateIssuer:、:= GeneralNames
-- hold instruction extension OID and syntax
-- 指示拡大OIDと構文を保持してください。
Housley, et. al. Standards Track [Page 111] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[111ページ]。
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
-- ANSI x9アークholdinstructionアーク
holdInstruction OBJECT IDENTIFIER ::=
{joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2}
holdInstruction物の識別子:、:= 共同iso-itu t(2)は(2) 私たち(840)x9cm(10040)2をメンバーと同じくらい具体化させます。
-- ANSI X9 holdinstructions referenced by this standard
-- この規格によって参照をつけられるANSI X9 holdinstructions
id-holdinstruction-none OBJECT IDENTIFIER ::=
{holdInstruction 1} -- deprecated
イドholdinstruction、なにも、OBJECT IDENTIFIER:、:= holdInstruction1--非難されます。
id-holdinstruction-callissuer OBJECT IDENTIFIER ::=
{holdInstruction 2}
イド-holdinstruction-callissuer OBJECT IDENTIFIER:、:= holdInstruction2
id-holdinstruction-reject OBJECT IDENTIFIER ::=
{holdInstruction 3}
イド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
終わり
Appendix B. ASN.1 Notes
ASN.1が注意する付録B.
CAs MUST force the serialNumber to be a non-negative integer, that is, the sign bit in the DER encoding of the INTEGER value MUST be zero - this can be done by adding a leading (leftmost) `00'H octet if necessary. This removes a potential ambiguity in mapping between a string of octets and an integer value.
すなわち、INTEGER価値のDERコード化における符号ビットはゼロであるに違いありません--CAsは、serialNumberが非負の整数であることを強制しなければならなくて、これは、必要なら、主である(一番左)'H'00八重奏を加えることによって、終わることができます。 これは一連の八重奏と整数値の間にマッピングの潜在的あいまいさを移します。
As noted in section 4.1.2.2, serial numbers can be expected to contain long integers. Certificate users MUST be able to handle serialNumber values up to 20 octets in length. Conformant CAs MUST NOT use serialNumber values longer than 20 octets.
セクション4.1.2で.2、通し番号が長整数型を含むと予想できることに注意するので。 証明書ユーザはserialNumber値を長さにおける20の八重奏まで扱うことができなければなりません。 Conformant CAsは20の八重奏より長い間、serialNumber値を使用してはいけません。
As noted in section 5.2.3, CRL numbers can be expected to contain long integers. CRL validators MUST be able to handle cRLNumber values up to 20 octets in length. Conformant CRL issuers MUST NOT use cRLNumber values longer than 20 octets.
セクション5.2.3で有名であることで、CRL番号が長整数型を含むと予想できます。 CRL validatorsはcRLNumber値を長さにおける20の八重奏まで扱うことができなければなりません。 Conformant CRL発行人は20の八重奏より長い間、cRLNumber値を使用してはいけません。
Housley, et. al. Standards Track [Page 112] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[112ページ]。
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'、'Z'を通した大文字アルファベット'A'、'9'、11の特殊文字を通したケタ'0''=+を通した小文字手紙'a'--. /:、' ? そして、スペース。
Implementers should note that the at sign ('@') and underscore ('_')
characters are not supported by the ASN.1 type PrintableString.
These characters often appear in internet addresses. Such addresses
MUST be encoded using an ASN.1 type that supports them. They are
usually encoded as IA5String in either the emailAddress attribute
within a distinguished name or the rfc822Name field of GeneralName.
Conforming implementations MUST NOT encode strings which include
either the at sign or underscore character as PrintableString.
Implementersがそれに注意するはずである、サイン('@')と強調('_')では、キャラクタはASN.1タイプPrintableStringによって支持されません。 これらのキャラクタはインターネットアドレスにしばしば載っています。 それらを支持するASN.1タイプを使用して、そのようなアドレスをコード化しなければなりません。 通常、それらはIA5Stringとして分類名の中のemailAddress属性かGeneralNameのrfc822Name分野のどちらかでコード化されます。 実現を従わせるとどちらかを含んでいるストリングがコード化されてはいけない、PrintableStringとしてのサインか強調キャラクタで。
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は好きです)かなり標準のラテン語の文字の組、ラテン語のキャラクタを支持します。
Named bit lists are BIT STRINGs where the values have been assigned names. This specification makes use of named bit lists in the definitions for the key usage, CRL distribution points and freshest CRL certificate extensions, as well as the freshest CRL and issuing distribution point CRL extensions. When DER encoding a named bit list, trailing zeroes MUST be omitted. That is, the encoded value ends with the last named bit that is set to one.
噛み付いているリストと命名されているのは、名前が値に割り当てられたBIT STRINGsです。 この仕様は最も新鮮なCRLと分配ポイントCRL拡張子を発行することと同様に主要な用法、CRL分配ポイント、および最も新鮮なCRL証明書拡張子のための定義で命名されたビットの使用をリストにします。 命名されたビットをコード化するDERが記載するとき、末尾のゼロを省略しなければなりません。 すなわち、コード化された値は1つに設定される最後に命名されたビットで終わります。
The character string type UniversalString supports any of the characters allowed by ISO 10646-1 [ISO 10646]. ISO 10646-1 is the Universal multiple-octet coded Character Set (UCS). ISO 10646-1 specifies the architecture and the "basic multilingual plane" -- a large standard character set which includes all major world character standards.
文字列タイプUniversalStringはISO10646-1[ISO10646]によって許容されたキャラクタのいずれも支持します。 ISO10646-1はUniversalの複数の八重奏コード化された文字コード(UCS)です。 ISO10646-1は構造と「基本多言語面」を指定します--すべての主要な世界キャラクタ規格を含んでいる大きい標準文字セット。
Housley, et. al. Standards Track [Page 113] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[113ページ]。
The character string type UTF8String was introduced in the 1997 version of ASN.1, and UTF8String was added to the list of choices for DirectoryString in the 2001 version of X.520 [X.520]. UTF8String is a universal type and has been assigned tag number 12. The content of UTF8String was defined by RFC 2044 [RFC 2044] and updated in RFC 2279 [RFC 2279].
1997年のASN.1のバージョンで文字列タイプUTF8Stringを挿入しました、そして、2001年のX.520[X.520]のバージョンのDirectoryStringのために選択のリストにUTF8Stringを追加しました。 UTF8Stringは普遍的なタイプであり、タグNo.12を割り当ててあります。 UTF8Stringの内容をRFC2044[RFC2044]が定義して、RFC2279[RFC2279]でアップデートしました。
In anticipation of these changes, and in conformance with IETF Best Practices codified in RFC 2277 [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[RFC2277]で成文化されている順応、文字コードのIETF Policy、およびこれらの変化を予測したLanguagesでは、このドキュメントは選択としてDirectoryStringとCPS資格を与える人拡張子でUTF8Stringを含んでいます。
Implementers should note that the DER encoding of the SET OF values requires ordering of the encodings of the values. In particular, this issue arises with respect to distinguished names.
Implementersは、SET OF値のDERコード化が、値のencodingsを注文するのを必要とすることに注意するはずです。 特に、この問題は分類名に関して起こります。
Implementers should note that the DER encoding of SET or SEQUENCE components whose value is the DEFAULT omit the component from the encoded certificate or CRL. For example, a BasicConstraints extension whose cA value is FALSE would omit the cA boolean from the encoded certificate.
Implementersは、値がDEFAULTであるSETかSEQUENCEの部品のDERコード化がコード化された証明書かCRLからコンポーネントを省略することに注意するはずです。 例えば、cA値がFALSEであるBasicConstraints拡張子はコード化された証明書からcA論理演算子を省略するでしょう。
Object Identifiers (OIDs) are used throughout this specification to identify certificate policies, public key and signature algorithms, certificate extensions, etc. There is no maximum size for OIDs. This specification mandates support for OIDs which have arc elements with values that are less than 2^28, that is, they MUST be between 0 and 268,435,455, inclusive. This allows each arc element to be represented within a single 32 bit word. Implementations MUST also support OIDs where the length of the dotted decimal (see [RFC 2252], section 4.1) string representation can be up to 100 bytes (inclusive). Implementations MUST be able to handle OIDs with up to 20 elements (inclusive). CAs SHOULD NOT issue certificates which contain OIDs that exceed these requirements. Likewise, CRL issuers SHOULD NOT issue CRLs which contain OIDs that exceed these requirements.
物のIdentifiers(OIDs)は、証明書方針と公開鍵と署名アルゴリズム、証明書拡張子などを特定するのにこの仕様中で使用されます。 OIDsのための最大サイズが全くありません。 命令が2未満^28である値に従ったアーク要素を持っているOIDsのために支持するこの仕様、すなわち、それらは、0〜2億6843万5455であるに違いありません、包括的です。 これは、それぞれのアーク要素が32ビットのただ一つの単語の中に表されるのを許容します。 また、実現は(包括的)でドット付き10進法([RFC2252]を見てください、セクション4.1)ストリング表現の長さが最大100バイトであるかもしれないOIDsを支持しなければなりません。 最大20の要素が(包括的)で実現はOIDsを扱うことができなければなりません。 CAs SHOULDはこれらの要件を超えているOIDsを含む証明書を発行しません。 同様に、CRL発行人SHOULD NOTはこれらの要件を超えているOIDsを含むCRLsを発行します。
Implementors are warned that the X.500 standards community has developed a series of extensibility rules. These rules determine when an ASN.1 definition can be changed without assigning a new object identifier (OID). For example, at least two extension definitions included in RFC 2459 [RFC 2459], the predecessor to this profile document, have different ASN.1 definitions in this specification, but the same OID is used. If unknown elements appear within an extension, and the extension is not marked critical, those unknown elements ought to be ignored, as follows:
作成者はX.500規格共同体が一連の伸展性規則を開発したのに注意されます。 これらの規則は、いつ新しい物の識別子(OID)を割り当てないでASN.1定義を変えることができるかを決定します。 例えば、RFC2459[RFC2459]に含まれていた少なくとも2つの拡大定義(このプロフィールドキュメントへの前任者)が異なったASN.1定義をこの仕様に持っていますが、同じOIDは使用されています。 未知の要素が拡大の中に現れて、拡大が重要であることはマークされないなら、それらの未知の要素が無視されるべきです、以下の通りです:
(a) ignore all unknown bit name assignments within a bit string;
(a) 課題が中に少し結ぶすべての未知の噛み付いている名前を無視してください。
Housley, et. al. Standards Track [Page 114] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[114ページ]。
(b) ignore all unknown named numbers in an ENUMERATED type or
INTEGER type that is being used in the enumerated style, provided
the number occurs as an optional element of a SET or SEQUENCE; and
(b) 列挙されたスタイルに使用されているENUMERATEDタイプかINTEGERタイプで数というすべての未知を無視してください、数がSETかSEQUENCEの随意的な要素として現れるなら。 そして
(c) ignore all unknown elements in SETs, at the end of SEQUENCEs,
or in CHOICEs where the CHOICE is itself an optional element of a
SET or SEQUENCE.
(c) SEQUENCEsの端のSETsかCHOICEがそれ自体でSETかSEQUENCEの随意的な要素であるCHOICEsのすべての未知の要素を無視してください。
If an extension containing unexpected values is marked critical, the implementation MUST reject the certificate or CRL containing the unrecognized extension.
予期していなかった値を含む拡大が批判的であるとマークされるなら、実現は認識されていない拡大を含む証明書かCRLを拒絶しなければなりません。
Appendix C. Examples
付録C.の例
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 C.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.
セクションC.1は分類名がcnであるカリフォルニア=私たちによって発行された、「自己によってサインされた」証明書、o=gov、ou=nistの注釈された十六進法ダンプを含んでいます。 証明書は、パラメタでDSA公開鍵を含んでいて、対応するDSA秘密鍵によってサインされます。
Section C.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 C.1.
セクションC.2は終わりの実体証明書の注釈された十六進法ダンプを含んでいます。 終わりの実体証明書は、DSA公開鍵を含んでいて、セクションC.1の「自己によってサインされた」証明書に対応する秘密鍵によってサインされます。
Section C.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.
セクションC.3はRSA公開鍵を含んでいて、RSAとMD5を契約される終わりの実体証明書のダンプを含んでいます。 この証明書は最小量の証明経路の一部ではありません。
Section C.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 C.2.
セクションC.4はCRLの注釈された十六進法ダンプを含んでいます。 CRLは分類名がcn=私たちであるカリフォルニアによって発行されて、o=gov、ou=nist、および取り消された証明書のリストはC.2に提示された終わりの実体証明書を含んでいます。
The certificates were processed using Peter Gutman's dumpasn1 utility to generate the output. The source for the dumpasn1 utility is available at <http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>. The binaries for the certificates and CRLs are available at <http://csrc.nist.gov/pki/pkixtools>.
証明書は、出力を発生させるのにピーターGutman'sのdumpasn1ユーティリティを使用することで処理されました。 dumpasn1ユーティリティのためのソースは<http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>に手があいています。 証明書とCRLsのための2種混合毒ガスは<http://csrc.nist.gov/pki/pkixtools>で利用可能です。
C.1 Certificate
C.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 23 (17 hex);
このセクションは699バイトのバージョン3証明書の注釈された十六進法ダンプを含みます。 証明書は以下の情報を含んでいます: (a) 通し番号は23(17十六進法)です。
Housley, et. al. Standards Track [Page 115] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[115ページ]。
(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 generated using method (1) of section 4.2.1.2; and (h) the certificate is a CA certificate (as indicated through the basic constraints extension.)
(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) 証明書がセクション4.2.1の方法(1)を使用することで発生する対象の主要な識別子拡張子を含んでいる、.2。 (h) そして、証明書はカリフォルニア証明書です。(基本的な規制拡大で示されるように。)
0 30 699: SEQUENCE {
4 30 635: SEQUENCE {
8 A0 3: [0] {
10 02 1: INTEGER 2
: }
13 02 1: INTEGER 17
16 30 9: SEQUENCE {
18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
: }
27 30 42: SEQUENCE {
29 31 11: SET {
31 30 9: SEQUENCE {
33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
38 13 2: PrintableString 'US'
: }
: }
42 31 12: SET {
44 30 10: SEQUENCE {
46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
51 13 3: PrintableString 'gov'
: }
: }
56 31 13: SET {
58 30 11: SEQUENCE {
60 06 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
65 13 4: PrintableString 'NIST'
: }
: }
: }
71 30 30: SEQUENCE {
73 17 13: UTCTime '970630000000Z'
88 17 13: UTCTime '971231000000Z'
: }
103 30 42: SEQUENCE {
105 31 11: SET {
0 30 699: 系列、73 17 13: UTCTime'970630000000Z'88 17 13: UTCTime'971231000000Z':、103、30 42、: 系列、105、31 11、: セット
Housley, et. al. Standards Track [Page 116] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[116ページ]。
107 30 9: SEQUENCE {
109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
114 13 2: PrintableString 'US'
: }
: }
118 31 12: SET {
120 30 10: SEQUENCE {
122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
127 13 3: PrintableString 'gov'
: }
: }
132 31 13: SET {
134 30 11: SEQUENCE {
136 06 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
141 13 4: PrintableString 'NIST'
: }
: }
: }
147 30 440: SEQUENCE {
151 30 300: SEQUENCE {
155 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1)
164 30 287: SEQUENCE {
168 02 129: INTEGER
: 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC
: FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC
: 48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F
: 22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64
: 3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A
: C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD
: 35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E
: 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A
: FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48
: 63 FE 43
300 02 21: INTEGER
: 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA
: 55 F7 7D 57 74 81 E5
323 02 129: INTEGER
: 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91
: C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92
: 81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77
: A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC
: 46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A
: 5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C
: 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2
: 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF
: F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE
: 1E 57 18
107 30 9: 系列、109 06 3: 物識別子countryName(2 5 4 6)114 13の2: PrintableString'米国':、: } 118 31 12: セット、120、30 10: 系列、122、06、3、: 物の識別子organizationName、(2 5 4、10、)、127 13 3: PrintableString'gov':、: } 132 31 13: セット、134、30 11: 系列、136 06 3: 物の識別子:、organizationalUnitName、(2 5 4、11、)、141 13 4: PrintableString'NIST':、: } : } 147 30 440: 系列、151、30、300: 系列、155、06、7: OBJECT IDENTIFIER dsa、(1 2、840、10040、4 1)、164、30、287: 系列..整数..Ce..エド..西暦..C..西暦..紀元前..C..C..EC..F1..ff; FC西暦21年のFB9E94 9E4B42 45 9Eの6A B2 48:63FE、43、300、02 21、: 整数: 00B2 0D B0 B1 01DF0C66 24FC13 92Ba: 55F7 7D57 74 81E5、323、02、129、: 整数: 00 9A BF46B1 F5 3F44の3D C9 A5 65FB91: C0 8E47F1 0A C3 01 47C2 44 42 36A9 92:81DE57C5E0 68 86 58 00 7B 1F F9 9B77; A1 C5 10A5 80 91 78 51 51 3C F6 FC FC CC: C38 7Eの46C6 81 78 92 84の3D F4 93 3D0 1A: 9C: 92B9 66 9Fの5B99 4EのAB14 64F6 0C21 22 4E28 08 40E8 95F6 D5 31 2A EF39A2: 58EのC4 3A A8 11 81 84 6D AF: 62C7 B2 6D9のF8 B4 19B4 C2 11AE D0 22 3B AA20 7FのEE: 1E57 18
Housley, et. al. Standards Track [Page 117] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[117ページ]。
: }
: }
455 03 133: BIT STRING 0 unused bits, encapsulates {
459 02 129: INTEGER
: 00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 04
: 75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3
: 03 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1
: 2A D3 78 77 63 56 EA 96 61 4D 42 0B 7A 1D
: FB AB 91 A4 CE DE EF 77 C8 E5 EF 20 AE A6
: 28 48 AF BE 69 C3 6A A5 30 F2 C2 B9 D9 82
: 2B 7D D9 C4 84 1F DE 0D E8 54 D7 1B 99 2E
: B3 D0 88 F6 D6 63 9B A7 E2 0E 82 D4 3B 8A
: 68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 41
: 7B C9 55
: }
: }
591 A3 50: [3] {
593 30 48: SEQUENCE {
595 30 29: SEQUENCE {
597 06 3: OBJECT IDENTIFIER
: subjectKeyIdentifier (2 5 29 14)
602 04 22: OCTET STRING, encapsulates {
604 04 20: OCTET STRING
: 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41
: 2C 29 49 F4 86 56
: }
: }
626 30 15: SEQUENCE {
628 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19)
633 01 1: BOOLEAN TRUE
636 04 5: OCTET STRING, encapsulates {
638 30 3: SEQUENCE {
640 01 1: BOOLEAN TRUE
: }
: }
: }
: }
: }
: }
643 30 9: SEQUENCE {
645 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
: }
654 03 47: BIT STRING 0 unused bits, encapsulates {
657 30 44: SEQUENCE {
659 02 20: INTEGER
: 43 1B CF 29 25 45 C0 4E 52 E7 7D D6 FC B1
: 66 4C 83 CF 2D 77
681 02 20: INTEGER
: } : } 455 03 133: BIT STRING0未使用のビット、要約、459、02、129: 整数: 00 B5 9E1F49 04 47D1 DB F5 3A DDカリフォルニア04: 75 8EのDD75F6 9B 8A B1 97D6 59 69 82D3: 03 4D FD 3B36 5F4A F2 D1 4E C1 07F5 D1: 2A D3 78 77 63 56EA96 61 4D42 0B 7A 1D: FB AB91A4Ce DE EF77C8 5EのEF20AE A6: 28 48AF、69C3 6A A5 30F2 C2 B9 D9 82になってください: 2B 7D D9 C4 84 1F DE0D E8 54D7 1B99 2E: B3 D0 88F6 D6 63 9B A7E2 0の82EのD4 3B 8A: 68 1B06 56 31 59 0B49EB99A5 D5 81 41: 7B C9 55: } : } 591 A3 50: [3] { 593 30 48: 系列、595、30 29: 系列、597、06、3: 物の識別子: subjectKeyIdentifier、(2 5、29 14)、602、04 22: OCTET STRING、要約する、604、04 20、: OCTET STRING: 紀元前ADの86CA A5 22 81 62EF AD0A89、72 41:2 C29 49F4 86 56:、: } 626 30 15: 系列、628、06、3: 識別子basicConstraintsが反対する、(2 5、29 19)、633、01、1: ブール本当の636、04、5: OCTET STRING、要約する、638、30、3、: SEQUENCE、640 01 1 : BOOLEAN TRUE:、:、: } : } : } : } 643 30 9: 系列、645、06、7: 識別子dsaWithSha1が反対する、(1 2、840、10040、4 3)、: } 654 03 47: BIT STRING0未使用のビット、要約、657、30 44: 系列、659、02 20: 整数: 43 1B Cf29 25 45C0 4E52E7 7D D6 FC B1: 66 4 C83Cf2D77 681 02 20: 整数
Housley, et. al. Standards Track [Page 118] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[118ページ]。
: 0B 5B 9A 24 11 98 E8 F3 86 90 04 F6 08 A9
: E1 8D A5 CC 3A D4
: }
: }
: }
: 0B 5B 9A24 11 98 8EのF3 86 90 04F6 08A9: E1 8D A5は3A D4をCCします: } : } : }
C.2 Certificate
C.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 matching the subject key identifier of the certificate in Appendix C.1; and (i) the certificate includes one alternative name - an RFC 822 address of "wpolk@nist.gov".
このセクションは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) 証明書はAppendix C.1に証明書の対象の主要な識別子に合っている権威の主要な識別子拡張子を含んでいます。 (i) そして、証明書は1つの代替名を含んでいます--" wpolk@nist.gov "のRFC822アドレス。
0 30 730: SEQUENCE {
4 30 665: SEQUENCE {
8 A0 3: [0] {
10 02 1: INTEGER 2
: }
13 02 1: INTEGER 18
16 30 9: SEQUENCE {
18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
: }
27 30 42: SEQUENCE {
29 31 11: SET {
31 30 9: SEQUENCE {
33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
38 13 2: PrintableString 'US'
: }
: }
42 31 12: SET {
44 30 10: SEQUENCE {
46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
51 13 3: PrintableString 'gov'
: }
: }
0 30 730: SEQUENCE { 4 30 665: SEQUENCE { 8 A0 3: [0] { 10 02 1: INTEGER 2 : } 13 02 1: INTEGER 18 16 30 9: SEQUENCE { 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) : } 27 30 42: SEQUENCE { 29 31 11: SET { 31 30 9: SEQUENCE { 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 38 13 2: PrintableString 'US' : } : } 42 31 12: SET 44 30 10、: 系列、46 06、3、: 物の識別子organizationName、(2 5 4、10、)、51 13、3、: PrintableString'gov':、:
Housley, et. al. Standards Track [Page 119] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[119ページ]。
56 31 13: SET {
58 30 11: SEQUENCE {
60 06 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
65 13 4: PrintableString 'NIST'
: }
: }
: }
71 30 30: SEQUENCE {
73 17 13: UTCTime '970730000000Z'
88 17 13: UTCTime '971201000000Z'
: }
103 30 61: SEQUENCE {
105 31 11: SET {
107 30 9: SEQUENCE {
109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
114 13 2: PrintableString 'US'
: }
: }
118 31 12: SET {
120 30 10: SEQUENCE {
122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
127 13 3: PrintableString 'gov'
: }
: }
132 31 13: SET {
134 30 11: SEQUENCE {
136 06 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
141 13 4: PrintableString 'NIST'
: }
: }
147 31 17: SET {
149 30 15: SEQUENCE {
151 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
156 13 8: PrintableString 'Tim Polk'
: }
: }
: }
166 30 439: SEQUENCE {
170 30 300: SEQUENCE {
174 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1)
183 30 287: SEQUENCE {
187 02 129: INTEGER
: 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC
: FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC
: 48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F
: 22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64
56 31 13: セット、58 30 11、: 系列、60 06、3、: 物の識別子: organizationalUnitName、(2 5 4、11、)、65 13、4、: PrintableString'NIST':、:、: } 71 30 30: 系列、73 17 13: UTCTime'970730000000Z'88 17 13: UTCTime'971201000000Z': } 103 30 61: 系列、105、31 11: セット、107、30、9、: 系列、109 06 3: 物識別子countryName(2 5 4 6)114 13の2: PrintableString'米国':、:、118、31 12、: セット、120、30 10、: 系列、122、06、3、: 物の識別子organizationName、(2 5 4、10、)、127 13 3: PrintableString'gov':、:、132、31 13、: セット、134、30 11、: 系列、136 06 3: 物の識別子:、organizationalUnitName、(2 5 4、11、)、141 13 4: PrintableString'NIST':、:、147、31 17、: セット、149、30 15、: 系列、151 06 3: 物識別子commonName(2 5 4 3)156 13の8: PrintableString'ティム・ポーク':、:、: } 166 30 439: 系列、170、30、300: SEQUENCE、174、06、7、: OBJECT IDENTIFIER dsa、(1 2、840、10040、4 1)、183、30、287、: SEQUENCE、187 02 129:INTEGER:00B6 8B0F94 2B 9A CE A5 25C6 F2 ED FC: C西暦90年9B紀元前FB95 32西暦01 12 33年のB9E0 1年: 48 54 9E F3 94 77 3C2C71 35 55E6FE4F: 22CB D5 D8 3E89 93 33 4D FC BD4F41 64
Housley, et. al. Standards Track [Page 120] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[120ページ]。
: 3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A
: C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD
: 35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E
: 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A
: FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48
: 63 FE 43
319 02 21: INTEGER
: 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA
: 55 F7 7D 57 74 81 E5
342 02 129: INTEGER
: 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91
: C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92
: 81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77
: A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC
: 46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A
: 5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C
: 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2
: 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF
: F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE
: 1E 57 18
: }
: }
474 03 132: BIT STRING 0 unused bits, encapsulates {
478 02 128: INTEGER
: 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B AB
: A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C
: B7 C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33
: 37 F4 01 0B F5 04 1F 9D 2E 1F 62 D8 84 3A
: 9B 25 09 5A 2D C8 46 8E 2B D4 F5 0D 3B C7
: 2D C6 6C B9 98 C1 25 3A 44 4E 8E CA 95 61
: 35 7C CE 15 31 5C 23 13 1E A2 05 D1 7A 24
: 1C CB D3 72 09 90 FF 9B 9D 28 C0 A1 0A EC
: 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F B5
: 95 BE
: }
: }
609 A3 62: [3] {
611 30 60: SEQUENCE {
613 30 25: SEQUENCE {
615 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
620 04 18: OCTET STRING, encapsulates {
622 30 16: SEQUENCE {
624 81 14: [1] 'wpolk@nist.gov'
: }
: }
: }
640 30 31: SEQUENCE {
642 06 3: OBJECT IDENTIFIER
: 2 98 70EC31B4 50DE EB F1 98 28 0Aあたり3E: C9 3E44B3 FD22 97 96 83D0 18A3E3BD: 35 5B ff EE A3 21 72 6A 7B96DA B9 3F1E: 5A90AF24D6 20F0 0D21A7 D4 02B9 1A: FC西暦21年のFB9E94 9E4B42 45 9Eの6A B2 48: 63FE43 319、02 21: 整数: 00 B2 0D B0 B1 01DF0C66 24FC13 92Ba: 55F7 7D57 74 81ユーロの5 342、02、129: 整数: 00 9A BF46B1 F5 3F44の3D C9 A5 65FB91: C0 8E47F1 0A C3 01 47C2 44 42 36A9 92: 81 DE57C5E0 68 86 58 00 7B 1F F9 9B77: A1 C5 10A5 80 91 78 51 51 3C F6 FC FC CC: 46 C38 7EのC6 81 78 92 84の3D F4 93 3D0 1A: 5B99 4EのAB14 64F6 0C21 22 4E28 08、9C: 92 B9 66 9F40E8 95F6 D5 31 2A EF39A2: 62 C7 B2 6D9 58EのC4 3A A8 11 81 84 6D AF: F8 B4 19B4 C2 11AE D0 22 3B AA20 7F EE: 1E57 18: } : } 474 03 132: BIT STRING0未使用のビット、要約、478、02、128: 整数: 30 B6 75F7 7C20 31AE38掲示板7E0D 2B AB: 98CD5 5F6E A0 9C 4B DF20D5 24 13 3C C: B7 C1Ba4A Ba A9 95 80 53F0 0D72DC33: 37 F4 01 0B F5 04 1F9D2 1EのF62D8 84 3A: C8 46 8Eの9B25 09 5A2D2B D4 F5 0D 3B C7: 2D C6 6C B9 98C1 25 3A44 4 8E Eのカリフォルニア95 61: 35 7 2 05D1 7A24あたりC Ce15 31 5C23 13 1E: 1 C CB D3 72 09 90ff9B 9D28C0 A1 0A EC: 46 9F0D B8 D0DC D0 18A6 2B5E F9 8F B5: 95 あります: } : } 609 A3 62: [3] { 611 30 60: 系列、613、30 25: 系列、615、06、3: 識別子subjectAltNameが反対する、(2 5、29 17)、620、04 18: OCTET STRING、要約する、622、30 16、: SEQUENCE、624、81 14、: [1]' wpolk@nist.gov ':、:、: } 640 30 31: 系列、642、06、3: 物の識別子
Housley, et. al. Standards Track [Page 121] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[121ページ]。
: authorityKeyIdentifier (2 5 29 35)
647 04 24: OCTET STRING, encapsulates {
649 30 22: SEQUENCE {
651 80 20: [0]
: 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72
: 41 2C 29 49 F4 86 56
: }
: }
: }
: }
: }
: }
673 30 9: SEQUENCE {
675 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
: }
684 03 48: BIT STRING 0 unused bits, encapsulates {
687 30 45: SEQUENCE {
689 02 20: INTEGER
: 36 97 CB E3 B4 2C E1 BB 61 A9 D3 CC 24 CC
: 22 92 9F F4 F5 87
711 02 21: INTEGER
: 00 AB C9 79 AF D2 16 1C A9 E3 68 A9 14 10
: B4 A0 2E FF 22 5A 73
: }
: }
: }
: authorityKeyIdentifier、(2 5、29 35)、647、04 24: OCTET STRING、要約する、649、30 22、: SEQUENCE、651、80 20、: [0]: 86 CA A5 22 81 62EF AD0A89紀元前AD72:41 2C29 49F4 86 56:、:、: } : } : } : } 673 30 9: 系列、675、06、7: 識別子dsaWithSha1が反対する、(1 2、840、10040、4 3)、: } 684 03 48: BIT STRING0未使用のビット、要約、687、30 45: 系列、689、02 20: 整数: 36 97CB3EのB4 2C E1掲示板61A9 D3CC24CC: 22 92 9F F4 F5 87 711、02 21: 整数: 00 AB C9 79AF D2 16 1C A9E3 68A9 14 10: B4 A0 2E ff22 5A73: } : } : }
C.3 End Entity Certificate Using RSA
RSAを使用するC.3終わりの実体証明書
This section contains an annotated hex dump of a 654 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 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 issued on May 21, 1996 at 09:58:26 and expired on May 21, 1997 at 09:58:26; (f) the certificate contains a 1024 bit RSA public key; (g) the certificate is an end entity certificate (not a CA certificate); (h) the certificate includes an alternative subject name of "<http://www.itl.nist.gov/div893/staff/polk/index.html>" and an alternative issuer name of "<http://www.nist.gov/>" - both are URLs; (i) the certificate include an authority key identifier extension and a certificate policies extension specifying the policy OID 2.16.840.1.101.3.2.1.48.9; and
このセクションは654バイトのバージョン3証明書の注釈された十六進法ダンプを含みます。 証明書は以下の情報を含んでいます: (a) 通し番号は256です。 (b) 証明書はRSAとSHA-1細切れ肉料理アルゴリズムを契約されます。 (c) 発行人の分類名はOU=NISTです。 O=gov。 CはU.S.(d)と等しいです、そして、対象の分類名はティム・CN=ポークです。 OU=NIST。 O=gov。 Cは証明書が1997年5月21日09:58:26に1996年5月21日09:58:26に発行されて、吐き出された米国(e)と等しいです。 (f) 証明書は1024年のビットのRSA公開鍵を含んでいます。 (g) 証明書は終わりの実体証明書(カリフォルニア証明書でない)です。 (h) 証明書は「<http://www.itl.nist.gov/div893/スタッフ/polk/index.html>」の代替の対象の名前と「<http://www.nist.gov/>」の代替の発行人名を含んでいます--ともに、URLです。 (i) 証明書が方針OID2.16.840.1を指定する権威の主要な識別子拡張子と証明書方針拡張子を含んでいる、.101、.3、.2、.1、.48、.9。 そして
Housley, et. al. Standards Track [Page 122] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[122ページ]。
(j) the certificate includes a critical key usage extension specifying that the public key is intended for verification of digital signatures.
(j) 証明書は公開鍵がデジタル署名の検証のために意図すると指定する批判的な主要な用法拡大を含んでいます。
0 30 654: SEQUENCE {
4 30 503: SEQUENCE {
8 A0 3: [0] {
10 02 1: INTEGER 2
: }
13 02 2: INTEGER 256
17 30 13: SEQUENCE {
19 06 9: OBJECT IDENTIFIER
: sha1withRSAEncryption (1 2 840 113549 1 1 5)
30 05 0: NULL
: }
32 30 42: SEQUENCE {
34 31 11: SET {
36 30 9: SEQUENCE {
38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
43 13 2: PrintableString 'US'
: }
: }
47 31 12: SET {
49 30 10: SEQUENCE {
51 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
56 13 3: PrintableString 'gov'
: }
: }
61 31 13: SET {
63 30 11: SEQUENCE {
65 06 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
70 13 4: PrintableString 'NIST'
: }
: }
: }
76 30 30: SEQUENCE {
78 17 13: UTCTime '960521095826Z'
93 17 13: UTCTime '970521095826Z'
: }
108 30 61: SEQUENCE {
110 31 11: SET {
112 30 9: SEQUENCE {
114 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
119 13 2: PrintableString 'US'
: }
: }
123 31 12: SET {
0 30 654: 系列、4、30、503、: 系列、8A0 3: 0、10 02、1、: 整数2:、13 02、2、: 整数、256、17 30 13; 系列、19 06、9、: 物の識別子: sha1withRSAEncryption、(1 2、840、113549、1 1 5)、30 05、0、: ヌル:、32 30 42; 系列、78 17 13: UTCTime'960521095826Z'93 17 13: UTCTime'970521095826Z':、108、30 61、: 系列、110、31 11、: セット、112、30、9、: 系列、114 06 3: 物識別子countryName(2 5 4 6)119 13の2: PrintableString'米国':、:、123、31 12、: セット
Housley, et. al. Standards Track [Page 123] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[123ページ]。
125 30 10: SEQUENCE {
127 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
132 13 3: PrintableString 'gov'
: }
: }
137 31 13: SET {
139 30 11: SEQUENCE {
141 06 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
146 13 4: PrintableString 'NIST'
: }
: }
152 31 17: SET {
154 30 15: SEQUENCE {
156 06 3: OBJECT IDENTIFIER commonName (2 5 4 3)
161 13 8: PrintableString 'Tim Polk'
: }
: }
: }
171 30 159: SEQUENCE {
174 30 13: SEQUENCE {
176 06 9: OBJECT IDENTIFIER
: rsaEncryption (1 2 840 113549 1 1 1)
187 05 0: NULL
: }
189 03 141: BIT STRING 0 unused bits, encapsulates {
193 30 137: SEQUENCE {
196 02 129: INTEGER
: 00 E1 6A E4 03 30 97 02 3C F4 10 F3 B5 1E
: 4D 7F 14 7B F6 F5 D0 78 E9 A4 8A F0 A3 75
: EC ED B6 56 96 7F 88 99 85 9A F2 3E 68 77
: 87 EB 9E D1 9F C0 B4 17 DC AB 89 23 A4 1D
: 7E 16 23 4C 4F A8 4D F5 31 B8 7C AA E3 1A
: 49 09 F4 4B 26 DB 27 67 30 82 12 01 4A E9
: 1A B6 C1 0C 53 8B 6C FC 2F 7A 43 EC 33 36
: 7E 32 B2 7B D5 AA CF 01 14 C6 12 EC 13 F2
: 2D 14 7A 8B 21 58 14 13 4C 46 A3 9A F2 16
: 95 FF 23
328 02 3: INTEGER 65537
: }
: }
: }
333 A3 175: [3] {
336 30 172: SEQUENCE {
339 30 63: SEQUENCE {
341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17)
346 04 56: OCTET STRING, encapsulates {
348 30 54: SEQUENCE {
125 30 10: 系列、127、06、3、: 物の識別子organizationName、(2 5 4、10、)、132 13 3: PrintableString'gov':、: } 137 31 13: セット、139、30 11: 系列、141 06 3: 物の識別子:、organizationalUnitName、(2 5 4、11、)、146 13 4: PrintableString'NIST':、: } 152 31 17: セット、154、30 15: 系列、156 06 3: 物識別子commonName(2 5 4 3)161 13の8: PrintableString'ティム・ポーク':、: } : } 171 30 159: 系列、174、30 13: 系列、176、06、9: 物の識別子: rsaEncryption、(1 2、840、113549、1 1 1)、187、05、0: ヌル: } 189 03 141: BIT STRING0未使用のビット、要約、193、30、137: 系列、196 02 129:整数:00E1 6A E4 03 30 97 02 3C F4 10F3 B5 1E: 9EのA4 8A F0 A3 75: ECエドB6 56 96 7Fの4D7F14 7B F6 F5 D0 78 88 99 85 9A F2 3E、68 77:87、EB9E D1 9F C0 B4 17DC AB89 23A4 1D: 7E16 23 4C4F A8 4D F5 31B8 7C AA E3 1A: 49 09F4 4B26DB27 67 30 82 12 01 4A E9: 1A B6 C1 0C53 8B6C FC2F7A43EC、33 36:7、32EのB2 7B D5 AA Cf01 14C6 12EC13F2: 2D14 7A 8B21 58 14 13 4C46A3 9A F2 16:95ff、23 328 02 3: 整数65537:、: } : } 333 A3 175: [3] { 336 30 172: 系列、339、30 63: SEQUENCE、341、06、3、: OBJECT IDENTIFIER subjectAltName、(2 5、29 17、)、346、04 56、: OCTET STRING、要約、348、30 54、: SEQUENCE
Housley, et. al. Standards Track [Page 124] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[124ページ]。
350 86 52: [6]
: 'http://www.itl.nist.gov/div893/staff/'
: 'polk/index.html'
: }
: }
: }
404 30 31: SEQUENCE {
406 06 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18)
411 04 24: OCTET STRING, encapsulates {
413 30 22: SEQUENCE {
415 86 20: [6] 'http://www.nist.gov/'
: }
: }
: }
437 30 31: SEQUENCE {
439 06 3: OBJECT IDENTIFIER
: authorityKeyIdentifier (2 5 29 35)
444 04 24: OCTET STRING, encapsulates {
446 30 22: SEQUENCE {
448 80 20: [0]
: 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E
: 70 6A 4A 20 84 2C 32
: }
: }
: }
470 30 23: SEQUENCE {
472 06 3: OBJECT IDENTIFIER
: certificatePolicies (2 5 29 32)
477 04 16: OCTET STRING, encapsulates {
479 30 14: SEQUENCE {
481 30 12: SEQUENCE {
483 06 10: OBJECT IDENTIFIER
: '2 16 840 1 101 3 2 1 48 9'
: }
: }
: }
: }
495 30 14: SEQUENCE {
497 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)
502 01 1: BOOLEAN TRUE
505 04 4: OCTET STRING, encapsulates {
507 03 2: BIT STRING 7 unused bits
: '1'B (bit 0)
: }
: }
: }
: }
: }
350 86 52: [6] : ' http://www.itl.nist.gov/div893/staff/ ': 'polk/index.html': } : } : } 404 30 31: 系列、406、06、3: 識別子issuerAltNameが反対する、(2 5、29 18)、411、04 24: OCTET STRING、要約する、413、30 22: 系列、415、86 20: [6]' http://www.nist.gov/ ': } : } : } 437 30 31: 系列、439、06、3: 物の識別子: authorityKeyIdentifier、(2 5、29 35)、444、04 24: OCTET STRING、要約する、446、30 22: 系列、448、80 20: [0] : 08 68AF85 33C8 39 4A 7A F8 82 93 8E: 70 6A 4A20 84 2C32: } : } : } 470 30 23: 系列、472、06、3: 物の識別子: certificatePolicies、(2 5、29 32)、477、04 16: OCTET STRING、要約する、479、30 14: 系列、481、30 12: 系列、483、06 10、: 物の識別子: '2、16、840、1、101、3 2 1、48、9':、: } : } : } 495 30 14: 系列、497、06、3: 識別子keyUsageが反対する、(2 5、29 15)、502、01、1: ブール本当の505、04、4: OCTET STRING、要約する、507、03、2: BIT STRING未使用の7ビット: '1'B(ビット0): } : } : } : } : }
Housley, et. al. Standards Track [Page 125] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[125ページ]。
511 30 13: SEQUENCE {
513 06 9: OBJECT IDENTIFIER
: sha1withRSAEncryption (1 2 840 113549 1 1 5)
524 05 0: NULL
: }
526 03 129: BIT STRING 0 unused bits
: 1E 07 77 6E 66 B5 B6 B8 57 F0 03 DC 6F 77
: 6D AF 55 1D 74 E5 CE 36 81 FC 4B C5 F4 47
: 82 C4 0A 25 AA 8D D6 7D 3A 89 AB 44 34 39
: F6 BD 61 1A 78 85 7A B8 1E 92 A2 22 2F CE
: 07 1A 08 8E F1 46 03 59 36 4A CB 60 E6 03
: 40 01 5B 2A 44 D6 E4 7F EB 43 5E 74 0A E6
: E4 F9 3E E1 44 BE 1F E7 5F 5B 2C 41 8D 08
: BD 26 FE 6A A6 C3 2F B2 3B 41 12 6B C1 06
: 8A B8 4C 91 59 EB 2F 38 20 2A 67 74 20 0B
: 77 F3
: }
511 30 13: 系列、513 06 9: 物の識別子:、sha1withRSAEncryption、(1 2、840 113549 1 1 5) 524 05 0 : ヌル:、526、03、129: BIT STRING未使用の0ビット: 1E07 77 6 66EのB5 B6 B8 57F0 03DC6F77: 6D AF55 1D74 5EのCe36 81FC 4B C5 F4 47: 82 C4 0A25AA 8D D6 7D 3A89AB44 34 39: F6 BD61 1A78 85 7A B8 1E92A2 22 2FのCe: 07 1A08 8EのF1 46 03 59 36 4A CB60ユーロの6 03: 40 01 5B 2A44D6E4 7F EB43 5の74Eの0A E6: 4F9 3E E1 44Eであることが、1F E7 5F 5B2C41 8D08です: BD26FE 6A A6 C3 2F B2 3B41 12 6B C1 06: 8A B8 4C91 59EB2F38 20 2A67 74 20 0B: 77F3: }
C.4 Certificate Revocation List
C.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 August 7, 1997; the next scheduled issuance was September 7, 1997. The CRL includes one revoked certificates: serial number 18 (12 hex), which was revoked on July 31, 1997 due to keyCompromise. The CRL itself is number 18, and it was signed with DSA and SHA-1.
このセクションは1つの拡大(cRLNumber)によるバージョン2CRLの注釈された十六進法ダンプを含みます。 CRLはOU=NISTによって発行されました。 O=gov。 Cは1997年8月7日に米国と等しいです。 次の予定されている発行は1997年9月7日でした。 CRLは1通の取り消された証明書を含んでいます: 通し番号18(12十六進法)はkeyCompromiseがそうします。(それは、1997年7月31日に取り消されました)。 CRL自身はNo.18です、そして、それはDSAとSHA-1を契約されました。
0 30 203: SEQUENCE {
3 30 140: SEQUENCE {
6 02 1: INTEGER 1
9 30 9: SEQUENCE {
11 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
: }
20 30 42: SEQUENCE {
22 31 11: SET {
24 30 9: SEQUENCE {
26 06 3: OBJECT IDENTIFIER countryName (2 5 4 6)
31 13 2: PrintableString 'US'
: }
: }
35 31 12: SET {
37 30 10: SEQUENCE {
39 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10)
44 13 3: PrintableString 'gov'
: }
: }
49 31 13: SET {
51 30 11: SEQUENCE {
0 30 203: SEQUENCE { 3 30 140: SEQUENCE { 6 02 1: INTEGER 1 9 30 9: SEQUENCE { 11 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) : } 20 30 42: SEQUENCE { 22 31 11: SET { 24 30 9: SEQUENCE { 26 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 31 13 2: PrintableString 'US' : } : } 35 31 12: SET { 37 30 10: SEQUENCE { 39 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 44 13 3: PrintableString 'gov' : } : } 49 31 13: SET { 51 30 11: SEQUENCE {
Housley, et. al. Standards Track [Page 126] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[126ページ]。
53 06 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
58 13 4: PrintableString 'NIST'
: }
: }
: }
64 17 13: UTCTime '970807000000Z'
79 17 13: UTCTime '970907000000Z'
94 30 34: SEQUENCE {
96 30 32: SEQUENCE {
98 02 1: INTEGER 18
101 17 13: UTCTime '970731000000Z'
116 30 12: SEQUENCE {
118 30 10: SEQUENCE {
120 06 3: OBJECT IDENTIFIER cRLReason (2 5 29 21)
125 04 3: OCTET STRING, encapsulates {
127 0A 1: ENUMERATED 1
: }
: }
: }
: }
: }
130 A0 14: [0] {
132 30 12: SEQUENCE {
134 30 10: SEQUENCE {
136 06 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20)
141 04 3: OCTET STRING, encapsulates {
143 02 1: INTEGER 12
: }
: }
: }
: }
: }
146 30 9: SEQUENCE {
148 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
: }
157 03 47: BIT STRING 0 unused bits, encapsulates {
160 30 44: SEQUENCE {
162 02 20: INTEGER
: 22 4E 9F 43 BA 95 06 34 F2 BB 5E 65 DB A6
: 80 05 C0 3A 29 47
184 02 20: INTEGER
: 59 1A 57 C9 82 D7 02 21 14 C3 D4 0B 32 1B
: 96 16 B1 1F 46 5A
: }
: }
: }
53 06 3: 物の識別子: organizationalUnitName、(2 5 4、11)、58 13、4: PrintableString'NIST': } : } : } 64 17 13: UTCTime'970807000000Z'79 17 13: UTCTime'970907000000Z'94 30 34: 系列、96 30 32: 系列、98 02、1: 整数18 101、17 13: UTCTime'970731000000Z'116 30 12: 系列、118、30 10: SEQUENCE、120、06、3、: OBJECT IDENTIFIER cRLReason、(2 5、29 21、)、125 04 3: OCTET STRING、要約、127 0A1: ENUMERATED1:、:、: } : } : } 130 A0 14: [0] { 132 30 12: 系列、134、30 10: 系列、136、06、3: 識別子cRLNumberが反対する、(2 5、29 20)、141、04、3: OCTET STRING、要約する、143 02 1: INTEGER12:、: } : } : } : } 146 30 9: 系列、148、06、7: 識別子dsaWithSha1が反対する、(1 2、840、10040、4 3)、: } 157 03 47: BIT STRING0未使用のビット、要約、160、30 44: 系列、162、02 20: 整数: 22 65Eの4 9EのF43Ba95 06 34F2掲示板5DB A6: 80 05C0 3A29 47 184、02 20: 整数: 59 1A57C9 82D7 02 21 14C3 D4 0B32 1B: 96 16B1 1F46 5A: } : } : }
Housley, et. al. Standards Track [Page 127] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[127ページ]。
Author Addresses
作者アドレス
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA
ラッセルHousley RSA研究所918は小山Driveヴァージニア20170ハーンドン(米国)を跳ばせます。
EMail: rhousley@rsasecurity.com
メール: rhousley@rsasecurity.com
Warwick Ford VeriSign, Inc. 401 Edgewater Place Wakefield, MA 01880 USA
ウォリックフォードベリサインInc.401Edgewater Place MA01880ウェークフィールド(米国)
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 Citigroup 909 Third Ave, 16th Floor New York, NY 10043 USA
デヴィッドのソロのシティグループ909第3Ave、第16Floorニューヨーク、ニューヨーク10043米国
EMail: dsolo@alum.mit.edu
メール: dsolo@alum.mit.edu
Housley, et. al. Standards Track [Page 128] RFC 3280 Internet X.509 Public Key Infrastructure April 2002
et Housley、アル。 規格はインターネットX.509公開鍵暗号基盤2002年4月にRFC3280を追跡します[128ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Housley, et. al. Standards Track [Page 129]
et Housley、アル。 標準化過程[129ページ]
一覧
スポンサーリンク
