RFC4043 日本語訳
4043 Internet X.509 Public Key Infrastructure Permanent Identifier. D.Pinkas, T. Gindin. May 2005. (Format: TXT=30092 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Pinkas
Request for Comments: 4043 Bull
Category: Standards Track T. Gindin
IBM
May 2005
コメントを求めるワーキンググループD.ピンカスの要求をネットワークでつないでください: 4043年の雄牛カテゴリ: 標準化過程T.Gindin IBM2005年5月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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.
永久的な識別子は2通以上の証明書が同じ実体に関連するのを示すのにカリフォルニアによって使用されるかもしれないオプション機能です、それらがsubjectAltName拡張子に異なった対象の名前(DNs)か異なった名前を含むか、または対象か別名フォームに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.
発行人名前欄によって定義されるようにもののカリフォルニアによって公認されたそれぞれの対象の実体だけに、対象の分野で運ばれた対象の名前はユニークです。 しかしながら、形成という新しい名前はカリフォルニアによって公認されたそれぞれの対象の実体に、ユニークな名前を運ぶことができます。
Pinkas & Gindin Standards Track [Page 1] RFC 4043 Permanent Identifier May 2005
識別子2005年5月に永久的なピンカスとGindin標準化過程[1ページ]RFC4043
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
1. 序論… 2 2. 永久的な識別子の定義… 3 3. IANA問題… 6 4. セキュリティ問題… 6 5. 参照… 7 5.1. 標準の参照… 7 5.2. 有益な参照… 8 付録A.ASN.1構文… 9 A.1。 1988ASN.1モジュール… 9 A.2。 1993ASN.1モジュール… 10 付録B. OIDは組織のためのものです… 11 B.1。 IANA(インターネット規定番号権威)を使用します… 11 B.2。 ISOメンバーボディーを使用します… 12 B.3。 新しい識別か既存の識別を指定するのに、英国規格協会からICD(国際規約指示子)を使用して、計画してください… 12人の作者のアドレス… 14 完全な著作権宣言文… 15
1. Introduction
1. 序論
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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 MUST、発行人名前欄によって定義されるように単一のカリフォルニアによって公認されたそれぞれの対象の実体において、ユニークであってください。
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.
会社か組織の従業員に関しては、人は、同じ会社の中で異なった位置を得るかもしれなくて、その結果、1つの組織部隊から別の1つまで移行するでしょう。 しかしながら、名前に組織部隊を含んでいるのは、正しい個人を特定するためにパーティー(RPのもの)が使用する信用にその証明書を許容するために非常に役に立つかもしれません。
Pinkas & Gindin Standards Track [Page 2] RFC 4043 Permanent Identifier May 2005
識別子2005年5月に永久的なピンカスとGindin標準化過程[2ページ]RFC4043
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.
永久的な識別子は与えられた命名スペースの中でスペースを命名するそれに、正式の組織によって割り当てられた識別子価値から成ります。 識別子値を割り当てる組織は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.
Assigner Authorityは政府、政府機関、会社、またはいかなる他の種類の組織であるかもしれません。 それには、いかなる他のそのような権威ともそれを区別するユニークな識別子がなければなりません。 この規格では、その識別子はオブジェクト識別子であるに違いありません。
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(アクセスControl List)で使用されるかもしれなくて、変えられる必要はないでしょう、実体の対象の名前が変化しても。 非拒否において、永久的な識別子は異なったトランザクションを同じ実体にリンクするのに使用されるかもしれません、実体の対象の名前が変化すると。
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.
永久的な識別子の使用がプライバシーと衝突するかもしれないので、CAs SHOULDは証明書における永久的な識別子の使用の証明書の購入者に広告を出します。
2. Definition of a Permanent Identifier
2. 永久的な識別子の定義
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].
このPermanent IdentifierはSubjectAltNameのGeneralName構造からotherNameのフォームと定義された名前です、[X.509]と[RFC3280]で定義されるように。
Pinkas & Gindin Standards Track [Page 3] RFC 4043 Permanent Identifier May 2005
識別子2005年5月に永久的なピンカスとGindin標準化過程[3ページ]RFC4043
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.
証明書に永久的な識別子を含んでいるカリフォルニアは、その識別子のための同じ値を含むどんな公開鍵証明書も同じ実体について言及するのを公認しています。
The use of a permanent identifier is OPTIONAL. The permanent identifier is defined as follows:
永久的な識別子の使用はOPTIONALです。 永久的な識別子は以下の通り定義されます:
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
}
permanentIdentifierの上のイドオブジェクト識別子:、:= イドオンな3、PermanentIdentifier:、:= 系列{identifierValue UTF8String OPTIONAL--休むなら、そのような存在している属性があれば、serialNumber属性を使用してください--休むなら、指定人が休むという対象のDN指定人OBJECT IDENTIFIER OPTIONALの証明書発行人}
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属性(.9セクション5.2[X.520]で定義されるように)の値はidentifierValueに取られるべき値です。 少なくとも1つのserialNumber属性がそうでなければ、対象のDN、PermanentIdentifier SHALLにあるに違いありません。使用されません。
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 Authorityとそのタイプがさばく両方)を特定するOIDです。 特徴として、OIDの接頭語はAssigner Authorityを特定します、そして、接尾語は、永久的な識別子のタイプを特定するのに使用されます。
When the assigner field is absent, then the permanent identifier
is locally unique to the CA.
指定人分野が欠けていると、永久的な識別子は局所的にカリフォルニアにユニークです。
The various combinations are detailed below:
様々な組み合わせは以下で詳細です:
1. Both the assigner and the identifierValue fields are present:
1. 指定人と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はそのタイプに関する識別子のための値です。 指定人分野は特定される永久的な識別子のAssigner Authorityとタイプを特定します。
Pinkas & Gindin Standards Track [Page 4] RFC 4043 Permanent Identifier May 2005
識別子2005年5月に永久的なピンカスとGindin標準化過程[4ページ]RFC4043
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.
永久的な識別子はすべてのCAsの中でグローバルにユニークです。 そして、このような場合には、このタイプの2つの永久的な識別子が合わせる、それらの指定人分野が合うだけであるか、そして、2つの永久的な識別子のidentifierValue分野のコンテンツは同次で提示された同じユニコードコード・ポイントから成ります。
2. The assigner field is absent and the identifierValue field is
present:
2. 指定人分野は欠けています、そして、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は証明書を発行したカリフォルニアです。 identifierValueはカリフォルニアによって与えられています、そして、永久的な識別子はローカルであるだけです。証明書を発行したカリフォルニアに。
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つの永久的な識別子が合わせる、発行人DNがそれらを含む証明書にある場合にだけ、X.501で定義されるようにdistinguishedNameMatch規則を使用するマッチとidentifierValue分野の2つの値が同次で提示された同じユニコードコード・ポイントから成ります。
3. Both the assigner and the identifierValue fields are absent:
3. 指定人と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属性(単独の、または、他の属性で伴っている)を含む1RDNsがあれば、値は最も深さのserialNumberにそのようなRDN SHALLを含みました。identifierValueとして、使用されてください。 さもなければ、Permanent Identifier定義は、無効であって、Permanent Identifier SHALLです。使用されません。
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.
永久的な識別子は単に証明書を発行したカリフォルニアにローカルです。 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.
4. The assigner field is present and the identifierValue field is
absent:
4. 指定人分野は存在しています、そして、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属性(単独の、または、他の属性で伴っている)を含む1RDNsがあれば、値は最も深さのserialNumberにそのようなRDN SHALLを含みました。identifierValueとして、使用されてください。 さもなければ、Permanent Identifier定義は、無効であって、Permanent Identifier SHALLです。使用されません。
The assigner field identifies the Assigner Authority and the type
of permanent identifier being identified.
指定人分野は特定される永久的な識別子のAssigner Authorityとタイプを特定します。
Pinkas & Gindin Standards Track [Page 5] RFC 4043 Permanent Identifier May 2005
識別子2005年5月に永久的なピンカスとGindin標準化過程[5ページ]RFC4043
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.
永久的な識別子はすべての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.
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) }
イド-pkix OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)
id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms
イドオンなOBJECT IDENTIFIER:、:= イド-pkix8--他の名前フォーム
3. IANA Considerations
3. IANA問題
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動作も必要ではありません。 しかしながら、兵士のエンタープライズNumberは、指定人分野にOIDを組み立てるのに使用されるかもしれません(Annex B.1を見てください。)。
4. Security Considerations
4. セキュリティ問題
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.
与えられた実体には、時間の瞬間か時間の異なった瞬間に、複数のフォームのアイデンティティがあるかもしれません。 永久的な識別子が局所的にカリフォルニアにユニークであるなら(すなわち、指定人分野は存在していません)、同じカリフォルニアからの当時の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つの同じ永久的な識別子を含んでいると、信用パーティーは、彼らが同じ実体について言及すると決心するかもしれません。 公認されていて、証明書に含まれている永久的な識別子が対象を示すことを確かめるのは、カリフォルニアの責任です。
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.
永久的な識別子はどんな属性拡大の如何にかかわらず実体を特定します。 公開鍵証明書が属性拡大を含むとき、永久的な識別子は存在しているならアクセス管理目的に使用されるべきであるのではなく、監査目的にだけ使用されます。 理由はこれらの属性が変化するかもしれないので元々、その実体に発行された証明書に存在していますが、もう現在の証明書に存在していない属性でアクセスを承諾できたということです。
Pinkas & Gindin Standards Track [Page 6] RFC 4043 Permanent Identifier May 2005
識別子2005年5月に永久的なピンカスとGindin標準化過程[6ページ]RFC4043
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.
証明書の対象の名前は、発行カリフォルニアによって選ばれていて、各カリフォルニアに特有になるように強制されます。 それで、名前衝突は全く対象の名前の間で同じカリフォルニアから来ているはずがありません。 証明書が葉の証明書、またはカリフォルニア名であるときに、そのような名前は終わりの実体名であるかもしれません、それがカリフォルニア証明書であるときに。
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.
いくつかの命名規制が使用されていない場合名前が優れたカリフォルニアに向かってユニークであるだけであるので、名前は優れたCAsというすべての名前の系列を含んでいると考えられるとき、グローバルに特有になるように保証されるだけでしょう。 したがって、同じ発行人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.
追加チェックは、終わって、例えば比較されるために証明書を発行した2CAsの公開鍵値が同じであるか、または信頼アンカーからカリフォルニアまでの証明経路の名前がカリフォルニアの系列であるなら同じであるかをチェックする必要があります。
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.
上のチェックが失敗するとき、カリフォルニアの主要なロールオーバーがあったなら、永久的な識別子はまだ合っているかもしれません。このような場合には照合は、より複雑です。
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との異なったCAsの証明はPKIの様々な部分に他の否定的結果を持っています、[RFC3852]セクション10.2.4におけるIssuerAndSerialNumber構造をあいまいに著しく表して。
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.
永久的な識別子で、組織は有効期間を重ね合わせることのあるなしにかかわらず発行される実体に関連している異なった証明書の間のリンクを作成できます。 異なった証明書をリンクするこの能力はプライバシーと衝突するかもしれません。 したがって、カリフォルニアが明確にそれらの証明書の潜在的対象に永久的な識別子を含んでいる証明書を発行するどんな計画も明らかにするのは、重要です。
5. References
5. 参照
5.1. Normative References
5.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
Pinkas & Gindin Standards Track [Page 7] RFC 4043 Permanent Identifier May 2005
識別子2005年5月に永久的なピンカスとGindin標準化過程[7ページ]RFC4043
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[UTF-8]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[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| ISO9594-2: 2001: 情報技術--オープン・システム・インターコネクション--ディレクトリ: 2001年2月のモデル。
5.2. Informative References
5.2. 有益な参照
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[RFC3852] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、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(1997E): 情報技術--オープン・システム・インターコネクション--ディレクトリ: 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。
Pinkas & Gindin Standards Track [Page 8] RFC 4043 Permanent Identifier May 2005
識別子2005年5月に永久的なピンカスとGindin標準化過程[8ページ]RFC4043
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.
RFC2459のように、ASN.1構文の2つの異なった異形でASN.1モジュールを供給します。
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.
このセクションが中でPKIの部品を従わせることによって使用されるデータ・オブジェクトについて説明する、「ASN.1のようである、」 構文。 この構文は1988年のハイブリッドであり、1993ASN.1は構文です。 1988ASN.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モジュールでの型宣言文の包含を可能にしません、そして、.1規格がする1993ASNは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は、「少しも」UNIVERSAL Typesのための定義を1988年のキャッチにすべて、取り替えることによって、1988年のASN.1-パーサによって分析されるかもしれません。
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。 1988ASN.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) }
PKIXpermanentidentifier88iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズパーマイド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がこのタイプのいずれかの--あなたのコンパイラによる決心--内容をしないならスラッシュが[UTF-8]に従う前にUTF8String、/はハイフンを動かします。
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]
イド-pkix FROM PKIX1Explicit88のiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1明白な(18)。 -- from[RFC3280]
Pinkas & Gindin Standards Track [Page 9] RFC 4043 Permanent Identifier May 2005
識別子2005年5月に永久的なピンカスとGindin標準化過程[9ページ]RFC4043
-- Permanent identifier Object Identifier and Syntax
-- 永久的な識別子のObject IdentifierとSyntax
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
イドオンなOBJECT IDENTIFIER:、:= イド-pkix8
id-on-permanentIdentifier OBJECT IDENTIFIER ::= { id-on 3 }
permanentIdentifierの上のイドオブジェクト識別子:、:= イドオンな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
}
PermanentIdentifier:、:= 系列{identifierValue UTF8String OPTIONAL--休むなら、単一の属性存在しているそのようなものがあれば、serialNumber属性を使用してください--休むなら、指定人が休むという対象のDN指定人OBJECT IDENTIFIER OPTIONALの証明書発行人}
END
終わり
Appendix A.2. 1993 ASN.1 Module
付録A.2。 1993ASN.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) }
PKIXpermanentidentifier93iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イドモッズパーマイド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]
イド-pkix FROM PKIX1Explicit88のiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1明白な(18)--[RFC3280]
ATTRIBUTE
FROM InformationFramework {joint-iso-itu-t ds(5) module(1)
informationFramework(1) 4};
-- from [X.501]
ATTRIBUTE FROM InformationFramework共同iso-itu t ds(5)モジュール(1)informationFramework(1)4。 -- from[X.501]
-- Permanent identifier Object Identifiers
-- 永久的な識別子Object Identifiers
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
イドオンなOBJECT IDENTIFIER:、:= イド-pkix8
id-on-permanentIdentifier OBJECT IDENTIFIER ::= { id-on 3 }
permanentIdentifierの上のイドオブジェクト識別子:、:= イドオンな3
Pinkas & Gindin Standards Track [Page 10] RFC 4043 Permanent Identifier May 2005
識別子2005年5月に永久的なピンカスとGindin標準化過程[10ページ]RFC4043
-- Permanent Identifier
-- 永久的な識別子
permanentIdentifier ATTRIBUTE ::= {
WITH SYNTAX PermanentIdentifier
ID id-on-permanentIdentifier }
permanentIdentifierは以下を結果と考えます:= permanentIdentifierの上の構文PermanentIdentifier IDイド
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
}
PermanentIdentifier:、:= 系列{identifierValue UTF8String OPTIONAL--休むなら、単一の属性存在しているそのようなものがあれば、serialNumber属性を使用してください--休むなら、指定人が休むという対象のDN指定人OBJECT IDENTIFIER OPTIONALの証明書発行人}
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を必要とします。 [X.660]に続く登録局からそのようなOIDを入手しなければなりません。 いくつかの場合、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リストの兵士のエンタープライズNumberのための申込み書は以下の通りです。 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 MIBsを定義するのに特に使用されます。
The official assignments under this OID are stored in the IANA file "enterprise-numbers" available at: http://www.iana.org/assignments/enterprise-numbers
このOIDの下の公式の課題は「企業番号」という利用可能なIANAファイルに以下に保存されます。 http://www.iana.org/assignments/enterprise-numbers
Pinkas & Gindin Standards Track [Page 11] RFC 4043 Permanent Identifier May 2005
識別子2005年5月に永久的なピンカスとGindin標準化過程[11ページ]RFC4043
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がaでOID構造をそのような方法と定義したので、あらゆるISOメンバーボディーには、それ自身のユニークな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の指定代理人のために1問い合せあたり1個のベースで尋問者を請求するのを好んで。 そのような登録を発行しないISO会員会社からのOIDのものの使用はOIDが登録された組織に対応するのを確実にする必要があるカリフォルニアに付加的なコストを課すかもしれません。
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(協会Francaise de Normalisation--ISOのメンバーであるフランスの組織)は会社のためにOIDのものを割り当てるためにアークを定義しました:
{iso (1) member-body (2) fr (250) type-org (1) organisation (n)}
iso(1)メンバーボディー(2)fr(250)タイプ-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.
国際旗信号Designator(ICD)は、唯一ISO6523対応することの組織識別計画を特定するのに使用されます。 ISO6523は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値: 識別計画に発行された国際旗信号Designatorは世界中の識別子をユニークに(最大4ケタ)します。
- the Organization, usually a company or governmental body (up to 35
characters),
- 通常Organization、会社または政府のボディー(最大35のキャラクタ)
Pinkas & Gindin Standards Track [Page 12] RFC 4043 Permanent Identifier May 2005
識別子2005年5月に永久的なピンカスとGindin標準化過程[12ページ]RFC4043
- an Organization Part (OPI - Organization Part Identifier). An
identifier allocated to a particular Organization Part (optional,
up to 35 characters)
- 組織は離れています(OPI--組織部分識別子)。 特定のOrganization Partに割り当てられた識別子(任意35のキャラクタまで)です。
The ICD is also equivalent to an object identifier (OID) under the
arc {1(iso). 3(identified organization)}.
また、ICDもアークの下で物の識別子(OID)に同等である、1、(iso) 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)はアークiso(1)org(3)の下における組織のためのRegistration Authorityです。 これは、BSIがフォームiso(1)org(3) icd(xxxx)のOIDsに同等な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)}.
例として、ICD0012を欧州コンピューター製造者協会に割り当てました: 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との登録のために、「後援権威」はApplying組織を保証しなければなりません。 登録は無料ではありません。 認識された「後援している当局」は以下の通りです。 ISOかTechnical(潜水艦)委員会のどれかがある連絡状態を持っているISOか国際OrganizationsのISO Technical Committeesか(潜水艦)委員会、メンバーBodies。
An example of a Sponsoring Authority is the EDIRA Association (EDI/EC Registration Authority, web: http://www.edira.org, email:info@edira.org).
Sponsoring Authorityに関する例はEDIRA Association(Registration Authorityウェブ: ( http://www.edira.org )がメールするEDI/EC: 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
発行されたすべてのICDsの数字のリストはウェブページに掲示されます: 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を所有していますが、(おそらく)それは現在の目的にそれを使用しないつもりです。
Pinkas & Gindin Standards Track [Page 13] RFC 4043 Permanent Identifier May 2005
識別子2005年5月に永久的なピンカスとGindin標準化過程[13ページ]RFC4043
Authors' Addresses
作者のアドレス
Denis Pinkas Bull Rue Jean-Jaures BP 68 78340 Les Clayes-sous-Bois FRANCE
デニスピンカス雄牛悔悟ジーン-ジョーレスBP68 78340レス・Clayes小銭Boisフランス
EMail: Denis.Pinkas@bull.net
メール: Denis.Pinkas@bull.net
Thomas Gindin IBM Corporation 6710 Rockledge Drive Bethesda, MD 20817 USA
トーマスGindin IBM社6710のRockledge Drive MD20817ベセスダ(米国)
EMail: tgindin@us.ibm.com
メール: tgindin@us.ibm.com
Pinkas & Gindin Standards Track [Page 14] RFC 4043 Permanent Identifier May 2005
識別子2005年5月に永久的なピンカスとGindin標準化過程[14ページ]RFC4043
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Pinkas & Gindin Standards Track [Page 15]
ピンカスとGindin標準化過程[15ページ]
一覧
スポンサーリンク
