RFC documents are not free enough

3 files changed, 0 insertions, 3425 deletions

diff --git a/lib/libkeynote/doc/rfc2704.txt b/lib/libkeynote/doc/rfc2704.txt
deleted file mode 100644
index d41cd3ae165..00000000000
--- a/lib/libkeynote/doc/rfc2704.txt
+++ /dev/null
@@ -1,2075 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           M. Blaze
-Request for Comments: 2704                                 J. Feigenbaum
-Category: Informational                                     J. Ioannidis
-                                                    AT&T Labs - Research
-                                                            A. Keromytis
-                                                      U. of Pennsylvania
-                                                          September 1999
-
-
-             The KeyNote Trust-Management System Version 2
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-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.
-
-1.  Introduction
-
-   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.
-
-
-
-
-
-
-
-
-Blaze, et al.                Informational                      [Page 1]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   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].
-
-   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
-
-
-
-Blaze, et al.                Informational                      [Page 2]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   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.
-
-2.  KeyNote Concepts
-
-   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
-
-
-
-Blaze, et al.                Informational                      [Page 3]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   KeyNote system (e.g., for credential signature verification).  In
-   other cases, Principal Identifiers may have a structure that is
-   opaque to KeyNote.
-
-   Principals perform two functions of concern to KeyNote: They request
-   `actions' and they issue `assertions'.  Actions are any trusted
-   operations that an application places under KeyNote control.
-   Assertions delegate the authorization to perform actions to other
-   principals.
-
-   Actions are described to the KeyNote compliance checker in terms of a
-   collection of name-value pairs called an `action attribute set'.  The
-   action attribute set is created by the invoking application.  Its
-   structure and format are described in detail in Section 3 of this
-   document.
-
-   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.
-
-   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.
-
-   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.
-
-
-
-
-
-
-
-Blaze, et al.                Informational                      [Page 4]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   Assertions issued by the "POLICY" principal are called `policy
-   assertions' and are used to delegate authority to otherwise untrusted
-   principals.  The KeyNote security policy of an application consists
-   of a collection of policy assertions.
-
-   When a principal is identified by a public key, it can digitally sign
-   assertions and distribute them over untrusted networks for use by
-   other KeyNote compliance checkers.  These signed assertions are also
-   called `credentials', and serve a role similar to that of traditional
-   public key certificates.  Policies and credentials share the same
-   syntax and are evaluated according to the same semantics.  A
-   principal can therefore convert its policy assertions into
-   credentials simply by digitally signing them.
-
-   KeyNote is designed to encourage the creation of human-readable
-   policies and credentials that are amenable to transmission and
-   storage over a variety of media.  Its assertion syntax is inspired by
-   the format of RFC822-style message headers [Cro82].  A KeyNote
-   assertion contains a sequence of sections, called `fields', each of
-   which specifies one aspect of the assertion's semantics.  Fields
-   start with an identifier at the beginning of a line and continue
-   until the next field is encountered.  For example:
-
-      KeyNote-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.
-
-   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.
-
-   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
-
-
-
-Blaze, et al.                Informational                      [Page 5]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   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].
-
-3.  Action Attributes
-
-   Trusted actions to be evaluated by KeyNote are described by a
-   collection of name-value pairs called the `action attribute set'.
-   Action attributes are the mechanism by which applications communicate
-   requests to KeyNote and are the primary objects on which KeyNote
-   assertions operate.  An action attribute set is passed to the KeyNote
-   compliance checker with each query.
-
-   Each action attribute consists of a name and a value.  The semantics
-   of the names and values are not interpreted by KeyNote itself; they
-   vary from application to application and must be agreed upon by the
-   writers of applications and the writers of the policies and
-   credentials that will be used by them.
-
-   Action attribute names and values are represented by arbitrary-length
-   strings.  KeyNote guarantees support of attribute names and values up
-   to 2048 characters long.  The handling of longer attribute names or
-   values is not specified and is KeyNote-implementation-dependent.
-   Applications and assertions should therefore avoid depending on the
-   the use of attributes with names or values longer than 2048
-   characters.  The length of an attribute value is represented by an
-   implementation-specific mechanism (e.g., NUL-terminated strings, an
-   explicit length field, etc.).
-
-   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".
-
-   Attribute names are of the form:
-
-       <AttributeID>:: {Any string starting with a-z, A-Z, or the
-                        underscore character, followed by any number of
-                        a-z, A-Z, 0-9, or underscore characters} ;
-
-   That is, an <AttributeID> begins with an alphabetic or underscore
-   character and can be followed by any number of alphanumerics and
-   underscores.  Attribute names are case-sensitive.
-
-
-
-Blaze, et al.                Informational                      [Page 6]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   The exact mechanism for passing the action attribute set to the
-   compliance checker is determined by the KeyNote implementation.
-   Depending on specific requirements, an implementation may provide a
-   mechanism for including the entire attribute set as an explicit
-   parameter of the query, or it may provide some form of callback
-   mechanism invoked as each attribute is dereferenced, e.g., for access
-   to kernel variables.
-
-   If an action attribute is not defined its value is considered to be
-   the empty string.
-
-   Attribute names beginning with the "_" character are reserved for use
-   by the KeyNote runtime environment and cannot be passed from
-   applications as part of queries.  The following special attribute
-   names are used:
-
-       Name                        Purpose
-       ------------------------    ------------------------------------
-       _MIN_TRUST                  Lowest-order (minimum) compliance
-                                   value in query; see Section 5.1.
-
-       _MAX_TRUST                  Highest-order (maximum) compliance
-                                   value in query; see Section 5.1.
-
-       _VALUES                     Linearly ordered set of compliance
-                                   values in query; see Section 5.1.
-                                   Comma separated.
-
-       _ACTION_AUTHORIZERS         Names of principals directly
-                                   authorizing action in query.
-                                   Comma separated.
-
-   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.
-
-   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.
-
-
-
-
-
-
-
-
-Blaze, et al.                Informational                      [Page 7]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   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.
-
-   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.
-
-   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.
-
-   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.)
-
-4.  KeyNote Assertion Syntax
-
-   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.
-
-4.1  Basic Structure
-
-       <Assertion>:: <VersionField>? <AuthField> <LicenseesField>?
-                     <LocalConstantsField>? <ConditionsField>?
-                     <CommentField>? <SignatureField>? ;
-
-   All KeyNote assertions are encoded in ASCII.
-
-
-
-
-Blaze, et al.                Informational                      [Page 8]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   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.
-
-   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.
-
-4.2  Comments
-
-      <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).
-
-
-
-
-
-
-Blaze, et al.                Informational                      [Page 9]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-4.3  Strings
-
-   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.
-
-4.3.1  String Literals
-
-      <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).
-
-   A printable character may be `escaped' inside a quoted string literal
-   by preceding it with the backslash character (ASCII 92 decimal)
-   (e.g., "like \"this\".").  This permits the inclusion of the double-
-   quote and backslash characters inside string literals.
-
-   A 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.
-
-   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:
-
-        "this string contains a newline\n followed by one space."
-        "this string contains a newline\n \
-        followed by one space."
-
-
-
-
-
-
-
-Blaze, et al.                Informational                     [Page 10]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-        "this str\
-           ing contains a \
-             newline\n followed by one space."
-
-        "this string contains a newline\012\040followed by one space."
-
-4.3.2  String Expressions
-
-   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.
-
-       <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.
-
-4.4  Dereferenced Attributes
-
-   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.
-
-   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).
-
-   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.
-
-   Any uninitialized attribute has the empty-string value when
-   dereferenced as a string and the value zero when dereferenced as an
-   integer or float.
-
-
-
-
-Blaze, et al.                Informational                     [Page 11]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   Attribute names may be given literally or calculated from string
-   expressions and may be recursively dereferenced.  In the simplest
-   case, an attribute is dereferenced simply by using its name outside
-   of quotes; e.g., the string value of the attribute named "foo" is by
-   reference to `foo' (outside of quotes).  The "$<StrEx>" construct
-   dereferences the attribute named in the string expression <StrEx>.
-   For example, if the attribute named "foo" contains the string "bar",
-   the attribute named "bar" contains the string "xyz", and the
-   attribute "xyz" contains the string "qua", the following string
-   comparisons are all true:
-
-    foo == "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).
-
-   The <DerefAttribute> token is defined as:
-
-      <DerefAttribute>:: <AttributeID> ;
-
-4.5  Principal Identifiers
-
-   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.
-
-       <PrincipalIdentifier>:: <OpaqueID>
-                             | <KeyID> ;
-
-   4.5.1  Opaque Principal Identifiers
-
-   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):
-
-       <OpaqueID>:: <StrEx> ;
-
-   Opaque identifier strings should not contain the ":" character.
-
-
-
-
-
-
-Blaze, et al.                Informational                     [Page 12]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-4.5.2  Cryptographic Principal Identifiers
-
-   Principal Identifiers that are used by KeyNote as keys, e.g., to
-   verify credential signatures, are said to be `cryptographic'.
-   Cryptographic identifiers are also lexically encoded as strings:
-
-       <KeyID>:: <StrEx> ;
-
-   Unlike Opaque Identifiers, however, Cryptographic Identifier strings
-   have a special form.  To be interpreted by KeyNote (for signature
-   verification), an identifier string should be of the form:
-
-      <IDString>:: <ALGORITHM>":"<ENCODEDBITS> ;
-
-   "ALGORITHM" is an ASCII substring that describes the algorithms to be
-   used in interpreting the key's bits.  The ALGORITHM identifies the
-   major cryptographic algorithm (e.g., RSA [RSA78], DSA [DSA94], etc.),
-   structured format (e.g., PKCS1 [PKCS1]), and key bit encoding (e.g.,
-   HEX or BASE64).  By convention, the ALGORITHM substring starts with
-   an alphabetic character and can contain letters, digits, underscores,
-   or dashes (i.e., it should match the regular expression "[a-zA-Z][a-
-   zA-Z0-9_-]*").  The IANA (or some other appropriate authority) will
-   provide a registry of reserved algorithm identifiers.
-
-   "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.
-
-   Cryptographic Principal Identifiers are converted to a normalized
-   canonical form for the purposes of any internal comparisons between
-   them; see Section 5.2.
-
-   Note that the keys used in examples throughout this document are
-   fictitious and generally much shorter than would be required for
-   security in practice.
-
-4.6  KeyNote Fields
-
-4.6.1  The KeyNote-Version Field
-
-   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> ;
-
-
-
-
-Blaze, et al.                Informational                     [Page 13]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   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.
-
-4.6.2  The Local-Constants Field
-
-   This field adds or overrides action attributes in the current
-   assertion only.  This mechanism allows the use of short names for
-   (frequently lengthy) cryptographic principal identifiers, especially
-   to make the Licensees field more readable.  The Local-Constants field
-   is of the form:
-
-       <LocalConstantsField>:: "Local-Constants:" <Assignments> ;
-       <Assignments>:: /* can be empty */
-                     | <AttributeID> "=" <StringLiteral> <Assignments> ;
-
-   <AttributeID> is an attribute name from the action attribute
-   namespace as defined in Section 3.  The name is available for use as
-   an attribute in any subsequent field.  If the Local-Constants field
-   defines more than one identifier, it can occupy more than one line
-   and be indented.  <StringLiteral> is a string literal as described in
-   Section 4.3.  Attributes defined in the Local-Constants field
-   override any attributes with the same name passed in with the action
-   attribute set.
-
-   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.
-
-4.6.3  The Authorizer Field
-
-   The Authorizer identifies the Principal issuing the assertion.  This
-   field is of the form
-
-       <AuthField>:: "Authorizer:" <AuthID> ;
-       <AuthID>:: <PrincipalIdentifier>
-                | <DerefAttribute> ;
-
-   The Principal Identifier may be given directly or by reference to the
-   attribute namespace (as defined in Section 4.4).
-
-
-
-
-
-
-Blaze, et al.                Informational                     [Page 14]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-4.6.4   The Licensees Field
-
-   The Licensees field identifies the principals authorized by the
-   assertion.  More than one principal can be authorized, and
-   authorization can be distributed across several principals through
-   the use of `and' and threshold constructs.  This field is of the form
-
-       <LicenseesField>:: "Licensees:" <LicenseesExpr> ;
-
-       <LicenseesExpr>::      /* can be empty */
-                         | <PrincExpr> ;
-
-       <PrincExpr>:: "(" <PrincExpr> ")"
-                     | <PrincExpr> "&&" <PrincExpr>
-                     | <PrincExpr> "||" <PrincExpr>
-                     | <K>"-of(" <PrincList> ")"        /* Threshold */
-                     | <PrincipalIdentifier>
-                     | <DerefAttribute> ;
-
-       <PrincList>:: <PrincipalIdentifier>
-                   | <DerefAttribute>
-                   | <PrincList> "," <PrincList> ;
-
-       <K>:: {Decimal number starting with a digit from 1 to 9} ;
-
-   The "&&" operator has higher precedence than the "||" operator.  <K>
-   is an ASCII-encoded positive decimal integer.  If a <PrincList>
-   contains fewer than <K> principals, the entire assertion is omitted
-   from processing.
-
-4.6.5  The Conditions Field
-
-   This field gives the `conditions' under which the Authorizer trusts
-   the Licensees to perform an action.  `Conditions' are predicates that
-   operate on the action attribute set.  The Conditions field is of the
-   form:
-
-    <ConditionsField>:: "Conditions:" <ConditionsProgram> ;
-
-    <ConditionsProgram>:: /* Can be empty */
-                          | <Clause> ";" <ConditionsProgram> ;
-
-    <Clause>:: <Test> "->" "{" <ConditionsProgram> "}"
-             | <Test> "->" <Value>
-             | <Test> ;
-
-    <Value>:: <StrEx> ;
-
-
-
-
-Blaze, et al.                Informational                     [Page 15]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-    <Test>:: <RelExpr> ;
-
-    <RelExpr>:: "(" <RelExpr> ")"        /* Parentheses */
-              | <RelExpr> "&&" <RelExpr> /* Logical AND */
-              | <RelExpr> "||" <RelExpr> /* Logical OR */
-              | "!" <RelExpr>         /* Logical NOT */
-              | <IntRelExpr>
-              | <FloatRelExpr>
-              | <StringRelExpr>
-              | "true"        /* case insensitive */
-              | "false" ;     /* case insensitive */
-
-    <IntRelExpr>:: <IntEx> "==" <IntEx>
-                 | <IntEx> "!=" <IntEx>
-                 | <IntEx> "<" <IntEx>
-                 | <IntEx> ">" <IntEx>
-                 | <IntEx> "<=" <IntEx>
-                 | <IntEx> ">=" <IntEx> ;
-
-    <FloatRelExpr>:: <FloatEx> "<" <FloatEx>
-                   | <FloatEx> ">" <FloatEx>
-                   | <FloatEx> "<=" <FloatEx>
-                   | <FloatEx> ">=" <FloatEx> ;
-
-    <StringRelExpr>:: <StrEx> "==" <StrEx>  /* String equality */
-                    | <StrEx> "!=" <StrEx>  /* String inequality */
-                    | <StrEx> "<" <StrEx>   /* Alphanum. comparisons */
-                    | <StrEx> ">" <StrEx>
-                    | <StrEx> "<=" <StrEx>
-                    | <StrEx> ">=" <StrEx>
-                    | <StrEx> "~=" <RegExpr> ; /* Reg. expr. matching */
-
-    <IntEx>:: <IntEx> "+" <IntEx>        /* Integer */
-            | <IntEx> "-" <IntEx>
-            | <IntEx> "*" <IntEx>
-            | <IntEx> "/" <IntEx>
-            | <IntEx> "%" <IntEx>
-            | <IntEx> "^" <IntEx>        /* Exponentiation */
-            | "-" <IntEx>
-            | "(" <IntEx> ")"
-            | <IntegerLiteral>
-            | "@" <StrEx> ;
-
-    <FloatEx>:: <FloatEx> "+" <FloatEx>  /* Floating point */
-              | <FloatEx> "-" <FloatEx>
-              | <FloatEx> "*" <FloatEx>
-              | <FloatEx> "/" <FloatEx>
-              | <FloatEx> "^" <FloatEx> /* Exponentiation */
-
-
-
-Blaze, et al.                Informational                     [Page 16]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-              | "-" <FloatEx>
-              | "(" <FloatEx> ")"
-              | <FloatLiteral>
-              | "&" <StrEx> ;
-
-    <IntegerLiteral>:: {Decimal number of at least one digit} ;
-    <FloatLiteral>:: <IntegerLiteral>"."<IntegerLiteral> ;
-
-    <StringLiteral> is a quoted string as defined in Section 4.3
-    <AttributeID> is defined in Section 3.
-
-   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.
-
-   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.
-
-
-
-
-
-
-
-
-
-Blaze, et al.                Informational                     [Page 17]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-4.6.6  The Comment Field
-
-   The Comment field allows assertions to be annotated with information
-   describing their purpose.  It is of the form
-
-       <CommentField>:: "Comment:" <text> ;
-
-   No interpretation of the contents of this field is performed by
-   KeyNote.  Note that this is one of two mechanisms for including
-   comments in KeyNote assertions; comments can also be inserted
-   anywhere in an assertion's body by preceding them with the "#"
-   character (except inside string literals).
-
-4.6.7  The Signature Field
-
-   The Signature field identifies a signed assertion and gives the
-   encoded digital signature of the principal identified in the
-   Authorizer field.  The Signature field is of the form:
-
-       <SignatureField>:: "Signature:" <Signature> ;
-
-       <Signature>:: <StrEx> ;
-
-   The <Signature> string should be of the form:
-
-       <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.
-
-   If the signature field is included, the principal named in the
-   Authorizer field must be a Cryptographic Principal Identifier, the
-   algorithm must be known to the KeyNote implementation, and the
-   signature must be correct for the assertion body and authorizer key.
-
-   The signature is computed over the assertion text, beginning with the
-   first field (including the field identifier string), up to (but not
-   including) the Signature field identifier.  The newline preceding the
-   signature field identifier is the last character included in
-   signature calculation.  The signature is always the last field in a
-   KeyNote assertion.  Text following this field is not considered part
-   of the assertion.
-
-
-
-
-Blaze, et al.                Informational                     [Page 18]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   The algorithms for computing and verifying signatures must be
-   configured into each KeyNote implementation and are defined and
-   documented separately.
-
-   Note that all signatures used in examples in this document are
-   fictitious and generally much shorter than would be required for
-   security in practice.
-
-5.   Query Evaluation Semantics
-
-   The KeyNote compliance checker finds and returns the Policy
-   Compliance Value of queries, as defined in Section 5.3, below.
-
-5.1  Query Parameters
-
-   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
-
-   *  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).
-
-5.1.1  Action Requester
-
-   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.
-
-
-
-
-
-
-Blaze, et al.                Informational                     [Page 19]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-5.1.2  Ordered Compliance Value Set
-
-   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.
-
-   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.
-
-5.2  Principal Identifier Normalization
-
-   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.
-
-   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).
-
-5.3  Policy Compliance Value Calculation
-
-   The Policy Compliance Value of a query is the Principal Compliance
-   Value of the principal named "POLICY".  This value is defined as
-   follows:
-
-
-
-
-
-
-
-Blaze, et al.                Informational                     [Page 20]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-5.3.1  Principal Compliance Value
-
-   The Compliance Value of a principal <X> is the highest order
-   (maximum) of:
-
-      -  the Direct Authorization Value of principal <X>; and
-
-      -  the Assertion Compliance Values of all assertions identifying
-         <X> in the Authorizer field.
-
-5.3.2  Direct Authorization Value
-
-   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.
-
-5.3.3  Assertion Compliance Value
-
-   The Assertion Compliance Value of an assertion is the lowest order
-   (minimum) of the assertion's Conditions Compliance Value and its
-   Licensee Compliance Value.
-
-5.3.4 Conditions Compliance Value
-
-   The Conditions Compliance Value of an assertion is the highest-order
-   (maximum) value among all successful clauses listed in the conditions
-   section.
-
-   If no clause's test succeeds or the Conditions field is empty, an
-   assertion's Conditions Compliance Value is considered to be the
-   _MIN_TRUST value, as defined Section 5.1.
-
-   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.
-
-   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
-
-
-
-
-Blaze, et al.                Informational                     [Page 21]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-       foo=="bar";
-
-   is equivalent to
-
-       foo=="bar" -> _MAX_TRUST;
-
-   If the value component of a clause is present, in the simplest case
-   it contains a string expression representing a possible compliance
-   value.  For example, consider an assertion with the following
-   Conditions field:
-
-       Conditions:
-          @user_id == 0 -> "full_access";             # clause (1)
-          @user_id < 1000 -> "user_access";           # clause (2)
-          @user_id < 10000 -> "guest_access";         # clause (3)
-          user_name == "root" -> "full_access";       # clause (4)
-
-   Here, if the value of the "user_id" attribute is "1073" and the
-   "user_name" attribute is "root", the possible compliance value set
-   would contain the values "guest_access" (by clause (3)) and
-   "full_access" (by clause (4)).  If the ordered set of compliance
-   values given in the query (in ascending order) is {"no_access",
-   "guest_access", "user_access", "full_access"}, the Conditions
-   Compliance Value of the assertion would be "full_access" (because
-   "full_access" has a higher-order value than "guest_access").  If the
-   "user_id" attribute had the value "19283" and the "user_name"
-   attribute had the value "nobody", no clause would succeed and the
-   Conditions Compliance Value would be "no_access", which is the
-   lowest-order possible value (_MIN_TRUST).
-
-   If a clause lists an explicit value, its value string must be named
-   in the query ordered compliance value set.  Values not named in the
-   query compliance value set are considered equivalent to _MIN_TRUST.
-
-   The value component of a clause can also contain recursively-nested
-   clauses.  Recursively-nested clauses are evaluated only if their
-   parent test is true.  That is,
-
-       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";
-
-
-
-
-Blaze, et al.                Informational                     [Page 22]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   String comparisons are case-sensitive.
-
-   A regular expression comparison ("~=") is considered true if the
-   left-hand-side string expression matches the right-hand-side regular
-   expression.  If the POSIX regular expression group matching scheme is
-   used, the number of groups matched is placed in the temporary meta-
-   attribute "_0" (dereferenced as _0), and each match is placed in
-   sequence in the temporary attributes (_1, _2, ..., _N).  These
-   match-attributes' values are valid only within subsequent references
-   made within the same clause.  Regular expression evaluation is case-
-   sensitive.
-
-   A runtime error occurring in the evaluation of a test, such as
-   division by zero or an invalid regular expression, causes the test to
-   be considered false.  For example:
-
-      foo == "bar" -> {
-                        @a == 1/0 -> "oneval";    # subclause 1
-                        @a == 2 -> "anotherval";  # subclause 2
-                      };
-
-   Here, subclause 1 triggers a runtime error.  Subclause 1 is therefore
-   false (and has the value _MIN_TRUST).  Subclause 2, however, would be
-   evaluated normally.
-
-   An invalid <RegExpr> is considered a runtime error and causes the
-   test in which it occurs to be considered false.
-
-5.3.5  Licensee Compliance Value
-
-   The Licensee Compliance Value of an assertion is calculated by
-   evaluating the expression in the Licensees field, based on the
-   Principal Compliance Value of the principals named there.
-
-   If an assertion's Licensees field is empty, its Licensee Compliance
-   Value is considered to be _MIN_TRUST.  If an assertion's Licensees
-   field is missing altogether, its Licensee Compliance Value is
-   considered to be _MAX_TRUST.
-
-   For each principal named in the Licensees field, its Principal
-   Compliance Value is substituted for its name.  If no Principal
-   Compliance Value can be found for some named principal, its name is
-   substituted with the _MIN_TRUST value.
-
-   The licensees expression (as defined in Section 4.6.4) is evaluated
-   as follows:
-
-
-
-
-
-Blaze, et al.                Informational                     [Page 23]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   *  A "(...)" expression has the value of the enclosed subexpression.
-
-   *  A "&&" expression has the 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.
-
-   For example, consider the following Licensees field:
-
-        Licensees: ("alice" && "bob") || "eve"
-
-   If the Principal Compliance Value is "yes" for principal "alice",
-   "no" for principal "bob", and "no" for principal "eve", and "yes" is
-   higher order than "no" in the query's Compliance Value Set, then the
-   resulting Licensee Compliance Value is "no".
-
-   Observe that if there are exactly two possible compliance values
-   (e.g., "false" and "true"), the rules of Licensee Compliance Value
-   resolution reduce exactly to standard Boolean logic.
-
-5.4  Assertion Management
-
-   Assertions may be either signed or unsigned.  Only signed assertions
-   should be used as credentials or transmitted or stored on untrusted
-   media.  Unsigned assertions should be used only to specify policy and
-   for assertions whose integrity has already been verified as
-   conforming to local policy by some mechanism external to the KeyNote
-   system itself (e.g., X.509 certificates converted to KeyNote
-   assertions by a trusted conversion program).
-
-   Implementations that permit signed credentials to be verified by the
-   KeyNote compliance checker generally provide two `channels' through
-   which applications can make assertions available.  Unsigned,
-   locally-trusted assertions are provided over a `trusted' interface,
-   while signed credentials are provided over an `untrusted' interface.
-   The KeyNote compliance checker verifies correct signatures for all
-   assertions submitted over the untrusted interface.  The integrity of
-   KeyNote evaluation requires that only assertions trusted as
-   reflecting local policy are submitted to KeyNote via the trusted
-   interface.
-
-
-
-
-Blaze, et al.                Informational                     [Page 24]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   Note that applications that use KeyNote exclusively as a local policy
-   specification mechanism need use only trusted assertions.  Other
-   applications might need only a small number of infrequently changed
-   trusted assertions to `bootstrap' a policy whose details are
-   specified in signed credentials issued by others and submitted over
-   the untrusted interface.
-
-5.5  Implementation Issues
-
-   Informally, the semantics of KeyNote evaluation can be thought of as
-   involving the construction a directed graph of KeyNote assertions
-   rooted at a POLICY assertion that connects with at least one of the
-   principals that requested the action.
-
-   Delegation of some authorization from principal <A> to a set of
-   principals <B> is expressed as an assertion with principal <A> given
-   in the Authorizer field, principal set <B> given in the Licensees
-   field, and the authorization to be delegated encoded in the
-   Conditions field.  How the expression digraph is constructed is
-   implementation-dependent and implementations may use different
-   algorithms for optimizing the graph's construction.  Some
-   implementations might use a `bottom up' traversal starting at the
-   principals that requested the action, others might follow a `top
-   down' approach starting at the POLICY assertions, and still others
-   might employ other heuristics entirely.
-
-   Implementations are encouraged to employ mechanisms for recording
-   exceptions (such as division by zero or syntax error), and reporting
-   them to the invoking application if requested.  Such mechanisms are
-   outside the scope of this document.
-
-6.  Examples
-
-   In this section, we give examples of KeyNote assertions that might be
-   used in hypothetical applications.  These examples are intended
-   primarily to illustrate features of KeyNote assertion syntax and
-   semantics, and do not necessarily represent the best way to integrate
-   KeyNote into applications.
-
-   In the interest of readability, we use much shorter keys than would
-   ordinarily be used in practice.  Note that the Signature fields in
-   these examples do not represent the result of any real signature
-   calculation.
-
-
-
-
-
-
-
-
-Blaze, et al.                Informational                     [Page 25]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   1. TRADITIONAL CA / EMAIL
-
-      A. A policy unconditionally authorizing RSA key abc123 for all
-         actions.  This essentially defers the ability to specify
-         policy to the holder of the secret key corresponding to
-         abc123:
-
-           Authorizer: "POLICY"
-           Licensees: "RSA:abc123"
-
-      B. A credential assertion in which RSA Key abc123 trusts either
-         RSA key 4401ff92 (called `Alice') or DSA key d1234f (called
-         `Bob') to perform actions in which the "app_domain" is
-         "RFC822-EMAIL", where the "address" matches the regular
-         expression "^.*@keynote\.research\.att\.com$".  In other
-         words, abc123 trusts Alice and Bob as certification
-         authorities for the keynote.research.att.com domain.
-
-           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):
-
-           KeyNote-Version: 2
-           Authorizer: "DSA:4401ff92"  # the Alice CA
-           Licensees: "DSA:12340987"   # mab's key
-           Conditions: ((app_domain == "RFC822-EMAIL") &&
-                        (name == "M. Blaze" || name == "") &&
-                        (address == "mab@keynote.research.att.com"));
-           Signature: "DSA-SHA1:ab23487"
-
-
-
-
-
-
-
-
-
-
-Blaze, et al.                Informational                     [Page 26]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-      D. Another certificate credential for a specific user, also
-         issued by the `Alice' authority.  This example allows three
-         different keys to sign as jf@keynote.research.att.com (each
-         for a different cryptographic algorithm).  This is, in
-         effect, three credentials in one:
-
-           KeyNote-Version: "2"
-           Authorizer: "DSA:4401ff92"   # the Alice CA
-           Licensees: "DSA:abc991" ||   # jf's DSA key
-                      "RSA:cde773" ||   # jf's RSA key
-                      "BFIK:fd091a"     # jf's BFIK key
-           Conditions: ((app_domain == "RFC822-EMAIL") &&
-                        (name == "J. Feigenbaum" || name == "") &&
-                        (address == "jf@keynote.research.att.com"));
-           Signature: "DSA-SHA1:8912aa"
-
-         Observe that under policy A and credentials B, C and D, the
-         following action attribute sets are accepted (they return
-         _MAX_TRUST):
-
-             _ACTION_AUTHORIZERS = "dsa:12340987"
-             app_domain = "RFC822-EMAIL"
-             address = "mab@keynote.research.att.com"
-          and
-             _ACTION_AUTHORIZERS = "dsa:12340987"
-             app_domain = "RFC822-EMAIL"
-             address = "mab@keynote.research.att.com"
-             name = "M. Blaze"
-
-         while the following are not accepted (they return
-         _MIN_TRUST):
-
-             _ACTION_AUTHORIZERS = "dsa:12340987"
-             app_domain = "RFC822-EMAIL"
-             address = "angelos@dsl.cis.upenn.edu"
-          and
-             _ACTION_AUTHORIZERS = "dsa:abc991"
-             app_domain = "RFC822-EMAIL"
-             address = "mab@keynote.research.att.com"
-             name = "M. Blaze"
-          and
-             _ACTION_AUTHORIZERS = "dsa:12340987"
-             app_domain = "RFC822-EMAIL"
-             address = "mab@keynote.research.att.com"
-             name = "J. Feigenbaum"
-
-
-
-
-
-
-Blaze, et al.                Informational                     [Page 27]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   2. WORKFLOW/ELECTRONIC COMMERCE
-
-      E. A policy that delegates authority for the "SPEND" application
-         domain to RSA key dab212 when the amount given in the
-         "dollars" attribute is less than 10000.
-
-           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.
-
-           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:
-
-           KeyNote-Version: 2
-           Authorizer: "POLICY"
-           Licensees: 2-of("DSA:feed1234", # The VP
-                           "RSA:abc123",   # Middle management clones
-                           "DSA:bcd987",
-                           "DSA:cde333",
-                           "DSA:def975",
-                           "DSA:978add")
-           Conditions: (app_domain=="SPEND") &&
-                       (@(dollars) < 1000);
-
-
-
-
-
-Blaze, et al.                Informational                     [Page 28]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-      H. A credential from dab212 with a similar policy, but only one
-         signer is required if @(dollars) < 500.  A log entry is made if
-         the amount is at least 100.
-
-           KeyNote-Version: 2
-           Comment: This one credential is equivalent to six separate
-                    credentials, one for each VP and middle manager.
-                    Individually, they can spend up to $500, but if
-                    it's $100 or more, we log it.
-           Authorizer: "RSA:dab212"      # From the CFO
-           Licensees: "DSA:feed1234" ||  # The VP
-                      "RSA:abc123" ||    # The middle management clones
-                      "DSA:bcd987" ||
-                      "DSA:cde333" ||
-                      "DSA:def975" ||
-                      "DSA:978add"
-           Conditions: (app_domain="SPEND")  # nested clauses
-                         -> { (@(dollars) < 100) -> _MAX_TRUST;
-                              (@(dollars) < 500) -> "ApproveAndLog";
-                            };
-           Signature: "RSA-SHA1:186123"
-
-      Assume a query in which the ordered set of Compliance Values is
-      {"Reject", "ApproveAndLog", "Approve"}.  Under policies E and G,
-      and credentials F and H, the Policy Compliance Value is
-      "Approve" (_MAX_TRUST) when:
-
-           _ACTION_AUTHORIZERS = "DSA:978add"
-           app_domain = "SPEND"
-           dollars = "45"
-           unmentioned_attribute = "whatever"
-       and
-           _ACTION_AUTHORIZERS = "RSA:abc123,DSA:cde333"
-           app_domain = "SPEND"
-           dollars = "550"
-
-      The following return "ApproveAndLog":
-
-           _ACTION_AUTHORIZERS = "DSA:feed1234,DSA:cde333"
-           app_domain = "SPEND"
-           dollars = "5500"
-       and
-           _ACTION_AUTHORIZERS = "DSA:cde333"
-           app_domain = "SPEND"
-           dollars = "150"
-
-
-
-
-
-
-Blaze, et al.                Informational                     [Page 29]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-      However, the following return "Reject" (_MIN_TRUST):
-
-           _ACTION_AUTHORIZERS = "DSA:def975"
-           app_domain = "SPEND"
-           dollars = "550"
-       and
-           _ACTION_AUTHORIZERS = "DSA:cde333,DSA:978add"
-           app_domain = "SPEND"
-           dollars = "5500"
-
-7.  Trust-Management Architecture
-
-   KeyNote provides a simple mechanism for describing security policy
-   and representing credentials.  It differs from traditional
-   certification systems in that the security model is based on binding
-   keys to predicates that describe what the key is authorized by policy
-   to do, rather than on resolving names.  The infrastructure and
-   architecture to support a KeyNote system is therefore rather
-   different from that required for a name-based certification scheme.
-   The KeyNote trust-management architecture is based on that of
-   PolicyMaker [BFL96,BFS98].
-
-   It is important to understand the separation between the
-   responsibilities of the KeyNote system and those of the application
-   and other support infrastructure.  A KeyNote compliance checker will
-   determine, based on policy and credential assertions, whether a
-   proposed action is permitted according to policy.  The usefulness of
-   KeyNote output as a policy enforcement mechanism depends on a number
-   of factors:
-
-   *  The action attributes and the assignment of their values must
-      reflect accurately the security requirements of the application.
-      Identifying the attributes to include in the action attribute set
-      is perhaps the most important task in integrating KeyNote into new
-      applications.
-
-   *  The policy of the application must be correct and well-formed.  In
-      particular, trust must be deferred only to principals that should,
-      in fact, be trusted by the application.
-
-   *  The application itself must be trustworthy.  KeyNote does not
-      directly enforce policy; it only provides advice to the
-      applications that call it.  In other words, KeyNote assumes that
-      the application itself is trusted and that the policy assertions
-      it specifies are correct.  Nothing prevents an application from
-      submitting misleading or incorrect assertions to KeyNote or from
-      ignoring KeyNote altogether.
-
-
-
-
-Blaze, et al.                Informational                     [Page 30]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   It is also up to the application (or some service outside KeyNote) to
-   select the appropriate credentials and policy assertions with which
-   to run a particular query.  Note, however, that even if inappropriate
-   credentials are provided to KeyNote, this cannot result in the
-   approval of an illegal action (as long as the policy assertions are
-   correct and the the action attribute set itself is correctly passed
-   to KeyNote).
-
-   KeyNote is monotonic; adding an assertion to a query can never result
-   in a query's having a lower compliance value that it would have had
-   without the assertion.  Omitting credentials may, of course, result
-   in legal actions being disallowed.  Selecting appropriate credentials
-   (e.g., from a distributed database or `key server') is outside the
-   scope of the KeyNote language and may properly be handled by a remote
-   client making a request, by the local application receiving the
-   request, or by a network-based service, depending on the application.
-
-   In addition, KeyNote does not itself provide credential revocation
-   services, although credentials can be written to expire after some
-   date by including a date test in the predicate.  Applications that
-   require credential revocation can use KeyNote to help specify and
-   implement revocation policies.  A future document will address
-   expiration and revocation services in KeyNote.
-
-   Because KeyNote is designed to support a variety of applications,
-   several different application interfaces to a KeyNote implementation
-   are possible.  In its simplest form, a KeyNote compliance checker
-   would exist as a stand-alone application, with other applications
-   calling it as needed.  KeyNote might also be implemented as a library
-   to which applications are linked.  Finally, a KeyNote implementation
-   might run as a local trusted service, with local applications
-   communicating their queries via some interprocess communication
-   mechanism.
-
-8.  Security Considerations
-
-   Trust management is itself a security service.  Bugs in or incorrect
-   use of a KeyNote compliance checker implementation could have
-   security implications for any applications in which it is used.
-
-9. IANA Considerations
-
-   This document contains three identifiers to be maintained by the
-   IANA.  This section explains the criteria to be used by the IANA to
-   assign additional identifiers in each of these lists.
-
-
-
-
-
-
-Blaze, et al.                Informational                     [Page 31]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-9.1  app_domain Identifiers
-
-   The only thing required of IANA on allocation of these identifiers is
-   that they be unique strings.  These strings are case-sensitive for
-   KeyNote purposes, however it is strongly recommended that IANA assign
-   different capitalizations of the same string only to the same
-   organization.
-
-9.2  Public Key Format Identifiers
-
-   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.
-
-9.3  Signature Algorithm Identifiers
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blaze, et al.                Informational                     [Page 32]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-A.  Acknowledgments
-
-   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.
-
-B.  Full BNF (alphabetical order)
-
-   <ALGORITHM>:: {see section 4.4.2} ;
-
-   <Assertion>:: <VersionField>? <AuthField> <LicenseesField>?
-                 <LocalConstantsField>? <ConditionsField>?
-                 <CommentField>? <SignatureField>? ;
-
-   <Assignments>:: "" | <AttributeID> "=" <StringLiteral> <Assignments>
-   ;
-
-   <AttributeID>:: {Any string starting with a-z, A-Z, or the
-                    underscore character, followed by any number of
-                    a-z, A-Z, 0-9, or underscore characters} ;
-
-   <AuthField>:: "Authorizer:" <AuthID> ;
-
-   <AuthID>:: <PrincipalIdentifier> | <DerefAttribute> ;
-
-   <Clause>:: <Test> "->" "{" <ConditionsProgram> "}"
-            | <Test> "->" <Value> | <Test> ;
-
-   <Comment>:: "#" {ASCII characters} ;
-
-   <CommentField>:: "Comment:" {Free-form text} ;
-
-   <ConditionsField>:: "Conditions:" <ConditionsProgram> ;
-
-   <ConditionsProgram>:: "" | <Clause> ";" <ConditionsProgram> ;
-
-   <DerefAttribute>:: <AttributeID> ;
-
-   <ENCODEDBITS>:: {see section 4.4.2} ;
-
-   <FloatEx>:: <FloatEx> "+" <FloatEx> | <FloatEx> "-" <FloatEx>
-             | <FloatEx> "*" <FloatEx> | <FloatEx> "/" <FloatEx>
-             | <FloatEx> "^" <FloatEx> | "-" <FloatEx>
-             | "(" <FloatEx> ")" | <FloatLiteral> | "&" <StrEx> ;
-
-   <FloatRelExpr>:: <FloatEx> "<" <FloatEx> | <FloatEx> ">" <FloatEx>
-                  | <FloatEx> "<=" <FloatEx>
-                  | <FloatEx> ">=" <FloatEx> ;
-
-
-
-Blaze, et al.                Informational                     [Page 33]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   <FloatLiteral>:: <IntegerLiteral>"."<IntegerLiteral> ;
-
-   <IDString>:: <ALGORITHM>":"<ENCODEDBITS> ;
-
-   <IntegerLiteral>:: {Decimal number of at least one digit} ;
-
-   <IntEx>:: <IntEx> "+" <IntEx> | <IntEx> "-" <IntEx>
-           | <IntEx> "*" <IntEx> | <IntEx> "/" <IntEx>
-           | <IntEx> "%" <IntEx> | <IntEx> "^" <IntEx>
-           | "-" <IntEx> | "(" <IntEx> ")" | <IntegerLiteral>
-           | "@" <StrEx> ;
-
-   <IntRelExpr>:: <IntEx> "==" <IntEx> | <IntEx> "!=" <IntEx>
-                | <IntEx> "<" <IntEx>  | <IntEx> ">" <IntEx>
-                | <IntEx> "<=" <IntEx> | <IntEx> ">=" <IntEx> ;
-
-   <K>:: {Decimal number starting with a digit from 1 to 9} ;
-
-   <KeyID>:: <StrEx> ;
-
-   <LicenseesExpr>:: "" | <PrincExpr> ;
-
-   <LicenseesField>:: "Licensees:" <LicenseesExpr> ;
-
-   <LocalConstantsField>:: "Local-Constants:" <Assignments> ;
-
-   <OpaqueID>:: <StrEx> ;
-
-   <PrincExpr>:: "(" <PrincExpr> ")" | <PrincExpr> "&&" <PrincExpr>
-               | <PrincExpr> "||" <PrincExpr>
-               | <K>"-of(" <PrincList> ")" | <PrincipalIdentifier>
-               | <DerefAttribute> ;
-
-   <PrincipalIdentifier>:: <OpaqueID> | <KeyID> ;
-
-   <PrincList>:: <PrincipalIdentifier> | <DerefAttribute>
-               | <PrincList> "," <PrincList> ;
-
-   <RegExpr>:: {POSIX 1003.2 Regular Expression}
-
-   <RelExpr>:: "(" <RelExpr> ")" | <RelExpr> "&&" <RelExpr>
-             | <RelExpr> "||" <RelExpr> | "!" <RelExpr>
-             | <IntRelExpr> | <FloatRelExpr> | <StringRelExpr>
-             | "true" | "false" ;
-
-   <Signature>:: <StrEx> ;
-
-   <SignatureField>:: "Signature:" <Signature> ;
-
-
-
-Blaze, et al.                Informational                     [Page 34]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   <StrEx>:: <StrEx> "." <StrEx> | <StringLiteral> | "(" <StrEx> ")"
-           | <DerefAttribute> | "$" <StrEx> ;
-
-   <StringLiteral>:: {see section 4.3.1} ;
-
-   <StringRelExpr>:: <StrEx> "==" <StrEx> | <StrEx> "!=" <StrEx>
-                   | <StrEx> "<" <StrEx> | <StrEx> ">" <StrEx>
-                   | <StrEx> "<=" <StrEx> | <StrEx> ">=" <StrEx>
-                   | <StrEx> "~=" <RegExpr> ;
-
-   <Test>:: <RelExpr> ;
-
-   <Value>:: <StrEx> ;
-
-   <VersionField>:: "KeyNote-Version:" <VersionString> ;
-
-   <VersionString>:: <StringLiteral> | <IntegerLiteral> ;
-
-References
-
-   [BFL96] M. Blaze, J. Feigenbaum, J. Lacy. Decentralized Trust
-           Management. Proceedings of the 17th IEEE Symp. on Security
-           and Privacy. pp 164-173.  IEEE Computer Society, 1996.
-           Available at
-           <ftp://ftp.research.att.com/dist/mab/policymaker.ps>
-
-   [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>.
-
-   [Cro82] Crocker, D., "Standard for the Format of ARPA Internet Text
-           Messages", STD 11, RFC 822, August 1982.
-
-   [DSA94] Digital Signature Standard. FIPS-186. National Institute of
-           Standards, U.S. Department of Commerce. May 1994.
-
-   [PKCS1] PKCS #1: RSA Encryption Standard, Version 1.5. RSA
-           Laboratories. November 1993.
-
-
-
-
-Blaze, et al.                Informational                     [Page 35]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-   [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.
-
-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>.
-
-   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:
-
-   Matt Blaze
-   AT&T Labs - Research
-   180 Park Avenue
-   Florham Park, New Jersey 07932-0971
-
-   EMail: mab@research.att.com
-
-
-   Joan Feigenbaum
-   AT&T Labs - Research
-   180 Park Avenue
-   Florham Park, New Jersey 07932-0971
-
-   EMail: jf@research.att.com
-
-
-   John Ioannidis
-   AT&T Labs - Research
-   180 Park Avenue
-   Florham Park, New Jersey 07932-0971
-
-   EMail: ji@research.att.com
-
-
-   Angelos D. Keromytis
-   Distributed Systems Lab
-   CIS Department, University of Pennsylvania
-   200 S. 33rd Street
-   Philadelphia, Pennsylvania  19104-6389
-
-   EMail: angelos@dsl.cis.upenn.edu
-
-
-
-
-Blaze, et al.                Informational                     [Page 36]
-
-RFC 2704          The KeyNote Trust-Management System     September 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blaze, et al.                Informational                     [Page 37]
-
diff --git a/lib/libkeynote/doc/rfc2792.txt b/lib/libkeynote/doc/rfc2792.txt
deleted file mode 100644
index 0b805c91a18..00000000000
--- a/lib/libkeynote/doc/rfc2792.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           M. Blaze
-Request for Comments: 2792                                  J. Ioannidis
-Category: Informational                             AT&T Labs - Research
-                                                            A. Keromytis
-                                                      U. of Pennsylvania
-                                                              March 2000
-
-
-             DSA and RSA Key and Signature Encoding for the
-                    KeyNote Trust Management System
-
-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 (2000).  All Rights Reserved.
-
-Abstract
-
-   This memo describes RSA and DSA key and signature encoding, and
-   binary key encoding for version 2 of the KeyNote trust-management
-   system.
-
-1.  Introduction
-
-   KeyNote is a simple and flexible trust-management system designed to
-   work well for a variety of large- and small-scale Internet-based
-   applications.  It provides a single, unified language for both local
-   policies and credentials.  KeyNote policies and credentials, called
-   `assertions', contain predicates that describe the trusted actions
-   permitted by the holders of specific public keys.  KeyNote assertions
-   are essentially small, highly-structured programs.  A signed
-   assertion, which can be sent over an untrusted network, is also
-   called a `credential assertion'.  Credential assertions, which also
-   serve the role of certificates, have the same syntax as policy
-   assertions but are also signed by the principal delegating the trust.
-   For more details on KeyNote, see [BFIK99].  This document assumes
-   reader familiarity with the KeyNote system.
-
-   Cryptographic keys may be used in KeyNote to identify principals.  To
-   facilitate interoperation between different implementations and to
-   allow for maximal flexibility, keys must be converted to a normalized
-   canonical form (depended on the public key algorithm used) for the
-   purposes of any internal comparisons between keys.  For example, an
-
-
-
-Blaze, et al.                Informational                      [Page 1]
-
-RFC 2792         Key and Signature Encoding for KeyNote       March 2000
-
-
-   RSA [RSA78] key may be encoded in base64 ASCII in one credential, and
-   in hexadecimal ASCII in another.  A KeyNote implementation must
-   internally convert the two encodings to a normalized form that allows
-   for comparison between them.  Furthermore, the internal structure of
-   an encoded key must be known for an implementation to correctly
-   decode it.
-
-   In some applications, other types of values, such as a passphrase or
-   a random nonce, may be used as principal identifiers.  When these
-   identifiers contain characters that may not appear in a string (as
-   defined in [BFIK99]), a simple ASCII encoding is necessary to allow
-   their use inside KeyNote assertions.  Note that if the identifier
-   only contains characters that can appear in a string, it may be used
-   as-is.  Naturally, such identifiers may not be used to sign an
-   assertion, and thus no related signature encoding is defined.
-
-   This document specifies RSA and DSA [DSA94] key and signature
-   encodings, and binary key encodings for use in KeyNote.
-
-2.  Key Normalized Forms
-
-2.1  DSA Key Normalized Form
-
-   DSA keys in KeyNote are identified by four values:
-
-   - the public value, y
-   - the p parameter
-   - the q parameter
-   - the g parameter
-
-   Where the y, p, q, and g are the DSA parameters corresponding to the
-   notation of [Sch96]. These four values together make up the DSA key
-   normalized form used in KeyNote.  All DSA key comparisons in KeyNote
-   occur between normalized forms.
-
-2.2  RSA Key Normalized Form
-
-   RSA keys in KeyNote are identified by two values:
-
-   - the public exponent
-   - the modulus
-
-   These two values together make up the RSA key normalized form used in
-   KeyNote.  All RSA key comparisons in KeyNote occur between normalized
-   forms.
-
-
-
-
-
-
-Blaze, et al.                Informational                      [Page 2]
-
-RFC 2792         Key and Signature Encoding for KeyNote       March 2000
-
-
-2.3  Binary Identifier Normalized Form
-
-   The normalized form of a Binary Identifier is the binary identifier's
-   data.  Thus, Binary Identifier comparisons are essentially binary-
-   string comparisons of the Identifier values.
-
-3.  Key Encoding
-
-3.1  DSA Key Encoding
-
-   DSA keys in KeyNote are encoded as an ASN1 SEQUENCE of four ASN1
-   INTEGER objects.  The four INTEGER objects are the public value and
-   the p, q, and g parameters of the DSA key, in that order.
-
-   For use in KeyNote credentials, the ASN1 SEQUENCE is then ASCII-
-   encoded (e.g., as a string of hex digits or base64 characters).
-
-   DSA keys encoded in this way in KeyNote must be identified by the
-   "dsa-XXX:" algorithm name, where XXX is an ASCII encoding ("hex" or
-   "base64").  Other ASCII encoding schemes may be defined in the
-   future.
-
-3.2  RSA Key Encoding
-
-   RSA keys in KeyNote are encoded as an ASN1 SEQUENCE of two ASN1
-   INTEGER objects.  The two INTEGER objects are the public exponent and
-   the modulus of the DSA key, in that order.
-
-   For use in KeyNote credentials, the ASN1 SEQUENCE is then ASCII-
-   encoded (e.g., as a string of hex digits or base64 characters).
-
-   RSA keys encoded in this way in KeyNote must be identified by the
-   "rsa-XXX:" algorithm name, where XXX is an ASCII encoding ("hex" or
-   "base64").  Other ASCII encoding schemes may be defined in the
-   future.
-
-3.3  Binary Identifier Encoding
-
-   Binary Identifiers in KeyNote are assumed to have no internal
-   encoding, and are treated as a sequence of binary digits.  The Binary
-   Identifiers are ASCII-encoded, similarly to RSA or DSA keys.
-
-   Binary Identifiers encoded in this way in KeyNote must be identified
-   by the "binary-XXX:" algorithm name, where XXX is an ASCII encoding
-   ("hex" or "base64").  Other ASCII encoding schemes may be defined in
-   the future.
-
-
-
-
-
-Blaze, et al.                Informational                      [Page 3]
-
-RFC 2792         Key and Signature Encoding for KeyNote       March 2000
-
-
-4.  Signature Computation and Encoding
-
-4.1  DSA Signature Computation and Encoding
-
-   DSA signatures in KeyNote are computed over the assertion body
-   (starting from the beginning of the first keyword, up to and
-   including the newline character immediately before the "Signature:"
-   keyword) and the signature algorithm name (including the trailing
-   colon character, e.g., "sig-dsa-sha1-base64:")
-
-   DSA signatures are then encoded as an ASN1 SEQUENCE of two ASN1
-   INTEGER objects.  The two INTEGER objects are the r and s values of a
-   DSA signature [Sch96], in that order.
-
-   For use in KeyNote credentials, the ASN1 SEQUENCE is then ASCII-
-   encoded (as a string of hex digits or base64 characters).
-
-   DSA signatures encoded in this way in KeyNote must be identified by
-   the "sig-dsa-XXX-YYY:" algorithm name, where XXX is a hash function
-   name ("sha1", for the SHA1 [SHA1-95] hash function is currently the
-   only hash function that may be used with DSA) and YYY is an ASCII
-   encoding ("hex" or "base64").
-
-4.2  RSA Signature Computation and Encoding
-
-   RSA signatures in KeyNote are computed over the assertion body
-   (starting from the beginning of the first keyword, up to and
-   including the newline character immediately before the "Signature:"
-   keyword) and the signature algorithm name (including the trailing
-   colon character, e.g., "sig-rsa-sha1-base64:")
-
-   RSA signatures are then encoded as an ASN1 OCTET STRING object,
-   containing the signature value.
-
-   For use in KeyNote credentials, the ASN1 OCTET STRING is then ASCII-
-   encoded (as a string of hex digits or base64 characters).
-
-   RSA signatures encoded in this way in KeyNote must be identified by
-   the "sig-rsa-XXX-YYY:" algorithm name, where XXX is a hash function
-   name ("md5" or "sha1", for the MD5 [Riv92] and SHA1 [SHA1-95] hash
-   algorithms respectively, may be used with RSA) and YYY is an ASCII
-   encoding ("hex" or "base64").
-
-4.3  Binary Signature Computation and Encoding
-
-   Binary Identifiers are unstructured sequences of binary digits, and
-   are not associated with any cryptographic algorithm.  Thus, they may
-   not be used to validate an assertion.
-
-
-
-Blaze, et al.                Informational                      [Page 4]
-
-RFC 2792         Key and Signature Encoding for KeyNote       March 2000
-
-
-5.  Security Considerations
-
-   This document discusses the format of RSA and DSA keys and signatures
-   and of Binary principal identifiers as used in KeyNote.  The security
-   of KeyNote credentials utilizing such keys and credentials is
-   directly dependent on the strength of the related public key
-   algorithms.  On the security of KeyNote itself, see [BFIK99].
-
-6.  IANA Considerations
-
-   Per [BFIK99], IANA should provide a registry of reserved algorithm
-   identifiers.  The following identifiers are reserved by this document
-   as public key and binary identifier encodings:
-
-   - "rsa-hex"
-   - "rsa-base64"
-   - "dsa-hex"
-   - "dsa-base64"
-   - "binary-hex"
-   - "binary-base64"
-
-   The following identifiers are reserved by this document as signature
-   encodings:
-
-   - "sig-rsa-md5-hex"
-   - "sig-rsa-md5-base64"
-   - "sig-rsa-sha1-hex"
-   - "sig-rsa-sha1-base64"
-   - "sig-dsa-sha1-hex"
-   - "sig-dsa-sha1-base64"
-
-   Note that the double quotes are not part of the algorithm
-   identifiers.
-
-7.  Acknowledgments
-
-   This work was sponsored by the DARPA Information Assurance and
-   Survivability (IA&S) program, under BAA 98-34.
-
-References
-
-   [Sch96]   Bruce Schneier, Applied Cryptography 2nd Edition, John
-             Wiley & Sons, New York, NY, 1996.
-
-   [BFIK99]  Blaze, M., Feigenbaum, J., Ioannidis, J. and A. Keromytis,
-             "The KeyNote Trust-Management System Version 2", RFC 2704,
-             September 1999.
-
-
-
-
-Blaze, et al.                Informational                      [Page 5]
-
-RFC 2792         Key and Signature Encoding for KeyNote       March 2000
-
-
-   [DSA94]   NIST, FIPS PUB 186, "Digital Signature Standard", May 1994.
-
-   [Riv92]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-             April 1992.
-
-   [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.
-
-   [SHA1-95] NIST, FIPS PUB 180-1, "Secure Hash Standard", April 1995.
-             http://csrc.nist.gov/fips/fip180-1.txt (ascii)
-             http://csrc.nist.gov/fips/fip180-1.ps  (postscript)
-
-Contacts
-
-   Comments about this document should be discussed on the
-   keynote-users@nsa.research.att.com mailing list.
-
-   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:
-
-   Matt Blaze
-   AT&T Labs - Research
-   180 Park Avenue
-   Florham Park, New Jersey 07932-0000
-
-   EMail: mab@research.att.com
-
-
-   John Ioannidis
-   AT&T Labs - Research
-   180 Park Avenue
-   Florham Park, New Jersey 07932-0000
-
-   EMail: ji@research.att.com
-
-
-   Angelos D. Keromytis
-   Distributed Systems Lab
-   CIS Department, University of Pennsylvania
-   200 S. 33rd Street
-   Philadelphia, Pennsylvania  19104-6389
-
-   EMail: angelos@cis.upenn.edu
-
-
-
-
-
-Blaze, et al.                Informational                      [Page 6]
-
-RFC 2792         Key and Signature Encoding for KeyNote       March 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blaze, et al.                Informational                      [Page 7]
-
diff --git a/usr.sbin/pppoe/rfc2516.txt b/usr.sbin/pppoe/rfc2516.txt
deleted file mode 100644
index 5397c863dc3..00000000000
--- a/usr.sbin/pppoe/rfc2516.txt
+++ /dev/null
@@ -1,955 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        L. Mamakos
-Request for Comments: 2516                                      K. Lidl
-Category: Informational                                       J. Evarts
-                                               UUNET Technologies, Inc.
-                                                              D. Carrel
-                                                              D. Simone
-                                                 RedBack Networks, Inc.
-                                                             R. Wheeler
-                                                       RouterWare, Inc.
-                                                          February 1999
-
-
-          A Method for Transmitting PPP Over Ethernet (PPPoE)
-
-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.
-
-Abstract
-
-   The Point-to-Point Protocol (PPP) [1] provides a standard method for
-   transporting multi-protocol datagrams over point-to-point links.
-
-   This document describes how to build PPP sessions and encapsulate PPP
-   packets over Ethernet.
-
-Applicability
-
-   This specification is intended to provide the facilities which are
-   defined for PPP, such as the Link Control Protocol, Network-layer
-   Control Protocols, authentication, and more.  These capabilities
-   require a point-to-point relationship between the peers, and are not
-   designed for the multi-point relationships which are available in
-   Ethernet and other multi-access environments.
-
-   This specification can be used by multiple hosts on a shared,
-   Ethernet to open PPP sessions to multiple destinations via one or
-   more bridging modems.  It is intended to be used with broadband
-   remote access technologies that provide a bridged Ethernet topology,
-   when access providers wish to maintain the session abstraction
-   associated with PPP.
-
-
-
-
-Mamakos, et. al.             Informational                      [Page 1]
-
-RFC 2516             Transmitting PPP Over Ethernet        February 1999
-
-
-   This document describes the PPP Over Ethernet encapsulation that is
-   being deployed by RedBack Networks, RouterWare, UUNET and others.
-
-1. Introduction
-
-   Modern access technologies are faced with several conflicting goals.
-   It is desirable to connect multiple hosts at a remote site through
-   the same customer premise access device.  It is also a goal to
-   provide access control and billing functionality in a manner similar
-   to dial-up services using PPP.  In many access technologies, the most
-   cost effective method to attach multiple hosts to the customer
-   premise access device, is via Ethernet.  In addition, it is desirable
-   to keep the cost of this device as low as possible while requiring
-   little or no configuration.
-
-   PPP over Ethernet (PPPoE) provides the ability to connect a network
-   of hosts over a simple bridging access device to a remote Access
-   Concentrator.  With this model, each host utilizes it's own PPP stack
-   and the user is presented with a familiar user interface.  Access
-   control, billing and type of service can be done on a per-user,
-   rather than a per-site, basis.
-
-   To provide a point-to-point connection over Ethernet, each PPP
-   session must learn the Ethernet address of the remote peer, as well
-   as establish a unique session identifier.  PPPoE includes a discovery
-   protocol that provides this.
-
-2. Conventions
-
-   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
-   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
-   document, are to be interpreted as described in [2].
-
-3. Protocol Overview
-
-   PPPoE has two distinct stages.  There is a Discovery stage and a PPP
-   Session stage.  When a Host wishes to initiate a PPPoE session, it
-   must first perform Discovery to identify the Ethernet MAC address of
-   the peer and establish a PPPoE SESSION_ID.  While PPP defines a
-   peer-to-peer relationship, Discovery is inherently a client-server
-   relationship.  In the Discovery process, a Host (the client)
-   discovers an Access Concentrator (the server).  Based on the network
-   topology, there may be more than one Access Concentrator that the
-   Host can communicate with.  The Discovery stage allows the Host to
-   discover all Access Concentrators and then select one.  When
-   Discovery completes successfully, both the Host and the selected
-   Access Concentrator have the information they will use to build their
-   point-to-point connection over Ethernet.
-
-
-
-Mamakos, et. al.             Informational                      [Page 2]
-
-RFC 2516             Transmitting PPP Over Ethernet        February 1999
-
-
-   The Discovery stage remains stateless until a PPP session is
-   established.  Once a PPP session is established, both the Host and
-   the Access Concentrator MUST allocate the resources for a PPP virtual
-   interface.
-
-4. Payloads
-
-   The following packet formats are defined here.  The payload contents
-   will be defined in the Discovery and PPP sections.
-
-   An Ethernet frame is as follows:
-
-                                       1
-                   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
-                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-                  |       DESTINATION_ADDR        |
-                  |          (6 octets)           |
-                  |                               |
-                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-                  |         SOURCE_ADDR           |
-                  |          (6 octets)           |
-                  |                               |
-                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-                  |    ETHER_TYPE  (2 octets)     |
-                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-                  ~                               ~
-                  ~           payload             ~
-                  ~                               ~
-                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-                  |           CHECKSUM            |
-                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   The DESTINATION_ADDR field contains either a unicast Ethernet
-   destination address, or the Ethernet broadcast address (0xffffffff).
-   For Discovery packets, the value is either a unicast or broadcast
-   address as defined in the Discovery section.  For PPP session
-   traffic, this field MUST contain the peer's unicast address as
-   determined from the Discovery stage.
-
-   The SOURCE_ADDR field MUST contains the Ethernet MAC address of the
-   source device.
-
-   The ETHER_TYPE is set to either 0x8863 (Discovery Stage) or 0x8864
-   (PPP Session Stage).
-
-
-
-
-
-
-
-Mamakos, et. al.             Informational                      [Page 3]
-
-RFC 2516             Transmitting PPP Over Ethernet        February 1999
-
-
-   The Ethernet payload for PPPoE is as follows:
-
-                        1                   2                   3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |  VER  | TYPE  |      CODE     |          SESSION_ID           |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |            LENGTH             |           payload             ~
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   The VER field is four bits and MUST be set to 0x1 for this version of
-   the PPPoE specification.
-
-   The TYPE field is four bits and MUST be set to 0x1 for this version
-   of the PPPoE specification.
-
-   The CODE field is eight bits and is defined below for the Discovery
-   and PPP Session stages.
-
-   The SESSION_ID field is sixteen bits.  It is an unsigned value in
-   network byte order.  It's value is defined below for Discovery
-   packets.  The value is fixed for a given PPP session and, in fact,
-   defines a PPP session along with the Ethernet SOURCE_ADDR and
-   DESTINATION_ADDR.  A value of 0xffff is reserved for future use and
-   MUST NOT be used
-
-   The LENGTH field is sixteen bits.  The value, in network byte order,
-   indicates the length of the PPPoE payload.  It does not include the
-   length of the Ethernet or PPPoE headers.
-
-5. Discovery Stage
-
-   There are four steps to the Discovery stage.  When it completes, both
-   peers know the PPPoE SESSION_ID and the peer's Ethernet address,
-   which together define the PPPoE session uniquely.  The steps consist
-   of the Host broadcasting an Initiation packet, one or more Access
-   Concentrators sending Offer packets, the Host sending a unicast
-   Session Request packet and the selected Access Concentrator sending a
-   Confirmation packet.  When the Host receives the Confirmation packet,
-   it may proceed to the PPP Session Stage.  When the Access
-   Concentrator sends the Confirmation packet, it may proceed to the PPP
-   Session Stage.
-
-   All Discovery Ethernet frames have the ETHER_TYPE field set to the
-   value 0x8863.
-
-
-
-
-
-
-Mamakos, et. al.             Informational                      [Page 4]
-
-RFC 2516             Transmitting PPP Over Ethernet        February 1999
-
-
-   The PPPoE payload contains zero or more TAGs.  A TAG is a TLV (type-
-   length-value) construct and is defined as follows:
-
-                        1                   2                   3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |          TAG_TYPE             |        TAG_LENGTH             |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |          TAG_VALUE ...                                        ~
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   TAG_TYPE is a sixteen bit field in network byte order.  Appendix A
-   contains a list of all TAG_TYPEs and their TAG_VALUEs.
-
-   TAG_LENGTH is a sixteen bit field.  It is an unsigned number in
-   network byte order, indicating the length in octets of the TAG_VALUE.
-
-   If a discovery packet is received with a TAG of unknown TAG_TYPE, the
-   TAG MUST be ignored unless otherwise specified in this document.
-   This provides for backwards compatibility if/when new TAGs are added.
-   If new mandatory TAGs are added, the version number will be
-   incremented.
-
-   Some example Discovery packets are shown in Appendix B.
-
-5.1 The PPPoE Active Discovery Initiation (PADI) packet
-
-   The Host sends the PADI packet with the DESTINATION_ADDR set to the
-   broadcast address.  The CODE field is set to 0x09 and the SESSION_ID
-   MUST be set to 0x0000.
-
-   The PADI packet MUST contain exactly one TAG of TAG_TYPE Service-
-   Name, indicating the service the Host is requesting, and any number
-   of other TAG types.  An entire PADI packet (including the PPPoE
-   header) MUST NOT exceed 1484 octets so as to leave sufficient room
-   for a relay agent to add a Relay-Session-Id TAG.
-
-5.2 The PPPoE Active Discovery Offer (PADO) packet
-
-   When the Access Concentrator receives a PADI that it can serve, it
-   replies by sending a PADO packet.  The DESTINATION_ADDR is the
-   unicast address of the Host that sent the PADI.  The CODE field is
-   set to 0x07 and the SESSION_ID MUST be set to 0x0000.
-
-
-
-
-
-
-
-
-Mamakos, et. al.             Informational                      [Page 5]
-
-RFC 2516             Transmitting PPP Over Ethernet        February 1999
-
-
-   The PADO packet MUST contain one AC-Name TAG containing the Access
-   Concentrator's name, a Service-Name TAG identical to the one in the
-   PADI, and any number of other Service-Name TAGs indicating other
-   services that the Access Concentrator offers.  If the Access
-   Concentrator can not serve the PADI it MUST NOT respond with a PADO.
-
-5.3 The PPPoE Active Discovery Request (PADR) packet
-
-   Since the PADI was broadcast, the Host may receive more than one
-   PADO.  The Host looks through the PADO packets it receives and
-   chooses one.  The choice can be based on the AC-Name or the Services
-   offered.  The Host then sends one PADR packet to the Access
-   Concentrator that it has chosen.  The DESTINATION_ADDR field is set
-   to the unicast Ethernet address of the Access Concentrator that sent
-   the PADO.  The CODE field is set to 0x19 and the SESSION_ID MUST be
-   set to 0x0000.
-
-   The PADR packet MUST contain exactly one TAG of TAG_TYPE Service-
-   Name, indicating the service the Host is requesting, and any number
-   of other TAG types.
-
-5.4 The PPPoE Active Discovery Session-confirmation (PADS) packet
-
-   When the Access Concentrator receives a PADR packet, it prepares to
-   begin a PPP session.  It generates a unique SESSION_ID for the PPPoE
-   session and replies to the Host with a PADS packet.  The
-   DESTINATION_ADDR field is the unicast Ethernet address of the Host
-   that sent the PADR.  The CODE field is set to 0x65 and the SESSION_ID
-   MUST be set to the unique value generated for this PPPoE session.
-
-   The PADS packet contains exactly one TAG of TAG_TYPE Service-Name,
-   indicating the service under which Access Concentrator has accepted
-   the PPPoE session, and any number of other TAG types.
-
-   If the Access Concentrator does not like the Service-Name in the
-   PADR, then it MUST reply with a PADS containing a TAG of TAG_TYPE
-   Service-Name-Error (and any number of other TAG types).  In this case
-   the SESSION_ID MUST be set to 0x0000.
-
-5.5 The PPPoE Active Discovery Terminate (PADT) packet
-
-   This packet may be sent anytime after a session is established to
-   indicate that a PPPoE session has been terminated.  It may be sent by
-   either the Host or the Access Concentrator.  The DESTINATION_ADDR
-   field is a unicast Ethernet address, the CODE field is set to 0xa7
-   and the SESSION_ID MUST be set to indicate which session is to be
-   terminated.  No TAGs are required.
-
-
-
-
-Mamakos, et. al.             Informational                      [Page 6]
-
-RFC 2516             Transmitting PPP Over Ethernet        February 1999
-
-
-   When a PADT is received, no further PPP traffic is allowed to be sent
-   using that session.  Even normal PPP termination packets MUST NOT be
-   sent after sending or receiving a PADT.  A PPP peer SHOULD use the
-   PPP protocol itself to bring down a PPPoE session, but the PADT MAY
-   be used when PPP can not be used.
-
-6. PPP Session Stage
-
-   Once the PPPoE session begins, PPP data is sent as in any other PPP
-   encapsulation.  All Ethernet packets are unicast.  The ETHER_TYPE
-   field is set to 0x8864.  The PPPoE CODE MUST be set to 0x00.  The
-   SESSION_ID MUST NOT change for that PPPoE session and MUST be the
-   value assigned in the Discovery stage.  The PPPoE payload contains a
-   PPP frame.  The frame begins with the PPP Protocol-ID.
-
-   An example packet is shown in Appendix B.
-
-7. LCP Considerations
-
-   The Magic Number LCP configuration option is RECOMMENDED, and the
-   Protocol Field Compression (PFC) option is NOT RECOMMENDED.  An
-   implementation MUST NOT request any of the following options, and
-   MUST reject a request for such an option:
-
-      Field Check Sequence (FCS) Alternatives,
-
-      Address-and-Control-Field-Compression (ACFC),
-
-      Asynchronous-Control-Character-Map (ACCM)
-
-   The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a
-   larger size than 1492.  Since Ethernet has a maximum payload size of
-   1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is
-   2 octets, the PPP MTU MUST NOT be greater than 1492.
-
-   It is RECOMMENDED that the Access Concentrator ocassionally send
-   Echo-Request packets to the Host to determine the state of the
-   session.  Otherwise, if the Host terminates a session without sending
-   a Terminate-Request packet, the Access Concentrator will not be able
-   to determine that the session has gone away.
-
-   When LCP terminates, the Host and Access concentrator MUST stop using
-   that PPPoE session.  If the Host wishes to start another PPP session,
-   it MUST return to the PPPoE Discovery stage.
-
-
-
-
-
-
-
-Mamakos, et. al.             Informational                      [Page 7]
-
-RFC 2516             Transmitting PPP Over Ethernet        February 1999
-
-
-8. Other Considerations
-
-   When a host does not receive a PADO packet within a specified amount
-   of time, it SHOULD resend it's PADI packet and double the waiting
-   period. This is repeated as many times as desired.  If the Host is
-   waiting to receive a PADS packet, a similar timeout mechanism SHOULD
-   be used, with the Host re-sending the PADR.  After a specified number
-   of retries, the Host SHOULD then resend a PADI packet.
-
-   The ETHER_TYPEs used in this document (0x8863 and 0x8864) have been
-   assigned by the IEEE for use by PPP Over Ethernet (PPPoE).  Use of
-   these values and the PPPoE VER (version) field uniquely identify this
-   protocol.
-
-   UTF-8 [5] is used throughout this document instead of ASCII.  UTF-8
-   supports the entire ASCII character set while allowing for
-   international character sets as well.  See [5] for more details.
-
-9. Security Considerations
-
-   To help protect against Denial of Service (DOS) attacks, the Access
-   Concentrator can employ the AC-Cookie TAG.  The Access Concentrator
-   SHOULD be able to uniquely regenerate the TAG_VALUE based on the PADR
-   SOURCE_ADDR.  Using this, the Access Concentrator can ensure that the
-   PADI SOURCE_ADDR is indeed reachable and can then limit concurrent
-   sessions for that address.  What algorithm to use is not defined and
-   left as an implementation detail.  An example is HMAC [3] over the
-   Host MAC address using a key known only to the Access > Concentrator.
-   While the AC-Cookie is useful against some DOS attacks, it can not
-   protect against all DOS attacks and an Access Concentrator MAY employ
-   other means to protect resources.
-
-   While the AC-Cookie is useful against some DOS attacks, it can not
-   protect against all DOS attacks and an Access Concentrator MAY employ
-   other means to protect resources.
-
-   Many Access Concentrators will not wish to offer information
-   regarding what services they offer to an unauthenticated entity.  In
-   that case the Access Concentrator should employ one of two policies.
-   It SHOULD never refuse a request based on the Service-Name TAG, and
-   always return the TAG_VALUE that was sent to it.  Or it SHOULD only
-   accept requests with a Service-Name TAG with a zero TAG_LENGTH
-   (indicating any service).  The former solution is RECOMMENDED.
-
-10. Acknowledgments
-
-   This document is based on concepts discussed in several forums,
-   including the ADSL forum.
-
-
-
-Mamakos, et. al.             Informational                      [Page 8]
-
-RFC 2516             Transmitting PPP Over Ethernet        February 1999
-
-
-   Copious amounts of text have been stolen from RFC 1661, RFC 1662 and
-   RFC 2364.
-
-11. References
-
-   [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
-       RFC 1661, July 1994
-
-   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
-       Levels", BCP 14, RFC 2119, March 1997.
-
-   [3] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
-       for Message Authentication", RFC 2104, February 1998.
-
-   [4] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
-       October 1994.  See also: http://www.iana.org/numbers.html
-
-   [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
-       2279, January 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mamakos, et. al.             Informational                      [Page 9]
-
-RFC 2516             Transmitting PPP Over Ethernet        February 1999
-
-
-Appendix A
-
-   TAG_TYPES and TAG_VALUES
-
-   0x0000 End-Of-List
-
-      This TAG indicates that there are no further TAGs in the list. The
-      TAG_LENGTH of this TAG MUST always be zero.  Use of this TAG is
-      not required, but remains for backwards compatibility.
-
-   0x0101 Service-Name
-
-      This TAG indicates that a service name follows.  The TAG_VALUE is
-      an UTF-8 string that is NOT NULL terminated. When the TAG_LENGTH
-      is zero this TAG is used to indicate that any service is
-      acceptable.  Examples of the use of the Service-Name TAG are to
-      indicate an ISP name or a class or quality of service.
-
-   0x0102 AC-Name
-
-      This TAG indicates that a string follows which uniquely identifies
-      this particular Access Concentrator unit from all others. It may
-      be a combination of trademark, model, and serial id information,
-      or simply an UTF-8 rendition of the MAC address of the box.  It is
-      not NULL terminated.
-
-   0x0103 Host-Uniq
-
-      This TAG is used by a Host to uniquely associate an Access
-      Concentrator response (PADO or PADS) to a particular Host request
-      (PADI or PADR).  The TAG_VALUE is binary data of any value and
-      length that the Host chooses.  It is not interpreted by the Access
-      Concentrator.  The Host MAY include a Host-Uniq TAG in a PADI or
-      PADR.  If the Access Concentrator receives this TAG, it MUST
-      include the TAG unmodified in the associated PADO or PADS
-      response.
-
-   0x0104 AC-Cookie
-
-      This TAG is used by the Access Concentrator to aid in protecting
-      against denial of service attacks (see the Security Considerations
-      section for an explanation of how this works).  The Access
-      Concentrator MAY include this TAG in a PADO packet.  If a Host
-      receives this TAG, it MUST return the TAG unmodified in the
-      following PADR.  The TAG_VALUE is binary data of any value and
-      length and is not interpreted by the Host.
-
-
-
-
-
-Mamakos, et. al.             Informational                     [Page 10]
-
-RFC 2516             Transmitting PPP Over Ethernet        February 1999
-
-
-   0x0105 Vendor-Specific
-
-      This TAG is used to pass vendor proprietary information.  The
-      first four octets of the TAG_VALUE contain the vendor id and the
-      remainder is unspecified.  The high-order octet of the vendor id
-      is 0 and the low-order 3 octets are the SMI Network Management
-      Private Enterprise Code of the Vendor in network byte order, as
-      defined in the Assigned Numbers RFC [4].
-
-      Use of this TAG is NOT RECOMMENDED.  To ensure inter-operability,
-      an implementation MAY silently ignore a Vendor-Specific TAG.
-
-   0x0110 Relay-Session-Id
-
-      This TAG MAY be added to any discovery packet by an intermediate
-      agent that is relaying traffic.  The TAG_VALUE is opaque to both
-      the Host and the Access Concentrator.  If either the Host or
-      Access Concentrator receives this TAG they MUST include it
-      unmodified in any discovery packet they send as a response.  All
-      PADI packets MUST guarantee sufficient room for the addition of a
-      Relay-Session-Id TAG with a TAG_VALUE length of 12 octets.
-
-      A Relay-Session-Id TAG MUST NOT be added if the discovery packet
-      already contains one.  In that case the intermediate agent SHOULD
-      use the existing Relay-Session-Id TAG.  If it can not use the
-      existing TAG or there is insufficient room to add a Relay-
-      Session-Id TAG, then it SHOULD return a Generic-Error TAG to the
-      sender.
-
-   0x0201 Service-Name-Error
-
-      This TAG (typically with a zero-length data section) indicates
-      that for one reason or another, the requested Service-Name request
-      could not be honored.
-
-      If there is data, and the first octet of the data is nonzero, then
-      it MUST be a printable UTF-8 string which explains why the request
-      was denied.  This string MAY NOT be NULL terminated.
-
-   0x0202 AC-System-Error
-
-      This TAG indicates that the Access Concentrator experienced some
-      error in performing the Host request.  (For example insufficient
-      resources to create a virtual circuit.)  It MAY be included in
-      PADS packets.
-
-
-
-
-
-
-Mamakos, et. al.             Informational                     [Page 11]
-
-RFC 2516             Transmitting PPP Over Ethernet        February 1999
-
-
-      If there is data, and the first octet of the data is nonzero, then
-      it MUST be a printable UTF-8 string which explains the nature of
-      the error.  This string MAY NOT be NULL terminated.
-
-   0x0203 Generic-Error
-
-      This TAG indicates an error.  It can be added to PADO, PADR or
-      PADS packets when an unrecoverable error occurs and no other error
-      TAG is appropriate.  If there is data then it MUST be an UTF-8
-      string which explains the nature of the error.  This string MUST
-      NOT be NULL terminated.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mamakos, et. al.             Informational                     [Page 12]
-
-RFC 2516             Transmitting PPP Over Ethernet        February 1999
-
-
-Appendix B
-
-   The following are some example packets:
-
-   A PADI packet:
-
-                           1                   2                   3
-       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                         0xffffffff                            |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |           0xffff              |        Host_mac_addr          |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                    Host_mac_addr (cont)                       |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |    ETHER_TYPE = 0x8863        | v = 1 | t = 1 |  CODE = 0x09  |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |     SESSION_ID = 0x0000       |      LENGTH = 0x0004          |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |      TAG_TYPE = 0x0101        |    TAG_LENGTH = 0x0000        |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mamakos, et. al.             Informational                     [Page 13]
-
-RFC 2516             Transmitting PPP Over Ethernet        February 1999
-
-
-   A PADO packet:
-
-                           1                   2                   3
-       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                         Host_mac_addr                         |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |      Host_mac_addr (cont)     | Access_Concentrator_mac_addr  |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |             Access_Concentrator_mac_addr (cont)               |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |    ETHER_TYPE = 0x8863        | v = 1 | t = 1 |  CODE = 0x07  |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |     SESSION_ID = 0x0000       |      LENGTH = 0x0020          |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |      TAG_TYPE = 0x0101        |    TAG_LENGTH = 0x0000        |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |      TAG_TYPE = 0x0102        |    TAG_LENGTH = 0x0018        |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |     0x47      |     0x6f      |     0x20      |     0x52      |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |     0x65      |     0x64      |     0x42      |     0x61      |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |     0x63      |     0x6b      |     0x20      |     0x2d      |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |     0x20      |     0x65      |     0x73      |     0x68      |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |     0x73      |     0x68      |     0x65      |     0x73      |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |     0x68      |     0x6f      |     0x6f      |     0x74      |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mamakos, et. al.             Informational                     [Page 14]
-
-RFC 2516             Transmitting PPP Over Ethernet        February 1999
-
-
-   A PPP LCP packet:  The PPP protocol value is shown (0xc021) but the
-   PPP payload is left to the reader.  This is a packet from the Host to
-   the Access Concentrator.
-
-                           1                   2                   3
-       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                  Access_Concentrator_mac_addr                 |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |Access_Concentrator_mac_addr(c)|        Host_mac_addr          |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                     Host_mac_addr (cont)                      |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |    ETHER_TYPE = 0x8864        | v = 1 | t = 1 |  CODE = 0x00  |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |     SESSION_ID = 0x1234       |      LENGTH = 0x????          |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |    PPP PROTOCOL = 0xc021      |        PPP payload            ~
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-Authors'  Addresses
-
-   Louis Mamakos
-   UUNET Technologies, Inc.
-   3060 Williams Drive
-   Fairfax, VA  22031-4648
-   United States of America
-
-   EMail: louie@uu.net
-
-
-   Kurt Lidl
-   UUNET Technologies, Inc.
-   3060 Williams Drive
-   Fairfax, VA  22031-4648
-   United States of America
-
-   EMail: lidl@uu.net
-
-
-   Jeff Evarts
-   UUNET Technologies, Inc.
-   3060 Williams Drive
-   Fairfax, VA  22031-4648
-   United States of America
-
-   EMail: jde@uu.net
-
-
-
-
-Mamakos, et. al.             Informational                     [Page 15]
-
-RFC 2516             Transmitting PPP Over Ethernet        February 1999
-
-
-   David Carrel
-   RedBack Networks, Inc.
-   1389 Moffett Park Drive
-   Sunnyvale, CA  94089-1134
-   United States of America
-
-   EMail: carrel@RedBack.net
-
-
-   Dan Simone
-   RedBack Networks, Inc.
-   1389 Moffett Park Drive
-   Sunnyvale, CA  94089-1134
-   United States of America
-
-   EMail:dan@RedBack.net
-
-
-   Ross Wheeler
-   RouterWare, Inc.
-   3961 MacArthur Blvd., Suite 212
-   Newport Beach, CA  92660
-   United States of America
-
-   EMail: ross@routerware.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mamakos, et. al.             Informational                     [Page 16]
-
-RFC 2516             Transmitting PPP Over Ethernet        February 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mamakos, et. al.             Informational                     [Page 17]
-