idnits 2.17.1 draft-ietf-pkix-acpolicies-extn-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 335. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 359. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 323), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 33. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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: 'RFC 2119' is mentioned on line 50, 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: 8 errors (**), 0 flaws (~~), 3 warnings (==), 8 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 December 2005 D. Pinkas 4 Expires: June 2006 Bull 6 Attribute Certificate Policies extension 7 9 Status of this memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2005). All Rights Reserved. 35 Abstract 37 This document describes one certificate extension to explicitly 38 state the Attribute Certificate Policies (ACPs) that apply to a 39 given Attribute Certificate (AC). The goal of this document is to 40 allow relying parties to perform an additional test when validating 41 an AC, i.e. to assess whether a given AC carrying some attributes 42 can be accepted on the basis of references to one or more specific 43 ACPs. 45 Conventions Used In This Document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in [RFC 2119]. 51 1. Introduction 53 When issuing a PKC, a Certificate Authority (CA) can perform various 54 levels of verification with regard to the subject identity. A CA 55 makes its verification procedures, as well as other operational 56 rules it abides by, "visible" through a certificate policy, which 57 may be referenced by a certificate policies extension in the PKC. 59 The purpose of this document is to define an AC policies extension 60 able to explicitly state the AC policies that apply to a given AC, 61 but not the AC policies themselves. 63 2. AC Policies Extension Semantics 65 Attribute Certificates are defined in [RFC3281]. 67 An Attribute Certificate Policy is a named set of rules that 68 indicates the applicability of an AC to a particular community 69 and/or class of application with common security requirements and 70 which defines rules for the generation, issuance and revocation of 71 ACs. It may also include additional rules for attributes 72 registration. 74 It should thus be noticed that an Attribute Authority (AA) does not 75 necessarily support one single ACP. However, for each AC that is 76 delivered it SHALL make sure that the policy applies to all the 77 attributes that are contained in it. 79 An ACP may be used by an AC user to decide whether or not to trust 80 the attributes contained in an AC for a particular purpose. 82 When an AC contains an AC policies extension, the extension MAY, 83 at the option of the AA, be either critical or non-critical. 85 The AC Policies extension MAY be included in an AC. Like all 86 X.509 certificate extensions [X.509], the AC policies extension is 87 defined using ASN.1 [ASN1]. 89 The AC policies extension is identified by id-pe-acPolicies. 91 id-pe-acPolicies OBJECT IDENTIFIER ::= { id-pe 15 } 93 The AC policies extension includes a list of AC policies recognized 94 by the AA that apply to the attributes included in the AC. 96 AC Policies may be defined by any organization with a need. Object 97 identifiers used to identify AC Policies are assigned in accordance 98 with [ITU-T Rec. X660 | ISO/IEC 9834-1]. 100 The AC policies extension in an AC indicates the AC policies for 101 which the AC is valid. 103 An application that recognizes this extension and its content SHALL 104 process the extension regardless of the value of the criticality 105 flag. 107 If the extension is both flagged non-critical and is not recognized 108 by the AC using application, then the application MAY ignore it. 110 If the extension is marked critical or is recognized by the AC 111 using application, it indicates that the attributes contained in 112 the attribute certificate SHALL only be used for the purpose, and 113 in accordance with the rules associated with one of the indicated 114 AC policies. If none of the ACP identifiers is adequate for the 115 application, then the AC MUST be rejected. 117 If the extension is marked critical or is recognized by the AC 118 using application, the AC using application MUST use the list of 119 AC policies to determine whether it is appropriate to use the 120 attributes contained in that AC for a particular transaction. 122 2.1 AC Policy Extension Syntax 124 The syntax for the AC Policy extension is: 126 AcPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 128 PolicyInformation ::= SEQUENCE { 129 policyIdentifier AcPolicyId, 130 policyQualifiers SEQUENCE SIZE (1..MAX) OF 131 PolicyQualifierInfo OPTIONAL} 133 AcPolicyId ::= OBJECT IDENTIFIER 135 PolicyQualifierInfo ::= SEQUENCE { 136 policyQualifierId PolicyQualifierId, 137 qualifier ANY DEFINED BY policyQualifierId } 139 -- policyQualifierIds for Internet policy qualifiers 141 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 142 id-qt-acps OBJECT IDENTIFIER ::= { id-qt 4 } 143 id-qt-acunotice OBJECT IDENTIFIER ::= { id-qt 5 } 145 PolicyQualifierId ::= 146 OBJECT IDENTIFIER ( id-qt-acps | id-qt-acunotice ) 148 -- ACPS pointer qualifier 150 ACPSuri ::= IA5String 151 -- ACP statement user notice qualifier 153 ACUserNotice ::= UserNotice 154 -- UserNotice is defined in [RFC3280] 155 To promote interoperability, this document RECOMMENDS that policy 156 information terms consist of only an OID. When more than one policy 157 is used, the policy requirements have to be non-conflicting, e.g. 158 one policy may refine the general requirements mandated by another 159 policy. 161 When qualifiers are used with the special policy anyPolicy, they 162 MUST be limited to the qualifiers identified in this section. 164 This specification defines two policy qualifier types for use by 165 ACP writers and AAs. The qualifier types are the ACPS Pointer and 166 the AC User 168 Notice qualifiers. 170 The ACPS Pointer qualifier contains a pointer to an Attribute 171 Certification Practice Statement (ACPS) published by the AA. 172 The pointer is in the form of a URI. Processing requirements for 173 this qualifier are a local matter. 175 The AC User Notice is intended for display to a relying party when 176 an attribute certificate is used. The application software SHOULD 177 display the AC User Notice of the AC. The AC User Notice is defined 178 in [RFC3280]. It has two optional fields: the noticeRef field and 179 the explicitText field. 181 The noticeRef field, if used, names an organization and 182 identifies, by number, a particular textual statement prepared by 183 that organization. For example, it might identify the 184 organization's name and notice number 1. In a typical 185 implementation, the application software will have a notice file 186 containing the current set of notices for the AA; the 187 application will extract the notice text from the file and 188 display it. Messages MAY be multilingual, allowing the software 189 to select the particular language message for its own 190 environment. 192 An explicitText field includes the textual statement directly in 193 the certificate. The explicitText field is a string with a 194 maximum size of 200 characters. 196 If both the noticeRef and explicitText options are included in the 197 one qualifier and if the application software can locate the notice 198 text indicated by the noticeRef option, then that text SHOULD be 199 displayed; otherwise, the explicitText string SHOULD be displayed. 201 2.2 Attribute Certificate Policies 203 The scope of this document is not the definition of the detailed 204 content of ACPs themselves, therefore specific policies are not 205 defined in this document. 207 3. Security Considerations 209 The ACP defined in this document applies for all the attributes 210 that are included in one AC. AAs SHALL ensure that the ACP applies 211 to all the attributes which are included in the ACs they issue. 213 Attributes may be dynamically grouped in several ACs. It should 214 be observed that since an AC may be issued under more than one ACP, 215 the attributes included in a given AC MUST be compliant with all 216 the ACPs from that AC. 218 When verifying an AC, a relying party MUST determine that the AC 219 was issued by a trusted AA and then has the appropriate policy. 221 Failure of AAs to protect their private keys will permit an 222 attacker to masquerade as them, potentially generating false ACs 223 or revocation status. Existence of bogus ACs and revocation status 224 will undermine confidence in the system. If the compromise is 225 detected, all ACs issued by the AA MUST be revoked. 227 Rebuilding after such a compromise will be problematic, so AAs are 228 advised to implement a combination of strong technical measures 229 (e.g., tamper-resistant cryptographic modules) and appropriate 230 management procedures (e.g., separation of duties) to avoid such 231 an incident. 233 Loss of an AA's private signing key may also be problematic. 234 The AA would not be able to produce revocation status or 235 perform AC renewal (i.e. the issue of a new AC with the same set 236 of attributes with the same values, for the same holder, from the 237 same AA but with a different validity period). AC issuers are 238 advised to maintain secure backup for signing keys. The security 239 of the key backup procedures is a critical factor in avoiding key 240 compromise. 242 The availability and freshness of revocation status will affect the 243 degree of assurance that should be placed in a long-lived AC. While 244 long-lived ACs expire naturally, events may occur during its natural 245 lifetime which negate the binding between the AC holder and the 246 attributes. If revocation status is untimely or unavailable, the 247 assurance associated with the binding is clearly reduced. 249 The binding between an AC holder and attributes cannot be stronger 250 than the cryptographic module implementation and algorithms used to 251 generate the signature. Short key lengths or weak hash algorithms 252 will limit the utility of an AC. AAs are encouraged to note 253 advances in cryptology so they can employ strong cryptographic 254 techniques. 256 If an AC is tied to the holder's PKC using the baseCertificateID 257 component of the Holder field and the PKI in use includes a rogue 258 CA with the same issuer name specified in the baseCertificateID 259 component, this rogue CA could issue a PKC to a malicious party, 260 using the same issuer name and serial number as the proper 261 holder's PKC. Then the malicious party could use this PKC in 262 conjunction with the AC. This scenario SHOULD be avoided by 263 properly managing and configuring the PKI so that there cannot be 264 two CAs with the same name. Another alternative is to tie ACs to 265 PKCs using the publicKeyCert type in the ObjectDigestInfo field. 266 Failing this, AC verifiers have to establish (using other means) 267 that the potential collisions cannot actually occur, for example, 268 the CPSs of the CAs involved may make it clear that no such name 269 collisions can occur. 271 Implementers MUST ensure that following validation of an AC, only 272 attributes that the issuer is trusted to issue are used in 273 authorization decisions. Other attributes, which MAY be present 274 MUST be ignored. AC verifiers SHALL support means of being provided 275 with this information. The AA controls PKC extension is one 276 possibility, but is optional to implement. Configuration 277 information is a likely alternative means, while out-of-bands means 278 is also another means. This becomes very important if an AC 279 verification application trusts more than one AC issuer. 281 4. References 283 4.1 Normative references 285 [ITU-T Rec. X660 | ITU-T Recommendation Rec X.660 (1992) 286 ISO/IEC 9834-1] | ISO/IEC 9834-1: 1993, Information 287 technology - Open Systems Interconnection 288 Procedures for the operation of OSI 289 Registration Authorities: General procedures. 291 [RFC3280] Certificate and Certificate Revocation List (CRL) Profile. 292 R. Housley, W.Polk, W.Ford, and D. Solo. April 2002. 294 [RFC3281] An Internet Attribute Certificate Profile for Authorization. 295 S. Farrell S. and R. Housley. April 2002. 297 [ASN1] X.680 - X.693 | ISO/IEC 8824: 1-4 Abstract Syntax 298 Notation One (ASN.1). 300 4.2 Informative reference 302 [X.509] ITU-T Recommendation X.509 (2000): Information Technology 303 Open Systems Interconnections - The Directory: 304 Public-key and Attribute Frameworks, March 2000 306 Author's Addresses 308 Christopher S. Francis 309 Raytheon 310 1501 72nd Street North, MS 25 311 St. Petersburg, Florida 33764 312 Email: Chris_S_Francis@Raytheon.com 314 Denis Pinkas 315 Bull 316 Rue Jean Jaures 317 78340 Les Clayes-sous-Bois 318 FRANCE 319 Email: Denis.Pinkas@bull.net 321 Full Copyright Statement 323 Copyright (C) The Internet Society (2005). 325 This document is subject to the rights, licenses and restrictions 326 contained in BCP 78, and except as set forth therein, the authors 327 retain all their rights. 329 This document and the information contained herein are provided on an 330 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 331 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 332 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 333 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 334 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 335 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 337 Intellectual Property 339 The IETF takes no position regarding the validity or scope of any 340 Intellectual Property Rights or other rights that might be claimed 341 to pertain to the implementation or use of the technology described 342 in this document or the extent to which any license under such 343 rights might or might not be available; nor does it represent that 344 it has made any independent effort to identify any such rights. 345 Information on the procedures with respect to rights in RFC 346 documents can be found in BCP 78 and BCP 79. 348 Copies of IPR disclosures made to the IETF Secretariat and any 349 assurances of licenses to be made available, or the result of an 350 attempt made to obtain a general license or permission for the use 351 of such proprietary rights by implementers or users of this 352 specification can be obtained from the IETF on-line IPR repository 353 at http://www.ietf.org/ipr. 355 The IETF invites any interested party to bring to its attention 356 any copyrights, patents or patent applications, or other 357 proprietary rights that may cover technology that may be required 358 to implement this standard. Please address the information to the 359 IETF at ietf-ipr@ietf.org. 361 Acknowledgement 363 Funding for the RFC Editor function is currently provided by the 364 Internet Society. 366 Annex A (normative): ASN.1 Definitions 368 ASN.1 Module 370 AcPolicies { iso(1) identified-organization(3) dod(6) 371 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 372 id-mod-ac-policies(26) } 374 DEFINITIONS IMPLICIT TAGS ::= 376 BEGIN 378 -- EXPORTS ALL -- 380 IMPORTS 382 -- Imports from RFC 3280 [RFC3280], Appendix A 384 UserNotice, anyPolicy 385 FROM PKIX1Implicit88 { iso(1) identified-organization(3) 386 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 387 id-mod(0) id-pkix1-implicit(19) } 389 id-pkix, id-pe 390 FROM PKIX1Explicit88 { iso(1) identified-organization(3) 391 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 392 id-mod(0) id-pkix1-explicit(18) }; 394 -- Locally defined OIDs 396 -- policyQualifierIds for Internet policy qualifiers 398 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 399 id-qt-acps OBJECT IDENTIFIER ::= { id-qt 4 } 400 id-qt-acunotice OBJECT IDENTIFIER ::= { id-qt 5 } 402 -- Attributes 404 id-pe-acPolicies OBJECT IDENTIFIER ::= { id-pe 15 } 406 AcPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 408 PolicyInformation ::= SEQUENCE { 409 policyIdentifier AcPolicyId, 410 policyQualifiers SEQUENCE SIZE (1..MAX) OF 411 PolicyQualifierInfo OPTIONAL } 413 AcPolicyId ::= OBJECT IDENTIFIER 415 PolicyQualifierInfo ::= SEQUENCE { 416 policyQualifierId PolicyQualifierId, 417 qualifier ANY DEFINED BY policyQualifierId } 419 PolicyQualifierId ::= 420 OBJECT IDENTIFIER ( id-qt-acps | id-qt-acunotice ) 421 -- ACPS pointer qualifier 423 ACPSuri ::= IA5String 424 -- ACP statement user notice qualifier 426 ACUserNotice ::= UserNotice 427 -- UserNotice is defined in [RFC3280] 429 END