[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 05 06 07 08 rfc4476                               
Internet Draft                                                C. Francis
PKIX Working Group                           WetStone Technologies, Inc.
May 2002                                                       D. Pinkas
Expires: November                                                   Bull


                  Attribute Certificate Policies Extension
                   <draft-ietf-pkix-acpolicies-extn-00.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

This document describes a certificate extension to explicitly state the
attribute certificate policies that apply to the attributes contained
in the certificate containing that extension.

It also defines two certificate extensions that may be used to indicate
the location of the public or private repositories where the
certificate is being stored.

Conventions Used In This Document

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 [RFC2119].

1. Introduction

A Public Key Certificate (PKC) binds a specific public key to the
identity of the certificate subject.  When issuing a PKC, a Certificate
Authority (CA) can perform various levels of verification with regard
to this identity.  A CA makes its verification procedures, as well as
other operational rules it abides by, "visible" through a certificate
policy, which may be referenced by a certificate policies extension in
the PKC.


Francis, Pinkas                                                   Page 1


Internet-Draft    Attribute Certificate Policies Extension     June 2002

Attributes may be inserted either in Attribute Certificates (ACs) in
the attributes field [RFC-3281] or in Public Key Certificates (PKCs) in
the subjectDirectoryAttribute extension [RFC-3280].

When issuing a PKC that contains a subjectDirectoryAttribute extension,
a Certificate Authority (CA) can perform various levels of initial and
subsequent verifications with regard to these attributes. The procedure
for handling the attributes may be part of the Certification Policy (CP)
or alternatively may be specified separately in an Attribute Certificate
Policy (ACP).

When issuing an AC, an Attribute Authority (AA) can perform various
levels of initial and subsequent verifications with regard to the
attributes that are contained in that certificate.

These verification procedures, as well as other operational rules the
attribute certification authority abides by, can be made "visible"
through an attribute certificate policies extension, which may be
included in the PKC or the AC as an extension. The purpose of this
document is to define such an extension, but not the attribute
certificate policies themselves.

2. AC Policy Extension Semantics

An Attribute Certificate Policy (ACP) is a named set of rules that
indicates the applicability of the attributes contained in a
certificate to a particular community and/or class of application with
common security requirements; or which indicates generic rules for
registering, verifying, delivering and revoking the attributes
contained in a particular Attribute Certificate.

It should thus be noticed that an AA does not necessarily support only
one single policy. However, for each AC that is delivered it SHALL make
sure that the policy applies to all the attributes that are contained
in it.

The Attribute Certificate Policy is independent from the intended use
of the AC, usually authorization or non-repudiation.

An Attribute Certificate Policy may be used by a certificate user to
decide whether or not to trust the attributes contained in a
certificate for a particular purpose.

When a certificate contains an AC policies extension, the extension
MAY, at the option of the certificate issuer, be either critical or
non-critical.  The extension MAY contain optional qualifiers.

The AC Policies extension MAY be included in an attribute certificate
or in a public-key certificate.  Like all X.509 certificate extensions,
the AC policies extension is defined using ASN.1 [X.208-88, X.209-88].

The AC policies extension is identified by id-pe-acPolicies.

     id-pe-acPolicies OBJECT IDENTIFIER  ::=  { id-pe <<TBD>> }

Francis, Pinkas                                                   Page 2


Internet-Draft    Attribute Certificate Policies Extension     June 2002


The AC policies extension includes a list of AC policies recognized by
the issuing authority that apply to the attributes included in the
certificate, together with optional qualifier information pertaining to
these AC policies.

AC Policies and AC policy qualifier types may be defined by any
organization with a need.  Object identifiers used to identify AC
Policies and AC Policy qualifier types are assigned in accordance with
[ITU-T Rec. X660 | ISO/IEC 9834-1].

The presence of this extension in an attribute certificate indicates
the AC policies for which the attribute certificate is valid.

The presence of this extension in a public-key certificate indicates
the AC policies for which the attributes included in that certificate
are valid.

An application that recognizes this extension and its content SHALL
process the extension regardless of the value of the criticality flag.

If the extension is both flagged non-critical and is not recognized,
then the application MAY ignore it.

If the extension is flagged critical or is recognized, it indicates
that the attributes contained in the certificate SHALL only be used for
the purpose, and in accordance with the rules implied by one of the
indicated AC policies.  The rules of a particular policy MAY require
the certificate-using system to process the qualifier value in a
particular way.

If the extension is marked critical or is recognized, certificate users
MUST use the list of AC policies and associated qualifiers to determine
whether it is appropriate to use the attributes contained in that
certificate for a particular transaction.

2.1 AC Policy Extension Syntax

The AC Policy syntax mirrors the certificate policies extension used for
public key certificates defined in [X.509] and profiled in [RFC-3280].

The syntax for the AC Policy extension is:

acPolicies EXTENSION ::= {
     SYNTAX              acPoliciesSyntax
     IDENTIFIED BY       id-pe-acPolicies}

acPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

PolicyInformation ::= SEQUENCE {
      policyIdentifier      acPolicyId,
      policyQualifiers      SEQUENCE SIZE (1..MAX) OF
                                     PolicyQualifierInfo OPTIONAL}


Francis, Pinkas                                                   Page 3


Internet-Draft    Attribute Certificate Policies Extension     June 2002


acPolicyId ::= OBJECT IDENTIFIER

   PolicyQualifierInfo ::= SEQUENCE {

        policyQualifierId  PolicyQualifierId,

        qualifier          ANY DEFINED BY policyQualifierId }

To promote interoperability, this document RECOMMENDS that policy
information terms consist of only an OID.

2.2 Attribute Certificate Policies

The scope of this document is not the definition of the detailed
content of Attribute Certificate policies themselves, therefore
specific policies are not detailed in this document.

2.3. Policy Qualifiers

2.3.1. Generic Policy Qualifiers

   This specification defines two generic policy qualifier types for
   use by certificate policy writers and certificate issuers.  The
   qualifier types are the CPS Pointer and User Notice qualifiers.

   The CPS Pointer qualifier contains a pointer to a Certification
   Practice Statement (CPS) published by the AA or the CA.  The pointer
   is in the form of a URI.

   User notice is intended for display to a relying party when a
   certificate is used.  The application software SHOULD display all
   user notices in all certificates of the certification path used,
   except that if a notice is duplicated only one copy need be
   displayed.  To prevent such duplication, this qualifier SHOULD only
   be present in end-entity certificates.

These policies Qualifiers are defined in RFC 3280.

   -- policyQualifierIds for Internet policy qualifiers

   id-qt          OBJECT IDENTIFIER ::=  { id-pkix 2 }
   id-qt-cps      OBJECT IDENTIFIER ::=  { id-qt 1 }
   id-qt-unotice  OBJECT IDENTIFIER ::=  { id-qt 2 }

2.3.2. Specific Policy Qualifiers

Specific Policy qualifiers MAY be used to convey important differences
between specific policies to relying parties.

This specification defines three specific policy qualifier types for
use by certificate policy writers and certificate issuers.



Francis, Pinkas                                                   Page 4


Internet-Draft    Attribute Certificate Policies Extension     June 2002

2.3.2.1. Initial Verification Qualifier

Attributes inserted in a certificate are verified at the time of the
initial registration of the attribute for a given end-entity. Unless
a specific revocation request is received and granted by the AA or the
CA, attributes will continue to be certified for the period indicated
by the certificateÆs validity period.

For an AC, since the validity period of an AC can be much shorter than
the period during which the asserted attribute(s) are granted to the
holder, unless specific additional information is included, it cannot
be known when attributes were initially verified.

The initial verification qualifier is only applicable for ACs and
indicates when the attributes contained in the AC have been initially
verified.

   id-qt-iniVer      OBJECT IDENTIFIER ::=  { id-qt W }

   IniVer ::= GeneralizedTime

Note: When an AC contains several attributes with different initial
verification dates, this field contains the oldest verification date.

2.3.2.2. Regular Verification Qualifier

AAs or CAs may choose to regularly verify some attributes so that
relying parties may be more confident about their association with
the end-entity. This information may be made available directly in a
certificate through the Regular Verification qualifier.

The Regular Verification Qualifier indicates that the attributes
contained in the AC are regularly verified and includes the
verification time period.

   id-qt-regVer      OBJECT IDENTIFIER ::=  { id-qt X }

   RegVer ::=  CHOICE {
     days       [0]    INTEGER ,
     months     [1]    INTEGER ,
     years      [2]    INTEGER
   }

2.3.2.3. Repository Qualifiers

When a relying party receives a certificate, it may be useful to avoid
forwarding the certificate itself and pass only a reference to the
certificate, together with a location where the certificate is stored.
In some cases the AA or CA may be responsible for publication of the
certificates it issues. When this is the case, a relying party
can take advantage of the storage performed by or on behalf of the
issuing authority.



Francis, Pinkas                                                   Page 5


Internet-Draft    Attribute Certificate Policies Extension     June 2002

In order to allow a relying party to know that such a storage is
available, two specific qualifiers may be used: the Public Repository
and /or Private Repository qualifiers.

The Public Repository Qualifier indicates that the AC is published in
a public repository.

   id-qt-pubRep      OBJECT IDENTIFIER ::=  { id-qt Y }

   PubRep ::= NULL

The Private Repository Qualifier indicates that the AC is published in
a private repository reserved for some community of users.

   id-qt-prvRep      OBJECT IDENTIFIER ::=  { id-qt Z }

   PrvRep ::= NULL

3. Repository location extensions

The locations of published certificates may be available in the CPS
from the CA or AA.

They may also be explicitly included in the certificate by including a
repository location extension.

The OIDs for these extensions are members of the id-ce arc, which
is defined by the following:

   id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29 }

3.1. Public repository location extension

The Public repository location Extension indicates the location of the
repositories where the certificate is publicly available.

This extension MAY be supported by CAs, AAs and/or applications, and it
MUST be non-critical.

   id-ce-pubRepLoc      OBJECT IDENTIFIER ::=  { id-ce X }

   PubRepLoc ::= SEQUENCE OF GeneralName
                 -- only uniformResourceIdentifier is allowed

3.2. Private repository location extension

The Private repository location Extension indicates the location of the
repositories where the certificate is only available for a community of
users.

This extension MAY be supported by CAs, AAs and/or applications, and it
MUST be non-critical.

   id-ce-prvRepLoc      OBJECT IDENTIFIER ::=  { id-ce Y }

Francis, Pinkas                                                   Page 6


Internet-Draft    Attribute Certificate Policies Extension     June 2002

   PrvRepLoc ::=  SEQUENCE OF GeneralName
                  -- only uniformResourceIdentifier is allowed

4. Security Considerations

The Attribute Certification Policy defined in this document applies
for all the attributes that are included in one AC or one PKC. AAs or
CAs shall make sure that the policy applies to all the attributes which
are included in the certificates they issue.

For AAs, attributes may be dynamically grouped in several ACs. It
should be observed that since the management of some attributes may be
different, different policies and/or different policy qualifiers may be
used by the same AA.

5. References

ITU-T Rec. X660 | ITU-T Recommendation Rec X.660 (1992)
ISO/IEC 9834-1  | ISO/IEC 9834-1: 1993, Information
                  technology - Open Systems Interconnection
                  Procedures for the operation of OSI
                  Registration Authorities: General procedures.

RFC-3280   Certificate and Certificate Revocation List (CRL) Profile.
           R. Housley, W.Polk, W.Ford, and D. Solo. April 2002.

RFC-3281   An Internet Attribute Certificate Profile for Authorization.
           S. Farrell S. and R. Housley. April 2002.

X.208-88   CCITT.  Recommendation X.208: Specification of
           Abstract Syntax Notation One (ASN.1). 1988.

X.209-88   CCITT.  Recommendation X.209: Specification of Basic
           Encoding Rules for Abstract Syntax Notation One (ASN.1).
           1988.

X.509      ITU-T Recommendation X.509 (2000): Information Technology û
           Open Systems Interconnections - The Directory:
           Public-key and Attribute Frameworks, March 2000

Author's Addresses

   Christopher S. Francis
   WetStone Technologies, Inc.
   17755 US Highway 19 North, Suite 150
   Clearwater, Florida   33764

   Email: Chris.Francis@wetstonetech.com







Francis, Pinkas                                                   Page 7


Internet-Draft    Attribute Certificate Policies Extension     June 2002


   Denis Pinkas
   Bull
   68, Route de Versailles
   78434 Louveciennes CEDEX
   FRANCE

   Email: Denis.Pinkas@bull.net

Full Copyright Statement

Copyright (C) The Internet Society 2002. 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 developing 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 MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.















Francis, Pinkas                                                   Page 8