Internet Draft C. Francis PKIX Working Group WetStone Technologies, Inc. October 2002 D. Pinkas Expires: April 2003 Bull Attribute Certificate Policy extension 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 one certificate extension to explicitly state the Attribute Certificate (AC) policies that apply to a given Attribute Certificate. 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 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. Francis, Pinkas Page 1 Internet-Draft AC Policy extension October 2002 When issuing an AC, an Attribute Authority (AA) can perform various levels of initial and subsequent verifications with regard to the attributes that will be contained in attribute certificates. These verification procedures, as well as other operational rules the attribute certification authority abides by, can be made "visible" through an AC policies extension, which may be included in the AC. The purpose of this document is to define such an extension, but not the AC policies themselves. 2. AC Policy 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 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. 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 <> } 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. Francis, Pinkas Page 2 Internet-Draft AC Policy extension October 2002 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 [RFC3280]. 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} 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 defined in this document. Francis, Pinkas Page 3 Internet-Draft AC Policy extension October 2002 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. 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 [RFC3280]. -- 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 two specific policy qualifier types for use by certificate policy writers and certificate issuers. 2.3.2.1. Initial Verification Qualifier Attributes inserted in a certificate are only 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 indicates when the attributes contained in the AC have been initially verified. Francis, Pinkas Page 4 Internet-Draft AC Policy extension October 2002 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 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 an attribute 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 } 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 policy applies to all the attributes which are included in the 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 and/or different policy qualifiers may be used by the same AA. 4. 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. Francis, Pinkas Page 5 Internet-Draft AC Policy extension October 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 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. Francis, Pinkas Page 6 Internet-Draft AC Policy extension October 2002 Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Francis, Pinkas Page 7 Internet-Draft AC Policy extension October 2002 Annex A (normative): ASN.1 Definitions To be provided. Francis, Pinkas Page 8