[要約] RFC 2704は、KeyNote Trust-Management System Version 2に関する要約と目的を提供します。このRFCは、セキュリティポリシーの表現と評価、および信頼管理システムの機能を改善するための提案を提供します。
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
基調講演の信託管理システムバージョン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.
Copyright（c）The Internet Society（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について説明しています。基調講演「アサーション」の構文とセマンティクスを指定し、「アクション属性」処理を説明し、基調講演の実装が適合するアプリケーションアーキテクチャの概要を説明します。基調講演のアーキテクチャと言語は、さまざまなインターネットプロトコルとサービスの信頼管理の側面の構成要素として役立ちます。
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 System [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.
Keynoteは、さまざまな大小のインターネットベースのアプリケーションに適しているように設計されたシンプルで柔軟な信頼管理システムです。ローカルポリシーと資格情報の両方に単一の統一言語を提供します。「アサーション」と呼ばれる基調講演のポリシーと資格には、特定の公開鍵の保有者が許可されている信頼できるアクションを説明する述語が含まれています。基調講演は、本質的に小規模で高度に構造化されたプログラムです。信頼されていないネットワークを介して送信できる署名されたアサーションは、「資格的アサーション」とも呼ばれます。証明書の役割にも役立つ資格的アサーションは、ポリシーアサーションと同じ構文を持っていますが、信託を委任する元本によって署名されています。
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.
基調講演では、信頼できる行動を実行する権限は、1人以上の「プリンシパル」に関連付けられています。プリンシパルは、物理的なエンティティ、オペレーティングシステムのプロセス、公開鍵、またはその他の便利な抽象化です。基調講演は、「主要な識別子」と呼ばれる文字列によって識別されます。場合によっては、主要な識別子には、基調講演システムによって解釈される暗号化キーが含まれます（例えば、資格情報の署名検証など）。それ以外の場合、主要な識別子には、基調講演に不透明な構造がある場合があります。
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.
プリンシパルは、基調講演に懸念の2つの機能を実行します。「アクション」を要求し、「アサーション」を発行します。アクションは、アプリケーションが基調講演の下に配置する信頼できる操作です。アサーションは、他の校長にアクションを実行する許可を委任します。
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.
アクションは、「アクション属性セット」と呼ばれる名前と価値のペアのコレクションの観点から、基調講演コンプライアンスチェッカーに説明されています。アクション属性セットは、呼び出しアプリケーションによって作成されます。その構造と形式については、このドキュメントのセクション3で詳しく説明しています。
KeyNote provides advice to applications about the interpretation of policy with regard to specific requested actions. Applications invoke the KeyNote compliance checker by issuing a `query' containing a proposed action attribute set and identifying the principal(s) requesting it. The KeyNote system determines and returns an appropriate `policy compliance value' from an ordered set of possible responses.
Keynoteは、特定の要求されたアクションに関するポリシーの解釈に関するアプリケーションにアドバイスを提供します。アプリケーションは、提案されたアクション属性セットを含む「クエリ」を発行し、それを要求する元本を識別することにより、基調講演コンプライアンスチェッカーを呼び出します。基調講演システムは、順序付けられた可能な応答セットから適切な「ポリシーコンプライアンス値」を決定および返します。
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:
Keynoteは、さまざまなメディアで送信と保管に適した人間の読み取り可能なポリシーと資格情報の作成を奨励するように設計されています。そのアサーション構文は、RFC822スタイルのメッセージヘッダー[CRO82]の形式に触発されています。基調講演には、「フィールド」と呼ばれる一連のセクションが含まれており、それぞれがアサーションのセマンティクスの1つの側面を指定しています。フィールドは、行の先頭から識別子から始まり、次のフィールドに遭遇するまで続きます。例えば：
KeyNote-Version: 2
Comment: A simple, if contrived, email certificate for user mab
Local-Constants: ATT_CA_key = "RSA:acdfa1df1011bbac"
mab_key = "DSA:deadbeefcafe001a"
Authorizer: ATT_CA_key
Licensees: mab_key
Conditions: ((app_domain == "email") # valid for email only
&& (address == "mab@research.att.com"));
Signature: "RSA-SHA1:f00f2244"
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.
基調講演セマンティクスは、資格によってサポートされているように、他の校長が要求するアプリケーションのポリシーとアクションとの関係を解決します。基調講演コンプライアンスチェッカーは、要求されたアクションのポリシーコンプライアンス値を決定するために設定されたアクション属性に対するアサーションを処理します。これらのセマンティクスは、セクション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.
基調講演によって評価される信頼できるアクションは、「アクション属性セット」と呼ばれる名前価値ペアのコレクションによって説明されています。アクション属性は、アプリケーションがリクエストを基調講演に伝えるメカニズムであり、基調講演の主要なオブジェクトであるメカニズムです。アクション属性セットは、各クエリで基調講演コンプライアンスチェッカーに渡されます。
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 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.).
アクション属性名と値は、任意の長さの文字列によって表されます。基調講演は、最大2048文字の属性名と値のサポートを保証します。より長い属性名または値の処理は指定されておらず、基調講演に依存します。したがって、アプリケーションとアサーションは、2048文字より長い名前または値を持つ属性の使用に応じて避ける必要があります。属性値の長さは、実装固有のメカニズム（たとえば、ヌル終端文字列、明示的な長さフィールドなど）によって表されます。
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".
属性値は本質的に無型であり、デフォルトでは文字文字列として表されます。属性値には、非NUN 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.
コンプライアンスチェッカーに設定されたアクション属性を渡すための正確なメカニズムは、基調講演の実装によって決定されます。特定の要件に応じて、実装は、属性セット全体をクエリの明示的なパラメーターとして含めるメカニズムを提供する場合があります。また、各属性が標準変数、例えばカーネル変数へのアクセスのために呼び出された何らかのコールバックメカニズムを提供する場合があります。
If an action attribute is not defined its value is considered to be the empty string.
アクション属性が定義されていない場合、その値は空の文字列と見なされます。
Attribute names beginning with the "_" character are reserved for use by the KeyNote runtime environment and cannot be passed from applications as part of queries. The following special attribute names are used:
「_」文字から始まる属性名は、基調講演のランタイム環境で使用するために予約されており、クエリの一部としてアプリケーションから渡すことはできません。次の特別な属性名が使用されます。
Name Purpose
------------------------ ------------------------------------
_MIN_TRUST Lowest-order (minimum) compliance
value in query; see Section 5.1.
_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.
_クエリのコンプライアンス値のセットを直線的に注文する値。セクション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>」という形式の名前を持つ属性は、<n>がAscii-Encoded整数であり、セクション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.
アクション属性セットの他の属性の名前は基調講演では指定されていませんが、特定の基調講演のクエリ評価で操作するポリシーと資格の作家によって合意されなければなりません。
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の1つ以上の繰り返しを意味します。x>。表記<x>は、xの1つ以上の繰り返しを意味しますが、<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行あたり1つのフィールドがあります。
A field may be continued over more than one line by indenting subsequent lines with at least one ASCII SPACE or TAB character. Whitespace (a SPACE, TAB, or NEWLINE character) separates tokens but is otherwise ignored outside of quoted strings. Comments with a leading octothorp character (see Section 4.2) may begin in any column.
少なくとも1つのASCIIスペースまたはタブ文字を伴う後続の線をインデントすることにより、フィールドは複数のラインにわたって継続できます。Whitespace（スペース、タブ、またはNewline文字）はトークンを分離しますが、それ以外の場合は引用された文字列の外で無視されます。主要なOctothorpキャラクター（セクション4.2を参照）のコメントは、任意の列で開始できます。
One mandatory field is required in all assertions:
すべてのアサーションで1つの必須フィールドが必要です。
Authorizer
承認者
Six optional fields may also appear:
6つのオプションフィールドも表示される場合があります。
Comment Conditions KeyNote-Version Licensees Local-Constants Signature
コメント条件KeyNote-versionライセンシーLocal-constants署名
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} ;
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.
「文字列」は、文字のシーケンスを含む語彙オブジェクトです。文字列には、ニューラインや印刷できない文字を含む非ヌール文字が含まれる場合があります。文字列は、リテラルとして与えられたり、複雑な式から計算されたり、属性名から提案されたりすることができます。
<StringLiteral>:: "\"" {see description below} "\"" ;
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 10進）（例えば、「\ "this \"のような\ "のような）でそれを前にすることにより、引用された文字通りの文字通りの内部に「逃げられます」。これにより、文字列リテラル内に二重引用符とバックスラッシュ文字を含めることができます。
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 10進数）を表し、「\ t」はタブ文字（ASCII文字9デシマル）、および「\を表します。f "は、フォームフィード文字（ASCII文字12小数）を表します。バックスラッシュキャラクターに続いて、新しいラインが続くすべての後続の白人（Newlineを含む）を次の非白色文字まで抑制します（これにより、線全体で長い文字列定数の継続が可能になります）。エスケープされていないNewlineおよびReturn Charatureは、文字列リテラル内の違法です。
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:
"\ 0o"、 "\ 0oo"、および「\ oooo "（oは任意のオクタル桁を表す場所）を使用して、対応するoctal値を持つ非nun ascii文字を表すために使用できます（したがって、「\ 012」は「\ n」と同じ、 "\ 101"は「a」、「\ 377」はASCII文字255小数です）。ただし、NUL文字はこの方法でエンコードすることはできません。「\ 0」、「\ 00」、および「\ 000」は、それぞれ文字列「0」、「00」、および「000」に変換されます。同様に、他のすべての脱出されたキャラクターには、リードバックスラッシュが削除されています（例えば、 "\ a"は「a」になり、「\\」が「\ "になります）。次の4つの文字列は同等です。
"this string contains a newline\n followed by one space." "this string contains a newline\n \ followed by one space."
「この文字列には、Newline \ nが続く1つのスペースが含まれています。」「この文字列には、新しいライン\ n \が含まれています。
"this str\ ing contains a \ newline\n followed by one space."
「このstr \ ingには、\ newline \ nが続いて1つのスペースが続きます。」
"this string contains a newline\012\040followed by one space."
「この文字列には、1つのスペースが生成されたNewLine \ 012 \ 040が含まれています。」
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.
アクション属性は、アプリケーションがアサーションに情報を渡すための主要なメカニズムを提供します。属性名は、セクション3で定義されている限られた文字セット（<AttributeID>）の文字列であり、属性値は文字列として内部的に表されます。属性は、単にその名前を使用するだけで参照されます。一般に、基調講演では、文字通りの文字列が許可されている場所で属性を使用できます。
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).
属性は、デフォルトで文字列として参照されます。必要に応じて、型回転型属性を整数または浮動小数点数に変換することができます。したがって、値「1.2」を持つ「foo」という名前の属性は、文字列「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「Long」および「Float」タイプに従って表されます。特に、整数は-2147483648から2147483647の範囲で、フロートは1.17549435E -38Fから3.40282347E 38Fの範囲です。
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」という名前の属性に文字列「バー」が含まれている場合、「bar」という名前の属性には文字列「xyz」が含まれ、属性「xyz」には文字列「qua」が含まれています。：
foo == "bar"
$("foo") == "bar"
$foo == "xyz"
$(foo) == "xyz"
$$foo == "qua"
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> ;
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> ;
4.5.1 Opaque Principal Identifiers
4.5.1 不透明なプリンシパル識別子
Principal Identifiers that are used by KeyNote only as labels are said to be `opaque'. Opaque identifiers are encoded in assertions as strings (see Section 4.3):
基調講演でのみラベルとして使用される主要な識別子は、「不透明」と言われています。不透明な識別子は、文字列としてアサーションでエンコードされます（セクション4.3を参照）：
<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> ;
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> ;
"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）を識別します。慣習により、アルゴリズムのサブストリングはアルファベット文字で始まり、文字、数字、アンダースコア、またはダッシュを含めることができます（つまり、正規表現と一致するはずです。"）。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.
「エンコードビット」は、キーのビットを表す文字のサブストリングであり、そのエンコードと形式はアルゴリズムに依存します。慣習により、ヘキサデシマルエンコードキーは低ケース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
基調講演フィールドは、アサーションが書かれた基調講演のバージョンを識別します。基調様式のバージョンフィールドはフォームです
<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.
ここで、<バージョンストリング>はAscii-Encoded文字列です。基調講演の生産バージョンのアサーションは、それらが解釈される基調講演のバージョン番号を表すバージョンで10進数桁を使用します。このドキュメントに準拠するために書かれたアサーションは、バージョン文字列「2」（または整数2）で識別する必要があります。基調講演フィールドが含まれている場合は、最初に表示される必要があります。
This field adds or overrides action attributes in the current assertion only. This mechanism allows the use of short names for (frequently lengthy) cryptographic principal identifiers, especially to make the Licensees field more readable. The Local-Constants field is of the form:
このフィールドは、現在のアサーションのみにアクション属性を追加またはオーバーライドします。このメカニズムにより、特にライセンシーのフィールドをより読みやすくするために、（頻繁に長い）暗号化されたプリンシパル識別子に短い名前を使用できます。ローカルコンスタントフィールドはフォームです。
<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で定義されているアクション属性名空間の属性名です。名前は、後続のフィールドで属性として使用できます。Local-Constantsフィールドが複数の識別子を定義する場合、複数のラインを占有してインデントすることができます。<StringLiteral>は、セクション4.3で説明されている文字列リテラルです。Local-Constantsフィールドで定義された属性は、アクション属性セットに渡された同じ名前の属性をオーバーライドします。
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.
属性は、ローカルコンスタントフィールドで最大で1回初期化される場合があります。属性がアサーションで複数回初期化されている場合、アサーション全体が無効とみなされ、クエリの評価において基調講演コンプライアンスチェッカーによって考慮されません。
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> ;
<LicenseesExpr>:: /* can be empty */
| <PrincExpr> ;
<PrincExpr>:: "(" <PrincExpr> ")"
| <PrincExpr> "&&" <PrincExpr>
| <PrincExpr> "||" <PrincExpr>
| <K>"-of(" <PrincList> ")" /* Threshold */
| <PrincipalIdentifier>
| <DerefAttribute> ;
<PrincList>:: <PrincipalIdentifier>
| <DerefAttribute>
| <PrincList> "," <PrincList> ;
<K>:: {Decimal number starting with a digit from 1 to 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-Encoded陽性小数整数です。<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> ;
<ConditionsProgram>:: /* Can be empty */
| <Clause> ";" <ConditionsProgram> ;
<Clause>:: <Test> "->" "{" <ConditionsProgram> "}"
| <Test> "->" <Value>
| <Test> ;
<Value>:: <StrEx> ;
<Test>:: <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> ;
<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.
<StringLiteral>は、セクション4.3 <Attiontidid>で定義されている引用文字列です。セクション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).
キーワード「true」と「false」は予約されていません。それらは属性または主要な識別子名として使用できます（ただし、このプラクティスは、アサーションを理解するのが難しくなり、落胆しています）。
<RegExpr> is a standard regular expression, conforming to the POSIX 1003.2 regular expression syntax and semantics.
<Regexpr>は標準的な正規表現であり、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> ;
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> ;
<Signature>:: <StrEx> ;
The <Signature> string should be of the form:
<Signature>文字列はフォームのものでなければなりません。
<IDString>:: <ALGORITHM>":"<ENCODEDBITS> ;
The formats of the "ALGORITHM" and "ENCODEDBITS" substrings are as described for Cryptographic Principal Identifiers in Section 4.4.2 The algorithm name should be the same as that of the principal appearing in the Authorizer field. The IANA (or some other suitable authority) will provide a registry of reserved names. It is not necessary that the encodings of the signature and the authorizer key be the same.
「アルゴリズム」および「エンコードビット」サブストリングの形式は、セクション4.4.2の暗号化プリンシパル識別子について説明されているとおりです。アルゴリズム名は、承認者フィールドに表示されるプリンシパルの名前と同じでなければなりません。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.
* アクション属性セットは、アクションを説明します。
* The set of compliance values of interest to the application, ordered from _MIN_TRUST to _MAX_TRUST
* _min_trustから_max_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.
各クエリで、アクションの「要求者」として少なくとも1つのプリンシパルを識別する必要があります。アクションは、それぞれが個別に要求したと考えられているいくつかの校長によって要求される場合があります。これにより、「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}または{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.
- ASSTIONコンプライアンス値は、Authizerフィールドで<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>の直接認証値は、<x>がアクションの承認者としてクエリにリストされている場合、_max_trustです。それ以外の場合、<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
セクション4.6.5の文法から、条件セクションの各句には2つの論理部分があることを思い出してください：「テスト」と「値」は、存在する場合、「 - >」トークンでテストから分離されています。テストのサブクロースは、成功（論理的な「真」に評価される）または失敗（論理的な「false」と評価）のいずれかの述語です。値のサブクロースは、クエリに与えられた順序付けられたコンプライアンス値のセットから1つの値を評価する文字列式です。値のサブクロースが欠落している場合、それは_max_trustと見なされます。つまり、句です
foo=="bar";
is equivalent to
に相当します
foo=="bar" -> _MAX_TRUST;
If the value component of a clause is present, in the simplest case it contains a string expression representing a possible compliance value. For example, consider an assertion with the following Conditions field:
句の値コンポーネントが存在する場合、最も単純な場合、コンプライアンス値の可能性を表す文字列式が含まれています。たとえば、次の条件フィールドでのアサーションを検討してください。
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」属性が「root」である場合、可能なコンプライアンス値セットには「guest_access」（節（3））と「full_access」（full_access」（条項（4））。クエリ（昇順で）で指定された順序付けられたコンプライアンス値のセット（昇順）のセットが{"no_access"、 "guest_access"、 "user_access"、 "full_access"}の場合、アサーションのコンプライアンス値は「full_access」になります（」full_access "は、「guest_access」よりも高次の値を持っています。「user_id」属性が値「19283」と「user_name」属性が値「誰も」を持っていた場合、条項は成功しず、条件コンプライアンス値は「no_access」になります。）。
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,
句の値コンポーネントには、再帰的にネストされた条項も含まれます。再帰的にネストされた条項は、親テストが真である場合にのみ評価されます。あれは、
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
};
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はfalseです（および値_min_trustがあります）。ただし、サブ2は正常に評価されます。
An invalid <RegExpr> is considered a runtime error and causes the test in which it occurs to be considered false.
無効な<regexpr>は、ランタイムエラーと見なされ、それが発生するテストがfalseと見なされると見なされます。
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.
* 「&&」式には、2つのサブエクスペッション値の低次（最小）があります。
* A "||" expression has the higher-order (maximum) of its two subexpression values.
* 「||」式には、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.
* 「<k> -of（<list>）」式には、<list>にリストされているk番目の最高次数のコンプライアンス値があります。複数回表示される値は、多重度でカウントされます。たとえば、k = 3およびリストされたコンプライアンス値の順序が（0、1、2、2、3）の場合、式の値は注文2のコンプライアンス値です。
For example, consider the following Licensees field:
たとえば、次のライセンシーフィールドを検討してください。
Licensees: ("alice" && "bob") || "eve"
ライセンシー：（ "Alice" && "Bob"）||"イブ"
If the Principal Compliance Value is "yes" for principal "alice", "no" for principal "bob", and "no" for principal "eve", and "yes" is higher order than "no" in the query's Compliance Value Set, then the resulting Licensee Compliance Value is "no".
プリンシパルコンプライアンス値がプリンシパル「アリス」の「はい」、「プリンシパル」ボブの「いいえ」、プリンシパル「イブ」の「いいえ」、「はい」がクエリのコンプライアンス値の「いいえ」よりも高次である場合設定して、結果のライセンシーコンプライアンス値は「いいえ」です。
Observe that if there are exactly two possible compliance values (e.g., "false" and "true"), the rules of Licensee Compliance Value resolution reduce exactly to standard Boolean logic.
コンプライアンスの値が正確に2つある場合（「false」および「true」など）、ライセンシーコンプライアンスの値解像度のルールが標準のブールロジックに正確に減少することを観察します。
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.
基調講演をローカルポリシー仕様としてのみ使用するアプリケーションは、信頼できるアサーションのみを使用する必要があることに注意してください。他のアプリケーションは、他の人が発行し、信頼されていないインターフェイスを介して提出された署名された資格情報で詳細が指定されているポリシーを「ブートストラップ」に「Bootstrap」に変更することなく、少数の頻繁に変更された信頼されたアサーションが必要な場合があります。
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.
プリンシパル<a>から一連のプリンシパル<b>へのいくつかの承認の委任は、校長<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.
読みやすさのために、通常、実際に使用されるよりもはるかに短いキーを使用します。これらの例の署名フィールドは、実際の署名計算の結果を表していないことに注意してください。
1. TRADITIONAL CA / EMAIL
1. 従来のCA /電子メール
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.すべてのアクションに対してRSAキーABC123を無条件に許可するポリシー。これにより、ABC123に対応するシークレットキーの所有者にポリシーを指定する能力が本質的に守られています。
Authorizer: "POLICY" Licensees: "RSA:abc123"
承認者：「ポリシー」ライセンシー：「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. RSAキーABC123がRSAキー4401FF92（「アリス」と呼ばれる）またはDSAキーD1234F（「ボブ」と呼ばれる）のいずれかを信頼して、「app_domain」が「rfc822-email」であるアクションを実行する資格的アサーション。アドレス「正規表現と一致する^。*@keynote \ .research \ .att \ .com $ "。言い換えれば、ABC123は、AliceとBobを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. Blaze」でなければならない特定のユーザーの証明書資格情報。資格情報は、「アリス」当局によって発行されました（その鍵は上記の例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"
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"
2. WORKFLOW/ELECTRONIC COMMERCE
2. ワークフロー/電子商取引
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.
F. RSAキーDAB212リストからの任意の2人の署名者への承認は、@dollars <7500の場合、@dollars <7500の場合は「支出」アプリケーションのDSAキーフィード1234でなければなりません。@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.このポリシーによると、マネージャーのリストの2人の署名者は、 @（ドル）<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からの資格情報ですが、 @（ドル）<500の場合、1つの署名者のみが必要です。
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:
順序付けられたコンプライアンス値のセットが{"reject"、 "appleveandlog"、 "承認"}であるクエリを想定します。ポリシーEおよびG、および資格情報の下では、ポリシーコンプライアンス値は「承認」（_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"
The following return "ApproveAndLog":
次の返品「承認」：
_ACTION_AUTHORIZERS = "DSA:feed1234,DSA:cde333"
app_domain = "SPEND"
dollars = "5500"
and
_ACTION_AUTHORIZERS = "DSA:cde333"
app_domain = "SPEND"
dollars = "150"
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"
KeyNote provides a simple mechanism for describing security policy and representing credentials. It differs from traditional certification systems in that the security model is based on binding keys to predicates that describe what the key is authorized by policy to do, rather than on resolving names. The infrastructure and architecture to support a KeyNote system is therefore rather different from that required for a name-based certification scheme. The KeyNote trust-management architecture is based on that of PolicyMaker [BFL96,BFS98].
Keynoteは、セキュリティポリシーを説明し、資格情報を表すための簡単なメカニズムを提供します。セキュリティモデルは、名前を解決するのではなく、ポリシーによって承認されていることを説明する述語へのバインディングキーに基づいているという点で、従来の認証システムとは異なります。したがって、基調講演システムをサポートするインフラストラクチャとアーキテクチャは、名前ベースの認証スキームに必要なものとはかなり異なります。基調講演の信託管理アーキテクチャは、政策立案者[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.
* アクション属性とその値の割り当ては、アプリケーションのセキュリティ要件を正確に反映する必要があります。アクション属性セットに含める属性を特定することは、おそらく基調講演を新しいアプリケーションに統合する上で最も重要なタスクです。
* 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).
また、特定のクエリを実行する適切な資格とポリシーの主張を選択するのは、アプリケーション（または基調講演外のサービス）次第です。ただし、不適切な資格情報が基調講演に提供されていても、これは違法行為の承認を得ることができないことに注意してください（ポリシーの主張が正しく、アクション属性セット自体が正確に基調講演に渡される限り）。
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スタイルのドキュメントを添付する必要があります。弦の例は「RSA-HEX：」および「DSA-Base64：」です。これらの文字列は症例に依存しません。
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-rsa-md5-hex：」および「sig-dsa-sha1-base64：」です。そのような文字列はすべて、プレフィックス「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.
Lorrie Faith Cranor（AT＆T Labs -Research）とJonathan M. Smith（ペンシルバニア大学）に、この文書の以前のバージョンに関する提案とコメントに感謝します。
B. Full BNF (alphabetical order)
B.フルBNF（アルファベット順）
<ALGORITHM>:: {see section 4.4.2} ;
<Assertion>:: <VersionField>? <AuthField> <LicenseesField>?
<LocalConstantsField>? <ConditionsField>?
<CommentField>? <SignatureField>? ;
<Assignments>:: "" | <AttributeID> "=" <StringLiteral> <Assignments>
;
<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} ;
<AuthField>:: "Authorizer:" <AuthID> ;
<AuthID>:: <PrincipalIdentifier> | <DerefAttribute> ;
<Clause>:: <Test> "->" "{" <ConditionsProgram> "}"
| <Test> "->" <Value> | <Test> ;
<Comment>:: "#" {ASCII characters} ;
<CommentField>:: "Comment:" {Free-form text} ;
<ConditionsField>:: "Conditions:" <ConditionsProgram> ;
<ConditionsProgram>:: "" | <Clause> ";" <ConditionsProgram> ;
<DerefAttribute>:: <AttributeID> ;
<ENCODEDBITS>:: {see section 4.4.2} ;
<FloatEx>:: <FloatEx> "+" <FloatEx> | <FloatEx> "-" <FloatEx>
| <FloatEx> "*" <FloatEx> | <FloatEx> "/" <FloatEx>
| <FloatEx> "^" <FloatEx> | "-" <FloatEx>
| "(" <FloatEx> ")" | <FloatLiteral> | "&" <StrEx> ;
<FloatRelExpr>:: <FloatEx> "<" <FloatEx> | <FloatEx> ">" <FloatEx>
| <FloatEx> "<=" <FloatEx>
| <FloatEx> ">=" <FloatEx> ;
<FloatLiteral>:: <IntegerLiteral>"."<IntegerLiteral> ;
<IDString>:: <ALGORITHM>":"<ENCODEDBITS> ;
<IntegerLiteral>:: {Decimal number of at least one digit} ;
<IntEx>:: <IntEx> "+" <IntEx> | <IntEx> "-" <IntEx>
| <IntEx> "*" <IntEx> | <IntEx> "/" <IntEx>
| <IntEx> "%" <IntEx> | <IntEx> "^" <IntEx>
| "-" <IntEx> | "(" <IntEx> ")" | <IntegerLiteral>
| "@" <StrEx> ;
<IntRelExpr>:: <IntEx> "==" <IntEx> | <IntEx> "!=" <IntEx>
| <IntEx> "<" <IntEx> | <IntEx> ">" <IntEx>
| <IntEx> "<=" <IntEx> | <IntEx> ">=" <IntEx> ;
<K>:: {Decimal number starting with a digit from 1 to 9} ;
<KeyID>:: <StrEx> ;
<LicenseesExpr>:: "" | <PrincExpr> ;
<LicenseesField>:: "Licensees:" <LicenseesExpr> ;
<LocalConstantsField>:: "Local-Constants:" <Assignments> ;
<OpaqueID>:: <StrEx> ;
<PrincExpr>:: "(" <PrincExpr> ")" | <PrincExpr> "&&" <PrincExpr>
| <PrincExpr> "||" <PrincExpr>
| <K>"-of(" <PrincList> ")" | <PrincipalIdentifier>
| <DerefAttribute> ;
<PrincipalIdentifier>:: <OpaqueID> | <KeyID> ;
<PrincList>:: <PrincipalIdentifier> | <DerefAttribute>
| <PrincList> "," <PrincList> ;
<RegExpr>:: {POSIX 1003.2 Regular Expression}
<RelExpr>:: "(" <RelExpr> ")" | <RelExpr> "&&" <RelExpr>
| <RelExpr> "||" <RelExpr> | "!" <RelExpr>
| <IntRelExpr> | <FloatRelExpr> | <StringRelExpr>
| "true" | "false" ;
<Signature>:: <StrEx> ;
<SignatureField>:: "Signature:" <Signature> ;
<StrEx>:: <StrEx> "." <StrEx> | <StringLiteral> | "(" <StrEx> ")"
| <DerefAttribute> | "$" <StrEx> ;
<StringLiteral>:: {see section 4.3.1} ;
<StringRelExpr>:: <StrEx> "==" <StrEx> | <StrEx> "!=" <StrEx>
| <StrEx> "<" <StrEx> | <StrEx> ">" <StrEx>
| <StrEx> "<=" <StrEx> | <StrEx> ">=" <StrEx>
| <StrEx> "~=" <RegExpr> ;
<Test>:: <RelExpr> ;
<Value>:: <StrEx> ;
<VersionField>:: "KeyNote-Version:" <VersionString> ;
<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. Blaze、J。Feigenbaum、J。Lacy。分散化された信頼管理。第17回IEEE Sympの議事録。セキュリティとプライバシーについて。PP 164-173。IEEE Computer Society、1996。
[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. Blaze、J。Feigenbaum、M。Strauss。Policymaker Trust-Managementシステムのコンプライアンスチェック。Proc。第2金融暗号会議。Anguilla1998。LNCS＃1465、pp 251-265、Springer-verlag、1998。
[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. Blaze、J。Feigenbaum、J。Ioannidis、A。Keromytis。分散型システムセキュリティにおける信頼管理の役割。安全なインターネットプログラミングの章：モバイルおよび分散オブジェクトのセキュリティ問題（Vitek and Jensen、編）。Springer-Verlag、1999。
[Cro82] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[CRO82] Crocker、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. Rivest、A。Shamir、L。M。Adleman。デジタル署名とパブリックキー暗号システムを取得する方法。ACMの通信、V21N2。pp 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でホストされている基調講演者メーリングリストで説明する必要があります。購読するには、メッセージ本文の単一行をサブスクライブするKeynote-Usersを含む電子メールメッセージを<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:
このドキュメントに関する質問は、kynote@research.att.comのエイリアスのグループとして、または次のような著者にも著者に送ることができます。
Matt Blaze AT&T Labs - Research 180 Park Avenue Florham Park, New Jersey 07932-0971
Matt Blaze AT＆T Labs -Research180 Park Avenue Florham Park、ニュージャージー07932-0971
EMail: mab@research.att.com
Joan Feigenbaum AT&T Labs - Research 180 Park Avenue Florham Park, New Jersey 07932-0971
Joan Feigenbaum AT＆T Labs -Research180 Park Avenue Florham Park、ニュージャージー07932-0971
EMail: jf@research.att.com
John Ioannidis AT&T Labs - Research 180 Park Avenue Florham Park, New Jersey 07932-0971
John Ioannidis AT＆T Labs -Research180 Park Avenue Florham Park、ニュージャージー07932-0971
EMail: ji@research.att.com
Angelos D. Keromytis Distributed Systems Lab CIS Department, University of Pennsylvania 200 S. 33rd Street Philadelphia, Pennsylvania 19104-6389
Angelos D. Keromytis Distributed Systems Lab CIS Department、University of Pennsylvania 200 S. 33rd Street Philadelphia、Pennsylvania 19104-6389
EMail: angelos@dsl.cis.upenn.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。