idnits 2.17.1 draft-ietf-pkix-acpolicies-extn-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 6) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 176 has weird spacing: '...olicies may b...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 40, but not defined == Missing Reference: 'PROFILE' is mentioned on line 266, but not defined ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3281 (Obsoleted by RFC 5755) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft C. Francis 2 PKIX Working Group Raytheon 3 April 2003 D. Pinkas 4 Expires: October 2003 Bull 6 Attribute Certificate Policy extension 7 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes one certificate extension to explicitly 32 state the Attribute Certificate (AC) policies that apply to a given 33 Attribute Certificate. 35 Conventions Used In This Document 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 38 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 39 document are to be interpreted as described in [RFC2119]. 41 1. Introduction 43 When issuing a PKC, a Certificate Authority (CA) can perform various 44 levels of verification with regard to the subject identity. A CA makes 45 its verification procedures, as well as other operational rules it 46 abides by, "visible" through a certificate policy, which may be 47 referenced by a certificate policies extension in the PKC. 49 The purpose of this document is to define such an extension, but not 50 the AC policies themselves. 52 2. AC Policy Extension Semantics 54 Attribute Certificates are defined in [RFC3281]. 56 An Attribute Certificate Policy (ACP) is a set of rules that indicates 57 generic rules for registering, verifying, delivering and revoking the 58 attributes contained in a particular Attribute Certificate. 60 It should thus be noticed that an AA does not necessarily support one 61 single policy. However, for each AC that is delivered it SHALL make 62 sure that the policy applies to all the attributes that are contained 63 in it. 65 An Attribute Certificate Policy may be used by a certificate user to 66 decide whether or not to trust the attributes contained in a 67 certificate for a particular purpose. 69 When a certificate contains an AC policies extension, the extension 70 MAY, at the option of the certificate issuer, be either critical or 71 non-critical. 73 The AC Policies extension MAY be included in an attribute certificate. 74 Like all X.509 certificate extensions [X.509], the AC policies 75 extension is defined using ASN.1 [ASN1]. 77 The AC policies extension is identified by id-pe-ac-policies. 79 id-pe-ac-policies OBJECT IDENTIFIER ::= { id-pe 15 } 81 The AC policies extension includes a list of AC policies recognized by 82 the issuing authority that apply to the attributes included in the 83 certificate. 85 AC Policies may be defined by any organization with a need. Object 86 identifiers used to identify AC Policies are assigned in accordance 87 with [ITU-T Rec. X660 | ISO/IEC 9834-1]. 89 The presence of this extension in an attribute certificate indicates 90 the AC policies for which the attribute certificate is valid. 92 An application that recognizes this extension and its content SHALL 93 process the extension regardless of the value of the criticality flag. 95 If the extension is both flagged non-critical and is not recognized, 96 then the application MAY ignore it. 98 If the extension is flagged critical or is recognized, it indicates 99 that the attributes contained in the certificate SHALL only be used 100 for the purpose, and in accordance with the rules implied by one of 101 the indicated AC policies. 103 If the extension is marked critical or is recognized, certificate 104 users MUST use the list of AC policies to determine whether it is 105 appropriate to use the attributes contained in that certificate for 106 a particular transaction. 108 2.1 AC Policy Extension Syntax 110 The syntax for the AC Policy extension is: 112 ac-policies EXTENSION ::= { 113 SYNTAX ac-policiesSyntax 114 IDENTIFIED BY id-pe-ac-policies} 116 ac-policiesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 118 PolicyInformation ::= SEQUENCE { 119 policyIdentifier AcPolicyId, 120 policyQualifiers SEQUENCE SIZE (1..MAX) OF 121 PolicyQualifierInfo OPTIONAL} 123 AcPolicyId ::= OBJECT IDENTIFIER 125 PolicyQualifierInfo ::= SEQUENCE { 126 policyQualifierId PolicyQualifierId, 127 qualifier ANY DEFINED BY policyQualifierId } 129 To promote interoperability, this document RECOMMENDS that policy 130 information terms consist of only an OID. When more than one policy 131 is used, the policy requirements have to be non conflicting, e.g. one 132 policy may refine the general requirements mandated by another policy. 134 2.2 Attribute Certificate Policies 136 The scope of this document is not the definition of the detailed 137 content of Attribute Certificate policies themselves, therefore 138 specific policies are not defined in this document. 140 2.3. Generic Policy Qualifiers 142 This specification defines two generic policy qualifier types for 143 use by certificate policy writers and certificate issuers, which 144 are similar to those used for Certificate Policies in Public Key 145 Certificates. The qualifier types are the CPS Pointer and User 146 Notice qualifiers. 148 The CPS Pointer qualifier contains a pointer to a Certification 149 Practice Statement (CPS) published by the AA. The pointer is in 150 the form of a URI. 152 User notice is intended for display to a relying party when a 153 certificate is used. The application software SHOULD display all 154 user notices in all certificates of the certification path used, 155 except that if a notice is duplicated only one copy need be 156 displayed. To prevent such duplication, this qualifier SHOULD only 157 be present in end-entity certificates. 159 These policies Qualifiers are defined in [RFC3280]. 161 -- policyQualifierIds for Internet policy qualifiers 163 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 164 id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } 165 id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } 167 3. Security Considerations 169 The Attribute Certification Policy defined in this document applies 170 for all the attributes that are included in one AC. AAs shall make sure 171 that the policy applies to all the attributes which are included in the 172 certificates they issue. 174 Attributes may be dynamically grouped in several ACs. It should be 175 observed that since the management of some attributes may be different, 176 different policies may be used by 177 the same AA. 179 4. Normative references 181 [ITU-T Rec. X660 | ITU-T Recommendation Rec X.660 (1992) 182 ISO/IEC 9834-1] | ISO/IEC 9834-1: 1993, Information 183 technology - Open Systems Interconnection 184 Procedures for the operation of OSI 185 Registration Authorities: General procedures. 187 [RFC3280] Certificate and Certificate Revocation List (CRL) Profile. 188 R. Housley, W.Polk, W.Ford, and D. Solo. April 2002. 190 [RFC3281] An Internet Attribute Certificate Profile for Authorization. 191 S. Farrell S. and R. Housley. April 2002. 193 [ASN1] X.680 - X.693 | ISO/IEC 8824: 1-4 Abstract Syntax 194 Notation One (ASN.1). See: 195 http://www.itu.int/ITU-T/studygroups/com17/languages/ and 196 http://asn1.elibel.tm.fr/en/standards/index.htm 198 [X.509] ITU-T Recommendation X.509 (2000): Information Technology � 199 Open Systems Interconnections - The Directory: 200 Public-key and Attribute Frameworks, March 2000 202 Author's Addresses 204 Christopher S. Francis 205 Raytheon 206 1501 72nd Street North, MS 25 207 St. Petersburg, Florida 33764 208 Email: Chris_S_Francis@Raytheon.com 210 Denis Pinkas 211 Bull 212 Rue Jean Jaures 213 78340 Les Clayes-sous-Bois 214 FRANCE 216 Email: Denis.Pinkas@bull.net 218 Full Copyright Statement 220 Copyright (C) The Internet Society 2002. All Rights Reserved. 222 This document and translations of it may be copied and furnished to 223 others, and derivative works that comment on or otherwise explain it or 224 assist in its implementation may be prepared, copied, published and 225 distributed, in whole or in part, without restriction of any kind, 226 provided that the above copyright notice and this paragraph are 227 included on all such copies and derivative works. However, this 228 document itself may not be modified in any way, such as by removing the 229 copyright notice or references to the Internet Society or other 230 Internet organizations, except as needed for the purpose of developing 231 Internet standards in which case the procedures for copyrights defined 232 in the Internet Standards process must be followed, or as required to 233 translate it into languages other than English. 235 The limited permissions granted above are perpetual and will not be 236 revoked by the Internet Society or its successors or assigns. 238 This document and the information contained herein is provided on an 239 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 240 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 241 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 242 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 243 FITNESS FOR A PARTICULAR PURPOSE. 245 Acknowledgement 247 Funding for the RFC Editor function is currently provided by the 248 Internet Society. 250 Annex A (normative): ASN.1 Definitions 252 ASN.1 Module 254 PKIXac-policies { iso(1) identified-organization(3) dod(6) 255 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 256 id-mod-ac-policies(26) } 258 DEFINITIONS IMPLICIT TAGS ::= 260 BEGIN 262 -- EXPORTS ALL -- 264 -- IMPORTS -- 266 -- Imports from RFC 3280 [PROFILE], Appendix A.1 268 PolicyQualifierId 269 FROM PKIX1Explicit88 { iso(1) identified-organization(3) 270 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 271 mod(0) pkix1-explicit(18) } 273 -- Arc for private certificate extensions 274 id-pe OBJECT IDENTIFIER ::= { id-pkix 1} 276 -- Locally defined OIDs 278 -- Attributes 280 id-pe-ac-policies OBJECT IDENTIFIER ::= { id-pe 15 } 282 ac-policies EXTENSION ::= { 283 SYNTAX ac-policiesSyntax 284 IDENTIFIED BY id-pe-ac-policies} 286 ac-policiesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 288 PolicyInformation ::= SEQUENCE { 289 policyIdentifier acPolicyId, 290 policyQualifiers SEQUENCE SIZE (1..MAX) OF 291 PolicyQualifierInfo OPTIONAL} 293 acPolicyId ::= OBJECT IDENTIFIER 295 PolicyQualifierInfo ::= SEQUENCE { 296 policyQualifierId PolicyQualifierId, 297 qualifier ANY DEFINED BY policyQualifierId } 299 END