RFC2704 日本語訳
2704 The KeyNote Trust-Management System Version 2. M. Blaze, J.Feigenbaum, J. Ioannidis, A. Keromytis. September 1999. (Format: TXT=79998 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Blaze
Request for Comments: 2704 J. Feigenbaum
Category: Informational J. Ioannidis
AT&T Labs - Research
A. Keromytis
U. of Pennsylvania
September 1999
コメントを求めるワーキンググループM.炎の要求をネットワークでつないでください: 2704年のJ.ファイゲンバウムカテゴリ: 情報のJ.Ioannidis AT&T研究室--1999年9月にペンシルバニアのA.Keromytis U.について研究してください。
The KeyNote Trust-Management System Version 2
基調信頼管理システムバージョン2
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This memo describes version 2 of the KeyNote trust-management system. It specifies the syntax and semantics of KeyNote `assertions', describes `action attribute' processing, and outlines the application architecture into which a KeyNote implementation can be fit. The KeyNote architecture and language are useful as building blocks for the trust management aspects of a variety of Internet protocols and services.
このメモはKeyNote信頼マネージメントシステムのバージョン2について説明します。 それは、KeyNote'主張'の構文と意味論を指定して、'動作属性'処理について説明して、KeyNote実装に合うことができるアプリケーションアーキテクチャについて概説します。 KeyNoteアーキテクチャと言語はさまざまなインターネットプロトコルとサービスの信頼管理局面へのブロックとして役に立ちます。
1. Introduction
1. 序論
Trust management, introduced in the PolicyMaker system [BFL96], is a unified approach to specifying and interpreting security policies, credentials, and relationships; it allows direct authorization of security-critical actions. A trust-management system provides standard, general-purpose mechanisms for specifying application security policies and credentials. Trust-management credentials describe a specific delegation of trust and subsume the role of public key certificates; unlike traditional certificates, which bind keys to names, credentials can bind keys directly to the authorization to perform specific tasks.
PolicyMakerシステム[BFL96]で導入された信頼管理は安全保障政策、資格証明書、および関係を指定して、解釈することへの統一されたアプローチです。 それはセキュリティ重要な動作のダイレクト承認を許容します。 信頼マネージメントシステムはアプリケーション安全保障政策と資格証明書を指定するのに標準の、そして、汎用のメカニズムを提供します。 信頼管理資格証明書は、信頼の特定の委譲について説明して、公開鍵証明書の役割を包括します。 伝統的な証明書と異なって、資格証明書は、特定のタスクを実行するために直接承認のキーを縛ることができます。証明書は名前のキーを縛ります。
Blaze, et al. Informational [Page 1] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[1ページ]のRFC2704基調信頼管理システム1999年9月
A trust-management system has five basic components:
信頼マネージメントシステムには、5つの基本的なコンポーネントがあります:
* A language for describing `actions', which are operations with
security consequences that are to be controlled by the system.
* システムによって制御されることになっているセキュリティ結果がある操作である'動作'について説明するための言語。
* A mechanism for identifying `principals', which are entities that
can be authorized to perform actions.
* 動作を実行するのを認可できる実体である'主体'を特定するためのメカニズム。
* A language for specifying application `policies', which govern the
actions that principals are authorized to perform.
* 主体が実行するのが認可される動作を治めるアプリケーション'方針'を指定するための言語。
* A language for specifying `credentials', which allow principals to
delegate authorization to other principals.
* 主体が他の主体へ承認を代表として派遣することができる'資格証明書'を指定するための言語。
* A `compliance checker', which provides a service to applications
for determining how an action requested by principals should be
handled, given a policy and a set of credentials.
* 方針と資格証明書のセットを考えて、主体によって要求された動作がどのように扱われるべきであるかを決定することのアプリケーションに対するサービスを提供する'承諾市松模様'。
The trust-management approach has a number of advantages over other mechanisms for specifying and controlling authorization, especially when security policy is distributed over a network or is otherwise decentralized.
信頼マネージメント・アプローチには、承認を指定して、制御するための他のメカニズムより多くの利点があります、特に、安全保障政策がネットワークの上に分配されるか、または別の方法で分散されるとき。
Trust management unifies the notions of security policy, credentials, access control, and authorization. An application that uses a trust-management system can simply ask the compliance checker whether a requested action should be allowed. Furthermore, policies and credentials are written in standard languages that are shared by all trust-managed applications; the security configuration mechanism for one application carries exactly the same syntactic and semantic structure as that of another, even when the semantics of the applications themselves are quite different.
信頼経営者側は安全保障政策、資格証明書、アクセスコントロール、および承認の概念を統一します。 信頼マネージメントシステムを使用するアプリケーションは、要求された動作が許容されるべきであるかどうか単に承諾市松模様に尋ねることができます。 その上、方針と資格証明書はすべての信頼で管理されたアプリケーションで共有される標準語で書かれています。 1つのアプリケーションのためのセキュリティ設定メカニズムはまさに別のもののものと同じ構文的、そして、意味的な構造を乗せます、アプリケーション自体の意味論が全く異なるときさえ。
Trust-management policies are easy to distribute across networks, helping to avoid the need for application-specific distributed policy configuration mechanisms, access control lists, and certificate parsers and interpreters.
信頼経営政策はネットワークの向こう側に分配しやすいです、アプリケーション特有の分配された方針構成メカニズム、アクセスコントロールリスト、証明書パーサ、およびインタプリタの必要性を避けるのを助けて。
For a general discussion of the use of trust management in distributed system security, see [Bla99].
分散システムセキュリティにおける信頼管理の使用の一般的な議論に関しては、[Bla99]を見てください。
KeyNote is a simple and flexible trust-management system designed to work well for a variety of large- and small-scale Internet-based applications. It provides a single, unified language for both local policies and credentials. KeyNote policies and credentials, called `assertions', contain predicates that describe the trusted actions permitted by the holders of specific public keys. KeyNote assertions are essentially small, highly-structured programs. A signed
KeyNoteはさまざまな大きくて小規模のインターネットを利用するアプリケーションにうまくいくように設計された簡単でフレキシブルな信頼マネージメントシステムです。 それはローカルの方針と資格証明書の両方に単一の、そして、統一された言語を提供します。 '主張'と呼ばれるKeyNote方針と資格証明書は特定の公開鍵の所有者によって可能にされた信じられた動作について説明する述部を含んでいます。 KeyNote主張は本質的には小さくて、非常に構造化されたプログラムです。Aは署名しました。
Blaze, et al. Informational [Page 2] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[2ページ]のRFC2704基調信頼管理システム1999年9月
assertion, which can be sent over an untrusted network, is also called a `credential assertion'. Credential assertions, which also serve the role of certificates, have the same syntax as policy assertions but are also signed by the principal delegating the trust.
また、主張(信頼されていないネットワークの上に送ることができる)は'資格証明主張'と呼ばれます。 資格証明主張(また、証明書の役割を受ける)は、方針主張と同じ構文を持っていますが、また、信頼を代表として派遣する主体によって署名されます。
In KeyNote:
基調で:
* Actions are specified as a collection of name-value pairs.
* 名前価値の収集が対にされるとき、動作は指定されます。
* Principal names can be any convenient string and can directly
represent cryptographic public keys.
* 主要な名前は、どんな便利なストリングであることができも、直接暗号の公開鍵を表すことができます。
* The same language is used for both policies and credentials.
* 同じ言語は方針と資格証明書の両方に使用されます。
* The policy and credential language is concise, highly expressive,
human readable and writable, and compatible with a variety of
storage and transmission media, including electronic mail.
* 方針と資格証明言語は簡潔です、非常に表現しています、さまざまなストレージとトランスミッションメディアとの読み込み可能で、書き込み可能で、コンパチブル人間、電子メールを含んでいて。
* The compliance checker returns an application-configured `policy
compliance value' that describes how a request should be handled
by the application. Policy compliance values are always
positively derived from policy and credentials, facilitating
analysis of KeyNote-based systems.
* 承諾市松模様は要求がアプリケーションでどう扱われるべきであるかを説明するアプリケーションで構成された'方針承諾価値'を返します。 KeyNoteベースのシステムの分析を容易にして、方針と資格証明書から方針承諾値をいつも明確に得ます。
* Compliance checking is efficient enough for high-performance and
real-time applications.
* 高性能とリアルタイムのアプリケーションに、承諾照合は十分効率的です。
This document describes the KeyNote policy and credential assertion language, the structure of KeyNote action descriptions, and the KeyNote model of computation.
このドキュメントはKeyNote方針、資格証明主張言語、KeyNote動作記述の構造、および計算のKeyNoteモデルについて説明します。
We assume that applications communicate with a locally trusted KeyNote compliance checker via a `function call' style interface, sending a collection of KeyNote policy and credential assertions plus an action description as input and accepting the resulting policy compliance value as output. However, the requirements of different applications, hosts, and environments may give rise to a variety of different interfaces to KeyNote compliance checkers; this document does not aim to specify a complete compliance checker API.
私たちは、アプリケーションが'ファンクションコール'スタイルインタフェースを通して局所的に信じられたKeyNote承諾市松模様とコミュニケートすると思います、入力されて、出力されるように結果として起こる方針承諾価値を受け入れるとしてKeyNote方針、資格証明主張、および動作記述の収集を送って。 しかしながら、異なったアプリケーション、ホスト、および環境の要件はさまざまな異なったインタフェースをKeyNote承諾市松模様にもたらすかもしれません。 このドキュメントは、完全な承諾数奇のAPIを指定することを目指しません。
2. KeyNote Concepts
2. 基調概念
In KeyNote, the authority to perform trusted actions is associated with one or more `principals'. A principal may be a physical entity, a process in an operating system, a public key, or any other convenient abstraction. KeyNote principals are identified by a string called a `Principal Identifier'. In some cases, a Principal Identifier will contain a cryptographic key interpreted by the
KeyNoteでは、信じられた動作を実行する権威は1'主体'に関連しています。 元本は、物理的実体、オペレーティングシステムによるプロセス、公開鍵、またはいかなる他の便利な抽象化であるかもしれません。 KeyNote主体は'主要なIdentifier'と呼ばれるストリングによって特定されます。 いくつかの場合、プリンシパルIdentifierは解釈された暗号化キーを含むでしょう。
Blaze, et al. Informational [Page 3] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[3ページ]のRFC2704基調信頼管理システム1999年9月
KeyNote system (e.g., for credential signature verification). In other cases, Principal Identifiers may have a structure that is opaque to KeyNote.
KeyNoteシステム(例えば、資格証明署名照合のための)。 他の場合では、プリンシパルIdentifiersはKeyNoteに不明瞭な構造を持っているかもしれません。
Principals perform two functions of concern to KeyNote: They request `actions' and they issue `assertions'. Actions are any trusted operations that an application places under KeyNote control. Assertions delegate the authorization to perform actions to other principals.
校長はKeyNoteに重要な2つの機能を実行します: 彼らは''それらが'主張を発行する動作'を要求します。 動作はアプリケーションがKeyNoteコントロールの下で置くあらゆる信じられた操作です。 主張は、承認が他の主体に動作を実行するのを代表として派遣します。
Actions are described to the KeyNote compliance checker in terms of a collection of name-value pairs called an `action attribute set'. The action attribute set is created by the invoking application. Its structure and format are described in detail in Section 3 of this document.
動作は'動作属性セット'と呼ばれる名前価値の組の収集でKeyNote承諾市松模様に説明されます。 動作属性セットは呼び出しアプリケーションで創設されます。 その構造と形式はこのドキュメントのセクション3で詳細に説明されます。
KeyNote provides advice to applications about the interpretation of policy with regard to specific requested actions. Applications invoke the KeyNote compliance checker by issuing a `query' containing a proposed action attribute set and identifying the principal(s) requesting it. The KeyNote system determines and returns an appropriate `policy compliance value' from an ordered set of possible responses.
KeyNoteは特定の要求された動作に関して方針の解釈に関するアプリケーションにアドバイスを提供します。 アプリケーションは、提案された動作属性セットを含んでいて、'質問'を発行して、それを要求しながら主体を特定することによって、KeyNote承諾市松模様を呼び出します。 KeyNoteシステムは、1つの順序集合の可能な応答から適切な'方針承諾価値'を決定して、返します。
The policy compliance value returned from a KeyNote query advises the application how to process the requested action. In the simplest case, the compliance value is Boolean (e.g., "reject" or "approve"). Assertions can also be written to select from a range of possible compliance values, when appropriate for the application (e.g., "no access", "restricted access", "full access"). Applications can configure the relative ordering (from `weakest' to `strongest') of compliance values at query time.
KeyNote質問から返された方針承諾価値は要求された動作を処理する方法にアプリケーションにアドバイスします。 最も簡単な場合では、承諾値はブールです(例えば、「廃棄物」か「承認してください」)。 また、さまざまな可能な承諾値から選び抜くために主張を書くことができます、アプリケーション(例えば、「アクセスがありません」、「制限されたアクセス」、「完全なアクセス」)に適切であるときに。 アプリケーションは質問時に承諾値の相対的な注文('最も弱いこと'から'最も強くなる'までの)を構成できます。
Assertions are the basic programming unit for specifying policy and delegating authority. Assertions describe the conditions under which a principal authorizes actions requested by other principals. An assertion identifies the principal that made it, which other principals are being authorized, and the conditions under which the authorization applies. The syntax of assertions is given in Section 4.
主張は、方針を指定して、権限を委ねるための基本的なプログラミングユニットです。 主張は元本が他の主体によって要求された動作を認可する状態について説明します。 主張はそれを作った校長、どの他の主体が認可されているか、そして、および承認が適用される状態を特定します。 セクション4で主張の構文を与えます。
A special principal, whose identifier is "POLICY", provides the root of trust in KeyNote. "POLICY" is therefore considered to be authorized to perform any action.
特別な元本(識別子は「方針」である)は基調における、信頼の根を提供します。 したがって、どんな動作も実行するのが"POLICY"が認可されると考えられます。
Blaze, et al. Informational [Page 4] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[4ページ]のRFC2704基調信頼管理システム1999年9月
Assertions issued by the "POLICY" principal are called `policy assertions' and are used to delegate authority to otherwise untrusted principals. The KeyNote security policy of an application consists of a collection of policy assertions.
「方針」主体によって発行された主張は、'方針主張'と呼ばれて、そうでなければ、信頼されていない主体への代表権威に使用されます。 アプリケーションのKeyNote安全保障政策は方針主張の収集から成ります。
When a principal is identified by a public key, it can digitally sign assertions and distribute them over untrusted networks for use by other KeyNote compliance checkers. These signed assertions are also called `credentials', and serve a role similar to that of traditional public key certificates. Policies and credentials share the same syntax and are evaluated according to the same semantics. A principal can therefore convert its policy assertions into credentials simply by digitally signing them.
元本が公開鍵によって特定されるとき、それは、使用のために他のKeyNote承諾チェッカーで主張にデジタルに署名して、信頼されていないネットワークの上にそれらを分配できます。 主張であると署名されるこれらは、また、'資格証明書'と呼ばれて、伝統的な公開鍵証明書のものと同様の役割を受けます。 方針と資格証明書は、同じ構文を共有して、同じ意味論によると、評価されます。 したがって、元本は、単にそれらにデジタルに署名することによって、方針主張を資格証明書に変換できます。
KeyNote is designed to encourage the creation of human-readable policies and credentials that are amenable to transmission and storage over a variety of media. Its assertion syntax is inspired by the format of RFC822-style message headers [Cro82]. A KeyNote assertion contains a sequence of sections, called `fields', each of which specifies one aspect of the assertion's semantics. Fields start with an identifier at the beginning of a line and continue until the next field is encountered. For example:
KeyNoteは、人間読み込み可能な方針とさまざまなメディアの上のトランスミッションとストレージに従順な資格証明書の作成を奨励するように設計されています。 主張構文はRFC822-スタイルメッセージヘッダー[Cro82]の形式によって奮い立たせられます。 KeyNote主張は'分野'と呼ばれるそれのそれぞれが主張の意味論の1つの局面を指定するセクションの系列を含んでいます。 分野は、系列の始めに識別子から始まって、次の分野が遭遇するまで、続きます。 例えば:
KeyNote-Version: 2
Comment: A simple, if contrived, email certificate for user mab
Local-Constants: ATT_CA_key = "RSA:acdfa1df1011bbac"
mab_key = "DSA:deadbeefcafe001a"
Authorizer: ATT_CA_key
Licensees: mab_key
Conditions: ((app_domain == "email") # valid for email only
&& (address == "mab@research.att.com"));
Signature: "RSA-SHA1:f00f2244"
基調バージョン: 2 コメント: ユーザmab Local-定数のための簡単で、人為的なメール証明書: ATT_カリフォルニア_主要な=「RSA: acdfa1df1011bbac」mab_キーは「DSA: deadbeefcafe001a」Authorizerと等しいです: ATT_カリフォルニアの_の主要なライセンシ: _の主要なmab Conditions: メールだけに、有効な(装置_ドメイン=「メール」)#、(アドレス=" mab@research.att.com ")。 署名: 「RSA-SHA1: f00f2244」
The meanings of the various sections are described in Sections 4 and 5 of this document.
様々なセクションの意味はこのドキュメントのセクション4と5で説明されます。
KeyNote semantics resolve the relationship between an application's policy and actions requested by other principals, as supported by credentials. The KeyNote compliance checker processes the assertions against the action attribute set to determine the policy compliance value of a requested action. These semantics are defined in Section 5.
アプリケーションの方針と動作との関係が資格証明書によってサポートされるように他の主体から要求したKeyNote意味論決心。 動作に対する主張が結果と考えるKeyNote承諾数奇のプロセスは、要求された動作の方針承諾価値を測定するためにセットしました。 これらの意味論はセクション5で定義されます。
An important principle in KeyNote's design is `assertion monotonicity'; the policy compliance value of an action is always positively derived from assertions made by trusted principals. Removing an assertion never results in increasing the compliance value returned by KeyNote for a given query. The monotonicity
KeyNoteのデザインにおける重要な原則は'主張単調'です。 信じられた主体によってされた主張から動作の方針承諾価値をいつも明確に得ます。 主張を取り除くのは承諾値が与えられた質問のためにKeyNoteで返した増加を決してもたらしません。 単調
Blaze, et al. Informational [Page 5] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[5ページ]のRFC2704基調信頼管理システム1999年9月
property can simplify the design and analysis of complex network- based security protocols; network failures that prevent the transmission of credentials can never result in spurious authorization of dangerous actions. A detailed discussion of monotonicity and safety in trust management can be found in [BFL96] and [BFS98].
特性は複雑なネットワークベースのセキュリティプロトコルのデザインと分析を簡素化できます。 資格証明書の送信を防ぐネットワーク失敗は危険な動きの偽りの承認を決してもたらすことができません。 [BFL96]と[BFS98]で信頼管理における単調と安全の詳細な論議を見つけることができます。
3. Action Attributes
3. 動作属性
Trusted actions to be evaluated by KeyNote are described by a collection of name-value pairs called the `action attribute set'. Action attributes are the mechanism by which applications communicate requests to KeyNote and are the primary objects on which KeyNote assertions operate. An action attribute set is passed to the KeyNote compliance checker with each query.
KeyNoteによって評価されるべき信じられた動作は'動作属性セット'と呼ばれる名前価値の組の収集で説明されます。 動作属性は、アプリケーションが要求をKeyNoteに伝えるメカニズムであり、KeyNote主張が作動するプライマリオブジェクトです。 動作属性セットは各質問のときにKeyNote承諾市松模様に渡されます。
Each action attribute consists of a name and a value. The semantics of the names and values are not interpreted by KeyNote itself; they vary from application to application and must be agreed upon by the writers of applications and the writers of the policies and credentials that will be used by them.
それぞれの動作属性は名前と価値から成ります。 名前と値の意味論はKeyNote自身によって解釈されません。 それらをアプリケーションによって異なって、それらによって使用されるアプリケーションの作家と方針と資格証明書の作家は同意しなければなりません。
Action attribute names and values are represented by arbitrary-length strings. KeyNote guarantees support of attribute names and values up to 2048 characters long. The handling of longer attribute names or values is not specified and is KeyNote-implementation-dependent. Applications and assertions should therefore avoid depending on the the use of attributes with names or values longer than 2048 characters. The length of an attribute value is represented by an implementation-specific mechanism (e.g., NUL-terminated strings, an explicit length field, etc.).
動作属性名と値は任意の長さのストリングによって表されます。 KeyNoteは長い間、属性名と値のサポートを2048のキャラクタまで保証します。 より長い属性名か値の取り扱いは、指定されないで、KeyNote実装扶養家族です。 したがって、アプリケーションと主張は、2048のキャラクタより長い間名前か値で属性の使用によるのを避けるべきです。 実装特有のメカニズム(例えば、NULによって終えられたストリング、明白な長さの分野など)によって属性値の長さは表されます。
Attribute values are inherently untyped and are represented as character strings by default. Attribute values may contain any non- NUL ASCII character. Numeric attribute values should first be converted to an ASCII text representation by the invoking application, e.g., the value 1234.5 would be represented by the string "1234.5".
属性値は、本来非タイプされて、デフォルトで文字列として表されます。 属性値はどんな非NULのASCII文字も含むかもしれません。 数値属性値は最初に呼び出しアプリケーションでASCIIテキスト表現に変換されるべきです、例えば、値1234.5はストリング「1234.5」によって表されるでしょう。
Attribute names are of the form:
属性名はフォームのものです:
<AttributeID>:: {Any string starting with a-z, A-Z, or the
underscore character, followed by any number of
a-z, A-Z, 0-9, or underscore characters} ;
<AttributeID>:、: 1zから始動するどんなストリング(A-Z、または強調キャラクタ)も、1zのどんな数、A-Z、0-9、または強調キャラクタでも続きました。
That is, an <AttributeID> begins with an alphabetic or underscore character and can be followed by any number of alphanumerics and underscores. Attribute names are case-sensitive.
すなわち、<AttributeID>のアルファベットか強調キャラクタと共に始まって、いろいろな英数と強調があとに続くことができます。 属性名は大文字と小文字を区別しています。
Blaze, et al. Informational [Page 6] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[6ページ]のRFC2704基調信頼管理システム1999年9月
The exact mechanism for passing the action attribute set to the compliance checker is determined by the KeyNote implementation. Depending on specific requirements, an implementation may provide a mechanism for including the entire attribute set as an explicit parameter of the query, or it may provide some form of callback mechanism invoked as each attribute is dereferenced, e.g., for access to kernel variables.
動作属性セットを承諾市松模様に渡すための正確なメカニズムはKeyNote実装で決定します。 決められた一定の要求によって、実装が質問の明白なパラメタとして全体の属性セットを含んでいるのにメカニズムを提供するかもしれませんか、または各属性が「反-参照をつけ」られるので呼び出された何らかのフォームのコールバックメカニズムを提供するかもしれません、例えば、カーネル変数へのアクセスのために。
If an action attribute is not defined its value is considered to be the empty string.
動作属性が定義されないなら、値は空のストリングであると考えられます。
Attribute names beginning with the "_" character are reserved for use by the KeyNote runtime environment and cannot be passed from applications as part of queries. The following special attribute names are used:
"_"キャラクタと共に始まる属性名は、使用のために基調ランタイム環境で予約して、質問の一部としてアプリケーションから通過できません。 以下の特別な属性名は使用されています:
Name Purpose
------------------------ ------------------------------------
_MIN_TRUST Lowest-order (minimum) compliance
value in query; see Section 5.1.
名前目的------------------------ ------------------------------------ _質問におけるMIN_TRUST Lowest-オーダー(最小の)承諾価値。 セクション5.1を見てください。
_MAX_TRUST Highest-order (maximum) compliance
value in query; see Section 5.1.
_質問におけるマックス_TRUST Highest-オーダー(最大の)承諾価値。 セクション5.1を見てください。
_VALUES Linearly ordered set of compliance
values in query; see Section 5.1.
Comma separated.
_質問における、VALUES Linearly順序集合の承諾値。 セクション5.1を見てください。 コンマは分離しました。
_ACTION_AUTHORIZERS Names of principals directly
authorizing action in query.
Comma separated.
_直接質問における動作を認可する校長のACTION_AUTHORIZERS Names。 コンマは分離しました。
In addition, attributes with names of the form "_<N>", where <N> is an ASCII-encoded integer, are used by the regular expression matching mechanism described in Section 5.
「追加、」 _フォーム<N>の名前がある属性」は<N>がASCIIによってコード化された整数であるところでセクション5で説明された正規表現の合っているメカニズムによって使用されます。
The assignment and semantics of any other attribute names beginning with "_" is unspecified and implementation-dependent.
"_"で始まるいかなる他の属性名の課題と意味論も、不特定であって、実装依存しています。
The names of other attributes in the action attribute set are not specified by KeyNote but must be agreed upon by the writers of any policies and credentials that are to inter-operate in a specific KeyNote query evaluation.
動作属性セットにおける他の属性の名前にKeyNoteによって指定されませんが、どんな方針の作家も同意しなければなりません、そして、特定のKeyNoteに共同利用することになっている資格証明書は評価について質問します。
Blaze, et al. Informational [Page 7] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[7ページ]のRFC2704基調信頼管理システム1999年9月
By convention, the name of the application domain over which action attributes should be interpreted is given in the attribute named "app_domain". The IANA (or some other suitable authority) will provide a registry of reserved app_domain names. The registry will list the names and meanings of each application's attributes.
コンベンションによって、動作属性が解釈されるべきであるアプリケーションドメインの名前は「装置_ドメイン」という属性で与えられています。 IANA(または、ある他の適当な権威)は予約された装置_ドメイン名の登録を提供するでしょう。 登録は各アプリケーションの属性の名前と意味を記載するでしょう。
The app_domain convention helps to ensure that credentials are interpreted as they were intended. An attribute with any given name may be used in many different application domains but might have different meanings in each of them. However, the use of a global registry is not always required for small-scale, closed applications; the only requirement is that the policies and credentials made available to the KeyNote compliance checker interpret attributes according to the same semantics assumed by the application that created them.
装置_ドメインコンベンションは、彼らが意図したとき資格証明書が解釈されるのを保証するのを助けます。 どんな名がいる属性も、多くの異なったアプリケーションドメインで使用されますが、それぞれのそれらに異なった意味を持っているかもしれません。 しかしながら、グローバルな登録の使用が小規模の、そして、閉じているアプリケーションにいつも必要であるというわけではありません。 唯一の要件はそれらを作成したアプリケーションで想定された同じ意味論によると、KeyNote承諾市松模様に利用可能にされた方針と資格証明書が属性を解釈するということです。
For example, an email application might reserve the app_domain "RFC822-EMAIL" and might use the attributes named "address" (the email address of a message's sender), "name" (the human name of the message sender), and any "organization" headers present (the organization name). The values of these attributes would be derived in the obvious way from the email message headers. The public key of the message's signer would be given in the "_ACTION_AUTHORIZERS" attribute.
(メッセージ送付者の人間の名前)、およびヘッダーが提示するどんな「組織」(組織名)も、例えば、メールアプリケーションが装置_ドメイン「RFC822-メール」を予約して、「アドレス」(メッセージの送付者のEメールアドレス)という属性を使用するかもしれないと「命名します」。 これらの属性の値はメールメッセージヘッダーから当たり前の方法的に引き出されるでしょう。 「メッセージの署名者の公開鍵を与えるだろう、」 _動作_AUTHORIZERS、」 結果と考えます。
Note that "RFC822-EMAIL" is a hypothetical example; such a name may or may not appear in the actual registry with these or different attributes. (Indeed, we recognize that the reality of email security is considerably more complex than this example might suggest.)
「RFC822-メール」が仮定している例であることに注意してください。 そのような名前はこれらか異なった属性と共に実際の登録に現れるかもしれません。 (本当に、私たちはメールセキュリティの現実がこの例に示されるかもしれないよりかなり複雑であると認めます。)
4. KeyNote Assertion Syntax
4. 基調主張構文
In the following sections, the notation [X]* means zero or more repetitions of character string X. The notation [X]+ means one or more repetitions of X. The notation <X>* means zero or more repetitions of non-terminal <X>. The notation <X>+ means one or more repetitions of X, whereas <X>? means zero or one repetitions of X. Nonterminal grammar symbols are enclosed in angle brackets. Quoted strings in grammar productions represent terminals.
以下のセクションでは、記法[X]*がゼロを意味するか、またはキャラクタの、より多くの反復がX. X. 非端末<X>の記法<X>*手段ゼロか、より多くの反復の記法[X]+手段1か、より多くの反復を結びます。 Xの記法<X>+手段1か、より多くの反復、<X>?はX.Nonterminalのゼロか1つの反復を意味しますが、文法シンボルは角ブラケットに同封されます。 文法創作の引用文字列は端末を表します。
4.1 Basic Structure
4.1 基本構造
<Assertion>:: <VersionField>? <AuthField> <LicenseesField>?
<LocalConstantsField>? <ConditionsField>?
<CommentField>? <SignatureField>? ;
<主張>:、: <VersionField>? <AuthField><LicenseesField>? <LocalConstantsField>? <ConditionsField>? <CommentField>? <SignatureField>? ;
All KeyNote assertions are encoded in ASCII.
すべてのKeyNote主張がASCIIでコード化されます。
Blaze, et al. Informational [Page 8] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[8ページ]のRFC2704基調信頼管理システム1999年9月
KeyNote assertions are divided into sections, called `fields', that serve various semantic functions. Each field starts with an identifying label at the beginning of a line, followed by the ":" character and the field's contents. There can be at most one field per line.
KeyNote主張は様々な意味関数に役立つ'分野'と呼ばれるセクションに分割されます。 「続かれて、各分野が系列の始めに特定ラベルから始まる、」、:、」 キャラクタとフィールドのコンテンツ。 1系列あたりの分野が最も1つにあることができます。
A field may be continued over more than one line by indenting subsequent lines with at least one ASCII SPACE or TAB character. Whitespace (a SPACE, TAB, or NEWLINE character) separates tokens but is otherwise ignored outside of quoted strings. Comments with a leading octothorp character (see Section 4.2) may begin in any column.
分野は、1つ以上の系列の上で少なくとも1ASCII SPACEかTABキャラクタと共にその後の系列を字下がりにすることによって、続けられるかもしれません。 空白(SPACE、TAB、またはNEWLINEキャラクタ)は、トークンを切り離しますが、別の方法で引用文字列の外で無視されます。 主なシャープ記号キャラクタ(セクション4.2を見る)とのコメントはどんなコラムでも始まるかもしれません。
One mandatory field is required in all assertions:
1つの義務的な分野がすべての主張で必要です:
Authorizer
Authorizer
Six optional fields may also appear:
また、6つの任意の野原が現れるかもしれません:
Comment
Conditions
KeyNote-Version
Licensees
Local-Constants
Signature
コメント状態基調バージョンライセンシ地方の定数署名
All field names are case-insensitive. The "KeyNote-Version" field, if present, appears first. The "Signature" field, if present, appears last. Otherwise, fields may appear in any order. Each field may appear at most once in any assertion.
すべてのフィールド名が大文字と小文字を区別しないです。 存在しているなら、「基調バージョン」野原は最初に、現れます。 存在しているなら、「署名」野原は最後に現れます。 さもなければ、野原は順不同に現れるかもしれません。 各野原はどんな主張にも高々一度現れるかもしれません。
Blank lines are not permitted in assertions. Multiple assertions stored in a file (e.g., in application policy configurations), therefore, can be separated from one another unambiguously by the use of blank lines between them.
空白行は主張で受入れられません。 お互いと明白にそれらの間の空白行の使用でしたがってファイル(例えば、アプリケーション方針構成における)に保存された複数の主張は切り離すことができます。
4.2 Comments
4.2 コメント
<Comment>:: "#" {ASCII characters} ;
<コメント>:、: 「#」ASCII文字。
The octothorp character ("#", ASCII 35 decimal) can be used to
introduce comments. Outside of quoted strings (see Section 4.3), all
characters from the "#" character through the end of the current line
are ignored. However, commented text is included in the computation
of assertion signatures (see Section 4.6.7).
コメントを導入するのに、シャープ記号キャラクタ(「#」、ASCII35小数)を使用できます。 引用文字列(セクション4.3を見る)の外では、現在行の端までの「#」キャラクタからのすべてのキャラクタが無視されます。 しかしながら、論評されたテキストは主張署名の計算に含まれています(セクション4.6.7を見てください)。
Blaze, et al. Informational [Page 9] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[9ページ]のRFC2704基調信頼管理システム1999年9月
4.3 Strings
4.3 ストリング
A `string' is a lexical object containing a sequence of characters. Strings may contain any non-NUL characters, including newlines and nonprintable characters. Strings may be given as literals, computed from complex expressions, or dereferenced from attribute names.
'ストリング'はキャラクタの系列を含む語彙オブジェクトです。 ストリングはニューラインと印字不能文字を含むどんな非NULキャラクタも含むかもしれません。 ストリングは、複素式から計算されたリテラルとして与えたかもしれないか、または属性名から「反-参照をつけ」ました。
4.3.1 String Literals
4.3.1 文字列リテラル
<StringLiteral>:: "\"" {see description below} "\"" ;
<StringLiteral>:、: 「「\」」が記述下を見る、「\」、」、。
A string literal directly represents the value of a string. String literals must be quoted by preceding and following them with the double-quote character (ASCII 34 decimal).
文字列リテラルは直接ストリングの値を表します。 二重引用文字と共にそれらに先行して、続くことによって文字列リテラルを引用しなければならない、(ASCII、34小数)
A printable character may be `escaped' inside a quoted string literal by preceding it with the backslash character (ASCII 92 decimal) (e.g., "like \"this\"."). This permits the inclusion of the double- quote and backslash characters inside string literals.
「印刷可能なキャラクタはそうです'がバックスラッシュキャラクタと共にそれに先行することによって'内面のa引用文字列リテラルから逃げた、(ASCII、92小数)、(例えば、「\」、この\、」、」、) これは文字列リテラルで二重引用文とバックスラッシュキャラクタの包含を可能にします。
A similar escape mechanism is also used to represent non-printable characters. "\n" represents the newline character (ASCII character 10 decimal), "\r" represents the carriage-return character (ASCII character 13 decimal), "\t" represents the tab character (ASCII character 9 decimal), and "\f" represents the form-feed character (ASCII character 12 decimal). A backslash character followed by a newline suppresses all subsequent whitespace (including the newline) up to the next non-whitespace character (this allows the continuation of long string constants across lines). Un-escaped newline and return characters are illegal inside string literals.
また、同様の逃避機制は、非印刷可能なキャラクタの代理をするのに使用されます。 「「\n」がニューラインキャラクタの代理をする、(ASCII文字、10小数)、」、\r」が復帰文字を表す、(ASCII文字、13小数)、」、\t」がタブキャラクタの代理をする、(ASCII文字、9小数)、」 \f」が用紙送り文字を表す、(ASCII文字、12小数) ニューラインが支えたバックスラッシュキャラクタはすべてのその後の空白(ニューラインを含んでいる)を次の非空白キャラクタまで抑圧します(これは系列の向こう側にロング・ストリング定数の継続を許します)。 不-逃げられたニューラインとリターン・マークは文字列リテラルで不法です。
The constructs "%%BODY%%o", "%%BODY%%oo", and "\ooo" (where o represents any octal digit) may be used to represent any non-NUL ASCII characters with their corresponding octal values (thus, "%%BODY%%12" is the same as "\n", "\101" is "A", and "\377" is the ASCII character 255 decimal). However, the NUL character cannot be encoded in this manner; "%%BODY%%", "%%BODY%%0", and "%%BODY%%00" are converted to the strings "0", "00", and "000" respectively. Similarly, all other escaped characters have the leading backslash removed (e.g., "\a" becomes "a", and "\\" becomes "\"). The following four strings are equivalent:
「構造物」 %%BODY%%o」、」、」 」 \がoooする%%BODY%%oo、」、彼らの対応する8進値でどんな非NUL ASCII文字も代理をするのに使用されるかもしれない、(oがどんな8進数字も表すところ)(このようにして」、\12インチが」 \n」と同じであり、」 101インチ円が「A」であり、」 377インチ円がASCII文字である、255小数) しかしながら、この様にNULキャラクタをコード化できません。 「「」 %%BODY%%インチ、\がストリングに」 0インチ、および%%BODY%%インチ変換される、「0インチ、「0インチ、「0インチ、それぞれ」 同様に、他のすべての逃げられたキャラクタが主なバックスラッシュを取り除かせます。「(」 例えば\a」が“a"になる、」 \\、」、なる、「\」) 以下の4個のストリングが同等です:
"this string contains a newline\n followed by one space."
"this string contains a newline\n \
followed by one space."
「このストリングは\nが1つのスペースで続いたニューラインを含んでいます。」 「このストリングは\n\が1つのスペースで続いたニューラインを含んでいます。」
Blaze, et al. Informational [Page 10] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[10ページ]のRFC2704基調信頼管理システム1999年9月
"this str\
ing contains a \
newline\n followed by one space."
「このstr\ingは\nが1つのスペースで続いた\ニューラインを含んでいます。」
"this string contains a newline%%BODY%%12%%BODY%%40followed by one space."
「このストリングは1つのスペースのそばにニューラインを012円の%%BODY%%40followed保管しています。」
4.3.2 String Expressions
4.3.2 ストリング式
In general, anywhere a quoted string literal is allowed, a `string expression' can be used. A string expression constructs a string from string constants, dereferenced attributes (described in Section 4.4), and a string concatenation operator. String expressions may be parenthesized.
一般に、そして、どこでも、引用文字列リテラルが許容されている'ストリング式'を使用できます。 ストリング式はストリング定数、「反-参照をつけ」られた属性(セクション4.4では、説明される)、および文字列連結演算子からストリングを構成します。 ストリング式はparenthesizedされるかもしれません。
<StrEx>:: <StrEx> "." <StrEx> /* String concatenation */
| <StringLiteral> /* Quoted string */
| "(" <StrEx> ")"
| <DerefAttribute> /* See Section 4.4 */
| "$" <StrEx> ; /* See Section 4.4 */
<StrEx>:、: 「<StrEx>」、」 <StrEx>/*文字列連結*/| <StringLiteral>/*引用文字列*/| 「(「<StrEx>」)」| <DerefAttribute>/*はセクション4.4*/を見ます。| 「$」<StrEx>。 /*はセクション4.4*/を見ます。
The "$" operator has higher precedence than the "." operator.
「「$」オペレータには、より高い先行がある、」 . 」 オペレータ。
4.4 Dereferenced Attributes
4.4 Dereferenced属性
Action attributes provide the primary mechanism for applications to pass information to assertions. Attribute names are strings from a limited character set (<AttributeID> as defined in Section 3), and attribute values are represented internally as strings. An attribute is dereferenced simply by using its name. In general, KeyNote allows the use of an attribute anywhere a string literal is permitted.
アプリケーションが情報を主張に通過するように、動作属性は一次機構を提供します。 属性名は限られた文字集合(セクション3で定義される<AttributeID>)からのストリングです、そして、属性値はストリングとして内部的に表されます。 単に人の名前を引合いに出すことによって、属性は「反-参照をつけ」られます。 一般に、KeyNoteはどこでも文字列リテラルが受入れられる属性の使用を許します。
Attributes are dereferenced as strings by default. When required, dereferenced attributes can be converted to integers or floating point numbers with the type conversion operators "@" and "&". Thus, an attribute named "foo" having the value "1.2" may be interpreted as the string "1.2" (foo), the integer value 1 (@foo), or the floating point value 1.2 (&foo).
属性はデフォルトでストリングとして「反-参照をつけ」られます。 必要であると、型変換オペレータの"@"と“&"と共に「反-参照をつけ」られた属性を整数か浮動小数点に変換できます。 したがって、属性が、値を持っていると"foo"を命名した、「1.2インチがそうである、「何1.2インチ(foo)も、整数は1(@foo)、または浮動小数点値1.2(foo)を評価します」ストリングとして解釈された。
Attributes converted to integer and floating point numbers are represented according to the ANSI C `long' and `float' types, respectively. In particular, integers range from -2147483648 to 2147483647, whilst floats range from 1.17549435E-38F to 3.40282347E+38F.
属性は整数に変えました、そして、ANSI Cに従って、浮動小数点は'長い'の間、表されます、そして、'浮遊物'はそれぞれタイプされます。 特に、整数は-2147483648〜2147483647まで及びますが、浮遊物はE+38Fに1.17549435E38Fから3.40282347まで及びます。
Any uninitialized attribute has the empty-string value when dereferenced as a string and the value zero when dereferenced as an integer or float.
どんな非初期化している属性にも、整数か浮遊物として「反-参照をつけ」られるとストリングと値ゼロとして「反-参照をつけ」られると、空のストリング値があります。
Blaze, et al. Informational [Page 11] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[11ページ]のRFC2704基調信頼管理システム1999年9月
Attribute names may be given literally or calculated from string expressions and may be recursively dereferenced. In the simplest case, an attribute is dereferenced simply by using its name outside of quotes; e.g., the string value of the attribute named "foo" is by reference to `foo' (outside of quotes). The "$<StrEx>" construct dereferences the attribute named in the string expression <StrEx>. For example, if the attribute named "foo" contains the string "bar", the attribute named "bar" contains the string "xyz", and the attribute "xyz" contains the string "qua", the following string comparisons are all true:
属性名を文字通り与えるか、ストリング式から計算して、または再帰的に「反-参照をつけ」るかもしれません。 最も簡単な場合では、単に引用文の外で名前を使用することによって、属性は「反-参照をつけ」られます。 例えば"foo"という属性のストリング値が'foo'の参照であります(引用文の外)。 $<StrEx>、」 属性がストリング式<StrEx>で命名した反参照を組み立ててください。 例えば、"foo"という属性がストリング「バー」を含んでいて、「バー」という属性がストリング"xyz"を含んでいて、属性"xyz"が「資格で」ストリングを含んでいるなら、以下のストリング比較はすべて本当です:
foo == "bar"
$("foo") == "bar"
$foo == "xyz"
$(foo) == "xyz"
$$foo == "qua"
"xyz"$(foo)="xyz"foo=「バー」$("foo")=「バー」$foo=$$foo=「資格で」
If <StrEx> evaluates to an invalid or uninitialized attribute name, its value is considered to be the empty string (or zero if used as a numeric).
または、StrEx>が無効の、または、非初期化している属性名、値に評価する<が空のストリングであると考えられる、(数値として使用されるならゼロに合わせる、)
The <DerefAttribute> token is defined as:
<DerefAttribute>トークンは以下と定義されます。
<DerefAttribute>:: <AttributeID> ;
<DerefAttribute>:、: <AttributeID>。
4.5 Principal Identifiers
4.5 主要な識別子
Principals are represented as ASCII strings called `Principal Identifiers'. Principal Identifiers may be arbitrary labels whose structure is not interpreted by the KeyNote system or they may encode cryptographic keys that are used by KeyNote for credential signature verification.
ASCIIストリングが、'主要なIdentifiers'と呼んだように主体は表されます。 主要なIdentifiersは構造がKeyNoteシステムによって解釈されない任意のラベルであるかもしれませんかそれらが資格証明署名照合にKeyNoteによって使用される暗号化キーをコード化するかもしれません。
<PrincipalIdentifier>:: <OpaqueID>
| <KeyID> ;
<PrincipalIdentifier>:、: <OpaqueID>。| <KeyID>。
4.5.1 Opaque Principal Identifiers
4.5.1 不明瞭な主要な識別子
Principal Identifiers that are used by KeyNote only as labels are said to be `opaque'. Opaque identifiers are encoded in assertions as strings (see Section 4.3):
ラベルだけとしてKeyNoteによって使用される主要なIdentifiersは'不透明である'と言われています。 不明瞭な識別子はストリングとして主張でコード化されます(セクション4.3を見てください):
<OpaqueID>:: <StrEx> ;
<OpaqueID>:、: <StrEx>。
Opaque identifier strings should not contain the ":" character.
「不透明な識別子ストリングが含むはずがない、」、:、」 キャラクタ。
Blaze, et al. Informational [Page 12] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[12ページ]のRFC2704基調信頼管理システム1999年9月
4.5.2 Cryptographic Principal Identifiers
4.5.2 暗号の主要な識別子
Principal Identifiers that are used by KeyNote as keys, e.g., to verify credential signatures, are said to be `cryptographic'. Cryptographic identifiers are also lexically encoded as strings:
キーとしてKeyNoteによって使用される主要なIdentifiersは、例えば資格証明署名について確かめるために'暗号である'と言われています。 また、暗号の識別子はストリングとして辞書的にコード化されます:
<KeyID>:: <StrEx> ;
<KeyID>:、: <StrEx>。
Unlike Opaque Identifiers, however, Cryptographic Identifier strings have a special form. To be interpreted by KeyNote (for signature verification), an identifier string should be of the form:
しかしながら、Opaque Identifiersと異なって、Cryptographic Identifierストリングには、特別なフォームがあります。 識別子ストリングはKeyNote(署名照合のための)によって解釈されるためには、フォームのものであるはずです:
<IDString>:: <ALGORITHM>":"<ENCODEDBITS> ;
<IDString>:、: 「<アルゴリズム>」: 「<ENCODEDBITS>」。
"ALGORITHM" is an ASCII substring that describes the algorithms to be used in interpreting the key's bits. The ALGORITHM identifies the major cryptographic algorithm (e.g., RSA [RSA78], DSA [DSA94], etc.), structured format (e.g., PKCS1 [PKCS1]), and key bit encoding (e.g., HEX or BASE64). By convention, the ALGORITHM substring starts with an alphabetic character and can contain letters, digits, underscores, or dashes (i.e., it should match the regular expression "[a-zA-Z][a- zA-Z0-9_-]*"). The IANA (or some other appropriate authority) will provide a registry of reserved algorithm identifiers.
"ALGORITHM"はキーのビットを解釈する際に使用されるためにアルゴリズムを説明するASCIIサブストリングです。 ALGORITHMは(例えば、HEXかBASE64)をコード化する構造化された主要な暗号アルゴリズム(例えば、RSA[RSA78]、DSA[DSA94]など)、形式(例えば、PKCS1[PKCS1])、およびキービットを特定します。 ALGORITHMサブストリングがコンベンションで、英字から始まって、手紙、ケタ、強調、またはダッシュを含むことができる、(正規表現に合うべきである、「[a-zA-Z]、[a zA-Z0-9_、-、]、*、」、) IANA(または、ある他の適切な権威)は予約されたアルゴリズム識別子の登録を提供するでしょう。
"ENCODEDBITS" is a substring of characters representing the key's bits, the encoding and format of which depends on the ALGORITHM. By convention, hexadecimal encoded keys use lower-case ASCII characters.
「ENCODEDBITS」はそれのキーのビットを表す、コード化、および形式をALGORITHMに依存するキャラクタに関するサブストリングです。 コンベンションで、16進のコード化されたキーは小文字のASCII文字を使用します。
Cryptographic Principal Identifiers are converted to a normalized canonical form for the purposes of any internal comparisons between them; see Section 5.2.
暗号のプリンシパルIdentifiersはそれらでのどんな内部の比較の目的のための正常にされた標準形にも転向しています。 セクション5.2を見てください。
Note that the keys used in examples throughout this document are fictitious and generally much shorter than would be required for security in practice.
このドキュメント中の例で使用されるキーが架空であって一般に、実際にはセキュリティのために必要とされるだろうよりはるかに不足していることに注意してください。
4.6 KeyNote Fields
4.6 基調分野
4.6.1 The KeyNote-Version Field
4.6.1 基調バージョン分野
The KeyNote-Version field identifies the version of the KeyNote assertion language under which the assertion was written. The KeyNote-Version field is of the form
KeyNote-バージョン分野は主張が書かれたKeyNote主張言語のバージョンを特定します。 KeyNote-バージョン分野はフォームのものです。
<VersionField>:: "KeyNote-Version:" <VersionString> ;
<VersionString>:: <StringLiteral>
| <IntegerLiteral> ;
<VersionField>:、: 「基調バージョン:」 <VersionString>。 <VersionString>:、: <StringLiteral>。| <IntegerLiteral>。
Blaze, et al. Informational [Page 13] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[13ページ]のRFC2704基調信頼管理システム1999年9月
where <VersionString> is an ASCII-encoded string. Assertions in production versions of KeyNote use decimal digits in the version representing the version number of the KeyNote language under which they are to be interpreted. Assertions written to conform with this document should be identified with the version string "2" (or the integer 2). The KeyNote-Version field, if included, should appear first.
<VersionString>がASCIIによってコード化されたストリングであるところ。 KeyNoteの生産バージョンにおける主張は、それらが解釈されることになっているKeyNote言語のバージョン番号を表しながら、バージョンで10進数字を使用します。 このドキュメントに従うために書かれた主張はバージョンストリング「2インチ(または、整数2)」と同一視されるべきです。 含まれているなら、KeyNote-バージョン野原は最初に、現れるはずです。
4.6.2 The Local-Constants Field
4.6.2 地方の定数分野
This field adds or overrides action attributes in the current assertion only. This mechanism allows the use of short names for (frequently lengthy) cryptographic principal identifiers, especially to make the Licensees field more readable. The Local-Constants field is of the form:
この分野は、現在の主張だけにおける動作属性を加えるか、またはくつがえします。 このメカニズムは、特にLicensees分野をより読み込み可能にするように省略名の(頻繁に長い)の暗号の主要な識別子の使用を許します。 Local-定数分野はフォームのものです:
<LocalConstantsField>:: "Local-Constants:" <Assignments> ;
<Assignments>:: /* can be empty */
| <AttributeID> "=" <StringLiteral> <Assignments> ;
<LocalConstantsField>:、: 「地方の定数:」 <課題>。 <課題>:、: /*は空の*/であることができる。| <AttributeID>は<StringLiteral><課題>と「等しいです」。
<AttributeID> is an attribute name from the action attribute namespace as defined in Section 3. The name is available for use as an attribute in any subsequent field. If the Local-Constants field defines more than one identifier, it can occupy more than one line and be indented. <StringLiteral> is a string literal as described in Section 4.3. Attributes defined in the Local-Constants field override any attributes with the same name passed in with the action attribute set.
<AttributeID>はセクション3で定義されるように動作属性名前空間からの属性名です。 名前はどんなその後の分野の属性としても使用に利用可能です。 Local-定数分野が1つ以上の識別子を定義するなら、それは、1つ以上の系列を占領して、ギザギザを付けられることができます。 <StringLiteral>はセクション4.3で説明されるように文字列リテラルです。 中の同じ名前が通過されていた状態で、属性は動作属性セットでLocal-定数分野オーバーライドでどんな属性も定義しました。
An attribute may be initialized at most once in the Local-Constants field. If an attribute is initialized more than once in an assertion, the entire assertion is considered invalid and is not considered by the KeyNote compliance checker in evaluating queries.
属性はLocal-定数分野で高々一度初期化されるかもしれません。 属性が主張における一度より初期化されるなら、全体の主張は、無効であると考えられて、質問を評価する際にKeyNote承諾市松模様によって考えられません。
4.6.3 The Authorizer Field
4.6.3 Authorizer分野
The Authorizer identifies the Principal issuing the assertion. This field is of the form
Authorizerは主張を発行するプリンシパルを特定します。 この分野はフォームのものです。
<AuthField>:: "Authorizer:" <AuthID> ;
<AuthID>:: <PrincipalIdentifier>
| <DerefAttribute> ;
<AuthField>:、: 「Authorizer:」 <AuthID>。 <AuthID>:、: <PrincipalIdentifier>。| <DerefAttribute>。
The Principal Identifier may be given directly or by reference to the attribute namespace (as defined in Section 4.4).
直接か属性名前空間の参照でプリンシパルIdentifierを与えるかもしれません(セクション4.4で定義されるように)。
Blaze, et al. Informational [Page 14] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[14ページ]のRFC2704基調信頼管理システム1999年9月
4.6.4 The Licensees Field
4.6.4 ライセンシ分野
The Licensees field identifies the principals authorized by the assertion. More than one principal can be authorized, and authorization can be distributed across several principals through the use of `and' and threshold constructs. This field is of the form
Licensees分野は主張で認可された主体を特定します。 1つ以上の主体を認可できます、そして、いくつかの主体の向こう側に'and'と敷居構造物の使用で承認を分配できます。 この分野はフォームのものです。
<LicenseesField>:: "Licensees:" <LicenseesExpr> ;
<LicenseesField>:、: 「ライセンシ:」 <LicenseesExpr>。
<LicenseesExpr>:: /* can be empty */
| <PrincExpr> ;
<LicenseesExpr>:、: /*は空の*/であることができる。| <PrincExpr>。
<PrincExpr>:: "(" <PrincExpr> ")"
| <PrincExpr> "&&" <PrincExpr>
| <PrincExpr> "||" <PrincExpr>
| <K>"-of(" <PrincList> ")" /* Threshold */
| <PrincipalIdentifier>
| <DerefAttribute> ;
<PrincExpr>:、: 「(「<PrincExpr>」)」| <PrincExpr>“&&"<PrincExpr>。| 「<PrincExpr>」||「<PrincExpr>」| 「<K>」、-、」 (「<PrincList>」)/*敷居*/| <PrincipalIdentifier>。| <DerefAttribute>。
<PrincList>:: <PrincipalIdentifier>
| <DerefAttribute>
| <PrincList> "," <PrincList> ;
<PrincList>:、: <PrincipalIdentifier>。| <DerefAttribute>。| 」 「<PrincList>」、<PrincList>。
<K>:: {Decimal number starting with a digit from 1 to 9} ;
<K>:、: 1〜9までケタから始まる10進数。
The "&&" operator has higher precedence than the "||" operator. <K> is an ASCII-encoded positive decimal integer. If a <PrincList> contains fewer than <K> principals, the entire assertion is omitted from processing.
「“&&"オペレータには、より高い先行がある、」||「オペレータ。」 <K>はASCIIによってコード化された陽の10進整数です。 PrincList>が<K>主体、全体の主張ほど含まない<が処理から省略されるなら。
4.6.5 The Conditions Field
4.6.5 状態分野
This field gives the `conditions' under which the Authorizer trusts the Licensees to perform an action. `Conditions' are predicates that operate on the action attribute set. The Conditions field is of the form:
この分野はAuthorizerが、Licenseesが動作を実行すると信じる'状態'を与えます。 '状態'は動作属性セットを経営する述部です。 Conditions分野はフォームのものです:
<ConditionsField>:: "Conditions:" <ConditionsProgram> ;
<ConditionsField>:、: 「状態:」 <ConditionsProgram>。
<ConditionsProgram>:: /* Can be empty */
| <Clause> ";" <ConditionsProgram> ;
<ConditionsProgram>:、: /*は空の*/であることができる。| 「<節>」;、」 <ConditionsProgram>。
<Clause>:: <Test> "->" "{" <ConditionsProgram> "}"
| <Test> "->" <Value>
| <Test> ;
<節>:、: <テスト>"->"「「<ConditionsProgram>」」| <テスト>"->"<値の>。| <テスト>。
<Value>:: <StrEx> ;
<値の>:、: <StrEx>。
Blaze, et al. Informational [Page 15] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[15ページ]のRFC2704基調信頼管理システム1999年9月
<Test>:: <RelExpr> ;
<テスト>:、: <RelExpr>。
<RelExpr>:: "(" <RelExpr> ")" /* Parentheses */
| <RelExpr> "&&" <RelExpr> /* Logical AND */
| <RelExpr> "||" <RelExpr> /* Logical OR */
| "!" <RelExpr> /* Logical NOT */
| <IntRelExpr>
| <FloatRelExpr>
| <StringRelExpr>
| "true" /* case insensitive */
| "false" ; /* case insensitive */
<RelExpr>:、: 「(「<RelExpr>」)」 /*括弧*/| <RelExpr>“&&"<RelExpr>/*論理的なAND*/| 「<RelExpr>」||「<RelExpr>/*論理的なOR*/」| "!" <RelExpr>/*論理的なNOT*/| <IntRelExpr>。| <FloatRelExpr>。| <StringRelExpr>。| 「本当」/*大文字と小文字を区別しない*/| 「虚偽」。 /*大文字と小文字を区別しない*/
<IntRelExpr>:: <IntEx> "==" <IntEx>
| <IntEx> "!=" <IntEx>
| <IntEx> "<" <IntEx>
| <IntEx> ">" <IntEx>
| <IntEx> "<=" <IntEx>
| <IntEx> ">=" <IntEx> ;
<IntRelExpr>:、: <IntEx>「=」<IntEx>。| 「<IntEx>!」 」 =<IntEx>。| <IntEx>"<"<IntEx>。| <IntEx>">"<IntEx>。| <IntEx>「<=」<IntEx>。| <IntEx>「>=」<IntEx>。
<FloatRelExpr>:: <FloatEx> "<" <FloatEx>
| <FloatEx> ">" <FloatEx>
| <FloatEx> "<=" <FloatEx>
| <FloatEx> ">=" <FloatEx> ;
<FloatRelExpr>:、: <FloatEx>"<"<FloatEx>。| <FloatEx>">"<FloatEx>。| <FloatEx>「<=」<FloatEx>。| <FloatEx>「>=」<FloatEx>。
<StringRelExpr>:: <StrEx> "==" <StrEx> /* String equality */
| <StrEx> "!=" <StrEx> /* String inequality */
| <StrEx> "<" <StrEx> /* Alphanum. comparisons */
| <StrEx> ">" <StrEx>
| <StrEx> "<=" <StrEx>
| <StrEx> ">=" <StrEx>
| <StrEx> "~=" <RegExpr> ; /* Reg. expr. matching */
<StringRelExpr>:、: <StrEx>「=」<StrEx>/*ストリング平等*/| 「<StrEx>!」 = 」 <StrEx>/*は不平等*/を結びます。| <StrEx>"<"<StrEx>/*Alphanum比較*/| <StrEx>">"<StrEx>。| <StrEx>「<=」<StrEx>。| <StrEx>「>=」<StrEx>。| 「<StrEx>」~、は」 <RegExpr>と等しいです。 /*レッジexpr合っている*/
<IntEx>:: <IntEx> "+" <IntEx> /* Integer */
| <IntEx> "-" <IntEx>
| <IntEx> "*" <IntEx>
| <IntEx> "/" <IntEx>
| <IntEx> "%" <IntEx>
| <IntEx> "^" <IntEx> /* Exponentiation */
| "-" <IntEx>
| "(" <IntEx> ")"
| <IntegerLiteral>
| "@" <StrEx> ;
<IntEx>:、: <IntEx>「+」<IntEx>/*整数*/| <IntEx>「-」<IntEx>。| <IntEx>「*」<IntEx>。| 」 「<IntEx>」/<IntEx>。| <IntEx>「%」<IntEx>。| <IntEx>"^"<IntEx>/*羃法*/| 「--」<IntEx>。| 「(「<IntEx>」)」| <IntegerLiteral>。| "@"<StrEx>。
<FloatEx>:: <FloatEx> "+" <FloatEx> /* Floating point */
| <FloatEx> "-" <FloatEx>
| <FloatEx> "*" <FloatEx>
| <FloatEx> "/" <FloatEx>
| <FloatEx> "^" <FloatEx> /* Exponentiation */
<FloatEx>:、: <FloatEx>「+」<FloatEx>/*浮動小数点*/| <FloatEx>「-」<FloatEx>。| <FloatEx>「*」<FloatEx>。| 」 「<FloatEx>」/<FloatEx>。| <FloatEx>"^"<FloatEx>/*羃法*/
Blaze, et al. Informational [Page 16] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[16ページ]のRFC2704基調信頼管理システム1999年9月
| "-" <FloatEx>
| "(" <FloatEx> ")"
| <FloatLiteral>
| "&" <StrEx> ;
| 「-」<FloatEx>。| 「(「<FloatEx>」)」| <FloatLiteral>。| "&"<StrEx>。
<IntegerLiteral>:: {Decimal number of at least one digit} ;
<FloatLiteral>:: <IntegerLiteral>"."<IntegerLiteral> ;
<IntegerLiteral>:、: 少なくとも1ケタの10進数。 <FloatLiteral>:、: 「<IntegerLiteral>」 「<IntegerLiteral>」。
<StringLiteral> is a quoted string as defined in Section 4.3
<AttributeID> is defined in Section 3.
<StringLiteral>によるセクション4.3<AttributeID>で定義される引用文字列がセクション3で定義されるということです。
The operation precedence classes are (from highest to lowest):
{ (, ) }
{unary -, @, &, $}
{^}
{*, /, %}
{+, -, .}
操作先行のクラスはこと(最も高いのから最も低くなるまで)です: ()、単項、-、@、$、^、*、/、%{+, -, .}
Operators in the same precedence class are evaluated left-to-right.
同じ先行のクラスのオペレータは、評価の左から右です。
Note the inability to test for floating point equality, as most floating point implementations (hardware or otherwise) do not guarantee accurate equality testing.
浮動小数点平等がないかどうかテストできないことに注意してください、ほとんどの浮動小数点実装(ハードウェアの、または、そうでない)が正確な平等テストを保証しないとき。
Also note that integer and floating point expressions can only be used within clauses of condition fields, but in no other KeyNote field.
また、状態分野の節にもかかわらず、他のどんなKeyNote分野でも整数と浮動小数点式を使用できるだけではないことに注意してください。
The keywords "true" and "false" are not reserved; they can be used as attribute or principal identifier names (although this practice makes assertions difficult to understand and is discouraged).
「本当である」というキーワードと「誤り」は予約されていません。 属性か主要な識別子名としてそれらを使用できます(この習慣は、主張を理解しているのを難しくして、がっかりしていますが)。
<RegExpr> is a standard regular expression, conforming to the POSIX 1003.2 regular expression syntax and semantics.
POSIX1003.2正規表現構文と意味論に従って、<RegExpr>は標準の正規表現です。
Any string expression (or attribute) containing the ASCII representation of a numeric value can be converted to an integer or float with the use of the "@" and "&" operators, respectively. Any fractional component of an attribute value dereferenced as an integer is rounded down. If an attribute dereferenced as a number cannot be properly converted (e.g., it contains invalid characters or is empty) its value is considered to be zero.
数値のASCII表現を含むどんなストリング式(または、属性)も、整数に変換されるか、または"@"と“&"の使用でそれぞれオペレータを広めることができます。 整数が概数に切り下げられるとき、属性値のどんな断片的なコンポーネントも「反-参照をつけ」ました。 属性が適切に数を変換できないように(例えば、それは、無効のキャラクタを含んでいるか、または空です)「反-参照をつけ」たなら、値はゼロであると考えられます。
Blaze, et al. Informational [Page 17] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[17ページ]のRFC2704基調信頼管理システム1999年9月
4.6.6 The Comment Field
4.6.6 注釈欄
The Comment field allows assertions to be annotated with information describing their purpose. It is of the form
Comment分野は、情報がそれらの目的について説明している状態で主張が注釈されるのを許容します。 それはフォームのものです。
<CommentField>:: "Comment:" <text> ;
<CommentField>:、: 「コメントしてください」 <テキスト>。
No interpretation of the contents of this field is performed by KeyNote. Note that this is one of two mechanisms for including comments in KeyNote assertions; comments can also be inserted anywhere in an assertion's body by preceding them with the "#" character (except inside string literals).
この分野のコンテンツの解釈は全くKeyNoteによって実行されません。 これがKeyNote主張におけるコメントを含むための2つのメカニズムの1つであるというメモ。 また、「#」キャラクタ(文字列リテラルを除いた)と共にそれらに先行することによって、主張のボディーでどこでもコメントを挿入できます。
4.6.7 The Signature Field
4.6.7 署名分野
The Signature field identifies a signed assertion and gives the encoded digital signature of the principal identified in the Authorizer field. The Signature field is of the form:
Signature分野は、署名している主張を特定して、Authorizer分野で特定された主体のコード化されたデジタル署名を与えます。 Signature分野はフォームのものです:
<SignatureField>:: "Signature:" <Signature> ;
<SignatureField>:、: 「署名:」 <署名>。
<Signature>:: <StrEx> ;
<署名>:、: <StrEx>。
The <Signature> string should be of the form:
<Signature>ストリングはフォームのものであるはずです:
<IDString>:: <ALGORITHM>":"<ENCODEDBITS> ;
<IDString>:、: 「<アルゴリズム>」: 「<ENCODEDBITS>」。
The formats of the "ALGORITHM" and "ENCODEDBITS" substrings are as described for Cryptographic Principal Identifiers in Section 4.4.2 The algorithm name should be the same as that of the principal appearing in the Authorizer field. The IANA (or some other suitable authority) will provide a registry of reserved names. It is not necessary that the encodings of the signature and the authorizer key be the same.
セクション4.4.2における暗号の主要な識別子のために説明されて、アルゴリズム名がAuthorizer分野に現れる主体のものと同じであるべきであるように「アルゴリズム」と「ENCODEDBITS」サブストリングの形式があります。 IANA(または、ある他の適当な権威)は予約された名前の登録を提供するでしょう。 署名のencodingsとauthorizerキーが同じであることは必要ではありません。
If the signature field is included, the principal named in the Authorizer field must be a Cryptographic Principal Identifier, the algorithm must be known to the KeyNote implementation, and the signature must be correct for the assertion body and authorizer key.
署名分野が含まれているなら、Authorizer分野で指定された主体はCryptographicプリンシパルIdentifierであるに違いありません、そして、KeyNote実装にアルゴリズムを知っていなければなりません、そして、主張本体とauthorizerキーに、署名は正しいに違いありません。
The signature is computed over the assertion text, beginning with the first field (including the field identifier string), up to (but not including) the Signature field identifier. The newline preceding the signature field identifier is the last character included in signature calculation. The signature is always the last field in a KeyNote assertion. Text following this field is not considered part of the assertion.
署名は主張テキストに関して計算されます、最初の分野で始まって(分野識別子ストリングを含んでいて)、(しかし、包含しない)Signature分野識別子まで。 署名分野識別子に先行するニューラインは署名計算に含まれていた最後のキャラクタです。 いつも署名はKeyNote主張で最後の分野です。 この野原に続くテキストは主張の一部であると考えられません。
Blaze, et al. Informational [Page 18] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[18ページ]のRFC2704基調信頼管理システム1999年9月
The algorithms for computing and verifying signatures must be configured into each KeyNote implementation and are defined and documented separately.
署名を計算して、確かめるためのアルゴリズムは、別々にそれぞれのKeyNote実装に構成しなければならなくて、定義されて、記録されます。
Note that all signatures used in examples in this document are fictitious and generally much shorter than would be required for security in practice.
例で使用されるすべての署名が本書では架空であって一般に、実際にはセキュリティのために必要とされるだろうよりはるかに不足していることに注意してください。
5. Query Evaluation Semantics
5. 質問評価意味論
The KeyNote compliance checker finds and returns the Policy Compliance Value of queries, as defined in Section 5.3, below.
KeyNote承諾市松模様は、以下のセクション5.3で定義されるように質問のPolicy Compliance Valueを見つけて、返します。
5.1 Query Parameters
5.1 質問パラメタ
A KeyNote query has four parameters:
KeyNote質問には、4つのパラメタがあります:
* The identifier of the principal(s) requesting the action.
* 動作を要求する校長の識別子。
* The action attribute set describing the action.
* 動作属性は、動作について説明しながら、セットしました。
* The set of compliance values of interest to the application,
ordered from _MIN_TRUST to _MAX_TRUST
* アプリケーションに興味があって、__MIN_TRUSTからマックス_TRUSTまで注文された承諾値のセット
* The policy and credential assertions that should be included in
the evaluation.
* 評価に含まれるべきである方針と資格証明主張。
The mechanism for passing these parameters to the KeyNote evaluator is application dependent. In particular, an evaluator might provide for some parameters to be passed explicitly, while others are looked up externally (e.g., credentials might be looked up in a network- based distribution system), while still others might be requested from the application as needed by the evaluator, through a `callback' mechanism (e.g., for attribute values that represent values from among a very large namespace).
これらのパラメタをKeyNote評価者に渡すためのメカニズムはアプリケーションに依存しています。 特に、評価者は明らかに通過されるためにいくつかのパラメタに備えるかもしれません、他のものが外部的に訪ねられますが(例えば資格証明書はネットワークのベースの流通制度で調べられるかもしれません)、それでも、他のものは必要に応じて評価者によってアプリケーションから要求されるかもしれませんが、'コールバック'メカニズム(例えば、非常に大きい名前空間から値を表す属性値のための)を通して。
5.1.1 Action Requester
5.1.1 動作リクエスタ
At least one Principal must be identified in each query as the `requester' of the action. Actions may be requested by several principals, each considered to have individually requested it. This allows policies that require multiple authorizations, e.g., `two person control'. The set of authorizing principals is made available in the special attribute "_ACTION_AUTHORIZERS"; if several principals are authorizers, their identifiers are separated with commas.
動作の'リクエスタ'として各質問で少なくとも1人のプリンシパルを特定しなければなりません。 動作は個別にそれを要求したとそれぞれ考えられたいくつかの主体によって要求されるかもしれません。 これは複数の承認を必要とする方針、例えば、'2人のコントロール'を許容します。 「主体を認可するセットを」 _特別な属性動作_AUTHORIZERSで利用可能にします」。 いくつかの主体がauthorizersであるなら、それらの識別子はコンマで切り離されます。
Blaze, et al. Informational [Page 19] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[19ページ]のRFC2704基調信頼管理システム1999年9月
5.1.2 Ordered Compliance Value Set
5.1.2 命令された承諾選択値群
The set of compliance values of interest to an application (and their
relative ranking to one another) is determined by the invoking
application and passed to the KeyNote evaluator as a parameter of the
query. In many applications, this will be Boolean, e.g., the ordered
sets {FALSE, TRUE} or {REJECT, APPROVE}. Other applications may
require a range of possible values, e.g., {No_Access, Limited_Access,
Full_Access}. Note that applications should include in this set only
compliance value names that are actually returned by the assertions.
アプリケーション(そして、彼らのお互いにとっての、幹部の親類)に興味がある承諾値のセットは、質問のパラメタとして呼び出しアプリケーションで決定して、KeyNote評価者に渡されます。 多くのアプリケーションでは、これがブールになる、例えば、命令はFALSE、TRUEかREJECT、APPROVEを設定します。 他のアプリケーションはさまざまな可能な値、いいえ_Access、株式会社_Access、例えばFull_Accessを必要とするかもしれません。 アプリケーションがこのセットだけに実際に主張で返される承諾値の名を含むべきであることに注意してください。
The lowest-order and highest-order compliance value strings given in the query are available in the special attributes named "_MIN_TRUST" and "_MAX_TRUST", respectively. The complete set of query compliance values is made available in ascending order (from _MIN_TRUST to _MAX_TRUST) in the special attribute named "_VALUES". Values are separated with commas; applications that use assertions that make use of the _VALUES attribute should therefore avoid the use of compliance value strings that themselves contain commas.
それぞれ「」 」 信頼_マックス_が信じる」_分_と命名されて、質問で与えられた最も少ない注文と最も高い注文承諾値のストリングは特別な属性で利用可能です」。 「」 _値という特別な属性で質問の完全な承諾値を昇順に利用可能にします(__MIN_TRUSTからマックス_TRUSTまで)。」 値はコンマで切り離されます。 したがって、_VALUES属性を利用する主張を使用するアプリケーションは自分たちでコンマを含む承諾値のストリングの使用を避けるべきです。
5.2 Principal Identifier Normalization
5.2 主要な識別子正常化
Principal identifier comparisons among Cryptographic Principal Identifiers (that represent keys) in the Authorizer and Licensees fields or in an action's direct authorizers are performed after normalizing them by conversion to a canonical form.
標準形への変換で彼らを正常にした後に、AuthorizerとLicensees分野か動作のダイレクトauthorizersのCryptographicプリンシパルIdentifiers(それはキーを表す)の中の主要な識別子比較は実行されます。
Every cryptographic algorithm used in KeyNote defines a method for converting keys to their canonical form and that specifies how the comparison for equality of two keys is performed. If the algorithm named in the identifier is unknown to KeyNote, the identifier is treated as opaque.
KeyNoteで使用されるあらゆる暗号アルゴリズムがそれらの標準形のキーを変換するためのメソッドを定義します、そして、それは2個のキーの平等のための比較がどう実行されるかを指定します。 KeyNoteにおいて、識別子で指定されたアルゴリズムが未知であるなら、識別子は不透明なものとして扱われます。
Opaque identifiers are compared as case-sensitive strings.
不明瞭な識別子は大文字と小文字を区別するストリングとして比較されます。
Notice that use of opaque identifiers in the Authorizer field requires that the assertion's integrity be locally trusted (since it cannot be cryptographically verified by the compliance checker).
Authorizer分野での不明瞭な識別子の使用が、主張の保全が局所的に信じられるのを必要とするのに注意してください(承諾市松模様が暗号でそれについて確かめることができないので)。
5.3 Policy Compliance Value Calculation
5.3 方針承諾値の計算
The Policy Compliance Value of a query is the Principal Compliance Value of the principal named "POLICY". This value is defined as follows:
質問のPolicy Compliance Valueは「方針」という主体のプリンシパルCompliance Valueです。 この値は以下の通り定義されます:
Blaze, et al. Informational [Page 20] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[20ページ]のRFC2704基調信頼管理システム1999年9月
5.3.1 Principal Compliance Value
5.3.1 主要な承諾値
The Compliance Value of a principal <X> is the highest order (maximum) of:
主要な<X>のCompliance Valueは以下の最も高い注文(最大の)です。
- the Direct Authorization Value of principal <X>; and
- 主要な<X>のDirect Authorization Value。 そして
- the Assertion Compliance Values of all assertions identifying
<X> in the Authorizer field.
- Authorizer分野で<X>を特定するすべての主張のAssertion Compliance Values。
5.3.2 Direct Authorization Value
5.3.2 ダイレクト認証値
The Direct Authorization Value of a principal <X> is _MAX_TRUST if <X> is listed in the query as an authorizer of the action. Otherwise, the Direct Authorization Value of <X> is _MIN_TRUST.
主体<X>のDirect Authorization Valueはそうです。_マックス_TRUSTは<X>であるなら動作のauthorizerとして質問で記載されます。 さもなければ、<X>のDirect Authorization Valueは_MIN_TRUSTです。
5.3.3 Assertion Compliance Value
5.3.3 主張承諾価値
The Assertion Compliance Value of an assertion is the lowest order (minimum) of the assertion's Conditions Compliance Value and its Licensee Compliance Value.
主張のAssertion Compliance Valueは主張のConditions Compliance ValueとそのLicensee Compliance Valueの最も少ない注文(最小の)です。
5.3.4 Conditions Compliance Value
5.3.4 状態承諾価値
The Conditions Compliance Value of an assertion is the highest-order (maximum) value among all successful clauses listed in the conditions section.
主張のConditions Compliance Valueは状態部でリストアップされたすべてのうまくいっている節の中の最も高いオーダーの(最大)の値です。
If no clause's test succeeds or the Conditions field is empty, an assertion's Conditions Compliance Value is considered to be the _MIN_TRUST value, as defined Section 5.1.
節がないことのテストが成功するか、またはConditions分野が人影がないなら、主張のConditions Compliance Valueは_MIN_TRUST価値であると考えられます、定義されたセクション5.1として。
If an assertion's Conditions field is missing entirely, its Conditions Compliance Value is considered to be the _MAX_TRUST value, as defined in Section 5.1.
主張のConditions分野が完全になくなるなら、Conditions Compliance Valueは_マックス_TRUST価値であると考えられます、セクション5.1で定義されるように。
The set of successful test clause values is calculated as follows:
うまくいったテスト節値のセットは以下の通り計算されます:
Recall from the grammar of section 4.6.5 that each clause in the conditions section has two logical parts: a `test' and an optional `value', which, if present, is separated from the test with the "->" token. The test subclause is a predicate that either succeeds (evaluates to logical `true') or fails (evaluates to logical `false'). The value subclause is a string expression that evaluates to one value from the ordered set of compliance values given with the query. If the value subclause is missing, it is considered to be _MAX_TRUST. That is, the clause
Recall from the grammar of section 4.6.5 that each clause in the conditions section has two logical parts: a `test' and an optional `value', which, if present, is separated from the test with the "->" token. The test subclause is a predicate that either succeeds (evaluates to logical `true') or fails (evaluates to logical `false'). The value subclause is a string expression that evaluates to one value from the ordered set of compliance values given with the query. If the value subclause is missing, it is considered to be _MAX_TRUST. That is, the clause
Blaze, et al. Informational [Page 21] RFC 2704 The KeyNote Trust-Management System September 1999
Blaze, et al. Informational [Page 21] RFC 2704 The KeyNote Trust-Management System September 1999
foo=="bar";
foo=="bar";
is equivalent to
is equivalent to
foo=="bar" -> _MAX_TRUST;
foo=="bar" -> _MAX_TRUST;
If the value component of a clause is present, in the simplest case it contains a string expression representing a possible compliance value. For example, consider an assertion with the following Conditions field:
If the value component of a clause is present, in the simplest case it contains a string expression representing a possible compliance value. For example, consider an assertion with the following Conditions field:
Conditions:
@user_id == 0 -> "full_access"; # clause (1)
@user_id < 1000 -> "user_access"; # clause (2)
@user_id < 10000 -> "guest_access"; # clause (3)
user_name == "root" -> "full_access"; # clause (4)
Conditions: @user_id == 0 -> "full_access"; # clause (1) @user_id < 1000 -> "user_access"; # clause (2) @user_id < 10000 -> "guest_access"; # clause (3) user_name == "root" -> "full_access"; # clause (4)
Here, if the value of the "user_id" attribute is "1073" and the
"user_name" attribute is "root", the possible compliance value set
would contain the values "guest_access" (by clause (3)) and
"full_access" (by clause (4)). If the ordered set of compliance
values given in the query (in ascending order) is {"no_access",
"guest_access", "user_access", "full_access"}, the Conditions
Compliance Value of the assertion would be "full_access" (because
"full_access" has a higher-order value than "guest_access"). If the
"user_id" attribute had the value "19283" and the "user_name"
attribute had the value "nobody", no clause would succeed and the
Conditions Compliance Value would be "no_access", which is the
lowest-order possible value (_MIN_TRUST).
Here, if the value of the "user_id" attribute is "1073" and the "user_name" attribute is "root", the possible compliance value set would contain the values "guest_access" (by clause (3)) and "full_access" (by clause (4)). If the ordered set of compliance values given in the query (in ascending order) is {"no_access", "guest_access", "user_access", "full_access"}, the Conditions Compliance Value of the assertion would be "full_access" (because "full_access" has a higher-order value than "guest_access"). If the "user_id" attribute had the value "19283" and the "user_name" attribute had the value "nobody", no clause would succeed and the Conditions Compliance Value would be "no_access", which is the lowest-order possible value (_MIN_TRUST).
If a clause lists an explicit value, its value string must be named in the query ordered compliance value set. Values not named in the query compliance value set are considered equivalent to _MIN_TRUST.
If a clause lists an explicit value, its value string must be named in the query ordered compliance value set. Values not named in the query compliance value set are considered equivalent to _MIN_TRUST.
The value component of a clause can also contain recursively-nested clauses. Recursively-nested clauses are evaluated only if their parent test is true. That is,
The value component of a clause can also contain recursively-nested clauses. Recursively-nested clauses are evaluated only if their parent test is true. That is,
a=="b" -> { b=="c" -> "value1";
d=="e" -> "value2";
true -> "value3"; } ;
a=="b" -> { b=="c" -> "value1"; d=="e" -> "value2"; true -> "value3"; } ;
is equivalent to
is equivalent to
(a=="b") && (b=="c") -> "value1";
(a=="b") && (d=="e") -> "value2";
(a=="b") -> "value3";
(a=="b") && (b=="c") -> "value1"; (a=="b") && (d=="e") -> "value2"; (a=="b") -> "value3";
Blaze, et al. Informational [Page 22] RFC 2704 The KeyNote Trust-Management System September 1999
Blaze, et al. Informational [Page 22] RFC 2704 The KeyNote Trust-Management System September 1999
String comparisons are case-sensitive.
String comparisons are case-sensitive.
A regular expression comparison ("~=") is considered true if the
left-hand-side string expression matches the right-hand-side regular
expression. If the POSIX regular expression group matching scheme is
used, the number of groups matched is placed in the temporary meta-
attribute "_0" (dereferenced as _0), and each match is placed in
sequence in the temporary attributes (_1, _2, ..., _N). These
match-attributes' values are valid only within subsequent references
made within the same clause. Regular expression evaluation is case-
sensitive.
A regular expression comparison ("~=") is considered true if the left-hand-side string expression matches the right-hand-side regular expression. If the POSIX regular expression group matching scheme is used, the number of groups matched is placed in the temporary meta- attribute "_0" (dereferenced as _0), and each match is placed in sequence in the temporary attributes (_1, _2, ..., _N). These match-attributes' values are valid only within subsequent references made within the same clause. Regular expression evaluation is case- sensitive.
A runtime error occurring in the evaluation of a test, such as division by zero or an invalid regular expression, causes the test to be considered false. For example:
A runtime error occurring in the evaluation of a test, such as division by zero or an invalid regular expression, causes the test to be considered false. For example:
foo == "bar" -> {
@a == 1/0 -> "oneval"; # subclause 1
@a == 2 -> "anotherval"; # subclause 2
};
foo == "bar" -> { @a == 1/0 -> "oneval"; # subclause 1 @a == 2 -> "anotherval"; # subclause 2 };
Here, subclause 1 triggers a runtime error. Subclause 1 is therefore false (and has the value _MIN_TRUST). Subclause 2, however, would be evaluated normally.
Here, subclause 1 triggers a runtime error. Subclause 1 is therefore false (and has the value _MIN_TRUST). Subclause 2, however, would be evaluated normally.
An invalid <RegExpr> is considered a runtime error and causes the test in which it occurs to be considered false.
An invalid <RegExpr> is considered a runtime error and causes the test in which it occurs to be considered false.
5.3.5 Licensee Compliance Value
5.3.5 Licensee Compliance Value
The Licensee Compliance Value of an assertion is calculated by evaluating the expression in the Licensees field, based on the Principal Compliance Value of the principals named there.
The Licensee Compliance Value of an assertion is calculated by evaluating the expression in the Licensees field, based on the Principal Compliance Value of the principals named there.
If an assertion's Licensees field is empty, its Licensee Compliance Value is considered to be _MIN_TRUST. If an assertion's Licensees field is missing altogether, its Licensee Compliance Value is considered to be _MAX_TRUST.
If an assertion's Licensees field is empty, its Licensee Compliance Value is considered to be _MIN_TRUST. If an assertion's Licensees field is missing altogether, its Licensee Compliance Value is considered to be _MAX_TRUST.
For each principal named in the Licensees field, its Principal Compliance Value is substituted for its name. If no Principal Compliance Value can be found for some named principal, its name is substituted with the _MIN_TRUST value.
For each principal named in the Licensees field, its Principal Compliance Value is substituted for its name. If no Principal Compliance Value can be found for some named principal, its name is substituted with the _MIN_TRUST value.
The licensees expression (as defined in Section 4.6.4) is evaluated as follows:
The licensees expression (as defined in Section 4.6.4) is evaluated as follows:
Blaze, et al. Informational [Page 23] RFC 2704 The KeyNote Trust-Management System September 1999
Blaze, et al. Informational [Page 23] RFC 2704 The KeyNote Trust-Management System September 1999
* A "(...)" expression has the value of the enclosed subexpression.
* A "(...)" expression has the value of the enclosed subexpression.
* A "&&" expression has the lower-order (minimum) of its two
subexpression values.
* A "&&" expression has the lower-order (minimum) of its two subexpression values.
* A "||" expression has the higher-order (maximum) of its two
subexpression values.
* A "||" expression has the higher-order (maximum) of its two subexpression values.
* A "<K>-of(<List>)" expression has the K-th highest order
compliance value listed in <list>. Values that appear multiple
times are counted with multiplicity. For example, if K = 3 and
the orders of the listed compliance values are (0, 1, 2, 2, 3),
the value of the expression is the compliance value of order 2.
* A "<K>-of(<List>)" expression has the K-th highest order compliance value listed in <list>. Values that appear multiple times are counted with multiplicity. For example, if K = 3 and the orders of the listed compliance values are (0, 1, 2, 2, 3), the value of the expression is the compliance value of order 2.
For example, consider the following Licensees field:
For example, consider the following Licensees field:
Licensees: ("alice" && "bob") || "eve"
Licensees: ("alice" && "bob") || "eve"
If the Principal Compliance Value is "yes" for principal "alice", "no" for principal "bob", and "no" for principal "eve", and "yes" is higher order than "no" in the query's Compliance Value Set, then the resulting Licensee Compliance Value is "no".
If the Principal Compliance Value is "yes" for principal "alice", "no" for principal "bob", and "no" for principal "eve", and "yes" is higher order than "no" in the query's Compliance Value Set, then the resulting Licensee Compliance Value is "no".
Observe that if there are exactly two possible compliance values (e.g., "false" and "true"), the rules of Licensee Compliance Value resolution reduce exactly to standard Boolean logic.
Observe that if there are exactly two possible compliance values (e.g., "false" and "true"), the rules of Licensee Compliance Value resolution reduce exactly to standard Boolean logic.
5.4 Assertion Management
5.4 Assertion Management
Assertions may be either signed or unsigned. Only signed assertions should be used as credentials or transmitted or stored on untrusted media. Unsigned assertions should be used only to specify policy and for assertions whose integrity has already been verified as conforming to local policy by some mechanism external to the KeyNote system itself (e.g., X.509 certificates converted to KeyNote assertions by a trusted conversion program).
Assertions may be either signed or unsigned. Only signed assertions should be used as credentials or transmitted or stored on untrusted media. Unsigned assertions should be used only to specify policy and for assertions whose integrity has already been verified as conforming to local policy by some mechanism external to the KeyNote system itself (e.g., X.509 certificates converted to KeyNote assertions by a trusted conversion program).
Implementations that permit signed credentials to be verified by the KeyNote compliance checker generally provide two `channels' through which applications can make assertions available. Unsigned, locally-trusted assertions are provided over a `trusted' interface, while signed credentials are provided over an `untrusted' interface. The KeyNote compliance checker verifies correct signatures for all assertions submitted over the untrusted interface. The integrity of KeyNote evaluation requires that only assertions trusted as reflecting local policy are submitted to KeyNote via the trusted interface.
Implementations that permit signed credentials to be verified by the KeyNote compliance checker generally provide two `channels' through which applications can make assertions available. Unsigned, locally-trusted assertions are provided over a `trusted' interface, while signed credentials are provided over an `untrusted' interface. The KeyNote compliance checker verifies correct signatures for all assertions submitted over the untrusted interface. The integrity of KeyNote evaluation requires that only assertions trusted as reflecting local policy are submitted to KeyNote via the trusted interface.
Blaze, et al. Informational [Page 24] RFC 2704 The KeyNote Trust-Management System September 1999
Blaze, et al. Informational [Page 24] RFC 2704 The KeyNote Trust-Management System September 1999
Note that applications that use KeyNote exclusively as a local policy specification mechanism need use only trusted assertions. Other applications might need only a small number of infrequently changed trusted assertions to `bootstrap' a policy whose details are specified in signed credentials issued by others and submitted over the untrusted interface.
Note that applications that use KeyNote exclusively as a local policy specification mechanism need use only trusted assertions. Other applications might need only a small number of infrequently changed trusted assertions to `bootstrap' a policy whose details are specified in signed credentials issued by others and submitted over the untrusted interface.
5.5 Implementation Issues
5.5 Implementation Issues
Informally, the semantics of KeyNote evaluation can be thought of as involving the construction a directed graph of KeyNote assertions rooted at a POLICY assertion that connects with at least one of the principals that requested the action.
Informally, the semantics of KeyNote evaluation can be thought of as involving the construction a directed graph of KeyNote assertions rooted at a POLICY assertion that connects with at least one of the principals that requested the action.
Delegation of some authorization from principal <A> to a set of principals <B> is expressed as an assertion with principal <A> given in the Authorizer field, principal set <B> given in the Licensees field, and the authorization to be delegated encoded in the Conditions field. How the expression digraph is constructed is implementation-dependent and implementations may use different algorithms for optimizing the graph's construction. Some implementations might use a `bottom up' traversal starting at the principals that requested the action, others might follow a `top down' approach starting at the POLICY assertions, and still others might employ other heuristics entirely.
Delegation of some authorization from principal <A> to a set of principals <B> is expressed as an assertion with principal <A> given in the Authorizer field, principal set <B> given in the Licensees field, and the authorization to be delegated encoded in the Conditions field. How the expression digraph is constructed is implementation-dependent and implementations may use different algorithms for optimizing the graph's construction. Some implementations might use a `bottom up' traversal starting at the principals that requested the action, others might follow a `top down' approach starting at the POLICY assertions, and still others might employ other heuristics entirely.
Implementations are encouraged to employ mechanisms for recording exceptions (such as division by zero or syntax error), and reporting them to the invoking application if requested. Such mechanisms are outside the scope of this document.
Implementations are encouraged to employ mechanisms for recording exceptions (such as division by zero or syntax error), and reporting them to the invoking application if requested. Such mechanisms are outside the scope of this document.
6. Examples
6. Examples
In this section, we give examples of KeyNote assertions that might be used in hypothetical applications. These examples are intended primarily to illustrate features of KeyNote assertion syntax and semantics, and do not necessarily represent the best way to integrate KeyNote into applications.
In this section, we give examples of KeyNote assertions that might be used in hypothetical applications. These examples are intended primarily to illustrate features of KeyNote assertion syntax and semantics, and do not necessarily represent the best way to integrate KeyNote into applications.
In the interest of readability, we use much shorter keys than would ordinarily be used in practice. Note that the Signature fields in these examples do not represent the result of any real signature calculation.
In the interest of readability, we use much shorter keys than would ordinarily be used in practice. Note that the Signature fields in these examples do not represent the result of any real signature calculation.
Blaze, et al. Informational [Page 25] RFC 2704 The KeyNote Trust-Management System September 1999
Blaze, et al. Informational [Page 25] RFC 2704 The KeyNote Trust-Management System September 1999
1. TRADITIONAL CA / EMAIL
1. TRADITIONAL CA / EMAIL
A. A policy unconditionally authorizing RSA key abc123 for all
actions. This essentially defers the ability to specify
policy to the holder of the secret key corresponding to
abc123:
A. A policy unconditionally authorizing RSA key abc123 for all actions. This essentially defers the ability to specify policy to the holder of the secret key corresponding to abc123:
Authorizer: "POLICY"
Licensees: "RSA:abc123"
Authorizer: "POLICY" Licensees: "RSA:abc123"
B. A credential assertion in which RSA Key abc123 trusts either
RSA key 4401ff92 (called `Alice') or DSA key d1234f (called
`Bob') to perform actions in which the "app_domain" is
"RFC822-EMAIL", where the "address" matches the regular
expression "^.*@keynote\.research\.att\.com$". In other
words, abc123 trusts Alice and Bob as certification
authorities for the keynote.research.att.com domain.
B. A credential assertion in which RSA Key abc123 trusts either RSA key 4401ff92 (called `Alice') or DSA key d1234f (called `Bob') to perform actions in which the "app_domain" is "RFC822-EMAIL", where the "address" matches the regular expression "^.*@keynote\.research\.att\.com$". In other words, abc123 trusts Alice and Bob as certification authorities for the keynote.research.att.com domain.
KeyNote-Version: 2
Local-Constants: Alice="DSA:4401ff92" # Alice's key
Bob="RSA:d1234f" # Bob's key
Authorizer: "RSA:abc123"
Licensees: Alice || Bob
Conditions: (app_domain == "RFC822-EMAIL") &&
(address ~= # only applies to one domain
"^.*@keynote\\.research\\.att\\.com$");
Signature: "RSA-SHA1:213354f9"
KeyNote-Version: 2 Local-Constants: Alice="DSA:4401ff92" # Alice's key Bob="RSA:d1234f" # Bob's key Authorizer: "RSA:abc123" Licensees: Alice || Bob Conditions: (app_domain == "RFC822-EMAIL") && (address ~= # only applies to one domain "^.*@keynote\\.research\\.att\\.com$"); Signature: "RSA-SHA1:213354f9"
C. A certificate credential for a specific user whose email
address is mab@keynote.research.att.com and whose name, if
present, must be "M. Blaze". The credential was issued by the
`Alice' authority (whose key is certified in Example B
above):
C. A certificate credential for a specific user whose email address is mab@keynote.research.att.com and whose name, if present, must be "M. Blaze". The credential was issued by the `Alice' authority (whose key is certified in Example B above):
KeyNote-Version: 2
Authorizer: "DSA:4401ff92" # the Alice CA
Licensees: "DSA:12340987" # mab's key
Conditions: ((app_domain == "RFC822-EMAIL") &&
(name == "M. Blaze" || name == "") &&
(address == "mab@keynote.research.att.com"));
Signature: "DSA-SHA1:ab23487"
KeyNote-Version: 2 Authorizer: "DSA:4401ff92" # the Alice CA Licensees: "DSA:12340987" # mab's key Conditions: ((app_domain == "RFC822-EMAIL") && (name == "M. Blaze" || name == "") && (address == "mab@keynote.research.att.com")); Signature: "DSA-SHA1:ab23487"
Blaze, et al. Informational [Page 26] RFC 2704 The KeyNote Trust-Management System September 1999
Blaze, et al. Informational [Page 26] RFC 2704 The KeyNote Trust-Management System September 1999
D. Another certificate credential for a specific user, also
issued by the `Alice' authority. This example allows three
different keys to sign as jf@keynote.research.att.com (each
for a different cryptographic algorithm). This is, in
effect, three credentials in one:
D. Another certificate credential for a specific user, also issued by the `Alice' authority. This example allows three different keys to sign as jf@keynote.research.att.com (each for a different cryptographic algorithm). This is, in effect, three credentials in one:
KeyNote-Version: "2"
Authorizer: "DSA:4401ff92" # the Alice CA
Licensees: "DSA:abc991" || # jf's DSA key
"RSA:cde773" || # jf's RSA key
"BFIK:fd091a" # jf's BFIK key
Conditions: ((app_domain == "RFC822-EMAIL") &&
(name == "J. Feigenbaum" || name == "") &&
(address == "jf@keynote.research.att.com"));
Signature: "DSA-SHA1:8912aa"
KeyNote-Version: "2" Authorizer: "DSA:4401ff92" # the Alice CA Licensees: "DSA:abc991" || # jf's DSA key "RSA:cde773" || # jf's RSA key "BFIK:fd091a" # jf's BFIK key Conditions: ((app_domain == "RFC822-EMAIL") && (name == "J. Feigenbaum" || name == "") && (address == "jf@keynote.research.att.com")); Signature: "DSA-SHA1:8912aa"
Observe that under policy A and credentials B, C and D, the
following action attribute sets are accepted (they return
_MAX_TRUST):
Observe that under policy A and credentials B, C and D, the following action attribute sets are accepted (they return _MAX_TRUST):
_ACTION_AUTHORIZERS = "dsa:12340987"
app_domain = "RFC822-EMAIL"
address = "mab@keynote.research.att.com"
and
_ACTION_AUTHORIZERS = "dsa:12340987"
app_domain = "RFC822-EMAIL"
address = "mab@keynote.research.att.com"
name = "M. Blaze"
_ACTION_AUTHORIZERS = "dsa:12340987" app_domain = "RFC822-EMAIL" address = "mab@keynote.research.att.com" and _ACTION_AUTHORIZERS = "dsa:12340987" app_domain = "RFC822-EMAIL" address = "mab@keynote.research.att.com" name = "M. Blaze"
while the following are not accepted (they return
_MIN_TRUST):
while the following are not accepted (they return _MIN_TRUST):
_ACTION_AUTHORIZERS = "dsa:12340987"
app_domain = "RFC822-EMAIL"
address = "angelos@dsl.cis.upenn.edu"
and
_ACTION_AUTHORIZERS = "dsa:abc991"
app_domain = "RFC822-EMAIL"
address = "mab@keynote.research.att.com"
name = "M. Blaze"
and
_ACTION_AUTHORIZERS = "dsa:12340987"
app_domain = "RFC822-EMAIL"
address = "mab@keynote.research.att.com"
name = "J. Feigenbaum"
_ACTION_AUTHORIZERS = "dsa:12340987" app_domain = "RFC822-EMAIL" address = "angelos@dsl.cis.upenn.edu" and _ACTION_AUTHORIZERS = "dsa:abc991" app_domain = "RFC822-EMAIL" address = "mab@keynote.research.att.com" name = "M. Blaze" and _ACTION_AUTHORIZERS = "dsa:12340987" app_domain = "RFC822-EMAIL" address = "mab@keynote.research.att.com" name = "J. Feigenbaum"
Blaze, et al. Informational [Page 27] RFC 2704 The KeyNote Trust-Management System September 1999
Blaze, et al. Informational [Page 27] RFC 2704 The KeyNote Trust-Management System September 1999
2. WORKFLOW/ELECTRONIC COMMERCE
2. WORKFLOW/ELECTRONIC COMMERCE
E. A policy that delegates authority for the "SPEND" application
domain to RSA key dab212 when the amount given in the
"dollars" attribute is less than 10000.
E. A policy that delegates authority for the "SPEND" application domain to RSA key dab212 when the amount given in the "dollars" attribute is less than 10000.
Authorizer: "POLICY"
Licensees: "RSA:dab212" # the CFO's key
Conditions: (app_domain=="SPEND") && (@dollars < 10000);
Authorizer: "POLICY" Licensees: "RSA:dab212" # the CFO's key Conditions: (app_domain=="SPEND") && (@dollars < 10000);
F. RSA key dab212 delegates authorization to any two signers,
from a list, one of which must be DSA key feed1234 in the
"SPEND" application when @dollars < 7500. If the amount in
@dollars is 2500 or greater, the request is approved but
logged.
F. RSA key dab212 delegates authorization to any two signers, from a list, one of which must be DSA key feed1234 in the "SPEND" application when @dollars < 7500. If the amount in @dollars is 2500 or greater, the request is approved but logged.
KeyNote-Version: 2
Comment: This credential specifies a spending policy
Authorizer: "RSA:dab212" # the CFO
Licensees: "DSA:feed1234" && # The vice president
("RSA:abc123" || # middle manager #1
"DSA:bcd987" || # middle manager #2
"DSA:cde333" || # middle manager #3
"DSA:def975" || # middle manager #4
"DSA:978add") # middle manager #5
Conditions: (app_domain=="SPEND") # note nested clauses
-> { (@(dollars) < 2500)
-> _MAX_TRUST;
(@(dollars) < 7500)
-> "ApproveAndLog";
};
Signature: "RSA-SHA1:9867a1"
KeyNote-Version: 2 Comment: This credential specifies a spending policy Authorizer: "RSA:dab212" # the CFO Licensees: "DSA:feed1234" && # The vice president ("RSA:abc123" || # middle manager #1 "DSA:bcd987" || # middle manager #2 "DSA:cde333" || # middle manager #3 "DSA:def975" || # middle manager #4 "DSA:978add") # middle manager #5 Conditions: (app_domain=="SPEND") # note nested clauses -> { (@(dollars) < 2500) -> _MAX_TRUST; (@(dollars) < 7500) -> "ApproveAndLog"; }; Signature: "RSA-SHA1:9867a1"
G. According to this policy, any two signers from the list of
managers will do if @(dollars) < 1000:
G. According to this policy, any two signers from the list of managers will do if @(dollars) < 1000:
KeyNote-Version: 2
Authorizer: "POLICY"
Licensees: 2-of("DSA:feed1234", # The VP
"RSA:abc123", # Middle management clones
"DSA:bcd987",
"DSA:cde333",
"DSA:def975",
"DSA:978add")
Conditions: (app_domain=="SPEND") &&
(@(dollars) < 1000);
KeyNote-Version: 2 Authorizer: "POLICY" Licensees: 2-of("DSA:feed1234", # The VP "RSA:abc123", # Middle management clones "DSA:bcd987", "DSA:cde333", "DSA:def975", "DSA:978add") Conditions: (app_domain=="SPEND") && (@(dollars) < 1000);
Blaze, et al. Informational [Page 28] RFC 2704 The KeyNote Trust-Management System September 1999
Blaze, et al. Informational [Page 28] RFC 2704 The KeyNote Trust-Management System September 1999
H. A credential from dab212 with a similar policy, but only one
signer is required if @(dollars) < 500. A log entry is made if
the amount is at least 100.
H. A credential from dab212 with a similar policy, but only one signer is required if @(dollars) < 500. A log entry is made if the amount is at least 100.
KeyNote-Version: 2
Comment: This one credential is equivalent to six separate
credentials, one for each VP and middle manager.
Individually, they can spend up to $500, but if
it's $100 or more, we log it.
Authorizer: "RSA:dab212" # From the CFO
Licensees: "DSA:feed1234" || # The VP
"RSA:abc123" || # The middle management clones
"DSA:bcd987" ||
"DSA:cde333" ||
"DSA:def975" ||
"DSA:978add"
Conditions: (app_domain="SPEND") # nested clauses
-> { (@(dollars) < 100) -> _MAX_TRUST;
(@(dollars) < 500) -> "ApproveAndLog";
};
Signature: "RSA-SHA1:186123"
KeyNote-Version: 2 Comment: This one credential is equivalent to six separate credentials, one for each VP and middle manager. Individually, they can spend up to $500, but if it's $100 or more, we log it. Authorizer: "RSA:dab212" # From the CFO Licensees: "DSA:feed1234" || # The VP "RSA:abc123" || # The middle management clones "DSA:bcd987" || "DSA:cde333" || "DSA:def975" || "DSA:978add" Conditions: (app_domain="SPEND") # nested clauses -> { (@(dollars) < 100) -> _MAX_TRUST; (@(dollars) < 500) -> "ApproveAndLog"; }; Signature: "RSA-SHA1:186123"
Assume a query in which the ordered set of Compliance Values is
{"Reject", "ApproveAndLog", "Approve"}. Under policies E and G,
and credentials F and H, the Policy Compliance Value is
"Approve" (_MAX_TRUST) when:
Assume a query in which the ordered set of Compliance Values is {"Reject", "ApproveAndLog", "Approve"}. Under policies E and G, and credentials F and H, the Policy Compliance Value is "Approve" (_MAX_TRUST) when:
_ACTION_AUTHORIZERS = "DSA:978add"
app_domain = "SPEND"
dollars = "45"
unmentioned_attribute = "whatever"
and
_ACTION_AUTHORIZERS = "RSA:abc123,DSA:cde333"
app_domain = "SPEND"
dollars = "550"
_ACTION_AUTHORIZERS = "DSA:978add" app_domain = "SPEND" dollars = "45" unmentioned_attribute = "whatever" and _ACTION_AUTHORIZERS = "RSA:abc123,DSA:cde333" app_domain = "SPEND" dollars = "550"
The following return "ApproveAndLog":
The following return "ApproveAndLog":
_ACTION_AUTHORIZERS = "DSA:feed1234,DSA:cde333"
app_domain = "SPEND"
dollars = "5500"
and
_ACTION_AUTHORIZERS = "DSA:cde333"
app_domain = "SPEND"
dollars = "150"
_ACTION_AUTHORIZERS = "DSA:feed1234,DSA:cde333" app_domain = "SPEND" dollars = "5500" and _ACTION_AUTHORIZERS = "DSA:cde333" app_domain = "SPEND" dollars = "150"
Blaze, et al. Informational [Page 29] RFC 2704 The KeyNote Trust-Management System September 1999
Blaze, et al. Informational [Page 29] RFC 2704 The KeyNote Trust-Management System September 1999
However, the following return "Reject" (_MIN_TRUST):
However, the following return "Reject" (_MIN_TRUST):
_ACTION_AUTHORIZERS = "DSA:def975"
app_domain = "SPEND"
dollars = "550"
and
_ACTION_AUTHORIZERS = "DSA:cde333,DSA:978add"
app_domain = "SPEND"
dollars = "5500"
_ACTION_AUTHORIZERS = "DSA:def975" app_domain = "SPEND" dollars = "550" and _ACTION_AUTHORIZERS = "DSA:cde333,DSA:978add" app_domain = "SPEND" dollars = "5500"
7. Trust-Management Architecture
7. Trust-Management Architecture
KeyNote provides a simple mechanism for describing security policy and representing credentials. It differs from traditional certification systems in that the security model is based on binding keys to predicates that describe what the key is authorized by policy to do, rather than on resolving names. The infrastructure and architecture to support a KeyNote system is therefore rather different from that required for a name-based certification scheme. The KeyNote trust-management architecture is based on that of PolicyMaker [BFL96,BFS98].
KeyNote provides a simple mechanism for describing security policy and representing credentials. It differs from traditional certification systems in that the security model is based on binding keys to predicates that describe what the key is authorized by policy to do, rather than on resolving names. The infrastructure and architecture to support a KeyNote system is therefore rather different from that required for a name-based certification scheme. The KeyNote trust-management architecture is based on that of PolicyMaker [BFL96,BFS98].
It is important to understand the separation between the responsibilities of the KeyNote system and those of the application and other support infrastructure. A KeyNote compliance checker will determine, based on policy and credential assertions, whether a proposed action is permitted according to policy. The usefulness of KeyNote output as a policy enforcement mechanism depends on a number of factors:
It is important to understand the separation between the responsibilities of the KeyNote system and those of the application and other support infrastructure. A KeyNote compliance checker will determine, based on policy and credential assertions, whether a proposed action is permitted according to policy. The usefulness of KeyNote output as a policy enforcement mechanism depends on a number of factors:
* The action attributes and the assignment of their values must
reflect accurately the security requirements of the application.
Identifying the attributes to include in the action attribute set
is perhaps the most important task in integrating KeyNote into new
applications.
* The action attributes and the assignment of their values must reflect accurately the security requirements of the application. Identifying the attributes to include in the action attribute set is perhaps the most important task in integrating KeyNote into new applications.
* The policy of the application must be correct and well-formed. In
particular, trust must be deferred only to principals that should,
in fact, be trusted by the application.
* The policy of the application must be correct and well-formed. In particular, trust must be deferred only to principals that should, in fact, be trusted by the application.
* The application itself must be trustworthy. KeyNote does not
directly enforce policy; it only provides advice to the
applications that call it. In other words, KeyNote assumes that
the application itself is trusted and that the policy assertions
it specifies are correct. Nothing prevents an application from
submitting misleading or incorrect assertions to KeyNote or from
ignoring KeyNote altogether.
* The application itself must be trustworthy. KeyNote does not directly enforce policy; it only provides advice to the applications that call it. In other words, KeyNote assumes that the application itself is trusted and that the policy assertions it specifies are correct. Nothing prevents an application from submitting misleading or incorrect assertions to KeyNote or from ignoring KeyNote altogether.
Blaze, et al. Informational [Page 30] RFC 2704 The KeyNote Trust-Management System September 1999
Blaze, et al. Informational [Page 30] RFC 2704 The KeyNote Trust-Management System September 1999
It is also up to the application (or some service outside KeyNote) to select the appropriate credentials and policy assertions with which to run a particular query. Note, however, that even if inappropriate credentials are provided to KeyNote, this cannot result in the approval of an illegal action (as long as the policy assertions are correct and the the action attribute set itself is correctly passed to KeyNote).
It is also up to the application (or some service outside KeyNote) to select the appropriate credentials and policy assertions with which to run a particular query. Note, however, that even if inappropriate credentials are provided to KeyNote, this cannot result in the approval of an illegal action (as long as the policy assertions are correct and the the action attribute set itself is correctly passed to KeyNote).
KeyNote is monotonic; adding an assertion to a query can never result in a query's having a lower compliance value that it would have had without the assertion. Omitting credentials may, of course, result in legal actions being disallowed. Selecting appropriate credentials (e.g., from a distributed database or `key server') is outside the scope of the KeyNote language and may properly be handled by a remote client making a request, by the local application receiving the request, or by a network-based service, depending on the application.
KeyNote is monotonic; adding an assertion to a query can never result in a query's having a lower compliance value that it would have had without the assertion. Omitting credentials may, of course, result in legal actions being disallowed. Selecting appropriate credentials (e.g., from a distributed database or `key server') is outside the scope of the KeyNote language and may properly be handled by a remote client making a request, by the local application receiving the request, or by a network-based service, depending on the application.
In addition, KeyNote does not itself provide credential revocation services, although credentials can be written to expire after some date by including a date test in the predicate. Applications that require credential revocation can use KeyNote to help specify and implement revocation policies. A future document will address expiration and revocation services in KeyNote.
In addition, KeyNote does not itself provide credential revocation services, although credentials can be written to expire after some date by including a date test in the predicate. Applications that require credential revocation can use KeyNote to help specify and implement revocation policies. A future document will address expiration and revocation services in KeyNote.
Because KeyNote is designed to support a variety of applications, several different application interfaces to a KeyNote implementation are possible. In its simplest form, a KeyNote compliance checker would exist as a stand-alone application, with other applications calling it as needed. KeyNote might also be implemented as a library to which applications are linked. Finally, a KeyNote implementation might run as a local trusted service, with local applications communicating their queries via some interprocess communication mechanism.
Because KeyNote is designed to support a variety of applications, several different application interfaces to a KeyNote implementation are possible. In its simplest form, a KeyNote compliance checker would exist as a stand-alone application, with other applications calling it as needed. KeyNote might also be implemented as a library to which applications are linked. Finally, a KeyNote implementation might run as a local trusted service, with local applications communicating their queries via some interprocess communication mechanism.
8. Security Considerations
8. Security Considerations
Trust management is itself a security service. Bugs in or incorrect use of a KeyNote compliance checker implementation could have security implications for any applications in which it is used.
Trust management is itself a security service. Bugs in or incorrect use of a KeyNote compliance checker implementation could have security implications for any applications in which it is used.
9. IANA Considerations
9. IANA Considerations
This document contains three identifiers to be maintained by the IANA. This section explains the criteria to be used by the IANA to assign additional identifiers in each of these lists.
このドキュメントはIANAによって維持される3つの識別子を含んでいます。 それぞれのこれらのリストの追加識別子を割り当てるのにIANAによって使用されるように、このセクションは評価基準について説明します。
Blaze, et al. Informational [Page 31] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[31ページ]のRFC2704基調信用管理システム1999年9月
9.1 app_domain Identifiers
9.1装置_ドメインIdentifiers
The only thing required of IANA on allocation of these identifiers is that they be unique strings. These strings are case-sensitive for KeyNote purposes, however it is strongly recommended that IANA assign different capitalizations of the same string only to the same organization.
これらの識別子の配分のときにIANAについて必要であった唯一のものはそれらがユニークなストリングであるということです。 これらのストリングがKeyNote目的のために大文字と小文字を区別している、しかしながら、IANAが同じストリングの異なった資源化を同じ組織だけに配属することが強く勧められます。
9.2 Public Key Format Identifiers
9.2 公開鍵形式ID
These strings uniquely identify a public key algorithm as used in the KeyNote system for representing keys. Requests for assignment of new identifiers must be accompanied by an RFC-style document that describes the details of this encoding. Example strings are "rsa- hex:" and "dsa-base64:". These strings are case-insensitive.
これらのストリングはキーを表すKeyNoteシステムで使用されるように唯一公開鍵アルゴリズムを特定します。 このコード化の詳細について説明するRFC-スタイルドキュメントで新しい識別子の課題を求める要求に伴わなければなりません。 例のストリングがそうである、「rsa十六進法:」 そして、「dsa-base64:」 これらのストリングは大文字と小文字を区別しないです。
9.3 Signature Algorithm Identifiers
9.3 署名アルゴリズム識別子
These strings uniquely identify a public key algorithm as used in the KeyNote system for representing public key signatures. Requests for assignment of new identifiers must be accompanied by an RFC-style document that describes the details of this encoding. Example strings are "sig-rsa-md5-hex:" and "sig-dsa-sha1-base64:". Note that all such strings must begin with the prefix "sig-". These strings are case-insensitive.
これらのストリングは公開鍵署名を表すKeyNoteシステムで使用されるように唯一公開鍵アルゴリズムを特定します。 このコード化の詳細について説明するRFC-スタイルドキュメントで新しい識別子の課題を求める要求に伴わなければなりません。 例のストリングがそうである、「sig-rsa-md5-十六進法:」 そして、「sig-dsa-sha1-base64:」 そのようなすべてのストリングが接頭語"sig"で始まらなければならないことに注意してください。 これらのストリングは大文字と小文字を区別しないです。
Blaze, et al. Informational [Page 32] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[32ページ]のRFC2704基調信用管理システム1999年9月
A. Acknowledgments
A。 承認
We thank Lorrie Faith Cranor (AT&T Labs - Research) and Jonathan M. Smith (University of Pennsylvania) for their suggestions and comments on earlier versions of this document.
私たちはこのドキュメントの以前のバージョンの彼らの提案とコメントについてロリーFaith Cranor(AT&T Labs--研究)とジョナサン・M.スミス(ペンシルバニア大学)に感謝します。
B. Full BNF (alphabetical order)
B。 完全なBNF(アルファベット順)
<ALGORITHM>:: {see section 4.4.2} ;
<アルゴリズム>:、: セクション4.4.2を見てください。
<Assertion>:: <VersionField>? <AuthField> <LicenseesField>?
<LocalConstantsField>? <ConditionsField>?
<CommentField>? <SignatureField>? ;
<主張>:、: <VersionField>? <AuthField><LicenseesField>? <LocalConstantsField>? <ConditionsField>? <CommentField>? <SignatureField>? ;
<Assignments>:: "" | <AttributeID> "=" <StringLiteral> <Assignments> ;
<課題>:、: "" | <AttributeID>は<StringLiteral><課題>と「等しいです」。
<AttributeID>:: {Any string starting with a-z, A-Z, or the
underscore character, followed by any number of
a-z, A-Z, 0-9, or underscore characters} ;
<AttributeID>:、: 1zから始動するどんなストリング(A-Z、または強調キャラクタ)も、1zのどんな数、A-Z、0-9、または強調キャラクタでも続きました。
<AuthField>:: "Authorizer:" <AuthID> ;
<AuthField>:、: 「Authorizer:」 <AuthID>。
<AuthID>:: <PrincipalIdentifier> | <DerefAttribute> ;
<AuthID>:、: <PrincipalIdentifier>。| <DerefAttribute>。
<Clause>:: <Test> "->" "{" <ConditionsProgram> "}"
| <Test> "->" <Value> | <Test> ;
<節>:、: <テスト>"->"「「<ConditionsProgram>」」| <テスト>"->"<値の>。| <テスト>。
<Comment>:: "#" {ASCII characters} ;
<コメント>:、: 「#」ASCII文字。
<CommentField>:: "Comment:" {Free-form text} ;
<CommentField>:、: 「コメントしてください」 自由形式テキスト。
<ConditionsField>:: "Conditions:" <ConditionsProgram> ;
<ConditionsField>:、: 「状態:」 <ConditionsProgram>。
<ConditionsProgram>:: "" | <Clause> ";" <ConditionsProgram> ;
<ConditionsProgram>:、: "" | 「<節>」;、」 <ConditionsProgram>。
<DerefAttribute>:: <AttributeID> ;
<DerefAttribute>:、: <AttributeID>。
<ENCODEDBITS>:: {see section 4.4.2} ;
<ENCODEDBITS>:、: セクション4.4.2を見てください。
<FloatEx>:: <FloatEx> "+" <FloatEx> | <FloatEx> "-" <FloatEx>
| <FloatEx> "*" <FloatEx> | <FloatEx> "/" <FloatEx>
| <FloatEx> "^" <FloatEx> | "-" <FloatEx>
| "(" <FloatEx> ")" | <FloatLiteral> | "&" <StrEx> ;
<FloatEx>:、: <FloatEx>「+」<FloatEx>。| <FloatEx>「-」<FloatEx>。| <FloatEx>「*」<FloatEx>。| 」 「<FloatEx>」/<FloatEx>。| <FloatEx>"^"<FloatEx>。| 「--」<FloatEx>。| 「(「<FloatEx>」)」| <FloatLiteral>。| "&"<StrEx>。
<FloatRelExpr>:: <FloatEx> "<" <FloatEx> | <FloatEx> ">" <FloatEx>
| <FloatEx> "<=" <FloatEx>
| <FloatEx> ">=" <FloatEx> ;
<FloatRelExpr>:、: <FloatEx>"<"<FloatEx>。| <FloatEx>">"<FloatEx>。| <FloatEx>「<=」<FloatEx>。| <FloatEx>「>=」<FloatEx>。
Blaze, et al. Informational [Page 33] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[33ページ]のRFC2704基調信用管理システム1999年9月
<FloatLiteral>:: <IntegerLiteral>"."<IntegerLiteral> ;
<FloatLiteral>:、: 「<IntegerLiteral>」 「<IntegerLiteral>」。
<IDString>:: <ALGORITHM>":"<ENCODEDBITS> ;
<IDString>:、: 「<アルゴリズム>」: 「<ENCODEDBITS>」。
<IntegerLiteral>:: {Decimal number of at least one digit} ;
<IntegerLiteral>:、: 少なくとも1ケタの10進数。
<IntEx>:: <IntEx> "+" <IntEx> | <IntEx> "-" <IntEx>
| <IntEx> "*" <IntEx> | <IntEx> "/" <IntEx>
| <IntEx> "%" <IntEx> | <IntEx> "^" <IntEx>
| "-" <IntEx> | "(" <IntEx> ")" | <IntegerLiteral>
| "@" <StrEx> ;
<IntEx>:、: <IntEx>「+」<IntEx>。| <IntEx>「-」<IntEx>。| <IntEx>「*」<IntEx>。| 」 「<IntEx>」/<IntEx>。| <IntEx>「%」<IntEx>。| <IntEx>"^"<IntEx>。| 「--」<IntEx>。| 「(「<IntEx>」)」| <IntegerLiteral>。| "@"<StrEx>。
<IntRelExpr>:: <IntEx> "==" <IntEx> | <IntEx> "!=" <IntEx>
| <IntEx> "<" <IntEx> | <IntEx> ">" <IntEx>
| <IntEx> "<=" <IntEx> | <IntEx> ">=" <IntEx> ;
<IntRelExpr>:、: <IntEx>「=」<IntEx>。| 「<IntEx>!」 」 =<IntEx>。| <IntEx>"<"<IntEx>。| <IntEx>">"<IntEx>。| <IntEx>「<=」<IntEx>。| <IntEx>「>=」<IntEx>。
<K>:: {Decimal number starting with a digit from 1 to 9} ;
<K>:、: 1〜9までケタから始まる10進数。
<KeyID>:: <StrEx> ;
<KeyID>:、: <StrEx>。
<LicenseesExpr>:: "" | <PrincExpr> ;
<LicenseesExpr>:、: "" | <PrincExpr>。
<LicenseesField>:: "Licensees:" <LicenseesExpr> ;
<LicenseesField>:、: 「免許所有者:」 <LicenseesExpr>。
<LocalConstantsField>:: "Local-Constants:" <Assignments> ;
<LocalConstantsField>:、: 「地方の定数:」 <課題>。
<OpaqueID>:: <StrEx> ;
<OpaqueID>:、: <StrEx>。
<PrincExpr>:: "(" <PrincExpr> ")" | <PrincExpr> "&&" <PrincExpr>
| <PrincExpr> "||" <PrincExpr>
| <K>"-of(" <PrincList> ")" | <PrincipalIdentifier>
| <DerefAttribute> ;
<PrincExpr>:、: 「(「<PrincExpr>」)」| <PrincExpr>“&&"<PrincExpr>。| 「<PrincExpr>」||「<PrincExpr>」| 「<K>」、-、(「<PrincList>」)、」| <PrincipalIdentifier>。| <DerefAttribute>。
<PrincipalIdentifier>:: <OpaqueID> | <KeyID> ;
<PrincipalIdentifier>:、: <OpaqueID>。| <KeyID>。
<PrincList>:: <PrincipalIdentifier> | <DerefAttribute>
| <PrincList> "," <PrincList> ;
<PrincList>:、: <PrincipalIdentifier>。| <DerefAttribute>。| 」 「<PrincList>」、<PrincList>。
<RegExpr>:: {POSIX 1003.2 Regular Expression}
<RegExpr>:、: POSIX1003.2正規表現
<RelExpr>:: "(" <RelExpr> ")" | <RelExpr> "&&" <RelExpr>
| <RelExpr> "||" <RelExpr> | "!" <RelExpr>
| <IntRelExpr> | <FloatRelExpr> | <StringRelExpr>
| "true" | "false" ;
<RelExpr>:、: 「(「<RelExpr>」)」| <RelExpr>“&&"<RelExpr>。| 「<RelExpr>」||「<RelExpr>」| "!" <RelExpr>。| <IntRelExpr>。| <FloatRelExpr>。| <StringRelExpr>。| 「本当に」| 「虚偽」。
<Signature>:: <StrEx> ;
<署名>:、: <StrEx>。
<SignatureField>:: "Signature:" <Signature> ;
<SignatureField>:、: 「署名:」 <署名>。
Blaze, et al. Informational [Page 34] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[34ページ]のRFC2704基調信用管理システム1999年9月
<StrEx>:: <StrEx> "." <StrEx> | <StringLiteral> | "(" <StrEx> ")"
| <DerefAttribute> | "$" <StrEx> ;
<StrEx>:、: 「<StrEx>」、」 <StrEx>。| <StringLiteral>。| 「(「<StrEx>」)」| <DerefAttribute>。| 「$」<StrEx>。
<StringLiteral>:: {see section 4.3.1} ;
<StringLiteral>:、: セクション4.3.1を見てください。
<StringRelExpr>:: <StrEx> "==" <StrEx> | <StrEx> "!=" <StrEx>
| <StrEx> "<" <StrEx> | <StrEx> ">" <StrEx>
| <StrEx> "<=" <StrEx> | <StrEx> ">=" <StrEx>
| <StrEx> "~=" <RegExpr> ;
<StringRelExpr>:、: <StrEx>「=」<StrEx>。| 「<StrEx>!」 」 =<StrEx>。| <StrEx>"<"<StrEx>。| <StrEx>">"<StrEx>。| <StrEx>「<=」<StrEx>。| <StrEx>「>=」<StrEx>。| 「<StrEx>」~、は」 <RegExpr>と等しいです。
<Test>:: <RelExpr> ;
<テスト>:、: <RelExpr>。
<Value>:: <StrEx> ;
<値の>:、: <StrEx>。
<VersionField>:: "KeyNote-Version:" <VersionString> ;
<VersionField>:、: 「基調バージョン:」 <VersionString>。
<VersionString>:: <StringLiteral> | <IntegerLiteral> ;
<VersionString>:、: <StringLiteral>。| <IntegerLiteral>。
References
参照
[BFL96] M. Blaze, J. Feigenbaum, J. Lacy. Decentralized Trust
Management. Proceedings of the 17th IEEE Symp. on Security
and Privacy. pp 164-173. IEEE Computer Society, 1996.
Available at
<ftp://ftp.research.att.com/dist/mab/policymaker.ps>
J.ファイゲンバウムの、そして、J.レース状の[BFL96]M.炎。 信用管理を分散しました。 議事、第17IEEE Symp SecurityとPrivacy pp164-173に関して。 IEEEコンピュータ社会、1996。 <ftp://ftp.research.att.com/dist/mab/policymaker.ps>では、利用可能です。
[BFS98] M. Blaze, J. Feigenbaum, M. Strauss. Compliance-Checking in
the PolicyMaker Trust-Management System. Proc. 2nd Financial
Crypto Conference. Anguilla 1998. LNCS #1465, pp 251-265,
Springer-Verlag, 1998. Available at
<ftp://ftp.research.att.com/dist/mab/pmcomply.ps>
[BFS98] M.炎、J.ファイゲンバウム、M.ストラウス。 政策立案者信用マネージメントシステムで承諾にチェックします。 Proc。 第2財政的な暗号コンファレンス。 アンギラ1998。 LNCS#1465、pp251-265、Springer-Verlag、1998。 <ftp://ftp.research.att.com/dist/mab/pmcomply.ps>では、利用可能です。
[Bla99] M. Blaze, J. Feigenbaum, J. Ioannidis, A. Keromytis. The
Role of Trust Management in Distributed System Security.
Chapter in Secure Internet Programming: Security Issues for
Mobile and Distributed Objects (Vitek and Jensen, eds.).
Springer-Verlag, 1999. Available at
<ftp://ftp.research.att.com/dist/mab/trustmgt.ps>.
[Bla99] M.炎、J.ファイゲンバウム、J.Ioannidis、A.Keromytis。 分散システムセキュリティにおける信用管理の役割。 安全なインターネットプログラミングにおける章: モバイルのためのセキュリティIssuesとDistributed Objects(edsのビテクとジェンセン)。 追出石-Verlag、1999。 <ftp://ftp.research.att.com/dist/mab/trustmgt.ps>では、利用可能です。
[Cro82] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[Cro82] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[DSA94] Digital Signature Standard. FIPS-186. National Institute of
Standards, U.S. Department of Commerce. May 1994.
[DSA94]デジタル署名基準。 FIPS-186。 規格の国家の研究所、米国商務省。 1994年5月。
[PKCS1] PKCS #1: RSA Encryption Standard, Version 1.5. RSA
Laboratories. November 1993.
[PKCS1]PKCS#1: RSA暗号化規格、バージョン1.5。 RSA研究所。 1993年11月。
Blaze, et al. Informational [Page 35] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[35ページ]のRFC2704基調信用管理システム1999年9月
[RSA78] R. L. Rivest, A. Shamir, L. M. Adleman. A Method for
Obtaining Digital Signatures and Public-Key Cryptosystems.
Communications of the ACM, v21n2. pp 120-126. February 1978.
[RSA78] R.L.Rivest、A.シャミル、L.M.Adleman。 Obtaining Digital SignaturesとPublic主要なCryptosystems v21n2ACMに関するコミュニケーション、pp120-126のためのMethod。 1978年2月。
Authors' Addresses
作者のアドレス
Comments about this document should be discussed on the keynote-users
mailing list hosted at nsa.research.att.com. To subscribe, send an
email message containing the single line
subscribe keynote-users
in the message body to <majordomo@nsa.research.att.com>.
nsa.research.att.comでホスティングされた基調ユーザメーリングリストでこのドキュメントの周りのコメントについて議論するべきです。 申し込むために、メッセージ本体 to <majordomo@nsa.research.att.com の基調ユーザを単線を含んでいると申し込まれるメールメッセージに送ってください、gt。
Questions about this document can also be directed to the authors as a group at the keynote@research.att.com alias, or to the individual authors at:
また、 keynote@research.att.com 別名におけるグループとしての作者、または、以下の個々の作者にこのドキュメントに関する質問を向けることができます。
Matt Blaze AT&T Labs - Research 180 Park Avenue Florham Park, New Jersey 07932-0971
マット炎のAT&T研究室--研究180パーク・アベニューFlorham公園、ニュージャージー07932-0971
EMail: mab@research.att.com
メール: mab@research.att.com
Joan Feigenbaum AT&T Labs - Research 180 Park Avenue Florham Park, New Jersey 07932-0971
ジョーンファイゲンバウムAT&T研究室--研究180パーク・アベニューFlorham公園、ニュージャージー07932-0971
EMail: jf@research.att.com
メール: jf@research.att.com
John Ioannidis AT&T Labs - Research 180 Park Avenue Florham Park, New Jersey 07932-0971
ジョンIoannidis AT&T研究室--研究180パーク・アベニューFlorham公園、ニュージャージー07932-0971
EMail: ji@research.att.com
メール: ji@research.att.com
Angelos D. Keromytis Distributed Systems Lab CIS Department, University of Pennsylvania 200 S. 33rd Street Philadelphia, Pennsylvania 19104-6389
ペンシルバニア大学200秒間Angelos D.Keromytis分散システム研究室CIS部、第33通りフィラデルフィア、ペンシルバニア19104-6389
EMail: angelos@dsl.cis.upenn.edu
メール: angelos@dsl.cis.upenn.edu
Blaze, et al. Informational [Page 36] RFC 2704 The KeyNote Trust-Management System September 1999
炎、他 情報[36ページ]のRFC2704基調信用管理システム1999年9月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Blaze, et al. Informational [Page 37]
炎、他 情報[37ページ]
一覧
スポンサーリンク
