PKIX Working Group                                                P. Yee
Internet Draft                                              RSA Security
Expires September 2002                                        March 2002


              Attribute Certificate Request Message Format
                     <draft-ietf-pkix-acrmf-01.txt>


Status of this Memo

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

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   The Certificate Request Message Format ([CRMF]) specifies a format
   for requesting an X.509 public key certificate from a Certification
   Authority (CA), possibly with assistance from an Local Registration
   Authority (LRA).  This specification, ACRMF, is modeled on CRMF,
   extending similar functionality to requests for X.509 attribute cer-
   tificates from Attribute Authorities (AA), possibly via an Attribute
   Registration Authority (ARA).

1.  Introduction

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

   ACRMF is essentially a recasting of CRMF to support attribute certi-
   ficate requests.  As such, the data structures are parallel.  CRMF
   specifies a set of controls for manipulating the certificate request.
   Most of these controls are not applicable to attribute certificates,
   and thus ACRMF presents a more limited set of controls.



Yee                                                             [Page 1]


Internet Draft                                                March 2002


   It is expected that ACRMF will be used in conjunction with [ACMC],
   the modification to [CMC] and [CMCbis] to allow attribute certificate
   requests.  Requested certificates must comply with the provisions of
   [ACPROF].


2.  Overview

   An attribute certificate request consists of:

   a) An AttrCertRequest value, which is made up of information about
   the holder of the proposed attribute certificate, the attributes and
   their values to be populated in the attribute certificate, the vali-
   dity period, and possibly extensions.

   b) Additional registration information that may be conveyed in the
   AttrCertReqMessage.


3.  AttrCertRequestMessage Syntax

   An attribute certificate request message is composed of the attribute
   certificate request and optional registration information.

   AttrCertReqMessages :: SEQUENCE SIZE (1..MAX) OF AttrCertReqMsg

   AttrCertReqMsg :: = SEQUENCE {
       attrCertReq   AttrCertRequest,
       regInfo       Attributes OPTIONAL }

   Attributes ::= SEQUENCE SIZE (1..MAX) OF Attribute

   The AttrCertRequest message contains information that will be used to
   form the attribute certificate.  Additional information that is
   placed in the attribute certificate MAY be supplied by the Attribute
   Registration Authority and will be supplied to the Attribute Author-
   ity.  The information in the request MAY be combined with information
   from other sources to form the attribute certificate.  For example, a
   local database may provide information about each potential attribute
   certificate holder.

   The registration information (regInfo) SHOULD only contain supplemen-
   tary information related to the context of the certification request
   when such information is required to fulfill a certification request.
   This information is not used in the construction of the attribute
   certificate.  This information MAY include subscriber contract infor-
   mation, billing information, or other ancillary information useful to
   fulfillment of the certification request.



Yee                                                             [Page 2]


Internet Draft                                                March 2002


4.  AttrCertRequest Syntax

   The AttrCertRequest syntax consists of an ID, a template of the
   (requestable) certificate content, and message controls.

   AttrCertRequest ::= SEQUENCE {
       attrCertReqID       INTEGER,
       attrCertTemplate    AttrCertTemplate,
       controls            Controls OPTIONAL}

   AttrCertTemplate ::= SEQUENCE {
       version                 [0] AttrCertVersion OPTIONAL, -- version must be v2
       holder                  [1] AttrCertHolder OPTIONAL,
       issuer                  [2] AttrCertIssuer OPTIONAL,
       signature               [3] SignatureAlgorithmIdentifier OPTIONAL,
       attrCertValidityPeriod  [4] AttrCertValidtyPeriod OPTIONAL,
       attributes              [5] Attributes OPTIONAL,
       extensions              [6] Extensions OPTIONAL }

   AttrCertVersion :: = INTEGER { v2(1) }

   AttrCertHolder ::= SEQUENCE {
       baseCertificateID [0] IssuerSerial OPTIONAL
         -- issuer and serial number of the holder's PKC
       entityName        [1] GeneralNames OPTIONAL }
         -- subject name or subject alternative name in the holder's PKC

   SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

   AttCertIssuer ::= CHOICE {
       v1Form   GeneralNames,  -- MUST NOT be used in this profile
       v2Form   [0] V2Form     -- v2 only
   }

   V2Form ::= SEQUENCE {
       issuerName            GeneralNames  OPTIONAL
           -- issuerName MUST be present in this profile
           -- the other forms sometimes used, baseCertificateID and objectDigestInfo,
           -- MUST NOT be present in this profile
   }

   AttrCertValidityPeriod ::= SEQUENCE {
       notBeforeTime  [0]    GeneralizedTime OPTIONAL,
       notAfterTime   [1]    GeneralizedTime OPTIONAL
   }






Yee                                                             [Page 3]


Internet Draft                                                March 2002


5.  Controls Syntax

   The generator of an AttrCertRequest may include one or more control
   values pertaining to the processing of the request.

   Controls ::= SEQUENCE SIZE (1..MAX) OF Attribute

   The following controls are defined (it is recognized that this list
   may expand over time): pmiPubInfo, oldCertID.


5.1.  Publication Information Control

   The pmiPubInfo control enables the holder to control the AA's publi-
   cation of the attribute certificate.  It is defined by the following
   syntax:

   PMIPubInfo ::= SEQUENCE {
       action     INTEGER {
                    doNotPublish   (0),
                    pleasePublish (1) },
       pubInfos   SEQUENCE SIZE (1..MAX} OF PubInfo OPTIONAL }

         -- pubInfos MUST NOT be present if the action is "doNotPublish".
         -- If the action is "pleasePublish" and PubInfos is omitted,
         -- "doNotCare" is assumed.

   PubInfo ::= SEQUENCE {
       pubMethod      PublicationMethod,
       pubLocation    GeneralName OPTIONAL }

   PublicationMethod :: = INTEGER {
       doNotCare (0),
       x500      (1),
       web       (2),
       ldap      (3) }


   If the doNotPublish option is chosen, the holder is requesting that
   the AA not publish the attribute certificate.  The holder may publish
   the certificate him/herself or the attribute certificate may have a
   short validity period, making publication undesirable.

   If the doNotCare method is chosen, or if the PMIPubInfo control is
   omitted from the request, the requester indicates that the AA MAY
   publish the attribute certificate by whatever means the AA deems
   appropriate.




Yee                                                             [Page 4]


Internet Draft                                                March 2002


   If the requester wishes the certificate to appear in at least some
   locations but wishes to enable the AA to make the certificate avail-
   able in other repositories, then multiple PubInfo values should be
   used, with one of these values set to doNotCare.

   The pubLocation field, if supplied, indicates where the requester
   would like the certificate to be found according to the publication
   method selected.  A suitable value using one of the CHOICE values
   from GeneralNames MUST be given if the pubLocation is present.


5.2.  OldCert ID Control

   If present, the OldCertID control specifies the certificate to be
   replaced by the certificate generated in response to the current
   attribute certificate request.  The syntax of its value is:

   AttrCertId ::= Sequence {
       issuer         GeneralName,
       SerialNumber   INTEGER
   }


6.  Security Considerations

   Security considerations are not yet discussed in this memo.

7.  References

   [ACMC]      Yee, P.  Work in progress, March 2001.  "Attribute Certi-
               ficate Management Messages over CMS", draft-ietf-pkix-
               acmc-01.txt.

   [ACPROF]    Farrell, S. and R. Housley.  Work in progress, June 8,
               2001.  "An Internet Atribute Certificate Profile for
               Authorization", draft-ietf-pkix-ac509prof-09.txt.

   [CMC]       Myers, M., X. Liu, J. Schaad, and J. Weinstein.  April
               2000.  "Certificate Management Messages over CMS", RFC
               2797.

   [CMCbis]    Myers, M., X. Liu, J. Schaad, and J. Weinstein.  Work in
               progress, July 2001.  "Certificate Management Messages
               over CMS", draft-ietf-pkix-rfc2797-bis-01.txt.

   [CRMF]      Myers, M., C. Adams, D. Solo, and D. Kemp.  March 1999.
               "Internet X.509 Certificate Request Message Format", RFC
               2511.



Yee                                                             [Page 5]


Internet Draft                                                March 2002


   [RFC2026]   Bradner, S.  October 1996.  "The Internet Standards Pro-
               cess -- Revision 3", RFC 2026, BCP 9.

   [RFC2119]   Bradner, S.  March 1997.  "Key words for use in RFCs to
               Indicate Requirement Levels", RFC 2119, BCP 14.

Author's  Address:

   Peter Yee
   RSA Security
   2955 Campus Drive
   Suite 400
   San Mateo, California 94403
   USA

   email: pyee@rsasecurity.com

Full Copyright Statement

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

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

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
   CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Appendix A: Object Identifiers

   The OID id-pkix has the value
   id-pkix  OBJECT IDENTIFIER ::= { iso(1) identified-organizations(3) dod(6)



Yee                                                             [Page 6]


Internet Draft                                                March 2002


       internet(1) security(5) mechanisms(5) pkix(7) }

   -- arc for Internet X.509 PKI protocols and their components
   id-pkip  OBJECT IDENTIFIER ::= { id-pkix pkip(5) }

   -- Remaining OIDs subject to change due to issuance of actual values or to
   -- changes in the arc placement.

   -- ACRMF arc
   id-acrmf OBJECT IDENTIFIER ::= { id-pkip acrmf(x) }

   -- Registration controls in ACRMF
   id-aCRegCtrl  OBJECT IDENTIFIER ::= { id-acrmf aCRegCtrl(1) }
   id-aCRegCtrl-pmiPublicationInfo  OBJECT IDENTIFIER ::= { id-aCRegCtrl 1 }
   id-aCRegCtrl-oldCertId           OBJECT IDENTIFIER ::= { id-aCRegCtrl 2 }

Appendix B: ASN.1 Module

   PKIXACRMF { iso(1) identified-organizations(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf(X) }

   ACRMF DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   IMPORTS
       -- Directory Authentcation Framework (X.509)
          Extensions
              FROM PKIX1Explicit88 { iso(1) identified-organizations(3) dod(6)
                  internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
                  id-pkix1-explicit-88(1) }

       -- Certificate Extensions (X.509)
          GeneralName
              FROM PKIX1Implicit88 { iso(1) identified-organizations(3) dod(6)
                  internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
                  id-pkix1-implicit-88(2) }

   AttrReqMesssages :: SEQUENCE SIZE (1..MAX) OF AttrCertReqMsg

   AttrCertReqMsg :: = SEQUENCE {
       attrCertReq   AttrCertRequest
       regInfo       SEQUENCE SIZE (1..MAX) OF Attribute OPTIONAL }

   AttrCertRequest ::= SEQUENCE {
       attrCertReqId     INTEGER,          -- ID for matching requests/replies
       attrCertTemplate  AttrCertTemplate,  -- Selected fields of cert to issue
       controls          Controls OPTIONAL } -- Attributes affecting issuance




Yee                                                             [Page 7]


Internet Draft                                                March 2002


   AttrCertTemplate ::= SEQUENCE {
       version                 [0] AttrCertVersion OPTIONAL, -- if used MUST be v2
       holder                  [1] AttrCertHolder OPTIONAL,
       issuer                  [2] AttrCertIssuer OPTIONAL,
       signature               [3] SignatureAlgorithmIdentifier OPTIONAL,
       attrCertValidityPeriod  [4] AttrCertValidtyPeriod OPTIONAL,
       attributes              [5] SEQUENCE OF Attribute  OPTIONAL, -- IMPORTed
       extensions              [6] Extensions OPTIONAL } -- IMPORTed from PKIX#1

   AttrCertVersion :: = INTEGER { v2(1) }

   AttrCertHolder ::= SEQUENCE {
       baseCertificateID [0] IssuerSerial OPTIONAL
         -- the issuer and serial number of the holder's Public Key Certificate
       entityName        [1] GeneralNames OPTIONAL
         -- the name of the claimant or role
   }

   SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

   AttCertIssuer ::= CHOICE {
       v1Form   GeneralNames,  -- MUST NOT be used in this profile
       v2Form   [0] V2Form     -- v2 only
   }

   V2Form ::= SEQUENCE {
       issuerName            GeneralNames  OPTIONAL,
           -- issuerName MUST be present in this profile
           -- the other forms sometimes used, baseCertificateID and objectDigestInfo,
           -- MUST NOT be present in this profile
   }

   AttrCertValidityPeriod ::= SEQUENCE {
       notBeforeTime  [0] GeneralizedTime OPTIONAL,
       notAfterTime   [1] GeneralizedTime OPTIONAL
   }

   Controls ::= SEQUENCE SIZE (1..MAX) OF Attribute













Yee                                                             [Page 8]