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
SPKI Certificate Theory
Status of this 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.
著作権（C）インターネット協会（1999）。全著作権所有。
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証明書とACLの背後にある理論を提供します。
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
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
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節：有効条件の議論：日付範囲、CRLを再検証し、一回のオンライン有効性をテストします。
Section 6: definition of 5-tuples and their reduction.
セクション6：5タプルの定義とその削減。
Section 7: discussion of key management.
セクション7：鍵管理についての議論。
Section 8: security considerations.
第8章：セキュリティの考慮事項。
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.
参考文献セクションでは、このトピックで読んで誰にも興味があるかもしれない測定値だけでなく、テキストで参照されるすべての文書を示しています。
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.]
主にワーキンググループを開始してからの貢献者のリストを含む謝辞セクション、。 [ワーキンググループメールのアーカイブは、貢献者情報のより正確なソースです。]
The Authors' Addresses section gives the addresses, telephone numbers and e-mail addresses of the authors.
著者のアドレス部分は、執筆者の住所、電話番号、電子メールアドレスを提供します。
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エントリが潜在的に証明書本体と同じ内容を有するが、全く発行者を有していない（そして署名されていません）。各制御リソースのない場合は、各リソースの所有者のための1つのACLは、最も可能性があります。
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.
CERTIFICATE：件名を支援し署名した楽器。それは、少なくとも発行者と件名が含まれています。これは、有効条件、認可および委任情報を含めることができます。証明書は、次の3つのカテゴリに来る：ID（マッピング<名、キー>）、属性（マッピング<承認、名>）、および承認（マッピング<認証、キー>）。 SPKIの許可または属性証明書は、発行者から受信したか、そのエンパワーメントの一部のみに沿って渡すことができ、すべてのエンパワーメントに沿って渡すことができます。
ISSUER: the signer of a certificate and the source of empowerment that the certificate is communicating to the Subject.
ISSUER：証明書の署名と証明書が被験者に通信している権限委譲のソース。
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.
キーホルダー：指定した秘密鍵を所有し、支配する者または他のエンティティ。このエンティティは、鍵ペアのキーホルダーか、単に公開鍵であると言われますが、秘密鍵の管理は、すべてのケースで想定されます。
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.
プリンシパル：暗号鍵、デジタル署名を生成することができます。私たちは、この文書の公開鍵署名を扱うが、任意のデジタル署名方式が適用されるべきです。
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.
話すこと：校長は、デジタル署名によって「話す」と言われています。声明は、署名されたオブジェクト（多くの場合、証明書）です。校長はキーホルダー「のために話す」と言われています。
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エントリによって力を与え事。これは、いくつかのオブジェクトのハッシュ、又は閾値関数に配置されたキーのセット（名前は、いくつかのキーまたは他のオブジェクトへの証明書によってマッピングされることを理解して）キーの形、名前であってもよいです。
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-EXPRESSION：SPKI / SDSIのために選択されたデータフォーマット。これは、空のリストが許可されていないと、任意のS-expressionの最初の要素が文字列でなければならないという制限が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".
THRESHOLD件名：N他の対象のKを指定するACLエントリまたは証明書のサブジェクト。概念的に、ACLエントリまたは証明書によって対象に伝達される電力は、リストされた各下位被験者に（1 / K）量で送信されます。これらの従属対象のKに沿って渡すことがその力のために（同じオブジェクトまたはキーに沿って彼らの株式を委譲することによって）に同意しなければなりません。このメカニズムは、フォールトトレランスを紹介し、「ルートキー」のためのフォールトトレランスを提供し、ACLエントリに特に有用です。
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.
名前にキーまたはキーに名前をバインド：証明書は、もともと一つの機能を持つと見ました。この考えは、バックディフィー及びヘルマンは、その前の時間に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]
ディフィー及びヘルマンは、彼らは根本的にこの問題を解決したと思いました。 「各ユーザーが自分の端末では、逆変換、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 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."
この修正された電話帳は、完全に公共の、信頼できる宅配便の開催されました。このディレクトリは、オンライン置くため、世界的に、オンデマンドで利用できるようにすることができます。その見通しを考慮して、ローレン・コーンフェルダーは、MIT [KOHNFELDER]から電気工学の彼の1978年学士論文では、注意：「（可能な場合は直接接触することによって）暗号化機能が確実のコミュニ間で共有することができたときに公開鍵通信が最適に動作します。機能のように信頼性の交換が不可能な場合、まだ次善の策は、第三者を信頼することです。ディフィー及びヘルマンが公開ファイルとして知られている中央機関をご紹介します。」
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.
Kohnfelderはその後、「各個人が、彼は公開ファイルで参照されるシステムに名前をしている。2つのコミュニは、彼らが安全に通信できるパブリック・ファイルから互いの鍵を得たら指摘している。公開ファイルがデジタルのでその送信のすべてに署名します公開ファイルの敵の偽装が排除されています。」パフォーマンスの問題を防止するためには、Kohnfelderは、新しい構造を発明：名前と公開鍵を含むデジタル署名されたデータレコードを。彼はこの新しい証明書を作成すると呼ばれます。それはデジタル署名されたので、そのような証明書が信頼されていない当事者が保有することができ、中央ディレクトリに関わるパフォーマンスの問題を解決し、人から人への周りに渡されます。
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の論文の後、ISO X.509勧告は、X.500の一部として公開されました。 X.500は、名前付きエンティティのグローバルな分散データベースであることだった：人々、コンピュータ、プリンタ、など言い換えれば、それはグローバル、オンライン電話帳であることでした。名前空間の一部を所有している組織は、その部分を維持し、可能性もそれが保存されたコンピュータを提供することになります。 X.509証明書は、キーホルダーは、X.500ディレクトリ・ノードを変更する権限を持っていた注意することを意図してX.500パス名（識別名）に公開鍵をバインドするために定義されていました。実際には、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のアイデアも発生する可能性はありません。そのアイデアは、単一のグローバル・ネーミングの規律を必要とし、あまりにも多くの企業ではない、単一の規律の下の名前を定義するビジネスに既に存在しています。レガシー従って、このような考え方に不利に作用。
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.
インターネットエンジニアリングタスクフォース[RFC1114]のプライバシー強化メール[PEM]努力はなく、異なった解釈と、X.509証明書を採用しました。 X.509は、もともと「キーホルダーは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の採用が遅れました。 RIPEMは、MSUのマーク・リオーダンによって、X.509証明書のないPEMのバージョンでした。これは、分散型と小さなコミュニティで使用されるが、廃用に落ちました。 MOSS（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年、フィル・ジマーマンのPGPは、別の証明書モデルで導入されました。代わりに、単一のグローバルルートとそのルートから降順証明機関の階層を待つのではなく、PGPは、その有効性を証明する、<名、キー>協会に署名するために、複数の、（たぶん）の独立ではなく、特別に信頼できる個人を可能にしました。理論は、これらの署名者のすべてではないが壊れてしまうので、十分な署名と、その関連付けが信頼できるということでした。これは、「ウェブの信頼の」モデルとして知られていました。これは、バインディング<名、キー>の信頼性を確保する方法にX.509と異なって、それはまだキーにグローバルに一意の名前をバインドするためのもの。 PEMとPGPでは、その意図は、この認定グローバル名で世界で誰にも知られるようにキーホルダーのためでした。
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.
名前は、今度は、私たち人間は、人物の識別子として使用するものです。私たちは、幼児のように、この実践を学びます。家庭環境では名前は現在でも、識別子として働きます。私たちは幼児として学ぶことはその後の人生で再学習するのが特に困難です。人々はキーホルダーがキーホルダーの名前を知っている必要がありますにあるかを知る必要性を翻訳するため、それは自然なことです。
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.
コンピュータアプリケーションは、キーホルダーについての決定を行う必要があります。これらの決定は、ほぼキーホルダーの名前に基づいて厳密に行われることはありません。アプリケーションへの関心のキーホルダー程度（またはアプリケーションを実行している人間に）他のいくつかの事実があります。セキュリティ目的のために、すべての名前の機能と、そのほかの情報の一部のデータベース（またはヒトメモリ）へのインデックスとしてあります。この役割に奉仕するために、名前が指標として機能するためには、一意である必要があり、そしてインデックスを作成するいくつかの情報がなければなりません。
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年代初頭を通じて、関係者に形成され、一つはキーホルダーに会ったと仮定でき、したがって、その人についての知識を取得しました。名前はそのキーホルダーの十分な識別子であることがわかったことができれば、その後1はキーホルダーについての思い出にインデックスにその名前を使用して、関連する決定を下すことができるかもしれません。
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つが物理的な世界では完全な見知らぬ人ですキーホルダーが発生しますので、残る可能性が高いです。連絡先はデジタルで行われるとの関係の継続のためにデジタルのままになります。したがって、最初の出会いの任意の識別子によってインデックス付けされる知識のない体は存在しません。
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 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.
私たちが知っている人々を扱うときに、グローバルに一意なIDでも失敗することがあります。私たちのいくつかは、我々が扱う人と人の完全な特定の名前を知っています。人のためのグローバルにユニークな名前が完全な指定された名前よりも大きくなるだろう（そしておそらくそれを含んで、服従のうちに彼または彼女自身の名前のため人の思い入れに）。したがって、人間の行動の根本的な変化がなければ、私たちは人を知っている名前ではありません。
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は、それが認識サブフィールドを持っていないように（そのような長い番号またはランダム探してテキスト文字列など）の外観が均一なものです。また、入力ミスが別の有効な識別子を得ないであろうと（スパース十分な名前空間から）十分大きくなければなりません。
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.
彼らは、1つの名前で悪をやって彼の名前を変更して、もう一度やり直すから誰かを防ぐことができ避けられない識別子であったかのように一部の人々はグローバルIDを話します。戻って自分の識別子に任意の肉と血の人から得ることが常に可能であるように、そのシナリオをかなえるためには、（出生時おそらく政府による、）ような識別子の割り当てと、いくつかのメカニズムを持っている必要があります。後者のメカニズムを考えると、与えられた個別に証明書を発行することを望む任意の認証局は、おそらくその証明書について同じ、避けられない名前を選ぶだろう。バイオメトリクスのフルセットは、グローバルに割り当てられた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 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.
商用の認証機関が政治プロセスと、そのような反対が強く、これらの国ではそのような名前への反対をバイパスして、存在に避けられない名前をもたらすために使用されているかもしれないという懸念がありました。 （名前、キー）証明書の事業は、今日の進化しているように、複数の競合するCAはそれぞればらばら識別名スペースを作成するがあります。新しいCAの創造への実際のブロックもありません。したがって、人はこれらの名前は避けられない作り、CAを変更することで、1の識別名を削除し、別のものを取得することができます。
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は、グローバルに一意である必要はありません。むしろ、彼らはそのアドレス帳、電子メールエイリアスファイルやアカウントのリストを維持するもののエンティティに対して一意である必要があります。さらに重要なのは、彼らがインデックスとしてそれらを使用する人にとって有意義である必要があります。
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.
ロナルド・リベストとバトラー・ランプソンは1つが1がグローバルにローカル名を使用することができ、ローカルでローカル名を使用できるだけでなく、[SDSI] SDSI 1.0でした。明確なセキュリティの利点とSDSI名の運用の簡素化は、SPKI標準の一部としてSDSI名を採用するSPKIグループで私たちを引き起こしました。
A basic SDSI 2.0 name is an S-expression with two elements: the word "name" and the chosen name. For example,
単語「名」と選択された名前：基本的なSDSI 2.0名前は2つの要素を持つS式です。例えば、
george: (name fred)
ジョージ：（名前フレッド）
represents a basic SDSI name "fred" in the name space defined by george.
ジョージによって定義された名前空間に「フレッド」の基本的なSDSI名を表します。
If fred in turn defines a name, for example,
順番にフレッドは、たとえば、名前を定義している場合、
fred: (name sam)
フレッド：（名前SAM）
then george can refer to this same entity as
その後、ジョージは、この同じ実体を参照することができます
george: (name fred sam)
ジョージ：（名前フレッドSAM）
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つのキーホルダーにしたがって、1つの秘密鍵に対応します。バイト文字列として表示する公開鍵は、したがって、キーホルダーのための識別子です。
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.
衝突のないハッシュ関数が存在する場合は、公開鍵の衝突のないハッシュもキーホルダーのためのグローバル一意識別子、及び公開鍵よりも、おそらく短いものです。
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ローカル名は、その定義に大きな価値があります。それぞれのローカル名は、1つまたは複数のパブリックキーにマッピングし、したがって、対応するキーホルダー（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で保存、SDSI 1.0慣例です。
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名が証明書の外を発生することが、これまでである場合には、それが定義されている範囲内の名前空間が識別されなければなりません。これは、完全修飾SDSI名が生じます。この名前は、そのキーと比べて1つまたは複数の名前に続いて公開鍵です。 2つの以上の名前がある場合は、名前の文字列は、SDSI名前のチェーンです。例えば、
(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim therese)
（名（ハッシュSHA1 | TLCgPLFlGTzgUbcaYLW8kGTEnUk = |）ジム・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名です。
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識別名は、時には完全修飾名のように表現されなければならないことができます。グローバルネームスペースのための単一のルートのPEMまたは元のX.500ビジョンが叶ういた場合、すべての名前が同じ1つのルートキーからの相対になるので、これは必要ではないでしょう。しかし、そこに今ではなく、単一のルートキーであることが今までにありそうではありません。したがって、すべての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
そのルートから降順すべてのリーフ名がユニークである場合。一意性のみを個々の各CA内に強制されている場合、一つのフォームを得、X.509証明書チェーンから完全修飾名チェーンを構築することになります
(name <root key> <CA(1)> <CA(2)> ... <CA(k)> <leaf name>).
（名前<ルートキー> <CA（1）> <CA（2）> ... <CA（K）> <葉名>）。
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つの - したがって、名前付きグループは、複数の同じ名前（名前、鍵）証明書を発行することによって定義することができます。
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は、誰かに関連する名前でキーホルダーを識別することができます。
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.
公開鍵証明書またはそれらの集合が与えられたときただし、アプリケーションが行う必要があるか、リモートのキーホルダーは、いくつかのアクセスを許可されているかどうかの質問に答えるです。そのアプリケーションは、決定を下す必要があります。その決定に必要なデータがほとんどないキーホルダーの名前のスペルではありません。
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.
代わりに、アプリケーションはキーホルダーが、いくつかのアクセスを許可されるかどうかを知る必要があります。これは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]）
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で定義された、識別名に承認することができ、属性をバインドします。この情報を使用するアプリケーションの場合、それは完全なマッピングを得るためには、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名の認可およびその他の機関の権威、異なる発行体から来ました。これらの発行体のいずれかが覆された場合は、その後、攻撃者が不正に許可を得ることができました。そのため、発行体の両方が認可判断で、信頼する必要があります。
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.
この場合、承認と名前の両方の権限でなければならない唯一の発行者は、そこにあります。
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に限定されることが望ましいです。
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:
誰かがログ記録の目的のために、あるいは間違っ-行った後罰のために、キーホルダーの名前へのアクセスを望んでいる場合は、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
マッピングは、アクセス制御機構に必要なレベルのセキュリティで保護する必要があります。ザ・
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.
マッピング（および関連するすべての証明書の発行者）は、弁護士や私立探偵を満たすために十分安全である必要があるが、このマッピングの転覆は、アクセス制御を倒すために、攻撃者が許可していません。おそらく、このため、これらの証明書（またはデータベースエントリ）が作成されるとケアは、認証証明書が発行されているとケアほど重要です。唯一の異常な状況で人間の研究者によって使用されるので、名前へのマッピングは、オンラインであるか、または証明書として保護されていない必要があることも可能です。
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.
SDSI 1.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エントリはSDSI 1.0のように、被写体として名前を付けることができ、またはそれは、被写体としてのキーを持つことができます。後者の例としては、SSL対応ブラウザやユーザのホームUNIXディレクトリ内のファイルの.ssh / authorized_keysの中でSSLルートキーのリストが含まれています。これらのACLは、単一目的なので、個々のエントリは、明示的な権限を有していない、しかし、1つは、複数のアプリケーションに対処するために、共通の認証計算コードを使用することができるようにSPKIは、明示的な権限を使用しています。
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.
認証証明書の大国の一つは、関係するリソース（複数可）の所有者の手を煩わせることなく、別の人から権限を委任する機能です。一つは、（いくつかのファイルを読むために、例えば）、またはさらにその権限を委譲する権限を発行する簡単な許可を発行することがあります。
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つの問題が生じました。
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つのキャンプがありました。そこのキャンプでは、これらの各の賛成で残っているが、決定は、ブール型のコントロールの賛成で達しました。
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.
制御なしの賛成の引数にはキーホルダーが何かではなく、それを委譲する権限を行う権限を与えられている場合、挑戦に署名、そのキーホルダーは、権限を与えられた秘密鍵を貸し出すしたり、プロキシサービスを設定することも可能であるということですまたは意図デリゲートの要求。したがって、委譲する権限を制限しようとする試みは無効であるとバック火をかもしれない、不適切なセキュリティ対策につながることで。
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.
ブール型のコントロールを支持する引数は1つが委任できないことを指定する必要がありますということです。例えば、1は、米国商務省がエクスポート暗号化ソフトウェアモジュールを宣言することが許可され、また他の人（例えば、製造業者）への許可を委任するためのキーを持つ想像できます。商務省はこれをさらに委譲する権限を発行しないと考えるのが妥当です。つまり、それが唯一の法的合意が所定の位置にあることを反映するために、各メーカーとの直接の法的合意を持っており、その製造業者に証明書を発行したいと思います。
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.
整数制御を支持する引数は1つが委任権限の増殖を制御するために、代表団の深さを制限したいかもしれないということです。
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.
これら三つのうち、グループはブール制御を選びました。証明書または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.
制御なし引数は、論理的な魅力を持っていますが、ユーザーがそれを貸し出したり、それが他のユーザーにコピーすることができない場合、キーは、ハードウェアにロックされるということがないように十分に彼または彼女の秘密鍵を重視するという仮定が残っています。これは、署名Oracleの設定からユーザーを防ぐことはできませんが、ネットワーク接続の欠如は、そのメカニズムを阻害することがあります。
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.
整数制御オプションは、オリジナルのデザインだったと魅力を持っていますが、代表団の適切な深さを予測することができないことによって敗北しました。一つは常に（例えば、ノートPCでの使用のための）一時的な署名キーを作成することによって、1つのより下のレベルに移動する必要がありますすることができます。そのため、当初の予測深さは大幅にオフである可能性があります。
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.
権限の増殖を制御するためとして、そこに委任ツリーの幅にはコントロールがないので、その深さの制御は、増殖に対する厳格な管理ではありません。
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.
私たちは、委任者が委任権限を行使するためにも、それによって制御される新しい鍵ペアを作成し、そのキーへの権限を委任して自由であることを決定しました。したがって、誰かがそれを委任することを許可によって許可の行使を制限しようとするから何の利点がありませんでした。
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.
認証証明書の定義の一つの懸念は、関数は、伝統的な<承認、名> ACLとグループを定義する<名、キー> ID証明書によって行うことができるということです。そのような機構は、SDSI 1.0に記載しました。新しいメカニズムは、値を追加する必要があるか、それだけで、開発者のための生活を複雑にします。
The argument for delegated authorization as opposed to ACLs can be seen in the following example.
ACLのとは対照的に、委任承認のための引数は、次の例で見ることができます。
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のアクセスを許可する想像してみてください。そのため、宛先ネットワークの感度、強力なアクセス制御が望まれるであろう。一つは、個々のキーホルダーが誰を確立するために、公開鍵認証と公開鍵証明書を使用することができます。秘密鍵とキーホルダーの証明書の両方がフォルテッツァカード上に保存することができます。そのカードは、X.509v1証明書を保持しているので、確立することができるすべては、キーホルダーの名前です。名前のキーホルダーと、彼らはそれぞれ許可されるアクセスのフォームをリスト、ACLを維持するために、次にファイアウォールの仕事です。
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を必要とするだけでなく。一つは、例えば、軍の誰かが海軍の誰かがアクセスを得たかどうかを決定する力を持って持っていませんでした。実際には、ACLはおそらく1つの、独自のACLのレベルが、最終的に全体の国防総省の組織構造を反映したACLのネストされたセットを、必要はありませんでしょう。
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.
ACLをすることなく、ファイアウォールは、1つの容易に片手で保持できる密閉ユニット内に存在する、ノーマスストレージを有するデバイスで実施することができます。 ACLを使用して、アクセス制御の決定をしながらも、ACLを更新するためだけでなく、アクセスされる大規模な大容量記憶装置が必要になります。
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 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.
これとは対照的に、アクセスが認証証明書によって制御することができます。ファイアウォールは、国防長官にファイアウォールを介してすべてのアクセスを委任する権利を属するキーを付与する、一つのエントリでACLを持っているでしょう。長官は、順番に、証明書を発行するには、彼または彼女の部下のそれぞれに委譲するには、この権限を委任します。このプロセスは、いくつかの下士官の男は、いくつかの特定のプロトコルのためにそのファイアウォールを貫通する許可を受け取ることになるまで、反復が、その権限を委譲する権限を持っていないでしょう。
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.
生成された証明書の構造は、ネストされたACLが持っているのと同じように、全体国防総省の組織構造を反映することになるが、これらの証明書（その発行及び失効経由）の制御が分散され、その1つのファイアウォールに表示されない必要があるか、複製されますすべてのファイアウォールインチ許可の各個々の委任者は簡単な仕事で、よく理解し実行します。その委任を許可するアプリケーションソフトウェアは、それに応じて簡単です。
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、再検証とワンタイムを。
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で、証明書発行者は、妥当性確認の発行者を指定しなければなりません。
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 [証明書失効リスト]の初期の形は、スーパーマーケットのレジスタンドで保持するために使用されるニュースの印刷書籍をモデルにしました。これらの本は、後で、悪いクレジットカード番号を不正な当座預金口座番号のリストを保有して。 1の支払い機器がブックに記載されていなかった場合は、その機器が良いと考えられました。
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.
これらの本は、定期的に発行され、必ずしも一定の時間を割いていないいくつかの手段によって送達されるだろう。新しい本が到着したときしかし、店員は新しいものと古い版を交換し、それを使用して開始します。物理的な本の使用、物理的手段によって送達：このデザインは、実装の制約に適していました。悪いアカウントのリストが小さかったので、この本は悪い口座番号ではなく、良いものを開催しました。
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のデザインは、このモデルを踏襲しました。これは、取り消された証明書の識別子のリストを持っていました。 1より新しいだった2つのCRLのどの伝えることができるように、それはまた、シーケンス番号を持っていました。新しい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.
しかし、このプロセスは非決定的です。認証計算の結果は、少なくともタイミング依存しています。アクティブな敵を考えると、それはまた、セキュリティホールすることができます。すなわち、新規のCRLの配信を防止することにより、指定された証明書の失効を防止することができる敵です。これは単に改ざんネットワーク、暗号化レベルの労力を必要としません。
SPKI has ruled out the use of wandering anti-matter CRLs for its certificates. Every authorization computation is deterministic, under SPKI rules.
SPKIは、その証明書の反物質のCRLを放浪の使用を除外しています。すべての認証計算はSPKIの規則の下で、決定論的です。
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は時限のCRLを使用することが可能になります。証明書がCRLで参照することができる場合には、次にCRLプロセスは三つの条件が適用されています。
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をフェッチするかもしれない1つまたは複数の場所を与える可能性があり、キー（またはそのハッシュ）をリストする必要があります。
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の有効日付範囲が交差していなければなりません。それは1つが現在展開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は、証明書の完成ではなく、心の変更を発表し、世界へのメッセージです。
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.
CRLは非常に大きくなるかもしれないと、彼らは単調に成長する傾向があるため、1は完全なものではなく、CRLのへの変更を発行する場合がありますので。これは、CRLはデルタのCRLのシーケンスが続くフルCRLかもしれません、です。器具のその配列は、その後、現在のCRLとして扱われ、合わせたCRLは、上記の条件に従わなければなりません。
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).
CRLは否定文です。 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）であることが要求されます。
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?"
どちらも、CRLを時限と時間指定再検証は非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.
その質問への答えは、リスク管理から来ています。それはおそらく、少なくとも商用の場合で期待金銭的損失、に基づいて行われます。
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回の再検証を定義します。
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.
再検証のこの形式は、現行の許可の計算を超えて何の寿命を持っていません。一つは、nonceを含む要求を提出することによって、このオンライン、1回の再検証のために適用されます。それナンスは、リプレイ攻撃を防ぐために、署名再検証器に返されます。このプロトコルは、有効日付範囲の場所を取り、承認計算が完了した時点で開始と終了、ゼロの有効期間を表しています。
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.
1は短命証明書を発行したい場合は、SPKIは、交換短命証明書をフェッチするかもしれない証明書の利用者に伝えるために、オンラインテスト文の種類を定義します。
There are other possibilities to be considered when choosing a validity condition model to use.
使用するために有効条件のモデルを選択する際に考慮すべき他の可能性があります。
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].
シルヴィオ・マイカリは再検証または安価に証明書を失効するハッシュチェーンを使用するための仕組みの特許を取得しました。このメカニズムは、それらのモデルの性能要件を変更するため、パフォーマンス分析[ECR]からの結論を変更する場合があります。
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.
ロナルド・リベストはそれは、発行者（またはこの責任それが代表者にはいくつかの実体が）証明書が有効になる条件を決定することを前提としているため、全体有効条件モデルは欠陥があることを示唆している紙[R98]を書いています。その伝統的なモデルは、キーのリリースのため、キーの有効性を決定する責任がいくつかの中央機関が存在する軍事鍵管理のモデルと一致しています。
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構造定義に反映されません。それも、任意の代替妥当性ロジックは両方からの入力を含める必要がありますように、発行者と検証の両方が、この決定の株式を持っていることかもしれません。
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種類があります。
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.個々の証明書はその署名をチェックし、おそらく他の作業を行うことにより確認されています。次に、これらをここでは「タプル」と呼ばれる中間フォームにマッピングされています。
The other work for SPKI or SDSI certificates might include
processing of on-line test results (CRL, re-validation or one-
time validation).
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 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証明書の他の作品は、X.509の特定の使用のために書かれた文書に依存して（通常、証明書が降り、そこからルートキーに接続）と拡張で親証明書の情報だけでなく、追加情報を確認関与し得ます問題の証明書の。それは名前だけを定義するために、いくつかの使用の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).
オンライン試験は、証明書の処理に関与している場合、それらのオンライン試験結果の有効日付が日付を生成する証明書の有効日付を[以下、6.3.2で定義されている] VIntersect（）と交差します証明書のタプル（複数可）。
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タプルを減らすから入手名の定義に基づいて、単純な定義（キーまたはハッシュ）、に置き換えられます。
3. Authorization 5-tuples are then reduced to a final authorization result.
3.認可5タプルは、次いで、最終的な認証結果に還元されます。
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タプルは、完全性のためのデジタル署名を必要としないように、信頼メモリに保持されているものとの中間形態です。これは、証明書または信頼できるソフトウェアを介して、他の資格情報から生成されます。その内容はSPKI証明書本体の内容と同じであるが、それは、証明書の別のフォームから、またはACLエントリから導出することがあります。
The elements of a 5-tuple are:
5タプルの要素は次のとおりです。
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.件名：公開鍵（またはそのハッシュ）、公開鍵を識別するための名前、オブジェクトまたは下位被験者の閾値関数のハッシュ。これは、この中間結果では約話されているエンティティを識別する。
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の場合は、件名には、さらに、この中間結果で承認を伝播する発行者によって許可されています。
4. Authorization: an S-expression. [Rules for combination of Authorizations are given below.]
4.認証：S-表現。 [権限の組み合わせのための規則は以下の通りです。]
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 <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やSDSI 1.0など）は、許可フィールドを運ばないが、名前を運ぶん。それが許可証明書とは質的に異なるので、別々の中間形態は、それのために定義されています。
The elements of a Name 4-tuple are:
名前4タプルの要素は次のとおりです。
1. Issuer: a public key (or its hash). This identifies the entity defining this name in its private name space.
1.発行者：公開鍵（またはそのハッシュ）。これは、そのプライベート名前空間にこの名前を定義するエンティティを識別する。
3. Subject: a public key (or its hash), a name, or a threshold function of subordinate subjects. This defines the name.
3.件名：公開鍵（またはそのハッシュ）、名前、または下位の被験者の閾値関数。これは名前を定義します。
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.使用期限：「日付」は、日付と時刻を意味しない、前の日付と後のない日付、。 -前にいない日が続いソースの資格情報から欠落している場合は、マイナス無限大を想定しています。ない-後の日付が、その後行方不明プラスされている場合は無限大が想定されます。
The two 5-tuples:
2つの5タプル：
<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 = TRUE
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で後述するように、この規則のわずかな変形があります。
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.
認可はに意味を、おそらくアクセス制御のために、この認可を使用するアプリケーションによって定義されるの、文字列またはサブリストのリストです。二つの権限は、要素のために、要素を照合することによって交差します。 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アクセスを許可されることを意味するものではありかもしれません。これは、（より多くのアクセスを許可する）よりも一般的です
(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の交点は、第二のだろう。
Since the AIntersect rules imply position dependency, one could also define the previous authorization string as:
AIntersectルールは位置依存性を暗示しているので、1はまた、以前の許可ストリングを定義することができます。
(ftp ftp.clark.net /pub/cme)
（Ftp.clark.net FTP /パブ/ 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 list as if it had enough (*) entries implicitly appended to it to match the length of another list with which it was being intersected.]
（*）は、すべてのS式とバイト文字列のセットを表します。言い換えれば、それは何もマッチします。何と交差する場合、結果は他の事です。 【それは暗黙のうちに、それが交差されたものと別のリストの長さと一致するように付加十分な（*）エントリを持っていたかのように、異なる長さのリストについてAIntersectルールリストを扱います。]
(* 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.
（*接頭辞<バイト文字列>）* - 体に与えられた1で始まるすべてのバイト文字列のセットを表します。
(* 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は、（）は、上記であり、通常のリストは、それらの要素で始まるすべてのリストを意味すると理解されるよう* -formsが定義されている場合、通常の積集合です。以下の実施例は、動作を設定するために参照せずに説明を好む人のためのより具体的な説明を与えるべきです。
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（（タグ（*セットの読み取り、書き込み（フー・BLA）を削除））、（タグ（*セットは、読み取り、書き込み）））
evaluates to (tag (* set read write))
（タグ（*セット読み書き））と評価され
AIntersect( (tag (* set read write (foo bla) delete)), (tag read ) )
AIntersect（（タグ（*セットの読み取り、書き込み（フー・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＃ル＃39＃））、（タグ＃26＃））
fails to intersect.
交差に失敗しました。
Date range intersection is straight-forward.
日付範囲の交差点は、ストレートフォワードです。
V = VIntersect( X, Y )
V = VIntersect（X、Y）
is defined as
と定義されている
Vmin = max( Xmin, Ymin )
VMIN = MAX（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にあるようdaytimesは、単調な形で表現されると仮定する。
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（）の実装が可能です。この場合、これらのオンライン試験の評価は、プロセスの終了まで延期されます。タプルの減少は1が長い時間のために有用であろう願っていかもしれないことではないの即時承認の質問に答えるためにではなく、要約証明書（証明書の結果の証明書）の生成のために実行されている場合、これは適切な場合があります。
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).
閾値被験者は二つの数、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.
閾値被験者のための中間形態は、従属対象の一つだけでなく、閾値被写体が表示されるタプルのコピーです。下位タプルのリストは、同じ被写体と（N-K）（NULL）エントリおよびKエントリを有するまでそれらの下位の組は、個々に低減されます。その時点で、それらのKタプルはタプルのリストを置き換えます単一のタプルを生成するために交差authorization-とdelegation-、validity-です。
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]解決されていますが、まれにしか使われないことがあります。いくつかの権限を付与された各キーホルダーは、その権限委譲証明書のシーケンスを受信する必要があります。それキーホルダーはその後、いくつかの他のキーホルダーの上でこの権限の一部を委譲することもできます。これを行うには、単一の追加の証明書が生成され、アクセス許可を証明する委任先で使用できるシーケンスを得、すでに入手可能な配列に追加します。
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タプルがあります。
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タプルと同様に、名前の定義4タプルは、証明者によって必要とされる順序で配信されるべきです。その場合には、名前の低減のためのルールは、ちょうどその定義によって定義された名前を交換することです。例えば、
(name K1 N N1 N2 N3) + [(name K1 N) -> K2]
（名前K1 N N1 N2 N3）+ [（名前K1 N） - > K2]
-> (name K2 N1 N2 N3)
- >（名K2 N1 N2 N3）
or, in case 2 above,
あるいは、上記のケース2に、
(name K1 N Na Nb Nc) + [(name K1 N) -> (name K2 N1 N2 ... Nk)]
（名前K1 NのNaのNb NC）+ [（名前K1 N） - >（名前K2 N1 N2 ... NK）]
-> (name K2 N1 N2 ... Nk Na Nb Nc)
- >（名K2 N1 N2 ... Nkのナの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は一時的成長の名前を持っているかもしれません。証明者が順番に証明書を提供している場合、それは言われているように、検証者にのみ行う必要が。
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.
検証者は、タプルの順序付けられていないプールから動作している場合、その名前の低減のための安全規則は、キーとして名前を定義するだけ4-タプルを適用することです。このようなアプリケーションには、（1）クラスにクラスに始まった4タプル（2）を持参し、最終的にはキーにすべての名前を減らす必要があります。任意の名前を付けるループは、このプロセスによって回避されます。
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タプルの適用により低減されなければなりません。名前低減処理は、上記の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つは、しきい値対象に個別の名前の科目を減らし、しきい値形態で対象を残すことができます。何delegation-または認可-交差点関与、名前の還元時のみ有効性-交差点はありません。これは、[6.7を参照してください]証明書の結果の証明書を作成するサービスで使用される可能性があります。
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-タプルが別のタプルの対象（または対象の一部）を減少させるために使用されるときはいつでも、その有効期間が削減されると、交差点が得られた組で使用されている被写体を保持するタプルのそれと交差します。 4タプルは何の委任または認可のフィールドが含まれていないため、作用を受けるタプルの委任権限と許可は変更されません。
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タプル（または名前タプル）に変換し、したがって認可計算に参加することができます。それらのための具体的なルールは以下の通りです。
The original X.509 certificate is a <name,key> certificate. It translates directly to a name tuple. The form
オリジナルのX.509証明書は、<名、キー> [証明書です。これは、名前のタプルに直接変換します。フォーム
[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階層内の個々のCAにのみ適用された場合は、1が生成する必要があります
[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.
その特定のチェーンに適切な規則によって証明書チェーンを検証した後。
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のドキュメントに指定されている）これは、ウェブ・オブ・トラスト規則によって検証されます。確認したら、それは、フォームの名前のタプルを生成します
[Ki, name, K1, validity]
[KI、名前、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（ユーザーID、鍵）ペアを署名した鍵です。キー、K1上の各署名のために製造されたもののタプルが存在することになります。
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証明書は、名前を宣言するために使用することができます。また、拡張の方法により、明示的な権限を宣言する可能性があります。また、形式（タグ（*））の暗黙の承認を宣言する可能性があります。それが生み出すタプルの実際のセットは、証明書のその行に関連付けられたドキュメントに依存します。資料には、概念的に証明書チェーンのルートキーに関連付けられていると考えられます。また、（例えばSETのために使用されるものなど）いくつかのX.509v3証明書は、カスタム拡張機能に応じて、証明書チェーンのための余分な妥当性検査を定義しています。その結果、のX.509v3鎖が各ルートキーに固有のチェーン検証コードによって、独立して検証されなければならない可能性が高いです。その検証後、そのルート固有のコードは、1つの証明書から適切な複数のタプルを生成することができます。
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属性証明書は、件名などの名前で、一つ以上の5タプルを生成する必要があります。属性証明書を翻訳するコードが件名に識別名を表現するために完全修飾名を構築する必要があります。明示的にID証明書を参照して、任意の属性証明書のために、5タプルの件名名前4タプルの構成をバイパスして、そのIDの証明書でキーとすることができます。
A SDSI 1.0 certificate maps directly to one 4-tuple.
SDSI 1.0証明書は、1つの4組に直接マップします。
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証明書は、それが名前の証明書であるか、または認可を運ぶかどうかにそれぞれ応じて、1つの4-または5-タプルに直接マッピングします。
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）（米国暗号）））
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に使用するCA証明書は、その証明書チェーン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:
CA証明書が運ぶかもしれませんが。
(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.
しかし、（*セット）を介して、それらを分離する（DNS）許可が別の組から導出されている間（SSL）許可がルートキーの一組（現在のCAのもの）から誘導されたSSLの将来の拡張を可能にしますルートキー（DNSSECで話すために権限を与えられたもの）（米国暗号）許可が米国商務省に属するルートキーにのみ付与することかもしれないが。検証コード（例えば、ブラウザ）に3つの別々の試験は、次に、別ルート鍵ACLエントリから別5タプル削減を伴うだろう。
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種類の論理積が権限を解釈し、証明書には発現されないコードのロジックから誘導されるかのように扱われているという事実。この決定は、検証するアプリケーションで実行される認証コードで具体化されます。
Typically, one will reduce a chain of certificates to answer an authorization question in one of two forms:
典型的には、1つの2つの形式のいずれかでの認証質問に答えるために、証明書のチェーンを削減します。
1. Is this Subject, S, allowed to do A, under this ACL and with this set of certificates?
1.この対象となり、Sは、このACLの下と証明書のセットで、Aを行うことを許可されていますか？
2. What is Subject S allowed to do, under this ACL and with this set of certificates?
2. SはこのACLの下と証明書のこのセットで、行うことを許さ件名は何ですか？
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つの証明書は、基礎となる証明書の意味とオンラインテストの結果に対応しています。私たちは、証明書の結果の証明書と呼んでいます。
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の下で悪いことするキーを宣言するのではなく、それを力づける停止し、代わりに他のいくつかのキーに力を与えていない、です。証明書の有効期間のこの制限は、発行時に限られた寿命によってかもしれないまたはオンラインテスト（CRL、再検証または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.
キーホルダーは、[上記のセクション2.5を参照してください]避けられない名前を持っていた場合、その一つはそれらの名前によってそれらを参照して、人の現在のキーに避けられない名からマッピングするための証明書を定義することができます。すべてのCAはキーホルダーのために避けられない名前を使用しますので、その証明書は、任意のCAが発行することができます。キーホルダーを参照してください。属性証明書とACLはすべてこの1人の避けられない名前を参照することになります。
However, there are no inescapable names for keyholders. [See section 2.5, above.]
しかし、キーホルダーには避けられない名前がありません。 【上記セクション2.5を参照してください。]
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, 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.
その権限は、任意の個人としてそれらをエンパワーするために、独自の鍵と証明書を作成することになり、これらの偽の証明書を通じて、世界のどの個々のアクセス権を取得します。このような電力は許容される可能性が高いではありません。したがって、このような中央当局は、渡すために来そうにありません。
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 = |）ジム）
the name is not
名前ではありません
"jim"
「ジム」
but rather
むしろ
"(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim)"
"（名（ハッシュSHA1 | TLCgPLFlGTzgUbcaYLW8kGTEnUk = |）ジム）"
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.
この名前は簡単にのみ鍵管理の目的のために、名前のキーホルダーによって発行することができます。その場合には、いくつかのサードパーティの命名機関によって覆されているアクセス制御についての心配はありません。
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.
上記のロジックでは、任意の名前は、いくつかの公開鍵をオフにハングします。ジョブはその公開鍵の寿命を延ばすために、その後です。キーの有効期間は、それを介して付与された権限付与の予想寿命を超えると、新しい、長寿命のキーの連続は永遠にキーホルダーをカバーすることができます。
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.
キーが長い寿命を持つためには、暗号解読攻撃や盗難に強いする必要があります。それは、信頼できるソフトウェアを実行している、唯一の信頼できるマシン上で使用する必要があります。これは、オンラインのマシン上で使用すべきではありません。攻撃者は、それが盗まれる可能性が明らかにキーを見つけるためにいくつかの機会を持つようにそれは、非常にまれに使用されなければなりません。
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.
異なるエンティティは、異なる方法で要件のこのセットに近づきます。民間の個人は、この目的のために彼自身の命名ルートキーを作り、商用CAが直面するかもしれない攻撃に比べて十分に資金を提供し、攻撃を招待するには小さすぎるという利点があります。
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つのキーだけを想定してみましょう可能性があります。
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名を介して）元のメカニズムは、より多くの自由を与えます。
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 = |証明書を発行します。最初のモデルでは、それが<名、キー> [証明書になります。第二に、それはより多くの一時キーに至るまで、すべての権利を委譲する認証証明書になります。
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、再検証またはワンタイム試験の形態であるかどうか、それがオンラインであり、いくつかのエンティティによって供給されます。
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時間365日有人机を実行することができます。その権限は、現在の1を取り消すために、ユーザーの新しい鍵を生成する力を持っていないでしょう。
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.
、最悪の場合には、ユーザーが自分のマスターキーを紛失した場合、その後、失われた財布で今日起こる同じプロセスが適用されます。そのマスターキーによる権限のすべての発行体は、新しいマスターキーによる新たな権限を発行する必要があると、古いマスターキーが盗まれていた場合、そのキーを介してすべての古い権限を取り消します。
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編集））
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)
（K-の-N＃03＃07＃K1 K2 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)
（K-の-N＃05＃07＃K1 K2 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の適切な選択と一緒に達成されます。
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つのクラスがあります。証明書の絆、一緒アイテムのどの組に応じて、証明書の三つの一般的な種類は、それゆえあります。名 - >キー、キー - >名前、authorization->名、名 - >承認、authorization->キー、キー - >承認：1のアイテムとの間のマッピングの方向を考慮した場合、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つの方法があります。一つは、ストレートの認可証明書を使用することができます。
(authorization->key)
（authorization->キー）
or one can use an attribute certificate and an ID certificate:
または1つは、属性証明書とID証明書を使用することができます。
(authorization->name) + (name->key)
（authorization->名）+（名 - >キー）
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.各証明書は、発行者を持っています。その発行者が覆された場合、攻撃者がアクセスを得ることができます。前者の場合には、信頼する唯一の発行体が存在します。後者の場合、二つがあります。
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 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.
第二の場合で、[証明書の間の結合は、名前です。 ID証明書の発行者の名前空間は、属性証明書の発行者の名前空間と異なっている場合、2回の発行体の一つは、外部ネームスペースを使用する必要があります。外部ネームスペースから適切な名前を選択するプロセスは、文字列のマッチングよりも複雑であっても、人間の推測を伴うかもしれません。これは、ミスの対象となります。このような間違いは、事故により作製することができるか、攻撃者によって導かれます。
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.
これは、1つの第二構成体を使用することはありませんしなければならないということではありません。 2つの証明書が同じ発行者から、したがって、同じ名前空間に付属している場合は、上記のセキュリティ差別の両方がキャンセルされています。
References
リファレンス
[Ab97] Abadi, Martin, "On SDSI's Linked Local Name Spaces", Proceedings of the 10th IEEE Computer Security Foundations Workshop (June 1997).
[Ab97]アバディ、マーティン、10日IEEEコンピュータセキュリティの基礎ワークショップ（1997年6月）の議事「SDSIのリンクローカル名前空間について」。
[BFL] Matt Blaze, Joan Feigenbaum and Jack Lacy, "Distributed Trust Management", Proceedings 1996 IEEE Symposium on Security and Privacy.
セキュリティとプライバシー上の[BFL]マット・ブレイズ、ジョーン・ファイゲンバウムとジャック・レイシー、「分散・トラスト・マネジメント」、議事1996 IEEEシンポジウム。
[CHAUM] D. Chaum, "Blind Signatures for Untraceable Payments", Advances in Cryptology -- CRYPTO '82, 1983.
CRYPTO '82、1983 - [CHAUM] D. Chaum、 "ブラックサイト支払いにブラインド署名" は、暗号理論の進歩します。
[DH] Whitfield Diffie and Martin Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, November 1976, pp. 644-654.
[DH]ホイットフィールドディフィーとマーティン・ヘルマン、「暗号に関する新」、情報理論、1976年11月、頁644から654までのIEEEトランザクション。
[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]シルヴィオ・マイカリ、 "効率的な証明書の失効"、原稿、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、修士論文、MIT LCS、1998年5月、 "SPKI / SDSI 2.0証明書を使用して証明書ディスカバリー" <http://theory.lcs.mit.edu/~cis/theses/elien-masters。 PS> [また、PDFファイルと
[HARDY] Hardy, Norman, "THE KeyKOS Architecture", Operating Systems Review, v.19 n.4, October 1985. pp 8-25.
[HARDY]ハーディ、ノーマン、 "KeyKOSアーキテクチャ"、オペレーティングシステムレビュー、V.19のN.4、1985年10月頁8-25。
[IDENT] Carl Ellison, "Establishing Identity Without Certification Authorities", USENIX Security Symposium, July 1996.
[IDENT]カール・エリソン、USENIXセキュリティシンポジウム、1996年7月「証明機関がないとアイデンティティの確立」。
[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).
[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）ナノカーネルアーキテクチャ」、マイクロカーネルおよびその他のカーネルアーキテクチャ、USENIX協会が1992年4月95から112頁（また、上のUSENIXワークショップの議事録ネット上KeyKOSの論文は<http://www.cis.upenn.edu/~KeyKOS/#bibliography>）から入手できます。
[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.
【LAMPSON] B. Lampson、M.アバディ、M.バローズ、及びE. Wobber、 "分散システムにおける認証：理論と実践"、ACMトランス。コンピュータシステム10、4（1992年11月）、頁265から310まで。
[LANDAU] Landau, Charles, "Security in a Secure Capability-Based System", Operating Systems Review, Oct 1989 pp 2-4.
[ランダウ]ランダウ、チャールズ、「セキュア機能ベースのシステムのセキュリティ」、オペレーティングシステムレビュー、1989年10月頁2-4。
[LEVY] Henry M. Levy, "Capability-Based Computer Systems", Digital Press, 12 Crosby Dr., Bedford MA 01730, 1984.
[LEVY]ヘンリーM.レビー、 "能力ベースのコンピュータシステム"、デジタルプレス、12クロスビー博士は、マサチューセッツ州ベッドフォード01730、1984。
[LINDEN] T. A. Linden, "Operating System Structures to Support Security and Reliable Software", Computing Surveys 8(4), December 1976.
[LINDEN] T.のA.リンデン、 "オペレーティングシステムの構造は、セキュリティと信頼性の高いソフトウェアをサポートするために"、コンピューティング調査8（4）、1976年12月。
[PKCS1] PKCS #1: RSA Encryption Standard, RSA Data Security, Inc., 3 June 1991, Version 1.4.
[PKCS1] PKCS＃1：RSA暗号化規格、RSA Data Security社、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氏、 "我々は失効リストを排除することはできますか？"、金融暗号1998年の議事録に表示されるように、<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 - 証明書ベースのキー管理」、RFC 1114、1989年8月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[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）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、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：メディアタイプ"、RFC 2046、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.ムーア、 "MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張"、RFC 2047、1996年12月。
[RFC2065] Eastlake, D. and C. Kaufman, "Proposed Standard for DNS Security", RFC 2065, January 1997.
[RFC2065]イーストレイク、D.およびC.カウフマン、 "DNSのセキュリティのためのProposed Standard"、RFC 2065、1997年1月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[SDSI] Ron Rivest and Butler Lampson, "SDSI - A Simple Distributed Security Infrastructure [SDSI]", <http://theory.lcs.mit.edu/~cis/sdsi.html>.
[SDSI]ロナルド・リベストとバトラー・ランプソン、 "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]セキュアな電子取引 - 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>。
[SRC-070] Abadi, Burrows, Lampson and Plotkin, "A Calculus for Access Control in Distributed Systems", DEC SRC-070, revised August 28, 1991.
[SRC-070]アバディ、バローズ、LampsonとPlotkin、 "分散システムにおけるアクセス制御のための微積分"、12月SRC-070、1991年8月28日改訂。
[UPKI] C. Ellison, "The nature of a useable PKI", Computer Networks 31 (1999) pp. 823-830.
[UPKI] C.エリソン、 "使用可能なPKIの自然"、コンピュータネットワーク31（1999）頁823から830まで。
[WEBSTER] "Webster's Ninth New Collegiate Dictionary", Merriam-Webster, Inc., 1991.
[WEBSTER] "ウェブスターの第九新大学辞典"、メリアム・ウェブスター社、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、ケルベロス、12月DSSA、[SRC-070]、KeyKOS [ハーディー]）を過剰評価することができません。
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氏、マーク・フェルドマン、ジョン・ギルモア、フィルハラム - ベイカー、ボブJueneman、デビッド・ケンプ、アンゲロスDを。Keromytis、ポール・ランバート、ジョン・ラッサー、ジェフ・パレット、ビルゾンマーフェルト、サイモン・スペロ。
Authors' Addresses
著者のアドレス
Carl M. Ellison Intel Corporation 2111 NE 25th Ave M/S JF3-212 Hillsboro OR 97124-5961 USA
カール・M.エリソンインテルコーポレーション2111 NE 25日アヴェM / S JF3-212ヒルズボロOR 97124から5961 USA
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ファックス：+ 1-503-264-6225 Eメール：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
ビル・フランツ・エレクトリックコミュニティ10101デアンザブルバードクパチーノCA 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レイクビューアベニューケンブリッジMA 02138
Phone: +1 617-547-9580 (voice + FAX) EMail: blampson@microsoft.com
電話：+1 617-547-9580（音声+ FAX）Eメール：blampson@microsoft.com
Ron Rivest Room 324, MIT Laboratory for Computer Science 545 Technology Square Cambridge MA 02139
ロナルド・リベストルーム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ファックス：+ 1-617-258-9738 Eメール：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
ブライアン・トーマス南西ベル一つベルセンター、ルーム34G3セントルイスMO 63101 USA
Phone: +1 314-235-3141 Fax: +1 314-235-0162 EMail: bt0008@sbc.com
電話：+1 314-235-3141ファックス：+1 314-235-0162電子メール：bt0008@sbc.com
Tatu Ylonen SSH Communications Security Ltd. Tekniikantie 12 FIN-02150 ESPOO Finland
タトゥYlonenと、SSHコミュニケーションズ・セキュリティ株式会社Tekniikantie 12 FIN-02150エスポー、フィンランド
EMail: ylo@ssh.fi
メールアドレス：ylo@ssh.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
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機能のための基金は現在、インターネット協会によって提供されます。