[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

INTERNET-DRAFT                                              S. Farrell
Expires in six months                           Baltimore Technologies
                                                        David Chadwick
                                                 University of Salford
                                                          14 July 2000

             Limited AttributeCertificate Acquisition Protocol

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of [RFC2026].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   The PKIX working group is profiling the use of X.509 attribute
   certificates. This document specifies a deliberately limited
   protocol for requesting an attribute certificate from a server. It
   is intended to be complementary to the use of LDAP for AC retrieval,
   covering, for example, those cases where use of an LDAP server is
   not suitable due to the type of authorization model being employed.
   For many other cases, the use of LDAP is preferred.

Table Of Contents

   Status of this Memo.............................................1
   Table Of Contents...............................................1
   1. Introduction.................................................2
   2. LAAP.........................................................3
       2.1  Message Types..........................................3
           2.1.1  LAAP Request Message.............................3
           2.1.2  LAAP Response Message............................5
       2.2  Encapsulation in CMP...................................6

Farrell & Chadwick                                            [Page 1]

INTERNET-DRAFT                                               July 2000

           2.2.1  PKI Body.........................................6
           2.2.2  PKI Header.......................................6
           2.2.3  PKI Protection...................................7
       2.3  Response Handling......................................7
       2.4  Error Handling.........................................7
   3. Transport Mechanisms.........................................8
   4. Security Considerations......................................9
   5. References...................................................9
   Author's Addresses.............................................10
   Full Copyright Statement.......................................10
   Appendix A: Object Identifiers.................................11
   Appendix B: "Compilable" ASN.1 module..........................12
   Appendix C: Changes this version / Open Issues.................13

1. Introduction

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

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

   [ACPROF] specifies the Internet profile of the X.509 attribute
   certificate (AC) for authorization purposes. This document specifies
   a deliberately limited protocol for requesting such an AC from a

   There is clearly a requirement for an AC management protocol (or
   protocols, like [CMP] and [CMC]). Such management protocols are not
   specified in this document. There is also a requirement for a
   specification of an LDAP schema to allow retrieval of ACs from LDAP
   servers, which is specified in [LDAP-SCHEMA].

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

   LAAP consists of a simple request/response protocol encapsulated in
   [CMP] messages. The entity which issues the request is called the
   LAAP requestor (LRQ), the entity which issues the response is called
   the LAAP responder (LRP). The LRQ is typically an AC holder or an AC
   verifier; the LRP is typically the AC issuer itself.

   The situations in which LAAP may be more suitable for use than LDAP

   - where ACs are very short lived and the latency involved in writing
     to the LDAP servers is relatively long (e.g. if a complex
     directory deployment is behind the LDAP server),

Farrell & Chadwick                                            [Page 2]

INTERNET-DRAFT                                               July 2000

   - where a least privilege style of AC use is required, the LRP can
     modulate the AC content based on the context of the LAAP request,
     for example, if the LRQ is authenticated and the LRP is the AC
     issuer, then the LRP may choose to include only the minimal set of
     attributes (administered to be) required by that LRQ,
   - where there are potentially numerous ACs, many of which are never
     actually used during their lifetime (in which case they should
     only be generated if needed) e.g. many entities have permission to
     access some data, but only a subset of them actually do access it,
   - where ACs contain encrypted attributes and it may not be possible
     to search the LDAP directory for ACs with attributes of a specific

   LAAP is only intended to be used for cases where an LRQ wishes to
   acquire a "current" AC for an entity (possibly itself) leaving
   almost all details as to the content of the AC to the LRP.


   The LAAP protocol consists of two new message types which are
   embedded in the PKI Message Body defined in [CMP]. One message (the
   LAAP Request) is embedded in the GenMsgContent field, the other (the
   LAAP Response) is embedded in the GenRepContent field. Future
   specifications MAY enhance the request and/or response types defined
   here - any such enhancement MUST use a different object identifier
   to identify the GenMsgContent or GenRepContent.

   The one and only feature of this protocol is to request an AC for a
   particular entity that may be either the LRQ or some other entity.
   The response is the requested AC or an error.

2.1 Message Types

2.1.1   LAAP Request Message

   The request MAY specify the identity of the AC holder (for the third
   party case), with an optional "profile". A profile is to be
   interpreted as a bilaterally agreed string, or OID, that may be
   mapped to a set of AC contents by the LRP. In the third party case,
   the LRQ, MAY also include some evidence that the AC holder has
   requested the LRQ to retrieve an AC belonging to the AC holder.

      LACRequestMessage ::= SEQUENCE {
           holder    Holder OPTIONAL,
           profile   [0] SEQUENCE {
                string          UTF8String,
                oid             OBJECT IDENTIFIER
                } OPTIONAL,
           issuer    [1] AttCertIssuer OPTIONAL,
           acOptions ACOptions OPTIONAL

Farrell & Chadwick                                            [Page 3]

INTERNET-DRAFT                                               July 2000

      ACOptions ::= BIT STRING {
        attr-encryption (0),
        proxying        (1),
        object-digests  (2),
        aa-controls     (3)

   Each field is described below.

   "holder": when present this specifies that the LRQ wishes to acquire
   an AC for this holder. When absent, it means that the LRQ is
   requesting an AC for itself (the LRP SHOULD use the identity
   established from whatever authentication is available). The rules
   for the holder field specified in [ACPROF] apply here (e.g.
   constrained use of entityName).

   "profile": when present this is signals that an AC matching the
   supplied profile is returned. The definition of profiles is not in
   scope for this specification and is expected to be a local matter.
   There are two main uses envisaged for this field:

   - Where an LRQ requests its own AC, then the profile field can be
   used for those entities which require a non-default AC. The typical
   case here is where a user requests her AC in order to "push" it to a
   relying party via some protocol (like CMS). In most such cases, the
   user can use a default AC whose content has been selected for her by
   an administrator. Occasionally, such users will require a different
   AC, perhaps for use in some application environment that is seldom
   used. In such cases the profile field can contain a value provided
   to the user by the AA administrator. It is often the case that a
   profile maps well to a role in this scenario.

   - When a relying party requests an AC for another entity it needs
   the AC to contain a set of attributes which will enable the relying
   party to make a "good" authorization decision. In most such cases,
   the identity of the relying party will determine (for the AA) the
   set of attribute types required. However, in cases where the
   identity of the relying party is not known, or where a single
   relying party makes "different" types of authorization decision,
   (say where two applications run from a single account), then the
   profile allows the relying party to specify which "type" of
   authorization decision it wishes to make. It is often the case that
   the profile maps well to an application or function in this

   Where it is desirable that the profile contain a globally unique
   value, the profile SHOULD use the oid choice. Conformant
   implementations MUST be able to handle both string and OID profiles.

   One possible implementation model which can usefully use the OID
   choice is for the profile to contain the OID of an LDAP or X.500
   object class ([X.501], [RFC2526]) and for the LRP to produce an AC

Farrell & Chadwick                                            [Page 4]

INTERNET-DRAFT                                               July 2000

   containing the relevant attribute values specified by that object

   Note that in all cases where a profile is specified by an LRQ, the
   resulting AC may or may not meet the LRQ's expectation for ACs which
   "match" the requested profile. The LRQ MUST check the resulting AC,
   if it needs to check this "matching". Note also, that in addition to
   selecting the "attributes" field, an LRP MAY also use the profile to
   determine other AC fields, e.g. validity or extensions.

   "issuer": This field allows the LRQ to specify the AC issuer in case
   an LRP responds on behalf of more than one AC issuer.

   "acOptions": This field allows the LRQ to indicate the set of the
   optional features from [ACPROF] that the LRQ "supports". Each bit
   may be set independently by the LRQ to indicate support for one of
   the optional features. When this field is not present it should be
   interpreted that all the bits are not set, which has the following

        Attribute encryption is not supported
        Proxying is not supported
        Object digests are not supported
        AA controls are not supported

   Note that if all the optional fields are missing, this means that
   the minimal LAAP request structure consists of the octets æ3000ÆH,
   an empty ASN.1 sequence. This means "give me my current default AC
   please and do not use any optional features from [ACPROF]".

2.1.2   LAAP Response Message

   The response message consists of an AC (errors are handled at the
   CMP level).

      LACResponseMessage ::= AttributeCertificate

   When an LRQ receives an AC from an LRP it SHOULD verify the AC. In
   addition the LRQ SHOULD ensure that the AC "matches" the LAAP
   request issued, i.e. that the holder in the AC matches that in the
   request (if present). Implementations may of course include
   additional checks.

   The AC in the response MUST conform to the profile specified in
   [ACPROF] and MUST only make use of the optional features that the
   LRQ has indicated that it can support.

Farrell & Chadwick                                            [Page 5]

INTERNET-DRAFT                                               July 2000

2.2 Encapsulation in CMP

   LAAP requests and responses are carried within a PKIMessage, as
   defined in [CMP].

      PKIMessage ::= SEQUENCE {
         header           PKIHeader,
         body             PKIBody,
         protection   [0] PKIProtection OPTIONAL,
         extraCerts   [1] SEQUENCE SIZE (1..MAX)
                                OF Certificate OPTIONAL

2.2.1   PKI Body

   The GenMsgContent CHOICE of the PKIBody contains the LAAP request
   and the GenRepContent contains the LAAP response. Each GenMsgContent
   and GenRepContent consists of a SEQUENCE OF InfoTypeAndValue.
   InfoTypeAndValue is an OID and an ANY defined by the OID. There
   SHALL be only one InfoTypeAndValue for both LAAP requests and
   responses. Separate OIDs are defined for LAAP requests and responses
   as follows:

      id-laap-req       OBJECT IDENTIFIER ::= { id-laap 1 }
      id-laap-rep       OBJECT IDENTIFIER ::= { id-laap 2 }

   The ANY field MUST be a LACRequestMessage for a LAAP request, and
   the ANY field MUST be a LACResponseMessage for a LAAP response.

   Errors are handled using the ErrorMsgContent form of PKIBody.

   A conformant implementation is NOT REQUIRED to be able to handle any
   other form of PKIBody. Of course, an LRQ or LRP MAY also handle
   other forms of PKIBody, e.g. the mandatory profile specified in

2.2.2   PKI Header

   The fields of the PKIHeader MUST be used as specified in section
   3.1.1 of [CMP]. <<may need more specification here.>>

        pvno        MUST be ietf-version 3 (2) [CMP2000]
        sender      MUST adhere to the restrictions in [ACPROF].
                    Anonymous requests are allowed provider the holder
                    field is present and MUST include an empty DN for
                    the sender field.
        recipient   MAY be empty DN. Only used for CMP message
                    authentication (e.g. D-H cases)
        generalInfo MUST be absent

   All other fields MUST be as specified in [CMP2000].

Farrell & Chadwick                                            [Page 6]

INTERNET-DRAFT                                               July 2000

2.2.3   PKI Protection

   Though the PKIMessage construct supports the use of various forms of
   authentication, the security required for a specific LAAP request or
   response is not specified here. In order to provide a basic level of
   interoperability LRPs MUST be able to handle requests authenticated
   with either the PasswordBasedMac or signature methods described in
   [CMP] section 3.1.3. LRPs MUST also be able to handle requests which
   contain no PKIProtection (though they MAY always return an error).

   LAAP requestors MUST implement one of PasswordBasedMac, signature or

   Algorithms: the defaults are as in CMP.

2.2.4   Additional Public Key Certificates

   This field MAY contain a set of public key certificates that MAY be
   used by the recipient to assist in verification of authentication of
   the message sender or of an attribute certificate contained in a

   <<Is this the right conformance specification?>>

2.3 Response Handling

   If the LRP provides the AC that the LRQ requested, then a PKIStatus
   of "granted" is returned.

   If the LRP provides an AC that is not exactly what the LRQ requested
   e.g. the AC grants some privileges but less than the LRQ requested,
   then a PKIStatus of "grantedWithMods" is returned. It is a local
   matter for the LRP to decide when to return granted and when to
   return grantedWithMods.

   If the LRP does not return an AC to the LRQ, then a PKIStatus of
   "rejection" SHALL be returned. Section 2.5.4 describes the
   PKIFailureInfo that MUST accompany this status message.

   Other PKIStatus values MUST NOT be returned to the LRQ.

2.4 Error Handling

   If an LRP receives any CMP message which it does not support (e.g. a
   public key certification request), then it MUST respond with an
   error containing "rejection" as the PKIStatus, and "badRequest" as
   the PKIFailureInfo. The status string MAY contain any implementation
   specific value (though note that this field is intended to be human

   For all other error conditions the PKIStatus MUST be "rejection".
   If the LRP fails to authenticate the LRQ, or no or insufficient
   authentication information was provided, and the LRP requires

Farrell & Chadwick                                            [Page 7]

INTERNET-DRAFT                                               July 2000

   authentication, then a PKIFailureInfo of "badMessageCheck" SHALL be

   If the LRP does authenticate the LRQ, but the the LRQ is not
   authorised to receive the AC, then "notAuthorized" SHALL be

   If the LRP detects an incorrectly formatted LACRequestMessage then a
   PKIFailure of "badDataFormat" SHALL be returned.

   If the LRP is unable to return an AC to the LRQ, then a PKIFailure
   of "badCertId" SHALL be returned.

   <<The semantics of this error code are correct and meaningful (i.e.
   no certificate could be found matching the provided criteria).
   However the label "badCertId" does not seem to be so correct, since
   a certificate id was not provided by the LRQ. Therefore we could
   either define a new PKIFailure code ("noCertFound") or we could ask
   that the label in [CMP2000] be changed to "noCertFound", leaving the
   semantics as now, or that [CMP2000] change the semantics of the
   "badCertId" error to "incorrect certificate id provided and no
   certificate could be found that matches it".>>

   If the LRP suspects that the LRQ has contacted the wrong Attribute
   Authority then a PKIFailure of "wrongAuthority" MAY be returned in
   addition to "badCertId".

   In addition to the above, the LRP MAY return a statusString for
   human consumption.

3. Transport Mechanisms

   LAAP can be carried via a number of transport mechanisms: either
   directly over TCP, or by encoding within HTTP.

   Both LRQ and LRP implementations MUST support the TCP transport.
   Either MAY support the HTTP transport.

   [CMP] already defines TCP and HTTP transports. These MAY also be
   used for LAAP. Some changes based on implementation experience have
   been developed in [CMP-Tran]]. These changes supercede the
   equivalent transports defined in [CMP] and MUST be supported by
   compliant implementations.

   LRQs and LRPs are NOT REQUIRED to support polling, as either an AC
   or an error is expected to be produced immediately in response to a
   request. This means that even if an LRP does support other forms of
   [CMP] requests, it cannot use the polling mechanism in response to a
   LAAP request.

Farrell & Chadwick                                            [Page 8]

INTERNET-DRAFT                                               July 2000

4. Security Considerations

   The LRQ MUST verify the AC using the rules given in [ACPROF] before
   making an authorization decision based on the AC. LAAP (like all
   such protocols) is vulnerable to denial-of-service attacks, this
   should be taken into account before deployment. If the LRP is the
   actual AC issuer, then it should be very careful about handing out
   ACs in response to unauthenticated requests. One model would be to
   manage the authentication "strength" required before issuing a given
   (type of) AC.

5. References

  [ACPROF]    Farrell, S., Housley, R. "An Internet
              AttributeCertificate Profile for Authorization",
              draft-ietf-pkix-acprof-04.txt, July 2000, work-in-
  [CMC]       M. Myers, X. Liu, J.Schaad, J. Weinstein. "Certificate
              Management Messages over CMS". RFC 2797. April 2000.
  [CMP]       Adams, C., Farrell, S., "Internet X.509 Public Key
              Infrastructure - Certificate Management Protocols",
              RFC2510. March 1999
  [CMP2000]   Adams, C., Farrell, S., Update to "Internet X.509 Public
              Key Infrastructure - Certificate Management Protocols",
              draft-ietf-pkix-rfc2510bis-01.txt, July 1999, work-in-
  [CMP-Tran]  Kapoor, A. and Tschalar, R. " Transport Protocols for
              CMP", draft-ietf-pkix-cmp-transport-protocols-00.txt,
              June 22 2000, work-in-progress.
  [LDAP-SCHEMA]Chadwick, D., "Internet X.509 Public Key Infrastructure
              Operational Protocols - Additional LDAP Schema for PKIs
              and PMIs <draft-pkix-ldap-schema-00.txt>, July 2000
  [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.
  [RFC2459]   Housley, R., Ford, W., Polk, T, & Solo, D., "Internet
              Public Key Infrastructure - X.509 Certificate and CRL
              profile", RFC2459.
  [RFC2252]   Wahl, M., et al., " Lightweight Directory Access
              Protocol (v3): Attribute Syntax Definitions", RFC2252.
  [RFC2256]   Wahl, M., "A Summary of the X.500(96) User Schema for
              use with LDAPv3", RFC2256.
  [X.501]     ITU-T Recommendation X.501 : Information Technology -
              Open Systems Interconnection - The Directory: Models,

Farrell & Chadwick                                            [Page 9]

INTERNET-DRAFT                                               July 2000

Author's Addresses

   Stephen Farrell,
   Baltimore Technologies,
   61/62 Fitzwilliam Lane,
   Dublin 2,

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

   David Chadwick
   IS Institute
   University of Salford
   M5 4WT

   Tel: +44 161 295 5351
   email: d.w.chadwick@salford.ac.uk

Full Copyright Statement

   Copyright (C) The Internet Society (date).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  In addition,
   the ASN.1 module presented in Appendix B may be used in whole or in
   part without inclusion of the copyright notice.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process shall be
   followed, or as required to translate it into languages other than

   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

Farrell & Chadwick                                           [Page 10]

INTERNET-DRAFT                                               July 2000

Appendix A: Object Identifiers

   This section lists the object identifiers defined in this

   The following object identifiers are inherited from [RFC2459] and

   id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
                dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
      id-mod  OBJECT IDENTIFIER ::= { id-pkix 0 }
      id-it   OBJECT IDENTIFIER ::= { id-pkix 4 }

   The following new ASN.1 module identifier is defined:

      id-mod-laap       OBJECT IDENTIFIER ::= { id-mod <<tbs>> }
      << probably { id-mod 13 }>>

   The LAAP message types are defined as follows:

      id-laap           OBJECT IDENTIFIER ::= { id-it <<tbs>> }
      << probably { id-it 7 } >>
      id-laap-req       OBJECT IDENTIFIER ::= { id-laap 1 }
      id-laap-rep       OBJECT IDENTIFIER ::= { id-laap 2 }

   Note: The following OID has been assigned that may be used during
   testing until an official pkix oid is assigned

        id-laap OBJECT IDENTIFIER ::= 1.2.826.0.1.3344810.5

Farrell & Chadwick                                           [Page 11]

INTERNET-DRAFT                                               July 2000

Appendix B: "Compilable" ASN.1 module

   PKIXLaap {iso(1) identified-organization(3) dod(6)
             internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
             -- temporary, still tbs -- id-mod-laap(13)}

   -- EXPORTS ALL --


      Holder, AttCertIssuer, AttributeCertificate
         PKIXAttributeCertificate {iso(1) identified-organization(3)
                     dod(6) internet(1) security(5) mechanisms(5)
                     pkix(7) id-mod(0) id-mod-attribute-cert(12)}

          PKIX1Explicit88 {iso(1) identified-organization(3)
                     dod(6) internet(1) security(5) mechanisms(5)
                     pkix(7) id-mod(0) id-pkix1-explicit-88(1)} ;

       -- this is referenced, but not defined in [CMP]
      id-it   OBJECT IDENTIFIER ::= { id-pkix 4 }

      id-laap           OBJECT IDENTIFIER ::=
                            { id-it -- temporary, still tbs -- 7 }

      -- these OIDs are used as the infoType of the
      -- GenMsgContent and GenRepContent PKIBody fields respectively
      id-laap-req       OBJECT IDENTIFIER ::= { id-laap 1 }
      id-laap-rep       OBJECT IDENTIFIER ::= { id-laap 2 }

      LACRequestMessage ::= SEQUENCE {
           holder    Holder OPTIONAL,
           profile   [0] SEQUENCE {
                string          UTF8String,
                oid             OBJECT IDENTIFIER
                } OPTIONAL,
           issuer    [1] AttCertIssuer OPTIONAL,
           acOptions ACOptions OPTIONAL
      ACOptions ::= BIT STRING {
           attr-encryption      (0),
           proxying             (1),
           object-digests       (2),
           aa-controls          (3)
      LACResponseMessage ::= AttributeCertificate


Farrell & Chadwick                                           [Page 12]

INTERNET-DRAFT                                               July 2000

Appendix C: Changes this version / Open Issues

   Changes for version 02:

   1.  Synchronized with latest [ACPROF]
   2.  Added GenRepContent for LAAP response
   3.  Added sections on response handling and error codes
   4.  Added provisional OIDs
   5.  Decided not to use UDP transport.

   Changes for version 01:

   1.  Synchronized with latest [ACPROF]
   2.  Samples to separate draft (same as [ACPROF])
   3.  Removed UDP transport requirement
   4.  Changed profile from UTF8 to optional OID and/or UTF8
   5.  Removed holderAuth feature
   6.  Added "supported options" indicator to request

   Changes for version 00:

   1.  This is the first issue, previously LAAP was specified as part
       of the AC profile [ACPROF]
   2.  Changed LAAP so its now encapsulated in [CMP]
   3.  Added more definition of profile field
   4.  Added holderAuth field (probably temporarily)
   5.  Added requirement for UDP transport
   6.  Added compiled ASN.1 module

   Open issues:

   1.  Register new pkix OIDs
   2.  What level of authentication to mandate (if any)
   3.  "badCertID" error code semantics and label to be resolved
   4.  Are details of CMP encapsulation correct, esp. for 2000

Farrell & Chadwick                                           [Page 13]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/