Internet Draft                                               C. Francis
PKIX Working Group                                             Raytheon
December 2003                                                 D. Pinkas
Expires: June 2004                                                 Bull


                    Attribute Certificate Policies extension
                    <draft-ietf-pkix-acpolicies-extn-05.txt>


Status of this memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.

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 one certificate extension to explicitly
state the Attribute Certificate (AC) policies that apply to a given
Attribute Certificate.  The goal of this document is to allow relying
parties to perform an additional test when validating an AC, i.e. to
assess whether a given AC carrying some attributes can be accepted on
the basis of references to one or more specific AC policies.

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 [RFC 2119].

1. Introduction

When issuing a PKC, a Certificate Authority (CA) can perform various
levels of verification with regard to the subject 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.

The purpose of this document is to define an AC policies extension
able to explicitly state the AC policies that apply to a given AC,
but not the AC policies themselves.

Francis, Pinkas                                                  Page 1


Internet-Draft            AC Policies extension           December 2003


2. AC Policies Extension Semantics

Attribute Certificates are defined in [RFC3281].

An Attribute Certificate Policy (ACP) is a set of rules that 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 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.

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 attribute certificate issuer, be either
critical or non-critical.

The AC Policies extension MAY be included in an attribute certificate.
Like all X.509 certificate extensions [X.509], the AC policies
extension is defined using ASN.1 [ASN1].

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

     id-pe-acPolicies OBJECT IDENTIFIER ::= { id-pe 15 }

The AC policies extension includes a list of AC policies recognized by
the issuing authority that apply to the attributes included in the
attribute certificate.

AC Policies may be defined by any organization with a need.  Object
identifiers used to identify AC Policies 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.

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 attribute certificate SHALL only
be used for the purpose, and in accordance with the rules implied by
one of the indicated AC policies. If none of the AC policy identifiers
is adequate for the application, then the AC MUST be rejected.



Francis, Pinkas                                                  Page 2


Internet-Draft            AC Policies extension           December 2003

If the extension is marked critical or is recognized, certificate
users MUST use the list of AC policies 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 syntax for the AC Policy extension is:

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

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

AcPolicyId ::= OBJECT IDENTIFIER

   PolicyQualifierInfo ::= SEQUENCE {
        policyQualifierId  PolicyQualifierId,
        qualifier          ANY DEFINED BY policyQualifierId }

   -- policyQualifierIds for Internet policy qualifiers

   id-qt            OBJECT IDENTIFIER ::=  { id-pkix 2 }
   id-qt-acps       OBJECT IDENTIFIER ::=  { id-qt 4 }
   id-qt-acunotice  OBJECT IDENTIFIER ::=  { id-qt 5 }

   PolicyQualifierId ::=
        OBJECT IDENTIFIER ( id-qt-acps | id-qt-acunotice )

-- ACPS pointer qualifier

ACPSuri ::= IA5String

-- AC user notice qualifier

ACUserNotice ::= UserNotice

-- UserNotice is defined in [RFC3280]

To promote interoperability, this document RECOMMENDS that policy
information terms consist of only an OID. When more than one policy
is used, the policy requirements have to be non conflicting, e.g. one
policy may refine the general requirements mandated by another policy.

   When qualifiers are used with the special policy anyPolicy, they
   MUST be limited to the qualifiers identified in this section.

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


Francis, Pinkas                                                  Page 3


Internet-Draft            AC Policies extension           December 2003

   The ACPS Pointer qualifier contains a pointer to an Attribute
   Certification Practice Statement (ACPS) published by the AA.
   The pointer is in the form of a URI.  Processing requirements for
   this qualifier are a local matter.

   The AC User notice is intended for display to a relying party when
   an attribute certificate is used.  The application software SHOULD
   display the AC user notice of the attribute certificate. The AC
   user notice is defined in [RFC3280]. It has two optional fields:
   the noticeRef field and the explicitText field.

      The noticeRef field, if used, names an organization and
      identifies, by number, a particular textual statement prepared by
      that organization.  For example, it might identify the
      organization's name and notice number 1.  In a typical
      implementation, the application software will have a notice file
      containing the current set of notices for the AA; the
      application will extract the notice text from the file and
      display it.  Messages MAY be multilingual, allowing the software
      to select the particular language message for its own
      environment.

      An explicitText field includes the textual statement directly in
      the certificate.  The explicitText field is a string with a
      maximum size of 200 characters.

   If both the noticeRef and explicitText options are included in the
   one qualifier and if the application software can locate the notice
   text indicated by the noticeRef option, then that text SHOULD be
   displayed; otherwise, the explicitText string SHOULD be displayed.

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 defined in this document.

3. Security Considerations

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

   Attributes may be dynamically grouped in several ACs. It should be
   observed that since the management of some attributes may be
   different, different policies may be used by the same AA.

   When verifying an Attribute Certificate, a relying party must
   determine first that the AC was issued by a trusted AA and then
   has the appropriate policy.



Francis, Pinkas                                                  Page 4


Internet-Draft            AC Policies extension           December 2003

   Failure of AC issuers to protect their private keys will permit
   an attacker to masquerade as them, potentially generating false ACs
   or revocation status.  Existence of bogus ACs and revocation status
   will undermine confidence in the system.  If the compromise is
   detected, all ACs issued by the AC issuer MUST be revoked.
   Rebuilding after such a compromise will be problematic, so AC
   issuers are advised to implement a combination of strong technical
   measures (e.g., tamper-resistant cryptographic modules) and
   appropriate management procedures (e.g., separation of duties)
   to avoid such an incident.

   Loss of an AC issuer's private signing key may also be problematic.
   The AC issuer would not be able to produce revocation status or
   perform AC renewal.  AC issuers are advised to maintain secure
   backup for signing keys.  The security of the key backup procedures
   is a critical factor in avoiding key compromise.

   The availability and freshness of revocation status will affect the
   degree of assurance that should be placed in a long-lived AC.  While
   long-lived ACs expire naturally, events may occur during its natural
   lifetime which negate the binding between the AC holder and the
   attributes.  If revocation status is untimely or unavailable, the
   assurance associated with the binding is clearly reduced.

   The binding between an AC holder and attributes cannot be stronger
   than the cryptographic module implementation and algorithms used to
   generate the signature.  Short key lengths or weak hash algorithms
   will limit the utility of an AC.  AC issuers are encouraged to note
   advances in cryptology so they can employ strong cryptographic
   techniques.

   If an attribute certificate is tied to the holder's PKC using the
   baseCertificateID component of the Holder field and the PKI in use
   includes a rogue CA with the same issuer name specified in the
   baseCertificateID component, this rogue CA could issue a PKC to a
   malicious party, using the same issuer name and serial number as the
   proper holder's PKC.  Then the malicious party could use this PKC in
   conjunction with the AC.  This scenario SHOULD be avoided by
   properly managing and configuring the PKI so that there cannot be
   two CAs with the same name.  Another alternative is to tie ACs to
   PKCs using the publicKeyCert type in the ObjectDigestInfo field.
   Failing this, AC verifiers have to establish (using other means)
   that the potential collisions cannot actually occur, for example,
   the CPSs of the CAs involved may make it clear that no such name
   collisions can occur.

   Implementers MUST ensure that following validation of an AC, only
   attributes that the issuer is trusted to issue are used in
   authorization decisions.  Other attributes, which MAY be present
   MUST be ignored.  Given that the AA controls PKC extension is
   optional to implement, AC verifiers MUST be provided with this
   information by other means.  Configuration information is a likely
   alternative means.  This becomes very important if an AC verifier
   trusts more than one AC issuer.

Francis, Pinkas                                                  Page 5


Internet-Draft            AC Policies extension           December 2003


4. References

4.1 Normative 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.

[RFC3280]  Certificate and Certificate Revocation List (CRL) Profile.
           R. Housley, W.Polk, W.Ford, and D. Solo. April 2002.

[RFC3281]  An Internet Attribute Certificate Profile for Authorization.
           S. Farrell S. and R. Housley. April 2002.

[ASN1]     X.680 - X.693 | ISO/IEC 8824: 1-4 Abstract Syntax
           Notation One (ASN.1). See:
           http://www.itu.int/ITU-T/studygroups/com17/languages/ and
           http://asn1.elibel.tm.fr/en/standards/index.htm

4.2 Informative reference

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

5. IPR Notice

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights.  Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11.  Copies of claims of
rights made available for publication and any assurances of licenses to
be made available, or the result of an attempt made to obtain a general
license or permission for the use of such proprietary rights by
implementors or users of this specification can be obtained from the
IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this
standard.  Please address the information to the IETF Executive
Director.






Francis, Pinkas                                                  Page 6


Internet-Draft            AC Policies extension           December 2003


Author's Addresses

   Christopher S. Francis
   Raytheon
   1501 72nd Street North, MS 25
   St. Petersburg, Florida  33764
   Email: Chris_S_Francis@Raytheon.com

   Denis Pinkas
   Bull
   Rue Jean Jaures
   78340 Les Clayes-sous-Bois
   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 7


Internet-Draft            AC Policies extension           December 2003

Annex A (normative): ASN.1 Definitions

ASN.1 Module

AcPolicies { iso(1) identified-organization(3) dod(6)
    internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
    id-mod-ac-policies(26) }

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL --

IMPORTS

-- Imports from RFC 3280 [RFC3280], Appendix A.1

      UserNotice, anyPolicy
         FROM PKIX1Implicit88 { iso(1) identified-organization(3)
         dod(6) internet(1) security(5) mechanisms(5) pkix(7)
         id-mod(0) id-pkix1-implicit(19) }

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

-- Locally defined OIDs

   -- policyQualifierIds for Internet policy qualifiers

   id-qt            OBJECT IDENTIFIER ::=  { id-pkix 2 }
   id-qt-acps       OBJECT IDENTIFIER ::=  { id-qt 4 }
   id-qt-acunotice  OBJECT IDENTIFIER ::=  { id-qt 5 }

-- Attributes

     id-pe-acPolicies OBJECT IDENTIFIER ::= { id-pe 15 }

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

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

AcPolicyId ::= OBJECT IDENTIFIER

   PolicyQualifierInfo ::= SEQUENCE {
        policyQualifierId  PolicyQualifierId,
        qualifier          ANY DEFINED BY policyQualifierId }



Francis, Pinkas                                                  Page 9


Internet-Draft            AC Policies extension           December 2003


   PolicyQualifierId ::=
        OBJECT IDENTIFIER ( id-qt-acps | id-qt-acunotice )

-- ACPS pointer qualifier

ACPSuri ::= IA5String

-- AC user notice qualifier

ACUserNotice ::= UserNotice
-- UserNotice is defined in [RFC3280]

END









































Francis, Pinkas                                                 Page 10