[要約] RFC 2693は、SPKI（Simple Public Key Infrastructure）証明書理論に関する情報を提供するものであり、その目的は、セキュリティと信頼性の向上を図るために、SPKI証明書の設計と使用方法に関するガイドラインを提供することです。
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
SPKI証明書理論
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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-Expressionsをこれらの証明書の標準形式として使用し、これらのS発現の標準形式を定義します。この開発の一環として、証明書タイプの混合から認可決定を導き出すメカニズムが開発され、このドキュメントに示されています。
This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses.
このドキュメントは、SPKI証明書とACLSの背後にある理論を、それらの構造やその用途について技術的な詳細を説明することなく提供します。
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が1つありますが、各制御されたリソースに対してはありません。
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.
証明書：主題に力を与える署名済みの機器。少なくとも発行者と主題が含まれています。有効性条件、承認、委任情報を含めることができます。証明書には、id（マッピング<name、key>）、属性（マッピング<authorization、name>）、および承認（マッピング<承認、key>）の3つのカテゴリがあります。SPKI承認または属性証明書は、発行者から受け取ったすべてのエンパワーメントを渡すことができます。または、そのエンパワーメントの一部のみを渡すことができます。
ISSUER: the signer of a certificate and the source of empowerment that the certificate is communicating to the Subject.
発行者：証明書の署名者と、証明書が主題と通信しているというエンパワーメントのソース。
KEYHOLDER: the person or other entity that owns and controls a given private key. This entity is said to be the keyholder of the keypair or just the public key, but control of the private key is assumed in all cases.
キーホルダー：特定の秘密鍵を所有および制御する個人またはその他のエンティティ。このエンティティは、キーペアまたは公開鍵のキーホルダーであると言われていますが、すべての場合に秘密鍵の制御が想定されています。
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.
件名：証明書または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に選択されたデータ形式。これは、空のリストが許可されていないという制限を伴うLISPのような括弧付き式であり、S-Expressionの最初の要素は式の「タイプ」と呼ばれる文字列でなければなりません。
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".
しきい値科目：ACLエントリまたは他の被験者のkを指定する証明書の件名。概念的には、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.
証明書は、もともと1つの関数を持っていると見なされていました。名前をキーまたは名前のキーにバインディングします。この考えは、1976年にDiffieとHellmanが公開キーの暗号化を導入することで論文にまでさかのぼることができます。それ以前は、キー管理はリスクが高く、関与し、費用がかかり、手首に手錠をかけられたブリーフケースを備えた特別な宅配便業者を採用していました。
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]
DiffieとHellmanは、この問題を根本的に解決したと思っていました。「この種のシステムを考えると、重要な分布の問題は非常に簡素化されています。各ユーザーは、彼の端末で逆変換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."
この修正された電話帳、完全に公開されているため、信頼できる宅配便業者に取って代わりました。このディレクトリはオンラインで配置される可能性があるため、世界中で利用可能になります。その見込み客を考慮すると、ロレン・コーンフェルダーは、1978年のMIT [Kohnfelder]の電気工学の学士論文の学士号[Kohnfelder]で次のように述べています。しかし、このような信頼できる機能交換が不可能な場合、次の最良のことは第三者を信頼することです。ディフェとヘルマンは、パブリックファイルとして知られる中央当局を紹介します。」
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の論文の10年後、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.
プライバシー強化されたメール[PEM]インターネットエンジニアリングタスクフォース[RFC1114]の努力は、X.509証明書を採用しましたが、異なる解釈がありました。X.509はもともと「キーホルダーがX.500データベースのこの部分を変更することができる」を意味することを意図していた場合、PEMは証明書を「鍵は指名された人に話す」と意味しました。Access Control Instrumentであったのは、Diffie、Hellman、Kohnfelderが想定している線に沿って、アイデンティティ機器でした。
The insistence on X.509 certificates with a single global root delayed PEM's adoption past its window of viability. RIPEM, by Mark Riordan of MSU, was a version of PEM without X.509 certificates. It was distributed and used by a small community, but fell into disuse. MOSS (a MIME-enhanced version of PEM, produced by TIS (www.tis.com)) made certificate use optional, but received little distribution.
単一のグローバルルートを使用したX.509証明書の主張は、PEMの採用が実行可能性の窓を過ぎて採用を遅らせました。MSUのMark RiordanによるRipemは、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年に、Phil ZimmermannのPGPが異なる証明書モデルで導入されました。単一のグローバルルートとそのルートから降りる証明書当局の階層を待つ代わりに、PGPは複数の（できれば）独立したが、特別に信頼できる個人ではなく、その有効性を証明する<名、キー>協会に署名することを許可しました。理論は、そのような署名が十分にあるため、これらの署名者のすべてが腐敗しているわけではないため、その関連付けは信頼できるということでした。これは「信頼のWeb」モデルとして知られていました。<名前、キー>バインディングに対する信頼を保証する方法で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.
人々を識別するために使用する名前は、通常、ローカルドメイン内で一意ですが、それは世界規模では真実ではありません。特定の名前である誰かがインターネット上の一意の識別子として機能することを知っている名前が非常にありそうもない。名前を考えると、名前で扱われたときに名前付きの人を認識していると感じさせるという社会的機能に役立ち続けますが、Diffie、Hellman、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年代初頭まで、関係は直接形成され、その人に関する知識を獲得したことを想定することができました。そのキーホルダーの適切な識別子である名前が見つかった場合、その名前を使用してキーホルダーに関する記憶にインデックスを付け、関連する決定を下すことができます。
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年代後半には、これはもはや真実ではありません。インターネットの爆発により、物理的な世界で完全に見知らぬ人であり、そのままであるキーホルダーに遭遇する可能性があります。接触はデジタルで行われ、関係の期間中はデジタルのままになります。したがって、最初の出会いでは、識別子によってインデックス化される知識の団体はありません。
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.
一部の人々は、まるで避けられない識別子であるかのようにグローバルなIDについて語り、誰かが1つの名前で悪をするのを防ぎ、彼の名前を変えて、もう一度やり直すことができます。そのシナリオを実現するには、そのような識別子（おそらく政府による、出生時）と何らかのメカニズムを割り当てる必要があります。後者のメカニズムを考えると、特定の個人に証明書を発行することを希望する証明書当局は、おそらくその証明書の同じ、避けられない名前を選択するでしょう。たとえば、グローバルに割り当てられたID番号のデータベースで偽陽性の危険のない人を検索するだけで、その手順では避けられない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は、グローバルに一意である必要はありません。むしろ、そのアドレス帳、電子メールエイリアスファイル、またはアカウントのリストを維持する1つのエンティティにとって、それらはユニークである必要があります。さらに重要なことは、それらをインデックスとして使用する人にとって意味がある必要があることです。
Ron Rivest and Butler Lampson showed with SDSI 1.0 [SDSI] that one can not only use local names locally, one can use local names globally. The clear security advantage and operational simplicity of SDSI names caused us in the SPKI group to adopt SDSI names as part of the SPKI standard.
Ron RivestとButler Lampsonは、SDSI 1.0 [SDSI]でローカル名をローカルで使用できるだけでなく、ローカル名をグローバルに使用できることを示しました。SDSI名の明確なセキュリティの優位性と運用上のシンプルさにより、SPKIグループのSPKI標準の一部としてSDSI名を採用することができました。
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-Expressionです。例えば、
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)
フレッド：（サムという名前）
then george can refer to this same entity as
その後、ジョージはこれと同じエンティティを参照できます
george: (name fred 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.
公開キーの暗号化で使用するためにキーペアを作成すると、秘密鍵は、優れたキー保護慣行によって所有者に縛られます。その秘密鍵が所有者から緩んでいる場合、公開鍵暗号の基本的な前提に違反されており、その鍵はもはや関心がありません。
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つ以上のパブリックキー、したがって対応するキーホルダーにマッピングします。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.
SPKIで保存されているSDSI 1.0コンベンションは、（ローカル）SDSI名が証明書内で発生した場合、発行者の公開鍵がその名前が定義されている名前空間の識別子であることです。
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)
（name（hash sha1 | tlcgplflgtzgubcaylw8kgtenuk = |）Jim Therese）
is a fully qualified SDSI name, using the SHA-1 hash of a public key as the global identifier defining the name space and anchoring this name string.
公開キーのSHA-1ハッシュを、名前空間を定義し、この名前の文字列を固定するグローバル識別子として使用して、完全に適格なSDSI名です。
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>).
（name <root key> <ca（1）> <ca（2）> ... <ca（k）> <leaf name>）。
SPKI/SDSI does not claim to enforce one key per name. Therefore, a named group can be defined by issuing multiple (name,key) certificates with the same name -- one for each group member.
SPKI/SDSIは、名前ごとに1つのキーを実施するとは主張していません。したがって、名前付きグループは、同じ名前の複数の（名前、キー）証明書を発行することで定義できます。これは、グループメンバーごとに1つです。
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名証明書を使用すると、誰かに関連する名前でキーホルダーを識別できます。
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つは認可に関する権限であり、もう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.
この場合、認可と名前の両方について権限でなければならない発行者は1人だけです。
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:
誰かがキーホルダーの名前にアクセスしたい場合、ロギングの目的で、または不正行為後の罰のためにさえ、キーから位置情報（名前、住所、電話など）にマッピングして次のことを行うことができます。
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対応ブラウザのSSLルートキーのリストまたはユーザーのHome UNIXディレクトリのファイル.SSH/Authorized_Keysが含まれます。これらのACLは単一の目的であるため、個々のエントリは明示的な承認を担当しませんが、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.
承認証明書の権限の1つは、関係するリソースの所有者を悩ませることなく、ある人から別の人に承認を委任する機能です。簡単な許可を発行し（たとえば、ファイルを読み取るなど）、その許可をさらに委任する許可を発行する場合があります。
Two issues arose as we considered delegation: the desire to limit depth of delegation and the question of separating delegators from those who can exercise the delegated permission.
委任を検討したときに2つの問題が発生しました。委任の深さを制限したいという願望と、委任者を委任された許可を行使できる人々から分離するという問題です。
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.
ブール制御を支持する議論は、委任できないことを指定する必要があるかもしれないということです。たとえば、米国の商務省が暗号化ソフトウェアモジュールをエクスポート可能に宣言することを許可されているキーを持っていることを想像できます。商務省がこれをさらに委任する許可を発行しないと仮定することは合理的です。つまり、各メーカーと直接的な法的契約を結び、法的合意が実施されていることを反映するためにのみ、そのメーカーに証明書を発行したいと考えています。
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.
整数制御を支持する議論は、委任された許可の急増を制御するために、委任の深さを制限したいと思うかもしれないということです。
Of these three, the group chose boolean control. The subject of a certificate or ACL entry may exercise any permission granted and, if delegation is TRUE, may also delegate that permission or some subset of it to others.
これら3つのうち、グループはブールコントロールを選択しました。証明書またはACLエントリの主題は、許可された許可を行使する場合があり、委任が真実である場合、その許可またはその一部を他のものに委任することもあります。
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.
NOコントロールの引数には論理的な魅力がありますが、ユーザーがそれを貸し出さないのに十分なほど自分の秘密キーを評価するか、キーが他のユーザーにコピーできないハードウェアにロックされるという仮定が残っています。これは、ユーザーがオラクルに署名することを妨げるものではありませんが、ネットワーク接続の欠如はそのメカニズムを阻害する可能性があります。
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.
整数制御オプションは元の設計であり、魅力的でしたが、適切な委任の深さを予測できないことで敗北しました。一時的な署名キーを作成することにより、いつでももう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.
承認証明書の定義に関する懸念の1つは、関数が従来の<承認、名前> acls、<name、key> 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.
インターネットから米国のDODマシンのネットワークにTelnetとFTPアクセスを許可するファイアウォールプロキシを想像してください。その宛先ネットワークの感度のため、強力なアクセス制御が望まれます。公開キー認証と公開キー証明書を使用して、個々のキーホルダーが誰であるかを確立できます。秘密鍵とキーホルダーの証明書の両方をFortezzaカードに保管できます。そのカードには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はおそらく独自のACLの1つのレベルではなく、最終的に国防総省全体の組織構造を反映する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.
ACLSがなければ、ファイアウォールは大量貯蔵のないデバイスに実装でき、シールされたユニットに住むことができます。ACLSを使用すると、アクセス制御の決定を下すだけでなく、ACLSを更新するためにもアクセスする大きな大量貯蔵装置が必要です。
By contrast, let the access be controlled by authorization certificates. The firewall would have an ACL with one entry, granting a key belonging to the Secretary of Defense the right to delegate all access through the firewall. The Secretary would, in turn, issue certificates delegating this permission to delegate to each of his or her subordinates. This process would iterate, until some enlisted man would receive permission to penetrate that firewall for some specific one protocol, but not have permission to delegate that permission.
対照的に、認証証明書によってアクセスを制御します。ファイアウォールには、1つのエントリを備えたACLがあり、国防長官に属する鍵を許可し、ファイアウォールを通じてすべてのアクセスを委任する権利を認めます。秘書は、この許可を委任する証明書を発行し、各部下に委任する。入隊した男性が特定の1つのプロトコルのためにそのファイアウォールに侵入する許可を受けますが、その許可を委任する許可がないまで、このプロセスは反復します。
The certificate structure generated would reflect the organization structure of the entire Defense Department, just as the nested ACLs would have, but the control of these certificates (via their issuance and revocation) is distributed and need not show up in that one firewall or be replicated in all firewalls. Each individual delegator of permission performs a simple task, well understood. The application software to allow that delegation is correspondingly simple.
生成された証明書構造は、ネストされたACLSが持つように、国防総省全体の組織構造を反映していますが、これらの証明書の制御（発行と失効を介して）が分散されており、その1つのファイアウォールに表示されるか、複製する必要はありません。すべてのファイアウォールで。許可の個々の委任者は、よく理解されている簡単なタスクを実行します。その代表団を許可するアプリケーションソフトウェアは、それに対応して簡単です。
A certificate, or an ACL entry, has optional validity conditions. The traditional ones are validity dates: not-before and not-after. The SPKI group resolved, in discussion, that on-line tests of various kinds are also validity conditions. That is, they further refine the valid date range of a certificate. Three kinds of on-line tests are envisioned: CRL, re-validation and one-time.
証明書、またはACLエントリには、オプションの有効条件があります。伝統的なものは有効期限です。SPKIグループは、議論で、さまざまな種類のオンラインテストも妥当性条件であると解決しました。つまり、証明書の有効な日付範囲をさらに洗練します。3種類のオンラインテストが想定されています：CRL、再検証、および1回限り。
When validity confirmation is provided by some online test, then the issuer of those refinements need not be the issuer of the original certificate. In many cases, the business or security model for the two issuers is different. However, in SPKI, the certificate issuer must specify the issuer of validity confirmations.
有効性の確認がいくつかのオンラインテストによって提供される場合、それらの改良の発行者は元の証明書の発行者である必要はありません。多くの場合、2つの発行者のビジネスまたはセキュリティモデルは異なります。ただし、SPKIでは、証明書発行者は有効性確認の発行者を指定する必要があります。
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 [証明書の取り消しリスト]の初期の形式は、スーパーマーケットのチェックアウトスタンドに保管されていたニュースプリントブックをモデルにしました。これらの本には、口座数の悪いチェック番号と、後に悪いクレジットカード番号のリストがありました。本に支払い手段がリストされていなかった場合、その楽器は良いと見なされました。
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設計がこのモデルに従いました。取り消された証明書識別子のリストがありました。また、シーケンス番号があったため、2つのCRLのどれがより最近かを知ることができました。新しい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プロセスは3つの条件の対象となります。
1. The certificate must list the key (or its hash) that will sign the CRL and may give one or more locations where that CRL might be fetched.
1. 証明書には、CRLに署名するキー（またはそのハッシュ）をリストし、そのCRLがフェッチされる可能性のある1つ以上の場所を提供する場合があります。
2. The CRL must carry validity dates.
2. CRLは有効性の日付を保持する必要があります。
3. CRL validity date ranges must not intersect. That is, one may not issue a new CRL to take effect before the expiration of the CRL currently deployed.
3. CRLの妥当性の範囲は交差してはなりません。つまり、現在展開されているCRLの有効期限の前に有効になるために新しいCRLを発行することはできません。
Under these rules, no certificate that might use a CRL can be processed without a valid CRL and no CRL can be issued to show up as a surprise at the verifier. This yields a deterministic validity computation, independent of clock skew, although clock inaccuracies in the verifier may produce a result not desired by the issuer. The CRL in this case is a completion of the certificate, rather than a message to the world announcing a change of mind.
これらの規則では、CRLを使用する可能性のある証明書を有効なCRLなしで処理することはできず、検証者に驚きとして表示するCRLを発行することはできません。これにより、クロックスキューとは無関係に決定論的妥当性計算が得られますが、検証者のクロックの不正確さは発行者が望まない結果を生成する可能性があります。この場合のCRLは、心の変化を発表する世界へのメッセージではなく、証明書の完成です。
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は非常に大きくなり、単調に成長する傾向があるため、CRLSではなくCRLに変更を発行したい場合があります。つまり、CRLは完全なCRLであり、その後のDelta-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人の消費者に送信されたばかりで、タイムスロットをロックしていると仮定する必要があります。この妥当性間隔が終了した後、スロットが開始されるときに次に利用できるようになります。それは、虚偽であることを学ぶ証明書を取り消すことができる最も早い人です。
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が検証剤に受信されるまでに、それは時代遅れで使用できません。それは完全な時計の同期を想定しています。Clock Skewが考慮される場合、有意義な妥当性間隔はそれほど大きくなる必要があります。
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.
短命の証明書を発行したい場合、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].
Silvio Micaliは、ハッシュチェーンを使用して証明書を修正または取り消すためのメカニズムを特許を取得しています。このメカニズムは、これらのモデルのパフォーマンス要件を変更するため、パフォーマンス分析[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.
Ron Rivestは、発行者（またはこの責任を委任するエンティティ）が証明書が有効な条件を決定すると仮定しているため、妥当性条件モデル全体に欠陥があることを示唆する論文[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証明書のセマンティクスを明確にすることと、認証結果を得るためにITおよびその他のさまざまな種類の証明書を使用する方法を明確にすることです。
There are three kinds of entity that might be input to the computation that yields an authorization result:
承認結果をもたらす計算に入力される可能性のあるエンティティには3種類あります。
1. <name,key> (as a certificate)
1. <名前、key>（証明書として）
2. <authorization,name> (as an attribute certificate or ACL entry)
2. <承認、name>（属性証明書またはACLエントリとして）
3. <authorization,key> (as an authorization certificate or ACL entry)
3. <承認、key>（承認証明書または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).
SPKIまたはSDSI証明書のもう1つの作業には、オンラインテスト結果（CRL、再検証または1回限りの検証）の処理が含まれる場合があります。
The other work for PGP certificates may include a web-of-trust computation.
PGP証明書の他の作業には、Web-of-Trust計算が含まれる場合があります。
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証明書を使用するものもあります。他の人はX.509を使用して、承認を暗黙的に通知します（例：SSLサーバー証明書）。X.509の拡張機能を定義して、明示的な承認を実施する人もいます。これらの解釈はすべて、証明書チェーンに関連する書かれたドキュメントで指定されているため、チェーンが下降するルートに記載されています。
If on-line tests are involved in the certificate processing, then the validity dates of those on-line test results are intersected by VIntersect() [defined in 6.3.2, below] with the validity dates of the certificate to yield the dates in the certificate's tuple(s).
オンラインテストが証明書の処理に関与している場合、それらのオンラインテスト結果の有効性は、Vintersect（）[下の6.3.2で定義]と交差しています。証明書のタプル。
2. Uses of names are replaced with simple definitions (keys or hashes), based on the name definitions available from reducing name 4-tuples.
2. 名前の名前の削減から利用可能な名前の定義に基づいて、名前の使用は単純な定義（キーまたはハッシュ）に置き換えられます。
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. 委任：ブール。真実の場合、被験者は発行者によってこの中間結果の許可をさらに伝播することを許可されます。
4. Authorization: an S-expression. [Rules for combination of Authorizations are given below.]
4. 承認：S-Expression。[承認の組み合わせのルールを以下に示します。]
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.
A <name、key>証明書（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. 発行者：公開キー（またはそのハッシュ）。これにより、この名前を称賛されるエンティティが識別されます。
2. Name: a byte string
2. 名前：バイト文字列
3. Subject: a public key (or its hash), a name, or a threshold function of subordinate subjects. This defines the name.
3. 件名：公開鍵（またはそのハッシュ）、名前、または下位被験者のしきい値関数。これは名前を定義します。
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>
yield
収率収量生じる利回り生み出す産出出来高譲る屈する上がり収穫物生産高上がり高産する供する同ずる同じる
<I1,S2,D2,AIntersect(A1,A2),VIntersect(V1,V2)>
provided
提供されたという条件で
the two intersections succeed,
2つの交差点が成功します、
S1 = I2
and
そしてと及びアンド並びに且つ兼又共それですると亦だからそれからはたまた
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.
承認は、この承認をアクセス制御に使用するアプリケーションの意味の文字列またはサブリストのリストであり、おそらく定義されています。2つの承認は、一致することによって交差します。要素の要素。1つのリストが他のリストよりも長いが、両方のリストに要素があるすべての要素と一致する場合、長いリストは交差の結果です。これは、リストの追加要素が許可された許可を制限する必要があることを意味します。
Although actual authorization string definitions are application dependent, AIntersect provides rules for automatic intersection of these strings so that application developers can know the semantics of the strings they use. Special semantics would require special reduction software.
実際の承認文字列の定義はアプリケーションに依存しますが、Ainterectは、アプリケーション開発者が使用する文字列のセマンティクスを知ることができるように、これらの文字列の自動交差点のルールを提供します。特別なセマンティクスには、特別な削減ソフトウェアが必要です。
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（host 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（host ftp.clark.net）（dir /pub /cme））
which would allow all kinds of access but only in the directory specified. The intersection of the two would be the second.
これにより、あらゆる種類のアクセスが可能になりますが、指定されたディレクトリのみが可能になります。2つの交差点が2番目になります。
Since the AIntersect rules imply position dependency, one could also define the previous authorization string as:
Aintersectルールは位置の依存性を意味するため、以前の承認文字列を次のように定義することもできます。
(ftp ftp.clark.net /pub/cme)
（ftp ftp.clark.net /pub /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-ExpressionsとByte-Stringsのセットを表します。言い換えれば、それは何でも一致します。何かと交差すると、結果は他のことです。[異なる長さのリストに関するAinterectルールは、リストを扱い、それが交差している別のリストの長さと一致するように暗黙的に追加された十分な（*）エントリがあるかのように扱います。]
(* set <tag-expr>*) stands for the set of elements listed in the *-form.
（*set <tag-expr>*）は、*-formにリストされている一連の要素を表します。
(* prefix <byte-string>) stands for the set of all byte strings that start with the one given in the *-form.
（ *プレフィックス<byte-string>）は、 * -formで与えられたものから始まるすべてのバイト文字列のセットを表します。
(* range <ordering> <lower-limit>? <upper-limit>?) stands for the set of all byte strings lexically (or numerically) between the two limits. The ordering parameter (alpha, numeric, time, binary, date) specifies the kind of strings allowed.
（* range <-ordering> <lower-limit>？<supper-limit>？）は、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（（tag（ftp ftp.clark.net cme（* set read write））、（tag（*））））
evaluates to (tag (ftp ftp.clark.net cme (* set read write)))
（tag（ftp ftp.clark.net cme（* set read write））に
AIntersect( (tag (* set read write (foo bla) delete)), (tag (* set write read) ) )
aintersect（tag（* set read write（foo bla）delete））、（tag（* set write read））））
evaluates to (tag (* set read write))
（tag（* set read write））を評価する
AIntersect( (tag (* set read write (foo bla) delete)), (tag read ) )
aintersect（tag（* set read write（foo bla）delete））、（tag read））
evaluates to (tag read)
（タグ読み取り）に評価する
AIntersect( (tag (* prefix http://www.clark.net/pub/)),
(tag (* prefix 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#) )
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 = min（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.
これらのルールは、日1回はSPKIにあるように、単調な形で表現されると想定しています。
The full SPKI VIntersect() also deals with online tests. In the most straight-forward implementation, each online test to which a certificate is subject is evaluated. Each such test carries with it a validity interval, in terms of dates. That validity interval is intersected with any present in the certificate, to yield a new, current validity interval.
完全なSPKI Vintersect（）もオンラインテストを扱います。最も簡単な実装では、証明書が対象となる各オンラインテストが評価されます。このような各テストは、日付の観点から有効性間隔を伴います。その妥当性間隔は、証明書に存在する任意の存在と交差しており、新しい現在の妥当性間隔を生成します。
It is possible for an implementation of VIntersect() to gather up online tests that are present in each certificate and include the union of all those tests in the accumulating tuples. In this case, the evaluation of those online tests is deferred until the end of the process. This might be appropriate if the tuple reduction is being performed not for answering an immediate authorization question but rather for generation of a summary certificate (Certificate Result Certificate) that one might hope would be useful for a long time.
Vintersect（）の実装は、各証明書に存在するオンラインテストを収集し、蓄積されるタプルのすべてのテストの結合を含めることができます。この場合、これらのオンラインテストの評価は、プロセスの終了まで延期されます。これは、即時の許可の質問に答えるためではなく、長い間有用であることを期待する要約証明書（証明書結果証明書）の生成のためにタプル削減が実行されている場合に適切かもしれません。
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下位の被験者の2つの数値によって指定されます。しきい値被験者は、n被験者のkを選択し、それらの各Kを同じ被験者に縮小して、証明書のシーケンスを介して削減することにより、単一の被験者に削減されます。（n-k）選択されていない下位被験者は（null）に設定されます。
The intermediate form for a threshold subject is a copy of the tuple in which the threshold subject appears, but with only one of the subordinate subjects. Those subordinate tuples are reduced individually until the list of subordinate tuples has (N-K) (null) entries and K entries with the same subject. At that point, those K tuples are validity-, authorization- and delegation- intersected to yield the single tuple that will replace the list of tuples.
しきい値科目の中間形式は、しきい値の主題が現れるタプルのコピーですが、下位の主題の1つだけです。これらの下位のタプルは、下位のタプルのリストが（n-k）（null）エントリと同じ主題を持つKエントリを持つまで個別に削減されます。その時点で、これらのKタプルは、タプルのリストを置き換える単一のタプルを生成するために、妥当性、承認、および委任 - 委任です。
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.
すべての削減操作は、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つの異なるクラスには、名前をキーとして定義するクラスと、名前を別の名前として定義する名前の名前があります。
1. [(name K1 N) -> K2]
2. [(name K1 N) -> (name K2 N1 N2 ... Nk)]
As with the 5-tuples discussed in the previous section, name definition 4-tuples should be delivered in the order needed by the prover. In that case, the rule for name reduction is to replace the name just defined by its definition. For example,
前のセクションで説明した5つのタプルと同様に、名前の定義4タプルは、得点者が必要とする順序で配信する必要があります。その場合、名前削減のルールは、その定義によって定義された名前を置き換えることです。例えば、
(name K1 N N1 N2 N3) + [(name 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)]
-> (name K2 N1 N2 ... Nk Na Nb Nc)
- >（名前k2 n1 n2 ... nk na nb nc）
With the second form of name definition, one might have names that temporarily grow. If the prover is providing certificates in order, then the verifier need only do as it is told.
名前定義の2番目の形式では、一時的に成長する名前がある場合があります。Proverが順番に証明書を提供している場合、検証者は指摘されたとおりにのみ行う必要があります。
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タプルのみを適用することです。このようなアプリケーションは、クラス（2）で始まった4タプルをクラス（1）に持ち込み、最終的にすべての名前をキーに削減する必要があります。命名ループはこのプロセスによって回避されます。
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].
しきい値被験者の個々の指定された被験者を削減し、必要がある場合は被験者をしきい値形式にしておくことができます。関係する委任または認可の相互作用はありません。名前の削減中の妥当性の相互作用のみがあります。これは、証明書結果証明書を生成するサービスによって使用される場合があります[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証明書は、<name、key> certifatisです。タプルという名前に直接翻訳します。フォーム
[Kroot, (name <leaf-name>), K1, validity]
[kroot、（name <leaf-name>）、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にのみ適用される場合、生成する必要があります
[Kroot, (name CA1 CA2 ... CAk <leaf-name>), K1, validity]
[kroot、（name ca1 ca2 ... cak <leaf-name>）、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証明書は、<name、key>証明書です。これは、TrustルールのWebによって検証されています（PGPドキュメントで指定されています）。検証されると、フォームの名前のタプルが生成されます
[Ki, name, K1, validity]
[ki、name、k1、妥当性]
where Ki is a key that signed that PGP (UserID,key) pair. There would be one tuple produced for each signature on the key, K1.
ここで、KiはそのPGP（userID、key）ペアに署名したキーです。キーの署名ごとに1つのタプルが生成されます。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証明書を使用して、名前を宣言できます。また、拡張機能を介して、明示的な承認を宣言する場合があります。また、フォーム（タグ（*））の暗黙の承認を宣言する場合があります。それが生成する実際のタプルのセットは、その証明書に関連するドキュメントに依存します。そのドキュメントは、証明書チェーンのルートキーに概念的に関連付けられていると見なすことができます。さらに、一部の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属性証明書は、名前を件名として1つ以上の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:
暗黙的です。さらに、サーバー証明書には、接続が行われているWebページのDNS名と一致するDNS名パラメーターを搭載しています。それは次のようにエンコードされる可能性があります：
(tag (dns <domain-name>))
（tag（dns <domain-name>））
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))
（タグ（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 (*))))
（tag（* set（ssl）（dns（*））））
which by the rules of intersection is equivalent to:
交差点のルールでは、次のものと同等です。
(tag (* set (ssl) (dns)))
（tag（* set（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)))
（tag（* set（ssl）（dns）（us-crypto）））
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)))
（tag（* set（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を実行し、指定されたドメイン名から動作することが権限を与えられていることを示していますが、米国のブラウザでUS Cryptoを使用しないことを示しています。
The use of (* set) for the two attributes in this example could have been abbreviated as:
この例の2つの属性に（* set）の使用は、次のように省略されている可能性があります。
(tag (ssl www.datafellows.com))
（タグ（SSL www.datafellows.com））
while CA certificates might carry:
CA証明書は運ばれるかもしれませんが、
(tag (ssl (*))) or just (tag (*))
（タグ（ssl（*）））またはjust（tag（*））
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.
しかし、それらを（* set）経由で分離することで、（SSL）許可が1つのルートキー（現在のCAS）のセット（DNS）の許可が別のセットのセットから導き出される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種類の許可は、ANDEDが許可を解釈し、証明書で表現されていないコードのロジックから派生しているかのように扱われるという事実です。その決定は、検証アプリケーションによって実行された承認コードで具体化されます。
Typically, one will reduce a chain of certificates to answer an authorization question in one of two forms:
通常、2つのフォームのいずれかで認可の質問に答えるために、証明書のチェーンを削減します。
1. Is this Subject, S, allowed to do A, under this ACL and with this set of certificates?
1. この主題は、このACLの下で、この一連の証明書を使用することを許可されていますか？
2. What is Subject S allowed to do, under this ACL and with this set of certificates?
2. この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.
暗号化キーの寿命は限られています。キーを盗むことができます。キーは、暗号化によっても発見される場合があります。盗難に気付いた場合、キーはクレジットカードを交換するため、キーを交換できます。おそらく、盗難は気づかないでしょう。このケースをカバーするために、キーは定期的に交換されます。
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の下では、鍵を悪いと宣言するのではなく、むしろそれに力を与えるのを止め、代わりに他の鍵に力を与えます。証明書の寿命のこの制限は、発行時の寿命が限られている可能性があるか、オンラインテスト（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を参照]、それらをそれらの名前で参照し、避けられない名前から人の現在のキーにマッピングする証明書を定義することができます。すべてのCASがキーホルダーに避けられない名前を使用するため、その証明書は任意のCAによって発行される可能性があります。キーホルダーを参照する属性証明書とACLはすべて、この避けられない名前を参照します。
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.
主要な管理を目的として、厳密にはキーホルダーに自発的に名前を発行する政府の機関または他のエンティティを持つことができます。その後、その名前を介してすべての承認を受け取ります。ただし、そのような権限は1つだけでなければなりません。それ以外の場合、名前は部分で構成されている必要があります。権威名と個人の名前。当局名は、単一のグローバルな権限によって認められなければなりません。
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.
避けられない名前や単一ルートの命名当局の代わりに、<name、key>証明書を発行するエンティティによって割り当てられた名前があります。上記のセクション2.8および2.9で述べたように、そのような名前はそれ自体で意味がありません。彼らは意味を持つために完全に資格がなければなりません。
Therefore, in the construct:
したがって、構成要素：
(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim)
（name（hash sha1 | tlcgplflgtzgubcaylw8kgtenuk = |）jim）
the name is not
名前はそうではありません
"jim"
「ジム」
but rather
むしろ
"(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim)"
"（name（hash sha1 | tlcgplflgtzgubcaylw8kgenuk = |）jim）"
This name includes a public key (through its hash, in the example above). That key has a lifetime like any other key, so this name has not achieved the kind of permanence (free from key lifetimes) that an inescapable name has. However, it appears to be our only alternative.
この名前には、公開鍵が含まれています（上記の例では、ハッシュを介して）。その鍵は他のキーと同様に生涯を持っているため、この名前は、避けられない名前が持つような永続性（キーの寿命がない）を達成していません。しかし、それは私たちの唯一の代替手段のようです。
This name could easily be issued by the named keyholder, for the purpose of key management only. In that case, there is no concern about access control being subverted by some third-party naming authority.
この名前は、キー管理のみを目的として、指名されたキーホルダーによって簡単に発行される可能性があります。その場合、サードパーティの命名当局によって覆われているアクセス制御に関する懸念はありません。
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つだけであると仮定しましょう。
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つしかない場合、名前を分配することができます。承認は、そのキーの下で定義されている名前ではなく、生のSPKIスタイルでキー自体に割り当てることができます。寿命の損失はありません - 認定キーが当局に委任するために使用する証明書の主題の変更のみです。
However, there is one significant difference, under the SPKI structure. If one delegates some authorization to
ただし、SPKI構造の下には、1つの大きな違いがあります。何らかの承認を委任する場合
(name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) carl)
（name（hash sha1 | tlcgplflgtzgubcaylw8kgtenuk = |）carl）
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.
直接、両方とも委任の許可を与えずに、そのキーは前者のケースの<name、key>証明書を介して自由に委任することができ、後者の場合はまったく委任しません。
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.
主要な管理の場合、私たちは、長生きされためったに使用されない鍵から委任する能力を望んでいます。
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.
上記のモデルのいずれかで、key | tlcgplflgtzgubcaylw8kgenuk = |証明書が発行されます。最初のモデルでは、<name、key>証明書になります。第二に、それはすべての権利をより一時的なキーに委任する認可証明書になります。
Either of those certificates might want an on-line validity test. Whether this test is in the form of a CRL, a re-validation or a one-time test, it will be supplied by some entity that is on-line.
これらの証明書のいずれかは、オンライン有効性テストを必要とする場合があります。このテストがCRL、再検証、または1回限りのテストの形であるかどうかにかかわらず、オンラインの一部のエンティティから提供されます。
As the world moves to having all machines on-line all the time, this might be the user's machine. However, until then -- and maybe even after then -- the user might want to hire some service to perform this function. That service could run a 24x7 manned desk, to receive phone calls reporting loss of a key. That authority would not have the power to generate a new key for the user, only to revoke a current one.
世界が常にオンラインですべてのマシンを置くことに移行するにつれて、これがユーザーのマシンかもしれません。しかし、それまでは、そしてそれ以降でさえ、ユーザーはこの機能を実行するためにサービスを雇いたいと思うかもしれません。そのサービスは、キーの損失を報告する電話を受けるために、24時間365日の有人机を実行できます。その権限には、ユーザーに新しいキーを生成する力はなく、現在のキーを取り消すだけです。
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-EDIT））
Assume also that what might have been a single root authorization key, K1, is actually a threshold subject
また、単一のルート認証キーである可能性があるものは、実際にはしきい値の主題であると仮定します
(k-of-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-EDIT）エントリの主題を持つことができます
(k-of-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つのクラスには、キー、名前、承認があります。したがって、証明書がどのようなアイテムを結びつけるかに応じて、3種類の一般的な証明書があります。アイテム間のマッピングの方向を考慮した場合、name-> key、key-> name、authorization-> name、name-> authorization-> key、key-> authorizationの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)
（承認 - >キー）
or one can use an attribute certificate and an ID certificate:
または、属性証明書とID証明書を使用できます。
(authorization->name) + (name->key)
There are at least two ways in which the former is more secure than the latter.
前者が後者よりも安全な方法は少なくとも2つあります。
1. Each certificate has an issuer. If that issuer is subverted, then the attacker can gain access. In the former case, there is only one issuer to trust. In the latter case, there are two.
1. 各証明書には発行者がいます。その発行者が破壊された場合、攻撃者はアクセスできます。前者の場合、信頼する発行者は1人だけです。後者の場合、2つあります。
2. In the second case, linkage between the certificates is by name. If the name space of the issuer of the ID certificate is different from the name space of the issuer of the attribute certificate, then one of the two issuers must use a foreign name space. The process of choosing the appropriate name from a foreign name space is more complex than string matching and might even involve a human guess. It is subject to mistakes. Such a mistake can be made by accident or be guided by an attacker.
2. 2番目のケースでは、証明書間のリンクは名前によるものです。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.
これは、2番目のコンストラクトを使用してはならないということではありません。2つの証明書が同じ発行者から来ているため、同じ名前のスペースがある場合、上記の両方のセキュリティ差別化要因がキャンセルされます。
References
参考文献
[Ab97] Abadi, Martin, "On SDSI's Linked Local Name Spaces", Proceedings of the 10th IEEE Computer Security Foundations Workshop (June 1997).
[AB97] Abadi、Martin、「SDSIのリンクされたローカル名スペースについて」、第10 IEEEコンピューターセキュリティファンデーションワークショップ（1997年6月）の議事録。
[BFL] Matt Blaze, Joan Feigenbaum and Jack Lacy, "Distributed Trust Management", Proceedings 1996 IEEE Symposium on Security and Privacy.
[BFL] Matt Blaze、Joan Feigenbaum、およびJack Lacy、「Trust Management」、Proceedings 1996 IEEE Symposium on Security and Privacy。
[CHAUM] D. Chaum, "Blind Signatures for Untraceable Payments", Advances in Cryptology -- CRYPTO '82, 1983.
[Chaum] D. Chaum、「追跡不可能な支払いのための盲目の署名」、暗号学の進歩-Crypto '82、1983。
[DH] Whitfield Diffie and Martin Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, November 1976, pp. 644-654.
[DH] Whitfield DiffieとMartin Hellman、「暗号化の新しい方向性」、IEEE情報に関するトランザクション、1976年11月、pp。644-654。
[DvH] J. B. Dennis and E. C. Van Horn, "Programming Semantics for Multiprogrammed Computations", Communications of the ACM 9(3), March 1966.
[DVH] J. B. DennisおよびE. C. Van Horn、「マルチプログラム計算のためのプログラミングセマンティクス」、ACM 9（3）の通信、1966年3月。
[ECR] Silvio Micali, "Efficient Certificate Revocation", manuscript, MIT LCS.
[ECR] Silvio Micali、「効率的な証明書の取り消し」、原稿、MIT LCS。
[ELIEN] Jean-Emile Elien, "Certificate Discovery Using SPKI/SDSI 2.0 Certificates", Masters Thesis, MIT LCS, May 1998, <http://theory.lcs.mit.edu/~cis/theses/elien-masters.ps> [also .pdf and
[Elien] Jean-Emile Elien、「SPKI/SDSI 2.0証明書を使用した証明書発見」、Masters Thesis、MIT LCS、1998年5月、<http://theory.lcs.mit.edu/~cis/theses/elien-masters。ps> [.pdf and
[HARDY] Hardy, Norman, "THE KeyKOS Architecture", Operating Systems Review, v.19 n.4, October 1985. pp 8-25.
[ハーディ]ハーディ、ノーマン、「keykosアーキテクチャ」、オペレーティングシステムレビュー、v.19 n.4、1985年10月。
[IDENT] Carl Ellison, "Establishing Identity Without Certification Authorities", USENIX Security Symposium, July 1996.
[識別] Carl Ellison、「認証当局なしでのアイデンティティの確立」、Usenix Security Symposium、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] McConnellとAppel、「グローバル情報インフラストラクチャにおけるプライバシー、商業、セキュリティ、公共安全の有効化」、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、alan、et al。、「keykos（r）nanokernelアーキテクチャ」、マイクロカーネルおよびその他のカーネルアーキテクチャに関するUsenixワークショップの議事録、Usenix Association、1992年4月。ネット上の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、Loren M.、「実用的な公開暗号システムに向けて」、MIT S.B.論文、5月。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。Abadi、M。Burrows、およびE. Wobber、「分散システムの認証：理論と実践」、ACM Trans。Computer Systems 10、4（1992年11月）、pp 265-310。
[LANDAU] Landau, Charles, "Security in a Secure Capability-Based System", Operating Systems Review, Oct 1989 pp 2-4.
[Landau] Landau、Charles、「安全な機能ベースのシステムにおけるセキュリティ」、オペレーティングシステムレビュー、1989年10月pp 2-4。
[LEVY] Henry M. Levy, "Capability-Based Computer Systems", Digital Press, 12 Crosby Dr., Bedford MA 01730, 1984.
[levy]ヘンリーM.レビー、「能力ベースのコンピューターシステム」、デジタルプレス、12クロスビー博士、ベッドフォードMA 01730、1984。
[LINDEN] T. A. Linden, "Operating System Structures to Support Security and Reliable Software", Computing Surveys 8(4), December 1976.
[Linden] T. A. Linden、「セキュリティと信頼できるソフトウェアをサポートするオペレーティングシステム構造」、コンピューティング調査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、Inc.、1991年6月3日、バージョン1.4。
[PKLOGIN] David Kemp, "The Public Key Login Protocol", Work in Progress.
[Pklogin] David Kemp、「公開キーログインプロトコル」、進行中の作業。
[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.du/~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] Kent、S。およびJ. Linn、「インターネット電子メールのプライバシー強化：パート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] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年12月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 1996.
[RFC2046] Freed、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. Moore、「Mime（多目的インターネットメールエクステンション）パート3：ASCII以外のテキスト用のメッセージヘッダー拡張機能」、RFC 2047、1996年12月。
[RFC2065] Eastlake, D. and C. Kaufman, "Proposed Standard for DNS Security", RFC 2065, January 1997.
[RFC2065] Eastlake、D。およびC. Kaufman、「DNSセキュリティの基準提案」、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.、Bellare、M。、およびR. CaNetti、「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] Ron Rivest and Butler Lampson、「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/>.
[セット]安全な電子トランザクション - すべての参加者をカバーする証明書構造を含む、Visa、MasterCardなどによって設計されたプロトコル。<http://www.visa.com/>を参照してください。
[SEXP] Ron Rivest, code and description of S-expressions, <http://theory.lcs.mit.edu/~rivest/sexp.html>.
[sexp] ron rivest、s-expressionsのコードと説明、<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] Abadi、Burrows、Lampson、およびPlotkin、「分散システムでのアクセス制御のための計算」、DEC SRC-070、1991年8月28日改訂。
[UPKI] C. Ellison, "The nature of a useable PKI", Computer Networks 31 (1999) pp. 823-830.
[Upki] C. Ellison、「使用可能なPKIの性質」、Computer Networks 31（1999）pp。823-830。
[WEBSTER] "Webster's Ninth New Collegiate Dictionary", Merriam-Webster, Inc., 1991.
[Webster]「Webster's Ninth New Collegiate Dictionary」、Merriam-Webster、Inc.、1991。
Acknowledgments
謝辞
Several independent contributions, published elsewhere on the net or in print, worked in synergy with our effort. Especially important to our work were: [SDSI], [BFL] and [RFC2065]. The inspiration we received from the notion of CAPABILITY in its various forms (SDS-940, Kerberos, DEC DSSA, [SRC-070], KeyKOS [HARDY]) can not be over-rated.
ネット上または印刷物で他の場所で公開されているいくつかの独立した貢献は、私たちの努力と相乗効果をもたらしました。私たちの仕事にとって特に重要なのは、[SDSI]、[BFL]、[RFC2065]でした。さまざまな形式での能力の概念から受けたインスピレーション（SDS-940、Kerberos、DEC DSSA、[SRC-070]、Keykos [Hardy]）は過大評価できません。
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メーリングリストのメンバー、特に以下の人物（アルファベット順にリストされている）によるこの取り組みへの重要な貢献は、Steve Bellovin、Mark Feldman、John Gilmore、Phill Hallam-Baker、Bob Jueneman、David Kemp、Angelos D。ケロミティ、ポール・ランバート、ジョン・ラッサー、ジェフ・パレット、ビル・ソマーフェルド、サイモン・スペロ。
Authors' Addresses
著者のアドレス
Carl M. Ellison Intel Corporation 2111 NE 25th Ave M/S JF3-212 Hillsboro OR 97124-5961 USA
Carl M. Ellison Intel Corporation 2111 NE 25th Ave M/S JF3-212ヒルズボロまたは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
Bill Frantz Electric Communities 10101 De Anza Blvd. Cupertino CA 95014
Bill Frantz Electric Communities 10101 de Anza Blvd.Cupertino CA 95014
Phone: +1 408-342-9576
EMail: 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 Ron Rivest Room 324, MIT Laboratory for Computer Science 545 Technology Square Cambridge MA 02139
電話：1 617-547-9580（音声ファックス）メール：blampson@microsoft.com Ron Rivest Room 324、MIT Laboratory for Computer Science 545 Technology Square Cambridge 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
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
Tatu Ylonen SSH Communications Security Ltd. Tekniikantie 12 FIN-02150 ESPOO Finland
Tatu Ylonen SSH Communications Security Ltd. Tekniikantie 12 Fin-02150 Espoo Finland
EMail: ylo@ssh.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。