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
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
KeyNote信任管理系统版本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.
本备忘录介绍了KeyNote信任管理系统的第2版。它指定了注释记号“断言”的语法和语义，描述了“动作属性”处理，并概述了适用于注释记号实现的应用程序体系结构。KeyNote体系结构和语言作为各种Internet协议和服务的信任管理方面的构建块非常有用。
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.
在决策者系统[BFL96]中引入的信任管理是指定和解释安全策略、凭证和关系的统一方法；它允许对安全关键操作进行直接授权。信任管理系统提供用于指定应用程序安全策略和凭据的标准通用机制。信任管理凭据描述特定的信任委托，并包含公钥证书的角色；与将密钥绑定到名称的传统证书不同，凭据可以将密钥直接绑定到授权以执行特定任务。
A trust-management system has five basic components:
信任管理系统有五个基本组件：
* 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.
信任管理统一了安全策略、凭据、访问控制和授权的概念。使用信任管理系统的应用程序只需询问合规性检查器是否应允许请求的操作。此外，策略和凭据使用标准语言编写，所有受信任管理的应用程序共享这些语言；一个应用程序的安全配置机制与另一个应用程序的安全配置机制具有完全相同的语法和语义结构，即使应用程序本身的语义非常不同。
Trust-management policies are easy to distribute across networks, helping to avoid the need for application-specific distributed policy configuration mechanisms, access control lists, and certificate parsers and interpreters.
信任管理策略易于跨网络分发，有助于避免需要特定于应用程序的分布式策略配置机制、访问控制列表以及证书解析器和解释器。
For a general discussion of the use of trust management in distributed system security, see [Bla99].
有关在分布式系统安全中使用信任管理的一般性讨论，请参阅[Bla99]。
KeyNote is a simple and flexible trust-management system designed to work well for a variety of large- and small-scale Internet-based applications. It provides a single, unified language for both local policies and credentials. KeyNote policies and credentials, called `assertions', contain predicates that describe the trusted actions permitted by the holders of specific public keys. KeyNote assertions are essentially small, highly-structured programs. A signed
KeyNote是一个简单灵活的信任管理系统，设计用于各种大型和小型基于Internet的应用程序。它为本地策略和凭据提供了一种统一的语言。KeyNote策略和凭据（称为“断言”）包含描述特定公钥持有者允许的可信操作的谓词。基调断言本质上是小型的、高度结构化的程序。签名
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.
我们假设应用程序通过“函数调用”样式的界面与本地受信任的注释记号符合性检查器通信，发送注释记号策略和凭证断言的集合以及操作描述作为输入，并接受结果策略符合性值作为输出。但是，不同应用程序、主机和环境的要求可能会导致KeyNote compliance Checker的各种不同接口；本文档的目的不是指定完整的合规性检查器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中，执行受信任操作的权限与一个或多个“主体”相关联。主体可以是物理实体、操作系统中的进程、公钥或任何其他方便的抽象。注释记号主体由名为“主体标识符”的字符串标识。在某些情况下，主标识符将包含由
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.
主体执行两项与KeyNote相关的功能：请求“操作”和发出“断言”。操作是应用程序置于注释记号控制下的任何受信任的操作。断言将执行操作的授权委托给其他主体。
Actions are described to the KeyNote compliance checker in terms of a collection of name-value pairs called an `action attribute set'. The action attribute set is created by the invoking application. Its structure and format are described in detail in Section 3 of this document.
根据名为“动作属性集”的名称-值对集合，向注释记号符合性检查器描述动作。动作属性集由调用应用程序创建。本文件第3节详细描述了其结构和格式。
KeyNote provides advice to applications about the interpretation of policy with regard to specific requested actions. Applications invoke the KeyNote compliance checker by issuing a `query' containing a proposed action attribute set and identifying the principal(s) requesting it. The KeyNote system determines and returns an appropriate `policy compliance value' from an ordered set of possible responses.
KeyNote为应用程序提供有关特定请求操作的政策解释的建议。应用程序通过发出一个“查询”来调用KeyNote compliance checker，该查询包含一个建议的操作属性集，并标识请求该属性集的主体。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.
一个标识符为“POLICY”的特殊主体在KeyNote中提供信任的根。因此，“政策”被视为有权执行任何行动。
Assertions issued by the "POLICY" principal are called `policy assertions' and are used to delegate authority to otherwise untrusted principals. The KeyNote security policy of an application consists of a collection of policy assertions.
“策略”主体发出的断言称为“策略断言”，用于将权限委托给其他不受信任的主体。应用程序的KeyNote安全策略由一组策略断言组成。
When a principal is identified by a public key, it can digitally sign assertions and distribute them over untrusted networks for use by other KeyNote compliance checkers. These signed assertions are also called `credentials', and serve a role similar to that of traditional public key certificates. Policies and credentials share the same syntax and are evaluated according to the same semantics. A principal can therefore convert its policy assertions into credentials simply by digitally signing them.
当主体由公钥标识时，它可以对断言进行数字签名，并将其分发到不受信任的网络上，供其他KeyNote合规性检查人员使用。这些签名断言也称为“凭证”，其作用类似于传统公钥证书。策略和凭据共享相同的语法，并根据相同的语义进行评估。因此，主体只需对其策略断言进行数字签名，即可将其转换为凭据。
KeyNote is designed to encourage the creation of human-readable policies and credentials that are amenable to transmission and storage over a variety of media. Its assertion syntax is inspired by the format of RFC822-style message headers [Cro82]. A KeyNote assertion contains a sequence of sections, called `fields', each of which specifies one aspect of the assertion's semantics. Fields start with an identifier at the beginning of a line and continue until the next field is encountered. For example:
KeyNote旨在鼓励创建易于通过各种媒体传输和存储的可读策略和凭证。其断言语法受RFC822样式消息头[Cro82]格式的启发。注释记号断言包含一系列称为“字段”的部分，每个部分指定断言语义的一个方面。字段以行首的标识符开始，并一直持续到遇到下一个字段。例如：
KeyNote-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"
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.
注释记号语义解决了应用程序的策略与其他主体请求的操作之间的关系，这由凭据支持。KeyNote compliance checker根据动作属性集处理断言，以确定所请求动作的策略符合性值。这些语义在第5节中有定义。
An important principle in KeyNote's design is `assertion monotonicity'; the policy compliance value of an action is always positively derived from assertions made by trusted principals. Removing an assertion never results in increasing the compliance value returned by KeyNote for a given query. The monotonicity
基调设计的一个重要原则是“断言单调性”；操作的策略遵从性值总是从可信主体所做的断言中得到。删除断言不会导致增加给定查询的KeyNote返回的符合性值。单调性
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.
由KeyNote评估的受信任操作由名为“操作属性集”的名称-值对集合描述。动作属性是应用程序向注释记号传递请求的机制，也是注释记号断言操作的主要对象。每个查询都会将动作属性集传递给注释记号符合性检查器。
Each action attribute consists of a name and a value. The semantics of the names and values are not interpreted by KeyNote itself; they vary from application to application and must be agreed upon by the writers of applications and the writers of the policies and credentials that will be used by them.
每个动作属性由一个名称和一个值组成。名称和值的语义不由注释记号本身解释；它们因应用程序而异，并且必须由应用程序的编写者以及将由其使用的策略和凭据的编写者同意。
Action attribute names and values are represented by arbitrary-length strings. KeyNote guarantees support of attribute names and values up to 2048 characters long. The handling of longer attribute names or values is not specified and is KeyNote-implementation-dependent. Applications and assertions should therefore avoid depending on the the use of attributes with names or values longer than 2048 characters. The length of an attribute value is represented by an implementation-specific mechanism (e.g., NUL-terminated strings, an explicit length field, etc.).
操作属性名称和值由任意长度的字符串表示。KeyNote保证支持最长2048个字符的属性名称和值。较长属性名称或值的处理未指定，且取决于注释记号实现。因此，应用程序和断言应避免使用名称或值超过2048个字符的属性。属性值的长度由特定于实现的机制表示（例如，以NUL结尾的字符串、显式长度字段等）。
Attribute values are inherently untyped and are represented as character strings by default. Attribute values may contain any non-NUL ASCII character. Numeric attribute values should first be converted to an ASCII text representation by the invoking application, e.g., the value 1234.5 would be represented by the string "1234.5".
属性值本质上是非类型化的，默认情况下表示为字符串。属性值可以包含任何非NUL ASCII字符。数值属性值应首先由调用应用程序转换为ASCII文本表示，例如，值1234.5将由字符串“1234.5”表示。
Attribute names are of the form:
属性名称的形式如下：
<AttributeID>:: {Any string starting with a-z, A-Z, or the
underscore character, followed by any number of
a-z, A-Z, 0-9, or underscore characters} ;
<AttributeID>:: {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:
以“\”字符开头的属性名称保留供KeyNote运行时环境使用，不能作为查询的一部分从应用程序中传递。使用以下特殊属性名称：
Name Purpose
------------------------ ------------------------------------
_MIN_TRUST Lowest-order (minimum) compliance
value in query; see Section 5.1.
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.
_最大信任查询中的最高顺序（最大）符合性值；见第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\授权人直接授权查询中操作的主体的名称。逗号分隔。
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.
此外，第5节中描述的正则表达式匹配机制使用了名为“<N>”的属性，其中<N>是ASCII编码的整数。
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_域名的注册。注册表将列出每个应用程序属性的名称和含义。
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_域约定有助于确保凭据按预期进行解释。具有任何给定名称的属性可以在许多不同的应用程序域中使用，但在每个应用程序域中可能具有不同的含义。然而，对于小规模、封闭的应用程序，并不总是需要使用全局注册表；唯一的要求是，提供给KeyNote compliance checker的策略和凭据必须根据创建属性的应用程序假定的相同语义来解释属性。
For example, an email application might reserve the app_domain "RFC822-EMAIL" and might use the attributes named "address" (the email address of a message's sender), "name" (the human name of the message sender), and any "organization" headers present (the organization name). The values of these attributes would be derived in the obvious way from the email message headers. The public key of the message's signer would be given in the "_ACTION_AUTHORIZERS" attribute.
例如，电子邮件应用程序可能保留应用程序域“RFC822-email”，并可能使用名为“address”（邮件发件人的电子邮件地址）、“name”（邮件发件人的人名）和任何存在的“organization”（组织名）标题的属性。这些属性的值将以显而易见的方式从电子邮件消息头中派生。消息签名者的公钥将在“\u ACTION\u 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的零次或一次重复。非终结语法符号用尖括号括起来。语法产品中的带引号的字符串表示终端。
<Assertion>:: <VersionField>? <AuthField> <LicenseesField>?
<LocalConstantsField>? <ConditionsField>?
<CommentField>? <SignatureField>? ;
<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.
注释记号断言被分为称为“字段”的部分，用于各种语义功能。每个字段都以行首的标识标签开头，后跟“：”字符和字段内容。每行最多只能有一个字段。
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空格或制表符缩进后续行，可以在多行上继续字段。空格（空格、制表符或换行符）分隔标记，但在带引号的字符串之外被忽略。带有前导八位字符的注释（见第4.2节）可以在任何列中开始。
One mandatory field is required in all assertions:
所有断言中都需要一个必填字段：
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.
所有字段名都不区分大小写。“注释记号版本”字段（如果存在）将首先显示。“签名”字段（如果存在）最后出现。否则，字段可能以任何顺序出现。每个字段在任何断言中最多只能出现一次。
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} ;
<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).
八进制字符（“#”，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>:: "\"" {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十进制）（例如，“like\“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十进制），“\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:
构造“\0o”、“\0oo”和“\ooo”（其中o表示任何八进制数字）可用于表示任何非NUL ASCII字符及其相应的八进制值（因此，“\012”与“\n”相同，“\101”为“A”；“\377”为ASCII字符255十进制）。但是，NUL字符不能以这种方式编码；“\0”、“\00”和“\000”分别转换为字符串“0”、“00”和“000”。同样，所有其他转义字符的前导反斜杠都已删除（例如，“\a”变为“a”，“\\”变为“\”）。以下四个字符串是等效的：
"this string contains a newline\n followed by one space." "this string contains a newline\n \ followed by one space."
“此字符串包含一个新行，\n后跟一个空格。”“此字符串包含一个新行\n \后跟一个空格。”
"this str\ ing contains a \ newline\n followed by one space."
“此字符串包含一个\newline\n后跟一个空格。”
"this string contains a newline\012\040followed by one space."
“此字符串包含一个换行符\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 */
<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节所定义），属性值在内部表示为字符串。属性只需使用其名称即可取消引用。通常，KeyNote允许在允许字符串文字的任何位置使用属性。
Attributes are dereferenced as strings by default. When required, dereferenced attributes can be converted to integers or floating point numbers with the type conversion operators "@" and "&". Thus, an attribute named "foo" having the value "1.2" may be interpreted as the string "1.2" (foo), the integer value 1 (@foo), or the floating point value 1.2 (&foo).
默认情况下，属性作为字符串取消引用。必要时，可以使用类型转换运算符“@”和“&”将取消引用的属性转换为整数或浮点数。因此，具有值“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:
属性名称可以按字面形式给出，也可以根据字符串表达式计算，还可以递归地取消引用。在最简单的情况下，属性只需在引号外使用其名称即可取消引用；e、 例如，名为“foo”的属性的字符串值是通过引用“foo”（引号之外）来表示的。“$<StrEx>”构造取消引用字符串表达式<StrEx>中命名的属性。例如，如果名为“foo”的属性包含字符串“bar”，名为“bar”的属性包含字符串“xyz”，而属性“xyz”包含字符串“qua”，则以下字符串比较均为真：
foo == "bar"
$("foo") == "bar"
$foo == "xyz"
$(foo) == "xyz"
$$foo == "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> ;
<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字符串。主标识符可以是任意标签，其结构不由KeyNote系统解释，也可以对KeyNote用于凭证签名验证的加密密钥进行编码。
<PrincipalIdentifier>:: <OpaqueID>
| <KeyID> ;
<PrincipalIdentifier>:: <OpaqueID>
| <KeyID> ;
4.5.1 Opaque Principal Identifiers
4.5.1 不透明主标识符
Principal Identifiers that are used by KeyNote only as labels are said to be `opaque'. Opaque identifiers are encoded in assertions as strings (see Section 4.3):
仅由注释记号用作标签的主要标识符称为“不透明”。不透明标识符在断言中编码为字符串（见第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:
KeyNote用作密钥的主要标识符（例如，用于验证凭证签名）称为“加密”。加密标识符也按词汇编码为字符串：
<KeyID>:: <StrEx> ;
<KeyID>:: <StrEx> ;
Unlike Opaque Identifiers, however, Cryptographic Identifier strings have a special form. To be interpreted by KeyNote (for signature verification), an identifier string should be of the form:
但是，与不透明标识符不同，加密标识符字符串具有特殊形式。要由注释记号解释（用于签名验证），标识符字符串的形式应为：
<IDString>:: <ALGORITHM>":"<ENCODEDBITS> ;
<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]）和密钥位编码（如十六进制或BASE64）。按照惯例，算法子字符串以字母字符开头，可以包含字母、数字、下划线或破折号（即，它应该匹配正则表达式“[a-zA-Z][a-zA-Z0-9_-]*”）。IANA（或其他相关机构）将提供保留算法标识符的注册表。
"ENCODEDBITS" is a substring of characters representing the key's bits, the encoding and format of which depends on the ALGORITHM. By convention, hexadecimal encoded keys use lower-case ASCII characters.
“ENCODEDBITS”是表示密钥位的字符的子字符串，其编码和格式取决于算法。按照惯例，十六进制编码键使用小写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> ;
<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）标识。注释记号版本字段（如果包括）应首先显示。
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> ;
<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节中定义的动作属性名称空间中的属性名称。该名称可用作任何后续字段中的属性。如果本地常量字段定义了多个标识符，则它可以占用多行并缩进<StringLiteral>是一个字符串文字，如第4.3节所述。在Local Constants字段中定义的属性将覆盖与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> ;
<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
Licensees字段标识由断言授权的主体。可以对多个主体进行授权，并且可以通过使用“和”和阈值结构跨多个主体分发授权。此字段的格式为
<LicenseesField>:: "Licensees:" <LicenseesExpr> ;
<LicenseesField>:: "Licensees:" <LicenseesExpr> ;
<LicenseesExpr>:: /* can be empty */
| <PrincExpr> ;
<LicenseesExpr>:: /* can be empty */
| <PrincExpr> ;
<PrincExpr>:: "(" <PrincExpr> ")"
| <PrincExpr> "&&" <PrincExpr>
| <PrincExpr> "||" <PrincExpr>
| <K>"-of(" <PrincList> ")" /* Threshold */
| <PrincipalIdentifier>
| <DerefAttribute> ;
<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>:: {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编码的正十进制整数。如果<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>:: "Conditions:" <ConditionsProgram> ;
<ConditionsProgram>:: /* Can be empty */
| <Clause> ";" <ConditionsProgram> ;
<ConditionsProgram>:: /* Can be empty */
| <Clause> ";" <ConditionsProgram> ;
<Clause>:: <Test> "->" "{" <ConditionsProgram> "}"
| <Test> "->" <Value>
| <Test> ;
<Clause>:: <Test> "->" "{" <ConditionsProgram> "}"
| <Test> "->" <Value>
| <Test> ;
<Value>:: <StrEx> ;
<Value>:: <StrEx> ;
<Test>:: <RelExpr> ;
<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 */
<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>:: <IntEx> "==" <IntEx>
| <IntEx> "!=" <IntEx>
| <IntEx> "<" <IntEx>
| <IntEx> ">" <IntEx>
| <IntEx> "<=" <IntEx>
| <IntEx> ">=" <IntEx> ;
<FloatRelExpr>:: <FloatEx> "<" <FloatEx>
| <FloatEx> ">" <FloatEx>
| <FloatEx> "<=" <FloatEx>
| <FloatEx> ">=" <FloatEx> ;
<FloatRelExpr>:: <FloatEx> "<" <FloatEx>
| <FloatEx> ">" <FloatEx>
| <FloatEx> "<=" <FloatEx>
| <FloatEx> ">=" <FloatEx> ;
<StringRelExpr>:: <StrEx> "==" <StrEx> /* String equality */
| <StrEx> "!=" <StrEx> /* String inequality */
| <StrEx> "<" <StrEx> /* Alphanum. comparisons */
| <StrEx> ">" <StrEx>
| <StrEx> "<=" <StrEx>
| <StrEx> ">=" <StrEx>
| <StrEx> "~=" <RegExpr> ; /* Reg. expr. matching */
<StringRelExpr>:: <StrEx> "==" <StrEx> /* 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> ;
<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> "+" <FloatEx> /* Floating point */
| <FloatEx> "-" <FloatEx>
| <FloatEx> "*" <FloatEx>
| <FloatEx> "/" <FloatEx>
| <FloatEx> "^" <FloatEx> /* Exponentiation */
| "-" <FloatEx>
| "(" <FloatEx> ")"
| <FloatLiteral>
| "&" <StrEx> ;
| "-" <FloatEx>
| "(" <FloatEx> ")"
| <FloatLiteral>
| "&" <StrEx> ;
<IntegerLiteral>:: {Decimal number of at least one digit} ;
<FloatLiteral>:: <IntegerLiteral>"."<IntegerLiteral> ;
<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节中定义的带引号的字符串。
The operation precedence classes are (from highest to lowest):
{ (, ) }
{unary -, @, &, $}
{^}
{*, /, %}
{+, -, .}
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.
<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> ;
<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).
注释记号不解释此字段的内容。注意，这是在注释记号断言中包含注释的两种机制之一；注释也可以通过在其前面加“#”字符（字符串文本内部除外）插入到断言正文的任何位置。
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:" <Signature> ;
<Signature>:: <StrEx> ;
<Signature>:: <StrEx> ;
The <Signature> string should be of the form:
<Signature>字符串的格式应为：
<IDString>:: <ALGORITHM>":"<ENCODEDBITS> ;
<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.
“算法”和“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.
如果包含签名字段，则授权人字段中指定的主体必须是加密主体标识符，KeyNote实现必须知道算法，并且断言主体和授权人密钥的签名必须正确。
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.
计算和验证签名的算法必须配置到每个KeyNote实现中，并单独定义和记录。
Note that all signatures used in examples in this document are fictitious and generally much shorter than would be required for security in practice.
请注意，本文件示例中使用的所有签名都是虚构的，通常比实际安全性要求的签名短得多。
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:
注释记号查询有四个参数：
* 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.
在每个查询中，必须至少将一个主体标识为操作的“请求者”。多个负责人可能会要求采取行动，每个人都被视为单独要求采取行动。这允许需要多个授权的策略，例如“两人控制”。授权主体集在特殊属性“\u ACTION\u 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，APPROVE}。其他应用程序可能需要一系列可能的值，例如{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.
查询中给出的最低阶和最高阶符合性值字符串分别位于名为“\u MIN\u TRUST”和“\u MAX\u TRUST”的特殊属性中。在名为“\u values”的特殊属性中，以升序（从_MIN\u TRUST到_MAX\u 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.
KeyNote中使用的每个加密算法都定义了一种方法，用于将密钥转换为其标准形式，并指定如何执行两个密钥相等的比较。如果注释记号不知道标识符中命名的算法，则该标识符将被视为不透明。
Opaque identifiers are compared as case-sensitive strings.
不透明标识符作为区分大小写的字符串进行比较。
Notice that use of opaque identifiers in the Authorizer field requires that the assertion's integrity be locally trusted (since it cannot be cryptographically verified by the compliance checker).
请注意，在Authorizer字段中使用不透明标识符要求断言的完整性在本地受信任（因为它不能由遵从性检查器进行加密验证）。
The Policy Compliance Value of a query is the Principal Compliance Value of the principal named "POLICY". This value is defined as follows:
查询的策略符合性值是名为“Policy”的主体的主体符合性值。该值定义如下：
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>列为操作的授权人，则主体<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.
断言的Conditions Compliance值是Conditions部分中列出的所有成功子句中的最高顺序（最大）值。
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_信任值。
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_信任值。
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节的语法，条件部分中的每个子句都有两个逻辑部分：一个“test”和一个可选的“value”，如果存在，则用“->”标记与测试分开。test子类是一个成功（计算结果为逻辑“true”）或失败（计算结果为逻辑“false”）的谓词。value子类是一个字符串表达式，其计算结果为查询中给定的符合性值的有序集合中的一个值。如果缺少值子项，则将其视为_MAX_TRUST。即该条
foo=="bar";
foo=="bar";
is equivalent to
相当于
foo=="bar" -> _MAX_TRUST;
foo=="bar" -> _MAX_TRUST;
If the value component of a clause is present, in the simplest case it contains a string expression representing a possible compliance value. For example, consider an assertion with the following Conditions field:
如果存在子句的值组件，在最简单的情况下，它包含一个表示可能的符合性值的字符串表达式。例如，考虑具有下列条件字段的断言：
Conditions:
@user_id == 0 -> "full_access"; # clause (1)
@user_id < 1000 -> "user_access"; # clause (2)
@user_id < 10000 -> "guest_access"; # clause (3)
user_name == "root" -> "full_access"; # clause (4)
Conditions:
@user_id == 0 -> "full_access"; # clause (1)
@user_id < 1000 -> "user_access"; # clause (2)
@user_id < 10000 -> "guest_access"; # clause (3)
user_name == "root" -> "full_access"; # clause (4)
Here, if the value of the "user_id" attribute is "1073" and the "user_name" attribute is "root", the possible compliance value set would contain the values "guest_access" (by clause (3)) and "full_access" (by clause (4)). If the ordered set of compliance values given in the query (in ascending order) is {"no_access", "guest_access", "user_access", "full_access"}, the Conditions Compliance Value of the assertion would be "full_access" (because "full_access" has a higher-order value than "guest_access"). If the "user_id" attribute had the value "19283" and the "user_name" attribute had the value "nobody", no clause would succeed and the Conditions Compliance Value would be "no_access", which is the lowest-order possible value (_MIN_TRUST).
这里，如果“user_id”属性的值是“1073”并且“user_name”属性是“root”，则可能的符合性值集将包含值“guest_access”（根据第（3）条）和“full_access”（根据第（4）条）。如果查询中给出的符合性值的有序集（升序）是{“no_access”、“guest_access”、“user_access”、“full_access”}，则断言的条件符合性值将是“full_access”（因为“full_access”的顺序值高于“guest_access”）。如果“user_id”属性的值为“19283”，而“user_name”属性的值为“nobody”，则任何子句都不会成功，条件符合性值将为“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"; } ;
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";
(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 == "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>被视为运行时错误，并导致出现该错误的测试被视为错误。
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.
断言的被许可方符合性值是通过计算Licensees字段中的表达式来计算的，该表达式基于此处指定的主体的主体符合性值。
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.
如果断言的Licensees字段为空，则其Licensees Compliance值被视为_MIN_TRUST。如果断言的Licensees字段完全缺失，则其Licensees Compliance值被视为_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 "&&" expression has the lower-order (minimum) of its two subexpression values.
* “&&”表达式具有其两个子表达式值的较低阶（最小值）。
* A "||" expression has the higher-order (maximum) of its two subexpression values.
* “| |”表达式具有其两个子表达式值的高阶（最大值）。
* A "<K>-of(<List>)" expression has the K-th highest order compliance value listed in <list>. Values that appear multiple times are counted with multiplicity. For example, if K = 3 and the orders of the listed compliance values are (0, 1, 2, 2, 3), the value of the expression is the compliance value of order 2.
* “<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”）| |“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".
如果主体“alice”的主体符合性值为“yes”，主体“bob”的主体符合性值为“no”，主体“eve”的主体符合性值为“no”，并且“yes”在查询的符合性值集中的顺序高于“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.
请注意，如果恰好有两个可能的符合性值（例如，“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).
断言可以是有符号的，也可以是无符号的。只有经过签名的断言才能用作凭据，或在不受信任的媒体上传输或存储。未签名断言应仅用于指定策略，并用于其完整性已通过KeyNote系统本身外部的某种机制验证为符合本地策略的断言（例如，通过可信转换程序转换为KeyNote断言的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.
允许KeyNote compliance checker验证签名凭据的实现通常提供两个“通道”，应用程序可以通过这两个“通道”使用断言。未签名的本地受信任断言通过“受信任”接口提供，而签名凭据通过“不受信任”接口提供。KeyNote compliance checker验证通过不受信任的接口提交的所有断言的正确签名。KeyNote评估的完整性要求仅通过可信接口将反映本地策略的可信断言提交给KeyNote。
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.
请注意，专门使用KeyNote作为本地策略规范机制的应用程序只需要使用可信断言。其他应用程序可能只需要少量很少更改的受信任断言即可“引导”策略，该策略的详细信息在其他人颁发的签名凭据中指定，并通过不受信任的接口提交。
Informally, the semantics of KeyNote evaluation can be thought of as involving the construction a directed graph of KeyNote assertions rooted at a POLICY assertion that connects with at least one of the principals that requested the action.
非正式地说，注释记号评估的语义可以被认为涉及构建一个基于策略断言的注释记号断言的有向图，该策略断言与请求操作的至少一个主体连接。
Delegation of some authorization from principal <A> to a set of principals <B> is expressed as an assertion with principal <A> given in the Authorizer field, principal set <B> given in the Licensees field, and the authorization to be delegated encoded in the Conditions field. How the expression digraph is constructed is implementation-dependent and implementations may use different algorithms for optimizing the graph's construction. Some implementations might use a `bottom up' traversal starting at the principals that requested the action, others might follow a `top down' approach starting at the POLICY assertions, and still others might employ other heuristics entirely.
将某些授权从主体<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.
在本节中，我们将给出可能在假设应用程序中使用的注释记号断言的示例。这些示例主要用于说明KeyNote断言语法和语义的功能，并不一定代表将KeyNote集成到应用程序中的最佳方式。
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（称为'Alice'）或DSA密钥d1234f（称为'Bob'）来执行“应用程序域”为“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"
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如果有，他的名字一定是“布莱泽先生”。凭证由“Alice”机构颁发（其密钥在上述示例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"
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.特定用户的另一个证书凭证，也是由“Alice”机构颁发的。此示例允许三个不同的键作为签名jf@keynote.research.att.com（每个用于不同的加密算法）。实际上，这是三个凭证合一：
KeyNote-Version: "2"
Authorizer: "DSA:4401ff92" # the Alice CA
Licensees: "DSA:abc991" || # jf's DSA key
"RSA:cde773" || # jf's RSA key
"BFIK:fd091a" # jf's BFIK key
Conditions: ((app_domain == "RFC822-EMAIL") &&
(name == "J. Feigenbaum" || name == "") &&
(address == "jf@keynote.research.att.com"));
Signature: "DSA-SHA1:8912aa"
KeyNote-Version: "2"
Authorizer: "DSA:4401ff92" # the Alice CA
Licensees: "DSA:abc991" || # jf's DSA key
"RSA:cde773" || # jf's RSA key
"BFIK:fd091a" # jf's BFIK key
Conditions: ((app_domain == "RFC822-EMAIL") &&
(name == "J. Feigenbaum" || name == "") &&
(address == "jf@keynote.research.att.com"));
Signature: "DSA-SHA1:8912aa"
Observe that under policy A and credentials B, C and D, the following action attribute sets are accepted (they return _MAX_TRUST):
请注意，在策略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"
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_信任）：
_ACTION_AUTHORIZERS = "dsa:12340987"
app_domain = "RFC822-EMAIL"
address = "angelos@dsl.cis.upenn.edu"
and
_ACTION_AUTHORIZERS = "dsa:abc991"
app_domain = "RFC822-EMAIL"
address = "mab@keynote.research.att.com"
name = "M. Blaze"
and
_ACTION_AUTHORIZERS = "dsa:12340987"
app_domain = "RFC822-EMAIL"
address = "mab@keynote.research.att.com"
name = "J. Feigenbaum"
_ACTION_AUTHORIZERS = "dsa:12340987"
app_domain = "RFC822-EMAIL"
address = "angelos@dsl.cis.upenn.edu"
and
_ACTION_AUTHORIZERS = "dsa:abc991"
app_domain = "RFC822-EMAIL"
address = "mab@keynote.research.att.com"
name = "M. Blaze"
and
_ACTION_AUTHORIZERS = "dsa:12340987"
app_domain = "RFC822-EMAIL"
address = "mab@keynote.research.att.com"
name = "J. Feigenbaum"
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);
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将授权委托给列表中的任意两个签名者，其中一个签名者必须是@USD<7500时“支出”应用程序中的DSA密钥feed1234。如果@美元的金额大于等于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"
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.根据该政策，如果@（美元）<1000美元，则经理名单中的任何两名签字人都可以：
KeyNote-Version: 2
Authorizer: "POLICY"
Licensees: 2-of("DSA:feed1234", # The VP
"RSA:abc123", # Middle management clones
"DSA:bcd987",
"DSA:cde333",
"DSA:def975",
"DSA:978add")
Conditions: (app_domain=="SPEND") &&
(@(dollars) < 1000);
KeyNote-Version: 2
Authorizer: "POLICY"
Licensees: 2-of("DSA:feed1234", # The VP
"RSA:abc123", # Middle management clones
"DSA:bcd987",
"DSA:cde333",
"DSA:def975",
"DSA:978add")
Conditions: (app_domain=="SPEND") &&
(@(dollars) < 1000);
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，则只需要一名签名人。如果金额至少为100，则会创建日志条目。
KeyNote-Version: 2
Comment: This one credential is equivalent to six separate
credentials, one for each VP and middle manager.
Individually, they can spend up to $500, but if
it's $100 or more, we log it.
Authorizer: "RSA:dab212" # From the CFO
Licensees: "DSA:feed1234" || # The VP
"RSA:abc123" || # The middle management clones
"DSA:bcd987" ||
"DSA:cde333" ||
"DSA:def975" ||
"DSA:978add"
Conditions: (app_domain="SPEND") # nested clauses
-> { (@(dollars) < 100) -> _MAX_TRUST;
(@(dollars) < 500) -> "ApproveAndLog";
};
Signature: "RSA-SHA1:186123"
KeyNote-Version: 2
Comment: This one credential is equivalent to six separate
credentials, one for each VP and middle manager.
Individually, they can spend up to $500, but if
it's $100 or more, we log it.
Authorizer: "RSA:dab212" # From the CFO
Licensees: "DSA:feed1234" || # The VP
"RSA:abc123" || # The middle management clones
"DSA:bcd987" ||
"DSA:cde333" ||
"DSA:def975" ||
"DSA:978add"
Conditions: (app_domain="SPEND") # nested clauses
-> { (@(dollars) < 100) -> _MAX_TRUST;
(@(dollars) < 500) -> "ApproveAndLog";
};
Signature: "RSA-SHA1:186123"
Assume a query in which the ordered set of Compliance Values is {"Reject", "ApproveAndLog", "Approve"}. Under policies E and G, and credentials F and H, the Policy Compliance Value is "Approve" (_MAX_TRUST) when:
假设一个查询，其中符合性值的有序集为{“拒绝”、“批准”和“批准”}。在策略E和G以及凭据F和H下，在以下情况下，策略符合性值为“批准”（_MAX_信任）：
_ACTION_AUTHORIZERS = "DSA:978add"
app_domain = "SPEND"
dollars = "45"
unmentioned_attribute = "whatever"
and
_ACTION_AUTHORIZERS = "RSA:abc123,DSA:cde333"
app_domain = "SPEND"
dollars = "550"
_ACTION_AUTHORIZERS = "DSA:978add"
app_domain = "SPEND"
dollars = "45"
unmentioned_attribute = "whatever"
and
_ACTION_AUTHORIZERS = "RSA:abc123,DSA:cde333"
app_domain = "SPEND"
dollars = "550"
The following return "ApproveAndLog":
以下返回“ApproveAndLog”：
_ACTION_AUTHORIZERS = "DSA:feed1234,DSA:cde333"
app_domain = "SPEND"
dollars = "5500"
and
_ACTION_AUTHORIZERS = "DSA:cde333"
app_domain = "SPEND"
dollars = "150"
_ACTION_AUTHORIZERS = "DSA:feed1234,DSA:cde333"
app_domain = "SPEND"
dollars = "5500"
and
_ACTION_AUTHORIZERS = "DSA:cde333"
app_domain = "SPEND"
dollars = "150"
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 = "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提供了一种简单的机制来描述安全策略和表示凭据。它不同于传统的认证系统，因为安全模型基于将密钥绑定到描述策略授权密钥执行的操作的谓词，而不是解析名称。因此，支持KeyNote系统的基础设施和体系结构与基于名称的认证方案所需的基础设施和体系结构大不相同。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:
理解KeyNote系统的职责与应用程序和其他支持基础架构的职责之间的分离非常重要。KeyNote compliance checker将根据策略和凭证断言确定根据策略是否允许提议的操作。基调输出作为策略执行机制的有用性取决于许多因素：
* 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.
* 操作属性及其值的分配必须准确反映应用程序的安全要求。在将KeyNote集成到新应用程序中时，识别要包含在动作属性集中的属性可能是最重要的任务。
* 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.
* 应用程序本身必须是可信的。KeyNote不直接执行策略；它只向调用它的应用程序提供建议。换句话说，KeyNote假定应用程序本身是可信的，并且它指定的策略断言是正确的。没有任何东西可以阻止应用程序向KeyNote提交误导性或不正确的断言，或者完全忽略KeyNote。
It is also up to the application (or some service outside KeyNote) to select the appropriate credentials and policy assertions with which to run a particular query. Note, however, that even if inappropriate credentials are provided to KeyNote, this cannot result in the approval of an illegal action (as long as the policy assertions are correct and the the action attribute set itself is correctly passed to KeyNote).
应用程序（或KeyNote之外的某些服务）也可以选择适当的凭据和策略断言来运行特定查询。但是，请注意，即使向KeyNote提供了不适当的凭据，也不会导致批准非法操作（只要策略断言正确且操作属性集本身正确传递给KeyNote）。
KeyNote is monotonic; adding an assertion to a query can never result in a query's having a lower compliance value that it would have had without the assertion. Omitting credentials may, of course, result in legal actions being disallowed. Selecting appropriate credentials (e.g., from a distributed database or `key server') is outside the scope of the KeyNote language and may properly be handled by a remote client making a request, by the local application receiving the request, or by a network-based service, depending on the application.
基调单调；向查询添加断言永远不会导致查询的符合性值低于没有断言时的值。当然，省略凭证可能会导致不允许采取法律行动。选择适当的凭据（例如，从分布式数据库或“密钥服务器”）不在KeyNote语言的范围内，可由发出请求的远程客户端、接收请求的本地应用程序或基于网络的服务（取决于应用程序）正确处理。
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.
此外，KeyNote本身不提供凭据吊销服务，尽管可以通过在谓词中包含日期测试将凭据写入某个日期后过期。需要凭据吊销的应用程序可以使用KeyNote来帮助指定和实施吊销策略。未来的文档将在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.
由于KeyNote旨在支持多种应用程序，因此可以为KeyNote实现提供多个不同的应用程序接口。在其最简单的形式中，注释记号符合性检查器将作为一个独立的应用程序存在，其他应用程序根据需要调用它。KeyNote还可以实现为应用程序链接到的库。最后，KeyNote实现可以作为本地受信任服务运行，本地应用程序通过一些进程间通信机制来传递查询。
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.
信任管理本身就是一种安全服务。KeyNote compliance checker实现中的错误或不正确使用可能会对使用它的任何应用程序产生安全影响。
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维护的三个标识符。本节解释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十六进制：”和“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实验室-研究）和Jonathan M.Smith（宾夕法尼亚大学）对本文件早期版本提出的建议和意见。
B. Full BNF (alphabetical order)
B.完整BNF（按字母顺序排列）
<ALGORITHM>:: {see section 4.4.2} ;
<ALGORITHM>:: {see section 4.4.2} ;
<Assertion>:: <VersionField>? <AuthField> <LicenseesField>?
<LocalConstantsField>? <ConditionsField>?
<CommentField>? <SignatureField>? ;
<Assertion>:: <VersionField>? <AuthField> <LicenseesField>?
<LocalConstantsField>? <ConditionsField>?
<CommentField>? <SignatureField>? ;
<Assignments>:: "" | <AttributeID> "=" <StringLiteral> <Assignments>
;
<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} ;
<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> ;
<AuthField>:: "Authorizer:" <AuthID> ;
<AuthID>:: <PrincipalIdentifier> | <DerefAttribute> ;
<AuthID>:: <PrincipalIdentifier> | <DerefAttribute> ;
<Clause>:: <Test> "->" "{" <ConditionsProgram> "}"
| <Test> "->" <Value> | <Test> ;
<Clause>:: <Test> "->" "{" <ConditionsProgram> "}"
| <Test> "->" <Value> | <Test> ;
<Comment>:: "#" {ASCII characters} ;
<Comment>:: "#" {ASCII characters} ;
<CommentField>:: "Comment:" {Free-form text} ;
<CommentField>:: "Comment:" {Free-form text} ;
<ConditionsField>:: "Conditions:" <ConditionsProgram> ;
<ConditionsField>:: "Conditions:" <ConditionsProgram> ;
<ConditionsProgram>:: "" | <Clause> ";" <ConditionsProgram> ;
<ConditionsProgram>:: "" | <Clause> ";" <ConditionsProgram> ;
<DerefAttribute>:: <AttributeID> ;
<DerefAttribute>:: <AttributeID> ;
<ENCODEDBITS>:: {see section 4.4.2} ;
<ENCODEDBITS>:: {see section 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>:: <ALGORITHM>":"<ENCODEDBITS> ;
<IntegerLiteral>:: {Decimal number of at least one digit} ;
<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> ;
<IntEx>:: <IntEx> "+" <IntEx> | <IntEx> "-" <IntEx>
| <IntEx> "*" <IntEx> | <IntEx> "/" <IntEx>
| <IntEx> "%" <IntEx> | <IntEx> "^" <IntEx>
| "-" <IntEx> | "(" <IntEx> ")" | <IntegerLiteral>
| "@" <StrEx> ;
<IntRelExpr>:: <IntEx> "==" <IntEx> | <IntEx> "!=" <IntEx>
| <IntEx> "<" <IntEx> | <IntEx> ">" <IntEx>
| <IntEx> "<=" <IntEx> | <IntEx> ">=" <IntEx> ;
<IntRelExpr>:: <IntEx> "==" <IntEx> | <IntEx> "!=" <IntEx>
| <IntEx> "<" <IntEx> | <IntEx> ">" <IntEx>
| <IntEx> "<=" <IntEx> | <IntEx> ">=" <IntEx> ;
<K>:: {Decimal number starting with a digit from 1 to 9} ;
<K>:: {Decimal number starting with a digit from 1 to 9} ;
<KeyID>:: <StrEx> ;
<KeyID>:: <StrEx> ;
<LicenseesExpr>:: "" | <PrincExpr> ;
<LicenseesExpr>:: "" | <PrincExpr> ;
<LicenseesField>:: "Licensees:" <LicenseesExpr> ;
<LicenseesField>:: "Licensees:" <LicenseesExpr> ;
<LocalConstantsField>:: "Local-Constants:" <Assignments> ;
<LocalConstantsField>:: "Local-Constants:" <Assignments> ;
<OpaqueID>:: <StrEx> ;
<OpaqueID>:: <StrEx> ;
<PrincExpr>:: "(" <PrincExpr> ")" | <PrincExpr> "&&" <PrincExpr>
| <PrincExpr> "||" <PrincExpr>
| <K>"-of(" <PrincList> ")" | <PrincipalIdentifier>
| <DerefAttribute> ;
<PrincExpr>:: "(" <PrincExpr> ")" | <PrincExpr> "&&" <PrincExpr>
| <PrincExpr> "||" <PrincExpr>
| <K>"-of(" <PrincList> ")" | <PrincipalIdentifier>
| <DerefAttribute> ;
<PrincipalIdentifier>:: <OpaqueID> | <KeyID> ;
<PrincipalIdentifier>:: <OpaqueID> | <KeyID> ;
<PrincList>:: <PrincipalIdentifier> | <DerefAttribute>
| <PrincList> "," <PrincList> ;
<PrincList>:: <PrincipalIdentifier> | <DerefAttribute>
| <PrincList> "," <PrincList> ;
<RegExpr>:: {POSIX 1003.2 Regular Expression}
<RegExpr>:: {POSIX 1003.2 Regular Expression}
<RelExpr>:: "(" <RelExpr> ")" | <RelExpr> "&&" <RelExpr>
| <RelExpr> "||" <RelExpr> | "!" <RelExpr>
| <IntRelExpr> | <FloatRelExpr> | <StringRelExpr>
| "true" | "false" ;
<RelExpr>:: "(" <RelExpr> ")" | <RelExpr> "&&" <RelExpr>
| <RelExpr> "||" <RelExpr> | "!" <RelExpr>
| <IntRelExpr> | <FloatRelExpr> | <StringRelExpr>
| "true" | "false" ;
<Signature>:: <StrEx> ;
<Signature>:: <StrEx> ;
<SignatureField>:: "Signature:" <Signature> ;
<SignatureField>:: "Signature:" <Signature> ;
<StrEx>:: <StrEx> "." <StrEx> | <StringLiteral> | "(" <StrEx> ")"
| <DerefAttribute> | "$" <StrEx> ;
<StrEx>:: <StrEx> "." <StrEx> | <StringLiteral> | "(" <StrEx> ")"
| <DerefAttribute> | "$" <StrEx> ;
<StringLiteral>:: {see section 4.3.1} ;
<StringLiteral>:: {see section 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> ;
<Test>:: <RelExpr> ;
<Value>:: <StrEx> ;
<Value>:: <StrEx> ;
<VersionField>:: "KeyNote-Version:" <VersionString> ;
<VersionField>:: "KeyNote-Version:" <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. 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>
[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. 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>
[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和Jensen编辑）。斯普林格·维拉格，1999年。可在<ftp://ftp.research.att.com/dist/mab/trustmgt.ps>.
[Cro82] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[Cro82]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。第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用户邮件列表中讨论。若要订阅，请将邮件正文中包含单行subscribe keynote用户的电子邮件发送至<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
Matt Blaze AT&T实验室-新泽西州弗洛勒姆公园公园大道180号研究中心07932-0971
EMail: mab@research.att.com
EMail: mab@research.att.com
Joan Feigenbaum AT&T Labs - Research 180 Park Avenue Florham Park, New Jersey 07932-0971
Joan Feigenbaum AT&T实验室-新泽西州弗洛勒姆公园公园大道180号研究中心07932-0971
EMail: jf@research.att.com
EMail: jf@research.att.com
John Ioannidis AT&T Labs - Research 180 Park Avenue Florham Park, New Jersey 07932-0971
John Ioannidis AT&T实验室-新泽西州弗洛勒姆公园公园大道180号研究中心07932-0971
EMail: ji@research.att.com
EMail: ji@research.att.com
Angelos D. Keromytis Distributed Systems Lab CIS Department, University of Pennsylvania 200 S. 33rd Street Philadelphia, Pennsylvania 19104-6389
安杰洛斯D.克罗米特分布系统实验室CIS系，宾夕法尼亚大学200 S.第三十三街费城，宾夕法尼亚19104-638
EMail: angelos@dsl.cis.upenn.edu
EMail: 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编辑功能的资金目前由互联网协会提供。