added more up to date documentation

9 files changed, 1920 insertions, 3632 deletions

diff --git a/doc/protocol/draft-ietf-pkix-ac509prof-05.txt b/doc/protocol/draft-ietf-pkix-ac509prof-05.txt
deleted file mode 100644
index 7bd8e4e54a..0000000000
--- a/doc/protocol/draft-ietf-pkix-ac509prof-05.txt
+++ /dev/null
@@ -1,2184 +0,0 @@
-
-
-
-PKIX Working Group                                          S. Farrell
-INTERNET-DRAFT                                  Baltimore Technologies
-Expires in six months                                       R. Housley
-                                                                SPYRUS
-                                                         8 August 2000
-
-                     An Internet Attribute Certificate
-                         Profile for Authorization
-                    <draft-ietf-pkix-ac509prof-05.txt>
-
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of [RFC2026].
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that
-   other groups may also distribute working documents as Internet-
-   Drafts. Internet-Drafts are draft documents valid for a maximum of
-   six months and may be updated, replaced, or obsoleted by other
-   documents at any time. It is inappropriate to use Internet- Drafts
-   as reference material or to cite them other than as "work in
-   progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-   This specification defines a profile for the use of X.509 Attribute
-   Certificates in Internet Protocols. Attribute certificates may be
-   used in a wide range of applications and environments covering a
-   broad spectrum of interoperability goals and a broader spectrum of
-   operational and assurance requirements. The goal of this document is
-   to establish a common baseline for generic applications requiring
-   broad interoperability as well as limited special purpose
-   requirements.  The profile places emphasis on attribute certificate
-   support for Internet electronic mail, IPSec, and WWW security
-   applications.
-
-
-
-
-
-
-
-
-
-
-Farrell & Housley                                             [Page 1]
-
-INTERNET-DRAFT                                             August 2000
-
-
-Table of Contents
-
-   Status of this Memo.............................................1
-   Abstract........................................................1
-   Table of Contents...............................................1
-   1. Introduction.................................................3
-       1.1  Delegation and AC chains...............................4
-       1.2  Attribute Certificate Distribution ("push" vs. "pull").4
-       1.3  Document Structure.....................................5
-   2. Terminology..................................................6
-   3. Requirements.................................................7
-   4. Attribute Certificate Profile................................8
-       4.1  X.509 Attribute Certificate Definition.................8
-       4.2  Profile of Standard Fields............................10
-           4.2.1  Version.........................................10
-           4.2.2  Holder..........................................10
-           4.2.3  Issuer..........................................11
-           4.2.4  Signature.......................................12
-           4.2.5  Serial Number...................................12
-           4.2.6  Validity Period.................................12
-           4.2.7  Attributes......................................13
-           4.2.8  Issuer Unique Identifier........................13
-           4.2.9  Extensions......................................13
-       4.3  Extensions............................................14
-           4.3.1  Audit Identity..................................14
-           4.3.2  AC Targeting....................................15
-           4.3.3  Authority Key Identifier........................16
-           4.3.4  Authority Information Access....................16
-           4.3.5  CRL Distribution Points.........................17
-           4.3.6  No Revocation Available.........................17
-       4.4  Attribute Types.......................................17
-           4.4.1  Service Authentication Information..............18
-           4.4.2  Access Identity.................................18
-           4.4.3  Charging Identity...............................19
-           4.4.4  Group...........................................19
-           4.4.5  Role............................................19
-           4.4.6  Clearance.......................................20
-       4.5  Profile of AC issuer's PKC............................21
-   5. Attribute Certificate Validation............................22
-   6. Revocation..................................................23
-   7. Optional Features...........................................24
-       7.1  Attribute Encryption..................................24
-       7.2  Proxying..............................................25
-       7.3  Use of ObjectDigestInfo...............................26
-       7.4  AA Controls...........................................27
-   8. Security Considerations.....................................29
-   9. References..................................................31
-   Author's Addresses.............................................32
-   Full Copyright Statement.......................................32
-   Appendix A: Object Identifiers.................................33
-   Appendix B: ASN.1 Module.......................................34
-
-
-
-Farrell & Housley                                             [Page 2]
-
-INTERNET-DRAFT                                             August 2000
-
-
-1. Introduction
-
-   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
-   in this document are to be interpreted as described in [RFC2119].
-
-   X.509 public key certificates (PKCs) [X.509-1997, X.509-2000,
-   PKIXPROF] bind an identity and a public key. An attribute
-   certificate (AC) is a structure similar to a PKC; the main
-   difference being that the AC contains no public key. An AC may
-   contain attributes that specify group membership, role, security
-   clearance, or other authorization information associated with the AC
-   holder. The syntax for the AC is defined in Recommendation X.509,
-   making the term "X.509 certificate" ambiguous.
-
-   Some people constantly confuse PKCs and ACs. An analogy may make the
-   distinction clear. A PKC can be considered to be like a passport: it
-   identifies the holder, tends to last for a long time, and should not
-   be trivial to obtain. An AC is more like an entry visa: it is
-   typically issued by a different authority and does not last for as
-   long a time. As acquiring an entry visa typically requires
-   presenting a passport, getting a visa can be a simpler process.
-
-   Authorization information may be placed in a PKC extension or placed
-   in a separate attribute certificate (AC). The placement of
-   authorization information in PKCs is usually undesirable for two
-   reasons. First, authorization information often does not have the
-   same lifetime as the binding of the identity and the public key.
-   When authorization information is placed in a PKC extension, the
-   general result is the shortening of the PKC useful lifetime. Second,
-   the PKC issuer is not usually authoritative for the authorization
-   information. This results in additional steps for the PKC issuer to
-   obtain authorization information from the authoritative source.
-
-   For these reasons, it is often better to separate authorization
-   information from the PKC. Yet, authorization information also needs
-   to be bound to an identity. An AC provides this binding; it is
-   simply a digitally signed (or certified) identity and set of
-   attributes.
-
-   An AC may be used with various security services, including access
-   control, data origin authentication, and non-repudiation.
-
-   PKCs can provide an identity to access control decision functions.
-   However, in many contexts the identity is not the criterion that is
-   used for access control decisions, rather the role or group-
-   membership of the accessor is the criterion used. Such access
-   control schemes are called role-based access control.
-
-   When making an access control decision based on an AC, an access
-   control decision function may need to ensure that the appropriate AC
-   holder is the entity that has requested access. One way in which the
-   linkage between the request or identity and the AC can be achieved
-   is the inclusion of a reference to a PKC within the AC and the use
-
-Farrell & Housley                                             [Page 3]
-
-INTERNET-DRAFT                                             August 2000
-
-
-   of the private key corresponding to the PKC for authentication
-   within the access request.
-
-   ACs may also be used in the context of a data origin authentication
-   service and a non-repudiation service. In these contexts, the
-   attributes contained in the AC provide additional information about
-   the signing entity. This information can be used to make sure that
-   the entity is authorized to sign the data. This kind of checking
-   depends either on the context in which the data is exchanged or on
-   the data that has been digitally signed.
-
-1.1 Delegation and AC chains
-
-   The X.509 standard [X.509-2000] defines authorization as the
-   "conveyance of privilege from one entity that holds such privilege,
-   to another entity". An AC is one authorization mechanism.
-
-   An ordered sequence of ACs could be used to verify the authenticity
-   of a privilege asserter's privilege. In this way, chains or paths of
-   ACs could be employed to delegate authorization.
-
-   Since the administration and processing associated with such AC
-   chains is complex and the use of ACs in the Internet today is quite
-   limited, this specification does NOT RECOMMEND the use of AC chains.
-   Other (future) specifications may address the use of AC chains. This
-   specification deals with the simple cases where one authority issues
-   all of the ACs for a particular set of attributes. However, this
-   simplification does not preclude the use of several different
-   authorities, each of which manages a different set of attributes.
-   For example, group membership may be included in one AC issued by
-   one authority, and security clearance may be included in another AC
-   issued by another authority.
-
-   This means that conformant implementations are only REQUIRED to be
-   able to process a single AC at a time. Processing of more than one
-   AC, one after another, may be necessary. Note however, that
-   validation of an AC MAY require validation of a chain of PKCs, as
-   specified in [PKIXPROF].
-
-1.2 Attribute Certificate Distribution ("push" vs. "pull")
-
-   As discussed above, ACs provide a mechanism to securely provide
-   authorization information to, for example, access control decision
-   functions. However, there are a number of possible communication
-   paths for ACs.
-
-   In some environments it is suitable for a client to "push" an AC to
-   a server. This means that no new connections between the client and
-   server are required. It also means that no search burden is imposed
-   on servers, which improves performance and that the AC verifier is
-   only presented with what it "needs to know." In inter-domain cases
-   where the client's rights should be assigned within client's "home"
-   domain, the "push" model is especially suitable.
-
-Farrell & Housley                                             [Page 4]
-
-INTERNET-DRAFT                                             August 2000
-
-
-   In other cases, it is more suitable for a client simply to
-   authenticate to the server and for the server to request or "pull"
-   the client's AC from an AC issuer or a repository. A major benefit
-   of the "pull" model is that it can be implemented without changes to
-   the client or to the client-server protocol. The "pull" model is
-   especially suitable for inter-domain cases where the client's rights
-   should be assigned within the server's domain, rather than within
-   the client's domain.
-
-   There are a number of possible exchanges involving three entities:
-   the client, the server, and the AC issuer. In addition, a directory
-   service or other repository for AC retrieval MAY be supported.
-
-   Figure 1 shows an abstract view of the exchanges that may involve
-   ACs. This profile does not specify a protocol for these exchanges.
-
-
-      +--------------+
-      |              |        Server Acquisition
-      |  AC issuer   +----------------------------+
-      |              |                            |
-      +--+-----------+                            |
-         |                                        |
-         | Client                                 |
-         | Acquisition                            |
-         |                                        |
-      +--+-----------+                         +--+------------+
-      |              |       AC "push"         |               |
-      |   Client     +-------------------------+    Server     |
-      |              | (part of app. protocol) |               |
-      +--+-----------+                         +--+------------+
-         |                                        |
-         | Client                                 | Server
-         | Lookup        +--------------+         | Lookup
-         |               |              |         |
-         +---------------+  Repository  +---------+
-                         |              |
-                         +--------------+
-
-                     Figure 1: AC Exchanges
-
-1.3 Document Structure
-
-   Section 2 defines some terminology. Section 3 specifies the
-   requirements that this profile is intended to meet.; Section 4
-   contains the profile of the X.509 AC. Section 5 specifies rules for
-   AC validation. Section 6 specifies rules for AC revocation checks.
-   Section 7 specifies optional features which MAY be supported;
-   however, support for these features is not required for conformance
-   to this profile.  Finally, appendices contain the list of OIDs
-   required to support this specification and an ASN.1 module.
-
-
-
-Farrell & Housley                                             [Page 5]
-
-INTERNET-DRAFT                                             August 2000
-
-
-2. Terminology
-
-   For simplicity, we use the terms client and server in this
-   specification. This is not intended to indicate that ACs are only to
-   be used in client-server environments.  For example, ACs may be used
-   in the S/MIME v3 context, where the mail user agent would be both a
-   "client" and a "server" in the sense the terms are used here.
-
-    Term          Meaning
-
-    AA            Attribute Authority, the entity that issues the
-                  AC, synonymous in this specification with "AC
-                  issuer"
-    AC            Attribute Certificate
-    AC user       any entity that parses or processes an AC
-    AC verifier   any entity that checks the validity of an AC and
-                  then makes use of the result
-    AC issuer     the entity which signs the AC, synonymous in this
-                  specification with "AA"
-    AC holder     the entity indicated (perhaps indirectly) in the
-                  holder field of the AC
-    Client        the entity which is requesting the action for
-                  which authorization checks are to be made
-    Proxying      in this specification, Proxying is used to mean
-                  the situation where an application server acts as
-                  an application client on behalf of a user.
-                  Proxying here does not mean granting of authority.
-    PKC           Public Key Certificate - uses the type ASN.1
-                  Certificate defined in X.509 and profiled in RFC
-                  2459. This (non-standard) acronym is used in order
-                  to avoid confusion about the term "X.509
-                  certificate".
-    Server        the entity which requires that the authorization
-                  checks are made
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell & Housley                                             [Page 6]
-
-INTERNET-DRAFT                                             August 2000
-
-
-3. Requirements
-
-   This AC profile meets the following requirements.
-
-   Time/Validity requirements:
-
-   1.   Support for short-lived as well as long-lived ACs. Typical
-        short-lived validity periods might be measured in hours, as
-        opposed to months for PKCs. Short validity periods allow ACs to
-        be useful without a revocation mechanism.
-
-   Attribute Types:
-
-   2.   Issuers of ACs should be able to define their own attribute
-        types for use within closed domains.
-   3.   Some standard attribute types should be defined which can be
-        contained within ACs.  Examples include "access identity,"
-        "group," "role," "clearance," "audit identity," and "charging
-        identity."
-   4.   Standard attribute types should be defined in a manner that
-        permits an AC verifier to distinguish between uses of the same
-        attribute in different domains.  For example, the
-        "Administrators group" as defined by Baltimore and the
-        "Administrators group" as defined by SPYRUS should be easily
-        distinguished.
-
-   Targeting of ACs:
-
-   5.   It should be possible to "target" an AC at one, or a small
-        number of, servers. This means that a trustworthy non-target
-        server will reject the AC for authorization decisions.
-
-   Push vs. Pull
-
-   6.   ACs should be defined so that they can either be "pushed" by
-        the client to the server, or "pulled" by the server from a
-        repository or other network service, including an online AC
-        issuer.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell & Housley                                             [Page 7]
-
-INTERNET-DRAFT                                             August 2000
-
-
-4. Attribute Certificate Profile
-
-   ACs may be used in a wide range of applications and environments
-   covering a broad spectrum of interoperability goals and a broader
-   spectrum of operational and assurance requirements.  The goal of
-   this document is to establish a common baseline for generic
-   applications requiring broad interoperability and limited special
-   purpose requirements.  In particular, the emphasis will be on
-   supporting the use of attribute certificates for informal Internet
-   electronic mail, IPSec, and WWW applications.
-
-   This section presents a profile for ACs that will foster
-   interoperability. This section also defines some private extensions
-   for the Internet community.
-
-   While the ISO/IEC/ITU documents use the 1993 (or later) version of
-   ASN.1; this document uses the 1988 ASN.1 syntax, as has been done
-   for PKCs [PKIXPROF]. The encoded certificates and extensions from
-   either ASN.1 version are bit-wise identical.
-
-   Where maximum lengths for fields are specified, these lengths refer
-   to the DER encoding and do not include the ASN.1 tag or length
-   fields.
-
-   Conforming implementations MUST support the profile specified in
-   this section.
-
-4.1 X.509 Attribute Certificate Definition
-
-   X.509 contains the definition of an AC given below. All types that
-   are not defined in this document can be found in [PKIXPROF].
-
-           AttributeCertificate ::= SEQUENCE {
-                acinfo               AttributeCertificateInfo,
-                signatureAlgorithm   AlgorithmIdentifier,
-                signatureValue       BIT STRING
-           }
-
-           AttributeCertificateInfo ::= SEQUENCE {
-                version              AttCertVersion DEFAULT v1,
-                holder               Holder,
-                issuer               AttCertIssuer,
-                signature            AlgorithmIdentifier,
-                serialNumber         CertificateSerialNumber,
-                attrCertValidityPeriod   AttCertValidityPeriod,
-                attributes           SEQUENCE OF Attribute,
-                issuerUniqueID       UniqueIdentifier OPTIONAL,
-                extensions           Extensions OPTIONAL
-           }
-
-           AttCertVersion ::= INTEGER { v1(0), v2(1) }
-
-
-
-Farrell & Housley                                             [Page 8]
-
-INTERNET-DRAFT                                             August 2000
-
-
-
-           Holder ::= SEQUENCE {
-                 baseCertificateID   [0] IssuerSerial OPTIONAL,
-                          -- the issuer and serial number of
-                          -- the holder's Public Key Certificate
-                 entityName          [1] GeneralNames OPTIONAL,
-                          -- the name of the claimant or role
-                 objectDigestInfo    [2] ObjectDigestInfo OPTIONAL
-                          -- if present, version must be v2
-           }
-
-           ObjectDigestInfo ::= SEQUENCE {
-                digestedObjectType  ENUMERATED {
-                        publicKey            (0),
-                        publicKeyCert        (1),
-                        otherObjectTypes     (2) },
-                                -- otherObjectTypes MUST NOT
-                                -- be used in this profile
-                otherObjectTypeID   OBJECT IDENTIFIER OPTIONAL,
-                digestAlgorithm     AlgorithmIdentifier,
-                objectDigest        BIT STRING
-           }
-
-           AttCertIssuer ::= CHOICE {
-                v1Form   GeneralNames,  -- v1 or v2
-                v2Form   [0] V2Form     -- v2 only
-           }
-
-           V2Form ::= SEQUENCE {
-                issuerName            GeneralNames  OPTIONAL,
-                baseCertificateID     [0] IssuerSerial  OPTIONAL,
-                objectDigestInfo      [1] ObjectDigestInfo  OPTIONAL
-                      -- at least one of issuerName, baseCertificateID
-                      -- or objectDigestInfo MUST be present
-           }
-
-           IssuerSerial  ::=  SEQUENCE {
-                issuer         GeneralNames,
-                serial         CertificateSerialNumber,
-                issuerUID      UniqueIdentifier OPTIONAL
-           }
-
-           AttCertValidityPeriod  ::= SEQUENCE {
-                notBeforeTime  GeneralizedTime,
-                notAfterTime   GeneralizedTime
-           }
-
-
-
-
-
-
-
-
-Farrell & Housley                                             [Page 9]
-
-INTERNET-DRAFT                                             August 2000
-
-
-   Although the Attribute syntax is defined in [PKIXPROF], we repeat
-   the definition here for convenience.
-
-           Attribute ::= SEQUENCE {
-                 type      AttributeType,
-                 values    SET OF AttributeValue
-                   -- at least one value is required
-           }
-
-           AttributeType ::= OBJECT IDENTIFIER
-
-           AttributeValue ::= ANY DEFINED BY AttributeType
-
-   Implementers should note that the DER encoding (see [X.509-
-   1988],[X.208-1988]) of the SET OF values requires ordering of the
-   encodings of the values. Though this issue arises with respect to
-   distinguished names, and has to be handled by [PKIXPROF]
-   implementations, its is much more significant in this context, since
-   the inclusion of multiple values is much more common in ACs.
-
-4.2 Profile of Standard Fields
-
-   For all GeneralName fields in this profile the otherName (except as
-   noted below), x400Address, ediPartyName and registeredID options
-   MUST NOT be used.  The use of Kerberos [KRB] principal names,
-   encoded into the otherName, SHOULD however, be supported using the
-   krb5PrincipalName OID and the KerberosName syntax as defined in
-   [PKINIT].
-
-   Conforming implementations MUST be able to support the dNSName,
-   directoryName, uniformResourceIdentifier, and iPAddress fields in
-   all cases where GeneralName is used. This is compatible with the
-   GeneralName requirements in [PKIXPROF] (mainly in section 4.2.1.7).
-
-4.2.1   Version
-
-   The version field MUST be the default value of v1.  That is, the
-   version field is not present in the DER encoding, except when the
-   holder is identified using the optional objectDigestInfo field, as
-   specified in section 7.3.
-
-4.2.2   Holder
-
-   For any environment where the AC is passed in an authenticated
-   message or session and where the authentication is based on the use
-   of an X.509 PKC, the holder field SHOULD use the baseCertificateID.
-
-   With the baseCertificateID option, the holder's PKC serialNumber and
-   issuer MUST be identical to the AC holder field. The PKC issuer MUST
-   have a non-empty distinguished name which is to be present as the
-   single value of the holder.baseCertificateID.issuer construct in the
-   directoryName field. The AC holder.baseCertificateID.issuerUID field
-   MUST only be used if the holder's PKC contains an issuerUniqueID
-
-Farrell & Housley                                            [Page 10]
-
-INTERNET-DRAFT                                             August 2000
-
-
-   field. If both the AC holder.baseCertificateID.issuerUID and the PKC
-   issuerUniqueID fields are present, then the same value MUST be
-   present in both fields. Thus, the baseCertificateID is only usable
-   with PKC profiles (like [PKIXPROF]) which mandate that the PKC
-   issuer field contain a non-empty distinguished name value.
-
-   Note: An empty distinguished name is a distinguished name where the
-   SEQUENCE OF relative distinguished names is of zero length. In a DER
-   encoding this has the value '3000'H.
-
-   If the holder field uses the entityName option and the underlying
-   authentication is based on a PKC, then the entityName MUST be the
-   same as the PKC subject field, unless the PKC subject field contains
-   an empty distinguished name. If the PKC subject field contains an
-   empty distinguished name, then the entityName field MUST be
-   identical to one of the values of the PKC subjectAltName field
-   extension. Note that [PKIXPROF] mandates that the subjectAltNames
-   extension be present if the PKC subject is an empty distinguished
-   name. See the security consideration section which mentions some
-   name collision problems that may arise when using the entityName
-   option.
-
-   In any other case where the holder field uses the entityName option,
-   then only one name SHOULD be present.
-
-   Implementations conforming to this profile are not required to
-   support the use of the objectDigest field. However, section 7.3
-   specifies how this optional feature MAY be used.
-
-   Any protocol conforming to this profile SHOULD specify which AC
-   holder option is to be used and how this fits with the supported
-   authentication schemes defined in that protocol.
-
-4.2.3   Issuer
-
-   ACs conforming to this profile MUST use the v1Form choice, which
-   MUST contain one and only one GeneralName, which MUST contain a non-
-   empty distinguished name in the directoryName field. This means that
-   all AC issuers MUST have non-empty distinguished names.
-
-   Part of the reason for the use of the v1Form field is that it means
-   that the AC issuer does not have to know which PKC the AC verifier
-   will use for it (the AC issuer). Using the baseCertificateID field
-   to reference the AC issuer would mean that the AC verifier would
-   have to trust the PKC that the AC issuer chose (for itself) at AC
-   creation time.
-
-
-
-
-
-
-
-
-Farrell & Housley                                            [Page 11]
-
-INTERNET-DRAFT                                             August 2000
-
-
-4.2.4   Signature
-
-   Contains the algorithm identifier used to validate the AC signature.
-
-   This MUST be one of the signing algorithms defined in [PKIXALGS].
-
-   id-dsa-with-sha1 MUST be supported by all AC users. The other
-   algorithms MAY be supported.
-
-4.2.5   Serial Number
-
-   For any conforming AC, the issuer/serialNumber pair MUST form a
-   unique combination, even if ACs are very short-lived.
-
-   AC issuers MUST force the serialNumber to be a positive integer,
-   that is, the sign bit in the DER encoding of the INTEGER value MUST
-   be zero - this can be done by adding a leading (leftmost) '00'H
-   octet if necessary. This removes a potential ambiguity in mapping
-   between a string of octets and an integer value.
-
-   Given the uniqueness and timing requirements above serial numbers
-   can be expected to contain long integers. AC users MUST be able to
-   handle serialNumber values longer than 4 octets. Conformant ACs MUST
-   NOT contain serialNumber values longer than 20 octets.
-
-   There is no requirement that the serial numbers used by any AC
-   issuer follow any particular ordering, in particular, they need not
-   be monotonically increasing with time. Each AC issuer MUST ensure
-   that each AC that it issues contain a unique serial number.
-
-4.2.6   Validity Period
-
-   The attrCertValidityPeriod (a.k.a. validity) field specifies the
-   period for which the AC issuer certifies that the binding between
-   the holder and the attributes fields will be valid.
-
-   The generalized time type, GeneralizedTime, is a standard ASN.1 type
-   for variable precision representation of time. The GeneralizedTime
-   field can optionally include a representation of the time
-   differential between the local time zone and Greenwich Mean Time.
-
-   For the purposes of this profile, GeneralizedTime values MUST be
-   expressed in Coordinated universal time (UTC) (also known as
-   Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times
-   are YYYYMMDDHHMMSSZ), even when the number of seconds is zero.
-   GeneralizedTime values MUST NOT include fractional seconds.
-   (Note: this is the same as specified in [PKIXPROF], section
-   4.1.2.5.2.)
-
-   AC users MUST be able to handle an AC which, at the time of
-   processing, has parts of its validity period or all its validity
-   period in the past or in the future (a post-dated AC). This is valid
-   for some applications, such as backup.
-
-Farrell & Housley                                            [Page 12]
-
-INTERNET-DRAFT                                             August 2000
-
-
-
-4.2.7   Attributes
-
-   The attributes field gives information about the AC holder. When the
-   AC is used for authorization this will often contain a set of
-   privileges.
-
-   The attributes field contains a SEQUENCE OF Attribute. Each
-   Attribute MAY contain a SET OF values. For a given AC, each
-   AttributeType OBJECT IDENTIFIER in the sequence MUST be unique. That
-   is, only one instance of each attribute can occur in a single AC,
-   but each instance can be multi-valued.
-
-   AC users MUST be able to handle multiple values for all attribute
-   types.
-
-   An AC MUST contain at least one attribute. That is, the SEQUENCE OF
-   Attributes MUST NOT be of zero length.
-
-   Some standard attribute types are defined in section 4.5.
-
-4.2.8   Issuer Unique Identifier
-
-   This field MUST NOT be used unless it is also used in the AC
-   issuer's PKC, in which case it MUST be used. Note that [PKIXPROF]
-   states that this field SHOULD NOT be used by conforming CAs, but
-   that applications SHOULD be able to parse PKCs containing the field.
-
-4.2.9   Extensions
-
-   The extensions field generally gives information about the AC as
-   opposed to information about the AC holder.
-
-   An AC that has no extensions conforms to the profile; however,
-   section 4.3 defines the extensions that MAY be used with this
-   profile, and whether or not they may be marked critical. If any
-   other critical extension is used, then the AC does not conform to
-   this profile. However, if any other non-critical extension is used,
-   then the AC does conform to this profile.
-
-   The extensions defined for ACs provide methods for associating
-   additional attributes with holders.  This profile also allows
-   communities to define private extensions to carry information unique
-   to those communities.  Each extension in an AC may be designated as
-   critical or non-critical.  An AC using system MUST reject an AC if
-   it encounters a critical extension it does not recognize; however, a
-   non-critical extension may be ignored if it is not recognized.
-   Section 4.3 presents recommended extensions used within Internet ACs
-   and standard locations for information.  Communities may elect to
-   use additional extensions; however, caution should be exercised in
-   adopting any critical extensions in ACs, which might prevent use in
-   a general context.
-
-
-Farrell & Housley                                            [Page 13]
-
-INTERNET-DRAFT                                             August 2000
-
-
-4.3 Extensions
-
-4.3.1   Audit Identity
-
-   In some circumstances it is required (e.g. by data protection/data
-   privacy legislation) that audit trails do not contain records which
-   directly identify individuals. This circumstance may make the use of
-   the AC holder field unsuitable for use in audit trails.
-
-   To allow for such cases, an AC MAY contain an audit identity
-   extension. Ideally it SHOULD be infeasible to derive the AC holder's
-   identity from the audit identity value without the co-operation of
-   the AC issuer.
-
-   The value of the audit identity along with the AC issuer/serial
-   SHOULD then be used for audit/logging purposes. If the value of the
-   audit identity is suitably chosen, then a server/service
-   administrator can use audit trails to track the behavior of an AC
-   holder without being able to identify the AC holder.
-
-   The server/service administrator in combination with the AC issuer
-   MUST be able to identify the AC holder in cases where misbehavior is
-   detected. This means that the AC issuer MUST be able to determine
-   the actual identity of the AC holder from the audit identity.
-
-   Of course, auditing could be based on the AC issuer/serial pair;
-   however, this method doesn't allow tracking the same AC holder with
-   multiple ACs. Thus, an audit identity is only useful if it lasts for
-   longer than the typical AC lifetime. Auditing could also be based on
-   the AC holder's PKC issuer/serial; however, this will often allow
-   the server/service administrator to identify the AC holder.
-
-   As the AC verifier might otherwise use the AC holder or some other
-   identifying value for audit purposes, this extension MUST be
-   critical when used.
-
-   Protocols that use ACs will often expose the identity of the AC
-   holder in the bits on-the-wire. In such cases, an opaque audit
-   identity does not make use of the AC anonymous, it simply ensures
-   that the ensuing audit trails do not contain identifying
-   information.
-
-   The value of an audit identity MUST be longer than zero octets.  The
-   value of an audit identity MUST NOT be longer than 20 octets.
-
-      name           id-pe-ac-auditIdentity
-      OID            { id-pe 4 }
-      syntax         OCTET STRING
-      criticality    MUST be TRUE
-
-
-
-
-
-Farrell & Housley                                            [Page 14]
-
-INTERNET-DRAFT                                             August 2000
-
-
-4.3.2   AC Targeting
-
-   To target an AC, the target information extension, imported from
-   [X.509-2000], MAY be used to specify a number of servers/services.
-   The intent is that the AC SHOULD only be usable at the specified
-   servers/services. An (honest) AC verifier who is not amongst the
-   named servers/services MUST reject the AC.
-
-   If this extension is not present, then the AC is not targeted and
-   may be accepted by any server.
-
-   In this profile, the targeting information simply consists of a list
-   of named targets or groups.
-
-   The following syntax is used to represent the targeting information:
-
-          Targets ::= SEQUENCE OF Target
-
-          Target  ::= CHOICE {
-            targetName          [0] GeneralName,
-            targetGroup         [1] GeneralName,
-            targetCert          [2] TargetCert
-          }
-
-          TargetCert  ::= SEQUENCE {
-            targetCertificate    IssuerSerial,
-            targetName           GeneralName OPTIONAL,
-            certDigestInfo       ObjectDigestInfo OPTIONAL
-          }
-
-   The targetCert CHOICE within the Target structure is only present to
-   allow future compatibility with [X.509-2000] and MUST NOT be used.
-
-   The targets check passes if the current server (recipient) is one of
-   the targetName fields in the Targets SEQUENCE, or if the current
-   server is a member of one of the targetGroup fields in the Targets
-   SEQUENCE. In this case, the current server is said to "match" the
-   targeting extension.
-
-   How the membership of a target within a targetGroup is determined is
-   not defined here. It is assumed that any given target "knows" the
-   names of the targetGroups to which it belongs or can otherwise
-   determine its membership. For example, the targetGroup specifies a
-   DNS domain, and the AC verifier knows the DNS domain to which it
-   belongs. For another example, the targetGroup specifies "PRINTERS,"
-   and the AC verifier knows whether or not it is a printer or print
-   server.
-
-   Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF
-   Targets". Conforming AC issuer implementations MUST only produce one
-   "Targets" element. Confirming AC users MUST be able to accept a
-   "SEQUENCE OF Targets". If more than one Targets element is found in
-
-
-Farrell & Housley                                            [Page 15]
-
-INTERNET-DRAFT                                             August 2000
-
-
-   an AC, then the extension MUST be treated as if all Target elements
-   had been found within one Targets element.
-
-      name           id-ce-targetInformation
-      OID            { id-ce 55 }
-      syntax         SEQUENCE OF Targets
-      criticality    MUST be TRUE
-
-4.3.3   Authority Key Identifier
-
-   The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY
-   be used to assist the AC verifier in checking the signature of the
-   AC. The [PKIXPROF] description should be read as if "CA" meant "AC
-   issuer." As with PKCs this extension SHOULD be included in ACs.
-
-   Note: An AC where the issuer field used the baseCertificateID CHOICE
-   would not need an authorityKeyIdentifier extension as it is
-   explicitly linked to the key in the referred certificate. However,
-   as this profile states (in section 4.2.3) that ACs MUST use the
-   v1Form CHOICE, this duplication does not arise.
-
-      name           id-ce-authorityKeyIdentifier
-      OID            { id-ce 35 }
-      syntax         AuthorityKeyIdentifier
-      criticality    MUST be FALSE
-
-4.3.4   Authority Information Access
-
-   The authorityInformationAccess extension, as defined in [PKIXPROF],
-   MAY be used to assist the AC verifier in checking the revocation
-   status of the AC. Support for the id-ad-caIssuers accessMethod is
-   NOT REQUIRED by this profile since AC chains are not expected.
-
-   The following accessMethod is used to indicate that revocation
-   status checking is provided for this AC, using the OCSP protocol
-   defined in [OCSP]:
-
-      id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
-
-   The accessLocation MUST contain a URI, and the URI MUST contain an
-   HTTP URL [URL] that specifies the location of an OCSP responder. The
-   AC issuer MUST, of course, maintain an OCSP responder at this
-   location.
-
-      name           id-ce-authorityInfoAccess
-      OID            { id-pe 1 }
-      syntax         AuthorityInfoAccessSyntax
-      criticality    MUST be FALSE
-
-
-
-
-
-
-Farrell & Housley                                            [Page 16]
-
-INTERNET-DRAFT                                             August 2000
-
-
-4.3.5   CRL Distribution Points
-
-   The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY
-   be used to assist the AC verifier in checking the revocation status
-   of the AC. See section 6 for details on revocation.
-
-   If the crlDistributionPoints extension is present, then exactly one
-   distribution point MUST be present. The crlDistributionPoints
-   extension MUST use the DistributionPointName option, which MUST
-   contain a fullName, which MUST contain a single name form. That name
-   MUST contain either a distinguished name or a URI. The URI MUST be
-   either an HTTP URL or an LDAP URL [URL].
-
-      name           id-ce-cRLDistributionPoints
-      OID            { id-ce 31 }
-      syntax         CRLDistPointsSyntax
-      criticality    MUST be FALSE
-
-4.3.6   No Revocation Available
-
-   The noRevAvail extension, defined in [X.509-2000], allows an AC
-   issuer to indicate that no revocation information will be made
-   available for this AC.
-
-   This extension MUST be non-critical. An AC verifier that does not
-   understand this extension might be able to find a revocation list
-   from the AC issuer, but the revocation list will never include an
-   entry for the AC.
-
-      name           id-ce-noRevAvail
-      OID            { id-ce 56 }
-      syntax         NULL (i.e. '0500'H is the DER encoding)
-      criticality    MUST be FALSE
-
-4.4 Attribute Types
-
-   Some of the attribute types defined below make use of the
-   IetfAttrSyntax type, also defined below. The reasons for using this
-   type are:
-
-   1.   It allows a separation between the AC issuer and the attribute
-        policy authority. This is useful for situations where a single
-        policy authority (e.g. an organization) allocates attribute
-        values, but where multiple AC issuers are deployed for
-        performance or other reasons.
-   2.   The syntaxes allowed for values are restricted to OCTET STRING,
-        OBJECT IDENTIFIER, and UTF8String, which significantly reduces
-        the complexity associated with matching more general syntaxes.
-        All multi-valued attributes using this syntax are restricted so
-        that each value MUST use the same choice of value syntax. For
-        example, AC issuers must not use one value with an oid and a
-        second value with a string.
-
-
-Farrell & Housley                                            [Page 17]
-
-INTERNET-DRAFT                                             August 2000
-
-
-           IetfAttrSyntax ::= SEQUENCE {
-                policyAuthority [0] GeneralNames    OPTIONAL,
-                values          SEQUENCE OF CHOICE {
-                              octets    OCTET STRING,
-                              oid       OBJECT IDENTIFIER,
-                              string    UTF8String
-               }
-           }
-
-   In the descriptions below, each attribute type is tagged as either
-   "Multiple Allowed" or "One Attribute value only; multiple values
-   within the IetfAttrSyntax". This refers to the SET OF
-   AttributeValue, the AttributeType still only occurs once, as
-   specified in section 4.2.7.
-
-4.4.1   Service Authentication Information
-
-   The SvceAuthInfo attribute identifies the AC holder to the
-   server/service by a name, and the attribute MAY include optional
-   service specific authentication information. Typically this will
-   contain a username/password pair for a "legacy" application.
-
-   This attribute provides information that can be presented by the AC
-   verifier to be interpreted and authenticated by a separate
-   application within the target system. Note that this is a different
-   use to that intended for the accessIdentity attribute in 4.4.2
-   below.
-
-   This attribute type will typically be encrypted when the authInfo
-   field contains sensitive information, such as a password.
-
-      name      id-aca-authenticationInfo
-      OID       { id-aca 1 }
-      Syntax    SvceAuthInfo
-      values:   Multiple allowed
-
-           SvceAuthInfo ::=    SEQUENCE {
-                service   GeneralName,
-                ident     GeneralName,
-                authInfo  OCTET STRING OPTIONAL
-           }
-
-4.4.2   Access Identity
-
-   The accessIdentity attribute identifies the AC holder to the
-   server/service. For this attribute the authInfo field MUST NOT be
-   present.
-
-   This attribute is intended to be used to provide information about
-   the AC holder, that can be used by the AC verifier (or a larger
-   system of which the AC verifier is a component) to authorize the
-   actions of the AC holder within the AC verifier's system. Note that
-
-
-Farrell & Housley                                            [Page 18]
-
-INTERNET-DRAFT                                             August 2000
-
-
-   this is a different use to that intended for the svceAuthInfo
-   attribute described in 4.4.1 above.
-
-      name      id-aca-accessIdentity
-      OID       { id-aca 2 }
-      syntax    SvceAuthInfo
-      values:   Multiple allowed
-
-4.4.3   Charging Identity
-
-   The chargingIdentity attribute identifies the AC holder for charging
-   purposes. In general, the charging identity will be different from
-   other identities of the holder. For example, the holder's company
-   may be charged for service.
-
-      name      id-aca-chargingIdentity
-      OID       { id-aca 3 }
-      syntax    IetfAttrSyntax
-      values:   One Attribute value only; multiple values within the
-                IetfAttrSyntax
-
-4.4.4   Group
-
-   The group attribute carries information about group memberships of
-   the AC holder.
-
-      name      id-aca-group
-      OID       { id-aca 4 }
-      syntax    IetfAttrSyntax
-      values:   One Attribute value only; multiple values within the
-                IetfAttrSyntax
-
-4.4.5   Role
-
-   The role attribute, specified in [X.509-2000], carries information
-   about role allocations of the AC holder.
-
-   The syntax used for this attribute is:
-
-        RoleSyntax ::= SEQUENCE {
-                roleAuthority   [0] GeneralNames OPTIONAL,
-                roleName        [1] GeneralName
-        }
-
-   The roleAuthority field MAY be used to specify the issuing authority
-   for the role specification certificate. There is no requirement that
-   a role specification certificate necessarily exists for the
-   roleAuthority. This differs from [X.500-2000], where the
-   roleAuthority field is assumed to name the issuer of a role
-   specification certificate. For example, to distinguish the
-   administrator role as defined by "Baltimore" from that defined by
-   "SPYRUS", one could put the value "administrator" in the roleName
-
-
-Farrell & Housley                                            [Page 19]
-
-INTERNET-DRAFT                                             August 2000
-
-
-   field and the value "Baltimore" or "SPYRUS" in the roleAuthority
-   field.
-
-   The roleName field MUST be present, and roleName MUST use the
-   uniformResourceIdentifier CHOICE of the GeneralName.
-
-      name      id-at-role
-      OID       { id-at 72 }
-      syntax    RoleSyntax
-      values:   Multiple allowed
-
-4.4.6   Clearance
-
-   The clearance attribute, specified in [X.501-1993], carries
-   clearance (associated with security labeling) information about the
-   AC holder.
-
-   The policyId field is used to identify the security policy to which
-   the clearance relates. The policyId indicates the semantics of the
-   classList and securityCategories fields.
-
-   This specification includes the classList field exactly as is
-   specified in [X.501-1993]. Additional security classification
-   values, and their position in the classification hierarchy, may be
-   defined by a security policy as a local matter or by bilateral
-   agreement. The basic security classification hierarchy is, in
-   ascending order: unmarked, unclassified, restricted, confidential,
-   secret, and top-secret.
-
-   An organization can develop its own security policy that defines
-   security classification values and their meanings. However, the BIT
-   STRING positions 0 through 5 are reserved for the basic security
-   classification hierarchy.
-
-   If present, the SecurityCategory field provides further
-   authorization information. The security policy identified by the
-   policyId field indicates the syntaxes that are allowed to be present
-   in the securityCategories SET. An OBJECT IDENTIFIER identifies each
-   of the allowed syntaxes. When one of these syntaxes is present in
-   the securityCategories SET, the OBJECT IDENTIFIER associated with
-   that syntax is carried in the SecurityCategory.type field.
-
-           Clearance  ::=  SEQUENCE {
-                policyId  OBJECT IDENTIFIER,
-                classList ClassList DEFAULT {unclassified},
-                securityCategories
-                          SET OF SecurityCategory OPTIONAL
-           }
-
-           ClassList  ::=  BIT STRING {
-                unmarked       (0),
-                unclassified   (1),
-                restricted     (2)
-
-Farrell & Housley                                            [Page 20]
-
-INTERNET-DRAFT                                             August 2000
-
-
-                confidential   (3),
-                secret         (4),
-                topSecret      (5)
-           }
-
-           SecurityCategory ::= SEQUENCE {
-                type      [0]  IMPLICIT OBJECT IDENTIFIER,
-                value     [1]  ANY DEFINED BY type
-           }
-
-           -- This is the same as the original syntax which was defined
-           -- using the MACRO construct, as follows:
-           -- SecurityCategory ::= SEQUENCE {
-           --      type      [0]  IMPLICIT SECURITY-CATEGORY,
-           --      value     [1]  ANY DEFINED BY type
-           -- }
-           --
-           -- SECURITY-CATEGORY MACRO  ::=
-           -- BEGIN
-           -- TYPE NOTATION ::= type | empty
-           -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
-           -- END
-
-
-
-      name      { id-at-clearance }
-      OID       { joint-iso-ccitt(2) ds(5) module(1)
-                  selected-attribute-types(5) clearance (55) }
-      syntax    Clearance - imported from [X.501-1993]
-      values    Multiple allowed
-
-4.5 Profile of AC issuer's PKC
-
-   The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage
-   extension in the PKC MUST NOT explicitly indicate that the AC
-   issuer's public key cannot be used to validate a digital signature.
-   In order to avoid confusion regarding serial numbers and
-   revocations, an AC issuer MUST NOT also be a PKC Issuer.  That is,
-   an AC issuer cannot be a CA as well. So, the AC issuer's PKC MUST
-   NOT have a basicConstraints extension with the cA BOOLEAN set to
-   TRUE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell & Housley                                            [Page 21]
-
-INTERNET-DRAFT                                             August 2000
-
-
-5. Attribute Certificate Validation
-
-   This section describes a basic set of rules that all valid ACs MUST
-   satisfy. Some additional checks are also described which AC
-   verifiers MAY choose to implement.
-
-   To be valid an AC MUST satisfy all of the following:
-
-   1.   The AC signature must be cryptographically correct, and the AC
-        issuer's entire PKC certification path MUST be verified in
-        accordance with [PKIXPROF].
-   2.   The AC issuer's PKC MUST also conform to the profile specified
-        in section 4.5 above.
-   3.   The AC issuer MUST be directly trusted as an AC issuer (by
-        configuration or otherwise).
-   4.   The time for which the AC is being evaluated MUST be within the
-        AC validity. If the evaluation time is equal to either
-        notBeforeTime or notAfterTime, then the AC is timely and this
-        check succeeds. Note that in some applications, the evaluation
-        time MAY not be the same as the current time.
-   5.   The AC targeting check MUST pass as specified in section 4.3.2.
-   6.   If the AC contains an unsupported critical extension, then the
-        AC MUST be rejected.
-
-   Support for an extension in this context means:
-
-   1.   The AC verifier MUST be able to parse the extension value.
-   2.   Where the extension value SHOULD cause the AC to be rejected,
-        the AC verifier MUST reject the AC.
-
-   Additional Checks:
-
-   1.   The AC MAY be rejected on the basis of further AC verifier
-        configuration. For example, an AC verifier may be configured to
-        reject ACs which contain or lack certain attributes.
-   2.   If the AC verifier provides an interface that allows
-        applications to query the contents of the AC, then the AC
-        verifier MAY filter the attributes from the AC on the basis of
-        configured information.  For example, an AC verifier might be
-        configured not to return certain attributes to certain servers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell & Housley                                            [Page 22]
-
-INTERNET-DRAFT                                             August 2000
-
-
-6. Revocation
-
-   In many environments, the validity period of an AC is less than the
-   time required to issue and distribute revocation information.
-   Therefore, short-lived ACs typically do not require revocation
-   support. However, long-lived ACs and environments where ACs enable
-   high value transactions MAY require revocation support.
-
-   Two revocation schemes are defined, and the AC issuer should elect
-   the one that is best suited to the environment in which the AC will
-   be employed.
-
-   "Never revoke" scheme:
-
-        ACs may be marked so that the relying party understands that no
-        revocation status information will be made available. The
-        noRevAvail extension is defined in section 4.3.6, and the
-        noRevAvail extension MUST be present in the AC to indicate use
-        of this scheme.
-
-        Where no noRevAvail is not present, then the AC issuer is
-        implicitly stating that revocation status checks are supported,
-        and some revocation method MUST be provided to allow AC
-        verifiers to establish the revocation status of the AC.
-
-   "Pointer in AC" scheme:
-
-        ACs may "point" to sources of revocation status information,
-        using either an authorityInfoAccess extension or a
-        crlDistributionPoints extension within the AC.
-
-   For AC users, the "never revoke" scheme MUST be supported, and the
-   "pointer in AC" scheme SHOULD be supported. If only the "never
-   revoke" scheme is supported, then all ACs that do not contain a
-   noRevAvail extension, MUST be rejected.
-
-   For AC issuers, the "never revoke" scheme MUST be supported. If all
-   ACs that will ever be issued by that AC issuer, will contain a
-   noRevAvail extension, then the "pointer in AC" scheme need not be
-   supported. If any AC can be issued that does not contain the
-   noRevAvail extension, then the "pointer in AC" scheme MUST be
-   supported.
-
-
-   An AC verifier MAY use any source for AC revocation status
-   information.
-
-
-
-
-
-
-
-
-Farrell & Housley                                            [Page 23]
-
-INTERNET-DRAFT                                             August 2000
-
-
-7. Optional Features
-
-   This section specifies features that MAY be implemented. Conformance
-   to this profile does NOT require support for these features;
-   however, if these features are offered, they MUST be offered as
-   described below.
-
-7.1 Attribute Encryption
-
-   Where an AC will be carried in clear within an application protocol
-   or where an AC contains some sensitive information like a legacy
-   application username/password, then encryption of AC attributes MAY
-   be needed.
-
-   When a set of attributes are to be encrypted within an AC, the
-   Cryptographic Message Syntax, EnvelopedData structure [CMS] is used
-   to carry the ciphertext and associated per-recipient keying
-   information.
-
-   This type of attribute encryption is targeted. Before the AC is
-   signed, the attributes are encrypted for a set of predetermined
-   recipients.
-
-   The AC then contains the ciphertext inside its signed data. The
-   EenvelopedData (id-envelopedData) ContentType is used, and the
-   content field will contain the EnvelopedData type.
-
-   The ciphertext is included in the AC as the value of an encAttrs
-   attribute. Only one encAttrs attribute can be present in an AC;
-   however, the encAttrs attribute MAY be multi-valued, and each of its
-   values will contain an independent EnvelopedData.
-
-   Each value can contain a set of attributes (each possibly a multi-
-   valued attribute) encrypted for a set of predetermined recipients.
-
-   The cleartext that is encrypted has the type:
-
-      ACClearAttrs ::= SEQUENCE {
-           acIssuer  GeneralName,
-           acSerial  INTEGER,
-           attrs     SEQUENCE OF Attribute
-      }
-
-   The DER encoding of the ACClearAttrs structure is used as the
-   encryptedContent field of the EnvelopedData. The DER encoding MUST
-   be embedded in an OCTET STRING.
-
-   The acIssuer and acSerial fields are present to prevent ciphertext
-   stealing. When an AC verifier has successfully decrypted an
-   encrypted attribute it MUST then check that the AC issuer and
-   serialNumber fields contain the same values. This prevents a
-   malicious AC issuer from copying ciphertext from another AC (without
-   knowing its corresponding plaintext).
-
-Farrell & Housley                                            [Page 24]
-
-INTERNET-DRAFT                                             August 2000
-
-
-
-   The procedure for an AC issuer when encrypting attributes is
-   illustrated by the following (any other procedure that gives the
-   same result MAY be used):
-
-
-      1.   Identify the sets of attributes that are to be encrypted for
-           each set of recipients.
-      2.   For each attribute set which is to be encrypted:
-         2.1. Create an EnvelopedData structure for the data for this
-              set of recipients.
-         2.2. Encode the ContentInfo containing the EnvelopedData as a
-              value of the encAttrs attribute
-         2.3. Ensure the cleartext attributes are not present in the
-              to-be-signed AC
-      3.   Add the encAttrs (with its multiple values) to the AC
-
-   Note that there may be more than one attribute of the same type (the
-   same OBJECT IDENTIFIER) after decryption. That is, an AC MAY contain
-   the same attribute type both in clear and in encrypted form (and
-   indeed several times if the same recipient is associated with more
-   than one EnvelopedData). One approach implementers may choose, would
-   be to merge attributes values following decryption in order to re-
-   establish the "once only" constraint.
-
-      name      id-aca-encAttrs
-      OID       { id-aca 6}
-      Syntax    ContentInfo
-      values    Multiple Allowed
-
-   If an AC contains attributes apparently encrypted for the AC
-   verifier, then the decryption process MUST not fail. If decryption
-   does fail, then the AC MUST be rejected.
-
-7.2 Proxying
-
-   When a server acts as a client for another server on behalf of the
-   AC holder, the server MAY need to proxy an AC. Such proxying MAY
-   have to be done under the AC issuer's control, so that not every AC
-   is proxiable and so that a given proxiable AC can be proxied in a
-   targeted fashion. Support for chains of proxies (with more than one
-   intermediate server) MAY also be required. Note that this does not
-   involve a chain of ACs.
-
-   In order to meet this requirement we define another extension,
-   ProxyInfo, similar to the targeting extension.
-
-   When this extension is present, the AC verifier must check that the
-   entity from which the AC was received was allowed to send it and
-   that the AC is allowed to be used by this verifier.
-
-   The proxying information consists of a set of proxy information,
-   each of which is a set of targeting information. If the verifier and
-
-Farrell & Housley                                            [Page 25]
-
-INTERNET-DRAFT                                             August 2000
-
-
-   the sender of the AC are both named in the same proxy set then the
-   AC can be accepted (the exact rule is given below).
-
-   The effect is that the AC holder can send the AC to any valid target
-   which can then only proxy to targets which are in one of the same
-   proxy sets as itself.
-
-   The following data structure is used to represent the
-   targeting/proxying information.
-
-          ProxyInfo ::= SEQUENCE OF Targets
-
-   As in the case of targeting, the targetCert CHOICE MUST NOT be used.
-
-   A proxy check succeeds if either one of the conditions below is met:
-
-   1. The identity of the sender as established by the underlying
-      authentication service matches the holder field of the AC, and the
-      current server "matches" any one of the proxy sets.  Recall that
-      "matches" is as defined section 4.3.2.
-
-   2. The identity of the sender as established by the underlying
-      authentication service "matches" one of the proxy sets (call it
-      set "A"), and the current server is one of the targetName fields
-      in the set "A", or the current server is a member of one of the
-      targetGroup fields in set "A".
-
-   When an AC is proxied more than once, a number of targets will be on
-   the path from the original client, which is normally, but not
-   always, the AC holder. In such cases, prevention of AC "stealing"
-   requires that the AC verifier MUST check that all targets on the
-   path are members of the same proxy set. It is the responsibility of
-   the AC using protocol to ensure that a trustworthy list of targets
-   on the path is available to the AC verifier.
-
-      name           id-pe-ac-proxying
-      OID            { id-pe 10 }
-      syntax         ProxyInfo
-      criticality    MUST be TRUE
-
-7.3 Use of ObjectDigestInfo
-
-   In some environments, it may be required that the AC is not linked
-   either to an identity (via entityName) or to a PKC (via
-   baseCertificateID). The objectDigestInfo CHOICE in the holder field
-   allows support for this requirement.
-
-   If the holder is identified with the objectDigestInfo field, then
-   the AC version field MUST contain v2 (the integer 1).
-
-   The idea is to link the AC to an object by placing a hash of that
-   object into the holder field of the AC. For example, this allows
-   production of ACs that are linked to public keys rather than names.
-
-Farrell & Housley                                            [Page 26]
-
-INTERNET-DRAFT                                             August 2000
-
-
-   It also allows production of ACs which contain privileges associated
-   with an executable object such as a Java class. However, this
-   profile only specifies how to use a hash over a public key or PKC.
-   That is, conformant ACs MUST NOT use the otherObjectTypes value for
-   the digestedObjectType.
-
-   To link an AC to a public key, the hash must be calculated over the
-   representation of that public key which would be present in a PKC,
-   specifically, the input for the hash algorithm MUST be the DER
-   encoding of a SubjectPublicKeyInfo representation of the key. Note:
-   This includes the AlgorithmIdentifier as well as the BIT STRING. The
-   rules given in [PKIXPROF] for encoding keys MUST be followed. In
-   this case the digestedObjectType MUST be publicKey and the
-   otherObjectTypeID field MUST NOT be present.
-
-   Note that if the public key value used as input to the hash function
-   has been extracted from a PKC, then it is possible that the
-   SubjectPublicKeyInfo from that PKC is NOT the value which should be
-   hashed. This can occur if DSA Dss-parms are inherited as described
-   in section 7.3.3 of [PKIXPROF]. The correct input for hashing in
-   this context will include the value of the parameters inherited from
-   the CA's PKC, and thus may differ from the SubjectPublicKeyInfo
-   present in the PKC.
-
-   Implementations which support this feature MUST be able to handle
-   the representations of public keys for the algorithms specified in
-   section 7.3 of [PKIXPROF]. In this case the digestedObjectType MUST
-   be publicKey and the otherObjectTypeID field MUST NOT be present.
-
-   In order to link an AC to a PKC via a digest, the digest MUST be
-   calculated over the DER encoding of the entire PKC, including the
-   signature value. In this case the digestedObjectType MUST be
-   publicKeyCert and the otherObjectTypeID field MUST NOT be present.
-
-7.4 AA Controls
-
-   During AC validation a relying party has to answer the question: is
-   this AC issuer trusted to issue ACs containing this attribute? The
-   AAControls PKC extension MAY be used to help answer the question.
-   The AAControls extension is intended to be used in CA and AC issuer
-   PKCs.
-
-         id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }
-
-         AAControls ::= SEQUENCE {
-            pathLenConstraint   INTEGER (0..MAX) OPTIONAL,
-            permittedAttrs      [0] AttrSpec OPTIONAL,
-            excludedAttrs       [1] AttrSpec OPTIONAL,
-            permitUnSpecified   BOOLEAN DEFAULT TRUE
-         }
-
-         AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
-
-
-Farrell & Housley                                            [Page 27]
-
-INTERNET-DRAFT                                             August 2000
-
-
-   The AAControls extension is used as follows:
-
-   The pathLenConstraint, if present, is interpreted as in [PKIXPROF].
-   It restricts the allowed distance between the AA CA, (a CA directly
-   trusted to include AAControls in its PKCs), and the AC issuer.
-
-   The permittedAttrs field specifies a set of attribute types that any
-   AC issuer below this AA CA is allowed to include in ACs. If this
-   field is not present, it means that no attribute types are
-   explicitly allowed.
-
-   The excludedAttrs field specifies a set of attribute types that no
-   AC issuer is allowed to include in ACs. If this field is not
-   present, it means that no attribute types are explicitly disallowed.
-
-   The permitUnSpecified field specifies how to handle attribute types
-   which are not present in either the permittedAttrs or excludedAttrs
-   fields. TRUE (the default) means that any unspecified attribute type
-   is allowed in ACs; FALSE means that no unspecified attribute type is
-   allowed.
-
-   When AAControls are used, the following additional checks on an AA's
-   PKC chain MUST all succeed for the AC to be valid:
-
-   1.   Some CA on the ACs certificate path MUST be directly trusted to
-        issue PKCs which precede the AC issuer in the certification
-        path, call this CA the "AA CA".
-   2.   All PKCs on the path from the AA CA down to and including the
-        AC issuer's PKC MUST contain an AAControls extension; however,
-        the AA CA's PKC need not contain this extension.
-   3.   Only those attributes in the AC which are allowed according to
-        all of the AAControls extension values in all of the PKCs from
-        the AA CA to the AC issuer, may be used for authorization
-        decisions, all other attributes MUST be ignored. This check
-        MUST be applied to the set of attributes following attribute
-        decryption, and the id-aca-encAttrs type MUST also be checked.
-
-      name           id-pe-aaControls
-      OID            { id-pe 6 }
-      syntax         AAControls
-      criticality    MAY be TRUE
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell & Housley                                            [Page 28]
-
-INTERNET-DRAFT                                             August 2000
-
-
-8. Security Considerations
-
-   The protection afforded for private keys is a critical factor in
-   maintaining security.  Failure of AC issuers to protect their
-   private keys will permit an attacker to masquerade as them,
-   potentially generating false ACs or revocation status.  Existence of
-   bogus ACs and revocation status will undermine confidence in the
-   system. If the compromise is detected, all ACs issued by the AC
-   issuer MUST be revoked. Rebuilding after such a compromise will be
-   problematic, so AC issuers are advised to implement a combination of
-   strong technical measures (e.g., tamper-resistant cryptographic
-   modules) and appropriate management procedures (e.g., separation of
-   duties) to avoid such an incident.
-
-   Loss of an AC issuer's private signing key may also be problematic.
-   The AC issuer would not be able to produce revocation status or
-   perform AC renewal. AC issuers are advised to maintain secure backup
-   for signing keys.  The security of the key backup procedures is a
-   critical factor in avoiding key compromise.
-
-   The availability and freshness of revocation status will affect the
-   degree of assurance that should be placed in a long-lived AC. While
-   long-lived ACs expire naturally, events may occur during its natural
-   lifetime which negate the binding between the AC holder and the
-   attributes.  If revocation status is untimely or unavailable, the
-   assurance associated with the binding is clearly reduced.
-
-   The binding between an AC holder and attributes cannot be stronger
-   than the cryptographic module implementation and algorithms used to
-   generate the signature.  Short key lengths or weak hash algorithms
-   will limit the utility of an AC.  AC issuers are encouraged to note
-   advances in cryptology so they can employ strong cryptographic
-   techniques.
-
-   Inconsistent application of name comparison rules may result in
-   acceptance of invalid targeted or proxied ACs, or rejection of valid
-   ones.  The X.500 series of specifications defines rules for
-   comparing distinguished names.  These rules require comparison of
-   strings without regard to case, character set, multi-character white
-   space substrings, or leading and trailing white space.  This
-   specification and [PKIXPROF] relaxes these requirements, requiring
-   support for binary comparison at a minimum.
-
-   AC issuers MUST encode the distinguished name in the AC
-   holder.entityName field identically to the distinguished name in the
-   holder's PKC.  If different encodings are used, implementations of
-   this specification may fail to recognize that the AC and PKC belong
-   to the same entity.
-
-   Implementers MUST ensure that following validation of an AC, only
-   attributes that the issuer is trusted to issue are used in
-   authorization decisions. Other attributes, which MAY be present MUST
-   be ignored. Given that the AA controls PKC extension is optional to
-
-Farrell & Housley                                            [Page 29]
-
-INTERNET-DRAFT                                             August 2000
-
-
-   implement, AC verifiers MUST be provided with this information by
-   other means. Configuration information is a likely alternative
-   means. This becomes very important if an AC verifier trusts more
-   than one AC issuer.
-
-   There is often a requirement to map between the authentication
-   supplied by a particular security protocol (e.g. TLS, S/MIME) and
-   the AC holder's identity. If the authentication uses PKCs, then this
-   mapping is straightforward. However, it is envisaged that ACs will
-   also be used in environments where the holder may be authenticated
-   using other means. Implementers SHOULD be very careful in mapping
-   the authenticated identity to the AC holder.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell & Housley                                            [Page 30]
-
-INTERNET-DRAFT                                             August 2000
-
-
-9. References
-
-  [CMC]       Myers, M., et al. "Certificate Management Messages over
-              CMS", RFC2797.
-  [CMP]       Adams, C., Farrell, S., "Internet X.509 Public Key
-              Infrastructure - Certificate Management Protocols",
-              RFC2510.
-  [CMS]       Housley, R., "Cryptographic Message Syntax", RFC 2630.
-  [ESS]       Hoffman, P., "Enhanced Security Services for S/MIME",
-              RFC2634.
-  [KRB]       Kohl, J., Neuman, C., "The Kerberos Network
-              Authentication Service (V5)", RFC 1510.
-  [LDAP]      Wahl, M., et al., "Lightweight Directory Access Protocol
-              (v3)", RFC 2251.
-  [OCSP]      Myers, M., et al., " X.509 Internet Public Key
-              Infrastructure - Online Certificate Status Protocol -
-              OCSP", RFC 2560.
-  [PKIXALGS]  Polk, T., Bassham, L., "Internet X.509 Public Key
-              Infrastructure Representation of Public Keys and Digital
-              Signatures in Internet X.509 Public Key Infrastructure
-              Certificates", draft-ietf-pkix-pkalgs-00.txt, work-in-
-              progress.
-  [PKINIT]    Tung, B., et al., "Public Key Cryptography for Initial
-              Authentication in Kerberos", draft-ietf-cat-kerberos-pk-
-              init-11.txt, work-in-progress.
-  [PKIXPROF]  Housley, R., Ford, W., Polk, T, & Solo, D., "Internet
-              Public Key Infrastructure - X.509 Certificate and CRL
-              Profile", draft-ietf-pkix-new-part1-02.txt, work-in-
-              progress.
-  [RFC2026]   Bradner, S., "The Internet Standards Process -- Revision
-              3", RFC 2026, BCP 9, October 1996.
-  [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119.
-  [URL]       Berners-Lee, T., Masinter L., and M. McCahill., "Uniform
-              Resource Locators (URL)", RFC 1738.
-  [X.208-1988]CCITT Recommendation X.208: Specification of Abstract
-              Syntax Notation One (ASN.1). 1988.
-  [X.209-88]  CCITT Recommendation X.209: Specification of Basic
-              Encoding Rules for Abstract Syntax Notation One (ASN.1).
-              1988.
-  [X.501-88]  CCITT Recommendation X.501: The Directory - Models.
-              1988.
-  [X.501-1993]ITU-T Recommendation X.501 : Information Technology -
-              Open Systems Interconnection - The Directory: Models,
-              1993.
-  [X.509-1988]CCITT Recommendation X.509: The Directory -
-              Authentication Framework.  1988.
-  [X.509-1997]ITU-T Recommendation X.509: The Directory -
-              Authentication Framework.  1997.
-  [X.509-2000]ITU-T Recommendation X.509: The Directory - Public-Key
-              and Attribute Certificate Frameworks.  2000
-
-
-
-Farrell & Housley                                            [Page 31]
-
-INTERNET-DRAFT                                             August 2000
-
-
-Author's Addresses
-
-   Stephen Farrell
-   Baltimore Technologies
-   61/62 Fitzwilliam Lane
-   Dublin 2
-   IRELAND
-
-   tel: +353-1-647-3000
-   email: stephen.farrell@baltimore.ie
-
-   Russell Housley
-   SPYRUS
-   381 Elden Street
-   Suite 1120
-   Herndon, VA 20170
-   USA
-
-   tel: +1-703-707-0696
-   email: housley@spyrus.com
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (date).  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.  In addition,
-   the ASN.1 module presented in Appendix B may be used in whole or in
-   part without inclusion of the copyright notice.  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 shall 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.
-
-
-
-
-
-Farrell & Housley                                            [Page 32]
-
-INTERNET-DRAFT                                             August 2000
-
-
-Appendix A: Object Identifiers
-
-   This (normative) appendix lists the new object identifiers which are
-   defined in this specification. Some of these are required only for
-   support of optional features and are not required for conformance to
-   this profile. This specification mandates support for OIDs which
-   have arc elements with values that are less than 2^32, (i.e. they
-   MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less
-   than 2^31 (i.e. less than or equal to 2,147,483,647). This allows
-   each arc element to be represented within a single 32 bit word.
-   Implementations MUST also support OIDs where the length of the
-   dotted decimal (see [LDAP], section 4.1.2) string representation can
-   be up to 100 bytes (inclusive). Implementations MUST be able to
-   handle OIDs with up to 20 elements (inclusive). AA's SHOULD NOT
-   issue ACs which contain OIDs that breach these requirements.
-
-   The following OIDs are imported from [PKIXPROF]:
-
-      id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
-                dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
-      id-mod  OBJECT IDENTIFIER ::= { id-pkix 0 }
-      id-pe   OBJECT IDENTIFIER ::= { id-pkix 1 }
-      id-ad   OBJECT IDENTIFIER ::= { id-pkix 48 }
-      id-at   OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
-      id-ce   OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 }
-
-   The following new ASN.1 module OID is defined:
-
-      id-mod-attribute-cert        OBJECT IDENTIFIER ::= { id-mod 12 }
-
-   The following AC extension OIDs are defined:
-
-      id-pe-ac-auditIdentity       OBJECT IDENTIFIER ::= { id-pe 4 }
-      id-pe-ac-proxying            OBJECT IDENTIFIER ::= { id-pe 10 }
-      id-ce-targetInformation      OBJECT IDENTIFIER ::= { id-ce 55 }
-
-   The following PKC extension OIDs are defined:
-
-      id-pe-aaControls             OBJECT IDENTIFIER ::= { id-pe 6 }
-
-   The following attribute OIDs are defined:
-
-      id-aca                       OBJECT IDENTIFIER ::= { id-pkix 10 }
-      id-aca-authenticationInfo    OBJECT IDENTIFIER ::= { id-aca 1 }
-      id-aca-accessIdentity        OBJECT IDENTIFIER ::= { id-aca 2 }
-      id-aca-chargingIdentity      OBJECT IDENTIFIER ::= { id-aca 3 }
-      id-aca-group                 OBJECT IDENTIFIER ::= { id-aca 4 }
-      id-aca-encAttrs              OBJECT IDENTIFIER ::= { id-aca 6 }
-      id-at-role                   OBJECT IDENTIFIER ::= { id-at 72 }
-      id-at-clearance              OBJECT IDENTIFIER ::=
-                  { joint-iso-ccitt(2) ds(5) module(1)
-                    selected-attribute-types(5) clearance (55) }
-
-
-Farrell & Housley                                            [Page 33]
-
-INTERNET-DRAFT                                             August 2000
-
-
-Appendix B: ASN.1 Module
-
-   PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
-                internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
-                id-mod-attribute-cert(12)}
-
-
-      DEFINITIONS EXPLICIT TAGS ::=
-
-      BEGIN
-
-      -- EXPORTS ALL --
-
-      IMPORTS
-
-            -- IMPORTed module OIDs MAY change if [PKIXPROF] changes
-            -- PKIX Certificate Extensions
-               Attribute, AlgorithmIdentifier, CertificateSerialNumber,
-               Extensions, UniqueIdentifier,
-               id-pkix, id-pe, id-kp, id-ad, id-at
-               FROM PKIX1Explicit88 {iso(1) identified-organization(3)
-                        dod(6) internet(1) security(5) mechanisms(5)
-                        pkix(7) id-mod(0) id-pkix1-explicit-88(1)}
-
-               GeneralName, GeneralNames, id-ce
-               FROM PKIX1Implicit88 {iso(1) identified-organization(3)
-                        dod(6) internet(1) security(5) mechanisms(5)
-                        pkix(7) id-mod(0) id-pkix1-implicit-88(2)} ;
-
-      id-pe-ac-auditIdentity       OBJECT IDENTIFIER ::= { id-pe 4 }
-      id-pe-aaControls             OBJECT IDENTIFIER ::= { id-pe 6 }
-      id-pe-ac-proxying            OBJECT IDENTIFIER ::= { id-pe 10 }
-      id-ce-targetInformation      OBJECT IDENTIFIER ::= { id-ce 55 }
-
-      id-aca                       OBJECT IDENTIFIER ::= { id-pkix 10 }
-
-      id-aca-authenticationInfo    OBJECT IDENTIFIER ::= { id-aca 1 }
-      id-aca-accessIdentity        OBJECT IDENTIFIER ::= { id-aca 2 }
-      id-aca-chargingIdentity      OBJECT IDENTIFIER ::= { id-aca 3 }
-      id-aca-group                 OBJECT IDENTIFIER ::= { id-aca 4 }
-      -- { id-aca 5 } is reserved
-      id-aca-encAttrs              OBJECT IDENTIFIER ::= { id-aca 6 }
-
-      id-at-role                   OBJECT IDENTIFIER ::= { id-at 72}
-      id-at-clearance              OBJECT IDENTIFIER ::=
-                  { joint-iso-ccitt(2) ds(5) module(1)
-                    selected-attribute-types(5) clearance (55) }
-
-             -- Uncomment this if using a 1988 level ASN.1 compiler
-             -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-
-              AttributeCertificate ::= SEQUENCE {
-                   acinfo               AttributeCertificateInfo,
-
-Farrell & Housley                                            [Page 34]
-
-INTERNET-DRAFT                                             August 2000
-
-
-                   signatureAlgorithm   AlgorithmIdentifier,
-                   signatureValue       BIT STRING
-              }
-
-              AttributeCertificateInfo ::= SEQUENCE {
-                version        AttCertVersion DEFAULT v1,
-                holder         Holder,
-                issuer         AttCertIssuer,
-                signature      AlgorithmIdentifier,
-                serialNumber   CertificateSerialNumber,
-                attrCertValidityPeriod   AttCertValidityPeriod,
-                attributes     SEQUENCE OF Attribute,
-                issuerUniqueID UniqueIdentifier OPTIONAL,
-                extensions     Extensions     OPTIONAL
-              }
-
-              AttCertVersion ::= INTEGER {v1(0), v2(1) }
-
-              Holder ::= SEQUENCE {
-                   baseCertificateID   [0] IssuerSerial OPTIONAL,
-                             -- the issuer and serial number of
-                             -- the holder's Public Key Certificate
-                   entityName          [1] GeneralNames OPTIONAL,
-                             -- the name of the claimant or role
-                   objectDigestInfo    [2] ObjectDigestInfo OPTIONAL
-                             -- if present, version must be v2
-              }
-
-              ObjectDigestInfo    ::= SEQUENCE {
-                   digestedObjectType  ENUMERATED {
-                        publicKey            (0),
-                        publicKeyCert        (1),
-                        otherObjectTypes     (2) },
-                                -- otherObjectTypes MUST NOT
-                                -- MUST NOT be used in this profile
-                   otherObjectTypeID   OBJECT IDENTIFIER  OPTIONAL,
-                   digestAlgorithm     AlgorithmIdentifier,
-                   objectDigest        BIT STRING
-              }
-
-              AttCertIssuer ::= CHOICE {
-                   v1Form   GeneralNames,  -- v1 or v2
-                   v2Form   [0] V2Form     -- v2 only
-              }
-
-              V2Form ::= SEQUENCE {
-                   issuerName            GeneralNames  OPTIONAL,
-                   baseCertificateID     [0] IssuerSerial  OPTIONAL,
-                   objectDigestInfo      [1] ObjectDigestInfo  OPTIONAL
-                      -- at least one of issuerName, baseCertificateID
-                      -- or objectDigestInfo must be present
-              }
-
-
-Farrell & Housley                                            [Page 35]
-
-INTERNET-DRAFT                                             August 2000
-
-
-              IssuerSerial  ::=  SEQUENCE {
-                   issuer         GeneralNames,
-                   serial         CertificateSerialNumber,
-                   issuerUID      UniqueIdentifier OPTIONAL
-              }
-
-              AttCertValidityPeriod  ::= SEQUENCE {
-                   notBeforeTime  GeneralizedTime,
-                   notAfterTime   GeneralizedTime
-              }
-
-             Targets ::= SEQUENCE OF Target
-
-             Target  ::= CHOICE {
-                   targetName     [0] GeneralName,
-                   targetGroup    [1] GeneralName,
-                   targetCert     [2] TargetCert
-          }
-
-             TargetCert  ::= SEQUENCE {
-                   targetCertificate  IssuerSerial,
-                   targetName         GeneralName OPTIONAL,
-                   certDigestInfo     ObjectDigestInfo OPTIONAL
-           }
-
-             IetfAttrSyntax ::= SEQUENCE {
-                  policyAuthority[0] GeneralNames    OPTIONAL,
-                  values         SEQUENCE OF CHOICE {
-                                 octets    OCTET STRING,
-                                 oid       OBJECT IDENTIFIER,
-                                 string    UTF8String
-                 }
-             }
-
-              SvceAuthInfo ::=    SEQUENCE {
-                   service       GeneralName,
-                   ident         GeneralName,
-                   authInfo      OCTET STRING OPTIONAL
-              }
-
-              RoleSyntax ::= SEQUENCE {
-                   roleAuthority  [0] GeneralNames OPTIONAL,
-                   roleName       [1] GeneralName
-             }
-
-              Clearance  ::=  SEQUENCE {
-                   policyId       OBJECT IDENTIFIER,
-                   classList      ClassList DEFAULT {unclassified},
-                   securityCategories
-                             SET OF SecurityCategory  OPTIONAL
-              }
-
-              ClassList  ::=  BIT STRING {
-
-Farrell & Housley                                            [Page 36]
-
-INTERNET-DRAFT                                             August 2000
-
-
-                   unmarked       (0),
-                   unclassified   (1),
-                   restricted     (2),
-                   confidential   (3),
-                   secret         (4),
-                   topSecret      (5)
-              }
-
-              SecurityCategory ::= SEQUENCE {
-                   type      [0]  IMPLICIT OBJECT IDENTIFIER,
-                   value     [1]  ANY DEFINED BY type
-              }
-
-              AAControls ::= SEQUENCE {
-                   pathLenConstraint INTEGER (0..MAX) OPTIONAL,
-                   permittedAttrs    [0] AttrSpec OPTIONAL,
-                   excludedAttrs     [1] AttrSpec OPTIONAL,
-                   permitUnSpecified BOOLEAN DEFAULT TRUE
-              }
-
-              AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
-
-              ACClearAttrs ::= SEQUENCE {
-                   acIssuer          GeneralName,
-                   acSerial          INTEGER,
-                   attrs             SEQUENCE OF Attribute
-              }
-
-              ProxyInfo ::= SEQUENCE OF Targets
-
-      END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell & Housley                                            [Page 37]
-
\ No newline at end of file
diff --git a/doc/protocol/draft-ietf-tls-camellia-00.txt b/doc/protocol/draft-ietf-tls-camellia-00.txt
deleted file mode 100644
index 50b2137ba2..0000000000
--- a/doc/protocol/draft-ietf-tls-camellia-00.txt
+++ /dev/null
@@ -1,232 +0,0 @@
-INTERNET-DRAFT                                                 S. Moriai
-TLS Working Group             Nippon Telegraph and Telephone Corporation
-Expires April 2001                                          October 2000
-
-
-          Addition of the Camellia Encryption Algorithm to TLS
-
-                    <draft-ietf-tls-camellia-00.txt>
-
-Status of this Memo
-
-    This document is an Internet-Draft and is NOT offered in accordance
-    with Section 10 of RFC2026, and the author does not provide the IETF
-    with any rights other than to publish as an Internet-Draft.
-
-    Internet-Drafts are working documents of the Internet Engineering
-    Task Force (IETF), its areas, and its working groups.  Note that
-    other groups may also distribute working documents as Internet-
-    Drafts.
-
-    Internet-Drafts are draft documents valid for a maximum of six
-    months and may be updated, replaced, or obsoleted by other documents
-    at any time.  It is inappropriate to use Internet-Drafts as
-    reference material or to cite them other than as "work in progress."
-
-    The list of current Internet-Drafts can be accessed at
-    http://www.ietf.org/ietf/1id-abstracts.txt
-
-    The list of Internet-Draft Shadow Directories can be accessed at
-    http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-    This document proposes the addition of new cipher suites to the TLS
-    protocol 1.0 to support the Camellia encryption algorithm as a bulk
-    cipher algorithm.
-
-
-1. Introduction
-
-    The demands placed on cryptographic primitives are changing: the
-    required level of security is increasing to match the progress made
-    in computational power and cryptanalytic techniques, and more
-    efficiency on a wide variety of platforms is required as they are
-    being implemented in a wide variety of applications.  However, the
-    TLS Protocol Version 1.0 [4] currently does not support cipher
-    suites including 128-bit block ciphers that offer a high level of
-    security and performance.
-
-MORIAI                                                          [Page 1]
-
-INTERNET-DRAFT         Addition of Camellia to TLS          October 2000
-
-
-    Camellia is a block cipher with 128-bit block size and 128-, 192-,
-    and 256-bit key sizes, i.e. the same interface specifications as the
-    Advanced Encryption Standard (AES).  The algorithm description is in
-    [1] or [3].  Efficiency on both software and hardware platforms is a
-    remarkable characteristic of Camellia in addition to its high level
-    of security.  It is confirmed that Camellia provides strong security
-    against differential and linear cryptanalysis.  An optimized
-    implementation of Camellia in assembly language can encrypt on a
-    Pentium III (800MHz) at the rate of more than 276 Mbits per second,
-    which is much faster than the speed of an optimized DES
-    implementation.  In addition, a distinguishing feature is its small
-    hardware design.  The hardware design, which includes the parts for
-    key scheduling, encryption and decryption, occupies approximately
-    11K gates, which is the smallest among all existing 128-bit block
-    ciphers as far as we know [2].
-
-    This document proposes the addition of new cipher suites to the TLS
-    protocol 1.0 [4] to support Camellia as a bulk cipher algorithm.
-    The proposed change is minimal, just the addition of a new option
-    for bulk cipher algorithms.
-
-
-2. The CipherSuites
-
-    We propose the following new cipher suites.
-
-    CipherSuite TLS_RSA_WITH_CAMELLIA_CBC_128_SHA      = { 0x00,0x2F };
-    CipherSuite TLS_DH_DSS_WITH_CAMELLIA_CBC_128_SHA   = { 0x00,0x30 };
-    CipherSuite TLS_DH_RSA_WITH_CAMELLIA_CBC_128_SHA   = { 0x00,0x31 };
-    CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_CBC_128_SHA  = { 0x00,0x32 };
-    CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_CBC_128_SHA  = { 0x00,0x33 };
-    CipherSuite TLS_DH_anon_WITH_CAMELLIA_CBC_128_SHA  = { 0x00,0x34 };
-
-    CipherSuite TLS_RSA_WITH_CAMELLIA_CBC_192_SHA      = { 0x00,0x35 };
-    CipherSuite TLS_DH_DSS_WITH_CAMELLIA_CBC_192_SHA   = { 0x00,0x36 };
-    CipherSuite TLS_DH_RSA_WITH_CAMELLIA_CBC_192_SHA   = { 0x00,0x37 };
-    CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_CBC_192_SHA  = { 0x00,0x38 };
-    CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_CBC_192_SHA  = { 0x00,0x39 };
-    CipherSuite TLS_DH_anon_WITH_CAMELLIA_CBC_192_SHA  = { 0x00,0x3A };
-
-    CipherSuite TLS_RSA_WITH_CAMELLIA_CBC_256_SHA      = { 0x00,0x3B };
-    CipherSuite TLS_DH_DSS_WITH_CAMELLIA_CBC_256_SHA   = { 0x00,0x3C };
-    CipherSuite TLS_DH_RSA_WITH_CAMELLIA_CBC_256_SHA   = { 0x00,0x3D };
-    CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_CBC_256_SHA  = { 0x00,0x3E };
-    CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_CBC_256_SHA  = { 0x00,0x3F };
-    CipherSuite TLS_DH_anon_WITH_CAMELLIA_CBC_256_SHA  = { 0x00,0x40 };
-
-    Note: The above numeric definitions for CipherSuites have not yet
-    been registered.  The numeric definitions follow the numbers given
-    in the CipherSuite of TLS standard [4].
-
-
-3. CipherSuite Definitions
-
-MORIAI                                                          [Page 2]
-
-INTERNET-DRAFT         Addition of Camellia to TLS          October 2000
-
-
-CipherSuite                        Is       Key    Cipher           Hash
-                               Exportable Exchange
-             
-TLS_RSA_WITH_CAMELLIA_CBC_128_SHA         RSA      CAMELLIA_CBC_128 SHA
-TLS_DH_DSS_WITH_CAMELLIA_CBC_128_SHA      DH_DSS   CAMELLIA_CBC_128 SHA
-TLS_DH_RSA_WITH_CAMELLIA_CBC_128_SHA      DH_RSA   CAMELLIA_CBC_128 SHA
-TLS_DHE_DSS_WITH_CAMELLIA_CBC_128_SHA     DHE_DSS  CAMELLIA_CBC_128 SHA
-TLS_DHE_RSA_WITH_CAMELLIA_CBC_128_SHA     DHE_RSA  CAMELLIA_CBC_128 SHA
-TLS_DH_anon_WITH_CAMELLIA_CBC_128_SHA     DH_anon  CAMELLIA_CBC_128 SHA
-
-TLS_RSA_WITH_CAMELLIA_CBC_192_SHA         RSA      CAMELLIA_CBC_192 SHA
-TLS_DH_DSS_WITH_CAMELLIA_CBC_192_SHA      DH_DSS   CAMELLIA_CBC_192 SHA
-TLS_DH_RSA_WITH_CAMELLIA_CBC_192_SHA      DH_RSA   CAMELLIA_CBC_192 SHA
-TLS_DHE_DSS_WITH_CAMELLIA_CBC_192_SHA     DHE_DSS  CAMELLIA_CBC_192 SHA
-TLS_DHE_RSA_WITH_CAMELLIA_CBC_192_SHA     DHE_RSA  CAMELLIA_CBC_192 SHA
-TLS_DH_anon_WITH_CAMELLIA_CBC_192_SHA     DH_anon  CAMELLIA_CBC_192 SHA
-
-TLS_RSA_WITH_CAMELLIA_CBC_256_SHA         RSA      CAMELLIA_CBC_256 SHA
-TLS_DH_DSS_WITH_CAMELLIA_CBC_256_SHA      DH_DSS   CAMELLIA_CBC_256 SHA
-TLS_DH_RSA_WITH_CAMELLIA_CBC_256_SHA      DH_RSA   CAMELLIA_CBC_256 SHA
-TLS_DHE_DSS_WITH_CAMELLIA_CBC_256_SHA     DHE_DSS  CAMELLIA_CBC_256 SHA
-TLS_DHE_RSA_WITH_CAMELLIA_CBC_256_SHA     DHE_RSA  CAMELLIA_CBC_256 SHA
-TLS_DH_anon_WITH_CAMELLIA_CBC_256_SHA     DH_anon  CAMELLIA_CBC_256 SHA
-
-                             Key      Expanded   Effective   IV   Block
-    Cipher           Type  Material Key Material  Key Bits  Size  Size
-
-    CAMELLIA_CBC_128 Block   16         16         128       16    16
-    CAMELLIA_CBC_192 Block   24         24         192       16    16
-    CAMELLIA_CBC_256 Block   32         32         256       16    16
-
-   Note: Key Exchange Algorithms and Hash Functions are defined in TLS.
-
-
-4. Security Considerations
-
-    The security of Camellia was evaluated by utilizing state-of-the-art
-    cryptanalytic techniques.  We confirmed that Camellia has no
-    differential and linear characteristics that hold with probability
-    more than 2^(-128), which means that it is extremely unlikely that
-    differential and linear attacks will succeed against Camellia.
-    Moreover, Camellia was designed to offer security against other
-    advanced cryptanalytic attacks including higher order differential
-    attacks, interpolation attacks, related-key attacks, truncated
-    differential attacks, and so on [3].
-
-
-5. Intellectual Property Statement
-
-    Mitsubishi Electric Corporation (Mitsubishi Electric) and Nippon
-    Telegraph and Telephone Corporation (NTT) have filed patent
-    applications on the techniques used in the block cipher Camellia.
-    For more information, please contact MISTY@isl.melco.co.jp and/or
-
-MORIAI                                                          [Page 3]
-
-INTERNET-DRAFT         Addition of Camellia to TLS          October 2000
-
-    camellia@isl.ntt.co.jp.
-
-
-References
-
-    [1] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, 
-        J. Nakajima, and T. Tokita
-        ``Specification of Camellia --- a 128-bit Block Cipher'',
-        2000.  http://info.isl.ntt.co.jp/camellia/
-
-    [2] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, 
-        J. Nakajima, and T. Tokita
-        ``Camellia: A 128-Bit Block Cipher Suitable for Multiple 
-        Platforms'', 2000.  http://info.isl.ntt.co.jp/camellia/
-
-    [3] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai,
-        J. Nakajima, and T. Tokita
-        ``Camellia: A 128-Bit Block Cipher Suitable for Multiple 
-        Platforms --- Design and Analysis ---'', in Workshop Record 
-        of SAC 2000, Seventh Annual Workshop on Selected Areas in 
-        Cryptography, pp.41--54, 14-15 August 2000.  (to appear in 
-        Lecture Notes in Computer Science of Spring-Verlag)
-
-    [4] T. Dierks, and C. Allen, "The TLS Protocol Version 1.0", RFC
-        2246, January 1999.
-
-Author's Addresses
-
-    Shiho Moriai
-    Nippon Telegraph and Telephone Corporation 
-    1-1 Hikarinooka, Yokosuka, 239-0847, Japan
-    Phone: +81-468-59-2007
-    FAX:   +81-468-59-3858
-    Email: shiho@isl.ntt.co.jp
-
- 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-MORIAI                                                          [Page 4]
-
-
-
-
-                    
diff --git a/doc/protocol/draft-ietf-tls-extensions-00.txt b/doc/protocol/draft-ietf-tls-extensions-00.txt
new file mode 100644
index 0000000000..38cd755b51
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-extensions-00.txt
@@ -0,0 +1,1176 @@
+
+
+
+
+TLS Working Group                           Simon Blake-Wilson, Certicom
+INTERNET-DRAFT                              Magnus Nystrom, RSA Security
+June 20, 2001                      David Hopwood, Independent Consultant
+Expires December 20, 2001                 Jan Mikkelsen, Transactionware
+Intended Category: Standards track                  Tim Wright, Vodafone
+
+
+                             TLS Extensions
+
+                   <draft-ietf-tls-extensions-00.txt>
+
+                          Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026. Internet-Drafts are working
+   documents of the Internet Engineering Task Force (IETF), its areas,
+   and its working groups.  Note that other groups may also distribute
+   working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or made obsolete by other documents at
+   any time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as work in progress.
+
+   The list of current Internet-Drafts may be found at
+   http://www.ietf.org/ietf/1id-abstracts.txt
+
+   The list of Internet-Draft Shadow Directories may be found at
+   http://www.ietf.org/shadow.html.
+
+                                 Abstract
+
+   This document describes extensions that may be used to add
+   functionality to TLS. It provides both generic extension mechanisms
+   for the TLS handshake client and server hellos, and specific
+   extensions using these generic mechanisms.
+
+   The extensions may be used by TLS clients and servers. The extensions
+   are backwards compatible - communication is possible between TLS 1.0
+   clients that support the extensions and TLS 1.0 servers that do not
+   support the extensions, and vice versa.
+
+   This document is based on discussions within the TLS working group
+   and within the WAP security group.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [KEYWORDS].
+
+
+
+Blake-Wilson et al.      Expires: December 2001                 [Page 1]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+   Please send comments on this document to the TLS mailing list.
+
+                             Table of Contents
+
+    1. Introduction .............................................. 2
+    2. General Extension Mechanisms .............................. 4
+    2.1. Extended Client Hello ................................... 4
+    2.2. Extended Server Hello ................................... 5
+    2.3. Hello Extensions ........................................ 5
+    2.4. Extensions to the handshake protocol .................... 6
+    3. Specific Extensions ....................................... 7
+    3.1. DNS Name Indication ..................................... 7
+    3.2. Maximum Record Size Negotiation ......................... 8
+    3.3. Client Certificate URLs ................................. 9
+    3.4. Trusted CA Indication .................................. 11
+    3.5. Truncated HMAC ......................................... 12
+    3.6. OCSP Status Request..................................... 13
+    4. Error alerts ............................................. 14
+    5. Procedure for Defining New Extensions..................... 16
+    6. Security Considerations .................................. 17
+    6.1. Security of dns_name ................................... 17
+    6.2. Security of max_record_size ............................ 17
+    6.3. Security of client_certificate_url ..................... 18
+    6.4. Security of trusted_ca_keys ............................ 18
+    6.5. Security of truncated_hmac ............................. 19
+    6.6. Security of status_request ............................. 19
+    7. Internationalisation Considerations .......................19
+    8. Intellectual Property Rights ............................. 20
+    9. Acknowledgments .......................................... 20
+   10. References ............................................... 20
+   11. Authors' Addresses ....................................... 21
+
+1. Introduction
+
+   This document describes extensions that may be used to add
+   functionality to TLS. It provides both generic extension mechanisms
+   for the TLS handshake client and server hellos, and specific
+   extensions using these generic mechanisms.
+
+   TLS is now used in an increasing variety of operational environments
+   - many of which were not envisioned when the original design criteria
+   for TLS were determined. The extensions introduced in this document
+   are designed to enable TLS to operate as effectively as possible in
+   new environments like wireless networks.
+
+   Wireless environments often suffer from a number of constraints not
+   commonly present in wired environments - these constraints may
+   include bandwidth limitations, computational power limitations,
+
+
+
+Blake-Wilson et al.      Expires: December 2001                 [Page 2]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+   memory limitations, and battery life limitations.
+
+   The extensions described here focus on extending the functionality
+   provided by the TLS protocol message formats. Other issues, such as
+   the addition of new cipher suites, are deferred.
+
+   Specifically, the extensions described in this document are designed
+   to:
+
+   - Allow TLS clients to provide to the TLS server the DNS name of the
+     server they are contacting. This functionality is desirable to
+     facilitate secure connections to servers which host multiple
+     'virtual' servers at a single underlying network address.
+
+   - Allow TLS clients and servers to negotiate the maximum record size
+     to be sent. This functionality is desirable as a result of memory
+     constraints among some clients, and bandwidth constraints among
+     some access networks.
+
+   - Allow TLS clients and servers to negotiate the use of client
+     certificate URLs. This functionality is desirable in order to
+     conserve memory on constrained clients.
+
+   - Allow TLS clients to indicate to TLS servers which CA root keys
+     they possess. This functionality is desirable in order to prevent
+     multiple handshake failures involving TLS clients which are only
+     able to store a small number of CA root keys due to memory
+     limitations.
+
+   - Allow TLS clients and servers to negotiate the use of truncated
+     MACs. This functionality is desirable in order to conserve
+     bandwidth in constrained access networks.
+
+   - Allow TLS clients and servers to negotiate that the server sends
+     the client an OCSP [OCSP] response during a TLS handshake. This
+     functionality is desirable in order to avoid sending a CRL over a
+     constrained access network and therefore save bandwidth.
+
+   In order to support the extensions above, general extension
+   mechanisms for the client hello message and the server hello message
+   are introduced.
+
+   The extensions described in this document may be used by TLS 1.0
+   clients and TLS 1.0 servers. The extensions are designed to be
+   backwards compatible - meaning that TLS 1.0 clients that support the
+   extensions can talk to TLS 1.0 servers that do not support the
+   extensions, and vice versa.
+
+
+
+
+Blake-Wilson et al.      Expires: December 2001                 [Page 3]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+   Backwards compatibility is primarily achieved via two considerations:
+
+   - Clients typically request the use of extensions via the extended
+     client hello message described in Section 2.1. TLS 1.0 [TLS]
+     requires servers to "accept" extended client hello messages, even
+     if the server does not "understand" the extension.
+
+   - For the specific extensions described here, no mandatory server
+     response is required when clients request extended functionality.
+
+   Note however, that although backwards compatibility is supported,
+   some constrained clients may be forced to reject communications with
+   servers that do not support the extensions as a result of the limited
+   capabilities of such clients.
+
+   The remainder of this document is organized as follows. Section 2
+   describes general extension mechanisms for the client hello and
+   server hello handshake messages. Section 3 describes specific
+   extensions to TLS 1.0. Section 4 describes new error alerts for use
+   with the TLS extensions. The final sections of the document address
+   IPR, security considerations, acknowledgements, and references.
+
+2. General Extension Mechanisms
+
+   This section presents general extension mechanisms for the TLS
+   handshake client hello and server hello messages.
+
+   These general extension mechanisms are necessary in order to enable
+   clients and servers to negotiate whether to use specific extensions,
+   and how to use specific extensions. The extension formats described
+   are based on [MAILING LIST].
+
+   Section 2.1 specifies the extended client hello message format,
+   Section 2.2 specifies the extended server hello message format, and
+   Section 2.3 describes the actual extension format used with the
+   extended client and server hellos.
+
+ 2.1. Extended Client Hello
+
+   The extended client hello message format MAY be sent in place of the
+   client hello message format when clients wish to request extended
+   functionality from servers. The extended client hello message format
+   is:
+
+       struct {
+           ProtocolVersion client_version;
+           Random random;
+           SessionID session_id;
+
+
+
+Blake-Wilson et al.      Expires: December 2001                 [Page 4]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+           CipherSuite cipher_suites<2..2^16-1>;
+           CompressionMethod compression_methods<1..2^8-1>;
+           Extension client_hello_extension_list<0..2^16-1>;
+       } ClientHello;
+
+   Here the new "client_hello_extension_list" field contains a list of
+   extensions. The actual "Extension" format is defined in Section 2.3.
+
+   In the event that clients request additional functionality using the
+   extended client hello, and this functionality is not supplied by the
+   server, clients MAY abort the handshake.
+
+   Note that TLS, Section 7.4.1.2, allows additional information to be
+   added to the client hello message. Thus the use of the extended
+   client hello defined above should not "break" existing TLS 1.0
+   servers.
+
+ 2.2. Extended Server Hello
+
+   The extended server hello message format MAY be sent in place of the
+   server hello message when the client has requested extended
+   functionality via the extended client hello message specified in
+   Section 2.1. The extended server hello message format is:
+
+       struct {
+           ProtocolVersion server_version;
+           Random random;
+           SessionID session_id;
+           CipherSuite cipher_suite;
+           CompressionMethod compression_method;
+           Extension server_hello_extension_list<0..2^16-1>;
+       } ServerHello;
+
+   Here the new "server_hello_extension_list" field contains a list of
+   extensions. The actual "Extension" format is defined in Section 2.3.
+
+   Note that the extended server hello message is only sent in response
+   to an extended client hello message. This prevents the possibility
+   that the extended server hello message could "break" existing TLS 1.0
+   clients.
+
+ 2.3. Hello Extensions
+
+   The extension format for extended client hellos and extended server
+   hellos is:
+
+       struct {
+           ExtensionType extensionType;
+
+
+
+Blake-Wilson et al.      Expires: December 2001                 [Page 5]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+           opaque extension_data<0..2^16-1>;
+       } Extension;
+
+   Here:
+
+   - "extensionType" identifies the particular extension type.
+
+   - "extension_data" contains information specific to the particular
+      extension type.
+
+   The extension types defined in this document are:
+
+       enum {
+           dns_name(0), max_record_size(1), client_certificate_url(2),
+           trusted_ca_keys(3), truncated_hmac(4), status_request(5),
+           (65535)
+       } ExtensionType;
+
+   Note that for all extension types (including those defined in
+   future), the extension type should appear in the extended server
+   hello only if the same extension type appeared in the corresponding
+   client hello. Thus clients MUST abort the handshake if they receive
+   an extension type in the extended server hello that they did not
+   request in the associated (extended) client hello.
+
+   Also note that when multiple extensions are present in the extended
+   client hello or the extended server hello, the extensions must appear
+   in the order identified in "ExtensionType". Thus clients and servers
+   MUST abort the handshake if they receive an extended hello message in
+   which the extensions are not in the correct order.
+
+   Finally note that all the extensions defined in this document are
+   relevant only when a session is initiated. Extensions appearing in
+   client and server hellos sent during session resumption MUST be
+   ignored, and the extension functionality negotiated during session
+   initiation applied to the resumed session.
+
+ 2.4. Extensions to the handshake protocol
+
+   This document suggests the use of two new handshake messages,
+   "CertificateURL" and "CertificateAndOCSPResponse". These messages are
+   described in Section 3.3 and Section 3.6, respectively. The new
+   handshake message structure therefore becomes:
+
+       enum {
+           hello_request(0), client_hello(1), server_hello(2),
+           certificate(11), server_key_exchange (12),
+           certificate_request(13), server_hello_done(14),
+
+
+
+Blake-Wilson et al.      Expires: December 2001                 [Page 6]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+           certificate_verify(15), client_key_exchange(16),
+           finished(20), certificate_url(21), ocsp_response(22), (255)
+       } HandshakeType;
+
+       struct {
+           HandshakeType msg_type;    /* handshake type */
+           uint24 length;             /* bytes in message */
+           select (HandshakeType) {
+               case hello_request:       HelloRequest;
+               case client_hello:        ClientHello;
+               case server_hello:        ServerHello;
+               case certificate:         Certificate;
+               case server_key_exchange: ServerKeyExchange;
+               case certificate_request: CertificateRequest;
+               case server_hello_done:   ServerHelloDone;
+               case certificate_verify:  CertificateVerify;
+               case client_key_exchange: ClientKeyExchange;
+               case finished:            Finished;
+               case certificate_url:     CertificateURL;
+               case ocsp_response:       CertificateAndOCSPResponse;
+           } body;
+       } Handshake;
+
+3. Specific Extensions
+
+   This section describes the specific TLS extensions specified in this
+   document.
+
+   Note that any messages associated with these extensions that are sent
+   during the TLS handshake MUST be included in the hash calculations
+   involved in "Finished" messages.
+
+   Section 3.1 describes the extension of TLS to allow clients to
+   indicate which server they are contacting. Section 3.2 describes the
+   extension to provide maximum record size negotiation. Section 3.3
+   describes the extension to allow client certificate URLs. Section 3.4
+   describes the extension to allow clients to indicate which CA root
+   keys they possess.  Section 3.5 describes the extension to allow the
+   use of truncated HMAC.  Section 3.6 describes the extension to
+   support integration of OCSP into TLS handshakes.
+
+ 3.1. DNS Name Indication
+
+   TLS does not provide a mechanism for clients to tell servers the DNS
+   name of the server they are contacting. It may be desirable for
+   clients to provide this information to facilitate secure connections
+   to servers which host multiple 'virtual' servers at a single
+   underlying network address.
+
+
+
+Blake-Wilson et al.      Expires: December 2001                 [Page 7]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+   In order to provide the server DNS name, clients MAY include an
+   extension of type "dns_name" in the (extended) client hello. The
+   "extension_data" field of this extension shall contain:
+
+       opaque DNSName<1..2^16-1>;
+
+   "DNSName" contains the fully qualified domain name of the server, as
+   understood by the client. The domain name is represented as a byte
+   string using UTF-8 encoding [UTF8], without a trailing dot.  (Note
+   that the use of UTF-8 here for encoding internationalized domain
+   names is independent of the choice of encoding for these names in the
+   DNS protocol. The latter has yet to be decided by the IETF
+   International Domain Name Working Group.)
+
+   Literal IPv4 and IPv6 addresses are not permitted.
+
+   It is RECOMMENDED that clients include an extension of type "DNSName"
+   in the client hello whenever they locate a server by its domain name.
+
+   Servers that receive a client hello containing the "dns_name"
+   extension, MAY use the information contained in the extension to
+   guide their selection of an appropriate certificate to return to the
+   client.  In this event, the server shall include an extension of type
+   "dns_name" in the (extended) server hello. The "extension_data" field
+   of this extension shall be empty.
+
+   If the server understood the client hello extension but does not
+   recognize the DNS name as belonging to a domain it is responsible
+   for, it should send an unrecognised_domain alert (which may or may
+   not be fatal).
+
+ 3.2. Maximum Record Size Negotiation
+
+   TLS specifies a fixed maximum record size of 2^14 bytes. It may be
+   desirable for constrained clients to negotiate a smaller maximum
+   record size due to memory limitations or bandwidth limitations.
+
+   In order to negotiate smaller maximum record sizes, clients MAY
+   include an extension of type "max_record_size" in the (extended)
+   client hello.  The "extension_data" field of this extension shall
+   contain:
+
+       enum{
+           2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
+       } MaxRecordSize;
+
+   whose value is the desired maximum record size. The allowed values
+   for this field are: 2^9, 2^10, 2^11, and 2^12.
+
+
+
+Blake-Wilson et al.      Expires: December 2001                 [Page 8]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+   Servers that receive an extended client hello containing a
+   "max_record_size" extension, MAY accept the requested maximum record
+   size by including an extension of type "max_record_size" in the
+   (extended) server hello. The "extension_data" field of this extension
+   shall contain "MaxRecordSize" whose value is the same as the
+   requested maximum record size.
+
+   Servers receiving maximum record size negotiation requests for values
+   other than the allowed values MUST abort the handshake with an
+   "illegal_parameter" alert. Similarly, clients receiving maximum
+   record size negotiation responses that differ from the size they
+   requested MUST also abort the handshake with an "illegal_parameter"
+   alert.
+
+   Once a maximum record size other than 2^14 has been successfully
+   negotiated, the client and server MUST immediately begin fragmenting
+   messages (including handshake messages), to ensure that no message
+   larger than the negotiated size is sent. Note that TLS already
+   requires clients and servers to support fragmentation of handshake
+   messages.
+
+   The negotiated size applies for the duration of the session including
+   session resumptions.
+
+   The negotiated size limits the input that the record layer may
+   process without fragmentation. Note that the output of the record
+   layer may be larger. For example, if the negotiated size is 2^9=512,
+   then for currently defined cipher suites (those defined in [TLS],
+   [KERB], and planned AES ciphersuites), the record layer output can be
+   at most 793 bytes: 5 bytes of headers, 512 bytes of application data,
+   256 bytes of padding, and 20 bytes of MAC. This means that in this
+   event a TLS record layer peer receiving a TLS record layer message
+   larger than 793 bytes may discard the message and output an error
+   without decrypting the message. The exact error message sent will
+   depend on the size of the received message - either "record_overflow"
+   if the message is longer than 2^14+2048 bytes, or "decryption_failed"
+   otherwise.
+
+ 3.3. Client Certificate URLs
+
+   TLS specifies that when client authentication is performed, client
+   certificates are sent by clients to servers during the TLS handshake.
+   It may be desirable for constrained clients to send certificate URLs
+   in place of certificates so that they do not need to store their
+   certificates and can therefore save memory.
+
+   In order to negotiate to send certificate URLs to a server, clients
+   MAY include an extension of type "client_certificate_url" in the
+
+
+
+Blake-Wilson et al.      Expires: December 2001                 [Page 9]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+   (extended) client hello. The "extension_data" field of this extension
+   shall be empty.
+
+   (Note that it is necessary to negotiate use of client certificate
+   URLs in order to avoid "breaking" existing TLS 1.0 servers.)
+
+   Servers that receive an extended client hello containing a
+   "client_certificate_url" extension, MAY indicate that they are
+   willing to accept certificate URLs by including an extension of type
+   "client_certificate_url" in the (extended) server hello. The
+   "extension_data" field of this extension shall be empty.
+
+   After negotiation of the use of client certificate URLs has been
+   successfully completed (by exchanging hellos including
+   "client_certificate_url" extensions), clients MAY send a
+   "CertificateURL" message in place of a "Certificate" message:
+
+       struct {
+           URLAndHash url_and_hash_list<1..2^16-1>;
+       } CertificateURL;
+
+       struct {
+           opaque URL<1..2^16-1>;
+           CertHash certificate_hash;
+       } URLAndHash;
+
+       opaque CertHash[20];
+
+   Here "url_and_hash_list" contains a sequence of URLs and SHA-1
+   hashes, each URL referring to a single, DER-encoded X.509v3
+   certificate, and the SHA-1 hash of that certificate. The URLs should
+   occur in the list in the same order that the corresponding
+   certificates appear in the certificate chain.
+
+   Servers receiving "CertificateURL" shall attempt to retrieve the
+   client's certificate chain from the URLs, and then process the
+   certificate chain as usual. HTTP SHOULD be used to retrieve the
+   certificate chain from the URLs, and MUST be supported by servers
+   supporting this extension.
+
+   Servers MUST check that the SHA-1 hash of any certificates retrieved
+   from a CertificateURL matches the given hash, and then process the
+   certificate chain as usual.
+
+   If any retrieved certificate does not have the correct SHA-1 hash,
+   the server MUST abort the handshake with a bad_certificate alert.
+
+   Note that clients may choose to send either "Certificate" or
+
+
+
+Blake-Wilson et al.      Expires: December 2001                [Page 10]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+   "CertificateURL" after successfully negotiating the option to send
+   certificate URLs. The option to send a certificate is included to
+   provide flexibility to clients possessing multiple certificates.
+
+   If a server encounters an unreasonable delay in obtaining
+   certificates in a given CertificateURL, it SHOULD time out and signal
+   a "certificate_unobtainable" error alert.
+
+ 3.4. Trusted CA Indication
+
+   Constrained clients which, due to memory limitations, possess only a
+   small number of CA root keys, may wish to indicate to servers which
+   root keys they possess, in order to avoid repeated handshake
+   failures.
+
+   In order to indicate which CA root keys they possess, clients MAY
+   include an extension of type "trusted_ca_keys" in the (extended)
+   client hello. The "extension_data" field of this extension shall
+   contain "TrustedAuthorities" where:
+
+       struct {
+           TrustedAuthority trusted_authorities_list<0..2^16-1>;
+       } TrustedAuthorities;
+
+       struct {
+           IdentifierType identifier_type;
+           select (identifier_type) {
+               case null: struct {};
+               case key_hash_sha: KeyHash;
+               case x509_name: DistinguishedName;
+               case cert_hash: CertHash;
+           } Identifier;
+       } TrustedAuthority;
+
+       enum { null(0), key_hash_sha(1), x509_name(2), cert_hash(3),
+           (255)}
+           IdentifierType;
+
+       opaque DistinguishedName<1..2^16-1>;
+
+       opaque KeyHash[20];
+
+   Here "TrustedAuthorities" provides a list of CA root key identifiers
+   that the client possesses. Each CA root key is identified via either:
+
+   - "null" - no CA root key identity supplied.
+
+   - "key_hash_sha" - contains the SHA-1 hash of the CA root key. For
+
+
+
+Blake-Wilson et al.      Expires: December 2001                [Page 11]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+      DSA and ECDSA keys, this is the hash of the "subjectPublicKey"
+      value. For RSA keys, this is the hash of the byte string
+      representation of the modulus (without any initial 0-valued
+      bytes). (This copies the key hash formats deployed in other
+      environments.)
+
+   - "cert_hash" - contains the SHA-1 hash of a certificate containing
+      the CA root key.
+
+   - "x509_name" - contains the X.509 distinguished name of the CA.
+
+   Note that clients may include none, some, or all of the CA root keys
+   they possess in this extension.
+
+   Note also that it is possible that a key hash or a distinguished name
+   alone may not uniquely identify a certificate issuer - for example if
+   a particular CA has multiple key pairs - however here we assume this
+   is the case following the use of distinguish names to identify
+   certificate issuers in TLS.
+
+   The option to include no CA root keys is included to allow the client
+   to indicate possession of some pre-defined set of CA root keys.
+
+   Servers that receive a client hello containing the "trusted_ca_keys"
+   extension, MAY use the information contained in the extension to
+   guide their selection of an appropriate certificate chain to return
+   to the client.
+
+ 3.5. Truncated HMAC
+
+   Currently defined TLS ciphersuites use the MAC construction HMAC with
+   either MD5 or SHA-1 [HMAC] to authenticate record layer
+   communications. In TLS the entire output of the hash function is used
+   as the MAC tag. However it may be desirable in constrained
+   environments to save bandwidth by truncating the output of the hash
+   function to 80 bits when forming MAC tags.
+
+   In order to negotiate the use of 80-bit truncated HMAC, clients MAY
+   include an extension of type "truncated_hmac" in the extended client
+   hello. The "extension_data" field of this extension shall be empty.
+
+   Servers that receive an extended hello containing a "truncated_hmac"
+   extension, MAY agree to use a truncated HMAC by including an
+   extension of type "truncated_hmac" in the extended server hello.
+
+   Note that if new ciphersuites are added that do not use HMAC, and the
+   session negotiates one of these ciphersuites, this extension will
+   have no effect. It is strongly recommended that any new cipher suites
+
+
+
+Blake-Wilson et al.      Expires: December 2001                [Page 12]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+   using other MACs consider the MAC size as an integral part of the
+   cipher suite definition, taking into account both security and
+   bandwidth considerations.
+
+   If HMAC truncation has been successfully negotiated during a TLS
+   handshake, and the negotiated ciphersuite uses HMAC, both the client
+   and the server pass this fact to the TLS record layer along with the
+   other negotiated security parameters. Subsequently during the
+   session, clients and servers MUST use truncated HMACs, calculated as
+   specified in [HMAC]. Note that this extension does not affect the
+   calculation of the PRF as part of handshaking or key derivation.
+
+   The negotiated HMAC truncation size applies for the duration of the
+   session including session resumptions.
+
+ 3.6. OCSP Status Request
+
+   Constrained clients may wish to use OCSP [OCSP] to check the validity
+   of server certificates, in order to avoid transmission of CRLs and
+   therefore save bandwidth on constrained networks.
+
+   In order to indicate their desire to use OCSP, clients MAY include an
+   extension of type "status_request" in the (extended) client hello.
+   The "extension_data" field of this extension shall contain
+   "StatusRequest" where:
+
+       struct {
+           ResponderID responder_id_list<0..2^16-1>;
+           Extensions  request_extensions;
+       } StatusRequest;
+
+       opaque ResponderID<1..2^16-1>;
+       opaque Extensions<0..2^16-1>;
+
+   Here "ResponderIDs" provides a list of OCSP responders that the
+   client trusts. A zero-length "responder_id_list" sequence has the
+   special meaning that the responders are implicitly known to the
+   server - e.g. by prior arrangement. "Extensions" is a DER encoding of
+   the OCSP request extensions.
+
+   Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as
+   defined in [OCSP].
+
+   Servers that receive a client hello containing the "status_request"
+   extension, MAY return an OCSP response to the client along with their
+   certificate. If so, they SHOULD use the information contained in the
+   extension when selecting an OCSP responder, and SHOULD include
+   request_extensions in the OCSP request.
+
+
+
+Blake-Wilson et al.      Expires: December 2001                [Page 13]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+   Servers return an OCSP response along with their certificate by
+   sending "CertificateAndOCSPResponse" in place of the "Certificate"
+   message. If a server returns an OCSP response, then the server MUST
+   have included an extension of type "status_request" with empty
+   "extension_data" in the extended server hello.
+
+       struct {
+           ASN.1Cert certificate_list<0..2^24-1>;
+           OCSPResponse ocsp_response;
+       } CertificateAndOCSPResponse;
+
+       opaque ASN.1Cert<1..2^24-1>;
+
+       opaque OCSPResponse<1..2^24-1>;
+
+   Here "ocsp_response" contains a complete, DER-encoded OCSP response
+   (using the ASN.1 type OCSPResponse defined in [OCSP]). Note that only
+   one OCSP response may be sent.
+
+   The "CertificateAndOCSPResponse" message is conveyed using the
+   handshake message type "ocsp_response".
+
+   Note that a server MAY also choose not to send the
+   "CertificateAndOCSPResponse" message, and instead send the
+   "Certificate" message, even if it receives a "status_request"
+   extension in the client hello message.
+
+   Note in addition that servers MUST NOT send the
+   "CertificateAndOCSPResponse" message unless it received a
+   "status_request" extension in the client hello message.
+
+   Clients requesting an OCSP response, and receiving an OCSP response
+   in a "CertificateAndOCSPResponse" field:
+
+   - MUST process the certificate as if it was received in a
+     "Certificate" message, and;
+
+   - SHOULD check the OCSP response and abort the handshake if the
+     response is not satisfactory.
+
+4. Error Alerts
+
+   This section defines new error alerts for use with the TLS extensions
+   defined in this document.
+
+   The following new error alerts are defined. To avoid "breaking"
+   existing clients and servers, these alerts MUST NOT be sent unless
+   the sending party has received an extended hello message from the
+
+
+
+Blake-Wilson et al.      Expires: December 2001                [Page 14]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+   party they are communicating with.
+
+   - "unsupported_extension" - this alert is sent by clients that
+     receive an extended server hello containing an extension that
+     they did not put in the corresponding client hello (see Section
+     2.3). This message is always fatal.
+
+   - "bad_extension_order" - this alert is sent by clients or servers
+     that receive an extended hello with the extensions in the wrong
+     order (see Section 2.3). This message is always fatal.
+
+   - "unrecognised_domain" - this alert is sent by servers that
+     receive a dns_name extension request, but do not recognize the
+     DNS name as belonging to a domain they are responsible for.
+     This message MAY be fatal.
+
+   - "certificate_unobtainable" - this alert is sent by servers who are
+     unable to retrieve a certificate chain from the URL supplied by
+     the client (see Section 3.3). This message is always fatal.
+
+   - "bad_ocsp_response" - this alert is sent by clients that receive
+     an invalid OCSP response (see Section 3.6). This message is always
+     fatal.
+
+   These error alerts are conveyed using the following syntax:
+
+       enum {
+           close_notify(0),
+           unexpected_message(10),
+           bad_record_mac(20),
+           decryption_failed(21),
+           record_overflow(22),
+           decompression_failure(30),
+           handshake_failure(40),
+           certificate_unobtainable(41), /* new */
+           bad_certificate(42),
+           unsupported_certificate(43),
+           certificate_revoked(44),
+           certificate_expired(45),
+           certificate_unknown(46),
+           illegal_parameter(47),
+           unknown_ca(48),
+           access_denied(49),
+           decode_error(50),
+           decrypt_error(51),
+           export_restriction(60),
+           protocol_version(70),
+           insufficient_security(71),
+
+
+
+Blake-Wilson et al.      Expires: December 2001                [Page 15]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+           internal_error(80),
+           user_canceled(90),
+           no_renegotiation(100),
+           unsupported_extension(110),   /* new */
+           bad_extension_order(111),     /* new */
+           unrecognised_domain(112),     /* new */
+           bad_ocsp_response(113),       /* new */
+           (255)
+       } AlertDescription;
+
+5. Procedure for Defining New Extensions
+
+   Traditionally for Internet protocols, the Internet Assigned Numbers
+   Authority (IANA) handles the allocation of new values for future
+   expansion, and RFCs usually define the procedure to be used by the
+   IANA. However, there are subtle (and not so subtle) interactions that
+   may occur in this protocol between new features and existing features
+   which may result in a significant reduction in overall security.
+
+   Therefore, requests to define new extensions (including assigning
+   extension and error alert numbers) should be forwarded to the IETF
+   TLS Working Group for discussion.
+
+   The following considerations should be taken into account when
+   designing new extensions:
+
+    - All of the extensions defined in this document follow the
+      convention that for each extension that a client requests
+      and that the server understands, the server replies with an
+      extension of the same type.
+
+
+    - Some cases where a server does not agree to an extension are
+      error conditions, and some simply a refusal to support a
+      particular feature. In general error alerts should be used for
+      the former, and a field in the server extension response for
+      the latter.
+
+    - Extensions should as far as possible be designed to prevent
+      any attack that forces use (or non-use) of a particular feature
+      by manipulation of handshake messages. This principle should
+      be followed regardless of whether the feature is believed
+      to cause a security problem.
+
+      Often the fact that the extension fields are included in the
+      inputs to the Finished message hashes will be sufficient,
+      but extreme care is needed when the extension changes the
+      meaning of messages sent in the handshake phase.
+
+
+
+Blake-Wilson et al.      Expires: December 2001                [Page 16]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+      Designers and implementors should be aware of the fact that
+      until the handshake has been authenticated, active attackers
+      can modify messages and insert, remove, or replace extensions.
+
+    - It would be technically possible to use extensions to change
+      major aspects of the design of TLS; for example the design of
+      ciphersuite negotiation. This is not recommended; it
+      would be more appropriate to define a new version of TLS -
+      particularly since the TLS handshake algorithms have specific
+      protection against version rollback attacks based on the
+      version number, and the possibility of version rollback
+      should be a significant consideration in any major design
+      change.
+
+6. Security Considerations
+
+   Security considerations for the extension mechanism in general, and
+   the design of new extensions, are described in the previous section.
+   A security analysis of each of the extensions defined in this
+   document is given below.
+
+   In general, implementers should continue to monitor the state of the
+   art, and address any weaknesses identified.
+
+   Additional security considerations are described in the TLS 1.0 RFC
+   [TLS].
+
+ 6.1. Security of dns_name
+
+   If a single server hosts several domains, then clearly it is
+   necessary for the owners of each domain to ensure that this satisfies
+   their security needs. Apart from this, dns_name does not appear to
+   introduce significant security issues.
+
+   The length of the domain name should be checked for buffer overflow
+   (note that RFC 1035 restricts domain names to 255 bytes).
+
+ 6.2. Security of max_record_size
+
+   The maximum record size takes effect immediately, including for
+   handshake messages. However, that does not introduce any security
+   complications that are not already present in TLS, since [TLS]
+   requires implementations to be able to handle fragmented handshake
+   messages.
+
+   Note that as described in section 3.2, once a non-null ciphersuite
+   has been activated, the effective maximum record size depends on the
+   ciphersuite, as well as on the negotiated max_record_size.  This must
+
+
+
+Blake-Wilson et al.      Expires: December 2001                [Page 17]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+   be taken into account when sizing buffers, and checking for buffer
+   overflow.
+
+ 6.3. Security of client_certificate_url
+
+   When client authentication is used *without* the
+   client_certificate_url extension, the client certificate chain is
+   covered by the Finished message hashes. The purpose of checking a
+   SHA-1 hash of the certificate chain contents, is to ensure that the
+   same property holds when this extension is used - i.e. that all of
+   the information in the certificate chain retrieved by the server is
+   as the client intended.
+
+   (The attack that this protects against is admittedly fairly
+   unrealistic: the attacker would have to get a valid certificate on
+   the client's key which is different from the client's certificate.
+   Nevertheless, including this hash guarantees that there can be no
+   unexpected problems due to the certificate chain not being directly
+   covered by the Finished hashes.)
+
+   A similar approach should also be taken if possible for any future
+   extensions that involve fetching information from external sources.
+
+   Note that although TLS uses both MD5 and SHA-1 hashes in several
+   other places, this was not believed to be necessary here. The
+   property required of SHA-1 is second pre-image resistance.
+
+   Support for client_certificate_url involves the server acting as a
+   client in another protocol (usually HTTP, but other URL schemes are
+   not prohibited). It is therefore subject to many of the same security
+   considerations that apply to a publically accessible HTTP proxy
+   server. This includes the possibility that an attacker might use the
+   server to indirectly attack another host that is vulnerable to some
+   security flaw. It also includes potentially increased exposure to
+   denial of service attacks: an attacker can make many connections,
+   each of which results in the server making an HTTP request.
+
+   It is recommended that the client_certificate_url extension should
+   have to be specifically enabled by a server administrator, rather
+   than being enabled by default.
+
+   As discussed in [URI], URLs that specify ports other than the default
+   may cause problems, as may very long URLs (which are more likely to
+   be useful in exploiting buffer overflow bugs).
+
+ 6.4. Security of trusted_ca_keys
+
+   It is possible that which CA root keys a client possesses could be
+
+
+
+Blake-Wilson et al.      Expires: December 2001                [Page 18]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+   regarded as confidential information. As a result, the CA root key
+   indication extension should be used with care.
+
+   The use of the SHA-1 certificate hash alternative ensures that each
+   certificate is specified unambiguously. As for the previous
+   extension, it was not believed necessary to use both MD5 and SHA-1
+   hashes.
+
+ 6.5. Security of truncated_hmac
+
+   It is possible that truncated MACs are weaker than "un-truncated"
+   MACs. However, no significant weaknesses are currently known or
+   expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.
+   Note that the output length of a MAC need not be as long as the
+   length of a symmetric cipher key, since forging of MAC values cannot
+   be done off-line: in TLS, a single failed MAC guess will cause the
+   immediate termination of the TLS session.
+
+   Since the MAC algorithm only takes effect after the handshake
+   messages have been authenticated by the hashes in the Finished
+   messages, it is not possible for an active attacker to force
+   negotiation of the truncated HMAC extension where it would not
+   otherwise be used (to the extent that the handshake authentication is
+   secure). Therefore, in the event that any security problem were found
+   with truncated HMAC in future, if either the client or the server for
+   a given session have been updated to take into account the problem,
+   they would be able to veto use of this extension.
+
+ 6.6. Security of status_request
+
+   If a client requests an OCSP response, it must take into account that
+   an attacker's server using a compromised key could (and probably
+   would) pretend not to support the extension. A client that requires
+   OCSP validation of certificates SHOULD be prepared to contact the
+   OCSP server directly in this case.
+
+   Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
+   improve security against attacks that attempt to replay OCSP
+   responses; see section 4.4.1 of [OCSP] for further details.
+
+7. Internationalisation Considerations
+
+   None of the extensions defined here directly use strings subject to
+   localisation. Domain names are encoded using UTF-8. If future
+   extensions use text strings, then internationalisation should be
+   considered in their design.
+
+
+
+
+
+Blake-Wilson et al.      Expires: December 2001                [Page 19]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+8. Intellectual Property Rights
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this document. Please address the information to the IETF Executive
+   Director.
+
+9. Acknowledgments
+
+   The authors wish to thank the TLS Working Group and the WAP Security
+   Group. This document is based on discussion within these groups.
+
+10. References
+
+   [HMAC] Krawczyk, H., Bellare, M., and Canetti, R. - HMAC: Keyed-
+   hashing for message authentication. IETF RFC 2104, February 1997.
+
+   [HTTP] J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T.
+   Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1," IETF RFC
+   2616, June 1999.
+
+   [KERB] A. Medvinsky, M. Hur, "Addition of Kerberos Cipher Suites to
+   Transport Layer Security (TLS)," IETF RFC 2712, October 1999.
+
+   [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
+   Requirement Levels," IETF RFC 2119, March 1997.
+
+   [MAILING LIST] Mikkelsen, J. Eberhard, R., and J. Kistler, "General
+   ClientHello extension mechanism and virtual hosting," Ietf-tls
+   mailing list posting, August 14, 2000.
+
+   [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
+   Adams, "Internet X.509 Public Key Infrastructure: Online Certificate
+   Status Protocol - OCSP," IETF RFC 2560, June 1999.
+
+   [TLS] Dierks, T., and C. Allen, "The TLS Protocol - Version 1.0,"
+   IETF RFC 2246, January 1999.
+
+   [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
+   Identifiers (URI): Generic Syntax," IETF RFC 2396, August 1998.
+
+   [UTF8] F. Yergeau, "UTF-8, a transformation format of ISO 10646,"
+   IETF RFC 2279, January 1998.
+
+
+
+
+
+
+
+Blake-Wilson et al.      Expires: December 2001                [Page 20]
+
+INTERNET-DRAFT               TLS Extensions                    June 2001
+
+
+11. Authors' Addresses
+
+   Simon Blake-Wilson
+   Certicom Corp.
+   sblake-wilson@certicom.com
+
+   Magnus Nystrom
+   RSA Security
+   magnus@rsasecurity.com
+
+   David Hopwood
+   Independent Consultant
+   david.hopwood@zetnet.co.uk
+
+   Jan Mikkelsen
+   Transactionware
+   jam@transactionware.com
+
+   Tim Wright
+   Vodafone
+   timothy.wright@vf.vodafone.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blake-Wilson et al.      Expires: December 2001                [Page 21]
diff --git a/doc/protocol/draft-ietf-tls-https-04.txt b/doc/protocol/draft-ietf-tls-https-04.txt
deleted file mode 100644
index 2a4c40f94c..0000000000
--- a/doc/protocol/draft-ietf-tls-https-04.txt
+++ /dev/null
@@ -1,54 +0,0 @@
-A new Request for Comments is now available in online RFC libraries.
-
-
-        RFC 2818
-
-        Title:      HTTP Over TLS
-        Author(s):  E. Rescorla
-        Status:     Informational
-        Date:       May 2000
-        Mailbox:    ekr@rtfm.com
-        Pages:      8
-        Characters: 15170
-        Updates/Obsoletes/SeeAlso: None
-
-        URL:        ftp://ftp.isi.edu/in-notes/rfc2818.txt
-
-
-This memo describes how to use TLS to secure HTTP connections over
-the Internet. Current practice is to layer HTTP over SSL (the
-predecessor to TLS), distinguishing secured traffic from insecure
-traffic by the use of a different server port. This document documents
-that practice using TLS. A companion document describes a method for
-using HTTP/TLS over the same port as normal HTTP [RFC2817].
-
-This document is a product of the Transport Layer Security Working
-Group of the IETF.
-
-This memo provides information for the Internet community.  It does
-not specify an Internet standard of any kind.  Distribution of this
-memo is unlimited.
-
-This announcement is sent to the IETF list and the RFC-DIST list.
-Requests to be added to or deleted from the IETF distribution list
-should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
-added to or deleted from the RFC-DIST distribution list should
-be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
-
-Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
-an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
-help: ways_to_get_rfcs.  For example:
-
-        To: rfc-info@RFC-EDITOR.ORG
-        Subject: getting rfcs
-
-        help: ways_to_get_rfcs
-
-Requests for special distribution should be addressed to either the
-author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
-specifically noted otherwise on the RFC itself, all RFCs are for
-unlimited distribution.echo 
-Submissions for Requests for Comments should be sent to
-RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
-Authors, for further information.
-
diff --git a/doc/protocol/draft-ietf-tls-misty1-00.txt b/doc/protocol/draft-ietf-tls-misty1-00.txt
deleted file mode 100644
index 8bb9b675ec..0000000000
--- a/doc/protocol/draft-ietf-tls-misty1-00.txt
+++ /dev/null
@@ -1,183 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT                                                   H. Ohta
-TLS Working Group                                               H. Tsuji
-Expires March 2001                       Mitsubishi Electric Corporation
-                                                          September 2000
-
-
-                       Addition of MISTY1 to TLS
-
-                     <draft-ietf-tls-misty1-00.txt>
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet- Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-Abstract
-
-   This document proposes the addition of new cipher suites to the TLS
-   protocol version 1.0 to support the MISTY1 encryption algorithm as a
-   bulk cipher algorithm.
-
-1. Introduction
-
-   This document proposes the addition of new cipher suites to the TLS
-   protocol version 1.0[2] to support MISTY1 encryption algorithm[1] as
-   a bulk cipher algorithm.  MISTY1 is a block cipher with a 128-bit key
-   and a 64-bit block.  It is designed on the basis of the theory of
-   provable security against differential and linear cryptanalysis, and
-   moreover it realizes high-speed encryption on hardware platforms as
-   well as on software environments.
-
-
-
-
-Ohta, Tsuji                Expires March 2001                   [Page 1]
-
-
-
-
-
-
-Internet-Draft         Addition of MISTY1 to TLS          September 2000
-
-
-   This document defines the additional cipher specification to the TLS
-   protocol version 1.0.
-
-2. The Cipher Suites
-
-   The following values define the CipherSuite codes for the cipher
-   suites that use the MISTY1 CBC mode as a bulk cipher algorithm.
-
-    CipherSuite TLS_RSA_WITH_MISTY1_CBC_SHA            = { 0x00,0xXX };
-    CipherSuite TLS_DH_DSS_WITH_MISTY1_CBC_SHA         = { 0x00,0xXX };
-    CipherSuite TLS_DH_RSA_WITH_MISTY1_CBC_SHA         = { 0x00,0xXX };
-    CipherSuite TLS_DHE_DSS_WITH_MISTY1_CBC_SHA        = { 0x00,0xXX };
-    CipherSuite TLS_DHE_RSA_WITH_MISTY1_CBC_SHA        = { 0x00,0xXX };
-    CipherSuite TLS_DH_anon_WITH_MISTY1_CBC_SHA        = { 0x00,0xXX };
-
-   Note: Above CipherSuite numbers should be assigned and registerd.
-
-3. CipherSuite Definitions
-
-CipherSuite                      Is       Key          Cipher      Hash
-                             Exportable Exchange
-
-TLS_RSA_WITH_MISTY1_CBC_SHA             RSA            MISTY1_CBC  SHA
-TLS_DH_DSS_WITH_MISTY1_CBC_SHA          DH_DSS         MISTY1_CBC  SHA
-TLS_DH_RSA_WITH_MISTY1_CBC_SHA          DH_RSA         MISTY1_CBC  SHA
-TLS_DHE_DSS_WITH_MISTY1_CBC_SHA         DHE_DSS        MISTY1_CBC  SHA
-TLS_DHE_RSA_WITH_MISTY1_CBC_SHA         DHE_RSA        MISTY1_CBC  SHA
-TLS_DH_anon_WITH_MISTY1_CBC_SHA         DH_anon        MISTY1_CBC  SHA
-
-                         Key      Expanded   Effective   IV    Block
-    Cipher       Type  Material Key Material  Key Bits  Size   Size
-
-    MISTY1_CBC   Block   16         16         128        8      8
-
-   Note: Key Exchange Algorithms and Hash Functions are defined in TLS.
-
-4. Security Considerations
-
-   MISTY1 cipher suites are subject to the same security consideration
-   as TLS.  In addition, MISTY1 is designed in consideratin of the
-   theory of provable security against differential and liner
-   cryptanalysis.
-
-5. References
-
-   [1]  H. Ohta and M. Matsui, "A Description of the MISTY1 Encryption
-        Algorithm", Internet-Draft <draft-ohta-misty1desc-02.txt>, July
-        2000
-
-
-
-Ohta, Tsuji                Expires March 2001                   [Page 2]
-
-
-
-
-
-
-Internet-Draft         Addition of MISTY1 to TLS          September 2000
-
-
-   [2]  T. Dierks and C. Allen, "The TLS Protocol Version 1.0", RFC
-        2246, January 1999
-
-6. Author's Addresses
-
-   Hidenori Ohta
-   Mitsubishi Electric Corporation, Information Technology R&D Center
-   5-1-1 Ofuna, Kamakura, Kanagawa 247-8501, Japan
-   Phone: +81-467-41-2183
-   FAX:   +81-467-41-2185
-   EMail: hidenori@iss.isl.melco.co.jp
-
-   Hirosato Tsuji
-   Mitsubishi Electric Corporation, Information Technology R&D Center
-   5-1-1 Ofuna, Kamakura, Kanagawa 247-8501, Japan
-   Phone: +81-467-41-2183
-   FAX:   +81-467-41-2185
-   EMail: hirosato@iss.isl.melco.co.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ohta, Tsuji                Expires March 2001                   [Page 3]
-
-
-
diff --git a/doc/protocol/draft-ietf-tls-openpgp-00.txt b/doc/protocol/draft-ietf-tls-openpgp-01.txt
index 92e308b1f5..9dfd1866e9 100644
--- a/doc/protocol/draft-ietf-tls-openpgp-00.txt
+++ b/doc/protocol/draft-ietf-tls-openpgp-01.txt
@@ -1,9 +1,9 @@
 TLS Working Group                                               W. Price
 INTERNET-DRAFT                                                 M. Elkins
                                                 Network Associates, Inc.
-                                                        15 December 1999
+                                                           23 March 2001
 
-draft-ietf-tls-openpgp-00.txt
+draft-ietf-tls-openpgp-01.txt
 
 
                    Extensions to TLS for OpenPGP keys
@@ -52,9 +52,9 @@ Certificate
 
 
 
-Price                    Expires 15 June 2000                   [Page 1]
-
-Internet-Draft     Extensions to TLS for OpenPGP keys   15 December 1999
+Price                    Expires 23 September 2001              [Page 1]
+
+Internet-Draft     Extensions to TLS for OpenPGP keys      23 March 2001
 
 
    not be used in conjunction with OpenPGP keys.  An implementation
@@ -108,9 +108,9 @@ Certificate Request
 
 
 
-Price                    Expires 15 June 2000                   [Page 2]
-
-Internet-Draft     Extensions to TLS for OpenPGP keys   15 December 1999
+Price                    Expires 23 September 2001              [Page 2]
+
+Internet-Draft     Extensions to TLS for OpenPGP keys      23 March 2001
 
 
    based on OpenPGP keys.
@@ -164,9 +164,9 @@ Cipher Suites
 
 
 
-Price                    Expires 15 June 2000                   [Page 3]
-
-Internet-Draft     Extensions to TLS for OpenPGP keys   15 December 1999
+Price                    Expires 23 September 2001              [Page 3]
+
+Internet-Draft     Extensions to TLS for OpenPGP keys      23 March 2001
 
 
    Note:     The above numeric definitions for Cipher Suites have not
@@ -220,5 +220,5 @@ Authors
 
 
 
-Price                    Expires 15 June 2000                   [Page 4]
-
+Price                    Expires 23 September 2001              [Page 4]
+
diff --git a/doc/protocol/draft-ietf-tls-seedhas-00.txt b/doc/protocol/draft-ietf-tls-seedhas-00.txt
deleted file mode 100644
index a662984118..0000000000
--- a/doc/protocol/draft-ietf-tls-seedhas-00.txt
+++ /dev/null
@@ -1,223 +0,0 @@
-TLS Working Group                                           Joo-won Jung
-INTERNET-DRAFT                                              ChangHee Lee
-                                                           INITECH, Inc.
-                                                            12 July 2000
-
-
-                   TLS Extension for SEED and HAS-160
-
-                      draft-ietf-tls-seedhas-00.txt 
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet- Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-Introduction
-
-   This document proposes the addition of new cipher suites to the TLS
-   protocol 1.0 [TLS] to support SEED and HAS-160.
-
-   The SEED algorithm is 128-bit symmetric block cipher algorithm.
-   [SEED] The HAS-160 is 160-bit secure hash function, whose block size
-   is 512 bit. [HAS] Both algorithms are developed in Korea since 1997
-   for stronger communication security.  Currently, SEED is widely used
-   and is the mandatory cipher in banking and stock applications in
-   Korea.
-
-HMAC of HAS-160
-
-   HMAC of HAS160 can be defined like HMAC_MD5 or HMAC_SHA1.  Since
-   HAS-160 is 512-bit block, 160-bit output secure hash algorithm, B=64
-   and L=20 as the notation of [HMAC].
-
-   The test values of HMAC_HAS160 is provided as appendix of this
-
-
-
-Jung & Lee             Expires in 12 January 2001               [Page 1]
-
-Internet-Draft     TLS Extension for SEED and HAS-160       12 July 2000
-
-
-   document.
-
-   HMAC_HAS160 is used just for MAC of record layer. Adding HMAC_HAS160
-   does not affect the definitions of PRF, Finished message and other
-   definitions using HMAC_MD5 or HMAC_SHA1.
-
-Cipher Suites
-
-   In spite of the existence of Korean digital signature algorithm,
-   KCDSA, RSA algorithm is more widely used in Korea. Therefore, we
-   define cipher suites with RSA key exchange.
-
-      CipherSuite TLS_RSA_WITH_SEED_CBC_MD5          = { 0x00, 0x2C };
-      CipherSuite TLS_RSA_WITH_SEED_CBC_SHA          = { 0x00, 0x2D };
-      CipherSuite TLS_RSA_WITH_SEED_CBC_HAS160       = { 0x00, 0x2E };
-
-      Note: The above numeric definitions for Cipher Suites have not yet
-      been registered. The numeric definitions are the following numbers
-      of CipherSuite of TLS standard.[TLS]
-
-References
-
-   [HAS]   TTA.IS-10118, "Hash Function Standard - Part 2 : Hash
-           Function Algorithm (HAS-160)", Telecommunications Technology
-           Association, Republic of Korea, November, 1998.
-
-   [HMAC]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:  Keyed-
-           Hashing for Message Authentication," RFC 2104, February,
-           1997.
-
-   [SEED]  TTA.KO-12.0004, "128-bit Symmetric Block Cipher (SEED)",
-           Telecommunications Technology Association, Republic of Korea,
-           September 28, 1999.
-
-   [TLS]   T. Dierks, and C. Allen, "The TLS Protocol Version 1.0", RFC
-           2246, January 1999.
-
-
-Test Values of HMAC_HAS160
-
-   test_case =     1
-   key =           0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
-   key_len =       20
-   data =          "Hi There"
-   data_len =      8
-   digest =        0xf5b44115a53f716b6f488de1098ee7c251418623
-
-   test_case =     2
-
-
-
-Jung & Lee             Expires in 12 January 2001               [Page 2]
-
-Internet-Draft     TLS Extension for SEED and HAS-160       12 July 2000
-
-
-   key =           "Jefe"
-   key_len =       4
-   data =          "what do ya want for nothing?"
-   data_len =      28
-   digest =        0xa74547c1ef0aa147c7428ab7e71664549be2a412
-
-   test_case =     3
-   key =           0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
-   key_len =       20
-   data =          0xdd repeated 50 times
-   data_len =      50
-   digest =        0xe4c91bc71782fa44a56be1a34aae167e8ffc9734
-
-   test_case =     4
-   key =           0x0102030405060708090a0b0c0d0e0f10111213141516171819
-   key_len =       25
-   data =          0xcd repeated 50 times
-   data_len =      50
-   digest =        0x14d1055da875222053bf1180bbef8892eba3ac30
-
-   test_case =     5
-   key =           0x0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c
-   key_len =       20
-   data =          "Test With Truncation"
-   data_len =      20
-   digest =        0x63750d67af40e3fde33526545d300972a1527053
-
-   test_case =     6
-   key =           0xaa repeated 80 times
-   key_len =       80
-   data =          "Test Using Larger Than Block-Size Key - Hash Key First"
-   data_len =      54
-   digest =        0x63750d67af40e3fde33526545d300972a1527053
-
-   test_case =     7
-   key =           0xaa repeated 80 times
-   key_len =       80
-   data =          "Test Using Larger Than Block-Size Key and Larger
-                   Than One Block-Size Data"
-   data_len =      73
-   digest =        0x1bdb821e399e208352c64f0655f6601e2a8a087c
-
-
-      Note: These values are not cross-verified with other organization.
-
-Author's Address
-
-   Joo-won Jung
-
-
-
-Jung & Lee             Expires in 12 January 2001               [Page 3]
-
-Internet-Draft     TLS Extension for SEED and HAS-160       12 July 2000
-
-
-   INITECH, Inc.
-   EMail: jwjung@initech.com
-
-   ChangHee Lee
-   INITECH, Inc.
-   EMail: chlee@initech.com
-
-   Phone: +82 2 3430 5700
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jung & Lee             Expires in 12 January 2001               [Page 4]
-
diff --git a/doc/protocol/draft-ietf-tls-wireless-00.txt b/doc/protocol/draft-ietf-tls-wireless-00.txt
deleted file mode 100644
index 77e59277d8..0000000000
--- a/doc/protocol/draft-ietf-tls-wireless-00.txt
+++ /dev/null
@@ -1,743 +0,0 @@
-
-
-
-
-TLS Working Group                             Simon Blake-Wilson, Certicom
-INTERNET-DRAFT                                Magnus Nystrom, RSA Security
-Expires May 16, 2001                                     November 17, 2000
-
-                        Wireless Extensions to TLS
-                     <draft-ietf-tls-wireless-00.txt>
-
-                          Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026. Internet-Drafts are working
-   documents of the Internet Engineering Task Force (IETF), its areas,
-   and its working groups.  Note that other groups may also distribute
-   working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or made obsolete by other documents at
-   any time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as work in progress.
-
-   The list of current Internet-Drafts may be found at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories may be found at
-   http://www.ietf.org/shadow.html.
-
-
-                               Abstract
-
-   This document suggests extensions to TLS designed to make TLS more 
-   amenable to use within wireless environments. The extensions may be
-   used by TLS clients and servers. The extensions are backwards
-   compatible - communication is possible between TLS 1.0 clients
-   that support the extensions and TLS 1.0 servers that do not
-   support the extensions, and vice versa.
-
-   The document suggests extensions of two types: generic extension
-   mechanisms for the TLS client and server hellos, and specific
-   extensions using these generic mechanisms. It is hoped that the
-   structure of the document will allow each suggested extension to be
-   evaluated independently.
-
-   This document is based on discussions at the TLS working group
-   meeting during the Pittsburgh IETF meeting, and on discussions
-   within the WAP security group.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119.
-
-   Please send comments on this document to the TLS mailing list.
-
-
-Blake-Wilson, Nystrom                                           [Page 1]
-
-INTERNET-DRAFT                                          17 November 2000
-
-
-                            Table of Contents
-
-   1. Introduction ............................................... 2
-   2. General Extension Mechanisms ............................... 4
-   2.1. Extended Client Hello .................................... 4
-   2.2. Extended Server Hello .................................... 4
-   2.3. Hello Extensions ......................................... 5
-   3. Wireless Extensions ........................................ 6
-   3.1.	Maximum Record Size Negotiation .......................... 6
-   3.2.	Client Certificate URLs .................................. 7
-   3.3.	Trusted CA Indication .................................... 8
-   3.4.	Small Session Identifiers ................................ 9
-   3.5.	Truncated MACs .......................................... 10 
-   3.6.	OCSP .................................................... 11
-   4. Security Considerations ................................... 12
-   5. Intellectual Property Rights .............................. 12
-   6. Acknowledgments ........................................... 12
-   7. References ................................................ 12
-   8. Authors' Addresses ........................................ 13
-
-
-1. Introduction
-
-Wireless environments often suffer from a number of constraints not
-commonly present in wired environments - these constraints may include
-bandwidth limitations, computational power limitations, memory 
-limitations, and battery life limitations.
-
-Use within wireless environments was not one of the initial design
-criteria of the TLS protocol. As a result, implementations of TLS
-within wireless environments face a number of challenges.
-
-This document specifies extensions to the TLS 1.0 protocol designed to
-make TLS more amenable to use within wireless environments. The 
-extensions described here focus on extending the functionality provided
-by the TLS protocol message formats. Other issues, such as the addition
-of "wireless-friendly" cipher suites, are deferred.
-
-Specifically, the extensions described in this document are designed
-to:
-
-- Allow TLS clients and servers to negotiate the maximum record size to
-  be sent. This functionality is desirable as a result of memory 
-  constraints common among wireless clients, and bandwidth constraints
-  common among wireless networks.
-
-- Allow TLS clients and servers to negotiate the use of client
-  certificate URLs. This functionality is desirable in order to
-  conserve memory on wireless clients.
-
-
-Blake-Wilson, Nystrom                                           [Page 2]
-
-INTERNET-DRAFT                                          17 November 2000
-
-
-- Allow TLS clients to indicate to TLS servers which CA root keys they
-  possess. This functionality is desirable in order to prevent multiple
-  handshake failures involving TLS clients which are only able to store
-  a small number of CA root keys due to memory limitations.
-
-- Encourage TLS servers to use small session identifiers. This 
-  functionality is desirable in order to conserve memory on wireless
-  clients.
-
-- Allow TLS clients and servers to negotiate the use of truncated MACs.
-  This functionality is desirable in order to conserve bandwidth in
-  wireless networks.
-
-- Allow TLS clients and servers to negotiate that the server sends the
-  client an OCSP response during a TLS handshake. This functionality is
-  desirable in order to avoid sending a CRL over a wireless network and
-  therefore save bandwidth.  
-
-In order to support the extensions above, general extension mechanisms
-for the client hello message and the server hello message are
-introduced.
-
-The extensions described in this document may be used by TLS 1.0
-clients and TLS 1.0 servers. The extensions are designed to be
-backwards compatible - meaning that TLS 1.0 clients that support the
-extensions can talk to TLS 1.0 servers that do not support the
-extensions, and vice versa. 
-
-Backwards compatibility is primarily achieved via two considerations:
-
-- Clients typically request the use of extensions via the extended
-  client hello message described in Section 2.1. TLS 1.0 [TLS] requires
-  servers to "accept" extended client hello messages, even if the server
-  does not "understand" the extension.
-
-- For the specific extensions described here, no mandatory server
-  response is required when clients request extended functionality.
-
-Note however, that although backwards compatibility is supported, some
-wireless clients may be forced to reject communications with servers
-that do not support the extensions as a result of the limited
-capabilities of the wireless clients.
-
-The remainder of this document is organized as follows. Section 2
-describes general extension mechanisms for the client hello and server
-hello handshake messages. Section 3 describes specific extensions to
-TLS 1.0. The final sections of the document address IPR, security
-considerations, acknowledgements, and references.
-
-
-
-Blake-Wilson, Nystrom                                           [Page 3]
-
-INTERNET-DRAFT                                          17 November 2000
-
-
-2. General Extension Mechanisms
-
-This section presents general extension mechanisms for the TLS
-handshake client hello and server hello messages. 
-
-These general extension mechanisms are necessary in order to enable 
-clients and servers to negotiate whether to use specific extensions,
-and how to use specific extensions. The extension formats described are
-based on [MAILING LIST].
-
-Section 2.1 specifies the extended client hello message format, Section
-2.2 specifies the extended server hello message format, and Section 2.3
-describes the actual extension format used with the extended client and
-server hellos.
-
-   
-2.1. Extended Client Hello
-
-The extended client hello message format MAY be sent in place of the
-client hello message format when clients wish to request extended
-functionality from servers. The extended client hello message format is:
-
-          struct {
-              ProtocolVersion client_version;
-              Random random;
-              SessionID session_id;
-              CipherSuite cipher_suites<2..2^16-1>;
-              CompressionMethod compression_methods<1..2^8-1>;
-              Extension client_hello_extension_list<0..2^16-1>;
-          } ClientHello;   
-
-Here the new "client_hello_extension_list" field contains a list of
-extensions. The actual "Extension" format is defined in Section 2.3.
-
-In the event that clients request additional functionality using the
-extended client hello, and this functionality is not supplied by the
-server, clients MAY abort the handshake.
-
-Note that TLS, Section 7.4.1.2, allows additional information to be
-added to the client hello message. Thus the use of the extended client
-hello defined above should not "break" existing TLS 1.0 servers.
-
-
-2.2. Extended Server Hello
-
-The extended server hello message format MAY be sent in place of the
-server hello message when the client has requested extended
-functionality via the extended client hello message specified in
-Section 2.1. The extended server hello message format is:
-
-
-Blake-Wilson, Nystrom                                           [Page 4]
-
-INTERNET-DRAFT                                          17 November 2000
-
-
-       struct {
-           ProtocolVersion server_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suite;
-           CompressionMethod compression_method;
-           Extension server_hello_extension_list<0..2^16-1>;
-       } ServerHello;
-
-Here the new "server_hello_extension_list" field contains a list of
-extensions. The actual "Extension" format is defined in Section 2.3.
-
-Note that the extended server hello message is only sent in response to
-an extended client hello message. This prevents the possibility that
-the extended server hello message could "break" existing TLS 1.0
-clients.
-
-
-2.3. Hello Extensions
-
-The extension format for extended client hellos and extended server
-hellos is:
-
-          struct {
-              ExtensionType extensionType;
-              opaque unknown_extension<0..2^16-1>;
-          } Extension;
-
-Here:
-
-- "extensionType" identifies the particular extension type.
-
-- "unknown_extension" contains information specific to the particular
-  extension type. 
-
-The extension types defined in this document are:
-
-          enum { 
-                reserved(0), max_record_size(1), 
-                client_certificate_url(2), trusted_key_ids(3), 
-                truncated_MAC(4), status_request(5), (65535) 
-          } ExtensionType;
-
-Note that for all the extension types defined in this document, the
-extension type should appear in the extended server hello only if the
-same extension type appeared in the corresponding client hello. Thus
-clients MUST abort the handshake if they receive an extension type in
-the extended server hello that they did not request in the associated
-(extended) client hello.
-
-
-Blake-Wilson, Nystrom                                           [Page 5]
-
-INTERNET-DRAFT                                          17 November 2000
-
-
-Also note that when multiple extensions are present in the extended
-client hello or the extended server hello, the extensions must appear
-in the order identified in "ExtensionType". Thus clients and servers
-MUST abort the handshake if they receive an extended hello message in
-which the extensions are not in the correct order.
-
-Finally note that it is possible to alternatively define
-"unknown_extension" using a selection on "extensionType" (instead of
-just defining it as type "opaque"). This approach appears to have pros
-and cons - using a selection is more restrictive and thus less prone to
-implementation errors, but using "opaque" ensures inclusion of the
-length and thus ensures that users can skip extensions they don't
-understand. We would particularly welcome comments on this issue.
-
-
-3. Wireless Extensions
-
-This section describes the specific TLS extensions specified in this
-document.
-
-Note that any messages associated with these extensions that is sent 
-during the TLS handshake MUST be included in the hash calculations
-involved in "Finished" messages.
-
-Section 3.1 describes the extension of TLS to provide maximum record 
-size negotiation. Section 3.2 describes the extension to allow client
-certificate URLs. Section 3.3 describes the extension to allow clients
-to indicate which CA root keys they possess. Section 3.4 describes the
-extension to restrict the size of session identifiers. Section 3.5
-describes the extension to allow the use of truncated MACs. Section 3.6
-describes the extension to support integration of OCSP into TLS
-handshakes. 
-   
-
-3.1. Maximum Record Size Negotiation
-
-TLS specifies a fixed maximum record size of 2^14 bytes. It may be
-desirable for wireless clients to negotiate a smaller maximum record
-size due to memory limitations or bandwidth limitations.
-
-In order to negotiate smaller maximum record sizes, clients MAY include
-an extension of type "max_record_size" in the (extended) client hello. 
-The "unknown-extension" field of this extension shall contain:
-
-         enum{ 
-           2^8(1), 2^9(2), 2^10(3), 2^11(4), 2^12(5), (255) 
-         } Negotiated_max_record_size ;
-
-whose value is the desired maximum record size. The allowed values for
-this field are: 2^8, 2^9, 2^10, 2^11, and 2^12.
-
-Blake-Wilson, Nystrom                                           [Page 6]
-
-INTERNET-DRAFT                                          17 November 2000
-
-
-
-Servers that receive an extended client hello containing a
-"max_record_size" extension, MAY accept the requested maximum record
-size by including an extension of type "max_record_size" in the
-(extended) server hello. The "unknown_extension" field of this
-extension shall contain "Negotiated_max_record_size" whose value is the
-same as the requested maximum record size.
-
-Servers receiving maximum record size negotiation requests for values
-other than the allowed values  MUST abort the handshake. Similarly,
-clients receiving maximum record size negotiation responses that differ
-from the size they requested MUST also abort the handshake.
-
-Once a maximum record size other than 2^14 has been successfully
-negotiated during a TLS handshake, both the client and server pass the
-negotiated maximum record size value to the TLS record layer along with
-the negotiated security parameters. (Note that it may be desirable in
-the future to update the TLS security parameters to include the maximum
-record size value.) During the subsequent session after exchange of
-change cipher spec messages, the client and server MUST ensure that no
-messages larger than the negotiated size are sent.
-
-3.2. Client Certificate URLs
-   
-TLS specifies that when client authentication is performed, client
-certificates are sent by clients to servers during the TLS handshake.
-It may be desirable for wireless clients to send a certificate URL in
-place of a certificate so that they do not need to store their
-certificate and can therefore save memory.
-
-In order to negotiate to send a certificate URL to a server, clients
-MAY include an extension of type "client_certificate_url" in the
-(extended) client hello. The "unknown_extension" field of this
-extension shall be empty. 
-
-(Note that it is necessary to negotiate use of a client certificate URL
-in order to avoid "breaking" existing TLS 1.0 servers.)
-
-Servers that receive an extended client hello containing a
-"client_certificate_url" extension, MAY indicate that they are willing
-to accept a certificate URL by including an extension of type
-"client_certificate_url" in the (extended) server hello. The
-"unknown_extension" field of this extension shall be empty.
-
-After negotiation of the use of a client certificate URL has been
-successfully completed (by exchanging hellos including
-"client_certificate_url" extensions), clients send a "CertificateorURL"
-message in place of a "Certificate" message:
-
-
-
-
-Blake-Wilson, Nystrom                                           [Page 7]
-
-INTERNET-DRAFT                                          17 November 2000
-
-
-         struct{
-              Certificate_or_URL certificate_transport_type;
-              select (Certificate_or_URL) {
-                  case certificate: 
-                      ASN.1Cert certificate_list<0..2^24-1>;
-                  case url: 
-                      opaque url<0..2^8-1>;
-              } certificate_transport_body;
-         } CertificateorURL;
-
-         enum{ certificate(1), url(2), (255) } Certificate_or_URL ;
-
-(Nevertheless, the handshake message is identified as being of type
-"certificate".)  
-
-Here:
-
-- "certificate_transport_type" indicates whether a certificate chain or
-  URL is being sent.
-
-- "certificate_transport_body" contains either a certificate chain, or
-  a certificate URL.
-
-Servers receiving "CertificateorURL" shall attempt to retrieve the
-client's certificate chain from the URL (if necessary), and then process the
-certificate chain as usual.
-
-Note that "CertificateorURL" allows the client to send either a
-certificate or a URL. The option to send a certificate, even after
-successfully negotiating the possibility to send a URL, is included to
-provide flexibility to clients possessing multiple certificates.
-
-
-3.3. Trusted CA Indication
-
-Wireless clients which, due to memory limitations, possess only a small
-number of CA root keys, may wish to indicate to servers which root keys
-they possess, in order to avoid repeated handshake failures.
-
-In order to indicate which CA root keys they possess, clients MAY
-include an extension of type "trusted_key_ids" in the (extended) client
-hello. The "unknown_extension" field of this extension shall contain
-"TrustedAuthorities" where:
-
-          TrustedAuthority TrustedAuthorities<0..2^16-1>;
-
-
-
-
-
-
-Blake-Wilson, Nystrom                                           [Page 8]
-
-INTERNET-DRAFT                                          17 November 2000
-
-
-          struct {
-              IdentifierType identifier_type;
-              select (identifier_type) {
-                  case null: struct {};
-                  case key_hash_sha: KeyHash;
-                  case x509_name: DistinguishedName;
-              } identifier;
-          } TrustedAuthority;
-
-          enum { null(0), key_hash_sha(1), x509_name(2),(255)}
-              IdentifierType;
-
-          opaque DistinguishedName<1..2^16-1>;
-
-          opaque KeyHash[20];
-
-Here "TrustedAuthorities" provides a list of CA root key identifiers
-that the client possesses. Each CA root key is identified via either:
-
-- "null" - no CA root key identity supplied.
-       
-- "key_hash_sha" - contains the SHA-1 hash of the CA root key. (For DSA
-  and ECDSA keys, this is the hash of the "subjectPublicKey" value. For
-  RSA keys, this is the hash of the byte string representation of the
-  modulus.) 
-       
-- "x509_name" - contains the X.509 distinguished name of the CA.
-
-Note that clients may include none, some, or all of the CA root keys
-they possess in this extension.
-
-(The option to include no CA root keys is included both to maintain
-syntactical similarity with Section 3.6, and to allow the client to
-indicate possession of some pre-defined set of CA root keys.)
-
-Servers that receive a client hello containing the "trusted_key_ids"
-extension, MAY use the information contained in the extension to guide
-their selection of an appropriate certificate chain to return to the
-client. 
-   
-
-3.4. Small Session Identifiers
-   
-TLS specifies that session identifiers can be up to 32 bytes in length.
-In order to save memory, it is desirable to restrict the size of
-session identifiers which are stored by wireless clients.
-
-The syntax used by TLS for session identifiers is:
-
-          opaque SessionID<0..32>;
-
-Blake-Wilson, Nystrom                                           [Page 9]
-
-INTERNET-DRAFT                                          17 November 2000
-
-
-In order to encourage use of small session identifiers, servers SHOULD
-select session identifiers whose length is 8 bytes or less.
-
-
-3.5. Truncated MACs
-
-TLS uses the MAC construction HMAC with either MD5 or SHA-1 [HMAC] to
-authenticate record layer communications. In TLS the entire output of
-the hash function is used as the MAC tag. However it may be desirable
-in wireless environments to save bandwidth by truncating the output of
-the hash function when forming MAC tags.
-
-In order to negotiate the use of truncated MACs, clients MAY include an
-extension of type "truncated_MAC" in the extended client hello. The
-"unknown_extension" field of this extension shall contain
-"MACTruncations", where:
-
-          MACTruncation MACTruncations<0..2^8-1>;
-
-          struct {
-              MACAlgorithm mac_type;
-              uint16 trucation_size_in_bits
-          } MACTruncation;
-
-          enum { null(0), md5(1), sha1(2), (255) } MACAlgorithm;
-
-Here "MACTruncations" contains a list of MAC truncation sizes suggested
-by the client. Allowed values for suggested truncation sizes are: for
-HMAC-with-SHA1 ("sha1") - 80 bits; and for HMAC-with-MD5 ("md5") - 80
-bits. 
-
-Servers that receive an extended hello containing a "truncated_MAC"
-extension, MAY agree to use a truncated MAC by including an extension
-of type "truncated_MAC" in the extended server hello. The
-"unknown_extension" field of this extension shall contain
-"MACTruncation". Here "MACTruncation" shall contain the agreed MAC
-truncation size, select from the list suggested by the client. Note
-that the "MACAlgorithm" identified in "MACTruncation" must match the
-MAC used by the established cipher suite.
-
-Servers receiving MAC truncation negotiation requests requesting values
-other than the allowed values, MUST abort the handshake. Similarly
-clients receiving MAC truncation negotiation responses that differ from
-the values they suggested, or that do not match the established cipher
-suite, MUST abort the handshake.
-
-Once MAC truncation has been successfully negotiated during a TLS
-handshake, both the client and the server pass the negotiated
-truncation size to the TLS record layer along with the other negotiated
-security parameters. Subsequently during the session, clients and
-
-Blake-Wilson, Nystrom                                          [Page 10]
-
-INTERNET-DRAFT                                          17 November 2000
-
-servers MUST use truncated MACs. (Truncated MACs are calculated as
-specified in [HMAC].)
-
-3.6. OCSP
-   
-Wireless clients may wish to use OCSP [OCSP] to check the validity of
-server certificates, in order to avoid transmission of CRLs and
-therefore save bandwidth on wireless networks.
-
-In order to indicate their desire to use OCSP, clients MAY include an
-extension of type "status_request" in the (extended) client hello. The
-"unknown_extension" field of this extension shall contain
-"TrustedAuthorities" as defined in Section 3.3.
-
-Here "TrustedAuthorities" provides a list of OCSP responders that the
-client trusts. The "null" alternative in "TrustedAuthorities" can be
-used to indicate that the responders are implicitly known to the server
-- e.g. by prior arrangement.
-
-Servers that receive a client hello containing the "status_request"
-extension, MAY return an OCSP response to the client along with their
-certificate, and MAY use the information contained in the extension
-when selecting an OCSP responder.
-
-Servers return an OCSP response along with their certificate by sending
-"CertificateAndOCSPResponse" in place of the "Certificate" message. If
-a server returns an OCSP response, then the server MUST include an
-extension of type "status_request" with empty "unknown_extensions" in the
-extended server hello. 
-
-          struct {
-              ASN.1Cert    certificate_list<0..2^24-1>;
-              OCSPResponse ocsp_response;
-          } CertificateAndOCSPResponse;
-
-          opaque ASN.1Cert<1..2^24-1>;
-
-          opaque OCSPResponse<1..2^24-1>;
-
-(Nevertheless, the handshake message is identified as being of type
-"certificate".) 
-
-Here "ocsp_response" contains a complete, DER-encoded OCSP response.
-Note that only one OCSP response may be sent.
-
-Note that a server MAY also choose not to send the
-"CertificateAndOCSPResponse" message, and instead send the "Certificate"
-message, even if it receives a "status_request" extension in the
-client hello message. 
-
-Note in addition that servers MUST NOT send the
-"CertificateAndOCSPResponse" message unless it received a
-"status_request" extension in the client hello message.
-
-Clients requesting an OCSP response, and receiving an OCSP response in
-a "CertificateAndOCSPResponse" field:
-
-- MUST process the certificate as if it was received in a "Certificate"
-  message, and;
-
-- MAY check the OCSP response and abort the handshake if the response
-  is not satisfactory. 
-
-Blake-Wilson, Nystrom                                          [Page 11]
-
-INTERNET-DRAFT                                          17 November 2000
-
-
-4. Security Considerations
-
-The use of the extensions specified in this document may introduce
-security concerns for TLS clients and servers.
-
-In particular, it is possible that truncated MACs are weaker than
-"un-truncated" MACs. No such weaknesses are currently known for the
-truncation sizes specified in this document.
-
-In addition, it is possible that which CA root keys a client possesses
-could be regarded as confidential information. As a result, the CA root
-key indication extension should be used with care.
-
-Also, TLS entities must be aware of the fact that until the handshake
-has been authenticated, active attackers can modify messages and
-insert, remove, or replace extensions.
-
-In general, implementers should continue to monitor the state of the
-art, and address any weaknesses identified.
-
-Additional security considerations are described in the TLS RFC [TLS].    
-
-
-5. Intellectual Property Rights
- 
-The IETF invites any interested party to bring to its attention any
-copyrights, patents or patent applications, or other proprietary rights
-which may cover technology that may be required to practice this
-document. Please address the information to the IETF Executive Director.
-  
-
-6. Acknowledgments
-
-The authors wish to thank the WAP Security Group. This document is
-based on discussion within the WAP Security Group.
-
-
-7. References
-
-[HMAC] Krawczyk, H., Bellare, M., and Canetti, R. - HMAC: Keyed-hashing
-  for message authentication. IETF RFC 2104, February 1997.
-
-[MAILING LIST] Mikkelsen, J. Eberhard, R., and J. Kistler, "General
-  ClientHello extension mechanism and virtual hosting," Ietf-tls
-  mailing list posting, August 14, 2000.
-
-[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
-  Adams, "Internet X.509 Public Key Infrastructure: Online Certificate
-  Status Protocol - OCSP," IETF RFC 2560, June 1999.
-
-
-Blake-Wilson, Nystrom                                          [Page 12]
-
-INTERNET-DRAFT                                          17 November 2000
-
-
-[TLS] Dierks, T., and C. Allen, "The TLS Protocol - Version 1.0,"
-  IETF RFC 2246, January 1999.
-
-
-8. Authors' Addresses
-
-           Simon Blake-Wilson
-           Certicom Corp.
-           sblake-wilson@certicom.com
-
-           Magnus Nystrom
-           RSA Security
-           magnus@rsasecurity.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, Nystrom                                          [Page 13]
-
diff --git a/doc/protocol/rfc2817.txt b/doc/protocol/rfc2817.txt
new file mode 100644
index 0000000000..d7b7e703bb
--- /dev/null
+++ b/doc/protocol/rfc2817.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                           R. Khare
+Request for Comments: 2817                     4K Associates / UC Irvine
+Updates: 2616                                                S. Lawrence
+Category: Standards Track                          Agranat Systems, Inc.
+                                                                May 2000
+
+
+                    Upgrading to TLS Within HTTP/1.1
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This memo explains how to use the Upgrade mechanism in HTTP/1.1 to
+   initiate Transport Layer Security (TLS) over an existing TCP
+   connection. This allows unsecured and secured HTTP traffic to share
+   the same well known port (in this case, http: at 80 rather than
+   https: at 443). It also enables "virtual hosting", so a single HTTP +
+   TLS server can disambiguate traffic intended for several hostnames at
+   a single IP address.
+
+   Since HTTP/1.1 [1] defines Upgrade as a hop-by-hop mechanism, this
+   memo also documents the HTTP CONNECT method for establishing end-to-
+   end tunnels across HTTP proxies. Finally, this memo establishes new
+   IANA registries for public HTTP status codes, as well as public or
+   private Upgrade product tokens.
+
+   This memo does NOT affect the current definition of the 'https' URI
+   scheme, which already defines a separate namespace
+   (http://example.org/ and https://example.org/ are not equivalent).
+
+
+
+
+
+
+
+
+
+
+
+Khare & Lawrence            Standards Track                     [Page 1]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+Table of Contents
+
+   1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.1 Requirements Terminology . . . . . . . . . . . . . . . . . . .  4
+   3.  Client Requested Upgrade to HTTP over TLS  . . . . . . . . . .  4
+   3.1 Optional Upgrade . . . . . . . . . . . . . . . . . . . . . . .  4
+   3.2 Mandatory Upgrade  . . . . . . . . . . . . . . . . . . . . . .  4
+   3.3 Server Acceptance of Upgrade Request . . . . . . . . . . . . .  4
+   4.  Server Requested Upgrade to HTTP over TLS  . . . . . . . . . .  5
+   4.1 Optional Advertisement . . . . . . . . . . . . . . . . . . . .  5
+   4.2 Mandatory Advertisement  . . . . . . . . . . . . . . . . . . .  5
+   5.  Upgrade across Proxies . . . . . . . . . . . . . . . . . . . .  6
+   5.1 Implications of Hop By Hop Upgrade . . . . . . . . . . . . . .  6
+   5.2 Requesting a Tunnel with CONNECT . . . . . . . . . . . . . . .  6
+   5.3 Establishing a Tunnel with CONNECT . . . . . . . . . . . . . .  7
+   6.  Rationale for the use of a 4xx (client error) Status Code  . .  7
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+   7.1 HTTP Status Code Registry  . . . . . . . . . . . . . . . . . .  8
+   7.2 HTTP Upgrade Token Registry  . . . . . . . . . . . . . . . . .  8
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   8.1 Implications for the https: URI Scheme . . . . . . . . . . . . 10
+   8.2 Security Considerations for CONNECT  . . . . . . . . . . . . . 10
+       References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
+   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
+       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
+
+1. Motivation
+
+   The historical practice of deploying HTTP over SSL3 [3] has
+   distinguished the combination from HTTP alone by a unique URI scheme
+   and the TCP port number. The scheme 'http' meant the HTTP protocol
+   alone on port 80, while 'https' meant the HTTP protocol over SSL on
+   port 443.  Parallel well-known port numbers have similarly been
+   requested -- and in some cases, granted -- to distinguish between
+   secured and unsecured use of other application protocols (e.g.
+   snews, ftps). This approach effectively halves the number of
+   available well known ports.
+
+   At the Washington DC IETF meeting in December 1997, the Applications
+   Area Directors and the IESG reaffirmed that the practice of issuing
+   parallel "secure" port numbers should be deprecated. The HTTP/1.1
+   Upgrade mechanism can apply Transport Layer Security [6] to an open
+   HTTP connection.
+
+
+
+
+
+
+Khare & Lawrence            Standards Track                     [Page 2]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+   In the nearly two years since, there has been broad acceptance of the
+   concept behind this proposal, but little interest in implementing
+   alternatives to port 443 for generic Web browsing. In fact, nothing
+   in this memo affects the current interpretation of https: URIs.
+   However, new application protocols built atop HTTP, such as the
+   Internet Printing Protocol [7], call for just such a mechanism in
+   order to move ahead in the IETF standards process.
+
+   The Upgrade mechanism also solves the "virtual hosting" problem.
+   Rather than allocating multiple IP addresses to a single host, an
+   HTTP/1.1 server will use the Host: header to disambiguate the
+   intended web service. As HTTP/1.1 usage has grown more prevalent,
+   more ISPs are offering name-based virtual hosting, thus delaying IP
+   address space exhaustion.
+
+   TLS (and SSL) have been hobbled by the same limitation as earlier
+   versions of HTTP: the initial handshake does not specify the intended
+   hostname, relying exclusively on the IP address. Using a cleartext
+   HTTP/1.1 Upgrade: preamble to the TLS handshake -- choosing the
+   certificates based on the initial Host: header -- will allow ISPs to
+   provide secure name-based virtual hosting as well.
+
+2. Introduction
+
+   TLS, a.k.a., SSL (Secure Sockets Layer), establishes a private end-
+   to-end connection, optionally including strong mutual authentication,
+   using a variety of cryptosystems. Initially, a handshake phase uses
+   three subprotocols to set up a record layer, authenticate endpoints,
+   set parameters, as well as report errors.  Then, there is an ongoing
+   layered record protocol that handles encryption, compression, and
+   reassembly for the remainder of the connection. The latter is
+   intended to be completely transparent. For example, there is no
+   dependency between TLS's record markers and or certificates and
+   HTTP/1.1's chunked encoding or authentication.
+
+   Either the client or server can use the HTTP/1.1 [1] Upgrade
+   mechanism (Section 14.42) to indicate that a TLS-secured connection
+   is desired or necessary. This memo defines the "TLS/1.0" Upgrade
+   token, and a new HTTP Status Code, "426 Upgrade Required".
+
+   Section 3 and Section 4 describe the operation of a directly
+   connected client and server. Intermediate proxies must establish an
+   end-to-end tunnel before applying those operations, as explained in
+   Section 5.
+
+
+
+
+
+
+
+Khare & Lawrence            Standards Track                     [Page 3]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+2.1 Requirements Terminology
+
+   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
+   "MAY" that appear in this document are to be interpreted as described
+   in RFC 2119 [11].
+
+3. Client Requested Upgrade to HTTP over TLS
+
+   When the client sends an HTTP/1.1 request with an Upgrade header
+   field containing the token "TLS/1.0", it is requesting the server to
+   complete the current HTTP/1.1 request after switching to TLS/1.0.
+
+3.1 Optional Upgrade
+
+   A client MAY offer to switch to secured operation during any clear
+   HTTP request when an unsecured response would be acceptable:
+
+       GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1
+       Host: example.bank.com
+       Upgrade: TLS/1.0
+       Connection: Upgrade
+
+   In this case, the server MAY respond to the clear HTTP operation
+   normally, OR switch to secured operation (as detailed in the next
+   section).
+
+   Note that HTTP/1.1 [1] specifies "the upgrade keyword MUST be
+   supplied within a Connection header field (section 14.10) whenever
+   Upgrade is present in an HTTP/1.1 message".
+
+3.2 Mandatory Upgrade
+
+   If an unsecured response would be unacceptable, a client MUST send an
+   OPTIONS request first to complete the switch to TLS/1.0 (if
+   possible).
+
+       OPTIONS * HTTP/1.1
+       Host: example.bank.com
+       Upgrade: TLS/1.0
+       Connection: Upgrade
+
+3.3 Server Acceptance of Upgrade Request
+
+   As specified in HTTP/1.1 [1], if the server is prepared to initiate
+   the TLS handshake, it MUST send the intermediate "101 Switching
+   Protocol" and MUST include an Upgrade response header specifying the
+   tokens of the protocol stack it is switching to:
+
+
+
+
+Khare & Lawrence            Standards Track                     [Page 4]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+       HTTP/1.1 101 Switching Protocols
+       Upgrade: TLS/1.0, HTTP/1.1
+       Connection: Upgrade
+
+   Note that the protocol tokens listed in the Upgrade header of a 101
+   Switching Protocols response specify an ordered 'bottom-up' stack.
+
+   As specified in  HTTP/1.1 [1], Section 10.1.2: "The server will
+   switch protocols to those defined by the response's Upgrade header
+   field immediately after the empty line which terminates the 101
+   response".
+
+   Once the TLS handshake completes successfully, the server MUST
+   continue with the response to the original request. Any TLS handshake
+   failure MUST lead to disconnection, per the TLS error alert
+   specification.
+
+4. Server Requested Upgrade to HTTP over TLS
+
+   The Upgrade response header field advertises possible protocol
+   upgrades a server MAY accept. In conjunction with the "426 Upgrade
+   Required" status code, a server can advertise the exact protocol
+   upgrade(s) that a client MUST accept to complete the request.
+
+4.1 Optional Advertisement
+
+   As specified in HTTP/1.1 [1], the server MAY include an Upgrade
+   header in any response other than 101 or 426 to indicate a
+   willingness to switch to any (combination) of the protocols listed.
+
+4.2 Mandatory Advertisement
+
+   A server MAY indicate that a client request can not be completed
+   without TLS using the "426 Upgrade Required" status code, which MUST
+   include an an Upgrade header field specifying the token of the
+   required TLS version.
+
+       HTTP/1.1 426 Upgrade Required
+       Upgrade: TLS/1.0, HTTP/1.1
+       Connection: Upgrade
+
+   The server SHOULD include a message body in the 426 response which
+   indicates in human readable form the reason for the error and
+   describes any alternative courses which may be available to the user.
+
+   Note that even if a client is willing to use TLS, it must use the
+   operations in Section 3 to proceed; the TLS handshake cannot begin
+   immediately after the 426 response.
+
+
+
+Khare & Lawrence            Standards Track                     [Page 5]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+5. Upgrade across Proxies
+
+   As a hop-by-hop header, Upgrade is negotiated between each pair of
+   HTTP counterparties.  If a User Agent sends a request with an Upgrade
+   header to a proxy, it is requesting a change to the protocol between
+   itself and the proxy, not an end-to-end change.
+
+   Since TLS, in particular, requires end-to-end connectivity to provide
+   authentication and prevent man-in-the-middle attacks, this memo
+   specifies the CONNECT method to establish a tunnel across proxies.
+
+   Once a tunnel is established, any of the operations in Section 3 can
+   be used to establish a TLS connection.
+
+5.1 Implications of Hop By Hop Upgrade
+
+   If an origin server receives an Upgrade header from a proxy and
+   responds with a 101 Switching Protocols response, it is changing the
+   protocol only on the connection between the proxy and itself.
+   Similarly, a proxy might return a 101 response to its client to
+   change the protocol on that connection independently of the protocols
+   it is using to communicate toward the origin server.
+
+   These scenarios also complicate diagnosis of a 426 response.  Since
+   Upgrade is a hop-by-hop header, a proxy that does not recognize 426
+   might remove the accompanying Upgrade header and prevent the client
+   from determining the required protocol switch.  If a client receives
+   a 426 status without an accompanying Upgrade header, it will need to
+   request an end to end tunnel connection as described in Section 5.2
+   and repeat the request in order to obtain the required upgrade
+   information.
+
+   This hop-by-hop definition of Upgrade was a deliberate choice.  It
+   allows for incremental deployment on either side of proxies, and for
+   optimized protocols between cascaded proxies without the knowledge of
+   the parties that are not a part of the change.
+
+5.2 Requesting a Tunnel with CONNECT
+
+   A CONNECT method requests that a proxy establish a tunnel connection
+   on its behalf. The Request-URI portion of the Request-Line is always
+   an 'authority' as defined by URI Generic Syntax [2], which is to say
+   the host name and port number destination of the requested connection
+   separated by a colon:
+
+      CONNECT server.example.com:80 HTTP/1.1
+      Host: server.example.com:80
+
+
+
+
+Khare & Lawrence            Standards Track                     [Page 6]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+   Other HTTP mechanisms can be used normally with the CONNECT method --
+   except end-to-end protocol Upgrade requests, of course, since the
+   tunnel must be established first.
+
+   For example, proxy authentication might be used to establish the
+   authority to create a tunnel:
+
+      CONNECT server.example.com:80 HTTP/1.1
+      Host: server.example.com:80
+      Proxy-Authorization: basic aGVsbG86d29ybGQ=
+
+   Like any other pipelined HTTP/1.1 request, data to be tunneled may be
+   sent immediately after the blank line. The usual caveats also apply:
+   data may be discarded if the eventual response is negative, and the
+   connection may be reset with no response if more than one TCP segment
+   is outstanding.
+
+5.3 Establishing a Tunnel with CONNECT
+
+   Any successful (2xx) response to a CONNECT request indicates that the
+   proxy has established a connection to the requested host and port,
+   and has switched to tunneling the current connection to that server
+   connection.
+
+   It may be the case that the proxy itself can only reach the requested
+   origin server through another proxy.  In this case, the first proxy
+   SHOULD make a CONNECT request of that next proxy, requesting a tunnel
+   to the authority.  A proxy MUST NOT respond with any 2xx status code
+   unless it has either a direct or tunnel connection established to the
+   authority.
+
+   An origin server which receives a CONNECT request for itself MAY
+   respond with a 2xx status code to indicate that a connection is
+   established.
+
+   If at any point either one of the peers gets disconnected, any
+   outstanding data that came from that peer will be passed to the other
+   one, and after that also the other connection will be terminated by
+   the proxy. If there is outstanding data to that peer undelivered,
+   that data will be discarded.
+
+6. Rationale for the use of a 4xx (client error) Status Code
+
+   Reliable, interoperable negotiation of Upgrade features requires an
+   unambiguous failure signal. The 426 Upgrade Required status code
+   allows a server to definitively state the precise protocol extensions
+   a given resource must be served with.
+
+
+
+
+Khare & Lawrence            Standards Track                     [Page 7]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+   It might at first appear that the response should have been some form
+   of redirection (a 3xx code), by analogy to an old-style redirection
+   to an https: URI.  User agents that do not understand Upgrade:
+   preclude this.
+
+   Suppose that a 3xx code had been assigned for "Upgrade Required"; a
+   user agent that did not recognize it would treat it as 300.  It would
+   then properly look for a "Location" header in the response and
+   attempt to repeat the request at the URL in that header field. Since
+   it did not know to Upgrade to incorporate the TLS layer, it would at
+   best fail again at the new URL.
+
+7. IANA Considerations
+
+   IANA shall create registries for two name spaces, as described in BCP
+   26 [10]:
+
+   o  HTTP Status Codes
+   o  HTTP Upgrade Tokens
+
+7.1 HTTP Status Code Registry
+
+   The HTTP Status Code Registry defines the name space for the Status-
+   Code token in the Status line of an HTTP response.  The initial
+   values for this name space are those specified by:
+
+   1.  Draft Standard for HTTP/1.1 [1]
+   2.  Web Distributed Authoring and Versioning [4] [defines 420-424]
+   3.  WebDAV Advanced Collections [5] (Work in Progress) [defines 425]
+   4.  Section 6 [defines 426]
+
+   Values to be added to this name space SHOULD be subject to review in
+   the form of a standards track document within the IETF Applications
+   Area.  Any such document SHOULD be traceable through statuses of
+   either 'Obsoletes' or 'Updates' to the Draft Standard for
+   HTTP/1.1 [1].
+
+7.2 HTTP Upgrade Token Registry
+
+   The HTTP Upgrade Token Registry defines the name space for product
+   tokens used to identify protocols in the Upgrade HTTP header field.
+   Each registered token should be associated with one or a set of
+   specifications, and with contact information.
+
+   The Draft Standard for HTTP/1.1 [1] specifies that these tokens obey
+   the production for 'product':
+
+
+
+
+
+Khare & Lawrence            Standards Track                     [Page 8]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+      product         = token ["/" product-version]
+      product-version = token
+
+   Registrations should be allowed on a First Come First Served basis as
+   described in BCP 26 [10]. These specifications need not be IETF
+   documents or be subject to IESG review, but should obey the following
+   rules:
+
+   1.  A token, once registered, stays registered forever.
+   2.  The registration MUST name a responsible party for the
+       registration.
+   3.  The registration MUST name a point of contact.
+   4.  The registration MAY name the documentation required for the
+       token.
+   5.  The responsible party MAY change the registration at any time.
+       The IANA will keep a record of all such changes, and make them
+       available upon request.
+   6.  The responsible party for the first registration of a "product"
+       token MUST approve later registrations of a "version" token
+       together with that "product" token before they can be registered.
+   7.  If absolutely required, the IESG MAY reassign the responsibility
+       for a token. This will normally only be used in the case when a
+       responsible party cannot be contacted.
+
+   This specification defines the protocol token "TLS/1.0" as the
+   identifier for the protocol specified by The TLS Protocol [6].
+
+   It is NOT required that specifications for upgrade tokens be made
+   publicly available, but the contact information for the registration
+   SHOULD be.
+
+8. Security Considerations
+
+   The potential for a man-in-the-middle attack (deleting the Upgrade
+   header) remains the same as current, mixed http/https practice:
+
+   o  Removing the Upgrade header is similar to rewriting web pages to
+      change https:// links to http:// links.
+   o  The risk is only present if the server is willing to vend such
+      information over both a secure and an insecure channel in the
+      first place.
+   o  If the client knows for a fact that a server is TLS-compliant, it
+      can insist on it by only sending an Upgrade request with a no-op
+      method like OPTIONS.
+   o  Finally, as the https: specification warns, "users should
+      carefully examine the certificate presented by the server to
+      determine if it meets their expectations".
+
+
+
+
+Khare & Lawrence            Standards Track                     [Page 9]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+   Furthermore, for clients that do not explicitly try to invoke TLS,
+   servers can use the Upgrade header in any response other than 101 or
+   426 to advertise TLS compliance. Since TLS compliance should be
+   considered a feature of the server and not the resource at hand, it
+   should be sufficient to send it once, and let clients cache that
+   fact.
+
+8.1 Implications for the https: URI Scheme
+
+   While nothing in this memo affects the definition of the 'https' URI
+   scheme, widespread adoption of this mechanism for HyperText content
+   could use 'http' to identify both secure and non-secure resources.
+
+   The choice of what security characteristics are required on the
+   connection is left to the client and server.  This allows either
+   party to use any information available in making this determination.
+   For example, user agents may rely on user preference settings or
+   information about the security of the network such as 'TLS required
+   on all POST operations not on my local net', or servers may apply
+   resource access rules such as 'the FORM on this page must be served
+   and submitted using TLS'.
+
+8.2 Security Considerations for CONNECT
+
+   A generic TCP tunnel is fraught with security risks. First, such
+   authorization should be limited to a small number of known ports.
+   The Upgrade: mechanism defined here only requires onward tunneling at
+   port 80. Second, since tunneled data is opaque to the proxy, there
+   are additional risks to tunneling to other well-known or reserved
+   ports. A putative HTTP client CONNECTing to port 25 could relay spam
+   via SMTP, for example.
+
+References
+
+   [1]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
+        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
+        HTTP/1.1", RFC 2616, June 1999.
+
+   [2]  Berners-Lee, T., Fielding, R. and L. Masinter, "URI Generic
+        Syntax", RFC 2396, August 1998.
+
+   [3]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [4]  Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen,
+        "Web Distributed Authoring and Versioning", RFC 2518, February
+        1999.
+
+
+
+
+
+Khare & Lawrence            Standards Track                    [Page 10]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+   [5]  Slein, J., Whitehead, E.J., et al., "WebDAV Advanced Collections
+        Protocol",  Work In Progress.
+
+   [6]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
+        1999.
+
+   [7]  Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet
+        Printing Protocol/1.0: Encoding and Transport", RFC 2565, April
+        1999.
+
+   [8]  Luotonen, A., "Tunneling TCP based protocols through Web proxy
+        servers",  Work In Progress.  (Also available in: Luotonen, Ari.
+        Web Proxy Servers, Prentice-Hall, 1997 ISBN:0136806120.)
+
+   [9]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
+        1999.
+
+   [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+Authors' Addresses
+
+   Rohit Khare
+   4K Associates / UC Irvine
+   3207 Palo Verde
+   Irvine, CA  92612
+   US
+
+   Phone: +1 626 806 7574
+   EMail: rohit@4K-associates.com
+   URI:   http://www.4K-associates.com/
+
+
+   Scott Lawrence
+   Agranat Systems, Inc.
+   5 Clocktower Place
+   Suite 400
+   Maynard, MA  01754
+   US
+
+   Phone: +1 978 461 0888
+   EMail: lawrence@agranat.com
+   URI:   http://www.agranat.com/
+
+
+
+
+
+Khare & Lawrence            Standards Track                    [Page 11]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 2000
+
+
+Appendix A. Acknowledgments
+
+   The CONNECT method was originally described in a Work in Progress
+   titled, "Tunneling TCP based protocols through Web proxy servers",
+   [8] by Ari Luotonen of Netscape Communications Corporation.  It was
+   widely implemented by HTTP proxies, but was never made a part of any
+   IETF Standards Track document. The method name CONNECT was reserved,
+   but not defined in [1].
+
+   The definition provided here is derived directly from that earlier
+   memo, with some editorial changes and conformance to the stylistic
+   conventions since established in other HTTP specifications.
+
+   Additional Thanks to:
+
+   o  Paul Hoffman for his work on the STARTTLS command extension for
+      ESMTP.
+   o  Roy Fielding for assistance with the rationale behind Upgrade:
+      and its interaction with OPTIONS.
+   o  Eric Rescorla for his work on standardizing the existing https:
+      practice to compare with.
+   o  Marshall Rose, for the xml2rfc document type description and tools
+      [9].
+   o  Jim Whitehead, for sorting out the current range of available HTTP
+      status codes.
+   o  Henrik Frystyk Nielsen, whose work on the Mandatory extension
+      mechanism pointed out a hop-by-hop Upgrade still requires
+      tunneling.
+   o  Harald Alvestrand for improvements to the token registration
+      rules.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Khare & Lawrence            Standards Track                    [Page 12]
+
+RFC 2817                  HTTP Upgrade to TLS                   May 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Khare & Lawrence            Standards Track                    [Page 13]
+