Network Working Group                                         S. FarrellRequest for Comments: 3281                        Baltimore TechnologiesCategory: Standards Track                                     R. Housley                                                        RSA Laboratories                                                              April 2002                   An Internet Attribute Certificate                       Profile for AuthorizationStatus of this Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2002).  All Rights Reserved.Abstract   This specification defines a profile for the use of X.509 Attribute   Certificates in Internet Protocols.  Attribute certificates may be   used in a wide range of applications and environments covering a   broad spectrum of interoperability goals and a broader spectrum of   operational and assurance requirements.  The goal of this document is   to establish a common baseline for generic applications requiring   broad interoperability as well as limited special purpose   requirements.  The profile places emphasis on attribute certificate   support for Internet electronic mail, IPSec, and WWW security   applications.Table of Contents   1. Introduction.................................................  2       1.1  Delegation and AC chains...............................  4       1.2  Attribute Certificate Distribution ("push" vs. "pull").  4       1.3  Document Structure.....................................  6   2. Terminology..................................................  6   3. Requirements.................................................  7   4. Attribute Certificate Profile................................  7       4.1  X.509 Attribute Certificate Definition.................  8       4.2  Profile of Standard Fields............................. 10           4.2.1  Version.......................................... 10           4.2.2  Holder........................................... 11Farrell & Housley           Standards Track                     [Page 1]RFC 3281           An Internet Attribute Certificate          April 2002           4.2.3  Issuer........................................... 12           4.2.4  Signature........................................ 12           4.2.5  Serial Number.................................... 12           4.2.6  Validity Period.................................. 13           4.2.7  Attributes....................................... 13           4.2.8  Issuer Unique Identifier......................... 14           4.2.9  Extensions....................................... 14       4.3  Extensions............................................. 14           4.3.1  Audit Identity................................... 14           4.3.2  AC Targeting..................................... 15           4.3.3  Authority Key Identifier......................... 17           4.3.4  Authority Information Access..................... 17           4.3.5  CRL Distribution Points.......................... 17           4.3.6  No Revocation Available.......................... 18       4.4  Attribute Types........................................ 18           4.4.1  Service Authentication Information............... 19           4.4.2  Access Identity.................................. 19           4.4.3  Charging Identity................................ 20           4.4.4  Group............................................ 20           4.4.5  Role............................................. 20           4.4.6  Clearance........................................ 21       4.5  Profile of AC issuer's PKC............................. 22   5. Attribute Certificate Validation............................. 23   6. Revocation................................................... 24   7. Optional Features............................................ 25       7.1  Attribute Encryption................................... 25       7.2  Proxying............................................... 27       7.3  Use of ObjectDigestInfo................................ 28       7.4  AA Controls............................................ 29   8. Security Considerations...................................... 30   9. IANA Considerations.......................................... 32   10. References.................................................. 32   Appendix A: Object Identifiers.................................. 34   Appendix B: ASN.1 Module........................................ 35   Author's Addresses.............................................. 39   Acknowledgements................................................ 39   Full Copyright Statement........................................ 401. Introduction   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this   document are to be interpreted as described in BCP 14, RFC 2119.   X.509 public key certificates (PKCs) [X.509-1997, X.509-2000,   PKIXPROF] bind an identity and a public key.  An attribute   certificate (AC) is a structure similar to a PKC; the main difference   being that the AC contains no public key.  An AC may containFarrell & Housley           Standards Track                     [Page 2]RFC 3281           An Internet Attribute Certificate          April 2002   attributes that specify group membership, role, security clearance,   or other authorization information associated with the AC holder.   The syntax for the AC is defined in Recommendation X.509, making the   term "X.509 certificate" ambiguous.   Some people constantly confuse PKCs and ACs.  An analogy may make the   distinction clear.  A PKC can be considered to be like a passport: it   identifies the holder, tends to last for a long time, and should not   be trivial to obtain.  An AC is more like an entry visa: it is   typically issued by a different authority and does not last for as   long a time.  As acquiring an entry visa typically requires   presenting a passport, getting a visa can be a simpler process.   Authorization information may be placed in a PKC extension or placed   in a separate attribute certificate (AC).  The placement of   authorization information in PKCs is usually undesirable for two   reasons.  First, authorization information often does not have the   same lifetime as the binding of the identity and the public key.   When authorization information is placed in a PKC extension, the   general result is the shortening of the PKC useful lifetime.  Second,   the PKC issuer is not usually authoritative for the authorization   information.  This results in additional steps for the PKC issuer to   obtain authorization information from the authoritative source.   For these reasons, it is often better to separate authorization   information from the PKC.  Yet, authorization information also needs   to be bound to an identity.  An AC provides this binding; it is   simply a digitally signed (or certified) identity and set of   attributes.   An AC may be used with various security services, including access   control, data origin authentication, and non-repudiation.   PKCs can provide an identity to access control decision functions.   However, in many contexts the identity is not the criterion that is   used for access control decisions, rather the role or group-   membership of the accessor is the criterion used.  Such access   control schemes are called role-based access control.   When making an access control decision based on an AC, an access   control decision function may need to ensure that the appropriate AC   holder is the entity that has requested access.  One way in which the   linkage between the request or identity and the AC can be achieved is   the inclusion of a reference to a PKC within the AC and the use of   the private key corresponding to the PKC for authentication within   the access request.Farrell & Housley           Standards Track                     [Page 3]RFC 3281           An Internet Attribute Certificate          April 2002   ACs may also be used in the context of a data origin authentication   service and a non-repudiation service.  In these contexts, the   attributes contained in the AC provide additional information about   the signing entity.  This information can be used to make sure that   the entity is authorized to sign the data.  This kind of checking   depends either on the context in which the data is exchanged or on   the data that has been digitally signed.1.1 Delegation and AC chains   The X.509 standard [X.509-2000] defines authorization as the   "conveyance of privilege from one entity that holds such privilege,   to another entity".  An AC is one authorization mechanism.   An ordered sequence of ACs could be used to verify the authenticity   of a privilege asserter's privilege.  In this way, chains or paths of   ACs could be employed to delegate authorization.   Since the administration and processing associated with such AC   chains is complex and the use of ACs in the Internet today is quite   limited, this specification does NOT RECOMMEND the use of AC chains.   Other (future) specifications may address the use of AC chains.  This   specification deals with the simple cases, where one authority issues   all of the ACs for a particular set of attributes.  However, this   simplification does not preclude the use of several different   authorities, each of which manages a different set of attributes.   For example, group membership may be included in one AC issued by one   authority, and security clearance may be included in another AC   issued by another authority.   This means that conformant implementations are only REQUIRED to be   able to process a single AC at a time.  Processing of more than one   AC, one after another, may be necessary.  Note however, that   validation of an AC MAY require validation of a chain of PKCs, as   specified in [PKIXPROF].1.2 Attribute Certificate Distribution ("push" vs. "pull")   As discussed above, ACs provide a mechanism to securely provide   authorization information to, for example, access control decision   functions.  However, there are a number of possible communication   paths for ACs.   In some environments, it is suitable for a client to "push" an AC to   a server.  This means that no new connections between the client and   server are required.  It also means that no search burden is imposed   on servers, which improves performance and that the AC verifier isFarrell & Housley           Standards Track                     [Page 4]RFC 3281           An Internet Attribute Certificate          April 2002   only presented with what it "needs to know."  The "push" model is   especially suitable in inter-domain cases where the client's rights   should be assigned within the client's "home" domain.   In other cases, it is more suitable for a client to simply   authenticate to the server and for the server to request or "pull"   the client's AC from an AC issuer or a repository.  A major benefit   of the "pull" model is that it can be implemented without changes to   the client or to the client-server protocol.  The "pull" model is   especially suitable for inter-domain cases where the client's rights   should be assigned within the server's domain, rather than within the   client's domain.   There are a number of possible exchanges involving three entities:   the client, the server, and the AC issuer.  In addition, a directory   service or other repository for AC retrieval MAY be supported.   Figure 1 shows an abstract view of the exchanges that may involve   ACs.  This profile does not specify a protocol for these exchanges.      +--------------+      |              |        Server Acquisition      |  AC issuer   +----------------------------+      |              |                            |      +--+-----------+                            |         |                                        |         | Client                                 |         | Acquisition                            |         |                                        |      +--+-----------+                         +--+------------+      |              |       AC "push"         |               |      |   Client     +-------------------------+    Server     |      |              | (part of app. protocol) |               |      +--+-----------+                         +--+------------+         |                                        |         | Client                                 | Server         | Lookup        +--------------+         | Lookup         |               |              |         |         +---------------+  Repository  +---------+                         |              |                         +--------------+                     Figure 1: AC ExchangesFarrell & Housley           Standards Track                     [Page 5]RFC 3281           An Internet Attribute Certificate          April 20021.3 Document Structure   Section 2 defines some terminology.  Section 3 specifies the   requirements that this profile is intended to meet.  Section 4   contains the profile of the X.509 AC.  Section 5 specifies rules for   AC validation.  Section 6 specifies rules for AC revocation checks.   Section 7 specifies optional features which MAY be supported;   however, support for these features is not required for conformance   to this profile.  Finally, appendices contain the list of OIDs   required to support this specification and an ASN.1 module.2. Terminology   For simplicity, we use the terms client and server in this   specification.  This is not intended to indicate that ACs are only to   be used in client-server environments.  For example, ACs may be used   in the S/MIME v3 context, where the mail user agent would be both a   "client" and a "server" in the sense the terms are used here.   Term          Meaning   AA            Attribute Authority, the entity that issues the                 AC, synonymous in this specification with "AC                 issuer"   AC            Attribute Certificate   AC user       any entity that parses or processes an AC   AC verifier   any entity that checks the validity of an AC and                 then makes use of the result   AC issuer     the entity which signs the AC, synonymous in this                 specification with "AA"   AC holder     the entity indicated (perhaps indirectly) in the                 holder field of the AC   Client        the entity which is requesting the action for