view Side-By-Side changes

Date: Tue, 09 Apr 2002 06:19:05 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Mon, 11 Oct 1999 13:33:00 GMT
ETag: "304bdf-12b5c-3801e70c"
Accept-Ranges: bytes
Content-Length: 76636
Connection: close
Content-Type: text/plain

PKIX Working Group                                                   SSE
expires                                          S. Farrell
INTERNET-DRAFT                                  Baltimore Technologies
Expires in six months                                       R. Housley
                                                                  Spryus
                                                              April
                                                                SPYRUS
                                                          October 1999

                     An Internet AttributeCertificate Attribute Certificate
                         Profile for Authorization
                               
              <draft-ietf-pkix-ac509prof-00.txt>
                   <draft-ietf-pkix-ac509prof-01.txt>


Status of this memo Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. [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. 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 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.

   <<Comments are contained in angle brackets like this.>>

Abstract

   Authorization support is services are required for various numerous Internet protocols, for example,
   including TLS, CMS IPSec, and their consumers,
   and others. S/MIME. The X.509 AttributeCertificate Attribute Certificate
   provides a structure that can form the basis for such services
   ([X.509], [XPDAM]).
   [X.509]. This specification defines two
   profiles (basic and proxiable) a profile for the use of X.509 
   AttributeCertificates
   Attribute Certificates to provide such authorization
   services. services for
   Internet protocols. Some optional features are also specified which
   are not required for conformance to the base profile.

Table of Contents


   Status of this Memo.............................................1
   Abstract........................................................1
   Table of Contents...............................................1
   1. Introduction.................................................3
   2. Terminology..................................................5
   3. Requirements.................................................6
   4. The AC Profile...............................................7



Farrell & Housley                                             [Page 1]


INTERNET-DRAFT                                                  April                                            October 1999


       4.1  X.509 Attribute Certificate Definition.................7
       4.2  Object Identifiers.....................................8
       4.3  Profile of Standard Fields.............................9
           4.3.1  version..........................................9
           4.3.2  owner...........................................10
           4.3.3  issuer..........................................10
           4.3.4  signature.......................................10
           4.3.5  serialNumber....................................11
           4.3.6  attrCertValidityPeriod..........................11
           4.3.7  attributes......................................12
           4.3.8  issuerUniqueID..................................12
           4.3.9  extensions......................................12
       4.4  Extensions............................................12
           4.4.1  Audit Identity..................................12
           4.4.2  AC Targeting....................................13
           4.4.3  authorityKeyIdentifier..........................14
           4.4.4  authorityInformationAccess......................14
           4.4.5  crlDistributionPoints...........................15
       4.5  Attribute Types.......................................15
           4.5.1  Service Authentication Info.....................16
           4.5.2  Access Identity.................................16
           4.5.3  Charging Identity...............................16
           4.5.4  Group...........................................17
           4.5.5  Role............................................17
           4.5.6  Clearance.......................................17
       4.6  PKC Extensions........................................18
           4.6.1  AAControls......................................18
       4.7  Profile of AC Issuer's PKC............................19
   5. Attribute Certificate Validation............................19
   6. Revocation..................................................21
           6.1.1  "Never revoke" method...........................21
           6.1.2  "Pointer from above" method.....................22
           6.1.3  "Pointer in AC" method..........................22
   7. Optional Features...........................................22
       7.1  Attribute Encryption..................................22
       7.2  Proxying..............................................23
       7.3  Use of ObjectDigestInfo...............................25
       7.4  AC Chaining...........................................26
   8. Security Considerations.....................................27
   9. References..................................................27
   Author's Addresses.............................................28
   Full Copyright Statement.......................................28
   Appendix A: "Compilable" ASN.1 Module..........................29
   Appendix B: Samples............................................32
   Appendix C: Changes this version / Open Issues.................32



Farrell & Housley                                             [Page 2]


INTERNET-DRAFT                                            October 1999



1. Introduction

   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
   in this document are to be interpreted as described in [RFC2119].

   A server makes an access control decision when a client requests
   access to a resource offered by that server. The server must ensure
   that the client is authorized to access that resource. The provision server
   decision is based on the access control policy, the context of authentication, data integrity the
   request, and
   confidentiality services for current Internet protocols
   is well understood the identity and many secure transports are defined
   (e.g. TLS, IPSEC, etc.). In many applications these
   services authorizations of the client. The
   access control policy and the context of the request are not sufficient (or too cumbersome readily
   available to
   administer) the server. Certificates may be used to provide the type of
   identity and authorization services
   required.

   [RFC2459] specifies a profile for information about the use of client.

   Similar access control decisions are made in other network
   environments, such as a store-and-forward electronic mail
   environment. That is, access control decisions are not limited to
   client-server protocol environments.

   X.509 public key certificates in Internet protocols. This type of
   certificate is typically used as (PKCs) [X.509],[RFC2459] bind an "identity"
   certificate, that is, it contains a certified name
   identity and a public key, and any entity key. The identity may be used to support
   identity-based access control decisions after the client proves that can use
   it has access to the corresponding private key that corresponds to the public key
   contained in the PKC. The public key is used to validate digital
   signatures or cryptographic key management operations. However, not
   all access control decisions are identity-based. Rule-based, role-
   based, and rank-based access control decisions require additional
   information. For example, information about a client's ability to
   pay for a resource access may be more important than the client's
   identity. Authorization information to support such access control
   decisions may be placed in a PKC extension or placed in a separate
   attribute certificate (AC).

   The placement of authorization information in PKCs is treated usually
   undesirable for two reasons. First, authorization information does
   not have the same lifetime as the named entity. binding of the identity and the
   public key. When considering authorization, one authorization information is often less
   interested placed in a PKC
   extension, the identity general result is the shortening of the entity than PKC useful
   lifetime. Second, the PKC issuer is not usually authoritative for
   the authorization information. This results in some
   other attributes, (e.g. roles, account limits etc.),
   which should be used additional steps for
   the PKC issuer to make an obtain authorization decision.

   In many such cases, information from the
   authoritative source.

   For these reasons, it is often better to separate this authorization
   information from the identity for management, security,
   interoperability or other reasons. However, PKC. Yet, this authorization information also
   needs to be protected in a fashion similar to a public key certificate - the name
   for the structure used is an PKC. An attribute
   certificate (an
   AC) which (AC) provides this protection, and it is simply a
   digitally signed (certified) (or certified) set of attributes.

   An AC is a structure that is similar to an X.509 public
   key certificate [RFC2459] with a PKC; the main difference being
   that it contains no public key. The An AC typically contains may contain attributes that
   specify group membership, role, clearance security clearance, and other access

Farrell & Housley                                             [Page 3]


INTERNET-DRAFT                                            October 1999


   control information associated with the AC owner. The
   base syntax for ACs the
   AC is also defined in the Recommendation X.509 standard (making the term X.509 certificate ambiguous!). "X.509
   certificate" ambiguous). This document specifies a profile of the
   X.509 AC suitable for use with authorization purposes in information within
   Internet protocols.






Farrell & Housley                                                [Page  2]


INTERNET-DRAFT                                                  April 1999

   When making an access control decision based on an AC, an access
   control decision function may need to ensure that the appropriate AC
   owner is the entity that has requested access. For example, one way
   in which the linkage between the request and the AC can be achieved
   is if the AC has a "pointer" to a PKC for the requestor requester and that PKC
   has been used to authenticate the access request.

   As there is often confusion about the difference between
   public key certificates (PKCs) PKCs and attribute certificates
   (ACs),
   ACs, an analogy may help. A PKC can be considered to be like a
   passport: it identifies the owner, tends to last for a long period time and shouldn't
   should not be too easy trivial to get. obtain. An AC is more like an entry visa in that visa:
   it is typically issued by a different authority and doesn't does not last
   for as long. long a time. As acquiring an entry visa typically requires
   presenting a passport, getting a visa can be a simpler process.

   In conjunction with authentication services services, ACs provide a means to transport
   securely provide authorization information securely to applications. However,
   there are a number of possible communication paths that an AC may take:
   take.

   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 domains are required. It also means that no search burden is imposed
   on servers, which improves performance.

   In other cases cases, it is more suitable for a client simply to
   authenticate to the server and for the server to request ("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 and
   client/server or client-server protocol. It is also more suitable for
   some inter-domain cases where the client's rights should be assigned
   within the server's domain, rather than within the client's "home"
   domain.

   There are a number of possible exchanges that can occur and three
   entities involved (client, server and AC issuer). In addition the
   use of a directory service or other repository for AC retrieval MAY
   be supported.










Farrell & Housley                                             [Page  3] 4]


INTERNET-DRAFT                                                  April                                            October 1999

   The diagram below



   Figure 1 shows an abstract view of the exchanges that may involve
   ACs. This profile does not specify protocol for all of these exchanges, though a limited
   case of client and server acquisition is defined below. exchanges.


      +--------------+                        +---------------+
   |              |
      |              |        Server Acquisition
      |  AC Issuer    +----+                   | Repository   +----------------------------+
      |              |                            |
      +--+-----------+                            |
         |                                        |
   +--+-----------+
         | Server            +-------+-------+ Client                                 |
         | Acquisition                            |
      |Client          |                           |Server
      |Acquisition     +----------------------+    |Lookup
      |
         |                                        |
      +--+-----------+                        +--+----+-------+                         +--+------------+
      |              |       AC "push"         |               |
      |   Client       +------------------------+     +-------------------------+    Server     |
      |              | (part of app. protocol)| protocol) |               |
      +--+-----------+                         +--+------------+
         |
   +--------------+                        +---------------+                                        |
         | Client                                 | Server
         | Lookup        +--------------+         | Lookup
   +--+-----------+
         |               |              |         |
         +---------------+  Repository  +---------+
                         |              |
                         +--------------+

                     Figure 1: AC Exchanges
   |              |
   +--------------+

   The remainder of the document is structured as follows:-

   Section 2 defines some terminology
   Section 3 specifies the requirements that this profile is 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 a limited AC acquisition protocol
   Section 8 contains a optional features which MAY be supported but for
   which support is not required for conformance statement to this profile

   Appendices contain samples, a "compilable" ASN.1 module for this specification
   specification, samples and a list of changes and open issues.

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, e.g. in the S/MIME v3
   context, the mail user agent would, by turns, be both "client" and
   "server" in the sense the terms are used here.

    Term          Meaning

    AA            Attribute Authority, the entity that issues the

Farrell & Housley                                             [Page 5]


INTERNET-DRAFT                                            October 1999


                   AC, synonymous in this specification with "AC
                   issuer"
    AC             AttributeCertificate            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

Farrell & Housley                                                [Page  4]


INTERNET-DRAFT                                                  April 1999 AC, synonymous in this
                   specification with "AA"
    AC owner      the entity indicated (perhaps indirectly) in the subject
                   owner field of the AC
    Client        the entity which is requesting the action for
                   which authorization checks are to be made
   LAAP           Limited AC Acquisition Protocol
   LRP            LAAP responder
   LRQ            LAAP requestor
    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

3. Requirements

   The following are the requirements that the "full"

   This Attribute Certificate profile defined here meets. meets the following requirements.

   Time/Validity requirements:

   1.   Support for short-lived or long-lived ACs is required. Typical
        validity periods might be measured in hours, as opposed to
        months for X.509 public key certificates. Short validity
        periods mean that ACs can be useful without a revocation scheme.
        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, for example "access identity", "group",
        "role", "clearance", "audit identity", "charging id" etc.
   4.   Standard attribute types should be defined so that it is
        possible for an AC verifier to distinguish between e.g. the
        "Administrators group" as defined by SSE Baltimore and the
        "Administrators group" as defined by Widgets inc.
   5.   ACs should support the encryption SPYRUS.

   Targeting of some, or all,
        attributes (e.g. passwords for legacy applications). It
        should be possible for such an encrypted attribute to be

Farrell & Housley                                                [Page  5]


INTERNET-DRAFT                                                  April 1999

        deciphered by an appropriate AC verifier even where the
        AC has not been received directly from the AC owner (i.e.
        where the AC is proxied).

   Targeting of ACs:

   6. ACs:

   5.   It should be possible to "target" an AC. This means that a
        given AC may be "targeted" at one, or a small number of,
        servers/services


Farrell & Housley                                             [Page 6]


INTERNET-DRAFT                                            October 1999


        servers in the sense that a trustworthy non- target will reject
        the AC for authorization decisions.

   Proxying:

   7.   It should be possible for a server to proxy an AC
        when it acts as a client (for another server) on behalf
        of the AC owner.
   8.   Proxying should be 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.
   9.   Support for chains of proxies (with more than one
        intermediate server) is required.


   Push vs. Pull

   10.

   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 (whether the AC issuer or (which may be an online repository).

   This profile specifically imposes no requirements for:

   1.   The meaning of a chain of ACs
   2. AC translation

   Support for such features may be part of some other
   profile.















Farrell & Housley                                                [Page  6]


INTERNET-DRAFT                                                  April 1999
        issuer).

4. The AC Profile

   This section specifies the presents a profile of the X.509 AC which for attribute certificates that will
   foster interoperability.  This section is to be supported by conforming implementations.

4.1  X.509 AttributeCertificate Definition

   X.509 contains based upon the definition of an AttributeCertificate
   given below. Types that are not X.509
   attribute certificate format defined can be found in
   [RFC2459].

   <<This definition is from [X.509].  The ISO/IEC/ITU
   documents use the PDAM.>>

        AttributeCertificate ::= SIGNED {
             acinfo         AttributeCertificateInfo
        }
        
        AttributeCertificateInfo ::= SEQUENCE { 1993 version   AttCertVersion DEFAULT v1,
             owner     CHOICE{
                  baseCertificateID   [0] IssuerSerial,
                       -- the issuer and serial number of
                       -- ASN.1; while this document uses
   the owner's Public Key Certificate
                  entityName          [1] GeneralNames,
                       -- 1988 ASN.1 syntax, the name of encoded certificate and standard
   extensions are equivalent.  This section also defines private
   extensions for the claimant or role
                  objectDigestInfo    [2] ObjectDigestInfo
                       -- if present, version must Internet community.

   Attribute certificates may be v2
             },
             issuer              CHOICE {
                  baseCertificateId   [0]  IssuerSerial,
                  issuerName          [1]  GeneralNames
             },
             --AA that issued 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 certificate certificates for informal
   Internet electronic mail, IPSec, and WWW applications.

   Conforming implementations MUST support the profile specified in
   this section.

4.1 X.509 Attribute Certificate Definition

   X.509 contains the definition of an Attribute Certificate given
   below. Types that are not defined can be found in [RFC2459].

           AttributeCertificate ::= SEQUENCE {
                acinfo               AttributeCertificateInfo
                signatureAlgorithm   AlgorithmIdentifier,
                signatureValue       BIT STRING
           }

           AttributeCertificateInfo ::= SEQUENCE {
                version        AttCertVersion DEFAULT v1,
                owner          Owner,
                issuer         AttCertIssuer,
                signature      AlgorithmIdentifier,
                serialNumber   CertificateSerialNumber,
                attrCertValidityPeriod   AttCertValidityPeriod
                attributes     SEQUENCE OF Attribute,
                issuerUniqueID UniqueIdentifier OPTIONAL,

Farrell & Housley                                             [Page 7]


INTERNET-DRAFT                                            October 1999


                extensions     Extensions     OPTIONAL
           }

           AttCertVersion ::= INTEGER {v1(0), v2(1) }

           Owner ::= SEQUENCE {
                     baseCertificateID   [0] IssuerSerial OPTIONAL,
                          -- the issuer and serial number of
                          -- the owner'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 {
                digestAlgorithm     AlgorithmIdentifier,
                objectDigest        OCTET STRING
           }

           AttCertIssuer ::= SEQUENCE {
                     issuerName              GeneralNames  OPTIONAL,
                     baseCertificateId   [0] IssuerSerial OPTIONAL
           }

           IssuerSerial  ::=  SEQUENCE {
                issuer         GeneralNames,

Farrell & Housley                                                [Page  7]


INTERNET-DRAFT                                                  April 1999
                serial         CertificateSerialNumber,
                issuerUID      UniqueIdentifier OPTIONAL
           }

           AttCertValidityPeriod  ::= SEQUENCE {
                notBeforeTime  GeneralizedTime,
                notAfterTime   GeneralizedTime
           }

4.2 Object Identifiers

   This section 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.

   The following OIDs are used:

   <<
   for interop testing purposes the SSE OID sse-ac-tst may
   be used instead of ietf-ac.
   sse-id imported from [RFC2459]:

      id-pkix OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 1201 iso(1) identified-organization(3)
                dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
   sse-ac-tst
      id-mod  OBJECT IDENTIFIER ::= { sse-id 56 id-pkix 0 }
   >>

   ietf-ac             OBJECT IDENTIFIER ::= <<tbs>>
   ietf-ac-extensions
      id-pe   OBJECT IDENTIFIER ::= { ietf-ac 1}
   ietf-ac-attributes id-pkix 1 }
      id-ad   OBJECT IDENTIFIER ::= { ietf-ac 2}

4.3  Profile of Standard Fields.

   For all GeneralName fields in this id-pkix 48 }

   The following new ASN.1 module OID is defined:


Farrell & Housley                                             [Page 8]


INTERNET-DRAFT                                            October 1999


      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-targeting           OBJECT IDENTIFIER ::= { id-pe 5 }
      id-pe-ac-proxying            OBJECT IDENTIFIER ::= { id-pe 7 }

   The following registeredID form of name for targets and proxies is
   defined (see section 4.4.2 below):

      id-pe-ac-targeting-all       OBJECT IDENTIIFIER ::=
                                       { id-pe-ac-targeting 1 }

   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-role                  OBJECT IDENTIFIER ::= { id-aca 5 }
      id-aca-encAttrs              OBJECT IDENTIFIER ::= { id-aca 6 }

   The following new access methods for an authorityInfoAccess
   extension are defined:

      id-ad-noRevStat              OBJECT IDENTIFIER ::= { id-ad 3 }
      id-ad-acRevStatusLocation    OBJECT IDENTIFIER ::= { id-ad 4 }

4.3 Profile of Standard Fields

   For all GeneralName fields in this profile the otherName,
   x400Address, ediPartyName and registeredId registeredID options MUST NOT be used
   unless otherwise specified (e.g. as in the description of targeting
   extension).

   This means that conforming implementations MUST be able to support
   the dNSName, directoryName, uniformResourceIdentifier and iPAddress
   fields in all cases where GeneralName is used. The MUST support
   requirements for each of these fields are as specified in [RFC2459],
   (mainly in section 4.2.1.7).

4.3.1   version

   This must be the default value of v1, i.e. not present in
   encoding.

   <<If we allow objectDigest then encoding,
   except where the above will have to
   change. There's also a comment to owner is identified using the PDAM which may
   cause a change here.>> optional
   objectDigestInfo field, as specified in section 7.3.


Farrell & Housley                                             [Page 9]


INTERNET-DRAFT                                            October 1999


4.3.2   owner

   For any protocol where the AC is passed in an authenticated message
   or session, and where the authentication is based on the use of an
   X.509 public key certificate (PKC), the owner field MUST SHOULD use the
   baseCertificateID.

   With the baseCertificateID option, the owner's PKC serialNumber and
   issuer MUST be identical to the AC owner

Farrell & Housley                                                [Page  8]


INTERNET-DRAFT                                                  April 1999 field. The PKC issuer MUST
   have a non-NULL X.500 name which is to be present as the single
   value of the of the
   owner.issuerSerial.issuer owner.baseCertificateID.issuer construct in the
   directoryName field. The owner.issuerSerial.issuerUID owner.baseCertificateID.issuerUID field
   MUST only be used if the owner's PKC contains an issuerUniqueID
   field.

   The above means that the baseCertificateID is only usable with PKC
   profiles (like RFC2459) which mandate that the PKC issuer field
   contain a value.

   If the owner 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, or, if the PKC subject is a "NULL"
   DN, then the entityName field MUST be identical to one of the values
   of the PKC subjectAltName field extension. Note that [RFC2459]
   mandates that the subjectAltNames extension be present if the PKC
   subject is a "NULL" DN.

   In any other case where the owner field uses the entityName option
   then only one name SHOULD be present.

   AC's

   Implementations conforming to this profile MUST NOT are not required to
   support the use of the objectDigest field.

   <<Uses of objectDigest are for further study.>> However, section 7.3
   specifies how this optional feature MAY be used.

   Any protocol conforming to this profile SHOULD specify which AC subject
   owner option is to be used and how this fits with e.g. peer-entity
   authentication in the protocol.

4.3.3   issuer

   ACs conforming to this profile MUST use the issuerName
   choice choice, which
   MUST contain one and only one GeneralName GeneralName, which MUST contain its
   non-null value in the directoryName field. This means that all AC
   issuers MUST have non-NULL X.500 names.

   Part of the reason for the use of the issuerName field is that it
   allows the AC verifier to be independent of the AC issuer's public
   key infrastructure. Using the baseCertificateId field to reference
   the AC issuer would mean that the AC verifier would have such a
   dependency.

4.3.4   signature


Farrell & Housley                                            [Page 10]


INTERNET-DRAFT                                            October 1999


   Contains the algorithm identifier used to validate the AC signature.

Farrell & Housley                                                [Page  9]


INTERNET-DRAFT                                                  April 1999

   This MUST be one of the following algorithms defined in [RFC2459]
   section 7.2: md5WithRSAEncryption, id-dsa-with-
   sha1 id-dsa-with-sha1 or sha-
   1WithRSAEncryption, or sha-1WithRSAEncryption. ecdsa-with-SHA1 defined in [ECDSA] section
   3.2.

   id-dsa-with-sha1 MUST be supported by all AC users. The other
   algorithms SHOULD be supported.

4.3.5   serialNumber

   For any conforming AC, the issuer/serialNumber pair MUST form a
   unique combination, even if ACs are very short-
   lived short-lived (one second is
   the shortest possible validity due to the use of GeneralizedTime).

   AC issuers MUST force the serialNumber to be a positive integer,
   that is, the topmost bit in the DER encoding of the INTEGER value
   MUST NOT be a `1'B - this is to 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 a serialNumber.

   Given the uniqueness and timing requirements above serial numbers
   can be expected to contain long integers, i.e. AC users MUST be able
   to handle more than 32 bit integers here.

   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.

4.3.6   attrCertValidityPeriod

   The attrCertValidityPeriod (a.k.a. validity) field specifies the
   period for which the AC issuer expects that the binding between the
   owner and the attributes fields will be valid.

   The generalized time type, GeneralizedTime, is a standard ASN.1 type
   for variable precision representation of time.  Optionally, the
   GeneralizedTime encoding field can include a representation of the time
   differential between local and Greenwich Mean Time.

   For the purposes of this profile, GeneralizedTime values MUST be
   expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e.,
   times are YYYYMMDDHHMMSSZ), even where the number of seconds is
   zero. GeneralizedTime values MUST NOT include fractional seconds.

   (Note that the above is restricted as specified in
   [RFC2459] for the corresponding fields in a PKC. [RFC2459], section
   4.1.2.5.2.)

   Note that AC users MUST be able to handle the case where an AC is
   issued, which (at the time of parsing), has its entire validity
   period in the future (a "post-dated" AC). This is valid for some
   applications, e.g. backup.

Farrell & Housley                                            [Page 11]


INTERNET-DRAFT                                            October 1999



4.3.7   attributes

   The attributes field gives information about the AC owner. When the
   AC is used for authorization this will

Farrell & Housley                                                [Page 10]


INTERNET-DRAFT                                                  April 1999 often contain a set of
   privileges. However, authorization
   may also require support for "restrictions" - these are
   not carried within the attributes field (though they
   "belong" to the AC owner) but in the extensions field.

   The attributes field contains a SEQUENCE OF Attribute. For a given
   AC each attribute type in the sequence MUST be unique, that is, only
   one instance of each attribute type can occur in a single AC. Each
   instance can however, be multi-valued.

   AC consumers users MUST be able to handle multiple values for all attribute
   types.

   Note that a conforming AC MAY contain an empty SEQUENCE, that is, no
   attributes at all. <<Note: This is no longer required since we've
   dropped support for restrictions, so it will disappear in the next
   revision unless there's an explicit consensus for keeping it.>>

   Some standard attribute types are defined in section 4.5.

4.3.8   issuerUniqueID

   This field MUST NOT be used.

4.3.9   extensions

   The extensions field generally gives information about the AC as
   opposed to information about the AC owner. The
   exception is where restrictions are to be supported. If
   one regards a restriction as a qualification on a
   privilege then it is clear that restrictions must be
   implemented as a critical extension.

   Section 4.4 defines the extensions that MAY be used with this
   profile. An AC that has no extensions conforms to the profile. If
   any other critical extension is used, then the AC does not conform
   to this profile. An AC that contains additional non-critical
   extensions still conforms.

4.4 Extensions.

4.4.1     Restrictions

   <<The authors solicit comment on whether support for
   restrictions is needed. The benefit   Audit Identity

   In some circumstances it is required (e.g. by data protection/data
   privacy legislation) that they audit trails do not contain records which
   directly identify individuals. This may
   allow the "positive" privilege syntax to be standardised
   more widely under make the assumption that use of the corresponding
   restriction syntax need only be understood "locally". On
   the other hand, we can omit this entirely if not many
   people see any benefit.>>

Farrell & Housley                                                [Page 11]


INTERNET-DRAFT                                                  April 1999

   A restriction is a "negative" privilege, for example an
   AC may "state" that the AC owner is a member of the
   administrative group except for purposes of backup.
   Restrictions would more properly be implemented as a
   separate field of the AC, but with the current syntax can
   only be supported via the use of a critical extension.

   The value of this extension will be a SEQUENCE OF
   Attribute. The rule stated above for the AC attributes
   field (only one instance of each type etc.) applies here
   also.

   Each restriction MUST correspond to one attribute present
   in the attributes field and must use the same attrType
   OID as the related attribute.

   name           ietf-ac-restrictions
   OID            { ietf-ac-extensions 1 }
   syntax         SEQUENCE OF Attribute
   criticality    MUST be TRUE

4.4.2     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 may make the use of the owner field of owner
   field of the AC unsuitable for use in audit trails.

   In order to allow for such cases an AC MAY contain an audit identity
   extension. Ideally it SHOULD be infeasible to derive the AC owner's
   identity from the audit identity value except with the co-operation
   of the AC issuer.

   The value of the audit identity plus the AC issuer/serial should
   then be used for audit/logging purposes. If the value of the audit

Farrell & Housley                                            [Page 12]


INTERNET-DRAFT                                            October 1999


   identity is suitably chosen then a server/service administrator can
   track the behaviour behavior of an AC owner without being able to identify the
   AC owner.

   The server/service administrator in combination with the AC issuer
   MUST be able to identify the AC owner in cases where mis-behaviour misbehavior is
   detected. This means that the AC issuer MUST be able to map
   "backwards" from the audit identity to the actual identity of the AC
   owner.

   Of course, auditing could be based on the AC issuer/serial pair,
   however, this method doesn't allow tracking the same AC owner across
   different ACs. This means that an audit identity is only useful if
   it lasts

Farrell & Housley                                                [Page 12]


INTERNET-DRAFT                                                  April 1999 for longer than the typical AC lifetime - how much longer
   is an issue for the AC issuer implementation. Auditing could also be
   based on the AC owner's PKC issuer/serial however, this will often
   allow the server/service administrator identify the AC owner.

   As the AC verifier might otherwise use the AC subject 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
   owner 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 are "semi-anonymous".

      name           ietf-ac-auditId           id-pe-ac-auditIdentity
      OID            { ietf-ac-extensions 3 id-pe 4 }
      syntax         OCTET STRING
      criticality    must be TRUE

4.4.3

4.4.2   AC Targeting and Proxying

   In order to allow that an AC is "targeted" and to control
   proxying, "targeted", the proxy target information
   extension 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
   proxiable. Any server which receives the AC such that the
   owner and the authenticated peer-entity do not match MUST
   reject the AC.

   When this extension is present we are essentially
   checking that the entity from which the AC was received
   was allowed to send it targeted and that the AC is allowed to may
   be
   used accepted by this recipient. any server.

   The targeting information simply consists of the direct
   information (targets field) and an optional set a list of proxy
   information (proxies field). If the "direct check" named targets
   or any
   of the "proxy" checks (see below) pass then the
   "targeting check" as a whole is successful.

   The effect is that the AC owner can send to any valid
   target which can then only proxy to targets which are in
   one of the same "proxy sets" as itself.


Farrell & Housley                                                [Page 13]


INTERNET-DRAFT                                                  April 1999 groups.

   The following data structure syntax is used to represent the
   targeting/proxying information.

       ProxyInfo ::= SEQUENCE {
            owner     CHOICE {
                 baseCertificateID   [0]  IssuerSerial,
                 subjectName         [1]  GeneralNames,
                 objectDigestInfo    [2]  ObjectDigestInfo
            },
            targets   [0]  Targets             OPTIONAL,
            proxies   [1]  SEQUENCE OF Targets OPTIONAL
       } targeting information:

          Targets ::= SEQUENCE OF Target
          Target ::= CHOICE {
               targetName          [0] GeneralName,
               targetGroup         [1] GeneralName
          }
       
   Where no proxies or targets are present then the entire
   field MUST be omitted, that is, a zero-length sequence of
   Targets MUST NOT be present. There MUST be at least one
   target or one proxy present, that is, one of the targets
   or proxies fields MUST be present.

Farrell & Housley                                            [Page 13]


INTERNET-DRAFT                                            October 1999



   We represent a special target, called "ALL" which is a wildcard as a
   targetName with the registeredID choice and a value of {ietf-ac-extensions 4 {id-pe-ac-
   targeting 1}. This is an exception to the general rule stated above
   about the use of GeneralName choices.

   The direct targets check passes if:

                the identity of the client as established by the
        underlying authentication service matches the owner
        field
        and
        (
            the targets field contains one targetName which
                is the "ALL" value
             or value,
                or,
                the current server (recipient) is one of the
                targetName fields in the targets part
             or part,
                or,
                the current server is a member of one of the
                targetGroup fields in the targets part.
        )

   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 targetGroup's to

Farrell & Housley                                                [Page 14]


INTERNET-DRAFT                                                  April 1999 which it belongs or can otherwise
   determine its membership. For example, if the targetGroup were to be
   a DNS domain and the AC verifier knows the DNS domain to which it
   belongs or it the targetGroup were "PRINTERS" and the AC verifier
   "knows" that it's a printer or print server.

   A proxy check succeeds if

        (
             the identity of the sender as established by
             the underlying authentication service matches
             the owner field
             and
             (
                  the current server "matches" any one of
                  the proxy sets (where "matches" is

      name           id-pe-ac-targeting
      OID            { id-pe 5 }
      syntax         Targets
      criticality    must be TRUE



4.4.3   authorityKeyIdentifier

   The authorityKeyIdentifier extension as for profiled in [RFC2459] MAY be
   used to assist the direct check above)
             )
        )
        or
        ( AC verifier in checking the identity signature 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".
             )
        )

   Where 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 owner. 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           ietf-ac-targeting
   OID            { ietf-ac-extensions 4 }
   syntax         ProxyInfo
   criticality    must be TRUE



Farrell & Housley                                                [Page 15]


INTERNET-DRAFT                                                  April 1999

4.4.4     authorityKeyIdentifier

   The authorityKeyIdentifier extension as profiled in
   [RFC2459] MAY be used to assist the AC verifier in
   checking the signature of the AC. The [RFC2459]
   description should be read AC.
   The [RFC2459] description should be read as if "CA" meant "AC
   issuer". As with PKCs this extension SHOULD be included in ACs.

      name           id-ce-authorityKeyIdentifier
      OID            { id-ce 35 }
      syntax         AuthorityKeyIdentifier
      criticality    MUST be FALSE

4.4.5

4.4.4   authorityInformationAccess

   The authorityInformationAccess extension as profiled in [RFC2459]
   MAY be used to assist the AC verifier in checking the revocation
   status of the AC. See section 6 on revocation below for details.

   The following accessMethod is used to indicate that revocation
   status checking is not provided for this AC:

   ietf-ac-norevstat


Farrell & Housley                                            [Page 14]


INTERNET-DRAFT                                            October 1999


      id-ad-noRevStat OBJECT IDENTIFIER ::=
                               { id-ad 3 }

   The following accessMethod is used to indicate that revocation
   status checking is provided for this AC, using the OCSP protocol
   defined in [RFC2560]:

      id-ad-ocsp OBJECT IDENTIFIER ::=
                               { id-ad 1 }

   The following accessMethod is used to indicate that revocation
   status checking is provided "below" this PKC or AC:

      id-ad-acRevStatusLocation OBJECT IDENTIFIER ::=
                               { ietf-ac-extensions 5} id-ad 4 }


   The accessLocation field MUST contain a NULL directoryName.

      name           id-ce-authorityInfoAccess
      OID            { id-pe 1 }
      syntax         AuthorityInfoAccessSyntax
      criticality    MUST be TRUE


4.5  Attribute Types

   Some of


4.4.5   crlDistributionPoints

   The crlDistributionPoints extension as profiled in [RFC2459] MAY be
   used to assist the attribute AC verifier in checking the revocation status of
   the AC. See section 6 on revocation below for details.

      name           id-ce-cRLDistributionPoints
      OID            { id-ce 31 }
      syntax         CRLDistPointsSyntax
      criticality    SHOULD be FALSE


4.5 Attribute Types

   Some of the attribute types defined below make use of the
   IetfAttrSyntax type 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 organisation) organization) allocates attribute
        values, but where multiple AC issuers are deployed for
        performance, network or other reasons.
   2.   It allows the type of the attribute (privilege,
        restriction) to be made explicit which helps server
        implementations that provide an API on top of an AC
        validation module.

Farrell & Housley                                                [Page 16]


INTERNET-DRAFT                                                  April 1999

   3.   The syntaxes allowed for values are restricted to OCTET STRING
        and OID, which reduces some of the matching complexities
        associated with GeneralName.

   <<The authors solicit comment on whether All multi-valued attributes using
        this flexibility
   is required. The alternative would be to encourage the syntax are restricted so that each value MUST use the same


Farrell & Housley                                            [Page 15]


INTERNET-DRAFT                                            October 1999


        choice of attributes which have value syntax, that is, it is not allowed that one
        value use an OID but that a GeneralName syntax and to
   mandate this for role/group etc..>> second value uses a string.

           IetfAttrSyntax ::= SEQUENCE OF SEQUENCE {
             type      INTEGER {
                                 privilege(0),
                                 restriction(1),
                                 other(2)
                      }
                       DEFAULT privilege,
                policyAuthority[0] GeneralNames    OPTIONAL,
                values         SEQUENCE OF CHOICE {
                              octets    OCTET STRING,
                              oid       OBJECT IDENTIFIER IDENTIFIER,
                              string    UTF8String
               }
           }

4.5.1   Service Authentication Info

   This attribute type identifies the AC owner to the server/service by
   a name and with optional authentication information. Typically this
   will contain a username/password pair for a "legacy" application
   (and hence MAY need to be encrypted).

   This attribute type will typically be encrypted if the authInfo
   field contains sensitive information (e.g. a password).

      name      ietf-ac-authInfo      id-aca-authenticationInfo
      OID       { ietf-ac-attributes 1} id-aca 1 }
      Syntax    SvceAuthInfo
      values:   Multiple allowed

           SvceAuthInfo ::=    SEQUENCE {
                service   GeneralName,
                ident     GeneralName,
                authInfo  OCTET STRING OPTIONAL
           }





Farrell & Housley                                                [Page 17]


INTERNET-DRAFT                                                  April 1999

4.5.2   Access Identity

   An access identity identifies the AC owner to the server/service.
   For this attribute the authInfo field MUST NOT be present.

      name      ietf-ac-accessId      id-aca-accessIdentity
      OID       { ietf-ac-attributes 2} id-aca 2 }
      syntax    SvceAuthInfo
      values:   Multiple allowed

4.5.3   Charging Identity

   This attribute type identifies the AC owner for charging purposes.
   Note that, in general, the charging identity will be different from
   other identities of the owner, for example, when the ownerÆs company
   is to be charged for service.

      name      ietf-ac-chargingId      id-aca-chargingIdentity
      OID       { ietf-ac-attributes 3} id-aca 3 }
      syntax    IetfAttrSyntax

Farrell & Housley                                            [Page 16]


INTERNET-DRAFT                                            October 1999


      values:   Multiple allowed

4.5.4   Group

   This attribute carries information about group memberships of the AC
   owner.

   <<Might it be more useful to define OS-specific group attribute
   types which map to UNIX gids and/or NT SIDs? Even with that,
   application defined groups will be needed - should they use a
   standard group attribute or should appX-group attribute types be
   defined for each?>>

      name      ietf-ac-group      id-aca-group
      OID       { ietf-ac-attributes 4} id-aca 4 }
      syntax    IetfAttrSyntax
      values:   Multiple allowed

4.5.5   Role

   This attribute carries information about role allocations of the AC
   owner.

      name      ietf-ac-role      id-aca-role
      OID       { ietf-ac-attributes 5} id-aca 5 }
      syntax    IetfAttrSyntax
      values:   Multiple allowed





Farrell & Housley                                                [Page 18]


INTERNET-DRAFT                                                  April 1999

4.5.6   Clearance

   This attribute (imported from [X.501]) carries clearance (security labelling)
   labeling) information about the AC owner.

      name      { id-at-clearance }
      OID       { joint-iso-ccitt(2) ds(5) module(1) selected-
      attribute-types(5) clearance (55) }
      syntax    Clearance - imported from [X.5??] [X.501]
      values    Multiple allowed

           Clearance  ::=  SEQUENCE {
                policyId  OBJECT IDENTIFIER,
                classList ClassList DEFAULT {unclassified},
                securityCategories
                          SET OF SecurityCategory  OPTIONAL
           }

           ClassList  ::=  BIT STRING {
                unmarked       (0),
                unclassified   (1),
                restricted     (2)
                confidential   (3),
                secret         (4),
                topSecret      (5)

Farrell & Housley                                            [Page 17]


INTERNET-DRAFT                                            October 1999


           }

           SecurityCategory ::= SEQUENCE {
                type      [0]  IMPLICIT OBJECT IDENTIFIER,
                value     [1]  ANY DEFINED BY type
           }

           -- original syntax with MACRO
           -- <<is the above equivalent??>>
           -- 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

4.5.7     EncryptedAttributes

   Where an

4.6 PKC Extensions

   Public key certificate extensions which assist in AC will be carried handling are
   defined in clear within an
   application protocol or where an this section. At the moment only one new extension is
   defined.

4.6.1   AAControls

   During AC contains some
   sensitive information (e.g. validation a legacy application
   username/password) then encryption of relying party has to answer the question "is
   this AC attributes issuer trusted to issue ACs containing this attribute"? The
   AAControls PKC extension, intended to be used in CA and AC Issuer
   PKCs, MAY be needed.

   When a set of attributes are used to be encrypted within an
   AC, help answer the cryptographic message syntax, EnvelopedData
   structure [CMS] question. The use of AAControls
   is further described in section 5.


         id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 }

         aaControls EXTENSION ::= {
            SYNTAX         AAControls
            IDENTIFIED BY  { id-pe-aaControls}
         }
         AAControls ::= SEQUENCE {
            pathLenConstraint   INTEGER (0..MAX) OPTIONAL,
            permittedAttrs      [0] AttrSpec OPTIONAL,
            excludedAttrs       [1] AttrSpec OPTIONAL,
            permitUnSpecified   BOOLEAN DEFAULT TRUE
         }
         AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER

   The aaControls extension is used to carry as follows:

   The pathLenConstraint if present is interpreted as in [RFC2459], but
   now restricts the ciphertext(s) and
   associated per-recipient keying information. allowed "distance" between the AA CA, (a CA

Farrell & Housley                                            [Page 19] 18]


INTERNET-DRAFT                                                  April                                            October 1999

   This type


   directly trusted to include AAControls in its PKCs), and the AC
   issuer.

   The permittedAttrs field specifies a set of attribute encryption is targeted which means types that before the any
   AC issuer below this AA CA is signed allowed to include in ACs. If this
   field is not present, it means that no attribute types are
   explicitly allowed (though the attributes have been
   encrypted for permitUnSpecified field may open
   things up).

   The excludedAttrs field specifies a set of predetermined recipients.

   The attribute types that no
   AC then contains the ciphertext(s) inside its signed
   data. The "enveloped-data" (id-envelopedData) ContentType issuer is
   used and the content allowed to include in ACs. If this field will contain is not
   present, it means that no attribute types are explicitly disallowed
   (though the EnvelopedData
   type.

   Only one encryptedAttributes permitUnSpecified field may close things down).

   The permitUnSpecified field specifies how to handle attribute can be types
   which are not present in
   an AC - however it MAY be multi-valued and each of its
   values will contain an EnvelopedData.

   Each value can contain a set of attributes (each possibly
   a multi-valued attribute) encrypted for a set of
   recipients.

   The cleartext either the permittedAttrs or excludedAttrs
   fields. TRUE (the default) means that any unspecified attribute type
   is encrypted has the type:

   ACClearAttrs ::= SEQUENCE {
        acIssuer  GeneralName,
        acSerial  INTEGER,
        attrs     SEQUENCE OF Attribute
   }

   The DER encoding of the ACClearAttrs structure allowed in ACs; FALSE means that no unspecified attribute type is used as
   the encryptedContent field
   allowed.

4.7 Profile of the EnvelopedData, i.e. the
   DER encoding MUST be embedded in an OCTET STRING. AC Issuer's PKC

   The acIssuer and acSerial fields are present to prevent
   ciphertext stealing - when an AC verifier has
   successfully decrypted an encrypted attribute it Issuer's PKC MUST
   then check conform to [RFC2459] and MUST NOT
   explicitly indicate that the AC issuer and serialNumber fields
   contain can't sign. In order to avoid
   confusion (e.g. over serial numbers or revocations) an AC issuer
   MUST NOT also be a PKC Issuer (i.e. it can't be a CA as well), so
   the same values. This prevents AC Issuer's PKC MUST NOT have a malicious basicConstraints extension with
   isACA set to TRUE.

   If the AC issuer from copying ciphertext from another supports revocation of ACs then the AC issuer's
   AC into PKC
   SHOULD contain an AC issued by authorityInfoAccess extension with a new
   accessMethod which assists the malicious AC issuer. verifier in checking the status of
   an AC.

   The procedure for new accessMethod is:

    id-ad-acRevStatusLocation OBJECT IDENTIFIER ::= { id-ad 4}

   The accessLocation field MUST contain a single GeneralName
   containing either an AC issuer when encrypting attributes X.500 Name or a URL. If accessLocation contains
   an X.500 Name, then this 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 name of recipients.
   2.   For each attribute set which is to be encrypted:
      2.1. Create an EnvelopedData structure for the data a directory entry where a
   revocation list for ACs issued by this set of recipients.
      2.2. Encode the EnvelopedData AC issuer should be present
   as a value of the
           EncryptedAttributes attribute
      2.3. Ensure atributeCertificateRevocationList attribute. If
   accessLocation contains a URI, then this specifies the cleartext attribute(s) are transport
   used for OCSP [RFC2560] requests. The AC issuer MUST, of course,
   maintain an OCSP responder at this location.

   Note that in contrast to the use of authorityInfoAccess described in
   section 4.4.4, in this case the extension is not present in the to-be-signed AC,
   but rather in the AC issuer's PKC.

5. Attribute Certificate Validation


Farrell & Housley                                            [Page 20] 19]


INTERNET-DRAFT                                                  April                                            October 1999

   3.   Add the EncryptedAttribute (with its multiple
        values) to the AC

   Note that the rule


   This section describes a basic set of rules that each attribute type (the OID)
   only occurs once may not hold after decryption. That is,
   an all "valid" ACs
   MUST satisfy. Some additional checks are also described which AC
   verifiers MAY contain choose to implement.

   To be valid an AC MUST satisfy all of the same attribute type both in clear following:

   1.   The AC signature must be cryptographically correct and in encrypted form (and indeed more than once if the
   decryptor is a recipient for more than one
   EnvelopedData). One approach would AC
        issuer's PKC MUST be to merge attributes
   following decryption verified in order accordance with [RFC2459].
   2.   The AC issuer's PKC MUST also conform to re-establish the "once
   only" constraint.

   name      ietf-ac-encAttrs
   OID       { ietf-ac-attributes 6}
   Syntax    ContentInfo
   values    Multiple Allowed

4.6 PKC Extensions

   Public key certificate extensions which assist profile specified
        in section 4.7 above.
   3.   If the AC
   handling are defined in this section.
   <<just one issuer is not directly trusted as an AC issuer (by
        configuration or otherwise), then the AC issuer's certification
        path must satisfy the additional PKC checks described below
   4.   The time for now, and hopefully, always!>>

4.6.1     AAControls

   During which the AC validation a relying party has to answer is being evaluated MUST be within the
   question "is this
        AC issuer trusted validity (if the evaluation time is equal to issue ACs
   containing either
        notBeforeTime or notAfterTime then the AC is timely, i.e. this attribute"?
        check succeeds). Note that in some applications, the evaluation
        time MAY not be the same as the current time.
   5.   The AAControls PKC extension,
   intended to AC targeting check MUST pass (see section 4.4.3 above)
   6.   If the AC contains any "unsupported" critical extensions then
        the AC MUST be used rejected.

   "Support" for an extension in CA and this context means:

   a. the AC Issuer PKCs, MAY verifier MUST be used able to help answer parse the question. extension value, and,
   b. where the extension value SHOULD cause the AC to be rejected, the
   AC verifier MUST reject the AC.

   The use of AAControls is
   further described following additional certification path checks (referred to in section 5.

      aaControls EXTENSION ::= {
         SYNTAX         AAControls
         IDENTIFIED BY  { ietf-ac-pkcexts-aaControls}
      }
      AAControls ::= SEQUENCE {
         pathLenConstraint   INTEGER (0..MAX) OPTIONAL,
         permittedAttrs      [0] AttrSpec OPTIONAL,
         excludedAttrs       [1] AttrSpec OPTIONAL,
         permitUnSpecified   BOOLEAN DEFAULT TRUE
      }
      AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER
      
   The
   (2) above) MUST all succeed:

   1.   Some CA on the AC's 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 PKC's on the path from the AA CA down to and including the
        AC issuer's PKC MUST contain an aaControls extension is used as follows:

   The pathLenConstraint if present is interpreted defined
        below (the PKC with the AA CA's as subject need not contain
        this extension).
   3.   Only those attributes in
   [RFC2459], but now restricts the AC which are allowed "distance"
   between according to
        all of the aaControls extension values in all of the PKCs from
        the AA CA, (a CA directly trusted to include
   AAControls in its PKCs), and the AC issuer.

Farrell & Housley                                                [Page 21]


INTERNET-DRAFT                                                  April 1999

   The permittedAttrs field specifies a set of attribute
   types issuer, may be used for authorization
        decisions, all other attributes MUST be ignored (note that any AC issuer below this AA CA is allowed
        check MUST be applied to
   include in ACs. If this field is not present, it means
   that no attribute types are explicitly allowed (though the permitUnSpecified field may open things up).

   The excludedAttrs field specifies a set of attributes following
        attribute
   types decryption and 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 (though the
   permitUnSpecified field may close things down).

   The permitUnSpecified field specifies how to handle
   attribute types which are not present in either such cases the
   permittedAttrs or excludedAttrs fields. TRUE (the
   default) means that any unspecified attribute type is
   allowed in ACs; FALSE means that no unspecified attribute id-aca-encAttrs
        type is allowed.

5.   AttributeCertificate 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: checked).

   Additional Checks:

   1.   the   The AC signature must MAY be cryptographically correct
        and rejected on the basis of further AC issuer's PKC MUST verifier
        configuration, for example an AC verifier may be verified in accordance
        with [RFC2459] configured to
        reject ACs which contain or lack certain attribute types.
   2.   if   If the AC issuer is not directly trusted as verifier provides an AC
        issuer (by configuration or otherwise), interface that allows
        applications to query the contents of the AC, then the AC
        issuer's certification path must satisfy

Farrell & Housley                                            [Page 20]


INTERNET-DRAFT                                            October 1999


        verifier MAY filter the additional
        PKC checks described below
   3. attributes from the time AC on the basis of evaluation MUST
        configured information, e.g. an AC verifier might be within configured
        not to return certain attributes to certain targets.

6. Revocation

   <<Input is solicited on the AC
        validity (if suitability of the evaluation time is equal to either
        notBeforeTime or notAfterTime then 3-scheme approach.>>

   In many environments, the AC is timely, i.e.
        this check succeeds)
   4.   if validity period of an AC contains attributes apparently encrypted
        for is less than the AC verifier then the decryption process MUST
   time required to issue and distribute revocation information.
   Therefore, short-lived ACs typically do not
        fail - if decryption fails then require revocation
   support. However, long-lived ACs and environments where ACs enable
   high value transactions MAY require revocation support.

   The basic approach taken is to allow use of the following AC MUST
   revocation related schemes.

   "Never revoke" scheme: ACs may be rejected
   5. marked so that the relying party
   understands that no revocation status information will be made
   available.

   "Pointer from above" scheme: The PKC (or AC targeting check MUST pass (see see section 4.4.3
        above)
   6.   if the 7.4) of an
   AC contains any "unsupported" critical
        extensions then issuer may "point" to sources of revocation status information
   for all ACs issued by that AC issuer, (with the exception of those
   marked using the never-revoke method above).

   "Pointer in AC" scheme: ACs may be marked (like PKCs) to "point" to
   sources of revocation status information (using an
   authorityInfoAccess or crlDistributionPoints extension in the AC
   itself).

   The never revoke scheme requires a new authorityInfoAccess
   accessMethod. The pointer from above scheme also requires a new
   authorityInfoAccess accessMethod. The pointer in AC scheme is as
   specified in [RFC2459] and [RFC2560].

   The never revoke scheme MUST be rejected.

   "Support" supported, the other schemes SHOULD
   be supported.

6.1.1   "Never revoke" method

   Where an AC issuer does not support revocation status checks for a
   particular AC, then an authority information access extension (id-
   pe-authorityInfoAccess) with an id-ad-noRevStat accessMethod as
   specified in section 4.4.4 above MUST be present and critical in the
   AC to indicate this.

   Where no authority information access is present with this context means:

   a.
   accessMethod, then the AC verifier issuer is implicitly stating that
   revocation status checks are supported and one of the other methods
   below MUST be able provided to parse allow AC verifiers to establish the extension
   value, and,
   revocation status of the AC.


Farrell & Housley                                            [Page 22] 21]


INTERNET-DRAFT                                                  April                                            October 1999

   b. where the extension value SHOULD cause


6.1.2   "Pointer from above" method

   In this case the AC to be
   rejected, the issuer's PKC contains an authority information
   access extension with an id-ad-acRevStatusLocation accessMethod as
   described in section 4.7 above.

6.1.3   "Pointer in AC" method

   AC verifier MUST reject revocation status MAY be checked using the AC.

   The following additional certification path checks
   (referred to methods described in (2) above) MUST all succeed:

   1.   some CA on the AC's certificate path MUST be
        directly trusted to issue PKCs which preceed
   [RFC2459], but substituting the AC issuer in the certification path, call this CA the "AA
        CA"
   2.   all PKC's on the path from the AA wherever a CA down to and
        including is
   mentioned.

   In these cases, the AC issuer's PKC MUST contain contains either an aaControls
        extension authorityInfoAccess or
   crlDistributionPoints extensions as defined below (the PKC with the AA CA's as
        subject need not contain this extension)
   3.   only those attributes in the AC which are allowed
        according [RFC2459] and
   [RFC2560] respectively.


7. Optional Features

   This section specifies features that MAY be implemented. Conformance
   to all of the aaControls extension values this specification does NOT require support for these features.

7.1 Attribute Encryption

   Where an AC will be carried in
        all clear within an application protocol
   or where an AC contains some sensitive information (e.g. a legacy
   application username/password) then encryption of the PKCs from the AA CA to the AC issuer, may be
        used for authorization decisions, all other attributes
        MUST MAY
   be ignored (note that this check MUST needed.

   When a set of attributes are to be applied encrypted within an AC, the
   cryptographic message syntax, EnvelopedData structure [CMS] is used
   to carry the set ciphertext(s) and associated per-recipient keying
   information.

   This type of attributes following attribute decryption and encryption is targeted, which means that in such cases
   before the ietf-ac-encAttrs type MUST also be
        checked)

   Additional Checks:

   1.   The AC MAY be rejected on is signed the basis of further AC
        verifier configuration, attributes have been encrypted for example an AC verifier may be
        configured to reject ACs which contain or lack certain
        attribute types
   2.   If the AC verifier provides an interface that allows
        applications to query the contents a set
   of the AC, predetermined recipients.

   The AC then contains the AC
        verifier MAY filter ciphertext(s) inside its signed data. The
   "enveloped-data" (id-envelopedData) ContentType is used and the attributes from
   content field will contain the EnvelopedData type.

   The set of ciphertexts is included into the AC on as the
        basis value of configured information, e.g. an
   encrypted attributes attribute. Only one encrypted attributes
   attribute can be present in an AC verifier
        might - however it MAY be configured not to return certain multi-valued
   and each of its values will contain an EnvelopedData.

   Each value can contain a set of attributes to
        certain targets. (each possibly a multi-
   valued attribute) encrypted for a set of recipients.

   The cleartext that is encrypted has the type:

      ACClearAttrs ::= SEQUENCE {

Farrell & Housley                                            [Page 23] 22]


INTERNET-DRAFT                                                  April                                            October 1999

6.   Revocation

   In many environments,


           acIssuer  GeneralName,
           acSerial  INTEGER,
           attrs     SEQUENCE OF Attribute
      }

   The DER encoding of the validity period ACClearAttrs structure is used as the
   encryptedContent field of the EnvelopedData, i.e. the DER encoding
   MUST be embedded in an OCTET STRING.

   The acIssuer and acSerial fields are present to prevent ciphertext
   stealing - when an AC is
   less than verifier has successfully decrypted an
   encrypted attribute it MUST then check that the time required to issue AC issuer and distribute
   revocation information.  Therefore, short-lived ACs do
   not require revocation support. However, long-lived ACs
   and environments where ACs enable high value transactions
   MAY require revocation support.

   In such cases, AC revocation status MAY be checked using
   serialNumber fields contain the methods described in [RFC2459], but substituting same values. This prevents a
   malicious AC issuer from copying ciphertext from another AC issuer's
   AC into an AC issued by the malicious AC issuer.

   The procedure for an AC issuer wherever a CA when encrypting attributes is mentioned.

   Note however
   illustrated by the following (any other procedure that this does not impose a requirement for
   conformant AC issuers gives the
   same result MAY be used):


      1.   Identify the sets of attributes that are to be able encrypted for
           each set of recipients.
      2.   For each attribute set which is to issue CRLs.

   Where be encrypted:
         2.1. Create an AC issuer does not support revocation status
   checks EnvelopedData structure for the data for this
              set of recipients.
         2.2. Encode the EnvelopedData as a particular AC, then an authority information
   access extension (id-pe-authorityInfoAccess) MUST be value of the
              EncryptedAttributes attribute
         2.3. Ensure the cleartext attribute(s) are not present and critical in the
              to-be-signed AC
      3.   Add the EncryptedAttribute (with its multiple values) to indicate this. Where no
   authority information access is present, then the
           AC
   issuer is implicitly stating

   Note that revocation checks are
   supported and mechanisms in accordance with [RFC2459]
   MUST be provided to allow the rule that each attribute type (the OID) only occurs
   once may not hold after decryption. That is, an AC verifiers to establish MAY contain the
   revocation status of
   same attribute type both in clear and in encrypted form (and indeed
   more than once if the AC.

   The accessMethod used to handle this case decryptor is described
   above. a recipient for 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
   fails then the AC MUST be rejected.


7.2 Proxying


Farrell & Housley                                            [Page 24] 23]


INTERNET-DRAFT                                                  April                                            October 1999

7.   Limited AC Acquisition Protocol

   <<Note that this section is very likely to change and may
   be removed, in particular if it is found that CMP or CMC
   can be suitably extended


   In some circumstances, a server needs to support proxy an AC acquisition. If
   the WG reaches a consensus that when it acts as
   a new protocol is needed
   then this section may move client (for another server) on behalf of the AC owner. Such
   proxying needs to a separate I-D. Even with a
   new protocol, it would be appropriate to examine
   extending CMP/CMC to handle more general under the AC issuer's control, so that not
   every AC management
   tasks. Basically, this is a "strawman">>

   There is clearly proxiable and so that a requirement for an given proxiable AC management
   protocol (or protocols, like [CMP] and [CMC]). Such
   management protocols are not specified can be
   proxied in this document.
   There is also a requirement targeted fashion. Support for a specification chains of an
   LDAP schema, which proxies (with
   more than one intermediate server) is also not specified here. sometimes required.

   In addition to such protocols, which may be more suited order to management of long-term or more sensitive (i.e. more
   "powerful") ACs, there is a meet this requirement for a very
   simple, explicitly limited AC acquisition protocol.

   This protocol we define another extension:
   ProxyInfo, similar to the targeting extension.

   When this extension is required for cases where an present the AC user
   wishes to acquire a "current" AC for an entity (possibly
   itself) leaving almost all details as to verifier must check that the content of
   entity from which the AC was received was allowed to send it and
   that the AA or whatever network service acts on its
   behalf.

   We call AC is allowed to be used by this protocol verifier.

   The proxying information consists of a set of proxy information,
   each of which is a set of targeting information. If the verifier and
   the sender of the Limited AC Acquisition Protocol
   (LAAP). The are two entities involved, both named in the LAAP requestor
   (LRQ) and LAAP responder (LRP). same proxy set then the
   AC can be accepted (the exact rule is given below).

   The LR effect is typically an that the AC owner or an AC verifier; can send the LRP is typically AC to any valid target
   which can then only proxy to targets which are in one of the AA same
   "proxy sets" as itself.

   LAAP

   The following data structure is designed used to represent the
   targeting/proxying information.

          ProxyInfo ::= SEQUENCE OF Targets


   A proxy check succeeds if

           (
                the identity of the sender as a single-shot request/response
   protocol with no polling, retries, etc.

   The one established by
                the underlying authentication service matches
                the owner field of the AC
                and only feature
                (
                     the current server "matches" any one of this protocol
                     the proxy sets (where "matches" is to request
   an AC as for a particular entity that may be either
                     the
   requestor direct check above)
                )
           )
           or some other entity. The response is
           (
                the
   requested AC or an error.

   The security identity of the request sender as established by
                the underlying authentication service "matches"
                one of the proxy sets (call it  set  "A")
                and response (e.g. whether
                (
                the requestor current server is authenticated one of the targetName
                fields in the set "A"
                or not)
                the current server is out of scope
   and a matter for LAAP implementers. For example, an LRP
   may be configured so that it only ever issues ACs if the
   request is received over an authenticated channel (e.g.
   TLS with client authentication), or it may only issue
   "guest" privileges when the LRQ is not the owner member of one of the
   AC.

Farrell & Housley                                            [Page 25] 24]


INTERNET-DRAFT                                                  April                                            October 1999

   The protocol consists of a request message that may
   specify the identity of the AC owner (for the third party
   case), with


                targetGroup fields in set "A".
                )
           )

   Where an optional "profile". A profile is to be
   interpreted as a bilaterally agreed string that AC is mapped
   to proxied more than once a set of AC contents by the LRP.

   LACRequestMessage ::= SEQUENCE {
             owner     [0] CHOICE{
                  baseCertificateID   [0] IssuerSerial,
                       -- the issuer and serial number of
                       -- the owner's Public Key Certificate
                  entityName          [1] GeneralNames,
                       -- targets will be on
   the name of path from the claimant or role
                  objectDigestInfo    [2] ObjectDigestInfo
                       -- if present, version must be v2
             } OPTIONAL,
             profile   [1] UTF8String OPTIONAL
   }

   <<Note that this message syntax omits any "proof" that original client, which is normally, but not
   always, the LRQ has some valid reason to ask for an AC for the owner. It would be (at least) nice to be able to include In such "proof", but can't be specified here since it might
   depend on cases prevention of AC "stealing"
   requires that the client/server authentication. Other than
   via AC verifier MUST check that all targets on the profile field,
   path are members of the LRQ also cannot specify same proxy set. It is the
   target(s) where responsibility of
   the AC will have to be verified. We need using protocol to consider if these are needed or not.>>

   Each field is described below.

   "owner": when present this specifies ensure that a trustworthy list of targets
   on the LRQ wishes path is available to acquire an the AC for this owner. When absent, verifier.

      name           id-pe-ac-proxying
      OID            { id-pe 7 }
      syntax         ProxyInfo
      criticality    must be TRUE

7.3 Use of ObjectDigestInfo

   <<In order to keep it means simple, I've only allowed for a hash over a
   key, a hash over a certificate is thus not supported. If this or any
   other form of hash were allowed, then we'll need a
   digestedObjectInfo extension as well.>>

   In some environments it may be required that the LRQ AC is requesting not linked
   either to an AC for itself (the LRP
   should use the identity established from whatever
   underlying authentication is available). (via entityName) or to a PKC (via
   baseCertificateID). The rules objectDigestInfo choice in the owner field
   allows support for this requirement.

   If the owner is identified via the objectDigestInfo field in then the
   AC apply here (e.g. no use of
   objectDigestInfo).

   "profile": when present this version field MUST contain v2 (i.e. the integer 1).

   The basic idea is an request to link the LRP
   that an AC matching a certain profile be returned. The
   definition of profiles is not in scope for this
   specification and is expected to be an object by placing a local matter. This
   field allows some simple switching.

   Note that this definition means hash of
   that object into the minimal LAAP
   request message consists owner field of the octets `3000'H, an empty
   sequence. This message means "give me my current default
   AC please".



Farrell & Housley                                                [Page 26]


INTERNET-DRAFT                                                  April 1999

   LACResponseMessage ::= CHOICE {
        ac        [0]  AttributeCertificate,
        errorInfo [1]  ErrorMsgContent -- from [CMP]
   }

   When AC. For example, this allows
   production of ACs that are linked to public keys rather than names
   or certificates, or production of ACs which contain privileges
   associated with an LRQ receives executable object (e.g. a Java class).

   In order to link an AC from an LRP it SHOULD verify to a public key the AC. In addition hash must be calculated
   over the LRQ SHOULD ensure representation of that the AC
   "matches" the LAAP request issued. The only matching public key which applies would be present in general is to ensure that
   a PKC, specifically, the LAAP
   request owner field and input for the AC owner field are identical.
   Implementations may of course include additional checks.

   We define hash algorithm MUST be the following HTTP based transport for LAAP.

   An LRQ should send
   DER encoding of a HTTP POST request to SubjectPublicKeyInfo representation of the LRP, key.
   Note: This includes the
   POST data should consist of AlgorithmIdentifier as well as the DER BIT
   STRING. The rules given in [RFC2459] and [ECDSA] for encoding of keys
   MUST be followed.

   Note that if the
   LACRequestMessage. The response is expected public key value used as input to have the
   MIME type "application/x-laapmsg" with hash function
   has been extracted from a PKC, then it is possible that the message data
   containing
   SubjectPublicKeyInfo from that PKC is NOT the DER encoding value which should be
   hashed. This can occur if, e.g. DSA Dss-parms are inherited as
   described in section 7.3.3 of [RFC2459]. The correct input for
   hashing in this context will include the LACResponseMessage.

   <<how an LRQ knows value of the URL for an LRP is TBS>> parameters


Farrell & Housley                                            [Page 27] 25]


INTERNET-DRAFT                                                  April                                            October 1999

8.   Conformance

   This specification defines two levels of conformance,
   basic and proxy-enabled. For each level


   inherited from the actors
   involved must meet different requirements. The intention
   is that support for basic conformance should allow for
   freely interoperable but fairly inflexible CA's PKC, and
   "featureless" AC based authorization. Proxy-enabled
   conformance requires more effort from implementers, thus may
   not be as widely interoperable and is harder to
   administer, but does offer much more flexibility and many
   more features.

   A proxy-enabled AC issuer differ from the
   SubjectPublicKeyInfo present in the PKC.

   Implementations which support this feature MUST be able to produce all handle
   the representations of keys for the attribute types and extensions algorithms specified above.

   A proxy-enabled AC verifier MUST "support" all in section
   7.3 of the
   attribute types [RFC2459] and extensions those specified above.

   "Support" in the previous paragraph means more than just
   parsing. It means that the [ECDSA].


7.4 AC verifier MUST be able Chaining

   Section 5 above specifies a way of embedding AAControls into PKCs in
   order to
   reject any AC control the attribute types for which should not be valid at that target
   and MUST an AA will be able trusted
   by an AC verifier.

   There are two drawbacks to make any attributes and extensions
   which were not fully processed available this mechanism:

        - PKC issuers have to the calling
   application.

   A proxy-enabled AC issuer know about authorization attribute types
        - It is responsible likely to ensure that
   no AC produced could be accepted by a basic AC verifier
   in such a way as require more frequent changes to cause a security breach.
   <<dunno if that AA's PKCs

   These problems can happen but it needs to be checked>>

   Basic conformance for avoided by placing the equivalent information
   into an AC issuer means support for
   production of ACs which:

   1.   MUST use the baseCertificateID owner field
        alternative
   2.   MUST NOT be post-dated
   3.   MAY contain AccessIdentity, Group and/or Role
        attributes with multiple values
   4.   MUST NOT contain any other attributes which cannot
        safely be ignored by an AC verifier
   5.   MAY contain the AuthorityKeyIdentifier extension
   6.   MUST contain no critical extensions (and hence owner is
        not proxiable) except for authorityInformationAccess
        where revocation status checks are not provided
   7.   MUST NOT contain encrypted attributes

   Basic conformance also an AA. However, this mechanism
   requires support for the
   AAControls PKC extension. A basic AC issuer MUST also
   support LAAP as specified chaining of ACs and thus imposes possibly significant costs
   both in section 7 above.

Farrell & Housley                                                [Page 28]


INTERNET-DRAFT                                                  April 1999

   Basic conformance for terms of implementation and deployment complexity.

   In order to use this feature, an AC verifier means support for
   the validation of ACs presented with an AC,
   (belonging say to an end entity, call this EE-AC), must retrieve an
   AC which are produced is owned by basic AC
   issuers.

   A basic the issuer of EE-AC (call this AA-AC). The AC
   verifier MAY ignore next verifies AA-AC, extracts the presence of any
   unsupported attributes or extensions (of course it must
   reject all ACs which contain unsupported critical
   extensions) AAControls information
   from AA-AC and need only make uses this to decide which attributes from EE-AC
   should be trusted.

   Of course, the values issuer of AA-AC may or may not be directly trusted by
   the
   remaining attributes available to applications.

   A basic AC verifier for the required attributes. In such a case, the AC
   verifier may have to retrieve another AC (AA2-AC), etc. until it
   finds one issued by a directly trusted AC issuer for each of the
   relevant attributes.

   AC verifiers which support this feature MUST also support the use of
   aaControls placed within PKCs.

   When verifying an AC, the verifier needs to determine when a chain
   of ACs is needed.

   When AAControls PKC
   extension.

9. are present in an AC, they are placed as an
   extension of the AC, using the same extension defined in section
   4.6.1 above.

   When chaining ACs the following additional verification rules apply

   1.  EE-AC.issuer and AA-AC.owner MUST contain the same value
   2.  At the time of evaluation all ACs in the chain MUST be valid

   <<probably needs more about the AC chain validation algorithm>>

Farrell & Housley                                            [Page 26]


INTERNET-DRAFT                                            October 1999



8. Security Considerations

   <<tbs>>

10.

   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.

   There is often a requirement to map between the authentication
   supplied by a particular protocol (e.g. TLS, S/MIME) and the AC
   owner'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 owner may be authenticated using
   other means. Implementers SHOULD be very careful in mapping the
   authenticated identity to the AC owner.

9. References

  [CMC]       Myers, M., et al. "Certificate Management Messages over
               CMS",
               draft-ietf-pkix-cmc-03.txt, March 1999.
  [CMP]       Adams, C., Farrell, S., "Internet X.509 Public Key
               Infrastructure - Certificate Management Protocols",
               RFC2510.
  [CMS]       Housley, R., "Cryptographic Message Syntax",
               draft-ietf-smime-cms-12.txt, March 1999.
  [ESS]       Hoffman, P., "Enhanced Security Services for S/MIME",
               draft-ietf-smime-ess-12.txt, March 1999.
  [ECDSA]     D. Johnson, W. Polk, "Internet X.509 Public Key
               Infrastructure Representation of Elliptic Curve Digital
               Signature Algorithm (ECDSA) Keys and Signatures in
               Internet X.509 Public Key Infrastructure Certificates"
               draft-ietf-pkix-ipki-ecdsa-01.txt, June 1999.
  [RFC2459]   Housley, R., Ford, W., Polk, T, & Solo, D., "Internet
               Public Key Infrastructure - X.509 Certificate and CRL
               profile", RFC2459.
  [RFC2560]   Myers, M., et al., " X.509 Internet Public Key
               Infrastructure - Online Certificate Status Protocol -
               OCSP", RFC2560.
  [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.
   [X.509]
  [X.501]     ITU-T Recommendation X.509 (1997 E): X.501 : Information Technology -
               Open Systems Interconnection - The Directory:
              Authentication Models,
               1993.
  [X.509]     ITU-T Recommendation X.509 (1997 E): Information
               Technology - Open Systems Interconnection - The
               Directory: Authentication Framework, June 1997.
  [X.208-88] CCITT.  CCITT Recommendation X.208: Specification of Abstract
               Syntax Notation One (ASN.1). 1988.



Farrell & Housley                                            [Page 27]


INTERNET-DRAFT                                            October 1999


  [X.209-88] CCITT.  CCITT Recommendation X.209: Specification of Basic
               Encoding Rules for Abstract Syntax Notation One (ASN.1).
               1988.
  [X.501-88] CCITT.  CCITT Recommendation X.501: The Directory - Models.
               1988.
  [X.509-88] CCITT.  CCITT Recommendation X.509: The Directory -
               Authentication Framework.  1988.

Farrell & Housley                                                [Page 29]


INTERNET-DRAFT                                                  April 1999
  [X.509-97] ITU-T.  ITU-T Recommendation X.509: The Directory -
               Authentication Framework.  1997.
   [XPDAM]
  [FPDAM]     ISO 9594-8 Information Technology - û Open systems
               Interconnection - The Directory: Authentication
               Framework - Proposed Draft Amendment 1: Certificate
               Extensions,
              September 1998. April 1999.

Author's Addresses

   Stephen Farrell,
   SSE Ltd.
   Baltimore Technologies
   61/62 Fitzwilliam Court,
   Leeson Close, Lane,
   Dublin 2,
   IRELAND

   tel: +353-1-216-2910 +353-1-647-3000
   email: stephen.farrell@sse.ie stephen.farrell@baltimore.ie

   Russell Housley,
   SPYRUS,
   381 Elden Street,
   Suite 1120,
   Herndon, VA 20170,
   USA

   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

Farrell & Housley                                                [Page 30]


INTERNET-DRAFT                                                  April 1999
   followed, or as required to translate it into languages other than
   English.

Farrell & Housley                                            [Page 28]


INTERNET-DRAFT                                            October 1999



   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 IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Appendix A: "Compilable" 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

            -- PKIX Certificate Extensions
               Attribute, AlgorithmIdentifier, CertificateSerialNumber,
               Extensions, UniqueIdentifier,
               id-pkix, id-pe, id-kp, id-ad
               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
               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-ac-targeting           OBJECT IDENTIFIER ::= { id-pe 5 }
      id-pe-aaControls             OBJECT IDENTIFIER ::= { id-pe 6 }
      id-pe-ac-proxying            OBJECT IDENTIFIER ::= { id-pe 7 }

      id-pe-ac-targeting-all       OBJECT IDENTIFIER ::=
                                            { id-pe-ac-targeting 1 }

      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-role                  OBJECT IDENTIFIER ::= { id-aca 5 }

Farrell & Housley                                            [Page 29]


INTERNET-DRAFT                                            October 1999


      id-aca-encAttrs              OBJECT IDENTIFIER ::= { id-aca 6 }

      id-ad-noRevStat              OBJECT IDENTIFIER ::= { id-ad 3 }
      id-ad-acRevStatusLocation    OBJECT IDENTIFIER ::= { id-ad 4 }

              AttributeCertificate ::= SEQUENCE {
                   acinfo               AttributeCertificateInfo,
                   signatureAlgorithm   AlgorithmIdentifier,
                   signatureValue       BIT STRING
              }

              AttributeCertificateInfo ::= SEQUENCE {
                   version        AttCertVersion DEFAULT v1,
                   owner          Owner,
                   issuer         AttCertIssuer,
                   signature      AlgorithmIdentifier,
                   serialNumber   CertificateSerialNumber,
                   attrCertValidityPeriod   AttCertValidityPeriod,
                   attributes     SEQUENCE OF Attribute,
                   issuerUniqueID UniqueIdentifier OPTIONAL,
                   extensions     Extensions     OPTIONAL
              }

              AttCertVersion ::= INTEGER {v1(0), v2(1) }

              Owner ::= SEQUENCE {
                   baseCertificateID   [0] IssuerSerial OPTIONAL,
                             -- the issuer and serial number of
                             -- the owner'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 {
                   digestAlgorithm     AlgorithmIdentifier,
                   objectDigest        OCTET STRING
              }

              AttCertIssuer ::= SEQUENCE {
                        issuerName              GeneralNames  OPTIONAL,
                        baseCertificateId   [0] IssuerSerial OPTIONAL
              }

              IssuerSerial  ::=  SEQUENCE {
                   issuer         GeneralNames,
                   serial         CertificateSerialNumber,
                   issuerUID      UniqueIdentifier OPTIONAL
              }

              AttCertValidityPeriod  ::= SEQUENCE {
                   notBeforeTime  GeneralizedTime,

Farrell & Housley                                            [Page 30]


INTERNET-DRAFT                                            October 1999


                   notAfterTime   GeneralizedTime
              }

             Targets ::= SEQUENCE OF Target

             Target ::= CHOICE {
                  targetName          [0] GeneralName,
                  targetGroup         [1] GeneralName
             }

             IetfAttrSyntax ::= SEQUENCE OF 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
              }

              Clearance  ::=  SEQUENCE {
                   policyId  OBJECT IDENTIFIER,
                   classList ClassList DEFAULT {unclassified},
                   securityCategories
                             SET OF SecurityCategory  OPTIONAL
              }

              ClassList  ::=  BIT STRING {
                   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
            }


Farrell & Housley                                            [Page 31]


INTERNET-DRAFT                                            October 1999


            AttrSpec::= SEQUENCE OF MERCHANTABILITY OR FITNESS FOR A
   PARTICULAR PURPOSE.

Appendix A:    Samples

   tbs OBJECT IDENTIFIER

            ACClearAttrs ::= SEQUENCE {
              acIssuer  GeneralName,
              acSerial  INTEGER,
              attrs     SEQUENCE OF Attribute
            }

            ProxyInfo ::= SEQUENCE OF Targets


      END


Appendix B:    "Compilable" ASN.1 Module

   <<tbs - will be supplied in '88 format>> Samples

   <<TBS>>

Appendix C: Changes this version / Open Issues

   This appendix lists major changes since the previous revision and
   open issues to be resolved (in order of occurrence in the body of
   the document).

   Major changes since last revision:

   1.   Additional introductory text is required   Re-structured conformance to motivate
        the use of ACs profile + options as per Oslo
        consensus
   2.   The ASN.1 has to be synched with the ISO FPDAM where
        necessary   Moved acquisition protocol (LAAP)_to separate I-D
   3.   An OID   Removed restrictions entirely
   4.   Added new AC revocation options
   5.   Added optional support for ietf-ac has use of objectDigestInfo for keys
   6.   Added optional support for chains of ACs
   7.   Changed some syntax:
        Added UTF8String to be allocated
   4.   The objectDigest IetfAttrSyntax value choice for
        Split target & proxy extensions, removed owner has to from proxyInfo
   8.   Allocated PKIX OIDs (note: check with repository before using
        these, the PKIX arc is currently available at
        http://www.imc.org/ietf-pkix/pkix-oid.asn)
   9.   Added compiled ASN.1 module

   Open issues remaining:

   1.   Should an AC without any attributes be a MUST
        NOT or else profiled (and explained!)
   5.   Are "restrictions" needed?
   6.   Is "IetfAttrSyntax" needed?
   7. allowed?
   2.   Should OS-specific group attribute types be defined?
   8.   More explanatory text for encryptedAttributes is
        needed.
   9.
   3.   Is a new AC acquisition protocol required? If not,
        how are ACs acquired? If so, should it be part the expansion of this
        specification?
   10. the SecurityCategory MACRO correct?
   4.   Are different conformance levels three revocation schemes needed? If so, are
        these the right ones?
   11.  Security considerations text needed
   12.  References Correct?
   5.   Should more types of objectDigestInfo be allowed?
   6.   AC chain section to needs more description of chain validation.
   7.   Samples - should they be fixed
   13.  Compilable ASN.1 and samples are needed a separate draft?




Farrell & Housley                                            [Page 31] 32]


----