[要約] RFC 3280は、インターネット上で使用される公開鍵基盤（PKI）証明書と証明書失効リスト（CRL）のプロファイルに関する規格です。このRFCの目的は、PKIのセキュリティと信頼性を向上させるための標準化とガイドラインの提供です。
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
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
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証明書失効リスト（CRL）のプロファイルを作成します。このアプローチとモデルの概要を紹介します。 X.509 v3証明書の形式について詳しく説明します。インターネットの名前形式の形式とセマンティクスについても説明します。標準の証明書拡張機能が説明され、2つのインターネット固有の拡張機能が定義されています。必要な証明書拡張のセットが指定されています。 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
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
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
Full Copyright Statement . . . . . . . . . . . . . . . . . . 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.
この仕様は、インターネットPKIの証明書と証明書失効リスト（CRL）の形式とセマンティクスをプロファイルしています。インターネット環境での認証パスの処理手順について説明します。最後に、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およびISO / IEC / ITU-T標準との関係について説明します。特に、このドキュメントとIETF PEM仕様およびISO / IEC / ITU-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バージョン2 CRLをプロファイルします。プロファイルには、インターネットPKIで役立つISO / IEC / ITU-TおよびANSI拡張の識別が含まれています。プロファイルは、最新のISO / IEC / ITU-T標準で使用されている1997 ASN.1構文ではなく、1988抽象構文記法1（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には、証明書パス検証手順が含まれています。これらの手順は、ISO / IEC / ITU-T定義に基づいています。同じ結果を得るには実装が必要ですが、指定された手順を使用する必要はありません。
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.
最後に、実装者を支援するために3つの付録が提供されています。付録Aには、この仕様で定義または参照されているすべてのASN.1構造が含まれています。上記のように、この資料は1988 ASN.1で提示されています。付録Bには、この仕様で使用されるASN.1表記のあまり知られていない機能に関する注意事項が含まれています。付録Cには、適合証明書と適合CRLの例が含まれています。
This specification obsoletes RFC 2459. This specification differs from RFC 2459 in five basic areas:
この仕様はRFC 2459を廃止します。この仕様は、RFC 2459と次の5つの基本的な領域が異なります。
* 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に含まれています。 RFC 2459は、パス検証の高レベルの説明のみを提供しました。
* 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.
* CRLを使用して証明書のステータスを決定するアルゴリズムは、この仕様のセクション6.3で提供されています。この資料はRFC 2459にはありませんでした。
* To accommodate new usage models, detailed information describing the use of delta CRLs is provided in Section 5 of this specification.
* 新しい使用モデルに対応するため、Delta CRLの使用に関する詳細情報は、この仕様のセクション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拡張です。証明書の拡張は、サブジェクト情報へのアクセスであり、any-policyを抑制し、最新の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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119で説明されているように解釈されます。
2 Requirements and Assumptions
2要件と前提条件
The goal of this specification is to develop a profile to facilitate the use of X.509 certificates within Internet applications for those communities wishing to make use of X.509 technology. Such applications may include WWW, electronic mail, user authentication, and IPsec. In order to relieve some of the obstacles to using X.509 certificates, this document defines a profile to promote the development of certificate management systems; development of application tools; and interoperability determined by policy.
この仕様の目標は、X.509テクノロジーの利用を希望するコミュニティがインターネットアプリケーション内でX.509証明書を簡単に使用できるようにするプロファイルを開発することです。このようなアプリケーションには、WWW、電子メール、ユーザー認証、IPsecなどがあります。 X.509証明書の使用に対するいくつかの障害を軽減するために、このドキュメントでは、証明書管理システムの開発を促進するためのプロファイルを定義しています。アプリケーションツールの開発;相互運用性はポリシーによって決定されます。
Some communities will need to supplement, or possibly replace, this profile in order to meet the requirements of specialized application domains or environments with additional authorization, assurance, or operational requirements. However, for basic applications, common representations of frequently used attributes are defined so that application developers can obtain necessary information without regard to the issuer of a particular certificate or certificate revocation list (CRL).
一部のコミュニティは、追加の承認、保証、または運用要件で特殊なアプリケーションドメインまたは環境の要件を満たすために、このプロファイルを補足するか、場合によっては置き換える必要があります。ただし、基本的なアプリケーションの場合、アプリケーション開発者が特定の証明書または証明書失効リスト（CRL）の発行者に関係なく必要な情報を取得できるように、頻繁に使用される属性の共通表現が定義されています。
A certificate user should review the certificate policy generated by the certification authority (CA) before relying on the authentication or non-repudiation services associated with the public key in a particular certificate. To this end, this standard does not prescribe legally binding rules or duties.
証明書ユーザーは、特定の証明書の公開キーに関連付けられている認証または否認防止サービスに依存する前に、証明機関（CA）によって生成された証明書ポリシーを確認する必要があります。このため、この規格は法的拘束力のある規則や義務を規定していません。
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.
属性証明書などの補足的な承認および属性管理ツールが登場したため、証明書に含まれる認証済み属性を制限することが適切な場合があります。これらの他の管理ツールは、多くの認証済み属性を伝達するより適切な方法を提供する場合があります。
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ディレクトリの使用を禁止していません。ただし、証明書および証明書失効リスト（CRL）を配布する任意の手段を使用できます。
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）の目標は、確定的で自動化された識別、認証、アクセス制御、および承認機能のニーズを満たすことです。これらのサービスのサポートにより、証明書に含まれる属性、およびポリシーデータや証明書パスの制約など、証明書内の補助的な制御情報が決まります。
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のユーザーは、クライアントソフトウェアを使用する人とプロセスであり、証明書で指定されたサブジェクトです。これらの用途には、電子メールのリーダーとライター、WWWブラウザーのクライアント、WWWサーバー、およびルーター内のIPsecのキーマネージャーが含まれます。このプロファイルは、これらのユーザーが使用するプラットフォームの制限と、ユーザー自身の高度さと注意力の制限を認識しています。これは、最小限のユーザー構成の責任（たとえば、信頼できるCAキー、ルール）、証明書内の明示的なプラットフォーム使用制限、ユーザーを多くの悪意のあるアクションから保護する証明書パス制限、および検証機能を慎重に自動化するアプリケーションで現れます。
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プロファイルは、一般的にCAを運用する個人をサポートするように構成されています。管理者に無制限の選択肢を提供すると、微妙なCA管理者のミスが広範な妥協につながる可能性が高まります。また、制限のない選択は、CAによって作成された証明書を処理および検証するソフトウェアを非常に複雑にします。
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.
Note that an Attribute Authority (AA) might also choose to delegate the publication of CRLs to a CRL issuer.
属性機関（AA）も、CRLの発行をCRL発行者に委任することを選択する場合があることに注意してください。
+---+
| 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 |
+---+ +------+
Figure 1 - PKI Entities
図1-PKIエンティティ
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 untrusted communications and server systems, and can be cached in unsecured storage in certificate-using systems.
公開鍵のユーザーは、関連する秘密鍵が、暗号化またはデジタル署名メカニズムが使用される正しいリモートサブジェクト（個人またはシステム）によって所有されているという信頼を必要とします。この信頼は、公開鍵の値をサブジェクトにバインドするデータ構造である公開鍵証明書を使用することによって得られます。信頼できるCAが各証明書にデジタル署名することで、バインディングがアサートされます。 CAは、このアサーションを技術的手段（チャレンジ応答プロトコルによる所有の証明）、秘密鍵の提示、またはサブジェクトによるアサーションに基づいて行うことができます。証明書には有効期間が限定されており、その署名付きコンテンツに示されています。証明書の署名と適時性は、証明書を使用するクライアントが個別にチェックできるため、信頼できない通信とサーバーシステムを介して証明書を配布し、証明書を使用するシステムの安全でないストレージにキャッシュできます。
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 / IEC 9594-8は、X.500 Directory勧告の一部として1988年に最初に公開され、標準の証明書形式[X.509]を定義しています。 1988標準の証明書形式は、バージョン1（v1）形式と呼ばれます。 X.500が1993年に改訂されたとき、さらに2つのフィールドが追加され、バージョン2（v2）形式になりました。
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年に公開されたインターネットプライバシー強化メール（PEM）RFCには、X.509 v1証明書に基づく公開鍵インフラストラクチャの仕様が含まれています[RFC 1422]。 RFC 1422を導入する試みで得られた経験から、v1およびv2証明書の形式はいくつかの点で不十分であることが明らかになりました。最も重要なのは、PEMの設計と実装の経験で必要であると証明された情報を伝達するために、より多くのフィールドが必要でした。これらの新しい要件に対応して、ISO / IEC、ITU-T、およびANSI X9は、X.509バージョン3（v3）証明書形式を開発しました。 v3形式は、追加の拡張フィールドのプロビジョニングを追加することにより、v2形式を拡張します。特定の拡張フィールドタイプは、標準で指定されるか、任意の組織またはコミュニティによって定義および登録されます。 1996年6月に、基本的なv3形式の標準化が完了しました[X.509]。
ISO/IEC, ITU-T, and ANSI X9 have also developed standard extensions for use in the v3 extensions field [X.509][X9.55]. These extensions can convey such data as additional subject identification information, key attribute information, policy information, and certification path constraints.
ISO / IEC、ITU-T、およびANSI X9も、v3拡張フィールド[X.509] [X9.55]で使用するための標準拡張を開発しました。これらの拡張機能は、追加のサブジェクト識別情報、主要な属性情報、ポリシー情報、証明書パスの制約などのデータを伝達できます。
However, the ISO/IEC, ITU-T, and ANSI X9 standard extensions are very broad in their applicability. In order to develop interoperable implementations of X.509 v3 systems for Internet use, it is necessary to specify a profile for use of the X.509 v3 extensions tailored for the Internet. It is one goal of this document to specify a profile for Internet WWW, electronic mail, and IPsec applications. Environments with additional requirements may build on this profile or may replace it.
ただし、ISO / IEC、ITU-T、およびANSI X9標準の拡張機能は、その適用範囲が非常に広範です。インターネット用のX.509 v3システムの相互運用可能な実装を開発するには、インターネット用に調整されたX.509 v3拡張機能を使用するためのプロファイルを指定する必要があります。このドキュメントの1つの目標は、インターネットWWW、電子メール、およびIPsecアプリケーションのプロファイルを指定することです。追加の要件がある環境は、このプロファイルに基づいて構築されたり、置き換えられたりする場合があります。
A user of a security service requiring knowledge of a public key generally needs to obtain and validate a certificate containing the required public key. If the public key user does not already hold an assured copy of the public key of the CA that signed the certificate, the CA's name, and related information (such as the validity period or name constraints), then it might need an additional certificate to obtain that public key. In general, a chain of multiple certificates may be needed, comprising a certificate of the public key owner (the end entity) signed by one CA, and zero or more additional certificates of CAs signed by other CAs. Such chains, called certification paths, are required because a public key user is only initialized with a limited number of assured CA public keys.
公開鍵の知識を必要とするセキュリティサービスのユーザーは、通常、必要な公開鍵を含む証明書を取得して検証する必要があります。公開鍵ユーザーが、証明書に署名したCAの公開鍵、CAの名前、および関連情報（有効期間や名前の制約など）の確実なコピーをまだ保持していない場合は、追加の証明書が必要になる場合があります。その公開鍵を取得します。一般に、1つのCAによって署名された公開鍵の所有者（エンドエンティティ）の証明書と、他のCAによって署名された0以上の追加のCA証明書を含む、複数の証明書のチェーンが必要になる場合があります。公開鍵ユーザーは限られた数の保証されたCA公開鍵でのみ初期化されるため、証明書パスと呼ばれるこのようなチェーンが必要です。
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:
公開鍵ユーザーが証明書パスを見つけられるようにCAを構成する方法はいくつかあります。 PEMの場合、RFC 1422はCAの厳密な階層構造を定義しました。 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証明書階層のルートとして機能します。証明書は、次のレベルの機関であるPCAに対してのみ発行されます。すべての認定パスは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）ポリシー認証局（PCA）：PCAは階層のレベル2にあり、各PCAはIPRAによって認証されています。 PCAは、ユーザーまたは下位の証明機関の認証に関するポリシーのステートメントを確立および公開します。明確なPCAは、さまざまなユーザーのニーズを満たすことを目的としています。たとえば、1つのPCA（組織の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）証明機関（CA）：CAは階層のレベル3にあり、より低いレベルにすることもできます。レベル3のものはPCAによって認定されています。 CAは、たとえば、特定の組織、特定の組織単位（部門、グループ、セクションなど）、または特定の地理的領域を表します。
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.
さらに、RFC 1422には、CAがCA自体の名前に従属する（X.500ネーミングツリー内の）名前を持つエンティティの証明書のみを発行できることを要求する名前従属ルールがあります。 PEM証明書パスに関連付けられた信頼は、PCA名によって暗示されます。名前の従属ルールにより、PCAの下のCAは、認証できる下位エンティティのセットに関して適切に制約されます（たとえば、組織のCAは、その組織の名前ツリーのエンティティのみを認証できます）。証明書ユーザーシステムは、名前の従属規則が遵守されていることを機械的に確認できます。
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:
RFC 1422はX.509 v1証明書形式を使用します。 X.509 v1の制限により、ポリシー情報を明確に関連付けたり、証明書のユーティリティを制限したりするために、いくつかの構造上の制限を課す必要がありました。これらの制限は次のとおりです。
(a) a pure top-down hierarchy, with all certification paths starting from IPRA;
（a）すべての認証パスがIPRAから始まる、純粋なトップダウン階層。
(b) a naming subordination rule restricting the names of a CA's subjects; and
（b）CAのサブジェクトの名前を制限する命名従属規則。そして
(c) use of the PCA concept, which requires knowledge of individual PCAs to be built into certificate chain verification logic. Knowledge of individual PCAs was required to determine if a chain could be accepted.
（c）PCAコンセプトの使用。これには、証明書チェーン検証ロジックに組み込まれる個々のPCAの知識が必要です。チェーンが受け入れられるかどうかを判断するには、個々のPCAの知識が必要でした。
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を使用すると、RFC 1422で対処されている要件のほとんどは、使用されるCA構造を制限する必要なく、証明書拡張を使用して対処できます。特に、証明書ポリシーに関連する証明書拡張機能はPCAの必要性を取り除き、制約拡張機能は名前の従属規則の必要性を取り除きます。その結果、このドキュメントは次のようなより柔軟なアーキテクチャをサポートします。
(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）証明書パスは、ユーザー自身のドメイン内のCAの公開鍵、または階層の最上位の公開鍵で始まります。ユーザー自身のドメインにあるCAの公開鍵から始めると、特定の利点があります。一部の環境では、ローカルドメインが最も信頼されています。
(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の概念を置き換えます。アプリケーションは、PCAの事前の知識ではなく、証明書の内容に基づいて、証明書パスが許容可能かどうかを判断できます。これにより、証明書パス処理の自動化が可能になります。
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.
証明書が発行されると、その有効期間全体にわたって使用されることが期待されます。ただし、さまざまな状況により、有効期限が切れる前に証明書が無効になる場合があります。そのような状況には、名前の変更、サブジェクトとCA間の関連付けの変更（たとえば、従業員が組織での雇用を終了する）、対応する秘密鍵の侵害または侵害の疑いが含まれます。このような状況では、CAは証明書を取り消す必要があります。
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つの方法を定義しています。この方法では、各CAが定期的に証明書失効リスト（CRL）と呼ばれる署名されたデータ構造を発行します。 CRLは、CAまたはCRLの発行者によって署名され、パブリックリポジトリで自由に利用できる、失効した証明書を識別するタイムスタンプ付きリストです。失効した各証明書は、CRLで証明書のシリアル番号によって識別されます。証明書を使用するシステムが証明書を使用する場合（たとえば、リモートユーザーのデジタル署名を検証するため）、そのシステムは証明書の署名と有効性をチェックするだけでなく、適切に最新のCRLを取得し、証明書のシリアル番号がその上にないことをチェックしますCRL。 「適切に最近」の意味は、ローカルポリシーによって異なる場合がありますが、通常は、最近発行されたCRLを意味します。新しいCRLは定期的に発行されます（たとえば、毎時、毎日、または毎週）。失効の通知に続く次の更新の一部として、エントリがCRLに追加されます。エントリは、失効した証明書の有効期間を超えて発行された定期的にスケジュールされたCRLに表示されるまで、CRLから削除してはなりません（MUST NOT）。
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.
この失効方法の利点は、CRLが証明書自体とまったく同じ方法で、つまり信頼できないサーバーや信頼できない通信を介して配布される可能性があることです。
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の発行期間に制限されることです。たとえば、失効が今報告された場合、その失効は、現在発行されているすべてのCRLが更新されるまで、証明書を使用するシステムに確実に通知されません。 CRLが発行されます。
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つの目標です。ただし、このプロファイルではCRLの発行は必要ありません。オンライン失効通知をサポートするメッセージ形式とプロトコルは、他のPKIX仕様で定義されています。失効通知のオンラインメソッドは、X.509 CRLの代替として一部の環境で適用できる場合があります。オンライン失効チェックにより、失効レポートと証明書利用者への情報の配布との間の待ち時間が大幅に短縮される場合があります。 CAが失効レポートを真正かつ有効であると受け入れると、オンラインサービスへのクエリはすべて、失効による証明書検証の影響を正しく反映します。ただし、これらの方法では新しいセキュリティ要件が課せられます。証明書検証ツールはオンライン検証サービスを信頼する必要がありますが、リポジトリは信頼する必要はありません。
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.
クライアントシステムを使用して証明書とCRL（またはステータス情報）を証明書に配信するには、運用プロトコルが必要です。 LDAP、HTTP、FTP、およびX.500に基づく配布手順を含む、証明書およびCRL配信のさまざまな異なる手段のための規定が必要です。これらの機能をサポートする運用プロトコルは、他のPKIX仕様で定義されています。これらの仕様には、適切なMIMEコンテンツタイプの定義または参照を含む、上記のすべての運用環境をサポートするためのメッセージ形式と手順の定義が含まれる場合があります。
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ユーザーと管理エンティティ間のオンライン対話をサポートするには、管理プロトコルが必要です。たとえば、管理プロトコルは、キーペアが関連付けられているCAとクライアントシステム間、または相互に相互認証する2つのCA間で使用されます。管理プロトコルでサポートする必要がある可能性のある一連の機能には、次のものがあります。
(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）登録：これは、CAがそのユーザーの証明書を発行する前に、ユーザーが最初にCAに（直接または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）初期化：クライアントシステムが安全に動作する前に、インフラストラクチャの他の場所に格納されているキーと適切な関係を持つキーマテリアルをインストールする必要があります。たとえば、クライアントは、証明書パスの検証に使用するために、公開鍵および信頼できるCAの他の保証された情報で安全に初期化する必要があります。
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）証明書：これは、CAがユーザーの公開鍵の証明書を発行し、その証明書をユーザーのクライアントシステムに返すか、リポジトリにその証明書を投稿するプロセスです。
(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）鍵ペアの回復：オプションとして、ユーザークライアントの鍵素材（暗号化の目的で使用されるユーザーの秘密鍵など）は、CAまたは鍵バックアップシステムによってバックアップされます。ユーザーがこれらのバックアップされたキーマテリアルを回復する必要がある場合（たとえば、パスワードを忘れた、またはキーチェーンファイルを紛失した結果として）、そのような回復をサポートするためにオンラインプロトコル交換が必要になる場合があります。
(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）失効要求：権限のある人物が、証明書の失効を必要とする異常な状況をCAに通知します。
(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）相互認証：2つのCAが相互認証の確立に使用される情報を交換します。相互証明書は、あるCAから別のCAに発行される証明書で、証明書の発行に使用されるCA署名キーが含まれています。
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シリーズの仕様では、上記の機能をサポートする一連の標準メッセージフォーマットが定義されています。これらのメッセージには、さまざまな環境（電子メール、ファイル転送、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 v3証明書形式と、[X.509]で定義されている標準の証明書拡張に基づいています。 ISO / IECおよびITU-T文書では、1997バージョンのASN.1を使用しています。このドキュメントでは1988 ASN.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.
証明書は、幅広い相互運用性の目標と、運用と保証の要件のより広い範囲をカバーする、幅広いアプリケーションと環境で使用できます。このドキュメントの目的は、幅広い相互運用性と限定された特別な目的の要件を必要とする汎用アプリケーションの共通ベースラインを確立することです。特に、非公式のインターネット電子メール、IPsec、およびWWWアプリケーションに対するX.509 v3証明書の使用をサポートすることに重点が置かれます。
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証明書の基本的な構文は次のとおりです。署名の計算では、署名されるデータは、ASN.1識別符号化規則（DER）[X.690]を使用して符号化されます。 ASN.1 DERエンコーディングは、各要素のタグ、長さ、値のエンコーディングシステムです。
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
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
}
Version ::= INTEGER { v1(0), v2(1), v3(2) }
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
notBefore Time,
notAfter Time }
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
UniqueIdentifier ::= BIT STRING
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING }
The following items describe the X.509 v3 certificate for use in the Internet.
次の項目は、インターネットで使用するX.509 v3証明書について説明しています。
The Certificate is a SEQUENCE of three required fields. The fields are described in detail in the following subsections.
証明書は、3つの必須フィールドのシーケンスです。フィールドについては、次のサブセクションで詳しく説明します。
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で説明する拡張機能が含まれています。
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フィールドには、CAがこの証明書に署名するために使用する暗号アルゴリズムの識別子が含まれています。 [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 }
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）の署名フィールドと同じアルゴリズム識別子を含める必要があります。
The signatureValue field contains a digital signature computed upon the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded tbsCertificate is used as the input to the signature function. This signature value is encoded as a BIT STRING and included in the signature field. The details of this process are specified for each of algorithms listed in [PKIXALGS].
signatureValueフィールドには、ASN.1 DERでエンコードされたtbsCertificateで計算されたデジタル署名が含まれます。 ASN.1 DERでエンコードされたtbsCertificateは、署名関数への入力として使用されます。この署名値は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.
この署名を生成することにより、CAはtbsCertificateフィールドの情報の有効性を証明します。特に、CAは公開鍵マテリアルと証明書のサブジェクト間のバインディングを認証します。
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には、証明書のサブジェクトとそれを発行したCAに関連する情報が含まれています。すべてのTBSCertificateには、サブジェクトと発行者の名前、サブジェクトに関連付けられた公開鍵、有効期間、バージョン番号、シリアル番号が含まれています。オプションの一意の識別子フィールドが含まれる場合があります。このセクションの残りの部分では、これらのフィールドの構文とセマンティクスについて説明します。 TBSCertificateには通常、拡張機能が含まれています。インターネットPKIの拡張機能については、セクション4.2で説明します。
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が存在する場合、バージョンは2（値は1）である必要があります（SHOULD）。ただし、バージョンは3でもかまいません。基本フィールドのみが存在する場合、バージョンは1である必要があります（デフォルト値として証明書から値が省略されます）。ただし、バージョンは2または3の場合があります。
Implementations SHOULD be prepared to accept any version certificate. At a minimum, conforming implementations MUST recognize version 3 certificates.
実装は、バージョン証明書を受け入れるように準備する必要があります。少なくとも、準拠する実装はバージョン3の証明書を認識しなければなりません。
Generation of version 2 certificates is not expected by implementations based on this profile.
このプロファイルに基づく実装では、バージョン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.
シリアル番号は、CAによって各証明書に割り当てられた正の整数である必要があります。特定のCAによって発行された証明書ごとに一意である必要があります（つまり、発行者名とシリアル番号が一意の証明書を識別します）。 CAは、serialNumberを負でない整数にする必要があります。
Given the uniqueness requirements above, serial numbers can be expected to contain long integers. Certificate users MUST be able to handle serialNumber values up to 20 octets. Conformant CAs MUST NOT use serialNumber values longer than 20 octets.
上記の一意性の要件を考慮すると、シリアル番号には長整数が含まれることが予想されます。証明書ユーザーは、最大20オクテットまでのserialNumber値を処理できる必要があります。適合CAは、20オクテットを超えるserialNumber値を使用してはなりません（MUST NOT）。
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.
注：非準拠のCAは、負またはゼロのシリアル番号を持つ証明書を発行する場合があります。証明書ユーザーは、そのような証明書を適切に処理できるように準備する必要があります。
This field contains the algorithm identifier for the algorithm used by the CA to sign the certificate.
このフィールドには、CAが証明書に署名するために使用するアルゴリズムのアルゴリズム識別子が含まれています。
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.
このフィールドには、シーケンス証明書（セクション4.1.1.2）のsignatureAlgorithmフィールドと同じアルゴリズム識別子を含める必要があります。オプションのパラメータフィールドの内容は、識別されたアルゴリズムによって異なります。 [PKIXALGS]はサポートされる署名アルゴリズムをリストしますが、他の署名アルゴリズムもサポートされる場合があります。
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タイプの名前[X.501]として定義されています。名前は、次のASN.1構造によって定義されます。
Name ::= CHOICE {
RDNSequence }
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::=
SET OF AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY DEFINED BY AttributeType DirectoryString ::= CHOICE {
teletexString TeletexString (SIZE (1..MAX)),
printableString PrintableString (SIZE (1..MAX)),
universalString UniversalString (SIZE (1..MAX)),
utf8String UTF8String (SIZE (1..MAX)),
bmpString BMPString (SIZE (1..MAX)) }
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.
名前は、国名などの属性と、USなどの対応する値で構成される階層名を表します。コンポーネント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の選択肢として定義されます。 UTF8Stringエンコーディング[RFC 2279]が推奨されるエンコーディングであり、2003年12月31日以降に発行されたすべての証明書は、DirectoryStringのUTF8Stringエンコーディングを使用する必要があります（下記を除く）。その日まで、準拠するCAは、識別名を作成するときに、次のオプションから選択する必要があります。
(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として表現できます（MAY）。そして
(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）が満たされている場合でも、CAは文字列をUTF8Stringとして表すことを選択できます（MAY）。
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）CAは、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で述べたように、サブジェクトフィールドには、エンコーディングに関係なく、サブジェクトCAによって発行されたすべての証明書の発行者フィールドの内容と一致する空でない識別名を入力する必要があります。
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は下位互換性のために含まれており、新しいサブジェクトの証明書には使用しないでください。ただし、これらのタイプは、名前が以前に確立されている証明書で使用される場合があります。証明書ユーザーは、これらのタイプの証明書を受け取る準備ができている必要があります。
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.
さらに、多くの従来の実装では、ISO 8859-1文字セット（Latin1String）[ISO 8859-1]でエンコードされた名前をサポートしていますが、TeletexStringとしてタグ付けしています。 TeletexStringはISO 8859-1よりも大きな文字セットをエンコードしますが、一部の文字は異なる方法でエンコードします。実装は、両方のエンコーディングを処理できるように準備する必要があります。
As noted above, distinguished names are composed of attributes. This specification does not restrict the set of attribute types that may appear in names. However, conforming implementations MUST be prepared to receive certificates with issuer names containing the set of attribute types defined below. This specification RECOMMENDS support for additional attribute types.
上記のように、識別名は属性で構成されています。この仕様は、名前に表示される可能性のある属性タイプのセットを制限しません。ただし、以下に定義されている属性タイプのセットを含む発行者名を持つ証明書を受け取るために、準拠する実装を準備する必要があります。この仕様は、追加の属性タイプのサポートを推奨しています。
Standard sets of attributes have been defined in the X.500 series of specifications [X.520]. Implementations of this specification MUST be prepared to receive the following standard attribute types in issuer and subject (section 4.1.2.6) names:
属性の標準セットは、X.500シリーズの仕様[X.520]で定義されています。この仕様の実装は、発行者とサブジェクト（セクション4.1.2.6）の名前で次の標準属性タイプを受け取る準備ができている必要があります。
* country, * organization, * organizational-unit, * distinguished name qualifier, * state or province name, * common name (e.g., "Susan Housley"), and * serial number.
* 国、*組織、*組織単位、*識別名修飾子、*州または地方の名前、*共通名（「Susan Housley」など）、および*シリアル番号。
In addition, implementations of this specification SHOULD be prepared to receive the following standard attribute types in issuer and subject names:
さらに、この仕様の実装は、発行者名と件名で次の標準属性タイプを受け取る準備ができている必要があります。
* locality, * title, * surname, * given name, * initials, * pseudonym, and * generation qualifier (e.g., "Jr.", "3rd", or "IV").
* 地域、*タイトル、*姓、*名、*イニシャル、*仮名、*生成修飾子（「Jr。」、「3rd」、「IV」など）。
The syntax and associated object identifiers (OIDs) for these attribute types are provided in the ASN.1 modules in Appendix A.
これらの属性タイプの構文と関連オブジェクト識別子（OID）は、付録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 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.
さらに、この仕様の実装は、[RFC 2247]で定義されているように、domainComponent属性を受信できるように準備する必要があります。ドメインネームシステム（DNS）は、階層的なリソースラベルシステムを提供します。この属性は、DNS名に対応するDNを使用したい組織に便利なメカニズムを提供します。これは、代替名フィールドのdNSNameコンポーネントの代わりにはなりません。このような名前をDNS名に変換するための実装は必要ありません。この属性タイプの構文と関連するOIDは、付録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つの証明書の発行者識別名をCA証明書のサブジェクト名と照合することによって実行されます。
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シリーズの仕様で指定されている名前比較機能のサブセットのみが必要です。以下の名前比較ルールを実装するには、準拠する実装が必要です。
(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以外のタイプの属性値では、大文字と小文字が区別されます（これにより、バイナリオブジェクトとしての属性値の照合が可能になります）。
(c) attribute values in PrintableString are not case sensitive (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and
（c）PrintableStringの属性値では大文字と小文字が区別されません（たとえば、「Marianne Swanson」は「MARIANNE SWANSON」と同じです）。そして
(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）PrintableStringの属性値は、先頭と末尾の空白を削除し、1つ以上の連続する空白文字の内部部分文字列を単一の空白に変換した後に比較されます。
These name comparison rules permit a certificate user to validate certificates issued using languages or encodings unfamiliar to the certificate user.
これらの名前比較規則により、証明書ユーザーは、証明書ユーザーにとって馴染みのない言語またはエンコーディングを使用して発行された証明書を検証できます。
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シリーズで定義された比較アルゴリズムを使用できます。そのような実装は、上で指定されたアルゴリズムによって認識される名前一致のスーパーセットを認識します。
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.
証明書の有効期間は、CAが証明書のステータスに関する情報を維持することを保証する期間です。このフィールドは、証明書の有効期間が開始する日付（notBefore）と証明書の有効期間が終了する日付（notAfter）の2つの日付のシーケンスとして表されます。 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.
このプロファイルに準拠するCAは、常に2049年までの証明書の有効期限をUTCTimeとしてエンコードする必要があります。 2050以降の証明書の有効期限はGeneralizedTimeとしてエンコードする必要があります。
The validity period for a certificate is the period of time from notBefore through notAfter, inclusive.
証明書の有効期間は、notBeforeからnotAfterまでの期間です。
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秒の精度で指定されます。 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値はグリニッジ標準時（Zulu）で表現する必要があり、秒数がゼロの場合でも秒を含める必要があります（つまり、時間はYYMMDDHHMMSSZです）。適合システムは年フィールド（YY）を次のように解釈しなければなりません：
Where YY is greater than or equal to 50, the year SHALL be interpreted as 19YY; and
YYが50以上の場合、年は19YYとして解釈されるものとします。そして
Where YY is less than 50, the year SHALL be interpreted as 20YY.
YYが50未満の場合、年は20YYとして解釈されるものとします（SHALL）。
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値はグリニッジ標準時（Zulu）で表現する必要があり、秒数がゼロの場合でも秒を含める必要があります（つまり、時間はYYYYMMDDHHMMSSZです）。 GeneralizedTime値に小数秒を含めることはできません。
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拡張、あるいはその両方に含めることができます。サブジェクトがCAである場合（たとえば、4.2.1.10で説明されている基本制約拡張が存在し、cAの値がTRUEの場合）、サブジェクトフィールドには、内容に一致する空ではない識別名を入力する必要があります。サブジェクトCAによって発行されたすべての証明書の発行者フィールド（セクション4.1.2.4）。サブジェクトがCRL発行者である場合（たとえば、4.2.1.3で説明されているように、キー使用法拡張が存在し、cRLSignの値がTRUEである場合）、サブジェクトフィールドには、対象のCRL発行者によって発行されたすべてのCRLの発行者フィールド（セクション4.1.2.4）。サブジェクトの名前付け情報がsubjectAltName拡張にのみ存在する場合（たとえば、メールアドレスまたは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は、発行者名フィールドで定義されているように、1つのCAによって認証されたサブジェクトエンティティごとに一意である必要があります。 CAは、同じサブジェクトエンティティに対して同じDNを持つ複数の証明書を発行する場合があります。
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タイプの名前として定義されます。このフィールドの実装要件は、発行者フィールドに対して定義されたものです（セクション4.1.2.4）。タイプDirectoryStringの属性値をエンコードする場合、発行者フィールドのエンコードルールを実装する必要があります。この仕様の実装は、発行者フィールドに必要な属性タイプを含むサブジェクト名を受け取る準備ができていなければなりません。この仕様の実装は、発行者フィールドの推奨属性タイプを含むサブジェクト名を受け取る準備ができている必要があります。これらの属性タイプの構文と関連するオブジェクト識別子（OID）は、付録AのASN.1モジュールで提供されています。この仕様の実装は、これらの比較規則を使用して、なじみのない属性タイプ（名前の連鎖など）を処理できます（MAY）。これにより、サブジェクト名に見慣れない属性を持つ証明書を実装で処理できます。
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").
さらに、RFC 822名がサブジェクト識別名にEmailAddress属性として埋め込まれている従来の実装が存在します。 EmailAddressの属性値はタイプIA5Stringであり、PrintableString文字セットの一部ではない文字「@」を含めることができます。 EmailAddress属性値は大文字と小文字を区別しません（たとえば、「fanfeedback@redsox.com」は「FANFEEDBACK@REDSOX.COM」と同じです）。
Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name field (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.
電子メールアドレスで新しい証明書を生成する適合実装は、サブジェクトの別名フィールド（セクション4.2.1.7）でrfc822Nameを使用して、そのようなIDを記述する必要があります。以前の実装をサポートするためにサブジェクト識別名にEmailAddress属性を同時に含めることは非推奨ですが許可されています。
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、Diffie-Hellmanなど）を識別するために使用されます。アルゴリズムは、セクション4.1.1.2で指定されたAlgorithmIdentifier構造を使用して識別されます。サポートされているアルゴリズムのオブジェクト識別子と公開鍵の素材（公開鍵とパラメーター）をエンコードする方法は、[PKIXALGS]で指定されています。
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の場合、これらのフィールドは表示してはなりません（MUST NOT）。サブジェクトおよび発行者の一意の識別子は、サブジェクトおよび/または発行者の名前の経時的な再利用の可能性を処理するために証明書に存在します。このプロファイルは、名前が異なるエンティティで再利用されないこと、およびインターネット証明書が一意の識別子を利用しないことを推奨します。このプロファイルに準拠するCAは、一意の識別子を持つ証明書を生成してはなりません（SHOULD NOT）。このプロファイルに準拠するアプリケーションは、一意の識別子を解析できる必要があります（SHOULD）。
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つ以上の証明書拡張のシーケンスです。インターネットPKIの証明書拡張の形式と内容は、セクション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 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.
X.509 v3証明書に対して定義された拡張機能は、追加の属性をユーザーまたは公開鍵に関連付け、認証階層を管理するための方法を提供します。 X.509 v3証明書形式を使用すると、コミュニティはプライベート拡張を定義して、それらのコミュニティに固有の情報を伝達することもできます。証明書の各拡張は、クリティカルまたは非クリティカルとして指定されます。システムを使用する証明書は、認識できない重要な拡張機能に遭遇した場合、証明書を拒否する必要があります。ただし、重要ではない拡張機能は、認識されない場合は無視される場合があります。次のセクションでは、インターネット証明書で使用される推奨拡張機能と、情報の標準的な場所を示します。コミュニティは、追加の拡張機能を使用することを選択できます。ただし、一般的なコンテキストでの使用を妨げる可能性がある重要な証明書の拡張を採用する場合は注意が必要です。
Each extension includes an OID and an ASN.1 structure. When an extension appears in a certificate, the OID appears as the field extnID and the corresponding ASN.1 encoded structure is the value of the octet string extnValue. 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構造が含まれています。証明書に拡張が表示される場合、OIDはフィールドextnIDとして表示され、対応するASN.1エンコード構造はオクテット文字列extnValueの値です。証明書には、特定の拡張機能の複数のインスタンスを含めることはできません。たとえば、証明書に含まれる認証局キー識別子の拡張は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.
適合CAは、キー識別子（セクション4.2.1.1および4.2.1.2）、基本制約（セクション4.2.1.10）、キー使用法（セクション4.2.1.3）、および証明書ポリシー（セクション4.2.1.5）拡張をサポートする必要があります。 CAがサブジェクトフィールドに空のシーケンスを含む証明書を発行する場合、CAはサブジェクトの代替名拡張子をサポートする必要があります（セクション4.2.1.7）。残りの拡張機能のサポートはオプションです。適合CAは、この仕様で特定されていない拡張機能をサポートしてもよい（MAY）。証明書の発行者は、そのような拡張をクリティカルとしてマークすると相互運用性が阻害される可能性があることに注意してください。
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.
さらに、このプロファイルに準拠するアプリケーションは、権限とサブジェクトのキー識別子（セクション4.2.1.1および4.2.1.2）、およびポリシーマッピング（セクション4.2.1.6）拡張を認識する必要があります（SHOULD）。
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に関連付けられています。これらのOIDは、次で定義されるid-ceアークのメンバーです。
id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }
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.
認証パスの構築を容易にするために、authorityKeyIdentifier拡張のkeyIdentifierフィールドは、適合CAによって生成されるすべての証明書に含まれている必要があります。例外が1つあります。 CAが公開鍵を「自己署名」証明書の形で配布する場合、認証局の鍵識別子は省略してもよい（MAY）。自己署名証明書の署名は、証明書のサブジェクトの公開鍵に関連付けられた秘密鍵を使用して生成されます。 （これは、発行者が公開キーと秘密キーの両方を所有していることを証明します。）この場合、サブジェクトとオーソリティキーの識別子は同じですが、証明書パスの構築に必要なのはサブジェクトキーの識別子だけです。
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で説明しています。キー識別子が以前に確立されていない場合、この仕様では、keyIdentifiersを生成するためにこれらのメソッドのいずれかを使用することを推奨しています。鍵識別子が以前に確立されている場合、CAは以前に確立された識別子を使用する必要があります（SHOULD）。
This profile RECOMMENDS support for the key identifier method by all certificate users.
このプロファイルは、すべての証明書ユーザーによる鍵識別子方式のサポートを推奨しています。
This extension MUST NOT be marked critical.
この拡張機能は、重要としてマークしてはなりません。
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNames OPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
KeyIdentifier ::= OCTET STRING
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.
証明書パスの構築を容易にするために、この拡張はすべての準拠CA証明書、つまり、cAの値がTRUEである基本制約拡張（セクション4.2.1.10）を含むすべての証明書に出現する必要があります。サブジェクトキー識別子の値は、この証明書のサブジェクトによって発行された証明書の認証局キー識別子拡張（セクション4.2.1.1）のキー識別子フィールドに配置された値である必要があります。
For CA certificates, subject key identifiers SHOULD be derived from the public key or a method that generates unique values. Two common methods for generating key identifiers from the public key are:
CA証明書の場合、サブジェクトキー識別子は、公開キーまたは一意の値を生成するメソッドから派生する必要があります（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は、値0100の4ビットタイプフィールドで構成され、その後にBIT STRING subjectPublicKeyの値のSHA-1ハッシュの最下位60ビットが続きます（タグ、長さ、および未使用ビットの数を除く）文字列ビット）。
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.
エンドエンティティ証明書の場合、サブジェクトキー識別子拡張は、アプリケーションで使用される特定の公開キーを含む証明書を識別するための手段を提供します。エンドエンティティが複数の証明書を、特に複数のCAから取得した場合、サブジェクトキー識別子は、特定の公開キーを含む証明書のセットをすばやく識別する手段を提供します。アプリケーションが適切なエンドエンティティ証明書を識別するのを支援するために、この拡張はすべてのエンドエンティティ証明書に含まれる必要があります。
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.
エンドエンティティ証明書の場合、サブジェクトキー識別子は公開キーから派生する必要があります。公開鍵から鍵識別子を生成するための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.
キー識別子が以前に確立されていない場合、この仕様では、keyIdentifiersを生成するためにこれらのメソッドのいずれかを使用することを推奨しています。鍵識別子が以前に確立されている場合、CAは以前に確立された識別子を使用する必要があります（SHOULD）。
This extension MUST NOT be marked critical.
この拡張機能は、重要としてマークしてはなりません。
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
SubjectKeyIdentifier ::= KeyIdentifier
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.
鍵使用拡張機能は、証明書に含まれる鍵の目的（暗号化、署名、証明書の署名など）を定義します。使用制限は、複数の操作に使用できるキーを制限する場合に使用できます。たとえば、公開鍵証明書とCRL以外のオブジェクトの署名を検証するためだけにRSA鍵を使用する必要がある場合、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.
この拡張機能は、他の公開鍵証明書またはCRLのデジタル署名を検証するために使用される公開鍵を含む証明書に出現する必要があります。この拡張機能が表示されたら、それを重要とマークする必要があります。
id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
KeyUsage ::= BIT STRING {
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）またはCRL署名（ビット6）以外のセキュリティサービスをサポートするために、サブジェクトの公開キーをデジタル署名メカニズムと共に使用すると、digitalSignatureビットがアサートされます。多くの場合、デジタル署名メカニズムは、エンティティ認証および整合性のあるデータ発信元認証に使用されます。
The nonRepudiation bit is asserted when the subject public key is used to verify digital signatures used to provide a non-repudiation service which protects against the signing entity falsely denying some action, excluding certificate or CRL signing. In the case of later conflict, a reliable third party may determine the authenticity of the signed data.
nonRepudiationビットは、サブジェクトの公開鍵を使用して、署名エンティティが証明書またはCRL署名を除いて何らかのアクションを誤って拒否することから保護する否認防止サービスを提供するために使用されるデジタル署名を検証するときにアサートされます。後で競合が発生した場合、信頼できる第三者が署名されたデータの信頼性を判断することがあります。
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ビットがアサートされます。たとえば、キー管理にDiffie-Hellmanキーが使用される場合、このビットが設定されます。
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ビットがアサートされている場合は、基本制約拡張（セクション4.2.1.10）のcAビットもアサートされている必要があります。
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、Delta CRL、ARLなど）の署名の検証に使用されると、cRLSignビットがアサートされます。このビットは、CRLの署名を検証するために使用される証明書でアサートする必要があります。
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.
keyAgreementビットがない場合、encipherOnlyビットの意味は未定義です。 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.
keyAgreementビットがない場合、decipherOnlyビットの意味は未定義です。 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]で指定されています。
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.
この拡張機能は、インターネットPKI内では使用しないでください。このプロファイルに準拠するCAは、重要な秘密鍵の使用期間の延長を含む証明書を生成してはなりません（MUST NOT）。
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.
秘密鍵の使用期間の拡張により、証明書発行者は、秘密鍵に証明書とは異なる有効期間を指定できます。この拡張機能は、デジタル署名キーで使用するためのものです。この拡張機能は、notBeforeとnotAfterの2つのオプションコンポーネントで構成されています。証明書に関連付けられた秘密鍵は、2つのコンポーネントによってそれぞれ指定された時間の前または後にオブジェクトに署名するために使用してはなりません（SHOULD NOT）。このプロファイルに準拠するCAは、2つのコンポーネントの少なくとも1つが存在し、拡張が重要でない限り、秘密鍵の使用期間の拡張を伴う証明書を生成してはなりません。
Where used, notBefore and notAfter are represented as GeneralizedTime and MUST be specified and interpreted as defined in section 4.1.2.5.2.
notBeforeとnotAfterを使用する場合は、GeneralizedTimeとして表され、セクション4.1.2.5.2で定義されているように指定および解釈する必要があります。
id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 }
PrivateKeyUsagePeriod ::= SEQUENCE {
notBefore [0] GeneralizedTime OPTIONAL,
notAfter [1] GeneralizedTime OPTIONAL }
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.
証明書ポリシー拡張には、1つ以上のポリシー情報用語のシーケンスが含まれています。それぞれの用語は、オブジェクト識別子（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 }.
エンドエンティティ証明書では、これらのポリシー情報用語は、証明書が発行されたポリシーと、証明書が使用される目的を示します。 CA証明書では、これらのポリシー情報用語は、この証明書を含む証明書パスの一連のポリシーを制限します。 CAがこの証明書を含む証明書パスのポリシーのセットを制限したくない場合は、特別なポリシーanyPolicyを{2 5 29 32 0}の値でアサートできます（MAY）。
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.
特定のポリシー要件を持つアプリケーションには、それらが受け入れるポリシーのリストがあり、証明書のポリシーOIDをそのリストと比較することが期待されています。この拡張が重要である場合、パス検証ソフトウェアはこの拡張（オプションの修飾子を含む）を解釈できなければなりません、または証明書を拒否しなければなりません（MUST）。
To promote interoperability, this profile RECOMMENDS that policy information terms consist of only an OID. Where an OID alone is insufficient, this profile strongly recommends that use of qualifiers be limited to those identified in this section. When qualifiers are used with the special policy anyPolicy, they MUST be limited to the qualifiers identified in this section.
相互運用性を促進するために、このプロファイルでは、ポリシー情報の用語がOIDのみで構成されることを推奨しています。 OIDだけでは不十分な場合、このプロファイルでは、修飾子の使用をこのセクションで識別されたものに限定することを強くお勧めします。修飾子が特別なポリシーanyPolicyで使用される場合、それらはこのセクションで識別される修飾子に限定されなければなりません（MUST）。
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ポインター修飾子とユーザー通知修飾子です。
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ポインター修飾子には、CAによって発行されたCPS（Certification Practice Statement）へのポインターが含まれています。ポインタは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つのコピーのみを表示する必要があります。そのような重複を防ぐために、この修飾子は、他の組織に発行されたエンドエンティティ証明書とCA証明書にのみ存在する必要があります。
The user notice has two optional fields: the noticeRef field and the explicitText field.
ユーザー通知には、noticeRefフィールドとexplicitTextフィールドの2つのオプションフィールドがあります。
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フィールドを使用する場合は、組織に名前を付け、その組織が作成した特定のテキストステートメントを番号で識別します。たとえば、組織「CertsRU」と通知番号1を識別します。一般的な実装では、アプリケーションソフトウェアには、CertsRUの現在の通知セットを含む通知ファイルがあります。アプリケーションはファイルから通知テキストを抽出して表示します。メッセージは多言語である場合があり、ソフトウェアが独自の環境に特定の言語メッセージを選択できるようにする場合があります。
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文字ですが、一部の非準拠CAはこの制限を超えています。したがって、証明書ユーザーは200文字を超えるexplicitTextを適切に処理する必要があります（SHOULD）。
id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 }
certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
PolicyInformation ::= SEQUENCE {
policyIdentifier CertPolicyId,
policyQualifiers SEQUENCE SIZE (1..MAX) OF
PolicyQualifierInfo OPTIONAL }
CertPolicyId ::= OBJECT IDENTIFIER
PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId,
qualifier ANY 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 }
PolicyQualifierId ::=
OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
Qualifier ::= CHOICE {
cPSuri CPSuri,
userNotice UserNotice }
CPSuri ::= IA5String
UserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL,
explicitText DisplayText OPTIONAL}
NoticeReference ::= SEQUENCE {
organization 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)) }
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.
この拡張はCA証明書で使用されます。 1つ以上のOIDのペアをリストします。各ペアには、issuerDomainPolicyとsubjectDomainPolicyが含まれています。ペアリングは、発行元のCAが、発行元のCAのサブジェクトドメインポリシーと同等の発行者ドメインポリシーを検討することを示します。
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を受け入れる場合があります。ポリシーマッピングは、サブジェクトCAに関連付けられたポリシーのリストを定義します。これは、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）。ポリシーは、特別な値anyPolicy（セクション4.2.1.5）との間でマッピングしないでください。
This extension MAY be supported by CAs and/or applications, and it MUST be non-critical.
この拡張機能は、CAやアプリケーションによってサポートされる場合があり、重要ではない必要があります。
id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }
PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
issuerDomainPolicy CertPolicyId,
subjectDomainPolicy CertPolicyId }
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.
サブジェクトの別名の拡張により、追加のIDを証明書のサブジェクトにバインドできます。定義されたオプションには、インターネット電子メールアドレス、DNS名、IPアドレス、およびUniform Resource Identifier（URI）が含まれます。完全にローカルな定義を含む他のオプションが存在します。複数の名前形式、および各名前形式の複数のインスタンスが含まれる場合があります。そのようなIDを証明書にバインドする場合は常に、サブジェクトの別名（または発行者の別名）拡張を使用する必要があります。ただし、セクション4.1.2.4で説明されているように、DNS名は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.
サブジェクトの別名は公開鍵に確実にバインドされていると見なされるため、サブジェクトの別名のすべての部分はCAによって検証される必要があります。
Further, if the only subject identity included in the certificate is an alternative name form (e.g., an electronic mail address), then the subject distinguished name MUST be empty (an empty sequence), and the subjectAltName extension MUST be present. If the subject field contains an empty sequence, the subjectAltName extension MUST be marked critical.
さらに、証明書に含まれる唯一のサブジェクトIDが代替名形式（たとえば、電子メールアドレス）である場合、サブジェクト識別名は空（空のシーケンス）である必要があり、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の形式は、RFC 822 [RFC 822]で定義されている「addr-spec」です。 addr-specの形式は「local-part @ domain」です。 addr-specは、その前にフレーズ（一般名など）がなく、その後にコメント（括弧で囲まれたテキスト）がなく、「<」と「>」で囲まれていないことに注意してください。 RFC 822 addr-specでは大文字と小文字を使用できますが、大文字と小文字は区別されません。
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が含まれている場合、アドレスはRFC 791 [RFC 791]で指定されているように、「ネットワークバイトオーダー」でオクテット文字列に格納する必要があります。各オクテットの最下位ビット（LSB）は、ネットワークアドレスの対応するバイトのLSBです。 RFC 791で指定されているIPバージョン4の場合、オクテット文字列には正確に4つのオクテットが含まれている必要があります。 RFC 1883で指定されているIPバージョン6の場合、オクテット文字列には正確に16オクテットが含まれている必要があります[RFC 1883]。
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）に格納する必要があります。名前は、RFC 1034 [RFC 1034]で指定されている「優先名構文」に含まれている必要があります。ドメイン名では大文字と小文字を使用できますが、大文字と小文字は区別されません。さらに、文字列 ""は有効なドメイン名ですが、dNSNameが ""のsubjectAltName拡張は使用しないでください。最後に、インターネットメールアドレスのDNS表現の使用（wpolk@nist.govの代わりにwpolk.nist.gov）を使用してはなりません（MUST NOT）。そのようなIDは、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であってはならず（MUST）、[RFC 1738]で指定されているURL構文とエンコーディングルールに従う必要があります。名前には、スキーム（「http」や「ftp」など）とスキーム固有の部分の両方を含める必要があります。スキーム固有部分には、完全修飾ドメイン名またはIPアドレスをホストとして含める必要があります。
As specified in [RFC 1738], the scheme name is not case-sensitive (e.g., "http" is equivalent to "HTTP"). The host part is also not case-sensitive, but other components of the scheme-specific-part may be case-sensitive. When comparing URIs, conforming implementations MUST compare the scheme and host without regard to case, but assume the remainder of the scheme-specific-part is case sensitive.
[RFC 1738]で指定されているように、スキーム名では大文字と小文字が区別されません（たとえば、「http」は「HTTP」と同等です）。ホスト部分も大文字と小文字が区別されませんが、スキーマ固有部分の他のコンポーネントでは大文字と小文字が区別される場合があります。 URIを比較するとき、準拠する実装は大文字小文字を区別せずにスキームとホストを比較しなければなりません（MUST）が、スキーマ固有部分の残りは大文字と小文字が区別されると想定します。
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は、発行者名フィールドで定義されている1つのCAによって認証された各サブジェクトエンティティに対して一意である必要があります。 CAは、同じサブジェクトエンティティに対して同じDNを持つ複数の証明書を発行する場合があります。
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フィールドを使用して、追加の名前タイプを運ぶことができます（MAY）。名前の形式とセマンティクスは、type-idフィールドのOBJECT IDENTIFIERによって示されます。名前自体は、otherNameの値フィールドとして伝達されます。たとえば、Kerberos 5 [RFC 1510]形式の名前は、Kerberos 5プリンシパル名OIDと、領域とPrincipalNameのシーケンスを使用して、otherNameにエンコードできます。
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つのエントリが含まれている必要があります。サブジェクトフィールドとは異なり、適合CAは、空のGeneralNameフィールドを含むsubjectAltNamesで証明書を発行してはなりません（MUST NOT）。たとえば、rfc822NameはIA5Stringとして表されます。空の文字列は有効なIA5Stringですが、このようなrfc822Nameはこのプロファイルでは許可されていません。証明書パスを処理するときにこのような証明書に遭遇するクライアントの動作は、このプロファイルでは定義されていません。
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.
最後に、ワイルドカード文字を含むサブジェクトの別名のセマンティクス（たとえば、名前のセットのプレースホルダーとして）は、この仕様では扱われていません。特定の要件を持つアプリケーションは、そのような名前を使用できますが、それらはセマンティクスを定義する必要があります。
id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 }
SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName 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 }
OtherName ::= SEQUENCE {
type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id }
EDIPartyName ::= SEQUENCE {
nameAssigner [0] DirectoryString OPTIONAL,
partyName [1] DirectoryString }
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と同様に、この拡張機能は、インターネットスタイルのIDを証明書発行者に関連付けるために使用されます。発行者の代替名は、4.2.1.7のようにエンコードする必要があります。
Where present, this extension SHOULD NOT be marked critical.
存在する場合、この拡張機能はクリティカルとしてマークするべきではありません。
id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
IssuerAltName ::= GeneralNames
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 }
SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
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.
基本制約拡張は、証明書のサブジェクトがCAであるかどうか、およびこの証明書を含む有効な証明書パスの最大の深さを識別します。
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に属しているかどうかを示します。 cAブール値がアサートされていない場合、キー使用法拡張のkeyCertSignビットをアサートしてはなりません（MUST NOT）。
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.
pathLenConstraintフィールドは、cAブール値がアサートされ、キー使用拡張がkeyCertSignビットをアサートする場合にのみ意味があります（セクション4.2.1.3）。この場合、有効な証明書パスでこの証明書に続く可能性のある非自己発行の中間証明書の最大数を示します。サブジェクトと発行者のフィールドに表示されるDNが同一で空でない場合、証明書は自己発行されます。 （注：証明書パスの最後の証明書は中間証明書ではないため、この制限に含まれていません。通常、最後の証明書はエンドエンティティ証明書ですが、CA証明書でもかまいません。）pathLenConstraintがゼロの場合、有効な認証パスでは、あと1つの証明書しか使用できません。表示される場合、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.
この拡張は、証明書のデジタル署名の検証に使用される公開鍵を含むすべてのCA証明書で重要な拡張として表示される必要があります。この拡張は、証明書のデジタル署名の検証以外の目的でのみ使用される公開鍵を含むCA証明書の重要な拡張または非重要な拡張として表示される場合があります。このようなCA証明書には、CRLでデジタル署名を検証するためにのみ使用される公開鍵を含むものと、証明書登録プロトコルで使用される鍵管理公開鍵を含むものが含まれます。この拡張は、エンドエンティティ証明書でクリティカルまたは非クリティカルな拡張として表示される場合があります。
CAs MUST NOT include the pathLenConstraint field unless the cA boolean is asserted and the key usage extension asserts the keyCertSign bit.
CAは、cAブール値がアサートされ、キー使用拡張がkeyCertSignビットをアサートしない限り、pathLenConstraintフィールドを含めてはなりません（MUST NOT）。
id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
BasicConstraints ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located. Restrictions apply to the subject distinguished name and apply to subject alternative names. Restrictions apply only when the specified name form is present. If no name of the type is in the certificate, the certificate is acceptable.
CA証明書でのみ使用する必要がある名前制約拡張は、証明書パス内の後続の証明書のすべてのサブジェクト名が配置される必要がある名前空間を示します。制限は、サブジェクトの識別名およびサブジェクトの別名に適用されます。指定された名前形式が存在する場合にのみ、制限が適用されます。タイプの名前が証明書にない場合、証明書は受け入れ可能です。
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.)
名前の制約は、発行者とサブジェクトが同一である証明書には適用されません（証明書がパスの最終証明書でない限り）。 （これにより、名前の制約を使用するCAが自己発行の証明書を使用してキーのロールオーバーを実装するのを防ぐことができます。）
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フィールドの制限に一致する名前は、allowedSubtreesに表示される情報に関係なく無効です。この拡張は重要である必要があります。
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の場合、制約は名前のホスト部分に適用されます。制約はホストまたはドメインを指定してもよい（MAY）。例は「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
タイプEmailAddressの属性のサブジェクト識別名にRFC 822名が埋め込まれているレガシー実装が存在します（セクション4.1.2.6）。 rfc822の名前が制約されているが、
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名前制約を適用する必要があります。 EmailAddressのASN.1構文と対応するOIDは、付録Aで提供されています。
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形式の制限は、証明書のサブジェクトフィールドおよびタイプdirectoryNameのsubjectAltName拡張に適用する必要があります。 x400Address形式の制限は、タイプx400AddressのsubjectAltName拡張に適用する必要があります。
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形式の制限付きで証明書を発行するCAは、完全なISO DN名比較アルゴリズムの実装に依存してはいけません（SHOULD NOT）。これは、サブジェクトフィールドまたは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の構文は、セクション4.2.1.7で説明されているとおりである必要があり、特に名前の制約に対して次の追加が必要です。 IPv4アドレスの場合、generalNameのipAddressフィールドには、アドレス範囲[RFC 1519]を表すためにRFC 1519（CIDR）の形式でエンコードされた8オクテットが含まれている必要があります。 IPv6アドレスの場合、ipAddressフィールドには、同様にエンコードされた32オクテットが含まれている必要があります。たとえば、「クラスC」サブネット10.9.8.0の名前の制約は、CIDR表記10.9.8.0/255.255.255.0を表すオクテット0A 09 08 00 FF FF FF 00として表されます。
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 }
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
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.
ポリシー制約拡張は、CAに発行された証明書で使用できます。ポリシー制約拡張は、パス検証を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.
preventPolicyMappingフィールドが存在する場合、値は、ポリシーマッピングが許可されなくなるまでにパスに表示される可能性のある追加の証明書の数を示します。たとえば、値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.
適合CAは、ポリシーの制約が空のシーケンスである証明書を発行してはなりません（MUST NOT）。つまり、inhibitPolicyMappingフィールドまたはrequireExplicitPolicyフィールドの少なくとも1つが存在する必要があります。空のポリシー制約フィールドが発生したクライアントの動作は、このプロファイルでは対処されていません。
This extension MAY be critical or non-critical.
この拡張機能は、重要な場合と重要でない場合があります。
id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX)
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: id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER
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勧告X.660 [X.660]に従って割り当てられなければなりません（MUST）。
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.
CAがそのようなアプリケーションを満たすために拡張キーの使用法を含んでいるが、キーの使用法を制限したくない場合、CAは特別な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 }
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
-- TLS WWW client authentication
-- Key usage bits that may be consistent: digitalSignature
-- and/or keyAgreement id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
-- Signing of downloadable executable code
-- Key usage bits that may be consistent: digitalSignature
id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
-- E-mail protection
-- Key usage bits that may be consistent: digitalSignature,
-- nonRepudiation, and/or (keyEncipherment or keyAgreement)
id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
-- Binding the hash of an object to a time
-- Key usage bits that may be consistent: 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
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情報の取得方法を識別します。拡張は重要ではありませんが、このプロファイルはCAおよびアプリケーションによるこの拡張のサポートを推奨します。 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のシーケンスです。 DistributionPointは3つのフィールドで構成され、各フィールドはオプションです：distributionPoint、reasons、およびcRLIssuer。これらの各フィールドはオプションですが、DistributionPointは理由フィールドのみで構成してはなりません（MUST NOT）。 distributionPointまたはcRLIssuerのいずれかが存在する必要があります。証明書発行者がCRL発行者でない場合、cRLIssuerフィールドが存在し、CRL発行者の名前が含まれている必要があります。証明書の発行者がCRLの発行者でもある場合は、cRLIssuerフィールドを省略し、distributionPointフィールドを存在させる必要があります。 distributionPointフィールドが省略されている場合、cRLIssuerが存在し、CRLが配置されているX.500またはLDAPディレクトリエントリに対応する名前を含める必要があります。
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.
distributionPointフィールドが存在する場合、一般的な名前のシーケンスまたは単一の値nameRelativeToCRLIssuerのいずれかが含まれます。 cRLDistributionPoints拡張にタイプURIの一般名が含まれている場合、次のセマンティクスを想定する必要があります。URIは、関連する理由による現在のCRLへのポインターであり、関連するcRLIssuerによって発行されます。 URIに期待される値は、4.2.1.7で定義されたものです。他の値の処理規則は、この仕様では定義されていません。
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を取得するための異なるメカニズムを示します。たとえば、同じCRLをLDAPとHTTPの両方で取得できます。
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に複数の識別名が含まれている場合、DistributionPointNameはnameRealtiveToCRLIssuer代替を使用してはなりません（MUST NOT）。
If the DistributionPoint omits the reasons field, the CRL MUST include revocation information for all reasons.
DistributionPointが理由フィールドを省略した場合、CRLはすべての理由で失効情報を含める必要があります。
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には少なくとも1つのX.500識別名（DN）を含める必要があり、他の名前形式も含めることができます（MAY）。 cRLIssuerはCRL発行者名と比較されるため、X.501タイプの名前は、証明書の発行者名フィールドのエンコーディングルールに従う必要があります（セクション4.1.2.4）。
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 }
CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
DistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
reasons [1] ReasonFlags OPTIONAL,
cRLIssuer [2] GeneralNames OPTIONAL }
DistributionPointName ::= CHOICE {
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) }
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.
すべてのポリシーの禁止の拡張は、CAに発行された証明書で使用できます。いずれかのポリシーの禁止は、値{2 5 29 32 0}を持つ特別なanyPolicy OIDが、他の証明書ポリシーの明示的な一致とは見なされないことを示します。この値は、anyPolicyが許可されなくなるまでにパスに表示される可能性のある追加の証明書の数を示します。たとえば、値が1の場合、anyPolicyは、この証明書のサブジェクトによって発行された証明書では処理できるが、パス内の追加の証明書では処理できないことを示します。
This extension MUST be critical.
この拡張は重要である必要があります。
id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }
InhibitAnyPolicy ::= SkipCerts
SkipCerts ::= INTEGER (0..MAX)
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拡張は、Delta 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 }
FreshestCRL ::= CRLDistributionPoints
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つの拡張機能を定義します。これらの拡張機能を使用して、アプリケーションを発行CAまたはサブジェクトに関するオンライン情報に誘導できます。情報は複数の形式で利用できる場合があるため、各拡張は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.
オブジェクト識別子がプライベート拡張に定義されています。プライベート拡張に関連付けられたオブジェクト識別子は、arc id-pkix内のarc id-peの下で定義されます。インターネットPKI用に定義された将来の拡張機能も、arc id-peの下で定義されることが期待されています。
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
id-pe OBJECT IDENTIFIER ::= { id-pkix 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.
機関情報アクセス拡張機能は、拡張機能が表示される証明書の発行者のCA情報およびサービスにアクセスする方法を示します。情報とサービスには、オンライン検証サービスとCAポリシーデータが含まれる場合があります。 （CRLの場所はこの拡張機能では指定されていません。その情報はcRLDistributionPoints拡張機能によって提供されます。）この拡張機能はエンドエンティティまたはCA証明書に含めることができ、重要ではない必要があります。
id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
AuthorityInfoAccessSyntax ::=
SEQUENCE SIZE (1..MAX) OF AccessDescription
AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER,
accessLocation GeneralName }
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 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.
This profile defines two accessMethod OIDs: id-ad-caIssuers and id-ad-ocsp.
このプロファイルは、id-ad-caIssuersとid-ad-ocspの2つのaccessMethod OIDを定義します。
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.
id-ad-caIssuers OIDは、追加情報に、この拡張機能を含む証明書を発行したCAよりも上位の証明書を発行したCAがリストされている場合に使用されます。参照されるCA発行者の説明は、証明書ユーザーが信頼するポイントで終了する証明書パスの選択において、証明書ユーザーを支援することを目的としています。
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.
id-ad-caIssuersがaccessMethodとして表示される場合、accessLocationフィールドは、参照される説明サーバーと、参照される説明を取得するためのアクセスプロトコルを記述します。 accessLocationフィールドはGeneralNameとして定義され、いくつかの形式をとることができます。情報がhttp、ftp、またはldapを介して入手できる場合、accessLocationはuniformResourceIdentifierである必要があります。情報がディレクトリアクセスプロトコル（DAP）を介して利用できる場合、accessLocationはdirectoryNameである必要があります。そのdirectoryNameのエントリには、crossCertificatePair属性にCA証明書が含まれています。電子メールで情報を入手できる場合、accessLocationはrfc822Nameである必要があります。他のid-ad-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].
id-ad-ocsp OIDは、この拡張を含む証明書の失効情報がオンライン証明書ステータスプロトコル（OCSP）[RFC 2560]を使用して入手できる場合に使用されます。
When id-ad-ocsp appears as accessMethod, the accessLocation field is the location of the OCSP responder, using the conventions defined in [RFC 2560].
id-ad-ocspがaccessMethodとして表示される場合、accessLocationフィールドは、[RFC 2560]で定義された規則を使用したOCSPレスポンダの場所です。
Additional access descriptors may be defined in other PKIX specifications.
追加のアクセス記述子は、他のPKIX仕様で定義できます。
The subject information access extension indicates how to access information and services for the subject of the certificate in which the extension appears. When the subject is a CA, information and services may include certificate validation services and CA policy data. When the subject is an end entity, the information describes the type of services offered and how to access them. In this case, the contents of this extension are defined in the protocol specifications for the suported services. This extension may be included in subject or CA certificates, and it MUST be non-critical.
サブジェクト情報アクセス拡張機能は、拡張機能が表示される証明書のサブジェクトの情報とサービスにアクセスする方法を示します。サブジェクトがCAの場合、情報とサービスには、証明書検証サービスとCAポリシーデータが含まれる場合があります。サブジェクトがエンドエンティティである場合、情報は提供されるサービスのタイプとそれらへのアクセス方法を説明します。この場合、この拡張機能の内容は、サポートされているサービスのプロトコル仕様で定義されています。この拡張機能は、サブジェクトまたはCA証明書に含まれる場合があり、重要ではない必要があります。
id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
SubjectInfoAccessSyntax ::=
SEQUENCE SIZE (1..MAX) OF AccessDescription
AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER,
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.
このプロファイルは、サブジェクトがCAである場合に使用される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.
id-ad-caRepository OIDは、サブジェクトがCAである場合に使用され、その証明書とCRL（発行されている場合）をリポジトリで公開します。 accessLocationフィールドはGeneralNameとして定義され、いくつかの形式をとることができます。情報がhttp、ftp、またはldapを介して入手できる場合、accessLocationはuniformResourceIdentifierである必要があります。情報がディレクトリアクセスプロトコル（dap）を介して利用できる場合、accessLocationはdirectoryNameである必要があります。電子メールで情報を入手できる場合、accessLocationはrfc822Nameである必要があります。他の名前形式のaccessLocation（accessMethodがid-ad-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 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.
id-ad-timeStamping OIDは、サブジェクトが[PKIXTSA]で定義されているタイムスタンププロトコルを使用してタイムスタンプサービスを提供するときに使用されます。タイムスタンプサービスがhttpまたはftp経由で利用できる場合、accessLocationはuniformResourceIdentifierである必要があります。タイムスタンプサービスが電子メールで利用できる場合、accessLocationはrfc822Nameである必要があります。 TCP / IPを使用してタイムスタンプサービスを利用できる場合は、dNSNameまたはipAddressの名前形式を使用できます。他の名前形式のaccessLocation（accessMethodがid-ad-timeStampingの場合）のセマンティクスは、この仕様では定義されていません。
Additional access descriptors may be defined in other PKIX specifications.
追加のアクセス記述子は、他のPKIX仕様で定義できます。
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 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.
CRLは、幅広い相互運用性の目標と、さらに幅広い運用要件と保証要件をカバーする、幅広いアプリケーションと環境で使用できます。このプロファイルは、幅広い相互運用性を必要とする汎用アプリケーションの共通のベースラインを確立します。プロファイルは、すべてのCRLで期待できる一連の情報を定義します。また、プロファイルは、頻繁に使用される属性の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発行者はCRLを発行します。一般に、CRL発行者はCAです。 CAはCRLを発行して、発行した証明書に関するステータス情報を提供します。ただし、CAはこの責任を別の信頼できる機関に委任する場合があります。 CRL発行者が証明書を発行したCAでない場合は常に、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に表示できる証明書のセットです。たとえば、スコープは「CA Xによって発行されたすべての証明書」、「CA Xによって発行されたすべてのCA証明書」、「鍵の侵害およびCAの侵害の理由で取り消されたCA Xによって発行されたすべての証明書」、または「ボルダーにあるNISTの従業員に発行されたすべての証明書」など、任意のローカル情報に基づく証明書のセット。
A complete CRL lists all unexpired certificates, within its scope, that have been revoked for one of the revocation reasons covered by the CRL scope. 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発行者は、デルタCRLも生成する場合があります。 Delta CRLは、参照された完全なCRLの発行以降に失効ステータスが変更されたスコープ内の証明書のみをリストします。参照される完全なCRLは、ベースCRLと呼ばれます。 Delta CRLのスコープは、それが参照するベースCRLと同じである必要があります。
This profile does not define any private Internet CRL extensions or CRL entry extensions.
このプロファイルは、プライベートインターネットCRL拡張またはCRLエントリ拡張を定義しません。
Environments with additional or special purpose requirements may build on this profile or may replace it.
追加または特別な目的の要件がある環境は、このプロファイルに基づいて構築することも、置き換えることもできます。
Conforming CAs are not required to issue CRLs if other revocation or certificate status mechanisms are provided. 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.
他の失効メカニズムまたは証明書ステータスメカニズムが提供されている場合、適合CAはCRLを発行する必要はありません。 CRLが発行される場合、CRLはバージョン2のCRLである必要があり、次のCRLが発行される日付をnextUpdateフィールド（セクション5.1.2.5）に含め、CRL番号拡張（セクション5.2.3）を含め、権限キー識別子拡張（セクション5.2.1）。 CRLをサポートする適合アプリケーションは、1つのCAによって発行されたすべての証明書の失効情報を提供するバージョン1とバージョン2の両方の完全なCRLを処理する必要があります。適合アプリケーションは、Delta CRL、間接CRL、または1つのCAによって発行されたすべての証明書以外のスコープを持つ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.1 DERエンコードされます。 ASN.1 DERエンコーディングは、各要素のタグ、長さ、値のエンコーディングシステムです。
CertificateList ::= SEQUENCE {
tbsCertList TBSCertList,
signatureAlgorithm AlgorithmIdentifier,
signatureValue 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] EXPLICIT Extensions OPTIONAL
-- if present, MUST be v2
}
-- Version, Time, CertificateSerialNumber, and Extensions -- are all defined in the ASN.1 in section 4.1
-バージョン、時間、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の使用について説明します。
The CertificateList is a SEQUENCE of three required fields. The fields are described in detail in the following subsections.
CertificateListは、3つの必須フィールドのシーケンスです。フィールドについては、次のサブセクションで詳しく説明します。
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エントリ拡張のシーケンスによって定義されます。
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フィールドには、CRL発行者がCertificateListに署名するために使用するアルゴリズムのアルゴリズム識別子が含まれています。フィールドのタイプはAlgorithmIdentifierであり、セクション4.1.1.2で定義されています。 [PKIXALGS]は、この仕様でサポートされているアルゴリズムを示していますが、他の署名アルゴリズムもサポートされている場合があります。
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）の署名フィールドと同じアルゴリズム識別子を含める必要があります。
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.1 DERエンコードされたtbsCertListで計算されたデジタル署名が含まれます。 ASN.1 DERでエンコードされた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発行者でもあるCAは、1つの秘密鍵を使用して証明書とCRLにデジタル署名することも、別の秘密鍵を使用して証明書とCRLにデジタル署名することもできます（MAY）。個別の秘密鍵を使用する場合、これらの秘密鍵に関連付けられている各公開鍵は、個別の証明書に配置されます。1つは鍵使用法拡張でkeyCertSignビットが設定され、もう1つは鍵使用法拡張でcRLSignビットが設定されます（セクション4.2.1.3）。個別の秘密鍵が使用される場合、CAによって発行された証明書には1つの認証局鍵IDが含まれ、対応するCRLには異なる認証局鍵IDが含まれます。証明書署名とCRL署名の検証に個別のCA証明書を使用すると、セキュリティ特性が向上します。ただし、アプリケーションに負担がかかり、相互運用性が制限される可能性があります。多くのアプリケーションが認証パスを構築し、次に認証パスを検証します（セクション6）。次に、CRLチェックでは、CAのCRL署名検証証明書用に個別の証明書パスを構築して検証する必要があります。 CRLチェックを実行するアプリケーションは、証明書とCRLが同じCA秘密鍵でデジタル署名されている場合、証明書パス検証をサポートする必要があります。これらのアプリケーションは、証明書とCRLが異なるCA秘密鍵でデジタル署名されている場合、証明書パス検証をサポートする必要があります（SHOULD）。
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 has issued. The profile requires conforming CRL issuers to use the CRL number and authority key identifier CRL extensions in all CRLs issued.
オプションのフィールドには、失効した証明書とCRL拡張のリストが含まれます。失効した証明書のリストは、CAが発行した有効期限が切れていない証明書をCAが失効していない場合をサポートするためにオプションです。このプロファイルでは、準拠するCRL発行者が、発行されたすべてのCRLでCRL番号と認証局キー識別子のCRL拡張を使用する必要があります。
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です）。
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]は、インターネットPKIで使用される最も一般的な署名アルゴリズムのOIDをリストします。
This field MUST contain the same algorithm identifier as the signatureAlgorithm field in the sequence CertificateList (section 5.1.1.2).
このフィールドには、シーケンスCertificateList（セクション5.1.1.2）のsignatureAlgorithmフィールドと同じアルゴリズム識別子を含める必要があります。
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に署名して発行したエンティティを識別します。発行者IDは、発行者名フィールドに保持されます。代替名の形式は、issuerAltName拡張機能にも表示される場合があります（セクション5.2.2）。発行者名フィールドには、X.500識別名（DN）を含める必要があります。発行者名フィールドはX.501タイプの名前として定義されており、証明書の発行者名フィールドのエンコードルールに従う必要があります（セクション4.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年までの日付のthisUpdateをUTCTimeとしてエンコードする必要があります。このプロファイルに準拠するCRL発行者は、2050年以降の日付のthisUpdateをGeneralizedTimeとしてエンコードする必要があります。
Where encoded as UTCTime, thisUpdate MUST be specified and interpreted as defined in section 4.1.2.5.1. Where encoded as GeneralizedTime, thisUpdate MUST be specified and interpreted as defined in section 4.1.2.5.2.
UTCTimeとしてエンコードされる場合、thisUpdateはセクション4.1.2.5.1の定義に従って指定および解釈される必要があります。 GeneralizedTimeとしてエンコードされている場合、thisUpdateはセクション4.1.2.5.2で定義されているように指定および解釈する必要があります。
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発行者は、以前のすべてのCRL以上のnextUpdate時間でCRLを発行する必要があります（SHOULD）。 nextUpdateは、UTCTimeまたはGeneralizedTimeとしてエンコードできます。
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発行者によって発行されたすべてのCRLにnextUpdateを含める必要があります。 TBSCertListのASN.1構文はこのフィールドをOPTIONALとして記述していることに注意してください。これは[X.509]で定義されているASN.1構造と一致しています。 nextUpdateを省略したCRLを処理するクライアントの動作は、このプロファイルでは指定されていません。
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年までの日付のnextUpdateをUTCTimeとしてエンコードする必要があります。このプロファイルに準拠するCRL発行者は、2050年以降の日付のnextizedをGeneralizedTimeとしてエンコードする必要があります。
Where encoded as UTCTime, nextUpdate MUST be specified and interpreted as defined in section 4.1.2.5.1. Where encoded as GeneralizedTime, nextUpdate MUST be specified and interpreted as defined in section 4.1.2.5.2.
UTCTimeとしてエンコードされている場合、nextUpdateはセクション4.1.2.5.1の定義に従って指定および解釈される必要があります。 GeneralizedTimeとしてエンコードされている場合、nextUpdateはセクション4.1.2.5.2の定義に従って指定および解釈する必要があります。
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.
取り消された証明書がない場合、取り消された証明書のリストは存在しない必要があります。それ以外の場合、失効した証明書はシリアル番号でリストされます。 CAによって取り消された証明書は、証明書のシリアル番号によって一意に識別されます。失効が発生した日付が指定されています。セクション5.1.2.4で説明されているように、revocationDateの時間を表現する必要があります。追加情報はCRLエントリ拡張で提供される場合があります。 CRLエントリの拡張については、セクション5.3で説明します。
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拡張のシーケンスです。 CRL拡張については、セクション5.2で説明します。
The extensions defined by ANSI X9, ISO/IEC, and ITU-T for X.509 v2 CRLs [X.509] [X9.55] provide methods for associating additional attributes with CRLs. The X.509 v2 CRL format also allows communities to define private extensions to carry information unique to those communities. Each extension in a CRL may be designated as critical or non-critical. A CRL validation MUST fail if it encounters a critical extension which it does not know how to process. However, an unrecognized non-critical extension may be ignored. The following subsections present those extensions used within Internet CRLs. Communities may elect to include extensions in CRLs which are not defined in this specification. However, caution should be exercised in adopting any critical extensions in CRLs which might be used in a general context.
X.509 v2 CRL [X.509] [X9.55]のANSI X9、ISO / IEC、およびITU-Tで定義された拡張機能は、追加の属性をCRLに関連付ける方法を提供します。 X.509 v2 CRL形式では、コミュニティがプライベート拡張を定義して、それらのコミュニティに固有の情報を伝達することもできます。 CRLの各拡張機能は、クリティカルまたは非クリティカルとして指定できます。 CRL検証は、処理方法がわからない重要な拡張機能に遭遇すると失敗する必要があります。ただし、認識されない重要でない拡張子は無視される場合があります。以下のサブセクションでは、インターネットCRL内で使用される拡張機能を示します。コミュニティーは、この仕様で定義されていない拡張機能をCRLに含めることを選択できます。ただし、一般的なコンテキストで使用される可能性のあるCRLの重要な拡張を採用する場合は注意が必要です。
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発行者は、発行されるすべてのCRLに認証局キー識別子（セクション5.2.1）とCRL番号（セクション5.2.3）拡張を含める必要があります。
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.
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.
Conforming CRL issuers MUST use the key identifier method, and MUST include this extension in all CRLs issued.
準拠するCRL発行者は、キー識別子メソッドを使用する必要があり、発行されるすべてのCRLにこの拡張を含める必要があります。
The syntax for this CRL extension is defined in section 4.2.1.1.
このCRL拡張の構文は、セクション4.2.1.1で定義されています。
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.
発行者の代替名の拡張により、追加のIDをCRLの発行者に関連付けることができます。定義されているオプションには、rfc822名（電子メールアドレス）、DNS名、IPアドレス、およびURIが含まれます。名前の複数のインスタンスと複数の名前フォームが含まれる場合があります。そのようなアイデンティティが使用されるときはいつでも、発行者の代替名の拡張子が使用されなければなりません。ただし、セクション4.1.2.4で説明されているように、DNS名はdomainComponent属性を使用して発行者フィールドで表すことができます。
The issuerAltName extension SHOULD NOT be marked critical.
issuerAltName拡張は、重要としてマークされるべきではありません。
The OID and syntax for this CRL extension are defined in section 4.2.1.8.
このCRL拡張のOIDと構文は、セクション4.2.1.8で定義されています。
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番号は、補完的な完全なCRLとデルタCRLの識別もサポートします。このプロファイルに準拠するCRL発行者は、すべてのCRLにこの拡張を含める必要があります。
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発行者が特定のスコープの完全なCRLに加えてデルタCRLを生成する場合、完全なCRLとデルタCRLは1つの番号付けシーケンスを共有する必要があります。 Delta CRLと、同じスコープをカバーする完全なCRLが同時に発行される場合、それらは同じCRL番号を持ち、同じ失効情報を提供する必要があります。つまり、Delta CRLと受け入れ可能な完全なCRLの組み合わせは、同時に発行された完全な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発行者が2つのCRL（2つの完全なCRL、2つのデルタCRL、または完全なCRLとデルタCRL）を異なる時点で同じスコープに対して生成する場合、2つのCRLは同じCRL番号を持っていてはなりません。つまり、2つのCRLのこの更新フィールド（セクション5.1.2.4）が同一でない場合、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検証者は、最大20オクテットのCRLNumber値を処理できる必要があります。適合CRL発行者は、20オクテットを超えるCRLNumber値を使用してはならない（MUST NOT）。
id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
CRLNumber ::= INTEGER (0..MAX)
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.
Delta CRLインジケーターは、CRLがDelta CRLであることを識別する重要なCRL拡張です。 Delta CRLには、完全なCRLに表示されるすべての情報ではなく、以前に配布された失効情報の更新が含まれています。 Delta CRLを使用すると、環境によってはネットワークの負荷と処理時間を大幅に削減できます。 Delta CRLは通常、更新するCRLよりも小さいため、Delta CRLを取得するアプリケーションは、対応する完全なCRLを取得するアプリケーションよりも少ないネットワーク帯域幅を消費します。 CRL構造以外の形式で失効情報を保存するアプリケーションは、情報を再処理せずにローカルデータベースに新しい失効情報を追加できます。
The delta CRL indicator extension contains the single value of type BaseCRLNumber. The CRL number identifies the CRL, complete for a given scope, that was used as the starting point in the generation of this delta CRL. A conforming CRL issuer MUST publish the referenced base CRL as a complete CRL. The delta CRL contains all updates to the revocation status for that same scope. The combination of a delta CRL plus the referenced base CRL is equivalent to a complete CRL, for the applicable scope, at the time of publication of the delta CRL.
Delta CRLインジケーター拡張には、BaseCRLNumberタイプの単一の値が含まれます。 CRL番号は、このデルタCRLの生成の開始点として使用された、特定のスコープに対して完全なCRLを識別します。適合CRL発行者は、参照されたベースCRLを完全なCRLとして公開する必要があります。 Delta CRLには、同じスコープの失効ステータスに対するすべての更新が含まれています。 Delta CRLと参照されたベースCRLの組み合わせは、Delta CRLの公開時点での該当するスコープの完全なCRLと同等です。
When a conforming CRL issuer generates a delta CRL, the delta CRL MUST include a critical delta CRL indicator extension.
適合CRL発行者がDelta CRLを生成するとき、Delta CRLは重要なDelta CRLインジケーター拡張を含まなければなりません（MUST）。
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.
Delta CRLが発行される場合、それが参照するベースCRLによってカバーされたのと同じ一連の理由と同じ一連の証明書をカバーする必要があります。つまり、Delta CRLのスコープは、ベースとして参照される完全なCRLのスコープと同じである必要があります。参照されているベースCRLおよびデルタCRLは、発行配布ポイント拡張を省略するか、同一の発行配布ポイント拡張を含んでいる必要があります。さらに、CRL発行者は、同じ秘密キーを使用して、Delta 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.
デルタCRLをサポートするアプリケーションは、そのスコープのデルタ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.
Delta CRLが完全なCRLまたはローカルで構築されたCRLと組み合わされると、結果としてローカルで構築されたCRLは、その構築で使用されたDelta CRLにあるCRL番号拡張で指定されたCRL番号を持ちます。さらに、結果としてローカルに構築されたCRLには、構築に使用されたDelta CRLの対応するフィールドで指定されたthisUpdateおよびnextUpdate時間があります。さらに、ローカルで構築されたCRLは、Delta CRLから発行配布ポイントを継承します。
A complete CRL and a delta CRL MAY be combined if the following four conditions are satisfied:
完全なCRLとDelta CRLは、次の4つの条件が満たされた場合に組み合わせることができます：
(a) The complete CRL and delta CRL have the same issuer.
（a）完全なCRLとDelta 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とDelta CRLのスコープは同じです。次のいずれかの条件が満たされている場合、2つのCRLのスコープは同じです。
(1) The issuingDistributionPoint extension is omitted from both the complete CRL and the delta CRL.
（1）isingDistributionPoint拡張は、完全なCRLとDelta CRLの両方から省略されています。
(2) The issuingDistributionPoint extension is present in both the complete CRL and the delta CRL, and the values for each of the fields in the extensions are the same in both CRLs.
（2）issueDistributionPoint拡張は、完全なCRLとデルタCRLの両方に存在し、拡張の各フィールドの値は両方のCRLで同じです。
(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番号が、Delta 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) 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.
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発行者は、Delta CRLと適切な完全なCRLの組み合わせが現在の失効ステータスを正確に反映していることを確認する必要があります。 CRL発行者は、参照されたベースCRLの生成以降にステータスが変更されたDelta CRLのスコープ内の各証明書のDelta 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）証明書が有効であり、参照されたベースCRLまたは理由コードcertificateHoldを持つ後続の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 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で証明書が保留されていなかった場合でも、Delta CRLに理由コードremoveFromCRLを付けて証明書をリストすることが適切です。証明書がベースの後で、このDelta CRLの前に発行されたCRLで保留され、その後保留から解放された場合、証明書は失効理由removeFromCRLとともにDelta 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時間より前であり、証明書が参照されたベースCRLまたは後に発行されたCRLにある場合、オプションで理由コードremoveFromCRLを使用してデルタ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.
証明書失効通知が最初にDelta CRLに表示された場合、同じ有効範囲の次の完全なCRLが発行される前に、証明書の有効期間が期限切れになる可能性があります。この場合、失効通知がこのスコープの明示的に発行された完全なCRLの少なくとも1つに含まれるまで、失効通知は後続のすべてのデルタCRLに含まれている必要があります。
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.
Delta CRLをサポートするアプリケーションは、以前に発行された完全なCRLと最新のデルタCRLを組み合わせることにより、現在の完全なCRLを構築できる必要があります。 Delta CRLをサポートするアプリケーションは、以前にローカルで構築された完全なCRLと現在の差分CRLを組み合わせることにより、現在の完全なCRLを構築できる場合があります。現在の時刻がthisUpdateフィールドとnextUpdateフィールドに含まれている時刻の間にある場合、Delta CRLは現在のものであると見なされます。状況によっては、CRL発行者がnextUpdateフィールドで示される前に1つ以上のデルタCRLを発行する場合があります。特定のスコープで複数の現在のDelta CRLが検出された場合、アプリケーションは、thisUpdateの最新の値を持つものを最新のものと見なす必要があります（SHOULD）。
id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
BaseCRLNumber ::= CRLNumber
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がエンドエンティティ証明書のみ、CA証明書のみ、属性証明書のみの失効をカバーしているかどうかを示します。
or a limited set of reason codes. Although the extension is critical, conforming implementations are not required to support this extension.
または理由コードの限られたセット。拡張機能は重要ですが、この拡張機能をサポートするために準拠する実装は必要ありません。
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配布ポイントには、独自のキーペアはありません。 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が表示されない場合、配布ポイントにはすべての理由コードの失効が含まれている必要があります。 CAは、CRL配布ポイントを使用して、侵害と定期的な失効に基づいてCRLを分割することができます。この場合、理由コードkeyCompromise（1）、cACompromise（2）、およびaACompromise（8）による失効は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は、CRLの範囲内で、CRL発行者が発行した、失効したすべての失効した証明書のエントリを含んでいる必要があります（MUST）。
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の範囲にCRL発行者以外の機関が発行した証明書が含まれている場合、CRL発行者はindirectCRLブール値をアサートする必要があります。各エントリを担当する機関は、証明書発行者のCRLエントリ拡張（セクション5.3.4）で示されます。
id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
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 }
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情報を取得する方法を識別します。拡張は重要ではない必要があります。この拡張機能は、Delta CRLで使用してはなりません（MUST NOT）。
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で説明されています。ただし、このコンテキストでは、配布ポイントフィールドのみが意味を持ちます。理由とCRLIssuerフィールドは、このCRL拡張から省略されている必要があります。
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のDelta CRLが見つかる場所を提供します。これらのデルタCRLのスコープは、この完全なCRLのスコープと同じである必要があります。このCRL拡張の内容は、Delta CRLを見つけるためにのみ使用されます。内容はCRLまたは参照されたDelta CRLの検証には使用されません。セクション4.2.1.14で配布ポイントに対して定義されたエンコーディング規則は、この拡張機能に適用されます。
id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
FreshestCRL ::= CRLDistributionPoints
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 CRLの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発行者は、この情報が利用可能な場合はいつでも理由コード（セクション5.3.1）と無効日（セクション5.3.3）を含める必要があります（SHOULD）。
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エントリ拡張は、未指定（0）のreasonCode値を使用する代わりに、存在しない必要があります（SHOULD）。
id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 }
-- reasonCode ::= { CRLReason }
CRLReason ::= ENUMERATED {
unspecified (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
removeFromCRL (8),
privilegeWithdrawn (9),
aACompromise (10) }
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 }
holdInstructionCode ::= OBJECT IDENTIFIER
The following instruction codes have been defined. Conforming applications that process this extension MUST recognize the following instruction codes.
以下の命令コードが定義されています。この拡張機能を処理する適合アプリケーションは、次の命令コードを認識しなければなりません（MUST）。
holdInstruction OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(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}
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.
id-holdinstruction-callissuerに遭遇する適合アプリケーションは、証明書発行者を呼び出すか、証明書を拒否する必要があります。 id-holdinstruction-rejectに遭遇する適合アプリケーションは、証明書を拒否しなければなりません（MUST）。保留命令id-holdinstruction-noneは、意味的にはholdInstructionCodeがないことと同等であり、インターネットPKIではその使用が強く推奨されていません。
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エントリの失効日よりも早い場合があります。これは、CAが失効を処理した日付です。失効が最初にCRLのCRL発行者によって投稿されたとき、無効日は以前のCRLの発行日より前になる場合がありますが、失効日は以前のCRLの発行日より前であってはなりません。この情報が利用可能な場合は常に、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値はグリニッジ標準時（Zulu）で表現する必要があり、セクション4.1.2.5.2で定義されているように指定および解釈する必要があります。
id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
invalidityDate ::= GeneralizedTime
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 }
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エントリを証明書に正しく関連付けることができませんでした。この仕様は、実装がこの拡張を認識することを推奨します。
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 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.
インターネットPKIの証明書パス検証手順は、[X.509]で提供されるアルゴリズムに基づいています。証明書パス処理では、サブジェクトの識別名やサブジェクトの別名、サブジェクトの公開鍵の間のバインディングを検証します。バインドは、証明書利用者によって指定されたパスと入力を構成する証明書で指定された制約によって制限されます。基本的な制約とポリシーの制約の拡張により、認証パス処理ロジックで意思決定プロセスを自動化できます。
This section describes an algorithm for validating certification paths. Conforming implementations of this specification are not required to implement this algorithm, but MUST provide functionality equivalent to the external behavior resulting from this procedure. Any algorithm may be used by a particular implementation so long as it derives the correct result.
このセクションでは、証明書パスを検証するためのアルゴリズムについて説明します。このアルゴリズムの実装には、この仕様の準拠実装は必須ではありませんが、この手順から生じる外部動作と同等の機能を提供する必要があります。正しい結果が得られる限り、特定の実装で任意のアルゴリズムを使用できます。
In section 6.1, the text describes basic path validation. Valid paths begin with certificates issued by a trust anchor. The algorithm requires the public key of the CA, the CA's name, and any constraints upon the set of paths which may be validated using this key.
セクション6.1のテキストでは、基本的なパスの検証について説明しています。有効なパスは、トラストアンカーによって発行された証明書で始まります。アルゴリズムには、CAの公開鍵、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のトップCAになる可能性があります。検証者自身の証明書を発行したCA。またはネットワークPKI内の他のCA。パスの検証手順は、トラストアンカーの選択に関係なく同じです。さらに、さまざまなアプリケーションがさまざまなトラストアンカーに依存する場合や、トラストアンカーのセットのいずれかで始まるパスを受け入れる場合があります。
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つの特定のケースについて説明します。パスがいくつかの信頼できるCAの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.
セクション6.3では、CRLが証明書発行者が使用する失効メカニズムである場合に、証明書が失効しているか保留状態になっているかを判断するために必要な手順について説明します。
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パス処理のアルゴリズムについて説明しています。適合実装には、このアルゴリズムの外部動作と機能的に同等のX.509パス処理手順を含める必要があります。ただし、このアルゴリズムで処理される一部の証明書拡張機能のサポートは、準拠した実装ではオプションです。これらの拡張をサポートしないクライアントは、パス検証アルゴリズムの対応するステップを省略してもよい（MAY）。
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.
たとえば、クライアントはポリシーマッピング拡張機能をサポートする必要はありません。この拡張機能をサポートしないクライアントは、ポリシーマッピングが処理されるパス検証手順を省略してもよい（MAY）。サポートされていない重要な拡張が含まれている場合、クライアントは証明書を拒否する必要があることに注意してください。
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.
このセクションで説明するアルゴリズムは、現在の日付と時刻に関して証明書を検証します。適合実装は、過去のある時点に関する検証もサポートする場合があります。証明書の有効期間外の時間に関して証明書を検証するメカニズムは利用できないことに注意してください。
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;
(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）への入力として提供されます。
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の有効なポリシーツリーになります。それ以外の場合、結果はnullの有効なポリシーツリーになります。
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.
サブジェクトと発行者のフィールドに表示されるDNが同一で空でない場合、証明書は自己発行されます。一般に、パスを構成する証明書の発行者とサブジェクトは、証明書ごとに異なります。ただし、CAは自身に証明書を発行して、キーのロールオーバーや証明書ポリシーの変更をサポートする場合があります。パスの長さまたは名前の制約を評価するとき、これらの自己発行の証明書はカウントされません。
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.
このセクションでは、（1）初期化、（2）基本的な証明書処理、（3）次の証明書の準備、（4）ラップアップという4つの基本的な手順でアルゴリズムを示します。手順（1）と（4）は1回だけ実行されます。手順（2）は、パス内のすべての証明書に対して実行されます。手順（3）は、パス内の最終的な証明書を除くすべての証明書に対して実行されます。図2に、このアルゴリズムの高レベルのフローチャートを示します。
+-------+
| START |
+-------+
|
V
+----------------+
| Initialization |
+----------------+
|
+<--------------------+
| |
V |
+----------------+ |
| Process Cert | |
+----------------+ |
| |
V |
+================+ |
| IF Last Cert | |
| in Path | |
+================+ |
| | |
THEN | | ELSE |
V V |
+----------------+ +----------------+ |
| Wrap up | | Prepare for | |
+----------------+ | Next Cert | |
| +----------------+ |
V | |
+-------+ +--------------+
| STOP |
+-------+
Figure 2. Certification Path Processing Flowchart
図2.証明書パス処理フローチャート
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）現在の日付/時刻。
(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）user-initial-policy-set：証明書ユーザーが受け入れ可能なポリシーに名前を付ける証明書ポリシー識別子のセット。ユーザーが証明書ポリシーに関心がない場合、user-initial-policy-setには特別な値any-policyが含まれます。
(d) trust anchor information, describing a CA that serves as a trust anchor for the certification path. The trust anchor information includes:
（d）トラストアンカー情報。証明書パスのトラストアンカーとして機能するCAを記述します。トラストアンカー情報は次のとおりです。
(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）initial-policy-mapping-inhibit。証明書パスでポリシーマッピングが許可されているかどうかを示します。
(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）initial-explicit-policy。これは、パスがuser-initial-policy-set内の少なくとも1つの証明書ポリシーに対して有効でなければならないかどうかを示します。
(g) initial-any-policy-inhibit, which indicates whether the anyPolicy OID should be processed if it is included in a certificate.
（g）initial-any-policy-inhibit。証明書に含まれている場合、anyPolicy OIDを処理する必要があるかどうかを示します。
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 certificates in the chain that have been processed. If valid policies do not exist at this stage in the certification path validation, the tree is set to NULL. Once the tree is set to NULL, policy processing ceases.
（a）valid_policy_tree：オプションの修飾子を持つ証明書ポリシーのツリー。ツリーの各リーフは、証明書パス検証のこの段階での有効なポリシーを表します。証明書パス検証のこの段階で有効なポリシーが存在する場合、ツリーの深さは、チェーン内で処理された証明書の数と等しくなります。証明書パス検証のこの段階で有効なポリシーが存在しない場合、ツリーは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:
valid_policy_treeの各ノードには、有効なポリシー、関連付けられたポリシー修飾子のセット、1つ以上の予期されるポリシー値のセット、および重要度インジケーターの4つのデータオブジェクトが含まれています。ノードが深さxにある場合、ノードのコンポーネントには次のセマンティクスがあります。
(1) The valid_policy is a single policy OID representing a valid policy for the path of length x.
（1）valid_policyは、長さxのパスの有効なポリシーを表す単一のポリシーOIDです。
(2) The qualifier_set is a set of policy qualifiers associated with the valid policy in certificate x.
（2）qualifier_setは、証明書xの有効なポリシーに関連付けられたポリシー修飾子のセットです。
(3) The criticality_indicator indicates whether the certificate policy extension in certificate x was marked as critical.
（3）criticality_indicatorは、証明書xの証明書ポリシー拡張がクリティカルとしてマークされたかどうかを示します。
(4) The expected_policy_set contains one or more policy OIDs that would satisfy this policy in the certificate x+1.
（4）expected_policy_setには、証明書x + 1でこのポリシーを満たす1つ以上のポリシーOIDが含まれています。
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.
valid_policy_treeの初期値は、valid_policy anyPolicyを持つ単一ノード、空のqualifier_set、単一値anyPolicyを持つexpected_policy_set、およびFALSEのcriticality_indicatorです。このノードは深さがゼロであると見なされます。
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は、valid_policy_treeの初期状態のグラフィック表現です。追加の図では、この形式を使用して、パス処理中のvalid_policy_treeの変更を説明します。
+----------------+
| anyPolicy | <---- valid_policy
+----------------+
| {} | <---- qualifier_set
+----------------+
| FALSE | <---- criticality_indicator
+----------------+
| {anyPolicy} | <---- expected_policy_set
+----------------+
Figure 3. Initial value of the valid_policy_tree state variable (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.
図3. valid_policy_tree状態変数の初期値（b）allowed_subtrees：すべてのサブジェクト名が含まれるサブツリーのセットを定義する、名前タイプごとのルート名のセット（X.500識別名、電子メールアドレス、IPアドレスなど）証明書パス内の後続の証明書では、該当する必要があります。この変数には、名前タイプごとのセットが含まれます。識別名のセットの初期値は、すべての識別名のセットです。 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）exclude_subtrees：証明書パス内の後続の証明書のサブジェクト名が含まれない可能性があるサブツリーのセットを定義する、名前タイプごとのルート名のセット（X.500識別名、電子メールアドレス、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）explicit_policy：NULL以外のvalid_policy_treeが必要かどうかを示す整数。整数は、この要件が課される前に処理される、自己発行でない証明書の数を示します。設定すると、この変数は減少する可能性がありますが、増加することはできません。つまり、パス内の証明書でNULL以外のvalid_policy_treeが必要な場合、以降の証明書ではこの要件を削除できません。 initial-explicit-policyが設定されている場合、初期値は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）prevent_any-policy：anyPolicyポリシー識別子が一致と見なされるかどうかを示す整数。整数は、anyPolicy OIDが証明書でアサートされている場合に無視される前に処理される、自己発行でない証明書の数を示します。設定すると、この変数は減少する可能性がありますが、増加することはできません。つまり、パス内の証明書がanyPolicyの処理を禁止している場合、以降の証明書はそれを許可できません。 initial-any-policy-inhibitが設定されている場合、初期値は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）policy_mapping：ポリシーマッピングが許可されているかどうかを示す整数。整数は、ポリシーマッピングが禁止される前に処理される、自己発行でない証明書の数を示します。設定すると、この変数は減少する可能性がありますが、増加することはできません。つまり、パス内の証明書がポリシーマッピングが許可されていないことを指定している場合、それを後の証明書で上書きすることはできません。 initial-policy-mapping-inhibitが設定されている場合、初期値は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）working_public_key_algorithm：証明書の署名を検証するために使用されるデジタル署名アルゴリズム。 working_public_key_algorithmは、トラストアンカー情報で提供される信頼できる公開鍵アルゴリズムから初期化されます。
(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）working_public_key：証明書の署名を検証するために使用される公開鍵。 working_public_keyは、トラストアンカー情報で提供される信頼できる公開鍵から初期化されます。
(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）working_public_key_parameters：現在の公開鍵に関連付けられているパラメーター。これは、署名を検証するために必要になる場合があります（アルゴリズムによって異なります）。 working_public_key_parameters変数は、トラストアンカー情報で提供される信頼できる公開鍵パラメーターから初期化されます。
(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）working_issuer_name：チェーンの次の証明書で予期される発行者の識別名。 working_issuer_nameは、トラストアンカー情報で提供される信頼できる発行者に初期化されます。
(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）max_path_length：この整数はnに初期化され、パス内の非自己発行証明書ごとに減分され、CA証明書の基本制約拡張内のパス長制約フィールドの値に削減される場合があります。
Upon completion of the initialization steps, perform the basic certificate processing steps specified in 6.1.3.
初期化ステップが完了したら、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）証明書は、working_public_keyおよびworking_public_key_parametersを使用して、working_public_key_algorithmで署名されました。
(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) 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.
(4) The certificate issuer name is the working_issuer_name.
（4）証明書の発行者名は、working_issuer_nameです。
(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識別名のallowed_subtreesの1つに含まれていることを確認し、subjectAltName拡張の各代替名（クリティカルまたは非クリティカル）がその名前タイプのallowed_subtreesの1つに含まれていることを確認します。
(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) 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.
(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）証明書ポリシー拡張が証明書に存在し、valid_policy_treeが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）各ポリシーPが証明書ポリシー拡張のanyPolicyと等しくない場合は、P-OIDがポリシーPのOIDを示し、P-QがポリシーPの修飾子セットを示します。次の手順を順番に実行します。
(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）valid_policy_treeに深さi-1のノードが含まれ、P-OIDがexpected_policy_setにある場合、次のように子ノードを作成します。valid_policyをOID-Pに設定します。 qualifier_setをP-Qに設定し、expected_policy_setを{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.
たとえば、expected_policy_setが{Gold、White}である、深さがi-1のノードを持つvalid_policy_treeを考えます。証明書ポリシーGoldおよびSilverが証明書iの証明書ポリシー拡張に表示されると想定します。ゴールドポリシーは一致していますが、シルバーポリシーは一致していません。このルールは、Goldポリシーの深さiの子ノードを生成します。結果を図4に示します。
+-----------------+
| Red |
+-----------------+
| {} |
+-----------------+ node of depth i-1
| FALSE |
+-----------------+
| {Gold, White} |
+-----------------+
|
|
|
V
+-----------------+
| Gold |
+-----------------+
| {} |
+-----------------+ node of depth i
| uninitialized |
+-----------------+
| {Gold} |
+-----------------+
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) 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}.
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.
たとえば、valid_policyがanyPolicyである、深さがi-1のノードを持つvalid_policy_treeを考えます。証明書ポリシーGoldおよびSilverが証明書iの証明書ポリシー拡張に表示されると想定します。ゴールドポリシーには修飾子がありませんが、シルバーポリシーには修飾子Q-シルバーがあります。上記の（i）でゴールドとシルバーが一致しなかった場合、このルールは深さiの2つの子ノードを生成します（各ポリシーに1つ）。結果を図5に示します。
+-----------------+
| anyPolicy |
+-----------------+
| {} |
+-----------------+ node of depth i-1
| FALSE |
+-----------------+
| {anyPolicy} |
+-----------------+
/ \
/ \
/ \
/ \
+-----------------+ +-----------------+
| Gold | | Silver |
+-----------------+ +-----------------+
| {} | | {Q-Silver} |
+-----------------+ nodes of +-----------------+
| uninitialized | depth i | uninitialized |
+-----------------+ +-----------------+
| {Gold} | | {Silver} |
+-----------------+ +-----------------+
Figure 5. Processing unmatched policies when a leaf node specifies anyPolicy
Figure 5. Processing unmatched policies when a leaf node specifies 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に設定されたポリシーanyPolicyが含まれていて、（a）prevent_any-policyが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のvalid_policy_treeの各ノードについて、子ノードに表示されないexpected_policy_set（anyPolicyを含む）の各値について、次の値を持つ子ノードを作成します。valid_policyを期待される_policy_setの値に設定します親ノード。 qualifier_setをAP-Qに設定し、expected_policy_setをこのノードのvalid_policyの値に設定します。
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.
たとえば、expected_policy_setが{Gold、Silver}である、深さがi-1のノードを持つvalid_policy_treeを考えます。証明書iの証明書ポリシー拡張にanyPolicyが表示されているが、GoldとSilverは表示されていないとします。このルールは、各ポリシーに1つずつ、深さiの2つの子ノードを生成します。結果を図6に示します。
+-----------------+
| Red |
+-----------------+
| {} |
+-----------------+ node of depth i-1
| FALSE |
+-----------------+
| {Gold, Silver} |
+-----------------+
/ \
/ \
/ \
/ \
+-----------------+ +-----------------+
| Gold | | Silver |
+-----------------+ +-----------------+
| {} | | {} |
+-----------------+ nodes of +-----------------+
| uninitialized | depth i | uninitialized |
+-----------------+ +-----------------+
| {Gold} | | {Silver} |
+-----------------+ +-----------------+
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) 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.
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に示すvalid_policy_treeを考えてみます。 「X」でマークされている深さi-1の2つのノードには子がなく、削除されます。結果のツリーにこのルールを適用すると、「Y」でマークされた深度i-2のノードが削除されます。ルールを次のように適用しても、ノードは削除されず、この手順は完了です。
+-----------+
| | node of depth i-3
+-----------+
/ | \
/ | \
/ | \
+-----------+ +-----------+ +-----------+
| | | | | Y | nodes of
+-----------+ +-----------+ +-----------+ depth i-2
/ \ | |
/ \ | |
/ \ | |
+-----------+ +-----------+ +-----------+ +-----------+ nodes of
| | | X | | | | X | depth
+-----------+ +-----------+ +-----------+ +-----------+ i-1
| / | \
| / | \
| / | \
+-----------+ +-----------+ +-----------+ +-----------+ nodes of
| | | | | | | | depth
+-----------+ +-----------+ +-----------+ +-----------+ i
Figure 7. Pruning the valid_policy_tree
図7. valid_policy_treeのプルーニング
(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）証明書ポリシー拡張がクリティカルとしてマークされている場合は、深さiのすべてのノードのcriticality_indicatorをTRUEに設定します。証明書ポリシー拡張にクリティカルのマークが付けられていない場合は、深さiのすべてのノードのcriticality_indicatorをFALSEに設定します。
(e) If the certificate policies extension is not present, set the valid_policy_tree to NULL.
（e）証明書ポリシー拡張が存在しない場合は、valid_policy_treeをNULLに設定します。
(f) Verify that either explicit_policy is greater than 0 or the valid_policy_tree is not equal to NULL;
（f）explicit_policyが0より大きいか、valid_policy_treeが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にリストされている後処理手順を実行します。
To prepare for processing of certificate i+1, perform the following steps for certificate i:
証明書i + 1の処理を準備するには、証明書iに対して次の手順を実行します。
(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）ポリシーマッピング拡張が存在する場合、ポリシーマッピング拡張内の発行者ドメインポリシー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) 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.
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:
valid_policy_treeの深さiのノードにvalid_policyのID-Pがないが、valid_policyがanyPolicyの深さiのノードがある場合、次のように、anyPolicyのvalid_policyを持つ深さi-1のノードの子ノードを生成します。続く：
(i) set the valid_policy to ID-P;
（i）valid_policyをID-Pに設定します。
(ii) set the qualifier_set to the qualifier set of the policy anyPolicy in the certificate policies extension of certificate i;
（ii）qualifier_setを、証明書iの証明書ポリシー拡張のポリシーanyPolicyの修飾子セットに設定します。
(iii) set the criticality_indicator to the criticality of the certificate policies extension of certificate i;
（iii）criticality_indicatorを証明書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）expected_policy_setを、ポリシーマッピング拡張機能によってID-Pと同等であると指定されているsubjectDomainPolicy値のセットに設定します。
(2) If the policy_mapping variable is equal to 0:
（2）policy_mapping変数が0の場合：
(i) delete each node of depth i in the valid_policy_tree where ID-P is the valid_policy.
（i）valid_policy_treeの深さiの各ノードを削除します。ID-Pはvalid_policyです。
(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以下のvalid_policy_treeにノードがある場合は、そのノードを削除します。子のない深さがi-1以下のノードがなくなるまで、この手順を繰り返します。
(c) Assign the certificate subject name to working_issuer_name.
（c）証明書のサブジェクト名をworking_issuer_nameに割り当てます。
(d) Assign the certificate subjectPublicKey to working_public_key.
（d）証明書subjectPublicKeyをworking_public_keyに割り当てます。
(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フィールドにnull以外のパラメーターを持つアルゴリズムフィールドが含まれている場合は、パラメーターをworking_public_key_parameters変数に割り当てます。
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フィールドにnullパラメータを含むアルゴリズムフィールドが含まれているか、パラメータが省略されている場合は、証明書のsubjectPublicKeyアルゴリズムをworking_public_key_algorithmと比較します。証明書のsubjectPublicKeyアルゴリズムとworking_public_key_algorithmが異なる場合は、working_public_key_parametersをnullに設定します。
(f) Assign the certificate subjectPublicKey algorithm to the working_public_key_algorithm variable.
(f) Assign the certificate subjectPublicKey algorithm to the working_public_key_algorithm variable.
(g) If a name constraints extension is included in the certificate, modify the permitted_subtrees and excluded_subtrees state variables as follows:
（g）名前制約拡張が証明書に含まれている場合は、次のようにallowed_subtreesおよびexcluded_subtrees状態変数を変更します。
(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) 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.
(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）excludeSubtreesが証明書に存在する場合、exclude_subtrees状態変数を、以前の値と拡張フィールドに示されている値の和集合に設定します。 excludeSubtreesに特定の名前タイプが含まれていない場合、exclude_subtrees状態変数はその名前タイプに対して変更されません。たとえば、名前空間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）explicit_policyが0でない場合、explicit_policyを1だけ減らします。
(2) If policy_mapping is not 0, decrement policy_mapping by 1.
（2）policy_mappingが0でない場合、policy_mappingを1減らします。
(3) If inhibit_any-policy is not 0, decrement inhibit_any-policy by 1.
（3）prevent_any-policyが0でない場合は、inhibit_any-policyを1だけ減らします。
(i) If a policy constraints extension is included in the certificate, modify the explicit_policy and policy_mapping state variables as follows:
(i) If a policy constraints extension is included in the certificate, modify the explicit_policy and policy_mapping state variables as follows:
(1) If requireExplicitPolicy is present and is less than explicit_policy, set explicit_policy to the value of requireExplicitPolicy.
（1）requireExplicitPolicyが存在し、explicit_policyより小さい場合、explicit_policyをrequireExplicitPolicyの値に設定します。
(2) If inhibitPolicyMapping is present and is less than policy_mapping, set policy_mapping to the value of inhibitPolicyMapping.
（2）preventPolicyMappingが存在し、policy_mappingより小さい場合は、policy_mappingをpreventPolicyMappingの値に設定します。
(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）preventAnyPolicy拡張が証明書に含まれていて、inhibit_any-policyより小さい場合は、inhibit_any-policyをpreventAnyPolicyの値に設定します。
(k) Verify that the certificate is a CA certificate (as specified in a basicConstraints extension or as verified out-of-band).
（k）証明書がCA証明書であることを確認します（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）証明書が自己発行されなかった場合は、max_path_lengthがゼロより大きいことを確認し、max_path_lengthを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が証明書に存在し、max_path_lengthより小さい場合、max_path_lengthを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.
（a）、（k）、（l）、（n）、（o）が正常に完了した場合は、iをインクリメントして、6.1.3で指定されている基本的な証明書処理を実行します。
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が自己発行でなく、explicit_policyが0でない場合、explicit_policyを1だけ減らします。
(b) If a policy constraints extension is included in the certificate and requireExplicitPolicy is present and has a value of 0, set the explicit_policy state variable to 0.
（b）ポリシー制約拡張が証明書に含まれていてrequireRequirePolicyが存在し、値が0である場合、explicit_policy状態変数を0に設定します。
(c) Assign the certificate subjectPublicKey to working_public_key.
（c）証明書subjectPublicKeyをworking_public_keyに割り当てます。
(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フィールドにnull以外のパラメーターを持つアルゴリズムフィールドが含まれている場合は、パラメーターをworking_public_key_parameters変数に割り当てます。
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フィールドにnullパラメータを含むアルゴリズムフィールドが含まれているか、パラメータが省略されている場合は、証明書のsubjectPublicKeyアルゴリズムをworking_public_key_algorithmと比較します。証明書のsubjectPublicKeyアルゴリズムとworking_public_key_algorithmが異なる場合は、working_public_key_parametersをnullに設定します。
(e) Assign the certificate subjectPublicKey algorithm to the working_public_key_algorithm variable.
（e）証明書のsubjectPublicKeyアルゴリズムをworking_public_key_algorithm変数に割り当てます。
(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）次のように、valid_policy_treeとuser-initial-policy-setの共通部分を計算します。
(i) If the valid_policy_tree is NULL, the intersection is NULL.
（i）valid_policy_treeが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）valid_policy_treeがNULLでなく、user-initial-policy-setがany-policyの場合、共通部分はvalid_policy_tree全体です。
(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）valid_policy_treeがNULLでなく、user-initial-policy-setがany-policyでない場合、次のようにvalid_policy_treeとuser-initial-policy-setの共通部分を計算します。
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のvalid_policyを持つポリシーノードのセットを決定します。これは、valid_policy_node_setです。
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. valid_policy_node_set内のいずれかのノードのvalid_policyがuser-initial-policy-set内になく、anyPolicyでない場合は、このノードとそのすべての子を削除します。
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. valid_policy_treeに、valid_policy anyPolicyの深さnのノードが含まれ、user-initial-policy-setがany-policyではない場合、次の手順を実行します。
a. Set P-Q to the qualifier_set in the node of depth n with valid_policy anyPolicy.
a. valid_policy anyPolicyを使用して、深さnのノードのP-Qをqualifier_setに設定します。
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. valid_policy_node_setのノードのvalid_policyではないuser-initial-policy-setの各P-OIDに対して、valid_policy anyPolicyを使用して深さn-1のノードを親とする子ノードを作成します。子ノードの値を次のように設定します。valid_policyをP-OIDに設定します。 qualifier_setをP-Qに設定します。深さnのノードから、valid_policy anyPolicyを使用してcriticality_indicatorをコピーします。 expected_policy_setを{P-OID}に設定します。
c. Delete the node of depth n with the valid_policy anyPolicy.
c. valid_policy 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以下のvalid_policy_treeにノードがある場合は、そのノードを削除します。子なしで深さが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）explicit_policy変数の値がゼロより大きい場合、または（2）valid_policy_treeがNULLでない場合、パス処理は成功しています。
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.
パス処理が成功した場合、プロシージャは終了し、valid_policy_tree、working_public_key、working_public_key_algorithm、working_public_key_parametersの最終値とともに成功を示します。
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 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で提示されたアルゴリズムを強化してもよい（MAY）。たとえば、実装は、初期化フェーズ中に特定のトラストアンカーに名前の制約を適用するようにアルゴリズムを変更する場合があります。または、アプリケーションがエンドエンティティ証明書に特定の代替名フォームの存在を要求する場合があります。または、アプリケーションがアプリケーションに要件を課す場合があります。固有の拡張子。したがって、セクション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つ以上の信頼できるCAの選択は、ローカルの決定です。システムは、信頼できるCAのいずれかを特定のパスのトラストアンカーとして提供できます。パス検証アルゴリズムへの入力は、パスごとに異なる場合があります。パスの処理に使用される入力は、特定のトラストアンカーによって与えられたトラストのアプリケーション固有の要件または制限を反映している場合があります。たとえば、信頼できるCAは、特定の証明書ポリシーに対してのみ信頼される場合があります。この制限は、パス検証手順への入力を通じて表現できます。
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 [RFC 1422]のルールと同じデフォルトの動作になる、上記の認証パス処理手順の拡張バージョンを指定することもできます。この拡張バージョンでは、手順への追加の入力は、1つ以上のポリシー認証局（PCA）名のリストと、PCAが期待される認証パス内の位置のインジケーターです。指定されたPCAの位置で、CA名がこのリストと比較されます。認識されたPCA名が見つかった場合、SubordinateToCAの制約が残りの証明書パスに対して暗黙的に想定され、処理が続行されます。有効なPCA名が見つからず、識別されたポリシーに基づいて証明書パスを検証できない場合、証明書パスは無効と見なされます。
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.
このセクションでは、CRLが証明書発行者が使用する失効メカニズムである場合に、証明書が失効しているか保留中かを判断するために必要な手順について説明します。 CRLをサポートする準拠実装は、このアルゴリズムを実装する必要はありませんが、この手順から生じる外部動作と機能的に同等である必要があります。正しい結果が得られる限り、特定の実装で任意のアルゴリズムを使用できます。
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.
このアルゴリズムは、必要なすべてのCRLがローカルキャッシュで使用できることを前提としています。さらに、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.
このアルゴリズムは、パスの各証明書に対して実行される一連の入力、一連の状態変数、および処理ステップを定義します。アルゴリズムの出力は、証明書の失効ステータスです。
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拡張機能は、提供された証明書がCAまたはエンドエンティティに関連付けられているかどうかを判断するために使用されます。存在する場合、アルゴリズムはcRLDistributionsPointおよびfreshestCRL拡張を使用して失効ステータスを決定します。
(b) use-deltas: This boolean input determines whether delta CRLs are applied to CRLs.
（b）use-deltas：このブール入力は、Delta CRLがCRLに適用されるかどうかを決定します。
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.
RFC 1422やX.509バージョン1などのレガシーPKIをサポートする実装では、提供された証明書がCAまたはエンドエンティティに関連付けられているかどうかを示す追加の入力が必要になることに注意してください。
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）reasons_mask：この変数には、これまでに処理されたCRLおよびDelta CRLによってサポートされている失効理由のセットが含まれています。セットの正当なメンバーは、取り消す理由の可能性のある値です：unspecified、keyCompromise、caCompromise、affiliationChanged、superseded、cessationOfOperation、certificateHold、privilegeWithdrawn、およびaACompromise。特別な値all-reasonsは、すべての正当なメンバーのセットを示すために使用されます。この変数は空のセットに初期化されます。
(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）cert_status：この変数には、証明書のステータスが含まれます。この変数には、unspecified、keyCompromise、caCompromise、affiliationChanged、superseded、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）interim_reasons_mask：これには、現在処理されているCRLまたはDelta CRLによってサポートされている失効理由のセットが含まれています。
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.
注：一部の環境では、すべての理由コードを確認する必要はありません。たとえば、一部の環境はCA証明書のcaCompromiseとkeyCompromiseのみに関係しています。このアルゴリズムは、すべての理由コードをチェックします。チェックを理由コードのサブセットに制限するには、追加の処理変数と状態変数が必要になる場合があります。
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.
このアルゴリズムは、証明書が取り消されていないと想定することから始まります。アルゴリズムは、証明書のステータスが取り消されたと判断されるか、すべての理由コードをカバーするのに十分なCRLが確認されるまで、1つ以上のCRLを確認します。
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:
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:
(a) Update the local CRL cache by obtaining a complete CRL, a delta CRL, or both, as required:
(a) Update the local CRL cache by obtaining a complete CRL, a delta CRL, or both, as required:
(1) If the current time is after the value of the CRL next update field, then do one of the following:
（1）現在時刻がCRLの次の更新フィールドの値より後の場合は、次のいずれかを実行します。
(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) 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.
(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で処理を続行します。 use-deltasが設定されている場合は、セクション5.2.4で指定されているように、ローカルにキャッシュされた新しい完全なCRLを更新するために使用できる現在のDelta 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）現在時刻が次の更新フィールドの値の前であり、use-deltasが設定されている場合、セクション5.2.4で指定されているように、ローカルにキャッシュされた完全なCRLを更新するために使用できる現在の差分CRLを取得します。
(b) Verify the issuer and scope of the complete CRL as follows:
（b）次のように、完全なCRLの発行者と範囲を確認します。
(1) If the DP includes cRLIssuer, then verify that the issuer field in the complete CRL matches cRLIssuer in the DP and that the complete CRL contains an issuing distribution point extension with the 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）IDP CRL拡張でonlyContainsUserCertsブール値がアサートされている場合は、証明書に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）use-deltasが設定されている場合は、以下のようにDelta CRLの発行者とスコープを確認します。
(1) Verify that the delta CRL issuer matches complete CRL issuer.
（1）Delta 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拡張が含まれている場合、Delta CRLに一致するIDP CRL拡張が含まれていることを確認します。完全なCRLでIDP CRL拡張が省略されている場合は、Delta CRLでもIDP CRL拡張が省略されていることを確認してください。
(3) Verify that the delta CRL authority key identifier extension matches complete CRL authority key identifier extension.
（3）Delta CRLオーソリティキー識別子拡張が完全なCRLオーソリティキー識別子拡張と一致することを確認します。
(d) Compute the interim_reasons_mask for this CRL as follows:
（d）このCRLのinterim_reasons_maskを次のように計算します。
(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に理由が含まれている場合は、interim_reasons_maskをDPの理由とIDP CRL拡張の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が理由を省略している場合は、interim_reasons_maskを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拡張が存在しないか、SomeReasonsのみが省略されているが、DPに理由が含まれている場合は、interim_reasons_maskを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拡張が存在しないか、SomeReasonsのみを省略し、DPが理由を省略した場合、interim_reasons_maskを特別な値all-reasonsに設定します。
(e) Verify that interim_reasons_mask includes one or more reasons that is not included in the reasons_mask.
（e）interim_reasons_maskに、reasons_maskに含まれていない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) Validate the signature on the complete CRL using the public key validated in step (f).
(h) If use-deltas is set, then validate the signature on the delta CRL using the public key validated in step (f).
（h）use-deltasが設定されている場合は、ステップ（f）で検証された公開鍵を使用して、Delta CRLの署名を検証します。
(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）use-deltasが設定されている場合は、Delta CRLで証明書を検索します。セクション5.3.4で説明されているように、証明書の発行者とシリアル番号に一致するエントリが見つかった場合は、次のようにcert_status変数を示された理由に設定します。
(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) If the reason code CRL entry extension is present, set the cert_status variable to the value of the reason code CRL entry extension.
(2) If the reason code CRL entry extension is not present, set the cert_status variable to the value unspecified.
（2）理由コードCRLエントリー拡張が存在しない場合は、cert_status変数を未指定の値に設定します。
(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）（cert_statusがUNREVOKED）の場合、完全なCRLで証明書を検索します。セクション5.3.4で説明されているように、証明書の発行者とシリアル番号に一致するエントリが見つかった場合は、手順（i）で説明されているように、cert_status変数を示された理由に設定します。
(k) If (cert_status is removeFromCRL), then set cert_status to UNREVOKED.
（k）（cert_statusがremoveFromCRL）の場合、cert_statusをUNREVOKEDに設定します。
If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)), then the revocation status has been determined, so return cert_status.
（（reasons_mask is all-reasons）OR（cert_status is unrevoked））の場合、失効ステータスが決定されているため、cert_statusを返します。
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.
失効ステータスが決定されていない場合は、配布ポイントで指定されていないが証明書発行者によって発行された使用可能なCRLを使用して、上記のプロセスを繰り返します。このようなCRLの処理については、理由とcRLIssuerフィールドの両方が省略されたDP、および証明書発行者の配布ポイント名を想定します。つまり、fullName内の名前のシーケンスは、証明書発行者フィールドと証明書発行者AltName拡張から生成されます。失効ステータスが未定のままの場合は、cert_status 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.
[ISO 10646] ISO / IEC 10646-1：1993。国際標準-情報技術-ユニバーサル複数オクテットコード化文字セット（UCS）-パート1：アーキテクチャと基本的な多言語プレーン。
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC 791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC 822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[RFC 822] Crocker、D。、「ARPAインターネットテキストメッセージのフォーマットの標準」、STD 11、RFC 822、1982年8月。
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC 1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management," RFC 1422, February 1993.
[RFC 1422]ケントS.、「インターネット電子メールのプライバシー強化：パートII：証明書ベースのキー管理」、RFC 1422、1993年2月。
[RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers," RFC 1423, February 1993.
[RFC 1423]バレンソン、D。、「インターネット電子メールのプライバシー強化：パートIII：アルゴリズム、モード、および識別子」、RFC 1423、1993年2月。
[RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)," RFC 1510, September 1993.
[RFC 1510]コールJ.およびC.ノイマン、「Kerberosネットワーク認証サービス（V5）」、RFC 1510、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.
[RFC 1519] Fuller、V.、T。Li、J。Yu、およびK. Varadhan、「Classless Inter-Domain Routing（CIDR）：A Address Assignment and Aggregation Strategy」、RFC 1519、1993年9月。
[RFC 1738] Berners-Lee, T., L. Masinter and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC 1738] Berners-Lee、T.、L。MasinterおよびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[RFC 1778] Howes, T., S. Kille, W. Yeong and C. Robbins, "The String Representation of Standard Attribute Syntaxes," RFC 1778, March 1995.
[RFC 1778] Howes、T.、S。Kille、W。Yeong、およびC. Robbins、「標準属性構文の文字列表現」、RFC 1778、1995年3月。
[RFC 1883] Deering, S. and R. Hinden. "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
[RFC 1883]ディアリング、S。およびR.ヒンデン。 「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 1883、1995年12月。
[RFC 2044] F. Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.
[RFC 2044] F. Yergeau、F。、「UTF-8、UnicodeおよびISO 10646の変換フォーマット」、RFC 2044、1996年10月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、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.
[RFC 2247] Kille、S.、M。Wahl、A。Grimstad、R。Huber、およびS. Sataluri、「Using Domains in LDAP / X.500 Distinguished Names」、RFC 2247、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.
[RFC 2252] Wahl、M.、A。Coulbeck、T。HowesおよびS. Kille、「Lightweight Directory Access Protocol（v3）：Attribute Syntax Definitions」、RFC 2252、1997年12月。
[RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC 2277] Alvestrand、H。、「文字セットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC 2279] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、RFC 2279、1998年1月。
[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.
[RFC 2459] Housley、R.、W。Ford、W。PolkおよびD. Solo、「Internet X.509 Public Key Infrastructure：Certificate and CRL Profile」、RFC 2459、1999年1月。
[RFC 2560] Myers, M., R. Ankney, A. Malpani, S. Galperin and C. Adams, "Online Certificate Status Protocal - OCSP", June 1999.
[RFC 2560]マイヤーズ、M.、R。アンクニー、A。マルパニ、S。ガルペリン、およびC.アダムス、「Online Certificate Status Protocal-OCSP」、1999年6月。
[SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A, 1997-02-06.
[SDN.701] SDN.701、「Message Security Protocol 4.0」、Revision A、1997-02-06。
[X.501] ITU-T Recommendation X.501: Information Technology - Open Systems Interconnection - The Directory: Models, 1993.
[X.501] ITU-T Recommendation X.501: Information Technology - Open Systems Interconnection - The Directory: Models, 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（1997 E）：情報技術-オープンシステム相互接続-ディレクトリ：認証フレームワーク、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勧告X.660情報技術-ASN.1エンコードルール：基本エンコードルール（BER）、正規エンコードルール（CER）、およびDistinguished Encodingルール（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勧告X.690情報技術-オープンシステム相互接続-OSI登録機関の運用手順：一般的な手順、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.、Polk、W。、およびR. Housley、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルのアルゴリズムと識別子」、RFC 3279、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] Adams、C.、Cain、P.、Pinkas、D。、およびR. Zuccherato、「Internet X.509 Public Key Infrastructure Time-Stamp Protocol（TSP）」、RFC 3161、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 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.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるまたは適用されない範囲に関して、いかなる立場も取らない。利用可能。また、そのような権利を特定するために何らかの努力をしたことも表していません。標準化過程および標準化関連文書の権利に関するIETFの手順に関する情報は、BCP 11にあります。公開のために利用可能にされた権利の主張のコピー、および利用可能になるライセンスの保証、または試行の結果この仕様の実装者またはユーザーがそのような所有権を使用するための一般的なライセンスまたは許可を取得するために作成されたものは、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.
この仕様の大部分は、証明書とCRLの形式と内容に特化しています。証明書とCRLはデジタル署名されているため、追加の整合性サービスは必要ありません。証明書もCRLも秘密にしておく必要はなく、証明書やCRLへの無制限の匿名アクセスはセキュリティに影響を与えません。
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.
ただし、この仕様の範囲外のセキュリティ要素は、証明書ユーザーに提供される保証に影響します。このセクションでは、実装者、管理者、およびユーザーが検討すべき重要な問題に焦点を当てています。
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.
CAとRAがサブジェクトのIDと公開キーのバインドを検証するために実行する手順は、証明書に配置する必要がある保証に大きく影響します。証明書利用者は、CAの証明書実務声明を確認することを希望する場合があります。これは、他のCAに証明書を発行するときに特に重要です。
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.
署名とその他の目的の両方に単一のキーペアを使用することは強くお勧めしません。署名と鍵管理に別々の鍵ペアを使用すると、ユーザーにいくつかの利点があります。署名鍵の紛失または開示に関連する影響は、鍵管理鍵の紛失または開示とは異なります。個別のキーペアを使用すると、バランスのとれた柔軟な応答が可能になります。同様に、一部のアプリケーション環境では、鍵ペアごとに異なる有効期間または鍵の長さが適切な場合があります。残念ながら、一部のレガシーアプリケーション（SSLなど）は、署名とキー管理に単一のキーペアを使用します。
The protection afforded private keys is a critical security factor. On a small scale, failure of users to protect their private keys will permit an attacker to masquerade as them, or decrypt their personal information. On a larger scale, compromise of a CA's private signing key may have a catastrophic effect. If an attacker obtains the private key unnoticed, the attacker may issue bogus certificates and CRLs. Existence of bogus certificates and CRLs will undermine confidence in the system. If such a compromise is detected, all certificates issued to the compromised CA MUST be revoked, preventing services between its users and users of other CAs. Rebuilding after such a compromise will be problematic, so CAs are advised to implement a combination of strong technical measures (e.g., tamper-resistant cryptographic modules) and appropriate management procedures (e.g., separation of duties) to avoid such an incident.
秘密鍵による保護は、重要なセキュリティ要素です。小規模では、ユーザーが秘密キーを保護できないと、攻撃者が偽装したり、個人情報を解読したりすることができます。大規模な場合、CAの秘密署名鍵の侵害は壊滅的な影響を与える可能性があります。攻撃者が気付かないうちに秘密鍵を取得した場合、攻撃者は偽の証明書とCRLを発行する可能性があります。偽の証明書とCRLが存在すると、システムの信頼が損なわれます。そのような侵害が検出された場合、侵害されたCAに発行されたすべての証明書を取り消す必要があり、そのユーザーと他のCAのユーザーとの間のサービスを防止する必要があります。このような妥協後の再構築には問題があるため、CAは、このようなインシデントを回避するために、強力な技術的手段（耐タンパー性暗号モジュールなど）と適切な管理手順（職務の分離など）を組み合わせて実装することをお勧めします。
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の秘密署名鍵の紛失も問題となる場合があります。 CAはCRLを生成したり、通常のキーロールオーバーを実行したりすることはできません。 CAは、署名鍵の安全なバックアップを維持する必要があります。キーのバックアップ手順のセキュリティは、キーの侵害を回避するための重要な要素です。
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に表示される可能性のあるすべての重要な拡張機能を処理できない場合があります。特に重要な拡張機能のサポートがこのプロファイルで義務付けられていない場合、CAは、重要な拡張機能を含むCRLを通じてのみ失効情報を利用できるようにする場合、特に注意を払う必要があります。たとえば、失効情報がデルタCRLとフルCRLの組み合わせを使用して提供され、デルタCRLがフルCRLよりも頻繁に発行される場合、デルタCRL処理に関連する重要な拡張を処理できない依存パーティは、次のことができません。最新の失効情報を取得します。または、Delta 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.
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.
In addition, where a key compromise or CA failure occurs for a trusted CA, the user will need to modify the information provided to the path validation routine. Selection of too many trusted CAs makes the trusted CA information difficult to maintain. On the other hand, selection of only one trusted CA could limit users to a closed community of users.
さらに、信頼できるCAで鍵の侵害またはCAの障害が発生した場合、ユーザーはパス検証ルーチンに提供される情報を変更する必要があります。選択した信頼できるCAが多すぎると、信頼できるCA情報を維持することが難しくなります。一方、信頼できるCAを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.
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.
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.
鍵と証明書のサブジェクト間のバインディングは、署名の生成に使用される暗号化モジュールの実装とアルゴリズムよりも強力にすることはできません。短いキーの長さまたは弱いハッシュアルゴリズムは、証明書の有用性を制限します。 CAは強力な暗号技術を使用できるように、暗号の進歩に注意することをお勧めします。さらに、CAは、弱い署名を生成するCAまたはエンドエンティティに証明書を発行することを拒否する必要があります。
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シリーズの仕様では、大文字、小文字、文字セット、複数文字の空白の部分文字列、または先頭と末尾の空白に関係なく、文字列の比較が必要な識別名を比較するためのルールが定義されています。この仕様は、これらの要件を緩和し、少なくともバイナリ比較のサポートを必要とします。
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.
CAは、CA証明書のサブジェクトフィールドの識別名を、そのCAが発行した証明書の発行者フィールドの識別名と同じようにエンコードする必要があります。 CAが異なるエンコーディングを使用する場合、実装はこの証明書を含むパスの名前チェーンを認識できない場合があります。その結果、有効なパスが拒否される可能性があります。
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拡張で使用されるエンコーディングと同じように記述する必要があります。一致しない場合、excludeSubTreesとして記述された名前の制約は一致せず、無効なパスが受け入れられ、permittedSubtreesとして表現された名前の制約は一致せず、有効なパスが拒否されます。無効なパスの受け入れを回避するために、CAは、可能な限り、識別名の名前制約をallowedSubtreeとして記述する必要があります（SHOULD）。
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.
このセクションでは、「ASN.1のような」構文でPKIコンポーネントに準拠することによって使用されるデータオブジェクトについて説明します。この構文は、1988年と1993年のASN.1構文のハイブリッドです。 1988 ASN.1構文は、1993年のUNIVERSALタイプの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.
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.
This appendix may be converted into 1988 ASN.1 by replacing the definitions for the UNIVERSAL Types with the 1988 catch-all "ANY".
この付録は、UNIVERSALタイプの定義を1988のキャッチオール「ANY」で置き換えることにより、1988 ASN.1に変換できます。
PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
ベギン
-- EXPORTS ALL --
-すべてエクスポート-
-- IMPORTS NONE --
-- IMPORTS NONE --
-- UNIVERSAL Types defined in 1993 and 1998 ASN.1 -- and required by this specification
-1993および1998 ASN.1で定義されているUNIVERSALタイプ-この仕様で必須
UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
-- UniversalString is defined in ASN.1:1993
BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
-- BMPString is the subtype of UniversalString and models
-- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The content of this type conforms to RFC 2279.
-- PKIX specific OIDs
-PKIX固有のOID
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) }
-- 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
-- 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
-- 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 }
-- attribute data types
-属性データ型
Attribute ::= SEQUENCE {
type AttributeType,
values SET OF AttributeValue }
-- at least one value is required
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value 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 }
-- Naming attributes of type X520name
-- Naming attributes of type 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 }
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)) }
-- Naming attributes of type X520CommonName
-タイプX520CommonNameの命名属性
id-at-commonName AttributeType ::= { id-at 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)) }
-- Naming attributes of type X520LocalityName
-X520LocalityNameタイプの命名属性
id-at-localityName AttributeType ::= { id-at 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)) }
-- Naming attributes of type X520StateOrProvinceName
-タイプX520StateOrProvinceNameの命名属性
id-at-stateOrProvinceName AttributeType ::= { id-at 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)) }
-- Naming attributes of type X520OrganizationName
-X520OrganizationNameタイプの命名属性
id-at-organizationName AttributeType ::= { id-at 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)) }
-- Naming attributes of type X520OrganizationalUnitName
-X520OrganizationalUnitNameタイプの命名属性
id-at-organizationalUnitName AttributeType ::= { id-at 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)) }
-- Naming attributes of type X520Title
-X520Titleタイプの命名属性
id-at-title AttributeType ::= { id-at 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)) }
-- Naming attributes of type X520dnQualifier
-X520dnQualifierタイプの命名属性
id-at-dnQualifier AttributeType ::= { id-at 46 }
X520dnQualifier ::= PrintableString
-- Naming attributes of type X520countryName (digraph from IS 3166)
-タイプX520countryNameの命名属性（IS 3166のダイグラフ）
id-at-countryName AttributeType ::= { id-at 6 }
X520countryName ::= PrintableString (SIZE (2))
-- Naming attributes of type X520SerialNumber
-タイプX520SerialNumberの命名属性
id-at-serialNumber AttributeType ::= { id-at 5 }
X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number))
-- Naming attributes of type X520Pseudonym
-X520Pseudonymタイプの命名属性
id-at-pseudonym AttributeType ::= { id-at 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)) }
-- Naming attributes of type DomainComponent (from RFC 2247)
-タイプDomainComponentの命名属性（RFC 2247から）
id-domainComponent AttributeType ::=
{ 0 9 2342 19200300 100 1 25 }
DomainComponent ::= IA5String
-- Legacy attributes
-レガシー属性
pkcs-9 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 }
id-emailAddress AttributeType ::= { pkcs-9 1 }
EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length))
-- naming data types --
-データ型の命名-
Name ::= CHOICE { -- only one possibility for now --
rdnSequence RDNSequence }
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
DistinguishedName ::= RDNSequence RelativeDistinguishedName ::=
SET SIZE (1 .. MAX) OF AttributeTypeAndValue
-- 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)) }
-- certificate and CRL specific structures begin here
-証明書とCRL固有の構造はここから始まります
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signature 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 -- }
Version ::= INTEGER { v1(0), v2(1), v3(2) }
CertificateSerialNumber ::= INTEGER
Validity ::= SEQUENCE {
notBefore Time,
notAfter Time }
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
UniqueIdentifier ::= BIT STRING SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING }
-- CRL structures
-CRL構造
CertificateList ::= SEQUENCE {
tbsCertList TBSCertList,
signatureAlgorithm AlgorithmIdentifier,
signature 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
-- Version, Time, CertificateSerialNumber, and Extensions were -- defined earlier for use in the certificate structure
-バージョン、時間、CertificateSerialNumber、および拡張機能が-証明書構造で使用するために以前に定義されました
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
-- X.400 address syntax starts here ORAddress ::= SEQUENCE {
built-in-standard-attributes BuiltInStandardAttributes,
built-in-domain-defined-attributes
BuiltInDomainDefinedAttributes OPTIONAL,
-- see also teletex-domain-defined-attributes
extension-attributes 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
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)) }
AdministrationDomainName ::= [APPLICATION 2] CHOICE {
numeric NumericString (SIZE (0..ub-domain-name-length)),
printable PrintableString (SIZE (0..ub-domain-name-length)) }
NetworkAddress ::= X121Address -- see also extended-network-address
X121Address ::= NumericString (SIZE (1..ub-x121-address-length))
TerminalIdentifier ::= PrintableString (SIZE
(1..ub-terminal-id-length))
PrivateDomainName ::= CHOICE {
numeric NumericString (SIZE (1..ub-domain-name-length)),
printable PrintableString (SIZE (1..ub-domain-name-length)) }
OrganizationName ::= PrintableString
(SIZE (1..ub-organization-name-length))
-- see also teletex-organization-name
NumericUserIdentifier ::= NumericString
(SIZE (1..ub-numeric-user-id-length))
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
OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units)
OF OrganizationalUnitName
-- see also teletex-organizational-unit-names
OrganizationalUnitName ::= PrintableString (SIZE
(1..ub-organizational-unit-name-length))
-- Built-in Domain-defined Attributes
-組み込みのドメイン定義属性
BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE
(1..ub-domain-defined-attributes) OF
BuiltInDomainDefinedAttribute
BuiltInDomainDefinedAttribute ::= SEQUENCE {
type PrintableString (SIZE
(1..ub-domain-defined-attribute-type-length)),
value PrintableString (SIZE
(1..ub-domain-defined-attribute-value-length)) }
-- Extension Attributes
-拡張属性
ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF
ExtensionAttribute
ExtensionAttribute ::= SEQUENCE {
extension-attribute-type [0] IMPLICIT INTEGER
(0..ub-extension-attributes),
extension-attribute-value [1]
ANY DEFINED BY extension-attribute-type }
-- Extension types and attribute values
-- Extension types and attribute values
common-name INTEGER ::= 1
CommonName ::= PrintableString (SIZE (1..ub-common-name-length))
teletex-common-name INTEGER ::= 2
TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length))
teletex-organization-name INTEGER ::= 3
TeletexOrganizationName ::=
TeletexString (SIZE (1..ub-organization-name-length))
teletex-personal-name 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 }
teletex-organizational-unit-names INTEGER ::= 5
TeletexOrganizationalUnitNames ::= SEQUENCE SIZE
(1..ub-organizational-units) OF TeletexOrganizationalUnitName
TeletexOrganizationalUnitName ::= TeletexString
(SIZE (1..ub-organizational-unit-name-length))
pds-name INTEGER ::= 7
PDSName ::= PrintableString (SIZE (1..ub-pds-name-length))
physical-delivery-country-name 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)) }
postal-code INTEGER ::= 9
PostalCode ::= CHOICE {
numeric-code NumericString (SIZE (1..ub-postal-code-length)),
printable-code PrintableString (SIZE (1..ub-postal-code-length)) }
physical-delivery-office-name INTEGER ::= 10
PhysicalDeliveryOfficeName ::= PDSParameter
physical-delivery-office-number INTEGER ::= 11
PhysicalDeliveryOfficeNumber ::= PDSParameter
extension-OR-address-components INTEGER ::= 12
ExtensionORAddressComponents ::= PDSParameter
physical-delivery-personal-name INTEGER ::= 13
PhysicalDeliveryPersonalName ::= PDSParameter
physical-delivery-organization-name INTEGER ::= 14
PhysicalDeliveryOrganizationName ::= PDSParameter
extension-physical-delivery-address-components INTEGER ::= 15
ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter
unformatted-postal-address 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 }
street-address INTEGER ::= 17
StreetAddress ::= PDSParameter
post-office-box-address INTEGER ::= 18
PostOfficeBoxAddress ::= PDSParameter
poste-restante-address INTEGER ::= 19 PosteRestanteAddress ::= PDSParameter
unique-postal-name INTEGER ::= 20
UniquePostalName ::= PDSParameter
local-postal-attributes INTEGER ::= 21
LocalPostalAttributes ::= PDSParameter
PDSParameter ::= SET {
printable-string PrintableString
(SIZE(1..ub-pds-parameter-length)) OPTIONAL,
teletex-string TeletexString
(SIZE(1..ub-pds-parameter-length)) OPTIONAL }
extended-network-address 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 }
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 }
terminal-type INTEGER ::= 23
TerminalType ::= INTEGER {
telex (3),
teletex (4),
g3-facsimile (5),
g4-facsimile (6),
ia5-terminal (7),
videotex (8) } (0..ub-integer-options)
-- Extension Domain-defined Attributes
-拡張ドメイン定義の属性
teletex-domain-defined-attributes INTEGER ::= 6 TeletexDomainDefinedAttributes ::= SEQUENCE SIZE
(1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute
TeletexDomainDefinedAttribute ::= SEQUENCE {
type TeletexString
(SIZE (1..ub-domain-defined-attribute-type-length)),
value TeletexString
(SIZE (1..ub-domain-defined-attribute-value-length)) }
-- specifications of Upper Bounds MUST be regarded as mandatory -- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter -- Upper Bounds
-上限の指定は必須と見なされなければなりません（MUST）-ITU-T X.411のAnnex BからMTSパラメータのリファレンス定義-上限
-- 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 ub-terminal-id-length INTEGER ::= 24
ub-unformatted-address-length INTEGER ::= 180
ub-x121-address-length 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。 UTF8StringまたはUniversalStringの場合、4回以上-上限を許可する必要があります。
END
終わり
PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(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) };
-- ISO arc for standard certificate and CRL extensions
-標準証明書およびCRL拡張のISOアーク
id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29}
-- authority key identifier OID and syntax
-権限キー識別子OIDおよび構文
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } 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
KeyIdentifier ::= OCTET STRING
-- subject key identifier OID and syntax
-サブジェクトキー識別子OIDおよび構文
id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 }
SubjectKeyIdentifier ::= KeyIdentifier
-- key usage extension OID and syntax
-鍵用途拡張OIDと構文
id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
KeyUsage ::= BIT STRING {
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 }
PrivateKeyUsagePeriod ::= SEQUENCE {
notBefore [0] GeneralizedTime OPTIONAL,
notAfter [1] GeneralizedTime OPTIONAL }
-- either notBefore or notAfter MUST be present
-- certificate policies extension OID and syntax
-証明書ポリシー拡張OIDおよび構文
id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 }
anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }
CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
PolicyInformation ::= SEQUENCE {
policyIdentifier CertPolicyId, policyQualifiers SEQUENCE SIZE (1..MAX) OF PolicyQualifierInfo OPTIONAL }
policyIdentifier CertPolicyId、policyQualifiers SEQUENCE SIZE（1..MAX）OF PolicyQualifierInfo OPTIONAL}
CertPolicyId ::= OBJECT IDENTIFIER
PolicyQualifierInfo ::= SEQUENCE {
policyQualifierId PolicyQualifierId,
qualifier ANY 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 )
-- CPS pointer qualifier
-CPSポインター修飾子
CPSuri ::= IA5String
-- user notice qualifier
-ユーザー通知修飾子
UserNotice ::= SEQUENCE {
noticeRef NoticeReference OPTIONAL,
explicitText DisplayText OPTIONAL}
NoticeReference ::= SEQUENCE {
organization 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)) }
-- policy mapping extension OID and syntax
-ポリシーマッピング拡張OIDと構文
id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 }
PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
issuerDomainPolicy CertPolicyId,
subjectDomainPolicy CertPolicyId }
-- subject alternative name extension OID and syntax
-サブジェクトの別名拡張OIDおよび構文
id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
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 }
-- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as
-- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax
AnotherName ::= SEQUENCE {
type-id OBJECT IDENTIFIER,
value [0] EXPLICIT ANY DEFINED BY type-id }
EDIPartyName ::= SEQUENCE {
nameAssigner [0] DirectoryString OPTIONAL,
partyName [1] DirectoryString }
-- issuer alternative name extension OID and syntax
-発行者の代替名拡張OIDと構文
id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 }
IssuerAltName ::= GeneralNames
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 }
SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
-- basic constraints extension OID and syntax
-基本的な制約拡張OIDと構文
id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 }
BasicConstraints ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }
-- name constraints extension OID and syntax
-名前制約拡張OIDと構文
id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
-- policy constraints extension OID and syntax
-ポリシー制約拡張OIDおよび構文
id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 }
PolicyConstraints ::= SEQUENCE {
requireExplicitPolicy [0] SkipCerts OPTIONAL,
inhibitPolicyMapping [1] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER (0..MAX)
-- CRL distribution points extension OID and syntax
-CRL配布ポイント拡張OIDおよび構文
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31}
CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
DistributionPoint ::= SEQUENCE {
distributionPoint [0] DistributionPointName OPTIONAL,
reasons [1] ReasonFlags OPTIONAL,
cRLIssuer [2] GeneralNames OPTIONAL }
DistributionPointName ::= CHOICE {
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) }
-- extended key usage extension OID and syntax
-拡張キー使用法拡張OIDおよび構文
id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37}
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER
-- permit unspecified key uses
-不特定のキーの使用を許可する
anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
-- extended key purpose OIDs
-拡張鍵目的OID
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 }
-- inhibit any policy OID and syntax
-ポリシーのOIDと構文を禁止する
id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 }
InhibitAnyPolicy ::= SkipCerts
-- freshest (delta)CRL extension OID and syntax
-最新の（delta）CRL拡張OIDと構文
id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 }
FreshestCRL ::= CRLDistributionPoints
-- authority info access
-機関情報アクセス
id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
AuthorityInfoAccessSyntax ::=
SEQUENCE SIZE (1..MAX) OF AccessDescription
AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER,
accessLocation GeneralName }
-- subject info access
-サブジェクト情報アクセス
id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } SubjectInfoAccessSyntax ::=
SEQUENCE SIZE (1..MAX) OF AccessDescription
-- CRL number extension OID and syntax
-CRL番号拡張OIDおよび構文
id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
CRLNumber ::= INTEGER (0..MAX)
-- issuing distribution point extension OID and syntax
-配布ポイント拡張OIDと構文の発行
id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
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 }
id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
BaseCRLNumber ::= CRLNumber
-- CRL reasons extension OID and syntax
-CRL理由拡張OIDおよび構文
id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }
CRLReason ::= ENUMERATED {
unspecified (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (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 }
CertificateIssuer ::= GeneralNames
-- hold instruction extension OID and syntax id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }
HoldInstructionCode ::= OBJECT IDENTIFIER
-- ANSI x9 holdinstructions
-ANSI x9ホールド命令
-- ANSI x9 arc holdinstruction arc
-ANSI x9アークホールド命令アーク
holdInstruction OBJECT IDENTIFIER ::=
{joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2}
-- ANSI X9 holdinstructions referenced by this standard
-この規格で参照されるANSI X9ホールド命令
id-holdinstruction-none OBJECT IDENTIFIER ::=
{holdInstruction 1} -- deprecated
id-holdinstruction-callissuer OBJECT IDENTIFIER ::=
{holdInstruction 2}
id-holdinstruction-reject OBJECT IDENTIFIER ::=
{holdInstruction 3}
-- invalidity date CRL entry extension OID and syntax
-無効日CRLエントリ拡張OIDおよび構文
id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
InvalidityDate ::= GeneralizedTime
END
終わり
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.
CAは、serialNumberを負でない整数にする必要があります。つまり、INTEGER値のDERエンコーディングの符号ビットはゼロでなければなりません。これは、必要に応じて、先頭（左端）の `00'Hオクテットを追加することで実行できます。これにより、オクテットの文字列と整数値との間のマッピングにおける潜在的なあいまいさがなくなります。
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で述べたように、シリアル番号には長整数が含まれることが予想されます。証明書ユーザーは、最大20オクテットまでのserialNumber値を処理できる必要があります。適合CAは、20オクテットを超えるserialNumber値を使用してはなりません（MUST NOT）。
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.
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.
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.
「SEQUENCE SIZE（1..MAX）OF」という構成は、いくつかのASN.1構成に現れます。有効なASN.1シーケンスには、0個以上のエントリがあります。 SIZE（1..MAX）コンストラクトは、シーケンスに少なくとも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.
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.
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.
実装者は、アットマーク（ '@'）およびアンダースコア（ '_'）文字がASN.1タイプのPrintableStringでサポートされていないことに注意する必要があります。これらの文字は、インターネットアドレスによく表示されます。このようなアドレスは、それらをサポートするASN.1タイプを使用してエンコードする必要があります。それらは通常、識別名内のemailAddress属性またはGeneralNameのrfc822NameフィールドのいずれかでIA5Stringとしてエンコードされます。適合実装は、アットマークまたはアンダースコア文字を含む文字列をPrintableStringとしてエンコードしてはなりません（MUST NOT）。
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.
名前付きビットリストは、値に名前が割り当てられているビットストリングです。この仕様では、キー使用法、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は、ISO 10646-1 [ISO 10646]で許可されている任意の文字をサポートします。 ISO 10646-1は、ユニバーサルマルチオクテットコード化文字セット（UCS）です。 ISO 10646-1は、アーキテクチャと「基本的な多言語プレーン」（すべての主要な世界の文字標準を含む大きな標準文字セット）を指定しています。
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].
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].
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.
これらの変更を見越して、RFC 2277 [RFC 2277]、文字セットと言語に関するIETFポリシーで成文化されたIETFベストプラクティスに準拠して、このドキュメントには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.
実装者は、SET OF値のDERエンコードには値のエンコードの順序付けが必要であることに注意する必要があります。特に、この問題は識別名に関して発生します。
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.
実装者は、値が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.
オブジェクト識別子（OID）は、この仕様全体で証明書ポリシー、公開鍵と署名アルゴリズム、証明書拡張などを識別するために使用されます。OIDの最大サイズはありません。この仕様では、2 ^ 28未満の値を持つ弧要素を持つOIDのサポートが義務付けられています。つまり、0から268,435,455までの範囲である必要があります。これにより、各弧要素を単一の32ビットワード内で表すことができます。実装は、ドット付き10進数（[RFC 2252]、セクション4.1を参照）の長さが最大100バイト（両端を含む）であるOIDもサポートする必要があります。実装は、最大20要素（両端を含む）のOIDを処理できる必要があります。 CAは、これらの要件を超えるOIDを含む証明書を発行しないでください。同様に、CRL発行者は、これらの要件を超えるOIDを含むCRLを発行しないでください。
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定義をいつ変更できるかを決定します。たとえば、このプロファイルドキュメントの前身であるRFC 2459 [RFC 2459]に含まれる少なくとも2つの拡張定義には、この仕様では異なるASN.1定義がありますが、同じOIDが使用されています。不明な要素が拡張機能内に表示され、拡張機能がクリティカルとしてマークされていない場合、次のようにそれらの不明な要素は無視されます。
(a) ignore all unknown bit name assignments within a bit string;
（a）ビット文字列内の不明なビット名の割り当てをすべて無視します。
(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）番号がSETまたはSEQUENCEのオプションの要素として出現する場合、列挙型スタイルで使用されているENUMERATEDタイプまたはINTEGERタイプのすべての不明な名前付き番号を無視します。そして
(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）SET内、SEQUENCEの最後、またはCHOICE自体がSETまたはSEQUENCEのオプションの要素であるCHOICE内のすべての不明な要素を無視します。
If an extension containing unexpected values is marked critical, the implementation MUST reject the certificate or CRL containing the unrecognized extension.
予期しない値を含む拡張がクリティカルとマークされている場合、実装は、認識されない拡張を含む証明書またはCRLを拒否する必要があります。
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 = us、o = gov、ou = nistであるCAによって発行された「自己署名」証明書の注釈付き16進ダンプが含まれています。証明書には、パラメーター付きの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には、エンドエンティティ証明書の注釈付き16進ダンプが含まれています。エンドエンティティ証明書には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の注釈付き16進ダンプが含まれています。 CRLは、識別名がcn = us、o = gov、ou = nistであるCAによって発行され、失効した証明書のリストには、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>.
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>.
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);
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);
(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.)
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 {
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
: }
: }
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
: 0B 5B 9A 24 11 98 E8 F3 86 90 04 F6 08 A9
: E1 8D A5 CC 3A D4
: }
: }
: }
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".
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'
: }
: }
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
: 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
: 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
: }
: }
: }
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 (j) the certificate includes a critical key usage extension
specifying that the public key is intended for verification of
digital signatures.
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 {
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 {
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)
: }
: }
: }
: }
: }
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
: }
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）を持つバージョン2 CRLの注釈付き16進ダンプが含まれています。 CRLはOU = NISTによって発行されました。 O =政府; C = 1997年8月7日の米国。次に予定されている発行は1997年9月7日でした。CRLには1つの失効した証明書が含まれています。シリアル番号18（12進数）は、keyCompromiseにより1997年7月31日に失効しました。 CRL自体は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 { 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
: }
: }
: }
Author Addresses
Author Addresses
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA
EMail: rhousley@rsasecurity.com
Warwick Ford VeriSign, Inc. 401 Edgewater Place Wakefield, MA 01880 USA
Warwick Ford VeriSign, Inc. 401 Edgewater Place Wakefield, MA 01880 USA
EMail: wford@verisign.com
Tim Polk NIST Building 820, Room 426 Gaithersburg, MD 20899 USA
Tim Polk NIST Building 820, Room 426 Gaithersburg, MD 20899 USA
EMail: wpolk@nist.gov
David Solo Citigroup 909 Third Ave, 16th Floor New York, NY 10043 USA
David Solo Citigroup 909 Third Ave, 16th Floor New York, NY 10043 USA
EMail: dsolo@alum.mit.edu
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright (C) The Internet Society (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.
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.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
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.
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.
Funding for the RFC Editor function is currently provided by the Internet Society.