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
The KeyNote Trust-Management System Version 2
Status of this 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.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
このメモは基調信託管理システムのバージョン2を説明します。それは、 `action属性説明基調講演`アサーションの構文とセマンティクスを指定する処理をし、基調実装がフィットすることができそこにアプリケーションアーキテクチャの概要を説明します。基調アーキテクチャおよび言語は、インターネット・プロトコルやサービスの様々な信託管理面のためのビルディングブロックとして有用です。
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]で導入された信託管理は、セキュリティポリシー、資格証明書、および関係を指定し、解釈に統一されたアプローチです。それはセキュリティ上重要な行為の直接の承認を可能にします。信託管理システムは、アプリケーションのセキュリティポリシーおよび資格情報を指定するための標準的な、汎用的なメカニズムを提供します。トラスト・マネジメントの資格情報は信頼の具体的な代表団を説明し、公開鍵証明書の役割を包括し、名前にキーをバインドする伝統的な証明書とは異なり、資格情報は、特定のタスクを実行するための権限に直接キーをバインドすることができます。
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 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.
*コンプライアンスチェッカは、要求がアプリケーションによって処理されるべき方法を説明アプリケーション構成 `ポリシーコンプライアンス値を」を返します。ポリシーコンプライアンス値は、常に積極基調ベースのシステムの分析を容易に、ポリシーおよび資格情報から派生しています。
* 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.
この文書では、基調方針と資格アサーション言語、基調アクション記述の構造、および計算の基調モデルを説明しています。
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.
私たちは、入力として基調方針と資格表明のコレクションに加えてアクションの説明を送信し、出力として結果のポリシーコンプライアンス値を受け入れ、アプリケーションが `関数呼び出し」スタイルのインタフェースを介してローカルに信頼さ基調コンプライアンス・チェッカーと通信することを前提としています。しかし、異なるアプリケーション、ホスト、および環境の要件は、基調コンプライアンスチェッカに異なるインターフェイスのさまざまを生じ得ます。このドキュメントは、完全なコンプライアンス・チェッカーAPIを指定することを目指していません。
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 system (e.g., for credential signature verification). In other cases, Principal Identifiers may have a structure that is opaque to 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.
プリンシパルは基調に懸念の二つの機能を実行します。彼らは、 `アクションを要求すると、彼らは`アサーションを発行します。アクションは、基調制御の下でアプリケーションの場所そのいずれかの信頼できる操作です。アサーションは他の主体へのアクションを実行する権限を委任します。
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.
アクションが設定され `action属性」と呼ばれる名前と値のペアのコレクションの観点で基調コンプライアンスチェッカーに説明されています。 action属性セットは、呼び出し元のアプリケーションによって作成されます。その構造や形式は、このドキュメントのセクション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.
基調は、特定の要求された行為についても政策の解釈についてのアプリケーションにアドバイスを提供します。アプリケーションセット提案action属性を含むと主（複数可）を要求を識別する `クエリ」を発行することにより、基調コンプライアンスチェッカを呼び出します。基調システムが判断し、可能な応答の順序集合から適切な `ポリシーコンプライアンス値」を返します。
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.
基調クエリから返されたポリシーコンプライアンス値は、要求されたアクションを処理するために、どのようにアプリケーションをアドバイスします。最も単純なケースでは、コンプライアンス値（例えば、「拒否」または「承認」）ブール値です。アサーションはまた、場合（例えば、「アクセスなし」、「アクセス制限」、「完全なアクセス」）アプリケーションに適した、可能なコンプライアンス値の範囲から選択するように記述することができます。アプリケーションは、クエリ時に、コンプライアンス値の（「`最強に」`最も弱いから）相対的な順序を設定することができます。
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.
識別子が「ポリシー」である特別なプリンシパルは、基調の信頼のルートを提供します。 「ポリシーは、」したがって、任意のアクションを実行する権限をされていると考えられます。
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.
「ポリシー」校長によって発行されたアサーションは `ポリシーアサーションと呼ばれており、それ以外の場合は信頼されていないプリンシパルに権限を委任するために使用されています。アプリケーションの基調セキュリティポリシーは、ポリシーアサーションの集合で構成されています。
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 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:
基調は、様々なメディア上での送信および保管に適している人間が読めるポリシーおよび資格証明書の作成を奨励するために設計されています。そのアサーション構文は[Cro82] RFC822形式のメッセージヘッダのフォーマットに触発されています。基調アサーションは、アサーションのセマンティクスの一の側面を指定するそれぞれの `フィールドと呼ばれるセクションの順序を、含まれています。フィールドは、行の先頭に識別子で始まり、次のフィールドに遭遇するまで継続します。例えば：
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のローカル定数のためのシンプルな、工夫すれば、電子メールの証明書：ATT_CA_key = "RSA：acdfa1df1011bbac" mab_key = "DSA：deadbeefcafe001a" オーソ：ATT_CA_keyライセンス保持者mab_key条件：（（app_domain == "電子メール "）のみ、電子メールの有効な＃&&（アドレス== "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.
資格証明書でサポートされているよう基調セマンティクスは、他の主体によって要求されたアプリケーションの政策と行動との関係を解消します。基調準拠チェッカーは、要求されたアクションのポリシーコンプライアンス値を決定するために設定され、action属性に対するアサーションを処理します。これらのセマンティクスは、第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 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]で見つけることができます。
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.
基調によって評価される信頼できるアクションが設定され `action属性」と呼ばれる名前と値のペアの集合によって記述されています。アクション属性は、アプリケーションが基調に要求を伝え、基調アサーションが動作する上で主要なオブジェクトであるメカニズムです。 action属性セットは、各クエリで基調コンプライアンス・チェッカーに渡されます。
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.
それぞれのaction属性は、名前と値で構成されています。名前と値の意味は基調自体によって解釈されません。彼らはアプリケーションによって異なり、アプリケーションの作家やそれらによって使用されるポリシーおよび資格証明書の作家が合意しなければなりません。
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.).
Action属性名と値は任意の長さの文字列で表されます。基調は長い2048文字までの属性名と値のサポートを保証します。長い属性名または値の処理が指定され、基調-実装依存であるされていません。アプリケーションとの主張は、それゆえ名以上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} ;
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>は、英字またはアンダースコア文字で始まり、英数字とアンダースコアの任意の数を続けることができます。属性名は大文字と小文字が区別されます。
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.
コンプライアンスチェッカに設定action属性を渡すための正確なメカニズムは基調実装によって決定されます。 、特定の要件に応じて実装では、クエリの明示的なパラメータとしてセット全体属性を含むための機構を提供することができ、またはそれは、各属性はカーネル変数にアクセスするために、例えば、逆参照されると呼び出されるコールバック機構のいくつかのフォームを提供することができます。
If an action attribute is not defined its value is considered to be the empty string.
action属性が定義されていない場合、その値は空の文字列であると考えられています。
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.
_MAX_TRUST Highest-order (maximum) compliance value in query; see Section 5.1.
クエリ内_MAX_TRUST最上位（最大）コンプライアンス値。セクション5.1を参照してください。
_VALUES Linearly ordered set of compliance values in query; see Section 5.1. Comma separated.
_valuesは直線クエリ内のコンプライアンス値のセットを注文しました。セクション5.1を参照してください。カンマ区切り。
_ACTION_AUTHORIZERS Names of principals directly authorizing action in query. Comma separated.
校長の_ACTION_AUTHORIZERS名を直接クエリでアクションを許可します。カンマ区切り。
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> ASCII符号化された整数である「<Nは、> _」、フォームの名前の属性、セクション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.
action属性セット内の他の属性の名前が基調で指定されていないが、特定の基調問合せ評価に相互運用にあるすべてのポリシーおよび資格証明書の作家が合意しなければなりません。
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.
慣例により、アクションの属性が解釈されるべきで、その上のアプリケーションドメインの名前は、「app_domain」という名前の属性で指定されています。 IANA（またはいくつかの他の適切な権限が）予約app_domain名のレジストリを提供します。レジストリは、各アプリケーションの属性の名前と意味の一覧が表示されます。
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.
app_domain規則は、それらが意図していたとして、資格情報が解釈されていることを確認するのに役立ちます。任意の与えられた名前を持つ属性は、多くの異なるアプリケーションドメインで使用することができるが、それらのそれぞれで異なる意味を持つかもしれません。しかし、世界的なレジストリの使用は常に小規模のために必要とされていない、アプリケーションを閉じました。唯一の要件は、ポリシーおよび資格情報がチェッカーは、それらを作成したアプリケーションが想定同じ意味に応じた属性を解釈基調遵守に利用可能となるということです。
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.
例えば、電子メールアプリケーションは、「app_domain「RFC822-EMAIL」を予約可能性があり、「名前」（メッセージの送信者の人間名）、「アドレス」（メッセージの送信者の電子メールアドレス）という名前の属性を使用するかもしれない、と任意の現在の組織」ヘッダ（組織名）。これらの属性の値は、電子メールメッセージのヘッダから明白な方法で導出されるだろう。メッセージの署名者の公開鍵は、「_ACTION_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-EMAIL」は仮想的な例であることに留意されたいです。そのような名前は、またはこれらまたは異なる属性を持つ実際のレジストリに表示されない場合があります。 （確かに、私たちは、電子メールセキュリティの現実は、この例が示唆するかもしれないよりかなり複雑であることを認識しています。）
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>。表記<X> +、一方、<X> Xの一つ又はそれ以上の繰り返しを意味しますか？ X.非終端文法シンボルのゼロまたは1回の繰り返しには角括弧で囲まれていることを意味します。文法プロダクションでの引用符で囲まれた文字列は、端末を表します。
<Assertion>:: <VersionField>? <AuthField> <LicenseesField>?
<LocalConstantsField>? <ConditionsField>?
<CommentField>? <SignatureField>? ;
All KeyNote assertions are encoded in ASCII.
すべての基調アサーションはASCIIでエンコードされています。
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.
基調アサーションは、様々な意味的な機能を果たす `フィールドと呼ばれるセクション、に分割されています。 「：」の文字と、フィールドの内容各フィールドは、続いて行の先頭に特定のラベルで始まります。行につき最大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.
フィールドは、少なくとも一つのASCIIのスペースまたはタブ文字で後続の行をインデントすることにより、複数の行にわたって継続することができます。空白（スペース、タブ、または改行文字）はトークンを区切るが、それ以外は引用符で囲まれた文字列の外に無視されます。大手octothorp文字（4.2節を参照）とのコメントが任意の列で開始することができます。
One mandatory field is required in all assertions:
1つの必須フィールドは、すべての表明に必要です。
Authorizer
オーソ
Six optional fields may also appear:
シックス・オプションのフィールドも表示されることがあります。
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.
すべてのフィールド名は大文字と小文字を区別しません。 「基調-バージョン」フィールドが存在する場合、最初に表示されます。 「署名」欄には、存在する場合、最後に表示されます。そうでない場合、フィールドは任意の順番で表示されることがあります。各フィールドには、任意の主張で、最高1回表示されることがあります。
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.
空白行はアサーションでは許可されていません。 （アプリケーションポリシー構成で、例えば）ファイルに格納された複数のアサーションは、それゆえ、それらの間に空白行を使用することによって明確に互いに分離することができます。
<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).
octothorp文字（「＃」、ASCII 35進）は、コメントを導入するために使用することができます。引用文字列（4.3節を参照）の外では、現在の行の終わりまで「＃」の文字からのすべての文字は無視されます。しかし、コメントテキストをアサーション署名の計算に含まれる（セクション4.6.7参照）。
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.
`string」は文字の配列を含む字句オブジェクトです。文字列は、改行や印字不能文字を含む任意の非NUL文字を含んでいてもよいです。文字列は、リテラルとして与えられた複雑な式から計算、または属性名から逆参照することができます。
<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.
印刷可能な文字は `バックスラッシュ文字（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 "\0o", "\0oo", and "\ooo" (where o represents any octal digit) may be used to represent any non-NUL ASCII characters with their corresponding octal values (thus, "\012" 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; "\0", "\00", and "\000" 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:
構築物「\ 0°」、「\の0oo」、および「OOO \」は（oは任意の8進数を表す）それらの対応する8進数値で任意の非NUL ASCII文字を表すために使用することができる（したがって、「\ 012」であります"\ nを"、 "\ 101" と同じことである "A"、および "\ 377" はASCII文字255 10進数）です。しかし、NUL文字は、この方法で符号化することはできません。 "\ 0"、 "\ 00"、及び "000 \" 文字列 "0" に変換され、 "00"、および "000" は、それぞれ。同様に、他のすべてのエスケープ文字が先頭のバックスラッシュを除去している（例えば、「\」となる「A」、及び「\\」「\」となります）。以下の4つの文字列は等価です。
"this string contains a newline\n followed by one space."
"this string contains a newline\n \
followed by one space."
"this str\ ing contains a \ newline\n followed by one space."
「これのstr \のINGは、\改行\ nは1つのスペースが続くが含まれています。」
"this string contains a newline\012\040followed by one space."
「この文字列は1つのスペースで040followed \ 012 \改行が含まれています。」
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を参照）属性、および文字列連結演算子を間接参照。文字列式は括弧することができます。
<StrEx>:: <StrEx> "." <StrEx> /* String concatenation */
| <StringLiteral> /* Quoted string */
| "(" <StrEx> ")"
| <DerefAttribute> /* See Section 4.4 */
| "$" <StrEx> ; /* See Section 4.4 */
The "$" operator has higher precedence than the "." operator.
「$」演算子は、より高い優先順位を持ちます「」オペレーター。
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.
アクション属性は、アサーションに情報を渡すためのアプリケーションのための主要なメカニズムを提供します。属性名は、限られた文字セット（<AttributeID>セクション3で定義されている）からの文字列であり、属性値は文字列として内部的に表現されています。属性は、単純にその名前を使用することによって間接参照されます。一般的には、基調はどこでも、文字列リテラルが許可されている属性を使用することができます。
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 '長い「と'フロート」タイプに従って表現されます。フロートは1.17549435E-38Fから3.40282347E + 38Fの範囲ながら、特に、整数は、-2147483648から2147483647までの範囲。
Any uninitialized attribute has the empty-string value when dereferenced as a string and the value zero when dereferenced as an integer or float.
任意の初期化されていない属性は、文字列と整数または浮動小数点数として逆参照値ゼロとして間接参照空の文字列値を有します。
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"
FOO == "バー" $（ "foo" という）== "バー" $ fooの== "XYZ" $（FOO）== "XYZ" $$ 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>。
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文字列として表現されています。プリンシパル識別子は、その構造基調システムによって解釈されていないか、またはそれらが資格署名検証のために基調によって使用される暗号鍵をコードすることができる任意の標識であってもよいです。
<PrincipalIdentifier>:: <OpaqueID>
| <KeyID> ;
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):
唯一のラベルとして基調で使用されている主な識別子が「`不透明であると言われています。不透明な識別子は、文字列（4.3節を参照）などの主張でエンコードされています。
<OpaqueID>:: <StrEx> ;
<OpaqueID> :: <STREX>。
Opaque identifier strings should not contain the ":" character.
「：」の文字の不透明な識別子の文字列が含まれているべきではありません。
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:
資格証明の署名を検証するために、例えばキーとして基調によって使用される主要な識別子は、「`暗号であると言われています。暗号識別子はまた、辞書的に文字列としてエンコードされます。
<KeyID>:: <StrEx> ;
<鍵ID> :: <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:
不透明な識別子とは異なり、暗号化識別子の文字列は特殊な形式を持っています。 （署名検証のための）基調によって解釈されるべきで、識別子文字列の形式でなければなりません。
<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.
「アルゴリズムは、」キーのビットを解釈する際に使用されるアルゴリズムを記述したASCIIストリングです。アルゴリズムは、主要な暗号化アルゴリズム（例えば、RSA [RSA78]、DSA [DSA94]など）、構造化形式（例えば、PKCS1 [PKCS1]）、及びキービット符号化（例えば、HEXまたはBASE64）を識別する。慣例により、アルゴリズムサブストリングが[a-zA-Z]の[-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」は、キーのビットを表す文字のストリングは、アルゴリズムに依存するの符号化フォーマットです。慣例により、進符号化されたキーは、小文字のASCII文字を使用します。
Cryptographic Principal Identifiers are converted to a normalized canonical form for the purposes of any internal comparisons between them; see Section 5.2.
暗号プリンシパル識別子は、それらの間の任意の内部の比較のために正規化された標準形に変換されます。 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.
本書を通して、例で使用されるキーは、実際には、セキュリティのために必要とされるよりもはるかに短く、一般的に架空としていることに注意してください。
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
基調-Versionフィールドは、アサーションが書かれた下基調アサーション言語のバージョンを識別する。基調-Versionフィールドの形式は
<VersionField>:: "KeyNote-Version:" <VersionString> ;
<VersionString>:: <StringLiteral>
| <IntegerLiteral> ;
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でエンコードされた文字列です。基調の生産バージョンのアサーションは、それらが解釈されるべきであるその下基調言語のバージョン番号を示すバージョンの桁を使用します。この文書に適合するように書かれたアサーションは、バージョン文字列「2」（又は整数2）で識別されなければなりません。基調-Versionフィールドは、含まれている場合、最初に表示されます。
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:
このフィールドには、追加またはアクションが唯一の現在のアサーションに属性を上書きします。このメカニズムは、特にライセンシーのフィールドを読みやすくするために、（頻繁に長い）暗号元本識別子の短い名前を使用できます。ローカル定数フィールドの形式は次のとおりです。
<LocalConstantsField>:: "Local-Constants:" <Assignments> ;
<Assignments>:: /* can be empty */
| <AttributeID> "=" <StringLiteral> <Assignments> ;
<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節で定義されたaction属性の名前空間からの属性名です。ローカル定数フィールドが複数の識別子を定義している場合、それは、複数の行を占めることができるし、インデントさ。 4.3節で説明したように、<StringLiteral>リテラル文字列です。ローカル定数フィールドで定義された属性が設定され、action属性で渡された同じ名前を持つすべての属性をオーバーライドします。
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.
属性は、ローカル定数フィールド内で最も一度初期化することができます。属性は、アサーションに複数回初期化されている場合は、全体の主張は無効とみなされ、クエリの評価に基調コンプライアンス・チェッカーによって考慮されていません。
The Authorizer identifies the Principal issuing the assertion. This field is of the form
オーソライザはアサーションを発行校長を識別します。このフィールドの形式は
<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).
（セクション4.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
ライセンシーフィールドは、アサーションが許可したプリンシパルを識別します。複数のプリンシパルを許可することができ、許可は 'と」と閾値構築物の使用を介していくつかのプリンシパルに分散させることができます。このフィールドの形式は
<LicenseesField>:: "Licensees:" <LicenseesExpr> ;
<LicenseesField> :: "ライセンシー：" <LicenseesExpr>。
<LicenseesExpr>:: /* can be empty */
| <PrincExpr> ;
<PrincExpr>:: "(" <PrincExpr> ")"
| <PrincExpr> "&&" <PrincExpr>
| <PrincExpr> "||" <PrincExpr>
| <K>"-of(" <PrincList> ")" /* Threshold */
| <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までの数字で始まる小数点数}。
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符号化された正の整数です。 <PrincListが> <K>プリンシパルより少ないが含まれている場合、全体のアサーションは、処理を省略しています。
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:
このフィールドは、オーソがアクションを実行するためにライセンシーを信頼するの下で `条件を与えます。 `条件アクションの属性セットで動作する述語です。条件フィールドの形式は次のとおりです。
<ConditionsField>:: "Conditions:" <ConditionsProgram> ;
<ConditionsField> :: "条件：" <ConditionsProgram>。
<ConditionsProgram>:: /* Can be empty */
| <Clause> ";" <ConditionsProgram> ;
<Clause>:: <Test> "->" "{" <ConditionsProgram> "}" | <Test> "->" <Value> | <Test> ;
<句> :: <試験> " - >" "{" <ConditionsProgram> "}" | <試験> " - >" <値> | <試験>。
<Value>:: <StrEx> ;
<値> :: <STREX>。
<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 */
<IntRelExpr>:: <IntEx> "==" <IntEx> | <IntEx> "!=" <IntEx> | <IntEx> "<" <IntEx> | <IntEx> ">" <IntEx> | <IntEx> "<=" <IntEx> | <IntEx> ">=" <IntEx> ;
<IntRelExpr> :: <インテックス> "==" <インテックス> | "！=" <インテックス> <インテックス> | <インテックス> "<" <インテックス> | <インテックス> ">" <インテックス> | <インテックス> "<=" <インテックス> | <インテックス> "> =" <インテックス>。
<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 */
<IntEx>:: <IntEx> "+" <IntEx> /* Integer */
| <IntEx> "-" <IntEx>
| <IntEx> "*" <IntEx>
| <IntEx> "/" <IntEx>
| <IntEx> "%" <IntEx>
| <IntEx> "^" <IntEx> /* Exponentiation */
| "-" <IntEx>
| "(" <IntEx> ")"
| <IntegerLiteral>
| "@" <StrEx> ;
<FloatEx>:: <FloatEx> "+" <FloatEx> /* Floating point */
| <FloatEx> "-" <FloatEx>
| <FloatEx> "*" <FloatEx>
| <FloatEx> "/" <FloatEx>
| <FloatEx> "^" <FloatEx> /* Exponentiation */
| "-" <FloatEx>
| "(" <FloatEx> ")"
| <FloatLiteral>
| "&" <StrEx> ;
<IntegerLiteral>:: {Decimal number of at least one digit} ;
<FloatLiteral>:: <IntegerLiteral>"."<IntegerLiteral> ;
<StringLiteral> is a quoted string as defined in Section 4.3 <AttributeID> is defined in Section 3.
4.3節で定義された<StringLiteral>は引用符で囲まれた文字列である<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.
また、その整数および浮動小数点式が唯一の条件フィールドの句内で使用されるが、それ以外の基調フィールドにすることができます注意してください。
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.
<正規表現> POSIX 1003.2正規表現の構文とセマンティクスに準拠し、標準正規表現です。
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表現を含む任意の文字列表現（または属性）は、それぞれ、「@」と「＆」演算子を使用して、整数または浮動小数点数に変換することができます。整数として間接参照属性値の端数成分が切り捨てされます。属性が逆参照場合数が適切に（例えば、それが無効な文字が含まれているか、空である）に変換することができないように、その値がゼロであると考えられます。
The Comment field allows assertions to be annotated with information describing their purpose. It is of the form
コメント欄には、アサーションはその目的を記述した情報で注釈付けすることができます。それは形式です
<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).
このフィールドの内容の解釈は基調によって実行されません。この基調アサーションのコメントを含むための2つの機構の1つであることに留意されたいです。コメントは、（内部の文字列リテラルを除く）「＃」文字でそれらを先行することによって、アサーションの体のどこにでも挿入することができます。
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:
署名フィールドは、署名されたアサーションを識別し、授権者フィールドで識別された主要の符号化されたデジタル署名を与えます。署名フィールドの形式は次のとおりです。
<SignatureField>:: "Signature:" <Signature> ;
<SignatureField> :: "署名：" <署名>。
<Signature>:: <StrEx> ;
<署名> :: <STREX>。
The <Signature> string should be of the form:
<署名>文字列の形式は次のようになります。
<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.
「アルゴリズム」と「ENCODEDBITS」サブストリングの形式は、アルゴリズム名がオーソライザフィールドに現れる主のものと同じでなければならないセクション4.4.2で暗号プリンシパル識別子の通りです。 IANA（またはいくつかの他の適切な権限）が予約名のレジストリを提供します。署名と承認者のキーのエンコーディングが同じである必要はありません。
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.
署名フィールドが含まれている場合、授権者フィールドで指定主は、暗号プリンシパル識別子である必要があり、このアルゴリズムは、基調実装に知られていなければならない、そして署名がアサーション本体及び認可キーに正確でなければなりません。
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.
署名は、署名フィールド識別子（は含まない）まで、（フィールド識別子列を含む）最初のフィールドから始まる、アサーションテキストにわたって計算されます。署名フィールド識別子に先行する改行は、署名の計算に含まれる最後の文字です。署名は常に基調表明の最後のフィールドです。このフィールドに続くテキストは、アサーションの一部とはみなされません。
The algorithms for computing and verifying signatures must be configured into each KeyNote implementation and are defined and documented separately.
コンピューティングのためのアルゴリズムおよび検証署名は、各基調実装に構成されなければならないと定義され、別々に文書化されています。
Note that all signatures used in examples in this document are fictitious and generally much shorter than would be required for security in practice.
このドキュメントの例で使用されるすべての署名は、実際には、セキュリティのために必要とされるよりもはるかに短く、一般的に架空としていることに注意してください。
The KeyNote compliance checker finds and returns the Policy Compliance Value of queries, as defined in Section 5.3, below.
基調コンプライアンスチェッカーが検出し、以下のセクション5.3で定義され、クエリのポリシーコンプライアンス値を返します。
A KeyNote query has four parameters:
基調クエリは、4つのパラメータがあります。
* The identifier of the principal(s) requesting the action.
*アクションを要求するプリンシパル（単数または複数）の識別子。
* The action attribute set describing the action.
* action属性は、アクションを記述した設定しました。
* The set of compliance values of interest to the application, ordered from _MIN_TRUST to _MAX_TRUST
*アプリケーションへの関心のコンプライアンス値のセット、_MAX_TRUSTする_MIN_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).
基調評価にこれらのパラメータを渡すためのメカニズムは、アプリケーションに依存します。で、必要に応じて、まだ他の人がアプリケーションから要求されるかもしれないが、他は、（例えば、資格情報はネットワークベースのディストリビューションシステム内で検索される可能性があります）外部ルックアップされる一方で、特に、評価者は、明示的に渡されるいくつかのパラメータを提供するかもしれません（非常に大規模な名前空間の中から値を表す属性値のために例えば、） `コールバック」メカニズムによる評価、。
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.
校長少なくとも一つは、アクションの `依頼者」として各クエリで識別されなければなりません。アクションには、いくつかのプリンシパル、個別にそれを要求していると考えられ、各によって要求される場合があります。これは、例えば、複数の認証を必要とするポリシー、 `2人コントロール」を可能にします。校長の許可のセットは、特別な属性「_ACTION_AUTHORIZERS」で利用可能になります。いくつかのプリンシパルが認可されている場合、その識別子は、カンマで区切られています。
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.
アプリケーション（及び互いに対するそれらの相対的なランキング）に関心のコンプライアンス値のセットは、呼び出しアプリケーションによって決定され、クエリのパラメータとして基調エバリュエータに渡されます。多くのアプリケーションでは、これはブール値、例えば、順序付けられた集合{FALSE、TRUE}または{APPROVE、REJECT}あろう。他のアプリケーションは、可能な値の範囲を必要とするかもしれない、例えば、{NO_ACCESS、Limited_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」と「_MAX_TRUST」という名前の特別な属性でご利用いただけます。クエリのコンプライアンス値の完全なセットは、「_values」という名前の特別な属性に（_MIN_TRUSTから_MAX_TRUSTに）昇順に使用可能になります。値は、カンマで区切られます。したがって、自身がコンマを含むコンプライアンス値文字列の使用を避けるべきである_values属性を利用するアサーションを使用するアプリケーション。
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.
授権者とライセンシーフィールドまたはアクションの直接認可に（キーを表す）暗号プリンシパル識別子のうち、プリンシパル識別子の比較は、標準形に変換することによりそれらを正規化した後に行われます。
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.
基調で使用されるすべての暗号化アルゴリズムは、それらの標準形にキーを変換する方法を定義し、すなわち、2つのキーの平等のための比較が行われる方法を指定します。識別子で指定されたアルゴリズムが基調に不明な場合、識別子は不透明なものとして扱われます。
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).
（それは、暗号コンプライアンスチェッカによって検証することができないので）オーソフィールドに不透明な識別子の使用を注意してくださいすることは、アサーションの整合性がローカルに信頼されている必要があります。
The Policy Compliance Value of a query is the Principal Compliance Value of the principal named "POLICY". This value is defined as follows:
クエリのポリシーコンプライアンス値は、「ポリシー」という名前の元本の主なコンプライアンス値です。次のようにこの値が定義されています。
The Compliance Value of a principal <X> is the highest order (maximum) of:
の主要<X>最上位である（最大）のコンプライアンス値：
- the Direct Authorization Value of principal <X>; and
- 主の直接許可値<X>。そして
- the Assertion Compliance Values of all assertions identifying <X> in the Authorizer field.
- オーソライザフィールドに<X>識別すべてのアサーションのアサーションコンプライアンス値。
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>は_MAX_TRUST <X>は、アクションの承認者としてクエリに表示されている場合。それ以外の場合は、<X>の直接の認証値は_MIN_TRUSTです。
The Assertion Compliance Value of an assertion is the lowest order (minimum) of the assertion's Conditions Compliance Value and its Licensee Compliance Value.
アサーションのアサーションコンプライアンス値は、アサーションの条件コンプライアンス値とそのライセンシーコンプライアンス値の最下位（最小値）です。
The Conditions Compliance Value of an assertion is the highest-order (maximum) value among all successful clauses listed in the conditions section.
アサーションの条件コンプライアンス値は、条件部に記載されているすべての成功した句のうち最上位の（最大）値です。
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.
無節のテストが成功したか、条件フィールドが空の場合、アサーションの条件コンプライアンス値が定義されたセクション5.1として、_MIN_TRUST値であると考えられています。
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.
アサーションの条件フィールドが完全に欠落している場合、その条件コンプライアンス値はセクション5.1で定義されるように、_MAX_TRUST値であると考えられています。
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
条件部の各句は、2つの論理部分がありセクション4.6.5の文法からリコール： `試験「及び任意 '値を」、存在する場合に、とテストから分離されている『 - >』トークン。テスト副次句は、どちらかが成功した（論理 `trueと評価「）述語（または失敗は論理` falseと評価」）です。値の副次句は、クエリで指定したコンプライアンス値の順序集合から1つの値に評価される文字列式です。値の副次句が欠落している場合、_MAX_TRUSTであると考えられています。つまり、句です
foo=="bar";
FOO ==「バー」。
is equivalent to
に相当します
foo=="bar" -> _MAX_TRUST;
FOO == "バー" - > _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:
句の値の成分が存在する場合、最も簡単な場合では、可能なコンプライアンス値を表す文字列表現を含みます。たとえば、以下の条件の場で主張を考慮してください。
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).
ここで、「USER_ID」属性の値が「1073」であり、「USER_NAME」は属性が可能コンプライアンス値セットは値「guest_access」を含んでいるでしょう、である「ルート」場合（句によって（3））及び「full_access」（ by句（4））。 （昇順で）クエリで指定されたコンプライアンス値の順序集合は{「NO_ACCESS」、「guest_access」、「user_access」、「full_access」}である場合に、アサーションの条件コンプライアンス値は「full_access」であろう（「なぜならfull_access guest_access 『）」より高次の価値を持っています』。 「USER_ID」属性の値が「19283」と「USER_NAME」を持っていた場合、属性の値は、「誰も」、何の句は成功しないだろうと条件コンプライアンス値は、最下位の可能な値である「NO_ACCESS」、だろう（_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.
句は、明示的な値をリストしている場合、その値の文字列は、コンプライアンス値のセットを注文したクエリで指定する必要があります。クエリコンプライアンス値セットで指定されていない値は_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,
句の値成分も再帰的にネストされた条項を含むことができます。再帰的にネスト句は、親テストがtrueの場合にのみ評価されます。あれは、
a=="b" -> { b=="c" -> "value1";
d=="e" -> "value2";
true -> "value3"; } ;
is equivalent to
に相当します
(a=="b") && (b=="c") -> "value1";
(a=="b") && (d=="e") -> "value2";
(a=="b") -> "value3";
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.
左辺の文字列式は、右辺の正規表現に一致する場合、正規表現の比較は、（「〜=」）真であると見なされます。 POSIX正規表現グループマッチング方式が使用される場合、グループの数は、（_0として間接参照）一時的メタ属性「_0」に配置されるマッチ、各マッチは、一時属性（_1、_2、順番に配置されます。 .. _N）。これらのマッチ属性の値は、同じ句内で行われ、その後の参照の中に有効です。正規表現の評価は、大文字と小文字が区別されます。
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 == "バー" - > {@a == 1/0 - > "oneval"。 ＃副次句1 @a == 2 - > "anotherval"。 ＃副次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.
ここでは、細分箇条1は、ランタイムエラーを引き起こします。副次1は、したがって偽（および値_MIN_TRUSTを有します）。副次句2は、しかし、通常は評価されるだろう。
An invalid <RegExpr> is considered a runtime error and causes the test in which it occurs to be considered false.
無効な<regExprの>ランタイムエラーとみなされ、偽と見なされるために発生しているテストを引き起こしています。
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.
アサーションのライセンシーのフィールドが空の場合、そのライセンシーのコンプライアンス値は_MIN_TRUSTであると考えられています。アサーションのライセンシーフィールドが完全に欠落している場合、そのライセンシーのコンプライアンス値は_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.
ライセンシーフィールドで指定された各校長について、その主なコンプライアンス値は、その名前に置き換えられます。何の主なコンプライアンス値は、いくつかの名前のプリンシパルに見つからない場合は、その名前が_MIN_TRUST値で置換されています。
The licensees expression (as defined in Section 4.6.4) is evaluated as follows:
次のようにライセンシー式（セクション4.6.4で定義されるように）評価されます：
* A "(...)" expression has the value of the enclosed subexpression.
* A「（...は）」という表現は、囲まれた部分式の値を持っています。
* A "&&" expression has the lower-order (minimum) of its two subexpression values.
* A「&&」という表現は、その2つの部分式の値の下位（最小値）を有しています。
* A "||" expression has the higher-order (maximum) of its two subexpression values.
* A "||"発現は、その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.
* A "<K> -of（<リスト>）" という表現は、<リスト>に記載されているK番目の最上位のコンプライアンス値を持っています。複数回表示される値は、多重度でカウントされます。例えば、K = 3と記載されているコンプライアンス値の注文がある場合（0、1、2、2、3）、式の値は、順序2のコンプライアンス値です。
For example, consider the following Licensees field:
たとえば、以下のライセンシーのフィールドを検討してください。
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".
主なコンプライアンス値は「はい」校長「アリス」のため、「いいえ」校長「ボブ」のために、そしてある場合には「いいえ」校長「前夜」のために、そして「はい」クエリのコンプライアンス値で「いいえ」よりも上位であります設定し、その結果のライセンシーのコンプライアンス値は「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.
ちょうど二つの可能なコンプライアンス値がある場合（例えば、「偽」と「真」）、ライセンシーのコンプライアンス値の解像度のルールは、標準ブール論理に正確に減らすことを確認します。
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).
アサーションは、符号付きまたは符号なしのいずれであってもよいです。のみ署名されたアサーションは、証明書として使用されるか、または信頼できない媒体上で送信または保存されるべきです。符号なしのアサーションは、ポリシーを指定するためにのみ使用されるべきであり、その完全性すでに基調システム自体の外部の何らかのメカニズムによってローカルポリシーに準拠するように検証されたアサーションのために（例えば、X.509証明書は、信頼された変換プログラムによってアサーションを基調に変換しました）。
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.
基調コンプライアンス・チェッカによって検証すべき署名信任状を許可する実装は、一般的なアプリケーションはアサーションを使用可能にすることができ、それを通して2 `チャンネルを提供しています。インターフェース「署名された証明書が信頼できない `上に設けられているが、界面」符号なし、ローカル信頼アサーションは`信頼上に設けられています。基調準拠チェッカーは、信頼できないインターフェイス上で提出されたすべてのアサーションの正しい署名を検証します。基調評価の整合性は、唯一のアサーションはローカルポリシーを反映していると、信頼は、信頼できるインターフェイスを介して基調に提出されている必要があります。
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.
ローカルポリシー指定メカニズムとして独占的基調を使用するアプリケーションは、信頼できるアサーションを使用する必要があることに注意してください。他のアプリケーションは、その詳細は他の人によって発行され、信頼できないインターフェイス上で提出署名した資格証明書で指定されたポリシー「ブートストラップ `に変更頻度の低い信頼できるアサーションのほんの数が必要になる場合があります。
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.
非公式基調評価のセマンティクスは、建設アクションを要求されたプリンシパルの少なくとも1つと接続するポリシー・アサーションをルート基調アサーションの有向グラフを含むと考えることができます。
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.
プリンシパルの集合<B>に主<A>からいくつかの権限の委任授権者フィールドに指定されたプリンシパルA、ライセンシーフィールドに指定された主要セット<B>、および委譲する権限を持つアサーションとして表現されます条件フィールドでエンコード。式有向グラフを構築する方法を実装依存であり、実装は、グラフの構造を最適化するための異なるアルゴリズムを使用してもよいです。一部の実装では、ポリシーアサーションで始まり、そしてまだ他は完全に他のヒューリスティックを採用するかもしれないアプローチ「他の人が `トップダウン続くかもしれませんが、アクションを要求したプリンシパルから始まるトラバーサル」を`ボトムアップを使用する場合があります。
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.
実装は、（例えば、ゼロによる除算、または構文エラーなど）の例外を記録し、要求された場合、呼び出しアプリケーションにそれらを報告するためのメカニズムを採用することが奨励されます。そのようなメカニズムは、この文書の範囲外です。
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.
読みやすさの興味では、我々は通常、実際に使用されるものよりもはるかに短いキーを使用します。これらの例における署名フィールドは、任意の実際の署名の計算の結果を表すものではないことに留意されたいです。
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.無条件にすべてのアクションのためのABC123 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資格アサーションもので信託ABC123 RSAキーのいずれかのRSAキー4401ff92（ `アリスと呼ばれる「）ここで、"「app_domain」は「RFC822-EMAIL」であるアクションを実行する（またはDSAキーd1234f `ボブと呼ばれます」）アドレスは^」正規表現にマッチする "* @基調\ .research \ .ATT \ .COM $"。言い換えれば、ABC123 keynote.research.att.comドメインの証明機関としてアリスとボブを信頼します。
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.メールアドレスmab@keynote.research.att.comと名前が存在する場合、「M.ブレイズ」でなければなりません特定のユーザーのための証明書の資格。資格は、（そのキー上の実施例Bに認定されている） `アリス機関によって発行されました：
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"
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.また `アリス機関によって発行された特定のユーザのための別の証明書の資格、。この例では、3つの異なるキーがjf@keynote.research.att.com（異なる暗号化アルゴリズムの各々）としてログインすることを可能にします。これは、実際には、1つの中に3つの資格情報です。
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):
ポリシーAと認証情報B、C及びDの下で、次のアクションが（それらが_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" アドレス= "mab@keynote.research.att.com" と_ACTION_AUTHORIZERS = "DSA：12340987" app_domain = "RFC822-EMAIL" アドレス=「mab@keynote.research .att.com」名前= "M.ブレイズ"
while the following are not accepted (they return _MIN_TRUST):
受け入れられない以下の間、（彼らは_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" アドレス= "angelos@dsl.cis.upenn.edu" と_ACTION_AUTHORIZERS = "DSA：abc991" app_domain = "RFC822-EMAIL" アドレス=「mab@keynote.research .att.com」NAME = "M.ブレイズ" と_ACTION_AUTHORIZERS = "DSA：12340987" app_domain = "RFC822-EMAIL" アドレス= "mab@keynote.research.att.com" NAME = "J.ファイゲンバウム"
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.「ドル」属性に与えられた量が10000未満であるとき、RSAキーdab212にアプリケーションドメインを「過ごす」のポリシー権限を委譲。
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.
任意の二つの署名者に委譲許可dab212 F. RSA鍵、リストからの一つはアプリケーション「費やす」でDSAキーfeed1234なければならない@dollars <7500 @dollarsにおける量が2500以上である場合と、要求であります承認されたが、ログに記録。
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.は、この方針によると、経営者のリストから任意の二つの署名者は、@ IF（ドル）<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);
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.同様の方針にdab212から信任状が、量は少なくとも100である場合、@（ドル）<500のログエントリがなされた場合のみ、署名者が必要とされます。
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:
コンプライアンス値の順序集合は{「拒否」、「ApproveAndLog」、「承認」}たクエリをとります。政策EとG、および資格情報FとHの下では、ポリシーコンプライアンス値（_MAX_TRUST）「承認」です。
_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 =ドルを "費やす" = "45" unmentioned_attribute = "何" と_ACTION_AUTHORIZERS = "RSA：ABC123、DSA：cde333" app_domain =ドルを "費やす" = "550"
The following return "ApproveAndLog":
次の戻り「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は=ドル= "5500" を "過ごす" と_ACTION_AUTHORIZERS = "DSA：cde333" app_domain =ドルを "過ごす" = "150"
However, the following return "Reject" (_MIN_TRUST):
ただし、以下のリターンは（_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 =ドル= "550" "過ごす" と_ACTION_AUTHORIZERS = "5500" = app_domain = "過ごす" ドル "DSA：cde333、DSAは978add"
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].
基調は、セキュリティポリシーを記述し、資格情報を表現するための単純なメカニズムを提供します。これは、セキュリティモデルは、キーはかなり名を解決する上よりも、やってポリシーで許可されているかを説明述語へのキーバインディングに基づいているという点で、伝統的な認証制度とは異なります。基調システムをサポートするインフラストラクチャおよびアーキテクチャは、したがって、名前ベースの認証方式に必要なものとはかなり異なっています。基調信託管理アーキテクチャは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:
基調システムの責任とアプリケーションおよびその他のサポートインフラのそれらの間の分離を理解することが重要です。基調コンプライアンスチェッカが提案アクションがポリシーに従って許可されるかどうか、ポリシーおよび資格アサーションに基づいて、決定します。ポリシー適用メカニズムとして基調出力の有用性は多くの要因に依存します。
* 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.
*アクションは、属性とその値の割り当ては、正確にアプリケーションのセキュリティ要件を反映しなければなりません。 action属性セットに含める属性を識別することは、おそらく新しいアプリケーションに基調を統合する上で最も重要な課題です。
* 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.
*アプリケーション自体が信頼できなければなりません。基調講演に直接ポリシーを適用しません。それだけで、それを呼び出すアプリケーションへのアドバイスを提供します。言い換えれば、基調は、アプリケーション自体が信頼できる、それが指定するポリシーアサーションが正しいことをしていることを前提としています。何も基調に誤解や間違った主張を提出するからか、完全基調を無視してからアプリケーションを防ぎません。
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).
これは、適切な資格情報と特定のクエリを実行するとポリシーアサーションを選択するために、アプリケーション（または基調外いくつかのサービス）までもあります。不適切な資格情報を基調に提供されている場合でも、これは（限り、ポリシーアサーションが正しいとaction属性自体が正しく基調に渡される設定）違法行為の承認につながることができないこと、しかし、注意してください。
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.
資格情報が述語の日付のテストを含むことにより、いくつかの日後に期限が切れるように書き込むことができますが、また、基調自体は、資格失効サービスを提供していません。資格取り消しを必要とするアプリケーションは失効ポリシーを指定し、実装を支援するために基調を使用することができます。将来の文書が基調に有効期限と失効サービスに対処します。
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.
基調は、様々なアプリケーションをサポートするように設計されているため、基調実装には、いくつかの異なるアプリケーションインタフェースが可能です。最も単純な形式では、基調準拠チェッカーは、必要に応じて、他のアプリケーションがそれを呼び出すと、スタンドアロンアプリケーションとして存在することになります。基調は、アプリケーションリンク先のライブラリとして実装される可能性があります。最後に、基調実装は、ローカルアプリケーションは、いくつかのプロセス間通信機構を介してそのクエリを伝えるとともに、地元の信頼できるサービスとして実行することがあります。
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.
信託管理は、セキュリティサービスそのものです。基調コンプライアンス・チェッカーの実装の使用または不適切なバグは、それが使用されているすべてのアプリケーションのためのセキュリティに影響を与える可能性があります。
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によって使用される基準を説明しています。
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の必要な唯一のことは、彼らはユニークな文字列であることです。これらの文字列は、しかし、IANAは、同じ組織に同じ文字列の異なる大文字表記を割り当てることを強く推奨され、基調講演の目的のために、大文字小文字を区別します。
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.
キーを表すため基調システムで使用されるこれらの文字列は、一意の公開鍵アルゴリズムを識別する。新しい識別子の割り当てを求めるには、この符号化の詳細を説明するRFC形式の文書を添付しなければなりません。そして、 "DSA-BASE64：" 例：文字列は、 "RSA-進" です。これらの文字列は、大文字と小文字を区別しません。
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.
公開鍵署名を表現するための基調システムで使用されるこれらの文字列は、一意の公開鍵アルゴリズムを識別する。新しい識別子の割り当てを求めるには、この符号化の詳細を説明するRFC形式の文書を添付しなければなりません。そして "SIG-DSA-SHA1-BASE64：" 例：文字列は "SIG-RSA-MD5-進" です。このようなすべての文字列は接頭辞「SIG-」で始める必要があることに注意してください。これらの文字列は、大文字と小文字を区別しません。
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.
このドキュメントの以前のバージョンにし、彼らの提案のためのジョナサン・M.スミス（ペンシルバニア大学）とコメント - 私たちは、ロリー信仰Cranor（研究AT＆T Labs社）を感謝します。
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> :: {-Zの任意の数、-Z、0-9、または続い-Z、A-Z、または下線文字で始まる任意の文字列は、文字を下線}。
<AuthField>:: "Authorizer:" <AuthID> ;
<AuthField> :: "オーソ：" <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>。
<FloatLiteral>:: <IntegerLiteral>"."<IntegerLiteral> ;
<FloatLiteral> :: <IntegerLiteral> <IntegerLiteral> "";
<IDString>:: <ALGORITHM>":"<ENCODEDBITS> ;
<IDString> :: <アルゴリズム> "：" <ENCODEDBITS>。
<IntegerLiteral>:: {Decimal number of at least one digit} ;
<IntegerLiteral> :: {少なくとも一つの桁の十進数}。
<IntEx>:: <IntEx> "+" <IntEx> | <IntEx> "-" <IntEx> | <IntEx> "*" <IntEx> | <IntEx> "/" <IntEx> | <IntEx> "%" <IntEx> | <IntEx> "^" <IntEx> | "-" <IntEx> | "(" <IntEx> ")" | <IntegerLiteral> | "@" <StrEx> ;
<インテックス> :: <インテックス> "+" <インテックス> | <INTEX> " - " <インテックス> | <インテックス> "*" <インテックス> | <インテックス> "/" <インテックス> | <インテックス> "％" <インテックス> | <インテックス> "^" <インテックス> | " - " <インテックス> | "（" <インテックス> "）" | <IntegerLiteral> | "@" <STREX>。
<IntRelExpr>:: <IntEx> "==" <IntEx> | <IntEx> "!=" <IntEx> | <IntEx> "<" <IntEx> | <IntEx> ">" <IntEx> | <IntEx> "<=" <IntEx> | <IntEx> ">=" <IntEx> ;
<IntRelExpr> :: <インテックス> "==" <インテックス> | "！=" <インテックス> <インテックス> | <インテックス> "<" <インテックス> | <インテックス> ">" <インテックス> | <インテックス> "<=" <インテックス> | <インテックス> "> =" <インテックス>。
<K>:: {Decimal number starting with a digit from 1 to 9} ;
<K> :: {1から9までの数字で始まる小数点数}。
<KeyID>:: <StrEx> ;
<鍵ID> :: <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> | <鍵ID>。
<PrincList>:: <PrincipalIdentifier> | <DerefAttribute> | <PrincList> "," <PrincList> ;
<PrincList> :: <PrincipalIdentifier> | <DerefAttribute> | <PrincList> "" <PrincList>。
<RegExpr>:: {POSIX 1003.2 Regular Expression}
<正規表現> :: {POSIX 1003.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> :: "署名：" <署名>。
<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>
【BFL96] M.ブレイズ、J.ファイゲンバウム、J.レイシー。分散型信託管理。第17回IEEE SYMPの議事録。セキュリティとプライバシー上。頁164から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.シュトラウス。 PolicyMakerのトラスト・マネジメント・システムにコンプライアンス・チェック。 PROC。第2回金融暗号会議。アンギラ1998年LNCSの＃1465、頁251から265、シュプリンガー・フェアラーク、利用可能な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。分散システムセキュリティにおける信託管理の役割。モバイルおよび分散オブジェクトのためのセキュリティ問題：セキュアインターネットプログラミングの章（ビテックとジェンセン編）。シュプリンガー・フェアラーク、<ftp://ftp.research.att.com/dist/mab/trustmgt.ps>の利用可能な1999年。
[Cro82] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[Cro82]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、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月。
[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.リベスト、シャミアA.、L. M.エーデルマン。デジタル署名と公開鍵暗号を得るための方法。 ACMのコミュニケーション、v21n2。頁120-126。 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でホストされているメーリングリスト基調ユーザーに議論する必要があります。購読するには、<majordomo@nsa.research.att.com>にメッセージ本文に基調講演、ユーザーをサブスクライブし、単一の行を含む電子メールメッセージを送信します。
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パークアベニューフローハムパーク、ニュージャージー州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パークアベニューフローハムパーク、ニュージャージー州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
ジョン・P・A・ヨアニディスAT＆T研究所 - 研究180パークアベニューフローハムパーク、ニュージャージー州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
アンゲロスD. Keromytisは、システム研究所CIS課、ペンシルバニア大学200 S. 33丁目駅、フィラデルフィア、ペンシルベニア州19104から6389を分散しました
EMail: angelos@dsl.cis.upenn.edu
メールアドレス：angelos@dsl.cis.upenn.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。