[要約] RFC 4043は、インターネットX.509公開鍵基盤の永続的な識別子に関する規格です。このRFCの目的は、X.509証明書の識別子の一貫性と一意性を確保することです。
Network Working Group D. Pinkas
Request for Comments: 4043 Bull
Category: Standards Track T. Gindin
IBM
May 2005
Internet X.509 Public Key Infrastructure Permanent Identifier
インターネットX.509公開キーインフラストラクチャパーマネント識別子
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 (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity.
このドキュメントでは、エンティティに発行された公開鍵証明書のsumbutaltname拡張に含まれる可能性のある永続識別子と呼ばれる新しい名前の形式を定義します。
The permanent identifier is an optional feature that may be used by a CA to indicate that two or more certificates relate to the same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed.
永久識別子は、CAが使用するオプションの機能であり、2つ以上の証明書が同じエンティティに関連していることを示すことができます。SubjectAltname拡張機能の件名または別の名前フォームに保存されているエンティティの所属が変更されました。
The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA.
件名フィールドに携帯される件名は、発行者名フィールドで定義されている1つのCAによって認定された各件名エンティティに対してのみ一意です。ただし、新しい名前のフォームは、CAによって認定された各件名エンティティに一意の名前を掲載できます。
Table of Contents
目次
1. Introduction.................................................. 2
2. Definition of a Permanent Identifier.......................... 3
3. IANA Considerations........................................... 6
4. Security Considerations....................................... 6
5. References.................................................... 7
5.1. Normative References.................................... 7
5.2. Informative References.................................. 8
Appendix A. ASN.1 Syntax.......................................... 9
A.1. 1988 ASN.1 Module....................................... 9
A.2. 1993 ASN.1 Module....................................... 10
Appendix B. OID's for organizations............................... 11
B.1. Using IANA (Internet Assigned Numbers Authority)........ 11
B.2. Using an ISO Member Body................................ 12
B.3. Using an ICD (International Code Designator) From
British Standards Institution to Specify a New or
an Existing Identification Scheme....................... 12
Authors' Addresses................................................ 14
Full Copyright Statement.......................................... 15
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
This specification is based on [RFC3280], which defines underlying certificate formats and semantics needed for a full implementation of this standard.
この仕様は[RFC3280]に基づいており、この標準の完全な実装に必要な基礎となる証明書形式とセマンティクスを定義します。
The subject field of a public key certificate identifies the entity associated with the public key stored in the subject public key field. Names and identities of a subject may be carried in the subject field and/or the subjectAltName extension. Where subject field is non-empty, it MUST contain an X.500 distinguished name (DN). The DN MUST be unique for each subject entity certified by a single CA as defined by the issuer name field.
公開キーの証明書の主題フィールドは、主題の公開鍵フィールドに保存されている公開鍵に関連するエンティティを識別します。主題の名前とアイデンティティは、サブジェクトフィールドおよび/またはsubjectaltname拡張機能に携帯する場合があります。サブジェクトフィールドが空でない場合、x.500の著名な名前（DN）を含める必要があります。DNは、発行者名フィールドで定義されている単一のCAによって認定された各主題エンティティに対して一意でなければなりません。
The subject name changes whenever any of the components of that name gets changed. There are several reasons for such a change to happen.
サブジェクト名は、その名前のコンポーネントのいずれかが変更されるたびに変更されます。このような変更が起こる理由はいくつかあります。
For employees of a company or organization, the person may get a different position within the same company and thus will move from one organization unit to another one. Including the organization unit in the name may however be very useful to allow the relying parties (RP's) using that certificate to identify the right individual.
会社または組織の従業員の場合、その人は同じ会社内で別のポジションを獲得することができ、したがって、ある組織ユニットから別の組織ユニットに移動します。ただし、名前に組織ユニットを含めることは、その証明書を使用して適切な個人を識別するために依存関係者（RP）を許可するのに非常に便利です。
For citizens, an individual may change their name by legal processes, especially as a result of marriage.
市民の場合、個人は、特に結婚の結果として、法的手続きによって自分の名前を変更する場合があります。
Any certificate subject identified by geographical location may relocate and change at least some of the location attributes (e.g., country name, state or province, locality, or street).
地理的位置によって識別された証明書の科目は、少なくともいくつかの場所の属性（国名、州または州、地域、または通りなど）を再配置して変更することができます。
A permanent identifier consists of an identifier value assigned within a given naming space by the organization which is authoritative for that naming space. The organization assigning the identifier value may be the CA that has issued the certificate or a different organization called an Assigner Authority.
永久識別子は、その命名スペースに対して権威ある組織によって、特定の命名スペース内で割り当てられた識別子値で構成されています。識別子値を割り当てる組織は、証明書を発行したCAまたはAssigner Authorityと呼ばれる別の組織である可能性があります。
An Assigner Authority may be a government, a government agency, a corporation, or any other sort of organization. It MUST have a unique identifier to distinguish it from any other such authority. In this standard, that identifier MUST be an object identifier.
割り当て者の権限は、政府、政府機関、企業、またはその他の組織である場合があります。それを他のそのような権限と区別するための一意の識別子が必要です。この標準では、その識別子はオブジェクト識別子でなければなりません。
A permanent identifier may be useful in three contexts: access control, non-repudiation and audit records.
永続的な識別子は、アクセス制御、非繰り返し、監査記録の3つのコンテキストで役立つ場合があります。
For access control, the permanent identifier may be used in an ACL (Access Control List) instead of the DN or any other form of name and would not need to be changed, even if the subject name of the entity changes. For non-repudiation, the permanent identifier may be used to link different transactions to the same entity, even when the subject name of the entity changes.
アクセス制御のために、永続的な識別子は、DNまたはその他の形式の名前の代わりにACL（アクセス制御リスト）で使用でき、エンティティの件名名が変更されたとしても、変更する必要はありません。非repudiationの場合、永続的な識別子を使用して、エンティティの件名名が変更された場合でも、異なるトランザクションを同じエンティティにリンクすることができます。
For audit records, the permanent identifier may be used to link different audit records to the same entity, even when the subject name of the entity changes.
監査記録の場合、永久識別子を使用して、エンティティの件名名が変更された場合でも、異なる監査レコードを同じエンティティにリンクすることができます。
For two certificates which have been both verified to be valid according to a given validation policy and which contain a permanent identifier, those certificates relate to the same entity if their permanent identifiers match, whatever the content of the DN or other subjectAltName components may be.
特定の検証ポリシーに従って有効であり、永続的な識別子を含む2つの証明書の場合、それらの証明書は、DNまたは他のSEMBULTALTNAMEコンポーネントのコンテンツが関係なく、永続的な識別子が一致する場合、同じエンティティに関連しています。
Since the use of permanent identifiers may conflict with privacy, CAs SHOULD advertise to purchasers of certificates the use of permanent identifiers in certificates.
恒久的な識別子の使用はプライバシーと競合する可能性があるため、CASは証明書の証明書の使用者に証明書に永久識別子の使用を宣伝する必要があります。
This Permanent Identifier is a name defined as a form of otherName from the GeneralName structure in SubjectAltName, as defined in [X.509] and [RFC3280].
この永久識別子は、[x.509]および[rfc3280]で定義されているように、subjectaltnameの一般名構造の他の名前の形式として定義された名前です。
A CA which includes a permanent identifier in a certificate is certifying that any public key certificate containing the same values for that identifier refers to the same entity.
証明書に永久識別子を含むCAは、その識別子に同じ値を含む公開鍵証明書が同じエンティティを参照することを証明することです。
The use of a permanent identifier is OPTIONAL. The permanent identifier is defined as follows:
永続的な識別子の使用はオプションです。永久識別子は次のように定義されます。
id-on-permanentIdentifier OBJECT IDENTIFIER ::= { id-on 3 }
PermanentIdentifier ::= SEQUENCE {
identifierValue UTF8String OPTIONAL,
-- if absent, use a serialNumber attribute,
-- if there is such an attribute present
-- in the subject DN
assigner OBJECT IDENTIFIER OPTIONAL
-- if absent, the assigner is
-- the certificate issuer
}
The identifierValue field is optional.
IdentifierValueフィールドはオプションです。
When the identifierValue field is present, then the identifierValue supports one syntax: UTF8String.
識別子バリューフィールドが存在する場合、識別子バルーは1つの構文、UTF8STRINGをサポートします。
When the identifierValue field is absent, then the value of the serialNumber attribute (as defined in section 5.2.9 of [X.520]) from the deepest RDN of the subject DN is the value to be taken for the identifierValue. In such a case, there MUST be at least one serialNumber attribute in the subject DN, otherwise the PermanentIdentifier SHALL NOT be used.
識別子バルーフィールドがない場合、被験者DNの最も深いRDNからのSerialNumber属性の値（[x.520]のセクション5.2.9で定義されている）の値は、識別子用語の値です。そのような場合、被験者DNには少なくとも1つのSerialNumber属性がある必要があります。そうしないと、永続的なIdentifierを使用してはなりません。
The assigner field is optional.
割り当てフィールドはオプションです。
When the assigner field is present, then it is an OID which identifies a naming space, i.e., both an Assigner Authority and the type of that field. Characteristically, the prefix of the OID identifies the Assigner Authority, and a suffix is used to identify the type of permanent identifier.
Assignerフィールドが存在する場合、それは命名スペース、つまり割り当て者の権限とそのフィールドのタイプの両方を識別するOIDです。特徴的には、OIDの接頭辞は割り当て者の権限を識別し、接尾辞を使用して永続的な識別子のタイプを識別します。
When the assigner field is absent, then the permanent identifier is locally unique to the CA.
Assigner Fieldが存在しない場合、永続的な識別子はCAに局所的に一意です。
The various combinations are detailed below:
さまざまな組み合わせを以下に詳しく説明します。
1. Both the assigner and the identifierValue fields are present:
1. 割り当て者と識別子バルーフィールドの両方が存在します。
The identifierValue is the value for that type of identifier. The assigner field identifies the Assigner Authority and the type of permanent identifier being identified.
識別子型は、そのタイプの識別子の値です。割り当て者フィールドは、割り当て者の権限と識別される永続的な識別子のタイプを識別します。
The permanent identifier is globally unique among all CAs. In such a case, two permanent identifiers of this type match if and only if their assigner fields match and the contents of the identifierValue field in the two permanent identifiers consist of the same Unicode code points presented in the same order.
永久識別子は、すべてのCAの中でグローバルにユニークです。そのような場合、Ascigner Fieldsが一致し、2つの永続的な識別子のIDIFIERVALUEフィールドの内容が一致した場合にのみ、このタイプの2つの永久識別子が一致します。
2. The assigner field is absent and the identifierValue field is present:
2. 割り当てフィールドは存在せず、識別子バリューフィールドが存在します。
The Assigner Authority is the CA that has issued the certificate. The identifierValue is given by the CA and the permanent identifier is only local to the CA that has issued the certificate.
割り当て者の権限は、証明書を発行したCAです。識別子はCAによって与えられ、永続的な識別子は証明書を発行したCAにのみローカルです。
In such a case, two permanent identifiers of this type match if and only if the issuer DN's in the certificates which contain them match using the distinguishedNameMatch rule, as defined in X.501, and the two values of the identifierValue field consist of the same Unicode code points presented in the same order.
そのような場合、このタイプの2つの永続的な識別子は、X.501で定義されているように、distinguishednamematchルールを使用してそれらを含む証明書にある発行者dnがx.501と、識別子バリューフィールドの2つの値が同じで構成される場合にのみ一致します。同じ順序で提示されたUnicodeコードポイント。
3. Both the assigner and the identifierValue fields are absent:
3. 割り当て者と識別子バルーフィールドの両方が欠けています。
If there are one or more RDNs containing a serialNumber attribute (alone or accompanied by other attributes), then the value contained in the serialNumber of the deepest such RDN SHALL be used as the identifierValue; otherwise, the Permanent Identifier definition is invalid and the Permanent Identifier SHALL NOT be used.
SerialNumber属性（単独または他の属性を伴う）を含む1つ以上のRDNがある場合、そのような深いRDNのシリアルナンバーに含まれる値は、識別子バルーとして使用するものとします。それ以外の場合、永続的な識別子定義は無効であり、永続的な識別子は使用されません。
The permanent identifier is only local to the CA that has issued the certificate. In such a case, two permanent identifiers of this type match if and only if the issuer DN's in the certificates which contain them match and the serialNumber attributes within the subject DN's of those same certificates also match using the caseIgnoreMatch rule.
永久識別子は、証明書を発行したCAのローカルのみです。そのような場合、このタイプの2つの永続的な識別子は、それらを含む証明書にある発行者DNが一致する場合にのみ一致し、それらの同じ証明書のサブジェクトDN内のシリアルナンバー属性も、caseignorematchルールを使用して一致します。
4. The assigner field is present and the identifierValue field is absent:
4. 割り当てフィールドが存在し、識別子バリューフィールドがありません。
If there are one or more RDNs containing a serialNumber attribute (alone or accompanied by other attributes), then the value contained in the serialNumber of the deepest such RDN SHALL be used as the identifierValue; otherwise, the Permanent Identifier definition is invalid and the Permanent Identifier SHALL NOT be used.
SerialNumber属性（単独または他の属性を伴う）を含む1つ以上のRDNがある場合、そのような深いRDNのシリアルナンバーに含まれる値は、識別子バルーとして使用するものとします。それ以外の場合、永続的な識別子定義は無効であり、永続的な識別子は使用されません。
The assigner field identifies the Assigner Authority and the type of permanent identifier being identified.
割り当て者フィールドは、割り当て者の権限と識別される永続的な識別子のタイプを識別します。
The permanent identifier is globally unique among all CAs. In such a case, two permanent identifiers of this type match if and only if their assigner fields match and the contents of the serialNumber attributes within the subject DN's of those same certificates match using the caseIgnoreMatch rule.
永久識別子は、すべてのCAの中でグローバルにユニークです。そのような場合、AscignoreMatchルールを使用して同じ証明書の対象DNのシリアルナンバー属性の内容が一致した場合にのみ、このタイプの2つの永続的な識別子が一致した場合にのみ一致します。
Note: The full arc of the object identifier used to identify the permanent identifier name form is derived using:
注：永続的な識別子名形式の識別に使用されるオブジェクト識別子の完全な弧は、以下を使用して導出されます。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms
No IANA actions are necessary. However, a Private Enterprise Number may be used to construct an OID for the assigner field (see Annex B.1.).
IANAアクションは必要ありません。ただし、プライベートエンタープライズ番号を使用して、割り当て者フィールドにOIDを構築することができます（付録B.1を参照）。
A given entity may have at an instant of time or at different instants of time multiple forms of identities. If the permanent identifier is locally unique to the CA (i.e., the assigner field is not present), then two certificates from the same CA can be compared.
特定のエンティティは、時間の瞬間または異なる時間の瞬間に複数の形式のアイデンティティを持っている場合があります。永久識別子がCAに局所的に一意である場合（つまり、割り当て者フィールドが存在しない）、同じCAの2つの証明書を比較できます。
When two certificates contain identical permanent identifiers, then a relying party may determine that they refer to the same entity.
2つの証明書に同一の永続的な識別子が含まれている場合、頼る当事者は同じエンティティを参照することを決定する場合があります。
If the permanent identifier is globally unique among all CAs (i.e., the assigner field is present), then two certificates from different CAs can be compared. When they contain two identical permanent identifiers, then a relying party may determine that they refer to the same entity. It is the responsibility of the CA to verify that the permanent identifier being included in the certificate refers to the subject being certified.
永久識別子がすべてのCASの間でグローバルに一意である場合（つまり、割り当て者フィールドが存在する）、異なるCASの2つの証明書を比較できます。2つの同一の永続的な識別子が含まれている場合、頼る当事者は、同じエンティティを参照することを決定する場合があります。証明書に含まれている恒久的な識別子が、認定されている被験者を指していることを確認することは、CAの責任です。
The permanent identifier identifies the entity, irrespective of any attribute extension. When a public key certificate contains attribute extensions, the permanent identifier, if present, should not be used for access control purposes but only for audit purposes. The reason is that since these attributes may change, access could be granted on attributes that were originally present in a certificate issued to that entity but are no longer present in the current certificate.
永久識別子は、属性拡張に関係なく、エンティティを識別します。公開キーの証明書に属性拡張機能が含まれている場合、存在する場合は、永続的な識別子がアクセス制御の目的ではなく、監査目的でのみ使用されるべきです。その理由は、これらの属性が変更される可能性があるため、そのエンティティに発行された証明書に元々存在していたが、現在の証明書には存在しなくなった属性にアクセスが許可される可能性があるためです。
Subject names in certificates are chosen by the issuing CA and are mandated to be unique for each CA; so there can be no name collision between subject names from the same CA. Such a name may be an end-entity name when the certificate is a leaf certificate, or a CA name, when it is a CA certificate.
証明書のサブジェクト名は、発行CAによって選択され、各CAに対して一意であることが義務付けられています。したがって、同じCAからのサブジェクト名の間に名前の衝突はありません。このような名前は、証明書が葉の証明書である場合、CAの証明書である場合のCA名である場合、エンティティ名である場合があります。
Since a name is only unique towards its superior CA, unless some naming constraints are being used, a name would only be guaranteed to be globally unique when considered to include a sequence of all the names of the superior CAs. Thus, two certificates that are issued under the same issuer DN and which contain the same permanent identifier extension without an assigner field do not necessarily refer to the same entity.
名前は優れたCAに対してのみ一意であるため、いくつかの命名制約が使用されていない限り、名前は、優れたCAのすべての名前のシーケンスを含めると考えられる場合にのみグローバルに一意であることが保証されます。したがって、同じ発行者DNの下で発行され、割り当て者フィールドのない同じ永続的な識別子拡張機能を含む2つの証明書は、必ずしも同じエンティティを参照するわけではありません。
Additional checks need to be done, e.g., to check if the public key values of the two CAs which have issued the certificates to be compared are identical or if the sequence of CA names in the certification path from the trust anchor to the CA are identical.
追加のチェックを行う必要があります。たとえば、比較する証明書を発行した2つのCAの公開値が同一かどうか、または信頼アンカーからCAまでの認証パス内のCA名のシーケンスが同一であるかどうかを確認する必要があります。。
When the above checks fail, the permanent identifiers may still match if there has been a CA key rollover. In such a case the checking is more complicated.
上記のチェックが失敗した場合、CAキーロールオーバーがあった場合、永久識別子がまだ一致する可能性があります。そのような場合、チェックはより複雑です。
The certification of different CAs with the same DN by different CAs has other negative consequences in various parts of the PKI, notably rendering the IssuerAndSerialNumber structure in [RFC3852] section 10.2.4 ambiguous.
異なるCASによる同じDNを持つ異なるCAの認証は、PKIのさまざまな部分で他の負の結果をもたらし、特に[RFC3852]セクション10.2.4の発行者と登場構造を曖昧にします。
The permanent identifier allows organizations to create links between different certificates associated with an entity issued with or without overlapping validity periods. This ability to link different certificates may conflict with privacy. It is therefore important that a CA clearly disclose any plans to issue certificates which include a permanent identifier to potential subjects of those certificates.
永久識別子により、組織は、有効期間が重複している場合とそれなしで発行されたエンティティに関連付けられた異なる証明書間のリンクを作成できます。異なる証明書をリンクするこの機能は、プライバシーと矛盾する可能性があります。したがって、CAは、これらの証明書の潜在的な被験者に対する永続的な識別子を含む証明書を発行する計画を明確に開示することが重要です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley、R.、Polk、W.、Ford、W.、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[X.501] ITU-T Rec X.501 | ISO 9594-2: 2001: Information technology - Open Systems Interconnection - The Directory: Models, February 2001.
[x.501] itu-t rec x.501 |ISO 9594-2：2001：情報技術 - オープンシステムの相互接続 - ディレクトリ：モデル、2001年2月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[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, June 1997.
[X.520] ITU -Tの推奨X.520：情報技術 - オープンシステムの相互接続 - ディレクトリ：選択された属性タイプ、1997年6月。
[X.660] ITU-T Recommendation X.660: Information Technology - Open Systems Interconnection - Procedures for the Operation of OSI Registration Authorities: General Procedures, 1992.
[X.660] ITU -Tの推奨X.660：情報技術 - オープンシステムの相互接続 - OSI登録当局の運用の手順：一般的な手順、1992。
[X.680] ITU-T Recommendation X.680: Information Technology - Abstract Syntax Notation One, 1997.
[X.680] ITU -Tの推奨X.680：情報技術 - 抽象的構文表記1、1997。
As in RFC 2459, ASN.1 modules are supplied in two different variants of the ASN.1 syntax.
RFC 2459と同様に、ASN.1モジュールは、ASN.1構文の2つの異なるバリアントで提供されます。
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 the UNIVERSAL Type UTF8String.
このセクションでは、「ASN.1のような」構文でPKIコンポーネントを適合させることで使用されるデータオブジェクトについて説明します。この構文は、1988年と1993年のASN.1構文のハイブリッドです。1988 ASN.1構文は、1993年のユニバーサルタイプのUTF8STRINGで補強されています。
The ASN.1 syntax does not permit the inclusion of type statements in the ASN.1 module, and the 1993 ASN.1 standard does not permit use of the new UNIVERSAL types in modules using the 1988 syntax. As a result, this module does not conform to either version of the ASN.1 standard.
ASN.1構文は、ASN.1モジュールにタイプステートメントを含めることを許可しておらず、1993 ASN.1標準では、1988構文を使用してモジュールで新しいユニバーサルタイプの使用を許可していません。その結果、このモジュールは、ASN.1標準のいずれのバージョンにも準拠していません。
Appendix A.1 may be parsed by an 1988 ASN.1-parser by replacing the definitions for the UNIVERSAL Types with the 1988 catch-all "ANY".
付録A.1は、1988年の普遍的なタイプの定義を1988年のキャッチオールの「Any」に置き換えることにより、1988年のASN.1-Parserによって解析される場合があります。
Appendix A.2 may be parsed "as is" by an 1997-compliant ASN.1 parser.
付録A.2は、1997年に準拠したASN.1パーサーによって「現状のまま」解析される場合があります。
In case of discrepancies between these modules, the 1988 module is the normative one.
これらのモジュール間で矛盾がある場合、1988年モジュールは規範的なモジュールです。
Appendix A.1. 1988 ASN.1 Module
付録A.1。1988 ASN.1モジュール
PKIXpermanentidentifier88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-perm-id-88(28) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
始める
-- EXPORTS ALL --
- すべてエクスポート -
IMPORTS
輸入
-- UTF8String, / move hyphens before slash if UTF8String does not
-- resolve with your compiler
-- The content of this type conforms to [UTF-8].
id-pkix
FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ;
-- from [RFC3280]
-- Permanent identifier Object Identifier and Syntax
- 永久識別子オブジェクト識別子と構文
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-permanentIdentifier OBJECT IDENTIFIER ::= { id-on 3 }
PermanentIdentifier ::= SEQUENCE {
identifierValue UTF8String OPTIONAL,
-- if absent, use the serialNumber attribute
-- if there is a single such attribute present
-- in the subject DN
assigner OBJECT IDENTIFIER OPTIONAL
-- if absent, the assigner is
-- the certificate issuer
}
END
終わり
Appendix A.2. 1993 ASN.1 Module
付録A.2。1993 ASN.1モジュール
PKIXpermanentidentifier93 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-perm-id-93(29) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
始める
-- EXPORTS ALL --
- すべてエクスポート -
IMPORTS
輸入
id-pkix
FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) }
-- from [RFC3280]
ATTRIBUTE
FROM InformationFramework {joint-iso-itu-t ds(5) module(1)
informationFramework(1) 4};
-- from [X.501]
-- Permanent identifier Object Identifiers
- 永続的な識別子オブジェクト識別子
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
id-on-permanentIdentifier OBJECT IDENTIFIER ::= { id-on 3 }
-- Permanent Identifier
- 永久識別子
permanentIdentifier ATTRIBUTE ::= {
WITH SYNTAX PermanentIdentifier
ID id-on-permanentIdentifier }
PermanentIdentifier ::= SEQUENCE {
identifierValue UTF8String OPTIONAL,
-- if absent, use the serialNumber attribute
-- if there is a single such attribute present
-- in the subject DN
assigner OBJECT IDENTIFIER OPTIONAL
-- if absent, the assigner is
-- the certificate issuer
}
END
終わり
In order to construct an OID for the assigner field, organizations need first to have a registered OID for themselves. Such an OID must be obtained from a registration authority following [X.660]. In some cases, OID's are provided for free. In other cases a one-time fee is required. The main difference lies in the nature of the information that is collected at the time of registration and how this information is verified for its accuracy.
AssignerフィールドにOIDを構築するために、組織は最初に自分のために登録されたOIDを持つ必要があります。このようなOIDは、[x.660]に続いて登録機関から取得する必要があります。場合によっては、OIDは無料で提供されます。それ以外の場合は、1回限りの料金が必要です。主な違いは、登録時に収集された情報の性質と、この情報がその正確性のためにどのように検証されるかにあります。
Appendix B.1. Using IANA (Internet Assigned Numbers Authority)
付録B.1。IANA（インターネットに割り当てられた番号当局）を使用する
The application form for a Private Enterprise Number in the IANA's OID list is: http://www.iana.org/cgi-bin/enterprise.pl.
IANAのOIDリストにあるプライベートエンタープライズ番号の申請書は次のとおりです。http：//www.iana.org/cgi-bin/enterprise.pl。
Currently, IANA assigns numbers for free. The IANA-registered Private Enterprises prefix is: iso.org.dod.internet.private.enterprise (1.3.6.1.4.1)
現在、IANAは無料で番号を割り当てています。IANA登録のプライベートエンタープライズプレフィックスは、iso.org.dod.internet.private.enterprise（1.3.6.1.4.1）です。
These numbers are used, among other things, for defining private SNMP MIBs.
これらの数値は、とりわけ、プライベートSNMP MIBを定義するために使用されます。
The official assignments under this OID are stored in the IANA file "enterprise-numbers" available at: http://www.iana.org/assignments/enterprise-numbers
このOIDに基づく公式の課題は、http：//www.iana.org/assignments/enterprise-numbersで利用可能なIANAファイル「Enterprise-Numbers」に保存されます
Appendix B.2. Using an ISO Member Body
付録B.2。ISOメンバーボディを使用します
ISO has defined the OID structure in a such a way so that every ISO member-body has its own unique OID. Then every ISO member-body is free to allocate its own arc space below.
ISOは、すべてのISOメンバーボディに独自のOIDを持つように、そのような方法でOID構造を定義しました。その後、すべてのISOメンバーボディは、以下の独自のアークスペースを無料で割り当てることができます。
Organizations and enterprises may contact the ISO member-body where their organization or enterprise is established to obtain an organization/enterprise OID.
組織と企業は、組織/企業OIDを取得するために組織または企業が設立されたISOメンバーボディに連絡する場合があります。
Currently, ISO members do not assign organization/enterprise OID's for free.
現在、ISOメンバーは組織/エンタープライズOIDを無料で割り当てていません。
Most of them do not publish registries of such OID's which they have assigned, sometimes restricting the access to registered organizations or preferring to charge inquirers for the assignee of an OID on a per-inquiry basis. The use of OID's from an ISO member organization which does not publish such a registry may impose extra costs on the CA that needs to make sure that the OID corresponds to the registered organization.
それらのほとんどは、彼らが割り当てたそのようなoidのレジストリを公開しておらず、時には登録済み組織へのアクセスを制限したり、OIDの譲受人に対して問い合わせ者を請求することを好むこともあります。このようなレジストリを公開していないISOメンバー組織からのOIDの使用は、OIDが登録された組織に対応することを確認するために必要なCAに追加費用を課す可能性があります。
As an example, AFNOR (Association Francaise de Normalisation - the French organization that is a member of ISO) has defined an arc to allocate OID's for companies:
例として、Afnor（Association francaise de remorization- ISOのメンバーであるフランスの組織）は、企業にOIDを割り当てるアークを定義しました。
{iso (1) member-body (2) fr (250) type-org (1) organisation (n)}
{ISO（1）メンバーボディ（2）FR（250）Type-ORG（1）組織（n）}
Appendix B.3. Using an ICD (International Code Designator) From British Standards Institution to Specify a New or an Existing Identification Scheme
付録B.3。英国標準機関のICD（国際コード指定者）を使用して、新しい識別スキームまたは既存の識別スキームを指定する
The International Code Designator (ICD) is used to uniquely identify an ISO 6523 compliant organization identification scheme. ISO 6523 is a standard that defines the proper structure of an identifier and the registration procedure for an ICD. The conjunction of the ICD with an identifier issued by the registration authority is worldwide unique.
International Code Designator（ICD）は、ISO 6523準拠の組織識別スキームを一意に識別するために使用されます。ISO 6523は、識別子の適切な構造とICDの登録手順を定義する標準です。登録機関によって発行されたICDと識別子の接続詞は、世界中のユニークです。
The basic structure of the code contains the following components:
コードの基本構造には、次のコンポーネントが含まれています。
- the ICD value: The International Code Designator issued to the identification scheme makes the identifier worldwide unique (up to 4 digits),
- ICD値：識別スキームに発行された国際コード設計者は、識別子を世界中の識別子（最大4桁）にします。
- the Organization, usually a company or governmental body (up to 35 characters),
- 組織、通常は会社または政府機関（最大35文字）、
- an Organization Part (OPI - Organization Part Identifier). An identifier allocated to a particular Organization Part (optional, up to 35 characters)
- 組織部品（OPI-組織部品識別子）。特定の組織部品に割り当てられた識別子（オプション、最大35文字）
The ICD is also equivalent to an object identifier (OID) under the arc {1(iso). 3(identified organization)}.
ICDは、ARC {1（ISO）の下のオブジェクト識別子（OID）と同等です。3（識別された組織）}。
On behalf of ISO, British Standards Institution (BSI) is the Registration Authority for organizations under the arc {iso (1) org(3)}. This means BSI registers code issuing authorities (organizations) by ICD values which are equivalent to OIDs of the form {iso (1) org(3) icd(xxxx)}. The corresponding IdentifierValue is the code value of the scheme identified by icd(xxxx).
ISOを代表して、英国標準機関（BSI）は、ARC {ISO（1）ORG（3）}の下での組織の登録機関です。これは、BSIがフォームのOIDと同等のICD値によってコードを発行するコード（組織）を登録することを意味します{ISO（1）org（3）ICD（xxxx）}。対応する識別子型は、ICD（xxxx）によって識別されるスキームのコード値です。
As an example, the ICD 0012 was allocated to European Computer Manufacturers Association: ECMA. Thus the OID for ECMA is {iso(1) org(3) ecma(12)}.
例として、ICD 0012は欧州コンピューターメーカー協会に割り当てられました：ECMA。したがって、ECMAのOIDは{ISO（1）org（3）ECMA（12）}です。
For registration with BSI, a "Sponsoring Authority" has to vouch for the Applying organization. Registration is not free. Recognized "Sponsoring Authorities" are: ISO Technical Committees or (Sub)Committees, Member Bodies of ISO or International Organizations having a liaison status with ISO or with any of its Technical (Sub)Committees.
BSIへの登録の場合、「スポンサー当局」は、適用組織を保証する必要があります。登録は無料ではありません。認識されている「スポンサー当局」は、ISO技術委員会または（サブ）委員会、ISOまたは国際機関のメンバー団体、またはISOまたはその技術的（サブ）委員会のいずれかと連絡状態を持っている国際機関です。
An example of a Sponsoring Authority is the EDIRA Association (EDI/EC Registration Authority, web: http://www.edira.org, email:info@edira.org).
スポンサー当局の例は、EDIRA協会（EDI/EC登録局、Web：http：//www.edira.org、電子メール：info@edira.org）です。
The numerical list of all ICDs that have been issued is posted on its webpage: http://www.edira.org/documents.htm#icd-List
発行されたすべてのICDの数値リストは、そのWebページに掲載されています：http：//www.edira.org/documents.htm#icd-list
Note: IANA owns ICD code 0090, but (presumably) it isn't intending to use it for the present purpose.
注：IANAはICDコード0090を所有していますが、（おそらく）現在の目的のために使用するつもりはありません。
Authors' Addresses
著者のアドレス
Denis Pinkas Bull Rue Jean-Jaures BP 68 78340 Les Clayes-sous-Bois FRANCE
デニス・ピンカス・ブル・ルー・ジャン・ジェアーズBP 68 78340 Les Clayes-Sous-Bois France
EMail: Denis.Pinkas@bull.net
Thomas Gindin IBM Corporation 6710 Rockledge Drive Bethesda, MD 20817 USA
Thomas Gindin IBM Corporation 6710 Rockledge Drive Bethesda、MD 20817 USA
EMail: tgindin@us.ibm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。