RFC2693 日本語訳
2693 SPKI Certificate Theory. C. Ellison, B. Frantz, B. Lampson, R.Rivest, B. Thomas, T. Ylonen. September 1999. (Format: TXT=96699 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Ellison
Request for Comments: 2693 Intel
Category: Experimental B. Frantz
Electric Communities
B. Lampson
Microsoft
R. Rivest
MIT Laboratory for Computer Science
B. Thomas
Southwestern Bell
T. Ylonen
SSH
September 1999
コメントを求めるワーキンググループC.エリソン要求をネットワークでつないでください: 2693年のインテルカテゴリ: 共同体B.ランプソンマイクロソフトR.Rivest MITコンピュータサイエンス研究所B.トーマスサウスウェスタンベル社T.Ylonenセキュアシェル (SSH)1999年9月の電気の実験的なB.フランツ
SPKI Certificate Theory
SPKI証明書理論
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
The SPKI Working Group has developed a standard form for digital certificates whose main purpose is authorization rather than authentication. These structures bind either names or explicit authorizations to keys or other objects. The binding to a key can be directly to an explicit key, or indirectly through the hash of the key or a name for it. The name and authorization structures can be used separately or together. We use S-expressions as the standard format for these certificates and define a canonical form for those S-expressions. As part of this development, a mechanism for deriving authorization decisions from a mixture of certificate types was developed and is presented in this document.
SPKI作業部会は主な目的が認証よりむしろ承認であるデジタル証明書のために標準形式を開発しました。 これらの構造は名前か明白な承認のどちらかをキーか他のオブジェクトに縛ります。 間接的に直接明白なキーか、キーのハッシュかそれのための名前を通してキーとの結合があることができます。 名前と承認構造を別々にか一緒に使用できます。 私たちは、これらの証明書に標準書式としてS-式を使用して、それらのS-式のために標準形を定義します。 この開発の一部として、証明書タイプの混合物から承認決定を得るためのメカニズムは、開発されて、本書では提示されます。
This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses.
このドキュメントは技術的になることのないSPKI証明書とACLsの後ろの理論にそれらの構造か彼らの用途に関する詳細を述べます。
Ellison, et al. Experimental [Page 1] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[1ページ]RFC2693SPKIは理論1999年9月を証明します。
Table of Contents
目次
1. Overview of Contents.......................................3 1.1 Glossary..................................................4 2. Name Certification.........................................5 2.1 First Definition of CERTIFICATE...........................6 2.2 The X.500 Plan and X.509..................................6 2.3 X.509, PEM and PGP........................................7 2.4 Rethinking Global Names...................................7 2.5 Inescapable Identifiers...................................9 2.6 Local Names..............................................10 2.6.1 Basic SDSI Names.......................................10 2.6.2 Compound SDSI Names....................................10 2.7 Sources of Global Identifiers............................11 2.8 Fully Qualified SDSI Names...............................11 2.9 Fully Qualified X.509 Names..............................12 2.10 Group Names.............................................12 3. Authorization.............................................12 3.1 Attribute Certificates...................................13 3.2 X.509v3 Extensions.......................................13 3.3 SPKI Certificates........................................14 3.4 ACL Entries..............................................15 4. Delegation................................................15 4.1 Depth of Delegation......................................15 4.1.1 No control.............................................15 4.1.2 Boolean control........................................16 4.1.3 Integer control........................................16 4.1.4 The choice: boolean....................................16 4.2 May a Delegator Also Exercise the Permission?............17 4.3 Delegation of Authorization vs. ACLs.....................17 5. Validity Conditions.......................................18 5.1 Anti-matter CRLs.........................................18 5.2 Timed CRLs...............................................19 5.3 Timed Revalidations......................................20 5.4 Setting the Validity Interval............................20 5.5 One-time Revalidations...................................20 5.6 Short-lived Certificates.................................21 5.7 Other possibilities......................................21 5.7.1 Micali's Inexpensive On-line Results...................21 5.7.2 Rivest's Reversal of the CRL Logic.....................21 6. Tuple Reduction...........................................22 6.1 5-tuple Defined..........................................23 6.2 4-tuple Defined..........................................24 6.3 5-tuple Reduction Rules..................................24 6.3.1 AIntersect.............................................25 6.3.2 VIntersect.............................................27 6.3.3 Threshold Subjects.....................................27 6.3.4 Certificate Path Discovery.............................28
1. コンテンツの概要…3 1.1用語集…4 2. 証明を命名してください…5 証明書の2.1/1定義…6 2.2 X.500プランとX.509…6 2.3のX.509、PEM、およびPGP…7 2.4 意識改革グローバル名…7 2.5の不可避的な識別子…9 2.6 ローカルの名前…10 2.6 .1 基本的なSDSI名…10 2.6 .2 SDSI名を合成してください…10 グローバルな識別子の2.7の源…11 2.8はSDSI名に完全に資格を与えました…11 2.9はX.509名に完全に資格を与えました…12 2.10のグループ名…12 3. 承認…12 3.1 証明書を結果と考えてください…13 3.2 X.509v3拡張子…13 3.3 SPKI証明書…14 3.4 ACLエントリー…15 4. 委譲…15 4.1 委譲の深さ…15 4.1 .1 コントロールがありません…15 4.1 .2 ブールコントロール…16 4.1 .3 整数コントロール…16 4.1 .4 選択: 論理演算子…16 4.2 また、Delegatorは許可を運動させるかもしれませんか?17 承認対ACLsの4.3委譲…17 5. 正当性状態…18 5.1 反物質CRLs…18 5.2 CRLsは調節しました…19 5.3 Revalidationsは調節しました…20 5.4 正当性間隔を設定します…20 5.5 1回のRevalidations…20 5.6通の短命な証明書…21 他の5.7の可能性…21 5.7 .1 Micaliの安価なオンライン結果…21 5.7 .2 最もRivestであるのは、CRL論理の反転です…21 6. Tuple減少…22 定義された6.1 5-tuple…23 定義された6.2 4-tuple…24 6.3 5-tuple減少は統治されます…24 6.3 .1AIntersect…25 6.3 .2VIntersect…27 6.3 .3 敷居対象…27 6.3 .4 経路発見を証明してください…28
Ellison, et al. Experimental [Page 2] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[2ページ]RFC2693SPKIは理論1999年9月を証明します。
6.4 4-tuple Reduction........................................28 6.4.1 4-tuple Threshold Subject Reduction....................29 6.4.2 4-tuple Validity Intersection..........................29 6.5 Certificate Translation..................................29 6.5.1 X.509v1................................................29 6.5.2 PGP....................................................30 6.5.3 X.509v3................................................30 6.5.4 X9.57..................................................30 6.5.5 SDSI 1.0...............................................30 6.5.6 SPKI...................................................31 6.5.7 SSL....................................................31 6.6 Certificate Result Certificates..........................32 7. Key Management............................................33 7.1 Through Inescapable Names................................33 7.2 Through a Naming Authority...............................33 7.3 Through <name,key> Certificates..........................34 7.4 Increasing Key Lifetimes.................................34 7.5 One Root Per Individual..................................35 7.6 Key Revocation Service...................................36 7.7 Threshold ACL Subjects...................................36 8. Security Considerations...................................37 References...................................................38 Acknowledgments..............................................40 Authors' Addresses...........................................41 Full Copyright Statement.....................................43
6.4 4-tuple減少…28 6.4.1 4-tuple敷居対象減少…29 6.4.2 4-tuple正当性交差点…29 6.5 翻訳を証明してください…29 6.5 .1X.509v1…29 6.5 .2PGP…30 6.5 .3X.509v3…30 6.5 .4X9.57…30 6.5 .5 SDSI1.0…30 6.5 .6SPKI…31 6.5 .7SSL…31 6.6 結果証明書を証明してください…32 7. 主要な管理…33 7.1 不可避的な名前を通して…33 7.2 命名権威を通して…33 7.3 <名、主要な>証明書を通して…34 7.4 主要な生涯を増強します…34 1個人あたりの7.5 1つの根…35 7.6 主要な取消しサービス…36 7.7 敷居ACL対象…36 8. セキュリティ問題…37の参照箇所…38の承認…40人の作者のアドレス…41 完全な著作権宣言文…43
1. Overview of Contents
1. コンテンツの概要
This document contains the following sections:
このドキュメントは以下のセクションを含みます:
Section 2: history of name certification, from 1976 on.
セクション2: 1976年からの名前証明の歴史。
Section 3: discussion of authorization, rather than authentication, as the desired purpose of a certificate.
セクション3: 証明書の必要な目的としての認証よりむしろ承認の議論。
Section 4: discussion of delegation.
セクション4: 委譲の議論。
Section 5: discussion of validity conditions: date ranges, CRLs, re- validations and one-time on-line validity tests.
セクション5: 正当性状態の議論: 範囲、CRLs、再合法化、および1回のオンライン正当性をテストとデートしてください。
Section 6: definition of 5-tuples and their reduction.
セクション6: 5-tuplesの定義とそれらの減少。
Section 7: discussion of key management.
セクション7: かぎ管理の議論。
Section 8: security considerations.
セクション8: セキュリティ問題。
Ellison, et al. Experimental [Page 3] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[3ページ]RFC2693SPKIは理論1999年9月を証明します。
The References section lists all documents referred to in the text as well as readings which might be of interest to anyone reading on this topic.
References部はこの話題を読み続けるだれにとっても、興味深いかもしれない読書と同様にテキストで参照されたすべてのドキュメントをリストアップします。
The Acknowledgements section, including a list of contributors primarily from the start of the working group. [The archive of working group mail is a more accurate source of contributor information.]
主としてワーキンググループの始まるのからの貢献者のリストを含むAcknowledgements部。 [ワーキンググループメールのアーカイブは貢献者情報の、より正確な源です。]
The Authors' Addresses section gives the addresses, telephone numbers and e-mail addresses of the authors.
AuthorsのAddresses部は作者のアドレス、電話番号、およびEメールアドレスを与えます。
1.1 Glossary
1.1 用語集
We use some terms in the body of this document in ways that could be specific to SPKI:
私たちはSPKIに特定であるかもしれない方法でこのドキュメントのボディーのいくつかの用語を使用します:
ACL: an Access Control List: a list of entries that anchors a certificate chain. Sometimes called a "list of root keys", the ACL is the source of empowerment for certificates. That is, a certificate communicates power from its issuer to its subject, but the ACL is the source of that power (since it theoretically has the owner of the resource it controls as its implicit issuer). An ACL entry has potentially the same content as a certificate body, but has no Issuer (and is not signed). There is most likely one ACL for each resource owner, if not for each controlled resource.
ACL: アクセスコントロールリスト: 証明書チェーンを据えつけるエントリーのリスト。 時々「ルートキーのリスト」、ACLと呼ばれているのは、証明書のための権限委譲の源です。 すなわち、証明書は発行人から対象までパワーを伝えますが、ACLはそのパワーの源(リソースの所有者が理論的にいるので、それは暗黙の発行人として制御される)です。 ACLエントリーには、潜在的に証明書ボディーと同じ内容を持っていますが、Issuer(そして、署名されない)は全くありません。 たぶんそれぞれのリソース所有者、またはそれぞれの制御リソースあたり1ACLがあります。
CERTIFICATE: a signed instrument that empowers the Subject. It contains at least an Issuer and a Subject. It can contain validity conditions, authorization and delegation information. Certificates come in three categories: ID (mapping <name,key>), Attribute (mapping <authorization,name>), and Authorization (mapping <authorization,key>). An SPKI authorization or attribute certificate can pass along all the empowerment it has received from the Issuer or it can pass along only a portion of that empowerment.
以下を証明してください。 Subjectに権限を与える署名している器具。 それは少なくともIssuerとSubjectを含んでいます。 それは正当性状態、承認、および委譲情報を含むことができます。 証明書は3つのカテゴリに入ります: (マッピング<名、主要な>)が結果と考えるID(<承認を写像して、>を命名する)、および承認(<承認、主要な>を写像します)。 SPKI承認か属性証明書がそれがIssuerから受けたすべての権限委譲を回すことができますか、またはそれはその権限委譲の部分しか回すことができません。
ISSUER: the signer of a certificate and the source of empowerment that the certificate is communicating to the Subject.
発行人: 証明書がSubjectに伝えている証明書の署名者と権限委譲の源。
KEYHOLDER: the person or other entity that owns and controls a given private key. This entity is said to be the keyholder of the keypair or just the public key, but control of the private key is assumed in all cases.
KEYHOLDER: 与えられた秘密鍵を所有して、制御する人か他の実体。 この実体はkeypairかまさしく公開鍵のkeyholderであると言われていますが、秘密鍵のコントロールはすべての場合で想定されます。
PRINCIPAL: a cryptographic key, capable of generating a digital signature. We deal with public-key signatures in this document but any digital signature method should apply.
主体: デジタル署名を生成することができる暗号化キー。 私たちは本書では公開鍵署名に対処しますが、どんなデジタル署名メソッドも適用されるべきです。
Ellison, et al. Experimental [Page 4] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[4ページ]RFC2693SPKIは理論1999年9月を証明します。
SPEAKING: A Principal is said to "speak" by means of a digital signature. The statement made is the signed object (often a certificate). The Principal is said to "speak for" the Keyholder.
話します: プリンシパルはデジタル署名による「話す」と言われています。 出された声明は署名しているオブジェクト(しばしば証明書)です。 プリンシパルはKeyholderを「代弁する」と言われています。
SUBJECT: the thing empowered by a certificate or ACL entry. This can be in the form of a key, a name (with the understanding that the name is mapped by certificate to some key or other object), a hash of some object, or a set of keys arranged in a threshold function.
SUBJECT: 証明書かACLエントリーで権限を与えられたもの。 これはしきい値関数でアレンジされたキー、名前(名前が証明書によって、ある主要であるか他のオブジェクトに写像されるという条件による)、あるオブジェクトのハッシュ、または1セットのキーの形にあることができます。
S-EXPRESSION: the data format chosen for SPKI/SDSI. This is a LISP- like parenthesized expression with the limitations that empty lists are not allowed and the first element in any S-expression must be a string, called the "type" of the expression.
S-式: SPKI/SDSIに選ばれたデータの形式。 式の「タイプ」は、これが空のリストが許容されていない制限があるparenthesized式とどんなS-式でも最初の要素がストリングであるに違いないようにLISPであると呼びました。
THRESHOLD SUBJECT: a Subject for an ACL entry or certificate that specifies K of N other Subjects. Conceptually, the power being transmitted to the Subject by the ACL entry or certificate is transmitted in (1/K) amount to each listed subordinate Subject. K of those subordinate Subjects must agree (by delegating their shares along to the same object or key) for that power to be passed along. This mechanism introduces fault tolerance and is especially useful in an ACL entry, providing fault tolerance for "root keys".
敷居SUBJECT: 他のN SubjectsのKを指定するACLエントリーか証明書のためのSubject。 概念的に、ACLエントリーか証明書によってSubjectに伝えられるパワーは(1/K)量でそれぞれの記載された下位のSubjectに伝えられます。 それらの下位のSubjectsのKはその回されるべきパワーのために同意しなければなりません(ずっと同じオブジェクトかキーへ彼らのシェアを代表として派遣することによって)。 「ルートキー」に耐障害性を提供して、このメカニズムは、耐障害性を導入して、ACLエントリーで特に役に立ちます。
2. Name Certification
2. 名前証明
Certificates were originally viewed as having one function: binding names to keys or keys to names. This thought can be traced back to the paper by Diffie and Hellman introducing public key cryptography in 1976. Prior to that time, key management was risky, involved and costly, sometimes employing special couriers with briefcases handcuffed to their wrists.
証明書は元々、1つの機能を持っていると見なされました: 名前のキーかキーに名前を縛ります。 1976年に公開鍵暗号を紹介するディフィーとヘルマンによる紙に戻った状態でこの考えをたどることができます。 その時以前、かぎ管理は、危険で、かかわって高価でした、彼らの手首に手錠をかけられるブリーフケースと共に特別な急使を時々雇って。
Diffie and Hellman thought they had radically solved this problem. "Given a system of this kind, the problem of key distribution is vastly simplified. Each user generates a pair of inverse transformations, E and D, at his terminal. The deciphering transformation, D, must be kept secret but need never be communicated on any channel. The enciphering key, E, can be made public by placing it in a public directory along with the user's name and address. Anyone can then encrypt messages and send them to the user, but no one else can decipher messages intended for him." [DH]
ディフィーとヘルマンは、彼らがこの問題を根本的に解決したと考えました。 「この種類のシステムを考えて、主要な分配の問題は広大に簡素化されます。」 各ユーザは彼の端末で1組の逆変換、E、およびDを生成します。 解読変換(D)を、秘密にしなければなりませんが、どんなチャンネルの上にも決して伝えてはいけません。 ユーザの名前とアドレスに伴う公共のディレクトリにそれを置くことによって、暗号化キー(E)を公表できます。 「だれでも、次に、メッセージを暗号化して、それらをユーザに送ることができますが、他の誰もは彼のために意図するメッセージを解読しないことができません。」 [DH]
This modified telephone book, fully public, took the place of the trusted courier. This directory could be put on-line and therefore be available on demand, worldwide. In considering that prospect, Loren Kohnfelder, in his 1978 bachelor's thesis in electrical engineering from MIT [KOHNFELDER], noted: "Public-key communication works best when the encryption functions can reliably be shared among
この変更された完全に公共の電話帳は信じられた急使の代理をしました。 このディレクトリは、オンラインで置かれて、したがって、世界中の要求のときに利用可能であるかもしれません。 見通し(MIT[KOHNFELDER]からの電気工学の1978年の彼の独身の論文のロレーンKohnfelder)が注意した考慮で: 「暗号化機能で確かに共有できるとき、公開鍵コミュニケーションはうまくいきます」
Ellison, et al. Experimental [Page 5] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[5ページ]RFC2693SPKIは理論1999年9月を証明します。
the communicants (by direct contact if possible). Yet when such a reliable exchange of functions is impossible the next best thing is to trust a third party. Diffie and Hellman introduce a central authority known as the Public File."
聖餐拝受者(できれば、接触を指示します)。 しかし、次善の策は機能のそのような信頼できる交換が不可能であるときに、第三者を信じることです。 「ディフィーとヘルマンはPublic Fileとして知られている主要な権威を紹介します。」
2.1 First Definition of CERTIFICATE
証明書の2.1/1定義
Kohnfelder then noted, "Each individual has a name in the system by which he is referenced in the Public File. Once two communicants have gotten each other's keys from the Public File they can securely communicate. The Public File digitally signs all of its transmissions so that enemy impersonation of the Public File is precluded." In an effort to prevent performance problems, Kohnfelder invented a new construct: a digitally signed data record containing a name and a public key. He called this new construct a CERTIFICATE. Because it was digitally signed, such a certificate could be held by non-trusted parties and passed around from person to person, resolving the performance problems involved in a central directory.
そして、「各個人には、彼がPublic Fileで参照をつけられるシステムの名前があります。」と、Kohnfelderは述べました。 一度、2人の聖餐拝受者が彼らがしっかりと伝えることができるPublic Fileから互いのキーを手に入れたことがあります。 「Public Fileがトランスミッションのすべてにデジタルに署名するので、Public Fileの敵のものまねは排除されます。」 性能問題を防ぐ取り組みでは、Kohnfelderは新しい構造物を発明しました: 名前と公開鍵を含むデジタルに署名しているデータレコード。 彼は、この新しい構造物をCERTIFICATEと呼びました。 それがデジタルに署名されたので、そのような証明書を非信じられたパーティーが保持して、人から人まで回すことができました、主要なディレクトリにかかわる性能問題を解決して。
2.2 The X.500 Plan and X.509
2.2 X.500プランとX.509
Ten years after Kohnfelder's thesis, the ISO X.509 recommendation was published as part of X.500. X.500 was to be a global, distributed database of named entities: people, computers, printers, etc. In other words, it was to be a global, on-line telephone book. The organizations owning some portion of the name space would maintain that portion and possibly even provide the computers on which it was stored. X.509 certificates were defined to bind public keys to X.500 path names (Distinguished Names) with the intention of noting which keyholder had permission to modify which X.500 directory nodes. In fact, the X.509 data record was originally designed to hold a password instead of a public key as the record-access authentication mechanism.
Kohnfelderの論文の10年後に、ISO X.509推薦はX.500の一部として発行されました。 X.500はaグローバルであることになってい、命名されることの分散データベースは実体です: 人々、コンピュータ、プリンタなど 言い換えれば、それによるグローバルで、オンラインの電話帳でした。 スペースという名前の何らかの部分を所有している組織は、その部分を維持して、ことによると、それが格納されたコンピュータを提供さえするでしょう。 X.509証明書は、どのkeyholderにどのX.500ディレクトリノードを変更するか許可があったかに注意するという意志でX.500パス名(Namesを区別する)に公開鍵を縛るために定義されました。 事実上、X.509データレコードは、元々、記録的なアクセス認証機構としての公開鍵の代わりにパスワードを保持するように設計されました。
The original X.500 plan is unlikely ever to come to fruition. Collections of directory entries (such as employee lists, customer lists, contact lists, etc.) are considered valuable or even confidential by those owning the lists and are not likely to be released to the world in the form of an X.500 directory sub-tree. For an extreme example, imagine the CIA adding its directory of agents to a world-wide X.500 pool.
オリジナルのX.500プランはかつて実を結びそうにはありません。 ディレクトリエントリー(従業員リスト、顧客リスト、コンタクトリストなどの)の収集は、貴重であるか、または秘密でさえあるとリストを所有しているものによって考えられて、X.500ディレクトリ下位木の形で世界にリリースされそうにはありません。 極端な例に関しては、CIAが世界的なX.500プールにエージェントのディレクトリを加えると想像してください。
The X.500 idea of a distinguished name (a single, globally unique name that everyone could use when referring to an entity) is also not likely to occur. That idea requires a single, global naming discipline and there are too many entities already in the business of defining names not under a single discipline. Legacy therefore militates against such an idea.
また、分類名(実体について言及するとき皆が使用できた単一の、そして、グローバルにユニークな名前)のX.500考えも起こりそうにはありません。 その考えはシングルを必要とします、グローバルな命名規律、既に定義名のビジネスにはあまりに多くの実体がどんなただ一つの規律の下にもありません。 したがって、遺産はそのような考えに影響します。
Ellison, et al. Experimental [Page 6] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[6ページ]RFC2693SPKIは理論1999年9月を証明します。
2.3 X.509, PEM and PGP
2.3 X.509、PEM、およびPGP
The Privacy Enhanced Mail [PEM] effort of the Internet Engineering Task Force [RFC1114] adopted X.509 certificates, but with a different interpretation. Where X.509 was originally intended to mean "the keyholder may modify this portion of the X.500 database", PEM took the certificate to mean "the key speaks for the named person". What had been an access control instrument was now an identity instrument, along the lines envisioned by Diffie, Hellman and Kohnfelder.
X.509証明書を採用しましたが、インターネット・エンジニアリング・タスク・フォース[RFC1114]のPrivacy Enhancedメール[PEM]の努力は異なった解釈でそうしました。 元々X.509が、「keyholderはX.500データベースのこの部分を変更するかもしれません」と意味することを意図したところでは、PEMは、「キーは命名された人を代弁します」と意味するために証明書を取りました。 現在アクセス管理器具であったことはアイデンティティ器具でした、ディフィー、ヘルマン、およびKohnfelderによって思い描かれた線に沿って。
The insistence on X.509 certificates with a single global root delayed PEM's adoption past its window of viability. RIPEM, by Mark Riordan of MSU, was a version of PEM without X.509 certificates. It was distributed and used by a small community, but fell into disuse. MOSS (a MIME-enhanced version of PEM, produced by TIS (www.tis.com)) made certificate use optional, but received little distribution.
ただ一つのグローバルな根があるX.509証明書の主張は生存力の窓の先でPEMの採用を遅らせました。 MSUのマーク・リオーダンで、RIPEMはX.509証明書のないPEMのバージョンでした。 それは、小規模地域社会によって分配されて、使用されましたが、不要になりました。 モス(TIS(www.tis.com)によって生産されたPEMのMIMEで高められたバージョン)は、証明書使用を任意にしましたが、ほとんど分配を受けませんでした。
At about the same time, in 1991, Phil Zimmermann's PGP was introduced with a different certificate model. Instead of waiting for a single global root and the hierarchy of Certificate Authorities descending from that root, PGP allowed multiple, (hopefully) independent but not specially trusted individuals to sign a <name,key> association, attesting to its validity. The theory was that with enough such signatures, that association could be trusted because not all of these signer would be corrupt. This was known as the "web of trust" model. It differed from X.509 in the method of assuring trust in the <name,key> binding, but it still intended to bind a globally unique name to a key. With PEM and PGP, the intention was for a keyholder to be known to anyone in the world by this certified global name.
ほぼ同じ頃、1991年に、異なった証明書モデルと共にフィルZimmermannのPGPを導入しました。 ただ一つのグローバルな根とその根から離すCertificate Authoritiesの階層構造を待つことの代わりに、PGPは複数の、そして、(希望をいだいて)独立していますが、特に、信じられなかった個人に<名を調印させました、主要な>協会、正当性を証明して。 理論はこれらの署名者のすべてが不正であるというわけではないでしょう、したがって、署名、十分なそのようなものとのその協会を信じることができたということでした。 これは「信用のウェブ」モデルとして知られていました。 それは<名への信用を保証する方法でX.509と異なっていました、主要な>結合、しかし、それがまだグローバルにユニークな名前をキーに縛っているつもりでした。 PEMとPGPと共に、意志はkeyholderが世界でだれにとってもこの公認されたグローバル名によって知られていることでした。
2.4 Rethinking Global Names
2.4 意識改革グローバル名
The assumption that the job of a certificate was to bind a name to a key made sense when it was first published. In the 1970's, people operated in relatively small communities. Relationships formed face to face. Once you knew who someone was, you often knew enough to decide how to behave with that person. As a result, people have reduced this requirement to the simply stated: "know who you're dealing with".
それが最初に発行されたとき、証明書の仕事がキーに名前を縛ることであったという仮定は理解できました。 1970年代に、人々は比較的小さい共同体で働いていました。 関係は面と向かって形成されました。 一度、あなたは、しばしばだれかがだれであるかをその人と共に振る舞う方法を決めることができるくらい知っていたんでしょう? その結果、人々は単に述べられているのにこの要件を減らしました: 「だれに対応しているかを知ってください。」
Names, in turn, are what we humans use as identifiers of persons. We learn this practice as infants. In the family environment names work as identifiers, even today. What we learn as infants is especially difficult to re-learn later in life. Therefore, it is natural for people to translate the need to know who the keyholder is into a need to know the keyholder's name.
名前は順番に私たち人間が人々の識別子として使用するものです。 私たちは幼児としてこの習慣を学びます。 家庭環境では、名前は今日のさえ識別子として働いています。 私たちが幼児として学ぶことは人生で後で再学ぶのが特に難しいです。 したがって、人々がkeyholderがkeyholderの名前を知る必要性へのだれであるかを知る必要性を翻訳するのは、当然です。
Ellison, et al. Experimental [Page 7] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[7ページ]RFC2693SPKIは理論1999年9月を証明します。
Computer applications need to make decisions about keyholders. These decisions are almost never made strictly on the basis of a keyholder's name. There is some other fact about the keyholder of interest to the application (or to the human being running the application). If a name functions at all for security purposes, it is as an index into some database (or human memory) of that other information. To serve in this role, the name must be unique, in order to serve as an index, and there must be some information to be indexed.
コンピュータアプリケーションは、keyholdersに関する決定をする必要があります。 keyholderの名前に基づいてほとんど厳密にこれらの決定をしません。 アプリケーション(またはアプリケーションを実行している人間に)に興味があるkeyholderに関するある他の事実があります。 名前がセキュリティ目的のために少しでも機能するなら、インデックスとしてその他の情報に関する何らかのデータベース(または、人間のメモリ)にはそれがあります。 この役割、名前に役立つように、インデックスとして機能するようにユニークでなければならなく、何らかの索引をつけられるべき情報があるに違いありません。
The names we use to identify people are usually unique, within our local domain, but that is not true on a global scale. It is extremely unlikely that the name by which we know someone, a given name, would function as a unique identifier on the Internet. Given names continue to serve the social function of making the named person feel recognized when addressed by name but they are inadequate as the identifiers envisioned by Diffie, Hellman and Kohnfelder.
私たちが人々を特定するのに使用する名前は私たちの局所領域の中で通常ユニークですが、それは世界的規模で本当ではありません。 名という私たちが知っているだれかの名前がインターネットに関するユニークな識別子として機能するのは、非常にありそうもないです。 名はずっと命名された人に名前によって記述されると認識されると感じさせる社会的機能に役立ちますが、それらはディフィー、ヘルマン、およびKohnfelderによって思い描かれた識別子として不十分です。
In the 1970's and even through the early 1990's, relationships formed in person and one could assume having met the keyholder and therefore having acquired knowledge about that person. If a name could be found that was an adequate identifier of that keyholder, then one might use that name to index into memories about the keyholder and then be able to make the relevant decision.
1970年代と、そして、1990年代さえ前半を通して、関係は自分で形成されて、人は有はその人に関してkeyholderに会って、したがって、有の後天的な知識に会ったと仮定できました。 そのkeyholderの適切な識別子であった名前を見つけることができるなら、1つは、keyholderに関する思い出に索引をつけて、次に、関連決定をすることができるようにその名前を使用するでしょうに。
In the late 1990's, this is no longer true. With the explosion of the Internet, it is likely that one will encounter keyholders who are complete strangers in the physical world and will remain so. Contact will be made digitally and will remain digital for the duration of the relationship. Therefore, on first encounter there is no body of knowledge to be indexed by any identifier.
1990年代後半に、これはもう本当ではありません。 インターネットの爆発で、1つは、物理的な世界で赤の他人であるkeyholdersに遭遇するので、残りそうでしょう。 接触は、デジタルに作られて、関係の持続時間にデジタルであるままで残るでしょう。 したがって、最初の遭遇には、どんな識別子によっても索引をつけられるために、一連の知識が全くありません。
One might consider building a global database of facts about all persons in the world and making that database available (perhaps for a fee). The name that indexes that database might also serve as a globally unique ID for the person referenced. The database entry under that name could contain all the information needed to allow someone to make a security decision. Since there are multiple decision-makers, each interested in specific information, the database would need to contain the union of multiple sets of information. However, that solution would constitute a massive privacy violation and would probably be rejected as politically impossible.
人は、世界のすべての人々に関する事実のグローバルなデータベースを築き上げて、そのデータベースを利用可能に(恐らく有料)すると考えるかもしれません。 また、そのデータベースに索引をつける名前は参照をつけられる人にとって、グローバルにユニークなIDとして機能するかもしれません。 その名前の下のデータベースエントリーはだれかがセキュリティ決定をするのを許容するのに必要であるすべての情報を含むかもしれません。 それぞれ特殊情報に興味を持っている複数の意思決定者がいるので、データベースは、複数のセットの情報の組合を含む必要があるでしょう。 しかしながら、その解決策は、大規模なプライバシー違反を構成して、たぶん政治的に不可能であると拒絶されるでしょう。
A globally unique ID might even fail when dealing with people we do know. Few of us know the full given names of people with whom we deal. A globally unique name for a person would be larger than the full given name (and probably contain it, out of deference to a
私たちが知っている人々に対応するとき、グローバルにユニークなIDは失敗さえするかもしれません。 私たちがだれを取扱うかと共に私たちのわずかしか人々の完全な名を知りません。 人にとって、グローバルにユニークな名前が完全な名より大きいだろう、(たぶん服従の外にaにそれを含んでください。
Ellison, et al. Experimental [Page 8] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[8ページ]RFC2693SPKIは理論1999年9月を証明します。
person's fondness for his or her own name). It would therefore not be a name by which we know the person, barring a radical change in human behavior.
その人の自己の名前に関する人の愛好心) したがって、それは人間挙動における根本的な変更を禁じて、私たちが知っている人の名前でないでしょう。
A globally unique ID that contains a person's given name poses a special danger. If a human being is part of the process (e.g., scanning a database of global IDs in order to find the ID of a specific person for the purpose of issuing an attribute certificate), then it is likely that the human operator would pay attention to the familiar portion of the ID (the common name) and pay less attention to the rest. Since the common name is not an adequate ID, this can lead to mistakes. Where there can be mistakes, there is an avenue for attack.
人の名を含むグローバルにユニークなIDは特別な危険を引き起こします。 人間が過程(例えば、属性証明書を発行する目的のために特定の人のIDを見つけるためにグローバルなIDに関するデータベースをスキャンする)の一部であるなら、人間のオペレータは、ID(一般名)の身近な部分に注意を向けて、残りは注意を向けそうにないでしょう。 一般名が適切なIDでないので、これは誤りに通じることができます。 誤りがあることができるところに、攻撃のための大通りがあります。
Where globally unique identifiers need to be used, perhaps the best ID is one that is uniform in appearance (such as a long number or random looking text string) so that it has no recognizable sub-field. It should also be large enough (from a sparse enough name space) that typographical errors would not yield another valid identifier.
グローバルにユニークであるところでは、使用されるべき識別子の必要性、恐らく最も良いIDが外観(長い番号か無作為の見るテキスト文字列などの)で一定のものであるので、それがどんな認識可能なサブ分野も持っていません。 また、誤字が別の有効な識別子をもたらさないほどそれも大きいはずです(十分まばらな名前スペースからの)。
2.5 Inescapable Identifiers
2.5 不可避的な識別子
Some people speak of global IDs as if they were inescapable identifiers, able to prevent someone from doing evil under one name, changing his name and starting over again. To make that scenario come true, one would have to have assignment of such identifiers (probably by governments, at birth) and some mechanism so that it is always possible to get from any flesh and blood person back to his or her identifier. Given that latter mechanism, any Certificate Authority desiring to issue a certificate to a given individual would presumably choose the same, inescapable name for that certificate. A full set of biometrics might suffice, for example, to look up a person without danger of false positive in a database of globally assigned ID numbers and with that procedure one could implement inescapable IDs.
何人かの人々がまるでそれらが不可避的な識別子であるかのようにグローバルなIDについて話します、だれかが1つ未満の名前を悪にするのを防ぐことができます、改名して、最初からやり直して。 1つには、そのシナリオが実現させるように、そのような識別子(たぶん出生の政府による)の課題と何らかのメカニズムがなければならないでしょう、したがって、それはどんな生身の人間人からその人の識別子までも得るのにおいていつも可能です。 その後者のメカニズムを考えて、おそらく、与えられた個人に証明書を下付することを望んでいるどんなCertificate Authorityも同じように選ぶでしょう、その証明書のための不可避的な名前。 生体認証のフルセットは十分であるかもしれません、例えば、無病誤診というデータベースにおける危険なしでグローバルに割り当てられたID番号とその手順1で人を訪ねるのは不可避的なIDを実行するかもしれません。
The use of an inescapable identifier might be possible in some countries, but in others (such as the US) it would meet strong political opposition. Some countries have government-assigned ID numbers for citizens but also have privacy regulations that prohibit the use of those numbers for routine business. In either of these latter cases, the inescapable ID would not be available for use in routine certificates.
不可避的な識別子の使用はいくつかの国で可能であるかもしれませんが、他のもの(米国などの)では、それは強い政治上の反対勢力を満たすでしょう。 国の中には、市民の政府によって割り当てられたID番号を持っていますが、経常的業務のそれらの数の使用を禁止するプライバシー規則をまた持っているものもあります。 これらの後者のケースのどちらかでは、不可避的なIDは通常の証明書における使用に利用可能でないでしょう。
There was a concern that commercial Certificate Authorities might have been used to bring inescapable names into existence, bypassing the political process and the opposition to such names in those countries where such opposition is strong. As the (name,key)
商業Certificate Authoritiesが不可避的な名前を生み出すのに使用されたかもしれないという関心がありました、そのような反対が強いそれらの国のそのような名前の政治プロセスと反対を迂回させて。 the(名前、キー)
Ellison, et al. Experimental [Page 9] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[9ページ]RFC2693SPKIは理論1999年9月を証明します。
certificate business is evolving today, there are multiple competing CAs each creating disjoint Distinguished Name spaces. There is also no real block to the creation of new CAs. Therefore a person is able to drop one Distinguished Name and get another, by changing CA, making these names not inescapable.
証明書ビジネスは今日発展していて、複数の競争CAsがあります。各作成はDistinguished Name空間をばらばらにならせます。 また、新しいCAsの創造へのどんな本当のブロックもありません。 したがって、人は、1Distinguished Nameを落として、別のものを得ることができます、カリフォルニアを変えることによって、これらの名前を不可避的にしないで。
2.6 Local Names
2.6 ローカルの名前
Globally unique names may be politically undesirable and relatively useless, in the world of the Internet, but we use names all the time.
グローバルにユニークな名前は、インターネットの世界で政治的に望ましくなくて、比較的役に立たないかもしれませんが、私たちは絶えず、名前を使用します。
The names we use are local names. These are the names we write in our personal address books or use as nicknames or aliases with e-mail agents. They can be IDs assigned by corporations (e.g., bank account numbers or employee numbers). Those names or IDs do not need to be globally unique. Rather, they need to be unique for the one entity that maintains that address book, e-mail alias file or list of accounts. More importantly, they need to be meaningful to the person who uses them as indexes.
私たちが使用する名前は地方名です。 これらは私たちが私たちの個人的なアドレス帳に書くか、またはメールエージェントとのあだ名か別名として使用する名前です。 それらは会社(例えば、銀行口座番号か従業員番号)によって割り当てられたIDであるかもしれません。 それらの名前かIDがグローバルに特有である必要はありません。 むしろ、彼らは、アカウントのそのアドレス帳、メール別名ファイルまたはリストを保守する1つの実体に特有である必要があります。 より重要に、彼らは、インデックスとしてそれらを使用する人にとって重要である必要があります。
Ron Rivest and Butler Lampson showed with SDSI 1.0 [SDSI] that one can not only use local names locally, one can use local names globally. The clear security advantage and operational simplicity of SDSI names caused us in the SPKI group to adopt SDSI names as part of the SPKI standard.
ロンRivestとバトラーランプソンは、SDSI1.0[SDSI]と共に1つが局所的に地方名を使用できるだけではなくて、1つが地方名をグローバルに使用できるのを示しました。 SPKIで私たちに引き起こされたSDSI名の明確なセキュリティ上の利点と操作上の簡単さは、SPKI規格の一部としてSDSI名を採用するために分類されます。
2.6.1 Basic SDSI Names
2.6.1 基本的なSDSI名
A basic SDSI 2.0 name is an S-expression with two elements: the word "name" and the chosen name. For example,
2つの要素で基本的なSDSI2.0名はS-表現です: 「名前」という言葉と選ばれた名前。 例えば
george: (name fred)
george: (名前fred)
represents a basic SDSI name "fred" in the name space defined by george.
georgeによって定義された名前スペースに基本的なSDSI名前"fred"を表します。
2.6.2 Compound SDSI Names
2.6.2 複合SDSI名
If fred in turn defines a name, for example,
例えば、fredが順番に名前を定義するなら
fred: (name sam)
fred: (名前sam)
then george can refer to this same entity as
georgeがこの同じ実体を参照できるその時
george: (name fred sam)
george: (名前fred sam)
Ellison, et al. Experimental [Page 10] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[10ページ]RFC2693SPKIは理論1999年9月を証明します。
2.7 Sources of Global Identifiers
2.7 グローバルな識別子の源
Even though humans use local names, computer systems often need globally unique identifiers. Even in the examples of section 2.6.2 above, we needed to make the local names more global and did so by specifying the name-space owner.
人間は地方名を使用しますが、コンピュータ・システムはしばしばグローバルにユニークな識別子を必要とします。 セクション2.6.2に関する例でさえ、私たちは、上では、地方名をよりグローバルにするのが必要であり、名前宇宙所有者を指定することによって、そうしました。
If we are using public key cryptography, we have a ready source of globally unique identifiers.
公開鍵暗号を使用しているなら、私たちには、グローバルにユニークな識別子の持ち合わせの源があります。
When one creates a key pair, for use in public key cryptography, the private key is bound to its owner by good key safeguarding practice. If that private key gets loose from its owner, then a basic premise of public key cryptography has been violated and that key is no longer of interest.
1つが公開鍵暗号における使用のために主要な組を創設すると、秘密鍵は良い主要な保護習慣によって所有者に縛られます。 その秘密鍵が所有者からゆるくなるなら、公開鍵暗号の根本的な前提に違反してあります、そして、そのキーはもう興味がありません。
The private key is also globally unique. If it were not, then the key generation process would be seriously flawed and we would have to abandon this public key system implementation.
また、秘密鍵もグローバルにユニークです。 それがないなら、主要な発生経過はひどく失敗するでしょうに、そして、私たちはこの公開鍵システムの実現を捨てなければならないでしょう。
The private key must be kept secret, so it is not a possible identifier, but each public key corresponds to one private key and therefore to one keyholder. The public key, viewed as a byte string, is therefore an identifier for the keyholder.
秘密鍵を秘密にしなければなりませんが、したがって、それは可能な識別子ではありませんが、各公開鍵は1つの秘密鍵と、そして、したがって、1keyholderに対応しています。 したがって、バイトストリングとして見なされた公開鍵はkeyholderのための識別子です。
If there exists a collision-free hash function, then a collision-free hash of the public key is also a globally unique identifier for the keyholder, and probably a shorter one than the public key.
無衝突のハッシュ関数が存在しているなら、公開鍵の無衝突の細切れ肉料理は、keyholderに、グローバルにユニークな識別子とも、たぶん公開鍵より短いものです。
2.8 Fully Qualified SDSI Names
2.8 完全に適切なSDSI名
SDSI local names are of great value to their definer. Each local name maps to one or more public keys and therefore to the corresponding keyholder(s). Through SDSI's name chaining, these local names become useful potentially to the whole world. [See section 2.6.2 for an example of SDSI name chaining.]
SDSI地方名には、それらのdefinerにはかなりの価値があります。 各地方名は1つ以上の公開鍵と、そして、したがって、相当であることにkeyholder(s)を写像します。 SDSIの名前推論で、これらの地方名は潜在的に役に立つようになります。全世界に。 [SDSI名前推論の例に関してセクション2.6.2を見てください。]
To a computer system making use of these names, the name string is not enough. One must identify the name space in which that byte string is defined. That name space can be identified globally by a public key.
これらの名前を利用するコンピュータ・システムには、名前ストリングは十分ではありません。 そのバイトストリングが定義される名前スペースを特定しなければなりません。 公開鍵はその名前スペースをグローバルに特定できます。
It is SDSI 1.0 convention, preserved in SPKI, that if a (local) SDSI name occurs within a certificate, then the public key of the issuer is the identifier of the name space in which that name is defined.
(地方)のSDSI名が証明書の中に現れるなら発行人の公開鍵がその名前が定義される名前スペースに関する識別子であることはSPKIで保存されたSDSI1.0コンベンションです。
Ellison, et al. Experimental [Page 11] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[11ページ]RFC2693SPKIは理論1999年9月を証明します。
However, if a SDSI name is ever to occur outside of a certificate, the name space within which it is defined must be identified. This gives rise to the Fully Qualified SDSI Name. That name is a public key followed by one or more names relative to that key. If there are two or more names, then the string of names is a SDSI name chain. For example,
しかしながら、かつてSDSI名が証明書の外に現れるつもりであるなら、それが定義される名前スペースを特定しなければなりません。 これはFully Qualified SDSI Nameをもたらします。 その名前は1つ以上の名前がそのキーに比例していうことになった公開鍵です。 2つ以上の名前があれば、名前のストリングはSDSI名前チェーンです。 例えば
(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim therese)
(名前(sha1| TLCgPLFlGTzgUbcaYLW8kGTEnUk=を論じ尽くしてください|)jim therese)
is a fully qualified SDSI name, using the SHA-1 hash of a public key as the global identifier defining the name space and anchoring this name string.
グローバルな識別子として公開鍵のSHA-1ハッシュを使用する完全に適切なSDSI名は、スペースという名前を定義して、この名前ストリングを据えつけていますか?
2.9 Fully Qualified X.509 Names
2.9 完全に適切なX.509名
An X.509 Distinguished Name can and sometimes must be expressed as a Fully Qualified Name. If the PEM or original X.500 vision of a single root for a global name space had come true, this wouldn't be necessary because all names would be relative to that same one root key. However, there is not now and is not likely ever to be a single root key. Therefore, every X.509 name should be expressed as the pair
そして、X.509 Distinguished Nameがそうすることができる、Fully Qualified Nameとして時々言い表さなければなりません。 すべての名前がその同じ1個のルートキーに比例しているでしょう、したがって、グローバル名スペースへのただ一つの根のPEMかオリジナルのX.500ビジョンが実現したなら、これは必要でないでしょう。 しかしながら、単一のルートキーは、現在でなく、ありそうにはありません。 したがって、あらゆるX.509名が組として表されるべきです。
(name <root key> <leaf name>)
(名前<ルートキー><葉の名前>)
if all leaf names descending from that root are unique. If uniqueness is enforced only within each individual CA, then one would build a Fully Qualified Name chain from an X.509 certificate chain, yielding the form
その根から離すすべての葉の名がユニークであるなら。 ユニークさがそれぞれの個々のカリフォルニアだけの中で励行されるなら、1つはX.509証明書チェーンからFully Qualified Nameチェーンを組立てるでしょう、フォームをもたらして
(name <root key> <CA(1)> <CA(2)> ... <CA(k)> <leaf name>).
(名前<ルートキー><カリフォルニア(1)><カリフォルニア(2)>…<カリフォルニア(k)><葉の名前>。)
2.10 Group Names
2.10 グループ名
SPKI/SDSI does not claim to enforce one key per name. Therefore, a named group can be defined by issuing multiple (name,key) certificates with the same name -- one for each group member.
SPKI/SDSIは、1名前あたり1個のキーを実施すると主張しません。 したがって、同じ名前で複数の(名前、キー)証明書を発行することによって、命名されたグループを定義できます--それぞれのグループのメンバーあたり1つ。
3. Authorization
3. 承認
Fully qualified SDSI names represent globally unique names, but at every step of their construction the local name used is presumably meaningful to the issuer. Therefore, with SDSI name certificates one can identify the keyholder by a name relevant to someone.
完全に適切なSDSI名はグローバルにユニークな名前を表しますが、至る所にそれらの構造では、おそらく、使用というローカルの名前は発行人に重要です。 したがって、SDSIと共に、名前証明書1はだれかに関連している名前のkeyholderを特定できます。
Ellison, et al. Experimental [Page 12] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[12ページ]RFC2693SPKIは理論1999年9月を証明します。
However, what an application needs to do, when given a public key certificate or a set of them, is answer the question of whether the remote keyholder is permitted some access. That application must make a decision. The data needed for that decision is almost never the spelling of a keyholder's name.
しかしながら、公開鍵証明書かそれらのセットに考えて、アプリケーションがする必要があることはいくらかのアクセサリーがリモートkeyholderに受入れられるかどうかに関する質問に答えることです。 そのアプリケーションは決定しなければなりません。 ほとんどその決定に必要であるデータはそうではありません。keyholderの名前のスペル。
Instead, the application needs to know if the keyholder is authorized for some access. This is the primary job of a certificate, according to the members of the SPKI WG, and the SPKI certificate was designed to meet this need as simply and directly as possible.
代わりに、アプリケーションは、keyholderがいくらかのアクセサリーのために認可されるかどうかを知る必要があります。 これはSPKI WGのメンバーに従った証明書のプライマリ仕事です、そして、SPKI証明書は、簡単にできるだけ直接この需要を満たすように設計されました。
We realize that the world is not going to switch to SPKI certificates overnight. Therefore, we developed an authorization computation process that can use certificates in any format. That process is described below in section 6.
私たちは、世界が一夜のうちにSPKI証明書に切り替わらないとわかります。 したがって、私たちはどんな形式にも証明書を使用できる承認計算プロセスを開発しました。 そのプロセスは以下でセクション6で説明されます。
The various methods of establishing authorization are documented below, briefly. (See also [UPKI])
承認を確立する様々なメソッドは以下に簡潔に記録されます。 (参照、[UPKI])
3.1 Attribute Certificates
3.1 属性証明書
An Attribute Certificate, as defined in X9.57, binds an attribute that could be an authorization to a Distinguished Name. For an application to use this information, it must combine an attribute certificate with an ID certificate, in order to get the full mapping:
X9.57で定義されるAttribute Certificateは承認であるかもしれない属性をDistinguished Nameに縛ります。 アプリケーションがこの情報を使用するように、属性証明書をID証明書に結合しなければなりません、完全なマッピングを得るために:
authorization -> name -> key
承認->名前->キー
Presumably the two certificates involved came from different issuers, one an authority on the authorization and the other an authority on names. However, if either of these issuers were subverted, then an attacker could obtain an authorization improperly. Therefore, both the issuers need to be trusted with the authorization decision.
おそらく、かかわった2通の証明書が異なった発行人から来て、1つが承認に関する権威であり、もう片方が名前に関する権威です。 しかしながら、これらの発行人のどちらかが打倒されるなら、攻撃者は不適切に承認を得ることができるでしょうに。 したがって、両方の発行人は、承認決定で信じられる必要があります。
3.2 X.509v3 Extensions
3.2 X.509v3拡張子
X.509v3 permits general extensions. These extensions can be used to carry authorization information. This makes the certificate an instrument mapping both:
X.509v3は一般的な拡大を可能にします。 承認情報を運ぶのにこれらの拡張子を使用できます。 これは証明書を両方を写像する器具にします:
authorization -> key
承認->キー
and
そして
name -> key
名前->キー
In this case, there is only one issuer, who must be an authority on both the authorization and the name.
この場合、1つの発行人しかありません。(発行人は承認と名前の両方の権威であるに違いありません)。
Ellison, et al. Experimental [Page 13] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[13ページ]RFC2693SPKIは理論1999年9月を証明します。
Some propose issuing a master X.509v3 certificate to an individual and letting extensions hold all the attributes or authorizations the individual would need. This would require the issuer to be an authority on all of those authorizations. In addition, this aggregation of attributes would result in shortening the lifetime of the certificate, since each attribute would have its own lifetime. Finally, aggregation of attributes amounts to the building of a dossier and represents a potential privacy violation.
或るものは、マスターX.509v3証明書を個人に発行して、拡大に個人が必要とするすべての属性か承認を保持させるよう提案します。 これは、発行人がそれらの承認のすべての権威であることを必要とするでしょう。 さらに、属性のこの集合は証明書の生涯を短くするのに結果として生じるでしょう、各属性に、それ自身の寿命があるでしょう、したがって。 最終的に、属性の集合は、関係書類のビルに達して、潜在的プライバシー違反を表します。
For all of these reasons, it is desirable that authorizations be limited to one per certificate.
これらの理由のすべてに関しては、承認が1証明書あたり1つに制限されるのは、望ましいです。
3.3 SPKI Certificates
3.3 SPKI証明書
A basic SPKI certificate defines a straight authorization mapping:
基本のSPKI証明書はまっすぐな承認マッピングを定義します:
authorization -> key
承認->キー
If someone wants access to a keyholder's name, for logging purposes or even for punishment after wrong-doing, then one can map from key to location information (name, address, phone, ...) to get:
だれかが悪行の後に伐採目的か罰のためにさえkeyholderの名前へのアクセスが欲しいなら、1つは得る位置情報(名前、アドレス、電話、…)のキーから以下を写像できます。
authorization -> key -> name
承認の->の主要な->名
This mapping has an apparent security advantage over the attribute certificate mapping. In the mapping above, only the
このマッピングは属性証明書マッピングの上に見かけのセキュリティ上の利点を持っています。 マッピングだけ
authorization -> key
承認->キー
mapping needs to be secure at the level required for the access control mechanism. The
レベルで安全になる必要性を写像するのがアクセス管理機構に必要です。 The
key -> name
主要な->名
mapping (and the issuer of any certificates involved) needs to be secure enough to satisfy lawyers or private investigators, but a subversion of this mapping does not permit the attacker to defeat the access control. Presumably, therefore, the care with which these certificates (or database entries) are created is less critical than the care with which the authorization certificate is issued. It is also possible that the mapping to name need not be on-line or protected as certificates, since it would be used by human investigators only in unusual circumstances.
マッピング(そして、かかわったどんな証明書の発行人も)は、弁護士か私立探偵を満たすほど安全である必要がありますが、このマッピングの転覆は、攻撃者がアクセス制御を破ることを許可しません。 おそらく、したがって、これらの証明書(または、データベースエントリー)が作成される注意は承認証明書が発行される注意ほど重要ではありません。 また、命名するマッピングがオンラインか証明書として保護されている必要はないのも、可能です、それは珍しい事情だけで人間の捜査官によって使用されるでしょう、したがって。
Ellison, et al. Experimental [Page 14] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[14ページ]RFC2693SPKIは理論1999年9月を証明します。
3.4 ACL Entries
3.4 ACLエントリー
SDSI 1.0 defined an ACL, granting authorization to names. It was then like an attribute certificate, except that it did not need to be signed or issued by any key. It was held in local memory and was assumed issued by the owner of the computer and therefore of the resource being controlled.
承認を名前に与えて、SDSI1.0はACLを定義しました。 それはそして、属性証明書に似ていました、どんなキーによっても署名されたか、または発行される必要はなかったのを除いて。 コンピュータとしたがって、リソースの所有者によって制御されながら、それは、ローカルの記憶で主張されて、発行されていると思われました。
In SPKI, an ACL entry is free to be implemented in any way the developer chooses, since it is never communicated and therefore does not need to be standardized. However, a sample implementation is documented, as a certificate body minus the issuer field. The ACL entry can have a name as a subject, as in SDSI 1.0, or it can have a key as a subject. Examples of the latter include the list of SSL root keys in an SSL capable browser or the file .ssh/authorized_keys in a user's home UNIX directory. Those ACLs are single-purpose, so the individual entries do not carry explicit authorizations, but SPKI uses explicit authorizations so that one can use common authorization computation code to deal with multiple applications.
SPKIでは、ACLエントリーは無料で開発者が選ぶどんな方法でも実装することができます、それは決してコミュニケートしないで、したがって、標準化される必要はありません。 しかしながら、サンプル実装は証明書ボディーとして発行人分野を引いて記録されます。 ACLエントリーがSDSI1.0のように対象としての名前を持つことができますか、またはそれは対象としてキーを持つことができます。 後者に関する例はユーザのホームUNIXディレクトリのSSLの有能なブラウザかファイル.ssh/認可された_キーにSSLルートキーのリストを含んでいます。 それらのACLsがただ一つの目的である、したがって、個人出場者は明白な承認を運びませんが、SPKIは1つが複数のアプリケーションに対処するのに一般的な承認計算コードを使用できるように、明白な承認を使用します。
4. Delegation
4. 委譲
One of the powers of an authorization certificate is the ability to delegate authorizations from one person to another without bothering the owner of the resource(s) involved. One might issue a simple permission (e.g., to read some file) or issue the permission to delegate that permission further.
承認証明書の強国の1つは1人の人からもう1人の人まで(s)がかかわったリソースの所有者を苦しめないで承認を代表として派遣する能力です。 1つは、簡単な許可(例えば何らかのファイルを読む)を発行するか、またはさらにその許可を代表として派遣する許可を発行するかもしれません。
Two issues arose as we considered delegation: the desire to limit depth of delegation and the question of separating delegators from those who can exercise the delegated permission.
私たちが委譲を考えたとき、2冊は起こりました: 委譲の深さを制限する願望と代表として派遣された許可を運動させることができる人と「反-遺贈者」を切り離す問題。
4.1 Depth of Delegation
4.1 委譲の深さ
There were three camps in discussing depth of delegation: no control, boolean control and integer control. There remain camps in favor of each of these, but a decision was reached in favor of boolean control.
委譲の深さについて議論するのにおいて3つの陣営がありました: コントロール、論理演算子コントロール、および整数は全く制御されません。 それぞれのこれらを支持して陣営は残っていましたが、決定に論理演算子コントロールを支持して達しました。
4.1.1 No control
4.1.1 コントロールがありません。
The argument in favor of no control is that if a keyholder is given permission to do something but not the permission to delegate it, then it is possible for that keyholder to loan out the empowered private key or to set up a proxy service, signing challenges or requests for the intended delegate. Therefore, the attempt to restrict the permission to delegate is ineffective and might back- fire, by leading to improper security practices.
コントロールを支持して議論はそれを代表として派遣する許可ではなく、何かをする許可をkeyholderに与えるならそのkeyholderが代理業務で権限を与えられた秘密鍵かセットに貸出しするのが、可能であるということです、意図している代表を求める挑戦か要求に署名して。 したがって、代表として派遣する許可を制限する試みは、効力がなく、炎を支持するかもしれません、不適当なセキュリティ実践に通じることによって。
Ellison, et al. Experimental [Page 15] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[15ページ]RFC2693SPKIは理論1999年9月を証明します。
4.1.2 Boolean control
4.1.2 ブールコントロール
The argument in favor of boolean control is that one might need to specify an inability to delegate. For example, one could imagine the US Commerce Department having a key that is authorized to declare a cryptographic software module exportable and also to delegate that authorization to others (e.g., manufacturers). It is reasonable to assume the Commerce Department would not issue permission to delegate this further. That is, it would want to have a direct legal agreement with each manufacturer and issue a certificate to that manufacturer only to reflect that the legal agreement is in place.
論理演算子コントロールを支持して議論は人が、代表として派遣する無能を指定する必要があるかもしれないということです。 例えば、人は、米国商務省が暗号ソフトウェアモジュールが輸出向きであると宣言して、また、他のもの(例えば、メーカー)へその承認を代表として派遣するのが認可されるキーを持っていると想像できました。 商務省がさらにこれを代表として派遣する許可を発行しないと仮定するのは妥当です。 各メーカーと共にダイレクト法的な協定を持って、そのメーカーに証明書を下付したがっているでしょうが、法的な協定が適所にあるのを反映します。
4.1.3 Integer control
4.1.3 整数コントロール
The argument in favor of integer control is that one might want to restrict the depth of delegation in order to control the proliferation of a delegated permission.
整数コントロールを支持して議論は人が代表として派遣された許可の増殖を制御するために委譲の深さを制限したがっているかもしれないということです。
4.1.4 The choice: boolean
4.1.4 選択: 論理演算子
Of these three, the group chose boolean control. The subject of a certificate or ACL entry may exercise any permission granted and, if delegation is TRUE, may also delegate that permission or some subset of it to others.
これらの3では、グループは論理演算子コントロールを選びました。 証明書かACLエントリーの対象は、与えられたどんな許可も運動させて、また、委譲がTRUEであるならその許可かそれの何らかの部分集合を他のものへ代表として派遣するかもしれません。
The no control argument has logical appeal, but there remains the assumption that a user will value his or her private key enough not to loan it out or that the key will be locked in hardware where it can't be copied to any other user. This doesn't prevent the user from setting up a signing oracle, but lack of network connectivity might inhibit that mechanism.
ノー、は議論を制御します。論理的な上告を持っていますが、ユーザがその人の秘密鍵をそれを外に貸与しないほど評価するか、またはいかなる他のユーザにもそれをコピーできないハードウェアがキーに閉じ込められるという仮定は、残っています。 これは、ユーザが署名神託をセットアップするのを防ぎませんが、ネットワークの接続性の不足はそのメカニズムを禁止するかもしれません。
The integer control option was the original design and has appeal, but was defeated by the inability to predict the proper depth of delegation. One can always need to go one more level down, by creating a temporary signing key (e.g., for use in a laptop). Therefore, the initially predicted depth could be significantly off.
整数規制オプションは、当初の設計であり、上告を持っていましたが、委譲の適切な深さを予測できないことによって破られました。 人は、いつももうひとつのレベルを下る必要があることができます、一時的な署名キー(例えば、ラップトップにおける使用のための)を作成することによって。 したがって、初めは予測された深さはかなりオフであるかもしれません。
As for controlling the proliferation of permissions, there is no control on the width of the delegation tree, so control on its depth is not a tight control on proliferation.
許容の増殖を制御することに関して、コントロールが全く委譲木の幅にないので、増殖のときに深さにおけるコントロールは厳格な管理ではありません。
Ellison, et al. Experimental [Page 16] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[16ページ]RFC2693SPKIは理論1999年9月を証明します。
4.2 May a Delegator Also Exercise the Permission?
4.2 また、Delegatorは許可を運動させるかもしれませんか?
We decided that a delegator is free to create a new key pair, also controlled by it, and delegate the rights to that key to exercise the delegated permission. Therefore, there was no benefit from attempting to restrict the exercise of a permission by someone permitted to delegate it.
私たちは、代表として派遣された許可を運動させるために「反-遺贈者」が新しい主要な組を創設して、また、それから制御して、自由にそのキーへの権利を代表として派遣することができると決めました。 したがって、それを代表として派遣することが許可されただれかによる許可の運動を制限するのを試みるのからの利益が全くありませんでした。
4.3 Delegation of Authorization vs. ACLs
4.3 承認対ACLsの委譲
One concern with defining an authorization certificate is that the function can be performed by traditional <authorization,name> ACLs and <name,key> ID certificates defining groups. Such a mechanism was described in SDSI 1.0. A new mechanism needs to add value or it just complicates life for the developer.
承認証明書を定義する1回の関心は伝統的な<承認、名前>ACLs、および<名(グループを定義する主要な>ID証明書)で機能を実行できるということです。 そのようなメカニズムはSDSI1.0で説明されました。 新しいメカニズムが、価値を高める必要があるか、またはそれは開発者のためにただ寿命を複雑にします。
The argument for delegated authorization as opposed to ACLs can be seen in the following example.
以下の例でACLsと対照的に代表として派遣された承認のための議論を見ることができます。
Imagine a firewall proxy permitting telnet and ftp access from the Internet into a network of US DoD machines. Because of the sensitivity of that destination network, strong access control would be desired. One could use public key authentication and public key certificates to establish who the individual keyholder was. Both the private key and the keyholder's certificates could be kept on a Fortezza card. That card holds X.509v1 certificates, so all that can be established is the name of the keyholder. It is then the job of the firewall to keep an ACL, listing named keyholders and the forms of access they are each permitted.
インターネットからファイアウォールがtelnetを可能にするプロキシとftpアクセスであると米国DoDマシンのネットワークに想像してください。 その送信先ネットワークの感度のために、強いアクセスコントロールは望まれているでしょう。 1つは、個々のkeyholderがだれであったかを証明するのに公開鍵認証と公開鍵証明書を使用するかもしれません。 Fortezzaカードに秘密鍵とkeyholderの証明書の両方を保管できました。 そのカードがX.509v1証明書を支えるので、設立できるすべてがkeyholderの名前です。 次に、ACLを保つのは、ファイアウォールの仕事です、それらがそれぞれ受入れられるアクセスの命名されたkeyholdersと書式を記載して。
Consider the ACL itself. Not only would it be potentially huge, demanding far more storage than the firewall would otherwise require, but it would also need its own ACL. One could not, for example, have someone in the Army have the power to decide whether someone in the Navy got access. In fact, the ACL would probably need not one level of its own ACL, but a nested set of ACLs, eventually reflecting the organization structure of the entire Defense Department.
ACL自身を考えてください。 また、ファイアウォールが別の方法で必要とするだろうよりはるかに多くのストレージを要求して、潜在的に巨大であるだろうというだけではなく、それはそれ自身のACLを必要とするでしょう。 1つで、例えば、陸軍のだれかが海軍のだれかがアクセサリーを得たかどうか決めるパワーを持つことができませんでした。 事実上、ACLはたぶんそれ自身のACLの1つのレベルではなく、ACLsの入れ子にされたセットを必要とするでしょう、結局全体の国防総省の組織構造を反映して。
Without the ACLs, the firewall could be implemented in a device with no mass storage, residing in a sealed unit one could easily hold in one hand. With the ACLs, it would need a large mass storage device that would be accessed not only while making access control decisions but also for updating the ACLs.
ACLs、デバイスで大容量記憶なしでファイアウォールを実装することができました、と密封されたユニット1に住んでいるのは片手に容易に保持するかもしれません。 ACLsと共に、それは決定ですが、ACLsをまたアップデートするためにアクセスコントロールを作っているだけではない間にアクセスされる大きい大記憶装置を必要とするでしょう。
By contrast, let the access be controlled by authorization certificates. The firewall would have an ACL with one entry, granting a key belonging to the Secretary of Defense the right to delegate all access through the firewall. The Secretary would, in
対照的に、承認証明書からアクセスを制御させてください。 ファイアウォールには1つのエントリーがあるACLがあるでしょう、ファイアウォールを通してすべてのアクセスを代表として派遣する権利を国防長官への主要な属に与えて。 中長官がそうするだろう。
Ellison, et al. Experimental [Page 17] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[17ページ]RFC2693SPKIは理論1999年9月を証明します。
turn, issue certificates delegating this permission to delegate to each of his or her subordinates. This process would iterate, until some enlisted man would receive permission to penetrate that firewall for some specific one protocol, but not have permission to delegate that permission.
問題証明書がその人の部下の各人に委任するこの許可を代表として派遣して、ターンしてください。 このプロセスには、その許可を代表として派遣する許可は、下士官兵が特定の何らかの1つのプロトコルのためにそのファイアウォールを理解する許可を受けるだろうまで繰り返しますが、ないでしょう。
The certificate structure generated would reflect the organization structure of the entire Defense Department, just as the nested ACLs would have, but the control of these certificates (via their issuance and revocation) is distributed and need not show up in that one firewall or be replicated in all firewalls. Each individual delegator of permission performs a simple task, well understood. The application software to allow that delegation is correspondingly simple.
構造が作った証明書は全体の国防総省の組織構造を反映するでしょう、入れ子にされたACLsがそうしたでしょうが、これらの証明書(彼らの発行と取消しを通した)のコントロールが分配されていて、その1個のファイアウォールに現れる必要はありませんし、またすべてのファイアウォールで模写されるだけである必要はないように。 許可のそれぞれの個々の「反-遺贈者」はよく理解されていた簡単な仕事を実行します。 その委譲を許容するアプリケーション・ソフトは対応する簡単です。
5. Validity Conditions
5. 正当性状態
A certificate, or an ACL entry, has optional validity conditions. The traditional ones are validity dates: not-before and not-after. The SPKI group resolved, in discussion, that on-line tests of various kinds are also validity conditions. That is, they further refine the valid date range of a certificate. Three kinds of on-line tests are envisioned: CRL, re-validation and one-time.
証明書、またはACLエントリーには、任意の正当性状態があります。 伝統的なものは使用期限です: そして、-以前でない、-後でない。 SPKIグループは、議論でまた、様々な種類のオンラインテストが正当性状態であると決議しました。 すなわち、彼らはさらに証明書の有効な日付の範囲を洗練します。 3種類のオンラインテストは思い描かれます: CRL、再合法化、および1回。
When validity confirmation is provided by some online test, then the issuer of those refinements need not be the issuer of the original certificate. In many cases, the business or security model for the two issuers is different. However, in SPKI, the certificate issuer must specify the issuer of validity confirmations.
何らかのオンラインテストで正当性確認を提供すると、それらの気品の発行人はオリジナルの証明書の発行人である必要はありません。 多くの場合、2つの発行人のビジネスか機密保護モデルが異なっています。 しかしながら、SPKIでは、証明書発行人は正当性確認の発行人を指定しなければなりません。
5.1 Anti-matter CRLs
5.1 反物質CRLs
An early form of CRL [Certificate Revocation List] was modeled after the news print book that used to be kept at supermarket checkout stands. Those books held lists of bad checking account numbers and, later, bad credit card numbers. If one's payment instrument wasn't listed in the book, then that instrument was considered good.
CRL[証明書Revocation List]の早めのフォームは以前はスーパーマーケットレジによく保管されていたニュース印刷の本に倣われました。 それらの本は悪い当座預金番号と後で悪いクレジットカード番号のリストを保持しました。 人の支払い器具が本に記載されなかったなら、その器具は良いと考えられました。
These books would be issued periodically, and delivered by some means not necessarily taking a constant time. However, when a new book arrived, the clerk would replace the older edition with the new one and start using it. This design was suited to the constraints of the implementation: use of physical books, delivered by physical means. The book held bad account numbers rather than good ones because the list of bad accounts was smaller.
これらの本は、どうでも必ず一定の時かかるというわけではないのを定期的に発行して、渡すでしょう。 しかしながら、新しい本が届いたとき、事務員は、より古い版を新しい方に取り替えて、それを使用し始めるでしょう。 このデザインは実現の規制に合いました: 物理的な手段で届けられた物理的な本の使用。 貸し倒れ勘定のリストが、より小さかったので、本は良いものよりむしろ貸し倒れ勘定番号を保持しました。
Ellison, et al. Experimental [Page 18] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[18ページ]RFC2693SPKIは理論1999年9月を証明します。
An early CRL design followed this model. It had a list of revoked certificate identifiers. It also had a sequence number, so that one could tell which of two CRLs was more recent. A newer CRL would replace an older one.
早めのCRLデザインはこのモデルに従いました。 それには、取り消された証明書識別子のリストがありました。 また、それには一連番号が、人が、2CRLsのどちらが、より最近であったかを言うことができるように、ありました。 より新しいCRLは、より古いものを取り替えるでしょう。
This mode of operation is like wandering anti-matter. When the issuer wants to revoke a certificate, it is listed in the next CRL to go out. If the revocation is urgent, then that CRL can be released immediately. The CRL then follows some dissemination process unrelated to the needs of the consumers of the CRL. If the CRL encounters a certificate it has listed, it effectively annihilates that certificate. If it encounters an older CRL, it annihilates that CRL also, leaving a copies of itself at the verifiers it encounters.
この運転モードは反物質を歩き回っているようです。 発行人が証明書を取り消したいと思うと、それは、出かけるために次のCRLに記載されます。 取消しが緊急であるなら、すぐに、そのCRLをリリースできます。 そして、CRLはCRLの消費者の必要性に関係ない何らかの普及の過程に従います。 CRLがそれがリストアップした証明書に遭遇するなら、事実上、それはその証明書を全滅させます。 より古いCRLに遭遇するなら、そのCRLも全滅させます、それが遭遇する検証にそれ自体のコピーを残して。
However, this process is non-deterministic. The result of the authorization computation is at least timing dependent. Given an active adversary, it can also be a security hole. That is, an adversary can prevent revocation of a given certificate by preventing the delivery of new CRLs. This does not require cryptographic level effort, merely network tampering.
しかしながら、この過程は非決定論的です。 認可計算の結果は少なくともタイミング扶養家族です。 活発な敵を考えて、また、それはセキュリティーホールであるかもしれません。 すなわち、敵は、新しいCRLsの配送を防ぐことによって、与えられた証明書の取消しを防ぐことができます。 これは暗号の平らな努力、単にネットワークのいじることを必要としません。
SPKI has ruled out the use of wandering anti-matter CRLs for its certificates. Every authorization computation is deterministic, under SPKI rules.
SPKIは放浪している反物質CRLsの証明書の使用を除外しました。 あらゆる認可計算がSPKI規則の下で決定論的です。
5.2 Timed CRLs
5.2 調節されたCRLs
SPKI permits use of timed CRLs. That is, if a certificate can be referenced in a CRL, then the CRL process is subject to three conditions.
SPKIは調節されたCRLsの使用を可能にします。 すなわち、CRLで証明書に参照をつけることができるなら、CRLの過程は3つの状態を受けることがあります。
1. The certificate must list the key (or its hash) that will sign
the CRL and may give one or more locations where that CRL might
be fetched.
1. 証明書は、CRLにサインするキー(または、細切れ肉料理)を記載しなければならなくて、そのCRLがとって来られるかもしれない複数の位置を与えるかもしれません。
2. The CRL must carry validity dates.
2. CRLは使用期限を運ばなければなりません。
3. CRL validity date ranges must not intersect. That is, one may
not issue a new CRL to take effect before the expiration of the
CRL currently deployed.
3. CRL使用期限の範囲は横切られてはいけません。 すなわち、CRLの満了が現在展開する前に効くように新しいCRLを発行しないかもしれません。
Under these rules, no certificate that might use a CRL can be processed without a valid CRL and no CRL can be issued to show up as a surprise at the verifier. This yields a deterministic validity computation, independent of clock skew, although clock inaccuracies in the verifier may produce a result not desired by the issuer. The CRL in this case is a completion of the certificate, rather than a message to the world announcing a change of mind.
これらの規則の下では、有効なCRLなしでCRLを使用するかもしれない証明書は全く処理できません、そして、驚きとして検証に現れるようにCRLを全く発行できません。 これは決定論的な正当性計算をもたらします、時計斜行の如何にかかわらず、検証の時計誤りが発行人によって望まれていなかった結果を生むかもしれませんが。 この場合、CRLは心の変更を発表する世界へのメッセージよりむしろ証明書の完成です。
Ellison, et al. Experimental [Page 19] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[19ページ]RFC2693SPKIは理論1999年9月を証明します。
Since CRLs might get very large and since they tend to grow monotonically, one might want to issue changes to CRLs rather than full ones. That is, a CRL might be a full CRL followed by a sequence of delta-CRLs. That sequence of instruments is then treated as a current CRL and the combined CRL must follow the conditions listed above.
CRLsが非常に大きくなるかもしれなくて、彼らが、単調に成長する傾向があるので、人は完全なものよりむしろCRLsへの変化を発行したがっているかもしれません。 すなわち、CRLはデルタ-CRLsの系列がいうことになった完全なCRLであるかもしれません。 次に、器具のその系列は現在のCRLとして扱われます、そして、結合したCRLは上にリストアップされた状態に続かなければなりません。
5.3 Timed Revalidations
5.3 調節されたRevalidations
CRLs are negative statements. The positive version of a CRL is what we call a revalidation. Typically a revalidation would list only one certificate (the one of interest), although it might list a set of certificates (to save digital signature effort).
CRLsは否定的声明です。 CRLの積極的なバージョンはいわゆる再合法化です。 通常、再合法化は1通の証明書(興味があるもの)だけをリストアップするでしょう、1セットの証明書(デジタル署名の努力を救う)をリストアップするかもしれませんが。
As with the CRL, SPKI demands that this process be deterministic and therefore that the revalidation follow the same rules listed above (in section 5.2).
CRLのように、この過程が決定論的であり、したがって、再合法化が同じ規則に従うというSPKI要求は上(セクション5.2で)に記載しました。
5.4 Setting the Validity Interval
5.4 正当性間隔を設定すること。
Both timed CRLs and timed revalidations have non-0 validity intervals. To set this validity interval, one must answer the question: "How long are you willing to let the world believe and act on a statement you know to be false?"
両方がCRLsを調節しました、そして、調節された再合法化には、非0正当性間隔があります。 この正当性間隔を設定するために、質問に答えなければなりません: 「どれくらい長い間、あなたは、世界をあなたが誤っているのを知っている声明を信じる、影響させても構わないと思っていますか?」
That is, one must assume that the previous CRL or revalidation has just been signed and transmitted to at least one consumer, locking up a time slot. The next available time slot starts after this validity interval ends. That is the earliest one can revoke a certificate one learns to be false.
すなわち、前のCRLか再合法化がちょうど少なくとも1人の消費者にサインされて、伝えられたところであると仮定しなければなりません、時間帯に鍵をかけて。 この正当性間隔が終わった後に次の使用可能時間スロットは始まります。 すなわち、最も早い方は、誤るために、1つが学ぶ証明書を取り消すことができます。
The answer to that question comes from risk management. It will probably be based on expected monetary losses, at least in commercial cases.
その質問の答えはリスク管理から来ます。 それはたぶん少なくとも商業場合における予想された通貨の損失に基づくでしょう。
5.5 One-time Revalidations
5.5 1回のRevalidations
Validity intervals of length zero are not possible. Since transmission takes time, by the time a CRL was received by the verifier, it would be out of date and unusable. That assumes perfect clock synchronization. If clock skew is taken into consideration, validity intervals need to be that much larger to be meaningful.
長さゼロの正当性間隔は可能ではありません。 トランスミッションが検証でCRLを受け取る時までに時間がかかるので、それは、時代遅れであって、使用不可能でしょう。 それは完全な時計同期を仮定します。 時計斜行が考慮に入れられるなら、正当性間隔は、重要になるように、より大きいそれだけである必要があります。
For those who want to set the validity interval to zero, SPKI defines a one-time revalidation.
正当性間隔をゼロに設定したがっている人に関しては、SPKIは1回の再合法化を定義します。
Ellison, et al. Experimental [Page 20] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[20ページ]RFC2693SPKIは理論1999年9月を証明します。
This form of revalidation has no lifetime beyond the current authorization computation. One applies for this on-line, one-time revalidation by submitting a request containing a nonce. That nonce gets returned in the signed revalidation instrument, in order to prevent replay attacks. This protocol takes the place of a validity date range and represents a validity interval of zero, starting and ending at the time the authorization computation completes.
再合法化のこのフォームには、現在の認可計算を超えて寿命が全くありません。 一回だけを含む要求を提出することによって、1つはこのオンラインの、そして、1回の再合法化に申し込みます。 反射攻撃を防ぐためにサインされた再合法化器具でその一回だけを返します。 このプロトコルは、使用期限の範囲の代理をして、ゼロの正当性間隔を表します、認可計算が完成する時に始まって、終わって。
5.6 Short-lived Certificates
5.6 短命な証明書
A performance analysis of the various methods of achieving fine-grain control over the validity interval of a certificate should consider the possibility of just making the original certificate short-lived, especially if the online test result is issued by the same key that issued the certificate. There are cases in which the short-lived certificate requires fewer signatures and less network traffic than the various online test options. The use of a short-lived certificate always requires fewer signature verifications than the use of certificate plus online test result.
証明書の正当性間隔の細粒コントロールを達成する様々な方法の機能解析はただオリジナルの証明書を短命にする可能性を考えるべきです、特にオンラインテスト結果が証明書を発行したのと同じキーによって発行されるなら。 短命な証明書が、より少ない署名を必要とする場合と様々なオンラインテストオプションより少ないネットワークトラフィックがあります。 短命な証明書の使用はいつも証明書とオンラインテスト結果の使用より少ない署名照合を必要とします。
If one wants to issue short-lived certificates, SPKI defines a kind of online test statement to tell the user of the certificate where a replacement short-lived certificate might be fetched.
人が短命な証明書を発行したいなら、SPKIは、交換の短命な証明書がどこでとって来られるかもしれないかを証明書のユーザに言うために一種のオンラインテスト声明を定義します。
5.7 Other possibilities
5.7 他の可能性
There are other possibilities to be considered when choosing a validity condition model to use.
他の使用する正当性状態モデルを選ぶとき考えられるべき可能性があります。
5.7.1 Micali's Inexpensive On-line Results
5.7.1 Micaliの安価なオンライン結果
Silvio Micali has patented a mechanism for using hash chains to revalidate or revoke a certificate inexpensively. This mechanism changes the performance requirements of those models and might therefore change the conclusion from a performance analysis [ECR].
シルビオMicaliは細切れ肉料理チェーンをrevalidateに使用するためにメカニズムの特許をとったか、または証明書を安く取り消します。 このメカニズムは、それらのモデルの性能要件を変えて、したがって、機能解析[ECR]から結論を変えるかもしれません。
5.7.2 Rivest's Reversal of the CRL Logic
5.7.2 最もRivestであるのは、CRL論理の反転です。
Ron Rivest has written a paper [R98] suggesting that the whole validity condition model is flawed because it assumes that the issuer (or some entity to which it delegates this responsibility) decides the conditions under which a certificate is valid. That traditional model is consistent with a military key management model, in which there is some central authority responsible for key release and for determining key validity.
発行人(または、それがこの責任を代表として派遣する何らかの実体)が証明書が有効である状態について決めると仮定するので全体の正当性状態モデルが失敗するのを示しながら、ロンRivestはレポートを書きました[R98]。 その伝統的なモデルは軍用のかぎ管理モデルと一致しています、どれが主要なリリースと主要な正当性を決定するのに原因となる何らかの主要な権威があるかで。
Ellison, et al. Experimental [Page 21] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[21ページ]RFC2693SPKIは理論1999年9月を証明します。
However, in the commercial space, it is the verifier and not the issuer who is taking a risk by accepting a certificate. It should therefore be the verifier who decides what level of assurance he needs before accepting a credential. That verifier needs information from the issuer, and the more recent that information the better, but the decision is the verifier's in the end.
しかしながら、商業地区では、証明書を受け入れることによって危険を冒すのは、発行人ではなく、検証です。 したがって、それは信任状を受け入れる前に彼がどんなレベルを保証を必要とするかを決める検証であるべきです。 その検証は発行人からの情報を必要とします、そして、結局唯一の決定が検証のものであるほうがよいというその情報は、より最近です。
This line of thought deserves further consideration, but is not reflected in the SPKI structure definition. It might even be that both the issuer and the verifier have stakes in this decision, so that any replacement validity logic would have to include inputs from both.
考えのこの方針は、さらなる考慮に値しますが、SPKI構造定義に反映されません。 発行人と検証の両方がこの決定における賭けを開くということでさえあるかもしれません、どんな交換正当性論理も両方からの入力を含まなければならないように。
6. Tuple Reduction
6. Tuple減少
The processing of certificates and related objects to yield an authorization result is the province of the developer of the application or system. The processing plan presented here is an example that may be followed, but its primary purpose is to clarify the semantics of an SPKI certificate and the way it and various other kinds of certificate might be used to yield an authorization result.
認可結果をもたらす証明書と関連する物の処理はアプリケーションかシステムの開発者の州です。 ここに提示された処理プランはいうことになられるかもしれない例ですが、第一の目的は認可結果をもたらすためにSPKI証明書の意味論とそれと他の様々な種類の証明書が使用されるかもしれない方法をはっきりさせることです。
There are three kinds of entity that might be input to the computation that yields an authorization result:
認可結果をもたらす計算に入力されるかもしれない3種類の実体があります:
1. <name,key> (as a certificate)
1. <名、主要な>。(証明書としての)
2. <authorization,name> (as an attribute certificate or ACL entry)
2. <認可、名前>。(属性証明書かACLエントリーとしての)
3. <authorization,key> (as an authorization certificate or ACL
entry)
3. <認可、主要な>。(認可証明書かACLエントリーとしての)
These entities are processed in three stages.
これらの実体は3つの段階で処理されます。
1. Individual certificates are verified by checking their
signatures and possibly performing other work. They are then
mapped to intermediate forms, called "tuples" here.
1. 個々の証明書は、彼らの署名をチェックして、ことによると他の仕事を実行することによって、確かめられます。 "tuples"は、ここに次に、それらが中間的フォームに写像されると呼びました。
The other work for SPKI or SDSI certificates might include
processing of on-line test results (CRL, re-validation or one-
time validation).
SPKIかSDSI証明書のためのもう片方の仕事はオンライン試験の成績(CRL、再合法化または1つの時間合法化)の処理を含むかもしれません。
The other work for PGP certificates may include a web-of-trust
computation.
PGP証明書のためのもう片方の仕事は信用のウェブ計算を含むかもしれません。
The other work for X.509 certificates depends on the written
documentation for that particular use of X.509 (typically tied
to the root key from which the certificate descended) and could
そしてであることができましたX.509証明書のためのもう片方の仕事がX.509(証明書が下降したルートキーに通常つながる)のその特定の使用のために書かれたドキュメンテーションによる。
Ellison, et al. Experimental [Page 22] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[22ページ]RFC2693SPKIは理論1999年9月を証明します。
involve checking information in the parent certificate as well
as additional information in extensions of the certificate in
question. That is, some use X.509 certificates just to define
names. Others use X.509 to communicate an authorization
implicitly (e.g., SSL server certificates). Some might define
extensions of X.509 to carry explicit authorizations. All of
these interpretations are specified in written documentation
associated with the certificate chain and therefore with the
root from which the chain descends.
問題の証明書の拡大における追加情報と同様に親証明書の情報をチェックすることを伴ってください。 すなわち、或るものは、ただ名前を定義するのにX.509証明書を使用します。 他のものは、それとなく(例えば、SSLサーバ証明書)認可を伝えるのにX.509を使用します。 或るものは、明白な承認を運ぶためにX.509の拡大を定義するかもしれません。 これらの解釈のすべてがチェーンが下降する証明書チェーンとしたがって、根に関連している書かれたドキュメンテーションで指定されます。
If on-line tests are involved in the certificate processing,
then the validity dates of those on-line test results are
intersected by VIntersect() [defined in 6.3.2, below] with the
validity dates of the certificate to yield the dates in the
certificate's tuple(s).
オンラインテストが証明書処理にかかわるならオンラインであるそれらには試験の成績がある使用期限がVIntersect()で交差した、[定義される、6.3、.2、下] 証明書のtuple(s)の日付をもたらす証明書に関する使用期限で。
2. Uses of names are replaced with simple definitions (keys or
hashes), based on the name definitions available from reducing
name 4-tuples.
2. 名前の用途を簡単な定義(合わせるか、または論じ尽くす)に取り替えます、名前4-tuplesを減少させるので利用可能な名前定義に基づいて。
3. Authorization 5-tuples are then reduced to a final authorization
result.
3. そして、認可5-tuplesは確定授権結果に減少します。
6.1 5-tuple Defined
6.1 定義された5-tuple
The 5-tuple is an intermediate form, assumed to be held in trusted memory so that it doesn't need a digital signature for integrity. It is produced from certificates or other credentials via trusted software. Its contents are the same as the contents of an SPKI certificate body, but it might be derived from another form of certificate or from an ACL entry.
5-tupleが信じられたメモリに保持されると思われた中間的フォームであるので、それは保全のためのデジタル署名を必要としません。 それは証明書か他の信任状から信じられたソフトウェアで生産されます。 内容はSPKI証明書ボディーのコンテンツと同じですが、それは別の形式の証明書かACLエントリーから引き出されるかもしれません。
The elements of a 5-tuple are:
5-tupleの要素は以下の通りです。
1. Issuer: a public key (or its hash), or the reserved word "Self".
This identifies the entity speaking this intermediate result.
1. 発行人: 公開鍵(または、細切れ肉料理)、またはリザーブドワード「自己。」 これはこの中間結果を話す実体を特定します。
2. Subject: a public key (or its hash), a name used to identify a
public key, the hash of an object or a threshold function of
subordinate subjects. This identifies the entity being spoken
about in this intermediate result.
2. Subject: 公開鍵(または、細切れ肉料理)、名前は以前は、よく公開鍵(下位の対象の物かしきい値関数の細切れ肉料理)を特定していました。 これはこの中間結果で話される実体を特定します。
3. Delegation: a boolean. If TRUE, then the Subject is permitted
by the Issuer to further propagate the authorization in this
intermediate result.
3. 代表団: 論理演算子。 TRUEであるなら、Subjectがさらにこの中間結果における認可を伝播するのがIssuerによって可能にされます。
4. Authorization: an S-expression. [Rules for combination of
Authorizations are given below.]
4. 認可: S-表現。 [Authorizationsの組み合わせのための規則を以下に与えます。]
Ellison, et al. Experimental [Page 23] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[23ページ]RFC2693SPKIは理論1999年9月を証明します。
5. Validity dates: a not-before date and a not-after date, where
"date" means date and time. If the not-before date is missing
from the source credential then minus infinity is assumed. If
the not-after date is missing then plus infinity is assumed.
5. 使用期限: -以前でない、-後でないことの日付とa(「日付」手段は、デートして、調節される)は、デートされます。 -以前でない、期日はソース信任状からなくなって、次に、マイナス無限は想定されます。 -後でない、期日はその時、なくなって、無限は想定されます。
6.2 4-tuple Defined
6.2 定義された4-tuple
A <name,key> certificate (such as X.509v1 or SDSI 1.0) carries no authorization field but does carry a name. Since it is qualitatively different from an authorization certificate, a separate intermediate form is defined for it.
<名であり、主要な>証明書(X.509v1かSDSI1.0などの)は、認可野原を全く運びませんが、名前を載せます。 それが認可証明書と質的に異なっているので、別々の中間的書式はそれのために定義されます。
The elements of a Name 4-tuple are:
Name 4-tupleの要素は以下の通りです。
1. Issuer: a public key (or its hash). This identifies the entity
defining this name in its private name space.
1. 発行人: 公開鍵(または、細切れ肉料理)。 これは個人的な名前スペースでこの名前を定義する実体を特定します。
2. Name: a byte string
2. 以下を命名してください。 バイトストリング
3. Subject: a public key (or its hash), a name, or a threshold
function of subordinate subjects. This defines the name.
3. Subject: 公開鍵(または、細切れ肉料理)、名前、または下位の対象のしきい値関数。 これは名前を定義します。
4. Validity dates: a not-before date and a not-after date, where
"date" means date and time. If the not-before date is missing
from the source credential then minus infinity is assumed. If
the not-after date is missing then plus infinity is assumed.
4. 使用期限: -以前でない、-後でないことの日付とa(「日付」手段は、デートして、調節される)は、デートされます。 -以前でない、期日はソース信任状からなくなって、次に、マイナス無限は想定されます。 -後でない、期日はその時、なくなって、無限は想定されます。
6.3 5-tuple Reduction Rules
6.3 5-tuple減少定規
The two 5-tuples:
2 5-tuples:
<I1,S1,D1,A1,V1> + <I2,S2,D2,A2,V2>
<I1、S1、D1、A1、V1>+<I2、S2、D2、A2、V2>。
yield
利回り
<I1,S2,D2,AIntersect(A1,A2),VIntersect(V1,V2)>
<I1、S2、D2、AIntersect(A1、A2)、VIntersect(V1、V2)>。
provided
提供します。
the two intersections succeed,
2つの交差点が成功します。
S1 = I2
S1はI2と等しいです。
and
そして
D1 = TRUE
D1は本当に等しいです。
Ellison, et al. Experimental [Page 24] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[24ページ]RFC2693SPKIは理論1999年9月を証明します。
If S1 is a threshold subject, there is a slight modification to this rule, as described below in section 6.3.3.
S1が敷居対象であるなら、この規則へのわずかな変更が以下でセクション6.3.3で説明されるようにあります。
6.3.1 AIntersect
6.3.1 AIntersect
An authorization is a list of strings or sub-lists, of meaning to and probably defined by the application that will use this authorization for access control. Two authorizations intersect by matching, element for element. If one list is longer than the other but match at all elements where both lists have elements, then the longer list is the result of the intersection. This means that additional elements of a list must restrict the permission granted.
認可はストリングかサブリスト、アクセスにこの認可を使用するアプリケーションで意味していてたぶん定義されたコントロールのリストです。 マッチング、要素のための要素に従って、2つの承認が交差しています。 1つのリストがもう片方にもかかわらず、マッチより長い間両方のリストが要素を持っているところにすべての要素であるなら、より長いリストは交差点の結果です。 これは、リストの追加要素が与えられた許可を制限しなければならないことを意味します。
Although actual authorization string definitions are application dependent, AIntersect provides rules for automatic intersection of these strings so that application developers can know the semantics of the strings they use. Special semantics would require special reduction software.
実際の認可ストリング定義はアプリケーションに依存していますが、AIntersectは、アプリケーション開発者がそれらが使用するストリングの意味論を知ることができるように、これらのストリングの自動交差点に規則を提供します。 特別な意味論は特別な減少ソフトウェアを必要とするでしょう。
For example, there might be an ftpd that allows public key access control, using authorization certificates. Under that service,
例えば、認可証明書を使用して、公開鍵アクセス管理を許容するftpdがあるかもしれません。 そのサービスの下で
(ftp (host ftp.clark.net))
(ftp(ホストftp.clark.net))
might imply that the keyholder would be allowed ftp access to all directories on ftp.clark.net, with all kinds of access (read, write, delete, ...). This is more general (allows more access) than
すべての種類のアクセスでftp.clark.netの上のすべてのディレクトリへのftpアクセスがkeyholderに許されているのを含意するかもしれない、(読んでくださいといって、書いてください、削除する、) これは、より一般的です(より多くのアクセスを許します)。
(ftp (host ftp.clark.net) (dir /pub/cme))
(ftp(ホストftp.clark.net)(dir/パブ/cme))
which would allow all kinds of access but only in the directory specified. The intersection of the two would be the second.
すべての種類のアクセスを許しますが、どれがディレクトリだけで指定するだろうかは指定しました。 2つのものの交差点は2番目でしょう。
Since the AIntersect rules imply position dependency, one could also define the previous authorization string as:
AIntersect規則が位置の依存を含意するので、また、人は前の認可ストリングを以下と定義できました。
(ftp ftp.clark.net /pub/cme)
(ftp ftp.clark.net/パブ/cme)
to keep the form compact.
コンパクトにフォームを保管するために。
To allow for wild cards, there are a small number of special S- expressions defined, using "*" as the expression name.
ワイルドカードを考慮するために、式名として「*」を使用して、定義された少ない数の特別なS表現があります。
(*)
stands for the set of all S-expressions and byte-strings.
In other words, it will match anything. When intersected
with anything, the result is that other thing. [The
AIntersect rule about lists of different length treats a
(*)はすべてのS-表現とバイトストリングのセットを表します。 言い換えれば、それは何にでも合うでしょう。 何かと交差していると、結果はその他のものです。 [異なった長さのリストに関するAIntersect規則はaを扱います。
Ellison, et al. Experimental [Page 25] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[25ページ]RFC2693SPKIは理論1999年9月を証明します。
list as if it had enough (*) entries implicitly appended to
it to match the length of another list with which it was
being intersected.]
まるでそれにはそれが存在であった別のリストの長さを合わせるためにそれとなくそれに追加されたエントリーが十分(*)あるかのようにリストは交差しました。]
(* set <tag-expr>*)
stands for the set of elements listed in the *-form.
(*exprにタグ付けををしている<>*を設定してください) 要素のセットのためのスタンドは*フォームに記載しました。
(* prefix <byte-string>)
stands for the set of all byte strings that start with the
one given in the *-form.
(*接頭語<バイトストリング>) すべてのバイトのセットがそれを結ぶので、スタンドは*フォームで与えられたものから始まります。
(* range <ordering> <lower-limit>? <upper-limit>?)
stands for the set of all byte strings lexically (or
numerically) between the two limits. The ordering
parameter (alpha, numeric, time, binary, date) specifies
the kind of strings allowed.
(><下限>(<上限>)を注文する*範囲<)は2つの限界の間に辞書的に(数の上で)すべてのバイトストリングのセットを表します。 注文パラメタ(アルファ、数値、時間、バイナリー、日付)は許容されたストリングの種類を指定します。
AIntersect() is normal set intersection, when *-forms are defined as they are above and a normal list is taken to mean all lists that start with those elements. The following examples should give a more concrete explanation for those who prefer an explanation without reference to set operations.
AIntersect()が正常なセット交差点である、*書式が定義されるとき、それらが上にあって、正常なリストを取るとき、すべてを意味するのはそれらの要素によるその始めを記載します。 以下の例は参照のない説明が操作を設定するのを好む人のための、より具体的な説明をするべきです。
AIntersect( (tag (ftp ftp.clark.net cme (* set read write))),
(tag (*)) )
AIntersect((タグ(ftp ftp.clark.net cme(書きます*セットが、読んだ)))、(タグ(*)))
evaluates to (tag (ftp ftp.clark.net cme (* set read write)))
評価(タグ(ftp ftp.clark.net cme(書きます*セットが、読んだ)))
AIntersect( (tag (* set read write (foo bla) delete)),
(tag (* set write read) ) )
AIntersect(タグ、((foo bla)に書く、*セットが、読んだ削除、)、(タグ(*設定されて、読まれて、書いてください))
evaluates to (tag (* set read write))
評価(タグ(書きます*セットが、読んだ))
AIntersect( (tag (* set read write (foo bla) delete)),
(tag read ) )
AIntersect(タグ、((foo bla)に書く、*セットが、読んだ削除、)、(読まれたタグ)
evaluates to (tag read)
評価(読まれたタグ)
AIntersect( (tag (* prefix http://www.clark.net/pub/)),
(tag (* prefix http://www.clark.net/pub/cme/html/)) )
AIntersect((タグ(*接頭語 http://www.clark.net/pub/ ))、(タグ(*接頭語 http://www.clark.net/pub/cme/html/ )))
evaluates to (tag (* prefix http://www.clark.net/pub/cme/html/))
評価(タグ(*接頭語 http://www.clark.net/pub/cme/html/ ))
AIntersect( (tag (* range numeric ge #30# le #39# )), (tag #26#) )
AIntersect((タグ(*範囲数値ge#30#le#39#))、(タグ#26#))
fails to intersect.
交差していません。
Ellison, et al. Experimental [Page 26] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[26ページ]RFC2693SPKIは理論1999年9月を証明します。
6.3.2 VIntersect
6.3.2 VIntersect
Date range intersection is straight-forward.
日付の範囲交差点は簡単です。
V = VIntersect( X, Y )
VはVIntersectと等しいです。(X、Y)
is defined as
定義されます。
Vmin = max( Xmin, Ymin )
Vmin=最大(Xmin、Ymin)
Vmax = min( Xmax, Ymax )
Vmax=分(Xmax、Ymax)
and if Vmin > Vmax, then the intersection failed.
そして、Vmin>Vmaxであるなら、交差点は失敗しました。
These rules assume that daytimes are expressed in a monotonic form, as they are in SPKI.
それらがSPKIにあって、これらの規則は、昼間が単調なフォームで言い表されると仮定します。
The full SPKI VIntersect() also deals with online tests. In the most straight-forward implementation, each online test to which a certificate is subject is evaluated. Each such test carries with it a validity interval, in terms of dates. That validity interval is intersected with any present in the certificate, to yield a new, current validity interval.
また、完全なSPKI VIntersect()はオンラインテストに対処します。 最も簡単な実現では、証明書は受けることがあるそれぞれのオンラインテストが評価されます。 そのような各テストはそれと共に日付に関して正当性間隔を運びます。 新しくて、現在の正当性間隔をもたらすためにはその正当性間隔によるいずれも中に交差される状態で証明書を提示するということです。
It is possible for an implementation of VIntersect() to gather up online tests that are present in each certificate and include the union of all those tests in the accumulating tuples. In this case, the evaluation of those online tests is deferred until the end of the process. This might be appropriate if the tuple reduction is being performed not for answering an immediate authorization question but rather for generation of a summary certificate (Certificate Result Certificate) that one might hope would be useful for a long time.
VIntersect()の実現が各証明書で存在しているオンラインテストを擦り取って、蓄積しているtuplesにそれらのすべてのテストの組合を含んでいるのは、可能です。 この場合、それらのオンラインテストの評価は過程の終わりまで延期されます。 tuple減少が即座の認可質問に答えるために実行されるのではなく、むしろ世代のために実行されているなら、これは人が長い間役に立つことを望むかもしれない概要証明書(証明書Result Certificate)で適切であるかもしれません。
6.3.3 Threshold Subjects
6.3.3 敷居対象
A threshold subject is specified by two numbers, K and N [0<K<=N], and N subordinate subjects. A threshold subject is reduced to a single subject by selecting K of the N subjects and reducing each of those K to the same subject, through a sequence of certificates. The (N-K) unselected subordinate subjects are set to (null).
敷居対象は2つの番号、K、N[0<K<はNと等しい]、およびN下位の対象によって指定されます。 敷居対象はN対象のKを選択して、それぞれのそれらのKを同じ対象に変えることによって、一人の被験者に変えられます、証明書の系列を通して。 (N K)の選ばれていない下位の対象は(ヌル)に設定されます。
The intermediate form for a threshold subject is a copy of the tuple in which the threshold subject appears, but with only one of the subordinate subjects. Those subordinate tuples are reduced individually until the list of subordinate tuples has (N-K) (null) entries and K entries with the same subject. At that point, those K tuples are validity-, authorization- and delegation- intersected to yield the single tuple that will replace the list of tuples.
敷居対象のための中間的フォームはしかし敷居対象が1だけと共に現れる下位の対象のtupleのコピーです。 下位のtuplesのリストには同じ対象による(ヌル)のエントリーとKエントリーがあるまで(N-K)、それらの下位のtuplesは個別に減少します。 その時それらのK tuplesが正当性である、認可と代表団は、tuplesのリストを置き換える単一のtupleをもたらすために交差しました。
Ellison, et al. Experimental [Page 27] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[27ページ]RFC2693SPKIは理論1999年9月を証明します。
6.3.4 Certificate Path Discovery
6.3.4 証明書経路発見
All reduction operations are in the order provided by the prover. That simplifies the job of the verifier, but leaves the job of finding the correct list of reductions to the prover.
すべての減少操作が証明装置によって提供されたオーダーにあります。それは、検証の仕事を簡素化しますが、証明装置への減少の正しいリストを見つける仕事を残します。
The general algorithm for finding the right certificate paths from a large set of unordered certificates has been solved[ELIEN], but might be used only rarely. Each keyholder who is granted some authority should receive a sequence of certificates delegating that authority. That keyholder may then want to delegate part of this authority on to some other keyholder. To do that, a single additional certificate is generated and appended to the sequence already available, yielding a sequence that can be used by the delegatee to prove access permission.
大きいセットの順不同の証明書から正しい証明書経路を見つけるための一般的なアルゴリズムは、解決されましたが[ELIEN]、めったにだけ使用されないかもしれません。 何らかの権威が与えられる各keyholderは、その権威を代表として派遣しながら、証明書の系列を受け取るはずです。 そして、そのkeyholderはこの権威の一部をある他のkeyholderへ代表として派遣したがっているかもしれません。 それをするために、ただ一つの追加証明書を既に利用可能な系列に作って、追加します、「反-遺産受取人」がアクセスが許可であると立証するのに使用できる系列をもたらして。
6.4 4-tuple Reduction
6.4 4-tuple減少
There will be name 4-tuples in two different classes, those that define the name as a key and those that define the name as another name.
2つの異なったクラス(別の名前と名前を定義するキーとものと名前を定義するもの)には名前4-tuplesがあるでしょう。
1. [(name K1 N) -> K2]
1. [(名前K1N)->ケーツー]
2. [(name K1 N) -> (name K2 N1 N2 ... Nk)]
2. (名前K1N) ->(名前ケーツーN1 N2…Nk]
As with the 5-tuples discussed in the previous section, name definition 4-tuples should be delivered in the order needed by the prover. In that case, the rule for name reduction is to replace the name just defined by its definition. For example,
前項で5-tuplesについて議論している場合、証明装置によって必要とされたオーダーで名前定義4-tuplesを届けるべきです。その場合、名前減少のための規則は定義でただ定義された名前を置き換えることです。 例えば
(name K1 N N1 N2 N3) + [(name K1 N) -> K2]
(名前K1N N1 N2 N3) +[(名前K1N)->ケーツー]
-> (name K2 N1 N2 N3)
->。(名前ケーツーN1 N2 N3)
or, in case 2 above,
または、上の2を中にケースに入れてください。
(name K1 N Na Nb Nc) + [(name K1 N) -> (name K2 N1 N2 ... Nk)]
(名前K1N Na Nb Nc) +(名前K1N) ->(名前ケーツーN1 N2…Nk]
-> (name K2 N1 N2 ... Nk Na Nb Nc)
->。(名前ケーツーN1 N2…Nk Na Nb Nc)
With the second form of name definition, one might have names that temporarily grow. If the prover is providing certificates in order, then the verifier need only do as it is told.
2番目の形式の名前定義によって、1つには、一時成長する名前があるかもしれません。 証明装置が整然とした状態で証明書を提供しているなら、それが言われるように確かめるだけでよいです。
Ellison, et al. Experimental [Page 28] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[28ページ]RFC2693SPKIは理論1999年9月を証明します。
If the verifier is operating from an unordered pool of tuples, then a safe rule for name reduction is to apply only those 4-tuples that define a name as a key. Such applications should bring 4-tuples that started out in class (2) into class (1), and eventually reduce all names to keys. Any naming loops are avoided by this process.
検証がtuplesの順不同のプールを中心に活動しているなら、名前減少のための安全な規則は名前をキーと定義するそれらの4-tuplesだけを適用することです。 そのようなアプリケーションは、クラス(2)で始めた4-tuplesをクラス(1)にもたらして、結局、すべての名前をキーに変えるべきです。 どんな命名輪もこの工程で避けられます。
6.4.1 4-tuple Threshold Subject Reduction
6.4.1 4-tuple敷居対象減少
Some of a threshold subject's subordinate subjects might be names. Those names must be reduced by application of 4-tuples. The name reduction process proceeds independently on each name in the subordinate subject as indicated in 6.3.3 above.
敷居対象のいくつかの下位の対象が名前であるかもしれません。 それらの名前は4-tuplesのアプリケーションで減少しなければなりません。 名前減少過程売り上げは部下でそれぞれで独自に6.3にみられるように対象を上の.3と命名します。
One can reduce individual named subjects in a threshold subject and leave the subject in threshold form, if one desires. There is no delegation- or authorization-intersection involved, only a validity- intersection during name reduction. This might be used by a service that produces Certificate Result Certificates [see 6.7].
1つは、1つの願望であるなら敷居対象で個々の命名された対象を減少させて、敷居フォームに対象を残すことができます。 そこには、何か代表団もかかわる認可交差点、正当性交差点も名前減少の間、ありませんか? これはCertificate Result Certificatesを生産するサービスで使用されるかもしれません[6.7を見てください]。
6.4.2 4-tuple Validity Intersection
6.4.2 4-tuple正当性交差点
Whenever a 4-tuple is used to reduce the subject (or part of the subject) of another tuple, its validity interval is intersected with that of the tuple holding the subject being reduced and the intersection is used in the resulting tuple. Since a 4-tuple contains no delegation or authorization fields, the delegation permission and authorization of the tuple being acted upon does not change.
4-tupleが別のtupleの対象(または、対象の一部)を減少させるのに使用されるときはいつも、tupleが減少する対象と交差点を保持するのについて結果として起こるtupleで費やされる正当性間隔は交差されます。 4-tupleがどんな代表団も認可分野も含んでいないので、作用されるtupleの代表団許可と認可は変化しません。
6.5 Certificate Translation
6.5 証明書翻訳
Any certificate currently defined, as well as ACL entries and possibly other instruments, can be translated to 5-tuples (or name tuples) and therefore take part in an authorization computation. The specific rules for those are given below.
現在ACLエントリーとことによると他の器具と同様に定義されているどんな証明書も、5-tuples(または、名前tuples)に翻訳されて、したがって、認可計算に参加できます。 それらのための特定の規則を以下に与えます。
6.5.1 X.509v1
6.5.1 X.509v1
The original X.509 certificate is a <name,key> certificate. It translates directly to a name tuple. The form
オリジナルのX.509証明書は<名、主要な>証明書です。 それは直接名前tupleに移します。 フォーム
[Kroot, (name <leaf-name>), K1, validity]
[Kroot、(名前<葉名の>)、K1、正当性]
is used if the rules for that particular X.509 hierarchy is that all leaf names are unique, under that root. If uniqueness of names applies only to individual CAs in the X.509 hierarchy, then one must generate
規則がその特定のX.509階層構造がそれであるのですべてページをめくるなら使用されて、名前はその根の下でユニークです。 名前のユニークさがX.509階層構造のCAs、当時発生させなければならない個人だけに適用されるなら
Ellison, et al. Experimental [Page 29] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[29ページ]RFC2693SPKIは理論1999年9月を証明します。
[Kroot, (name CA1 CA2 ... CAk <leaf-name>), K1, validity]
[Kroot、(名前CA1 CA2…CAk<葉名の>)、K1、正当性]
after verifying the certificate chain by the rules appropriate to that particular chain.
証明書について確かめた後に、その特定のチェーンに適切な規則で、鎖を作ってください。
6.5.2 PGP
6.5.2 PGP
A PGP certificate is a <name,key> certificate. It is verified by web-of-trust rules (as specified in the PGP documentation). Once verified, it yields name tuples of the form
PGP証明書は<名、主要な>証明書です。 それは信用のウェブ規則によって確かめられます(PGPドキュメンテーションで指定されるように)。 いったん確かめられると、それは形式の名前tuplesをもたらします。
[Ki, name, K1, validity]
[気、名前、K1、正当性]
where Ki is a key that signed that PGP (UserID,key) pair. There would be one tuple produced for each signature on the key, K1.
KiがそのPGP(UserID、キー)にサインしたキーであるところと、対にしてください。 キーにおける各署名のために生産された、1tuple、K1があるでしょう。
6.5.3 X.509v3
6.5.3 X.509v3
An X.509v3 certificate may be used to declare a name. It might also declare explicit authorizations, by way of extensions. It might also declare an implicit authorization of the form (tag (*)). The actual set of tuples it yields depends on the documentation associated with that line of certificates. That documentation could conceptually be considered associated with the root key of the certificate chain. In addition, some X.509v3 certificates (such as those used for SET), have defined extra validity tests for certificate chains depending on custom extensions. As a result, it is likely that X.509v3 chains will have to be validated independently, by chain validation code specific to each root key. After that validation, that root-specific code can then generate the appropriate multiple tuples from the one certificate.
X.509v3証明書は、名前を宣言するのに使用されるかもしれません。 また、それは拡大を通して明白な承認を宣言するかもしれません。 また、それは形式(タグ(*))の暗黙の認可を宣言するかもしれません。 それがもたらすtuplesの実際のセットは証明書のその線に関連しているドキュメンテーションに依存します。 証明書チェーンのルートキーに関連していると概念的にそのドキュメンテーションを考えることができました。 添加、いくつかのX.509v3証明書(SETに使用されるものなどの)では、定義されたカスタム拡大による証明書チェーンに、余分な正当性テストを持ってください。 その結果、X.509v3チェーンは独自に有効にされなければならなそうでしょう、各ルートキーに特定のチェーン認証コードで。 そして、その合法化の後に、その根の特有のコードは1通の証明書から複数の適切tuplesを発生させることができます。
6.5.4 X9.57
6.5.4 X9.57
An X9.57 attribute certificate should yield one or more 5-tuples, with names as Subject. The code translating the attribute certificate will have to build a fully-qualified name to represent the Distinguished Name in the Subject. For any attribute certificates that refer to an ID certificate explicitly, the Subject of the 5-tuple can be the key in that ID certificate, bypassing the construction of name 4-tuples.
X9.57属性証明書はSubjectとして名前がある1 5-tuplesをもたらすはずです。 属性証明書を翻訳するコードは、SubjectにDistinguished Nameを表すために完全に修飾された名前を築き上げなければならないでしょう。 明らかにID証明書を示すどんな属性証明書に関してはも、5-tupleのSubjectはそのID証明書のキーであるかもしれません、名前4-tuplesの構造を迂回させて。
6.5.5 SDSI 1.0
6.5.5 SDSI1.0
A SDSI 1.0 certificate maps directly to one 4-tuple.
SDSI1.0証明書は直接1つに4-tupleを写像します。
Ellison, et al. Experimental [Page 30] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[30ページ]RFC2693SPKIは理論1999年9月を証明します。
6.5.6 SPKI
6.5.6 SPKI
An SPKI certificate maps directly to one 4- or 5- tuple, depending respectively on whether it is a name certificate or carries an authorization.
SPKI証明書は4か5tupleを直接1つに写像します、それぞれそれが名前証明書ですかそれとも認可を運ぶかによって。
6.5.7 SSL
6.5.7 SSL
An SSL certificate carries a number of authorizations, some implicitly. The authorization:
SSL証明書はそれとなく多くの承認をいくつか載せます。 認可:
(tag (ssl))
(タグ(ssl))
is implicit. In addition, the server certificate carries a DNS name parameter to be matched against the DNS name of the web page to which the connection is being made. That might be encoded as:
暗黙。 さらに、サーバ証明書は、接続がされているウェブページのDNS名に対して合わせられるためにDNS名前パラメタを載せます。 それは以下としてコード化されるかもしれません。
(tag (dns <domain-name>))
(タグ(dns<ドメイン名>))
Meanwhile, there is the "global cert" permission -- the permission for a US-supplied browser to connect using full strength symmetric cryptography even though the server is outside the USA. This might be encoded as:
その間、「グローバルな本命」許可があります--米国の外に米国によって供給されたブラウザがサーバですが、定員の左右対称の暗号を使用することで接続する許可があります。 これは以下としてコード化されるかもしれません。
(tag (us-crypto))
(タグ、(私たち、-、暗号、)
There are other key usage attributes that would also be encoded as tag fields, but a full discussion of those fields is left to the examples document.
また、タグ・フィールドとしてコード化される他の主要な用法属性がありますが、それらの分野の十分な議論は例のドキュメントに残されます。
An ACL entry for an SSL root key would have the tag:
SSLルートキーのためのACLエントリーには、タグがあるでしょう:
(tag (* set (ssl) (dns (*))))
(タグ(*(ssl)(dns(*))を設定してください))
which by the rules of intersection is equivalent to:
交差点の規則によるどれが以下に同等ですか?
(tag (* set (ssl) (dns)))
(タグ(*(ssl)(dns)を設定してください))
unless that root key also had the permission from the US Commerce Department to grant us-crypto permission, in which case the root key would have:
また、そのルートキーには米国商務省から交付金までの許可がなかった、私たち、-、暗号、許可、ルートキーでは、その場合、以下があるでしょう。
(tag (* set (ssl) (dns) (us-crypto)))
(タグ、(*(ssl)(dns)を設定してください、(私たち、-、暗号、)
Ellison, et al. Experimental [Page 31] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[31ページ]RFC2693SPKIは理論1999年9月を証明します。
A CA certificate, used for SSL, would then need only to communicate down its certificate chain those permissions allocated in the ACL. Its tag might then translate to:
そして、SSLに使用されるカリフォルニア証明書は、証明書チェーンの下で単にACLに割り当てられたそれらの許容を伝える必要があるでしょう。 そして、タグは以下のことのために翻訳されるかもしれません。
(tag (*))
(タグ(*))
A leaf server certificate for the Datafellows server might, for example, have a tag field of the form:
Datafellowsサーバのための葉のサーバ証明書には、例えば、フォームのタグ・フィールドがあるかもしれません:
(tag (* set (ssl) (dns www.datafellows.com)))
(タグ(*(ssl)(dns www.datafellows.com)を設定してください))
showing that it was empowered to do SSL and to operate from the given domain name, but not to use US crypto with a US browser.
米国ブラウザがある米国暗号を使用するのに権限を与えられるのではなく、SSLをして、それが与えられたドメイン名を中心に活動するのに権限を与えられたのを示します。
The use of (* set) for the two attributes in this example could have been abbreviated as:
(*セット)のこの例の2つの属性の使用は以下が簡略化されたかもしれません。
(tag (ssl www.datafellows.com))
(タグ(ssl www.datafellows.com))
while CA certificates might carry:
カリフォルニア証明書は運ばれるかもしれませんが:
(tag (ssl (*))) or just (tag (*))
(タグ(ssl(*)))か正当です。(タグ(*))
but separating them, via (* set), allows for a future enhancement of SSL in which the (ssl) permission is derived from one set of root keys (those of current CAs) while the (dns) permission is derived from another set of root keys (those empowered to speak in DNSSEC) while the (us-crypto) permission might be granted only to a root key belonging to the US Department of Commerce. The three separate tests in the verifying code (e.g., the browser) would then involve separate 5-tuple reductions from separate root key ACL entries.
しかし、(*セット)を通してそれらを切り離すとキー(DNSSECで話すのに権限を与えられたもの)がゆったり過ごす根のもう1セットから(dns)許可を得ますが、あるセットのルートキー(現在のCAsのもの)から(ssl)許可を得るSSLの今後の増進が考慮される、(私たち、-、暗号、)、米国商務省のものルートキーだけに許可を与えるかもしれません。 次にコード(例えば、ブラウザ)がかかわる検証における3つの別々のテストが別々のルートキーACLエントリーと5-tuple減少を切り離します。
The fact that these three kinds of permission are treated as if ANDed is derived from the logic of the code that interprets the permissions and is not expressed in the certificate. That decision is embodied in the authorization code executed by the verifying application.
これらの3種類の許可がまるで許容を解釈して、証明書に表されないコードの理論からANDedを得るかのように扱われるという事実。 その決定は検証アプリケーションで実行された許可コードに表現されます。
6.6 Certificate Result Certificates
6.6 証明書結果証明書
Typically, one will reduce a chain of certificates to answer an authorization question in one of two forms:
通常、1つは2つのフォームの1つでの承認質問に答えるために証明書のチェーンを減少させるでしょう:
1. Is this Subject, S, allowed to do A, under this ACL and with
this set of certificates?
1. このSubject、SはこのACLとこのセットの証明書でAができますか?
2. What is Subject S allowed to do, under this ACL and with this
set of certificates?
2. Subject SはこのACLとこのセットの証明書で何にすることができますか?
Ellison, et al. Experimental [Page 32] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[32ページ]RFC2693SPKIは理論1999年9月を証明します。
The answer to the second computation can be put into a new certificate issued by the entity doing the computation. That one certificate corresponds to the semantics of the underlying certificates and online test results. We call it a Certificate Result Certificate.
計算をする実体によって発行された新しい証明書に2番目の計算の答えを入れることができます。 その1通の証明書が基本的な証明書とオンライン試験の成績の意味論に一致しています。 私たちは、それをCertificate Result Certificateと呼びます。
7. Key Management
7. Key Management
Cryptographic keys have limited lifetimes. Keys can be stolen. Keys might also be discovered through cryptanalysis. If the theft is noticed, then the key can be replaced as one would replace a credit card. More likely, the theft will not be noticed. To cover this case, keys are replaced routinely.
暗号化キーは生涯を制限しました。 キーを盗むことができます。 また、キーは暗号文解読術で発見されるかもしれません。 窃盗に気付くなら、1つがクレジットカードを取り替えるようにキーを取り替えることができます。 おそらく、窃盗は気付かれないでしょう。 本件をカバーするために、きまりきってキーを取り替えます。
The replacement of a key needs to be announced to those who would use the new key. It also needs to be accomplished smoothly, with a minimum of hassle.
キーの交換は、新しいキーを使用する人に発表される必要があります。 また、それは、最小苦労でスムーズに達成される必要があります。
Rather than define a mechanism for declaring a key to be bad or replaced, SPKI defines a mechanism for giving certificates limited lifetimes so that they can be replaced. That is, under SPKI one does not declare a key to be bad but rather stops empowering it and instead empowers some other key. This limitation of a certificate's lifetime might be by limited lifetime at time of issuance or might be via the lifetime acquired through an on-line test (CRL, revalidation or one-time). Therefore, all key lifetime control becomes certificate lifetime control.
むしろ、SPKIは、それらを取り替えることができるように限られた生涯を証明書に与えるためにキーが悪いか取り替えられると宣言するためにメカニズムを定義するよりメカニズムを定義します。 すなわち、SPKIの下では、1つは、キーが悪いと宣言しませんが、それに権限を与えるのをむしろ止めて、代わりにある他のキーに権限を与えます。 証明書の生涯のこの制限を発行の限られた寿命時に、あるか、またはオンラインテスト(再合法化であるか1回のCRL)で生涯で取得するかもしれません。 したがって、すべての主要な生涯コントロールが証明書生涯コントロールになります。
7.1 Through Inescapable Names
7.1 不可避的な名前を通して
If keyholders had inescapable names [see section 2.5, above], then one could refer to them by those names and define a certificate to map from an inescapable name to the person's current key. That certificate could be issued by any CA, since all CAs would use the inescapable name for the keyholder. The attribute certificates and ACLs that refer to the keyholder would all refer to this one inescapable name.
keyholdersに不可避的な名前があるなら[セクション2.5を見てください、上です]、人は、それらの名前でそれらについて言及して、不可避的な名前から現在の人のキーまで写像する証明書を定義できるでしょうに。 すべてのCAsがkeyholderに不可避的な名前を使用するでしょう、したがって、どんなカリフォルニアもその証明書を発行できました。 属性証明書とkeyholderについて言及するACLsがすべて、この1つの不可避的な名前を示すでしょう。
However, there are no inescapable names for keyholders. [See section 2.5, above.]
しかしながら、どんなkeyholdersに、不可避的な名前もありません。 [上でセクション2.5を見てください。]
7.2 Through a Naming Authority
7.2 命名権威を通して
One could conceivably have a governmental body or other entity that would issue names voluntarily to a keyholder, strictly for the purpose of key management. One would then receive all authorizations through that name. There would have to be only one such authority,
1つには、自発的にkeyholderに名前を発行する政府のボディーか他の実体が多分あるかもしれません、厳密にかぎ管理の目的のために。 そして、人はその名前を通してすべての承認を受けるでしょう。 そこでは、そのような権威の1つであるだけでよいでしょう。
Ellison, et al. Experimental [Page 33] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[33ページ]RFC2693SPKIは理論1999年9月を証明します。
however. Otherwise, names would have to be composed of parts: an authority name and the individual's name. The authority name would, in turn, have to be granted by some single global authority.
. そうでなければ、名前がどのようにそうしても、部品で構成させてください: 権威名と個人の名前。 何らかのただ一つのグローバルな権威は順番に権威名を与えなければならないでしょう。
That authority then becomes able to create keys of its own and certificates to empower them as any individual, and through those false certificates acquire access rights of any individual in the world. Such power is not likely to be tolerated. Therefore, such a central authority is not likely to come to pass.
そして、その権威はどんな個人としてもそれらに権限を与えるためにそれ自身と証明書のキーを作成して、世界でそれらの偽の証明書を通してどんな個人のアクセス権も取得できるようになります。 そのようなパワーは許容されそうにはありません。 したがって、そのような主要な権威は起こりそうにはありません。
7.3 Through <name,key> Certificates
7.3 <名、主要な>証明書を通して
Instead of inescapable names or single-root naming authorities, we have names assigned by some entity that issues a <name,key> certificate. As noted in sections 2.8 and 2.9, above, such names have no meaning by themselves. They must be fully qualified to have meaning.
不可避的な名前かただ一つの根命名当局の代わりに、私たちは<名、主要な>証明書を発行する何らかの実体で名前を割り当てさせます。 セクション2.8と2.9で注意されるように、上では、そのような名前が自分たちで意味を持っていません。 完全に意味を持っているのにそれらに資格がなければなりません。
Therefore, in the construct:
したがって、構造物で:
(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim)
(名前(sha1| TLCgPLFlGTzgUbcaYLW8kGTEnUk=を論じ尽くしてください|)jim)
the name is not
存在でないという名前
"jim"
"jim"
but rather
むしろ
"(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim)"
「(名前(sha1| TLCgPLFlGTzgUbcaYLW8kGTEnUk=を論じ尽くしてください|)jim)」
This name includes a public key (through its hash, in the example above). That key has a lifetime like any other key, so this name has not achieved the kind of permanence (free from key lifetimes) that an inescapable name has. However, it appears to be our only alternative.
この名前は公開鍵(上記の例のハッシュを通した)を含んでいます。 そのキーにはいかなる他のキーのような寿命もあるので、この名前は不可避的な名前が持っている恒久的(主要な生涯の有でない)種類を実現していません。 しかしながら、それは私たちの唯一の選択肢であるように見えます。
This name could easily be issued by the named keyholder, for the purpose of key management only. In that case, there is no concern about access control being subverted by some third-party naming authority.
命名されたkeyholderはかぎ管理だけの目的のために容易にこの名前を発行できました。 その場合、権威を命名する第三者によって打倒されるアクセスコントロールに関する心配が全くありません。
7.4 Increasing Key Lifetimes
7.4 増加する主要な生涯
By the logic above, any name will hang off some public key. The job is then to increase the lifetime of that public key. Once a key lifetime exceeds the expected lifetime of any authorization granted through it, then a succession of new, long-lifetime keys can cover a keyholder forever.
論理で、上では、どんな名前も何らかの公開鍵にぶら下がるでしょう。 仕事はそして、その公開鍵の生涯を増強することです。 一度、主要な寿命はそれを通して与えられたどんな承認の予想された生涯も超えて、次に、新しくて、長い生涯のキーの流れはいつまでも、keyholderをカバーできます。
Ellison, et al. Experimental [Page 34] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[34ページ]RFC2693SPKIは理論1999年9月を証明します。
For a key to have a long lifetime, it needs to be strong against cryptanalytic attack and against theft. It should be used only on a trusted machine, running trusted software. It should not be used on an on-line machine. It should be used very rarely, so that the attacker has few opportunities to find the key in the clear where it can be stolen.
キーには長い寿命があるように、それは、cryptanalytic攻撃と窃盗に対して強い必要があります。 信じられたソフトウェアを動かして、それは信じられたマシンだけの上で使用されるべきです。 オンラインマシンの上でそれを使用するべきではありません。 めったにそれを使用するべきではありません、攻撃者には明確でキーを見つけるそれを盗むことができるわずかな機会しかないように。
Different entities will approach this set of requirements in different ways. A private individual, making his own naming root key for this purpose, has the advantage of being too small to invite a well funded attack as compared to the attacks a commercial CA might face.
異なった実体は異なった方法でこのセットの要件にアプローチするでしょう。 一私人には、彼自身にルートキーをこのために命名させて、商業カリフォルニアが直面するかもしれない攻撃と比べて、小さ過ぎるのがよく資金を供給された攻撃を招待する利点があります。
7.5 One Root Per Individual
7.5 1個人あたりの1つの根
In the limit, one can have one highly protected naming root key for each individual. One might have more than one such key per individual, in order to frustrate attempts to build dossiers, but let us assume only one key for the immediate discussion.
限界では、1つで、ルートキーを各個人にちなんで命名しながら、1つを非常に保護できます。 1つには、そのようなキーの1個人あたり1つ以上があるかもしれません、関係書類を築き上げる試みをだめにしますが、即座の議論に、1つだけが主要であると仮定しようというために。
If there is only one name descending from such a key, then one can dispense with the name. Authorizations can be assigned to the key itself, in raw SPKI style, rather than to some name defined under that key. There is no loss of lifetime -- only a change in the subject of the certificate the authorizing key uses to delegate authority.
そのようなキーから離す1つの名前しかなければ、1つは名前を省くことができます。 承認をキー自体に割り当てることができます、そのキーの下で定義された何らかの名前にというよりむしろ生のSPKIスタイルで。 生涯には損失が全くありません--認可キーが権限を委ねるのに使用する証明書の対象における変化だけ。
However, there is one significant difference, under the SPKI structure. If one delegates some authorization to
しかしながら、1つの著しい違いがSPKI構造の下にあります。 1つは何らかの承認を代表として派遣します。
(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) carl)
(名前(sha1| TLCgPLFlGTzgUbcaYLW8kGTEnUk=を論じ尽くしてください|)無作法者)
and a different authorization to
異なった承認
(hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|)
(sha1| TLCgPLFlGTzgUbcaYLW8kGTEnUk=を論じ尽くしてください|)
directly, both without granting the permission to delegate, that key can delegate at will through <name,key> certificates in the former case and not delegate at all in the latter case.
直接、ともに代表として派遣する許可を与えないで、そのキーは全く<を通して後者の場合で代表ではなく、名前、前のケースの中の主要な>証明書を自由自在に代表として派遣することができます。
In the case of key management, we desire the ability to delegate from a long lived, rarely used key to a shorter lived, often used key -- so in this case, the former mechanism (through a SDSI name) gives more freedom.
かぎ管理の場合では、私たちは長い送られて、めったに使用されなかったキーからの、より短い送られて、しばしば使用されたキーへの代表への能力を望んでいます--したがって、この場合、前のメカニズム(SDSI名を通した)は、より多くの自由を与えます。
Ellison, et al. Experimental [Page 35] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[35ページ]RFC2693SPKIは理論1999年9月を証明します。
7.6 Key Revocation Service
7.6 主要な取消しサービス
In either of the models above, key |TLCgPLFlGTzgUbcaYLW8kGTEnUk=| will issue a certificate. In the first model, it will be a <name,key> certificate. In the second, it will be an authorization certificate delegating all rights through to the more temporary key.
上のモデル、キーのどちらかで|TLCgPLFlGTzgUbcaYLW8kGTEnUk=| 証明書を下付するでしょう。 第1代モデルでは、それは<名、主要な>証明書になるでしょう。 2番目では、それは、より一時的なキーに終えたすべての権利を代表として派遣する承認証明書になるでしょう。
Either of those certificates might want an on-line validity test. Whether this test is in the form of a CRL, a re-validation or a one- time test, it will be supplied by some entity that is on-line.
それらの証明書のどちらかがオンライン正当性テストが欲しいかもしれません。 このテストがCRLのフォーム、再合法化または1つの時間テストであるか否かに関係なく、何らかのオンラインである実体からそれを供給するでしょう。
As the world moves to having all machines on-line all the time, this might be the user's machine. However, until then -- and maybe even after then -- the user might want to hire some service to perform this function. That service could run a 24x7 manned desk, to receive phone calls reporting loss of a key. That authority would not have the power to generate a new key for the user, only to revoke a current one.
世界が絶えずオンラインですべてのマシンを持っているのに移行するとき、これはユーザのマシンであるかもしれません。 次に、ユーザがしかしながら、それまで、この機能を実行するために多分何らかのサービスを雇いたがってさえいたかもしれない後に。 そのサービスは、キーの損失を報告する電話を受けるために24×7の有人のデスクを動かすかもしれません。 その権威には、ユーザのために新しいキーを生成して、単に現在のものを取り消すパワーがないでしょう。
If, in the worst case, a user loses his master key, then the same process that occurs today with lost wallets would apply. All issuers of authorizations through that master key would need to issue new authorizations through the new master key and, if the old master key had been stolen, cancel all old authorizations through that key.
ユーザが最悪の場合には彼のマスターキーをなくすなら、今日無くなっている財布で起こるのと同じプロセスは適用されるでしょう。 そのマスターキーを通した承認のすべての発行人が、そのキーを通して新しいマスターキーを通して新しい承認を発行して、古いマスターキーが盗まれたならすべての古い承認を取り消す必要があるでしょう。
7.7 Threshold ACL Subjects
7.7 敷居ACL対象
One can take extraordinary measures to protect root keys and thus increase the lifetimes of those keys. The study of computer fault- tolerance teaches us that truly long lifetimes can be achieved only by redundancy and replacement. Both can be achieved by the use of threshold subjects [section 6.3.3], especially in ACL entries.
ものはルートキーを保護して、その結果それらのキーの生涯を増強する並はずれた対策を実施できます。 単に冗長と交換でそんなに本当に、寛容が長い生涯私たちに教えるコンピュータ欠点の研究を達成できます。 特にACLエントリーにおける敷居対象[セクション6.3.3]の使用で両方を達成できます。
If we use a threshold subject in place of a single key subject, in an ACL (or a certificate), then we achieve redundancy immediately. This can be redundancy not only of keys but also of algorithms. That is, the keys in a threshold subject do not need to have the same algorithm.
ACLのただ一つの主要な対象に代わって敷居対象を使用するなら(または、証明書)、私たちはすぐに、冗長を達成します。 これはキーだけではなく、またアルゴリズムについて冗長であるかもしれません。すなわち、敷居対象のキーは同じアルゴリズムを必要としません。
Truly long lifetimes come from replacement, not just redundancy. As soon as a component fails (or a key is assumed compromised), it must be replaced.
本当に長い寿命は冗長だけではなく、交換から来ます。 コンポーネントが失敗すると(キーは感染されると思われます)すぐに、それを取り替えなければなりません。
An ACL needs to be access-controlled itself. Assume that the ACL includes an entry with authorization
ACLは、アクセスによってそれ自体で制御されている必要があります。 ACLが承認があるエントリーを含んでいると仮定してください。
(tag (acl-edit))
(タグ(acl-編集))
Ellison, et al. Experimental [Page 36] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[36ページ]RFC2693SPKIは理論1999年9月を証明します。
Assume also that what might have been a single root authorization key, K1, is actually a threshold subject
また、K1単一の根の承認キーであったかもしれないことが実際に敷居対象であると仮定してください。
(k-of-n #03# #07# K1 K2 K3 K4 K5 K6 K7)
(nのk#03##07#K1ケーツーK3 K4 K5 K6 K7)
used in any ACL entry granting a normal authorization.
正常な承認を与えるどんなACLエントリーでも、使用されています。
That same ACL could have the subject of an (acl-edit) entry be
その同じACLが(acl-編集)エントリーの対象をあることができました。
(k-of-n #05# #07# K1 K2 K3 K4 K5 K6 K7)
(nのk#05##07#K1ケーツーK3 K4 K5 K6 K7)
This use of threshold subject would allow the set of root keys to elect new members to that set and retire old members. In this manner, replacement is achieved alongside redundancy and the proper choice of K and N should allow threshold subject key lifetimes approaching infinity.
敷居対象のこの使用で、ルートキーのセットは、新しいメンバーをそのセットに選出して、古いメンバーを引退させるでしょう。 この様に、交換品は冗長と並んで実現されます、そして、KとNの適切な選択は無限にアプローチしながら、敷居の対象の主要な生涯を許容するべきです。
8. Security Considerations
8. セキュリティ問題
There are three classes of information that can be bound together by public key certificates: key, name and authorization. There are therefore three general kinds of certificate, depending on what pair of items the certificate ties together. If one considers the direction of mapping between items, there are six classes: name->key, key->name, authorization->name, name->authorization, authorization- >key, key->authorization.
公開鍵証明書で一緒に縛ることができる3つの情報の種類があります: キー、名前、および承認。 したがって、証明書が項目の何の組を結びつけるかによって、一般的な3種類の証明書があります。 人が項目の間のマッピングの方向を考えるなら、6つのクラスがあります: >を命名しているキー、主要な>の名前、承認->名義、>承認を命名して、承認>主要、そして、>承認を合わせます。
The SPKI working group concluded that the most important use for certificates was access control. Given the various kinds of mapping possible, there are at least two ways to implement access control. One can use a straight authorization certificate:
SPKIワーキンググループは、証明書の最も重要な使用がアクセスコントロールであると結論を下しました。 様々な種類の可能なマッピングを考えて、アクセスがコントロールであると実装する少なくとも2つの方法があります。 1つはまっすぐな承認証明書を使用できます:
(authorization->key)
(承認->主要である、)
or one can use an attribute certificate and an ID certificate:
または、1つは属性証明書とID証明書を使用できます:
(authorization->name) + (name->key)
(承認->名義、)、+(>を命名しているキー)
There are at least two ways in which the former is more secure than the latter.
前者が後者より安全である少なくとも2つの方法があります。
1. Each certificate has an issuer. If that issuer is subverted,
then the attacker can gain access. In the former case, there is
only one issuer to trust. In the latter case, there are two.
1. 各証明書には、発行人があります。 その発行人が打倒されるなら、攻撃者はアクセサリーを獲得できます。 前の場合には、信じる1つの発行人しかありません。 後者の場合には、2があります。
2. In the second case, linkage between the certificates is by name.
If the name space of the issuer of the ID certificate is
different from the name space of the issuer of the attribute
2. 2番目の場合には、証明書の間のリンケージが名前であります。 ID証明書の発行人の名前スペースが属性の発行人の名前スペースと異なるなら
Ellison, et al. Experimental [Page 37] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[37ページ]RFC2693SPKIは理論1999年9月を証明します。
certificate, then one of the two issuers must use a foreign name
space. The process of choosing the appropriate name from a
foreign name space is more complex than string matching and
might even involve a human guess. It is subject to mistakes.
Such a mistake can be made by accident or be guided by an
attacker.
証明書、当時2つの発行人の1つは外国名前スペースを使用しなければなりません。 外国名前スペースから適切な名前を選ぶプロセスはマッチングを結んで、人間の推測にかかわりさえするかもしれないより複雑です。 それは誤りを被りやすいです。 そのような誤りを偶然に作るか、または攻撃者は誘導できます。
This is not to say that one must never use the second construct. If the two certificates come from the same issuer, and therefore with the same name space, then both of the security differentiators above are canceled.
これは、2番目の構造物を決して使用してはいけないと言わないためのものです。 2通の証明書が同じ発行人、およびしたがって、同じ名前スペースと共に来るなら、上のセキュリティ識別因子の両方が取り消されます。
References
参照
[Ab97] Abadi, Martin, "On SDSI's Linked Local Name Spaces",
Proceedings of the 10th IEEE Computer Security
Foundations Workshop (June 1997).
[Ab97] Abadi、マーチン、「SDSIの繋がっている地方名空間」、第10IEEEコンピュータセキュリティ財団ワークショップ(1997年6月)の議事。
[BFL] Matt Blaze, Joan Feigenbaum and Jack Lacy, "Distributed
Trust Management", Proceedings 1996 IEEE Symposium on
Security and Privacy.
[BFL] ジョーン・ファイゲンバウムの、そして、ジャックLacyのつや消しの炎、「分配された信頼管理」、セキュリティに関する議事1996IEEEシンポジウム、およびプライバシー。
[CHAUM] D. Chaum, "Blind Signatures for Untraceable Payments",
Advances in Cryptology -- CRYPTO '82, 1983.
「追跡不可能な支払いのための盲目の署名」という[CHAUM]D.Chaumは暗号理論で進みます--暗号1983 82年。
[DH] Whitfield Diffie and Martin Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Theory,
November 1976, pp. 644-654.
[DH] ホイットフィールド・ディフィーとマーチン・ヘルマン、「暗号に関する新傾向」、情報Theory、1976年11月、ページのIEEE Transactions 644-654.
[DvH] J. B. Dennis and E. C. Van Horn, "Programming Semantics
for Multiprogrammed Computations", Communications of the
ACM 9(3), March 1966.
[DvH]J.B.デニスとE.C.バン・ホーン、「マルチプログラムの計算のためのプログラミング意味論」、ACM 9(3)(1966年3月)に関するコミュニケーション。
[ECR] Silvio Micali, "Efficient Certificate Revocation",
manuscript, MIT LCS.
[ECR]シルビオMicali、「効率的な証明書取消し」、原稿、MIT LCS。
[ELIEN] Jean-Emile Elien, "Certificate Discovery Using SPKI/SDSI
2.0 Certificates", Masters Thesis, MIT LCS, May 1998,
<http://theory.lcs.mit.edu/~cis/theses/elien-masters.ps>
[also .pdf and
そして[ELIEN]ジーン-エイミールElien、「証明書発見使用SPKI/SDSI2.0証明書」、マスターズ論文、MIT LCS、1998年5月、<http://theory.lcs.mit.edu/~cis/論文/elien-masters.ps>、[.pdf、も。
[HARDY] Hardy, Norman, "THE KeyKOS Architecture", Operating
Systems Review, v.19 n.4, October 1985. pp 8-25.
[ハーディー]ハーディー、ノーマン、「KeyKOSアーキテクチャ」、Operating Systems Review、v.19 n.4、10月1985日のpp8-25。
[IDENT] Carl Ellison, "Establishing Identity Without
Certification Authorities", USENIX Security Symposium,
July 1996.
[IDENT]カール・エリソン、「証明当局なしでアイデンティティを確立します」、USENIXセキュリティシンポジウム、1996年7月。
Ellison, et al. Experimental [Page 38] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[38ページ]RFC2693SPKIは理論1999年9月を証明します。
[IWG] McConnell and Appel, "Enabling Privacy, Commerce,
Security and Public Safety in the Global Information
Infrastructure", report of the Interagency Working Group
on Cryptography Policy, May 12, 1996; (quote from
paragraph 5 of the Introduction).
「世界情報通信基盤における可能なプライバシー、商業、セキュリティ、および公安」というマッコネールとAppelが報告するCryptography Policyの上のInteragency作業部会の[IWG]、1996年5月12日。 (序論のパラグラフ5から、引用します。)
[KEYKOS] Bomberger, Alan, et al., "The KeyKOS(r) Nanokernel
Architecture", Proceedings of the USENIX Workshop on
Micro-Kernels and Other Kernel Architectures, USENIX
Association, April 1992. pp 95-112 (In addition, there
are KeyKOS papers on the net available through
<http://www.cis.upenn.edu/~KeyKOS/#bibliography>).
[KEYKOS]Bomberger、アラン、他、「KeyKOS(r) Nanokernel構造」、Micro-カーネルのUSENIX WorkshopとOther Kernel Architectures、USENIX AssociationのProceedings、4月1992日のpp95-112(さらに、<http://www.cis.upenn.edu/~KeyKOS/#図書目録>を通して利用可能なネットに関してKeyKOS論文があります)。
[KOHNFELDER] Kohnfelder, Loren M., "Towards a Practical Public-key
Cryptosystem", MIT S.B. Thesis, May. 1978.
[KOHNFELDER]Kohnfelder、ロレーンM.、「実用的な公開カギ暗号系」MIT S.B.論文はそうするかもしれません。 1978.
[LAMPSON] B. Lampson, M. Abadi, M. Burrows, and E. Wobber,
"Authentication in distributed systems: Theory and
practice", ACM Trans. Computer Systems 10, 4 (Nov.
1992), pp 265-310.
[ランプソン]のB.ランプソン、M.Abadi、M.バロウズ、およびE.Wobber、「分散システムにおける認証:」 「理論と習慣」、ACM Trans。 コンピュータシステムズ10、4(1992年11月)、pp265-310。
[LANDAU] Landau, Charles, "Security in a Secure Capability-Based
System", Operating Systems Review, Oct 1989 pp 2-4.
[ランドー]ランドー、チャールズ、「安全な能力ベースのシステムにおけるセキュリティ」、Operating Systems Review、1989年10月のpp2-4。
[LEVY] Henry M. Levy, "Capability-Based Computer Systems",
Digital Press, 12 Crosby Dr., Bedford MA 01730, 1984.
[課税]ヘンリーM.課税、「能力ベースのコンピュータシステム」、デジタルプレス12クロズビーベッドフォード博士(MA)、01730、1984。
[LINDEN] T. A. Linden, "Operating System Structures to Support
Security and Reliable Software", Computing Surveys 8(4),
December 1976.
1976年12月の調査を計算する[リンデン]T.A.リンデンと、「セキュリティを支持するオペレーティングシステム構造と高信頼のソフトウェア」8(4)。
[PKCS1] PKCS #1: RSA Encryption Standard, RSA Data Security,
Inc., 3 June 1991, Version 1.4.
[PKCS1]PKCS#1: 標準のRSA暗号化RSA Data Security Inc.、1991年6月3日、バージョン1.4。
[PKLOGIN] David Kemp, "The Public Key Login Protocol", Work in
Progress.
[PKLOGIN]デヴィッド・ケンプ、「公開鍵ログインプロトコル」は進行中で働いています。
[R98] R. Rivest, "Can We Eliminate Revocation Lists?", to
appear in the Proceedings of Financial Cryptography
1998, <http://theory.lcs.mit.edu/~rivest/revocation.ps>.
[R98] R. 最もRivestに、「私たちは取消しリストを排除できますか?」、Financial Cryptography1998のProceedings、<http://theory.lcs.mit.edu/~rivest/revocation.ps>に現れるように。
[RFC1114] Kent, S. and J. Linn, "Privacy Enhancement for Internet
Electronic Mail: Part II -- Certificate-Based Key
Management", RFC 1114, August 1989.
[RFC1114] ケント、S.、およびJ.リン、「インターネット電子メールのためのプライバシー増進:」 「IIを分けてください--証明書ベースのKey Management」、RFC1114、8月1989日
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[RFC1321] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
Ellison, et al. Experimental [Page 39] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[39ページ]RFC2693SPKIは理論1999年9月を証明します。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, December 1996.
解放された[RFC2045]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年12月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
December 1996.
解放された[RFC2046]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年12月。
[RFC2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII
Text", RFC 2047, December 1996.
[RFC2047]K.ムーア、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、1996年12月。
[RFC2065] Eastlake, D. and C. Kaufman, "Proposed Standard for DNS
Security", RFC 2065, January 1997.
[RFC2065] イーストレークとD.とC.コーフマン、「DNSセキュリティの提案された標準」、RFC2065、1997年1月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[SDSI] Ron Rivest and Butler Lampson, "SDSI - A Simple
Distributed Security Infrastructure [SDSI]",
<http://theory.lcs.mit.edu/~cis/sdsi.html>.
[SDSI] ロンRivestとバトラーランプソン、「SDSI--、簡単な分配されたセキュリティインフラストラクチャ[SDSI]、」、<http://theory.lcs.mit.edu/~cis/sdsi.html>。
[SET] Secure Electronic Transactions -- a protocol designed by
VISA, MasterCard and others, including a certificate
structure covering all participants. See
<http://www.visa.com/>.
[SET]Secure Electronic Transactions--すべての関係者を覆う証明書構造を含むVISA、マスターカード、および他のものによって設計されたプロトコル。 <http://www.visa.com/>を見てください。
[SEXP] Ron Rivest, code and description of S-expressions,
<http://theory.lcs.mit.edu/~rivest/sexp.html>.
[SEXP] S-表現、<http://theory.lcs.mit.edu/~rivest/sexp.html>のロンRivest、コード、および記述。
[SRC-070] Abadi, Burrows, Lampson and Plotkin, "A Calculus for
Access Control in Distributed Systems", DEC SRC-070,
revised August 28, 1991.
[SRC-070] Abadi、バロウズ、ランプソン、およびPlotkin(「分散システムにおけるアクセス管理のための微積分学」、DEC SRC-070)は1991年8月28日に復習しました。
[UPKI] C. Ellison, "The nature of a useable PKI", Computer
Networks 31 (1999) pp. 823-830.
[UPKI]C.エリソン、「useable PKIの自然」、コンピュータNetworks31(1999)ページ 823-830.
[WEBSTER] "Webster's Ninth New Collegiate Dictionary", Merriam-
Webster, Inc., 1991.
[ウェブスター] 「ウェブスターの第9新しい大学生用辞典」、メリアムウェブスターInc.、1991。
Acknowledgments
承認
Several independent contributions, published elsewhere on the net or in print, worked in synergy with our effort. Especially important to our work were: [SDSI], [BFL] and [RFC2065]. The inspiration we received from the notion of CAPABILITY in its various forms (SDS-940, Kerberos, DEC DSSA, [SRC-070], KeyKOS [HARDY]) can not be over-rated.
ほかの場所でネットか印刷して発行されたいくつかの独立している貢献が私たちの努力がある相乗作用で働いていました。 私たちの仕事に特に重要であるのは、以下の通りでした。 [SDSI]、[BFL]、および[RFC2065。] 私たちが様々なフォーム(SDS-940、ケルベロス、DEC DSSA、[SRC-070]、KeyKOS[ハーディー])でCAPABILITYの概念から受けたインスピレーションを過大評価できません。
Ellison, et al. Experimental [Page 40] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[40ページ]RFC2693SPKIは理論1999年9月を証明します。
Significant contributions to this effort by the members of the SPKI mailing list and especially the following persons (listed in alphabetic order) are gratefully acknowledged: Steve Bellovin, Mark Feldman, John Gilmore, Phill Hallam-Baker, Bob Jueneman, David Kemp, Angelos D. Keromytis, Paul Lambert, Jon Lasser, Jeff Parrett, Bill Sommerfeld, Simon Spero.
SPKIメーリングリストのメンバーと特に以下の人々(アルファベット順に記載されています)によるこの努力への重要な貢献は感謝して承諾されます: スティーブBellovin、Mark Feldman、ジョン・ギルモア、フィル・ハラム-ベイカー、ボブJueneman、デヴィッド・ケンプ、Angelos D.Keromytis、ポール・ランバート、ジョン・ラサー、ジェフParrett、ビル・ゾンマーフェルト(サイモンSpero)。
Authors' Addresses
作者のアドレス
Carl M. Ellison Intel Corporation 2111 NE 25th Ave M/S JF3-212 Hillsboro OR 97124-5961 USA
カールM.エリソンインテル社2111の第25Ne Ave M/S JF3-212ヒルズバロか97124-5961米国
Phone: +1-503-264-2900
Fax: +1-503-264-6225
EMail: carl.m.ellison@intel.com
cme@alum.mit.edu
Web: http://www.pobox.com/~cme
以下に電話をしてください。 +1-503-264-2900 Fax: +1-503-264-6225 メールしてください: carl.m.ellison@intel.com cme@alum.mit.eduウェブ: http://www.pobox.com/~cme
Bill Frantz Electric Communities 10101 De Anza Blvd. Cupertino CA 95014
ビルフランツ電気共同体10101DeアンサBlvd. カルパチーノカリフォルニア 95014
Phone: +1 408-342-9576 EMail: frantz@netcom.com
以下に電話をしてください。 +1 408-342-9576 メールしてください: frantz@netcom.com
Butler Lampson Microsoft 180 Lake View Ave Cambridge MA 02138
バトラーランプソンマイクロソフト180レイク・ビューAveケンブリッジMA 02138
Phone: +1 617-547-9580 (voice + FAX) EMail: blampson@microsoft.com
以下に電話をしてください。 +1 617-547-9580(声+ファックス)に、メールしてください: blampson@microsoft.com
Ellison, et al. Experimental [Page 41] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[41ページ]RFC2693SPKIは理論1999年9月を証明します。
Ron Rivest Room 324, MIT Laboratory for Computer Science 545 Technology Square Cambridge MA 02139
ロンRivest部屋324、MITコンピュータサイエンス研究所545の技術の正方形のケンブリッジMA 02139
Phone: +1-617-253-5880 Fax: +1-617-258-9738 EMail: rivest@theory.lcs.mit.edu Web: http://theory.lcs.mit.edu/~rivest
以下に電話をしてください。 +1-617-253-5880 Fax: +1-617-258-9738 メールしてください: rivest@theory.lcs.mit.edu ウェブ: http://theory.lcs.mit.edu/~rivest
Brian Thomas Southwestern Bell One Bell Center, Room 34G3 St. Louis MO 63101 USA
ブライアントーマス南西のベル1ベルセンター、余地の34G3セントルイスMO63101米国
Phone: +1 314-235-3141 Fax: +1 314-235-0162 EMail: bt0008@sbc.com
以下に電話をしてください。 +1 314-235-3141Fax: +1 314-235-0162 メールしてください: bt0008@sbc.com
Tatu Ylonen SSH Communications Security Ltd. Tekniikantie 12 FIN-02150 ESPOO Finland
Tatu Ylonenセキュアシェル (SSH)通信秘密保全株式会社Tekniikantie12フィン-02150エスポーフィンランド
EMail: ylo@ssh.fi
メール: ylo@ssh.fi
Ellison, et al. Experimental [Page 42] RFC 2693 SPKI Certificate Theory September 1999
エリソン、他 実験的な[42ページ]RFC2693SPKIは理論1999年9月を証明します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Ellison, et al. Experimental [Page 43]
エリソン、他 実験的[43ページ]
一覧
スポンサーリンク
