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
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.
このドキュメントでは、インターネットコミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めています。 このプロトコルの標準化状態とステータスについては、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
このドキュメントは、エンティティに発行された公開鍵証明書のsubjectAltName拡張に含まれる可能性がある、永続的な識別子と呼ばれる新しい形式の名前を定義します。
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.
永久識別子は、subjectAltName拡張に異なるサブジェクト名（DN）または異なる名前が含まれる場合、または名前または名前が異なる場合でも、2つ以上の証明書が同じエンティティに関連することを示すためにCAによって使用されるオプション機能です 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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「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.
公開鍵証明書のサブジェクトフィールドは、サブジェクト公開キーフィールドに格納されている公開キーに関連付けられたエンティティを識別します。 サブジェクトの名前とIDは、サブジェクトフィールドおよび/または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または割り当て機関と呼ばれる別の組織です。
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（アクセス制御リスト）で使用でき、エンティティのサブジェクト名が変更された場合でも、変更する必要はありません。 否認防止の場合、エンティティのサブジェクト名が変更された場合でも、永続的な識別子を使用して異なるトランザクションを同じエンティティにリンクできます。
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または他のsubjectAltNameコンポーネントの内容に関係なく、永続的な識別子が一致する場合、それらの証明書は同じエンティティに関連付けられます。
Since the use of permanent identifiers may conflict with privacy, CAs SHOULD advertise to purchasers of certificates the use of permanent identifiers in certificates.
永続的な識別子の使用はプライバシーと矛盾する可能性があるため、CAは証明書の購入者に証明書での永続的な識別子の使用を通知する必要があります。
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のGeneralName構造からotherNameの形式として定義された名前です。
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.
identifierValueフィールドが存在する場合、identifierValueは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.
identifierValueフィールドが存在しない場合、サブジェクトDNの最も深いRDNからのserialNumber属性の値（[X.520]のセクション5.2.9で定義）はidentifierValueに使用される値です。 そのような場合、サブジェクトDNには少なくとも1つのserialNumber属性がなければなりません。そうでなければ、PermanentIdentifierを使用しないでください。
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.
割り当て者フィールドが存在する場合、それは名前空間、つまり割り当て者機関とそのフィールドのタイプの両方を識別するOIDです。 特徴的に、OIDのプレフィックスは割り当て機関を識別し、サフィックスは永続的な識別子のタイプを識別するために使用されます。
When the assigner field is absent, then the permanent identifier is locally unique to the CA.
割り当て者フィールドが存在しない場合、永続的な識別子はCAに対してローカルに一意です。
The various combinations are detailed below:
以下に、さまざまな組み合わせの詳細を示します。
1. Both the assigner and the identifierValue fields are present:
1. assignerフィールドとidentifierValueフィールドの両方が存在します。
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.
identifierValueは、そのタイプの識別子の値です。 割り当て者フィールドは、割り当てられる機関と、識別される永続的な識別子のタイプを識別します。
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の間でグローバルに一意です。 そのような場合、このタイプの2つの永続的な識別子は、割り当て者フィールドが一致し、2つの永続的な識別子のidentifierValueフィールドの内容が同じ順序で提示された同じUnicodeコードポイントである場合にのみ一致します。
2. The assigner field is absent and the identifierValue field is present:
2. assignerフィールドが存在せず、identifierValueフィールドが存在します。
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.
Assigner Authorityは、証明書を発行したCAです。 identifierValueは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.
このような場合、X.501で定義されているdistinguishedNameMatchルールを使用して証明書の発行者DNが一致し、identifierValueフィールドの2つの値が同じである場合にのみ、このタイプの2つの永続的な識別子が一致します Unicodeコードポイントは同じ順序で表示されます。
3. Both the assigner and the identifierValue fields are absent:
3. assignerフィールドとidentifierValueフィールドの両方がありません：
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の最も深いserialNumberに含まれる値をidentifierValueとして使用する必要があります。 それ以外の場合、永久識別子の定義は無効であり、永久識別子は使用しないでください。
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が一致し、caseIgnoreMatchルールを使用して同じ証明書のサブジェクトDN内のserialNumber属性も一致する場合にのみ一致します。
4. The assigner field is present and the identifierValue field is absent:
4. assignerフィールドが存在し、identifierValueフィールドが存在しない：
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の最も深いserialNumberに含まれる値をidentifierValueとして使用する必要があります。 それ以外の場合、永久識別子の定義は無効であり、永久識別子は使用しないでください。
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の間でグローバルに一意です。 このような場合、caseIgnoreMatchルールを使用して、割り当て者フィールドが一致し、同じ証明書のサブジェクトDN内のserialNumber属性の内容が一致する場合にのみ、このタイプの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.
永続的な識別子がすべてのCAの間でグローバルに一意である場合（つまり、割り当て者フィールドが存在する場合）、異なるCAからの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.
異なるCAによる同じDNを持つ異なるCAの認証は、特に[RFC3852]セクション10.2.4のIssuerAndSerialNumber構造を曖昧にすることで、PKIのさまざまな部分に他の負の結果をもたらします。
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。、「Cryptographic Message Syntax（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。
Appendix A. ASN.1 Syntax
付録A. ASN.1の構文
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年のUNIVERSAL Type 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構文を使用するモジュールで新しいUNIVERSAL型を使用することは許可されていません。 その結果、このモジュールは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 ASN.1パーサーによって、UNIVERSALタイプの定義を1988キャッチオール「ANY」に置き換えることで解析できます。
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) }
PKIXpermanentidentifier88 {iso（1）特定組織（3）dod（6）インターネット（1）セキュリティ（5）メカニズム（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].
-UTF8String、UTF8Stringがそうでない場合はスラッシュの前にハイフンを移動します-コンパイラーで解決します-このタイプのコンテンツは[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) }
PKIXpermanentidentifier93 {iso（1）特定組織（3）dod（6）インターネット（1）セキュリティ（5）メカニズム（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]
InformationFrameworkからの属性{joint-iso-itu-t ds（5）module（1）informationFramework（1）4}; -[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
終わり
Appendix B. OID's for Organizations
付録B.組織のOID
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.
アサイナーフィールドのOIDを作成するには、組織が最初に登録済みのOIDを所有している必要があります。 このようなOIDは、[X.660]に続く登録機関から取得する必要があります。 場合によっては、OIDは無料で提供されます。 それ以外の場合は、1回限りの料金が必要です。 主な違いは、登録時に収集される情報の性質と、この情報の正確性を検証する方法にあります。
Appendix B.1. Using IANA (Internet Assigned Numbers Authority)
付録B.1。 IANA（Internet Assigned Numbers Authority）を使用する
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に基づく公式の割り当ては、次のURLで入手可能なIANAファイル「enterprise-numbers」に保存されています。http：//www.iana.org/assignments/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 Normalization-ISOのメンバーであるフランスの組織）は、企業にOIDを割り当てるためのアークを定義しています：
{iso (1) member-body (2) fr (250) type-org (1) organisation (n)}
{iso（1）member-body（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は、アーク{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を代表するBritish Standards Institution（BSI）は、{iso（1）org（3）}の下の組織の登録機関です。 つまり、BSIは{iso（1）org（3）icd（xxxx）}の形式のOIDと同等のICD値によってコード発行機関（組織）を登録します。 対応するIdentifierValueは、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登録機関、ウェブ：http：//www.edira.org、email：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レ・クレイ・スー・ボアフランス
EMail: Denis.Pinkas@bull.net
メール：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
メール：tgindin@us.ibm.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（http://www.ietf.org/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のietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。