rfc3281.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,558 行 · 第 1/5 页

Network Working Group                                         S. Farrell
Request for Comments: 3281                        Baltimore Technologies
Category: Standards Track                                     R. Housley
                                                        RSA Laboratories
                                                              April 2002


                   An Internet Attribute Certificate
                       Profile for Authorization

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (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........................................... 11



Farrell & 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........................................ 40

1. 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 contain



Farrell & 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 is




Farrell & 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 Exchanges








Farrell & Housley           Standards Track                     [Page 5]

RFC 3281           An Internet Attribute Certificate          April 2002


1.3 Document Structure

   Section 2 defines some terminology.  Section 3 specifies the
   requirements that this profile is intended to meet.  Section 4
   contains the profile of the X.509 AC.  Section 5 specifies rules for
   AC validation.  Section 6 specifies rules for AC revocation checks.
   Section 7 specifies optional features which MAY be supported;
   however, support for these features is not required for conformance
   to this profile.  Finally, appendices contain the list of OIDs
   required to support this specification and an ASN.1 module.

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