idnits 2.17.1 draft-ietf-pkix-acpolicies-extn-08.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 359. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 383. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 347), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 51, but not defined == Missing Reference: 'RFC 3280' is mentioned on line 56, but not defined ** Obsolete undefined reference: RFC 3280 (Obsoleted by RFC 5280) == Missing Reference: 'RFC 3281' is mentioned on line 290, but not defined ** Obsolete undefined reference: RFC 3281 (Obsoleted by RFC 5755) == Unused Reference: 'RFC3281' is defined on line 318, but no explicit reference was found in the text ** 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 (~~), 6 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 February 2006 D. Pinkas 4 Expires: August 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- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2006). All Rights Reserved. 36 Abstract 38 This document describes one certificate extension to explicitly 39 state the Attribute Certificate Policies (ACPs) that apply to a 40 given Attribute Certificate (AC). The goal of this document is to 41 allow relying parties to perform an additional test when validating 42 an AC, i.e. to assess whether a given AC carrying some attributes 43 can be accepted on the basis of references to one or more specific 44 ACPs. 46 Conventions Used In This Document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in [RFC 2119]. 52 1. Introduction 54 When issuing a Public Key Certificate (PKC), a Certificate 55 Authority (CA) can perform various levels of verification with 56 regard to the subject identity (see [RFC 3280]). A CA makes its 57 verification procedures, as well as other operational rules it 58 abides by, "visible" through a certificate policy, which may be 59 referenced by a certificate policies extension in the PKC. 61 The purpose of this document is to define an AC policies extension 62 able to explicitly state the AC policies that apply to a given AC, 63 but not the AC policies themselves. Attribute Certificates are 64 defined in [RFC 3281]. 66 2. AC Policies Extension Semantics 68 An Attribute Certificate Policy is a named set of rules that 69 indicates the applicability of an AC to a particular community 70 and/or class of application with common security requirements and 71 which defines rules for the generation, issuance and revocation of 72 ACs. It may also include additional rules for attributes 73 registration. 75 It should thus be noticed that an Attribute Authority (AA) does not 76 necessarily support one single ACP. However, for each AC that is 77 delivered the AA SHALL make sure that the policy applies to all 78 the attributes that are contained in it. 80 An ACP may be used by an AC user to decide whether or not to trust 81 the attributes contained in an AC for a particular purpose. 83 When an AC contains an AC policies extension, the extension MAY, 84 at the option of the AA, be either critical or non-critical. 86 The AC Policies extension MAY be included in an AC. Like all 87 X.509 certificate extensions [X.509], the AC policies extension is 88 defined using ASN.1 [ASN1]. See Annex A. 90 The definitions are presented in the 1988 Abstract Syntax Notation 91 One (ASN.1) rather than the 1997 ASN.1 syntax used in the most 92 recent ISO/IEC/ITU-T standards. 94 The AC policies extension is identified by id-pe-acPolicies. 96 id-pe-acPolicies OBJECT IDENTIFIER ::= { iso(1) 97 identified-organization(3) dod(6) internet(1) security(5) 98 mechanisms(5) id-pkix(7) id-pe(1) 15 } 100 The AC policies extension includes a list of AC policies recognized 101 by the AA that apply to the attributes included in the AC. 103 AC Policies may be defined by any organization with a need. Object 104 identifiers used to identify AC Policies are assigned in accordance 105 with [ITU-T Rec. X.660 | ISO/IEC 9834-1]. 107 The AC policies extension in an AC indicates the AC policies for 108 which the AC is valid. 110 An application that recognizes this extension and its content SHALL 111 process the extension regardless of the value of the criticality 112 flag. 114 If the extension is both flagged non-critical and is not recognized 115 by the AC using application, then the application MAY ignore it. 117 If the extension is marked critical or is recognized by the AC 118 using application, it indicates that the attributes contained in 119 the attribute certificate SHALL only be used for the purpose, and 120 in accordance with the rules associated with one of the indicated 121 AC policies. If none of the ACP identifiers is adequate for the 122 application, then the AC MUST be rejected. 124 If the extension is marked critical or is recognized by the AC 125 using application, AC using applications MUST use the list of AC 126 policies to determine whether it is appropriate to use the 127 attributes contained in that AC for a particular transaction. When 128 the appropriate policy is not found, the AC SHALL be rejected. 130 2.1 AC Policy Extension Syntax 132 The syntax for the AC Policy extension is: 134 AcPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 136 PolicyInformation ::= SEQUENCE { 137 policyIdentifier AcPolicyId, 138 policyQualifiers SEQUENCE SIZE (1..MAX) OF 139 PolicyQualifierInfo OPTIONAL} 141 AcPolicyId ::= OBJECT IDENTIFIER 143 PolicyQualifierInfo ::= SEQUENCE { 144 policyQualifierId PolicyQualifierId, 145 qualifier ANY DEFINED BY policyQualifierId } 147 -- policyQualifierIds for Internet policy qualifiers 149 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 150 id-qt-acps OBJECT IDENTIFIER ::= { id-qt 4 } 151 id-qt-acunotice OBJECT IDENTIFIER ::= { id-qt 5 } 153 id-qt-acps OBJECT IDENTIFIER ::= { iso(1) 154 identified-organization(3) dod(6) internet(1) security(5) 155 mechanisms(5) id-pkix(7) id-qt(2) 4 } 157 id-qt-acunotice OBJECT IDENTIFIER ::= { iso(1) 158 identified-organization(3) dod(6) internet(1) security(5) 159 mechanisms(5) id-pkix(7) id-qt(2) 5 } 161 PolicyQualifierId ::= 162 OBJECT IDENTIFIER ( id-qt-acps | id-qt-acunotice ) 164 -- ACPS pointer qualifier 166 ACPSuri ::= IA5String 167 -- ACP statement user notice qualifier 169 ACUserNotice ::= UserNotice 170 -- UserNotice is defined in [RFC3280] 172 To promote interoperability, this document RECOMMENDS that policy 173 information terms consist of only an OID. When more than one policy 174 is used, the policy requirements have to be non-conflicting, e.g. 175 one policy may refine the general requirements mandated by another 176 policy. 178 The extension defined in this specification supports two policy 179 qualifier types for use by ACP writers and AAs. The qualifier 180 types are the ACPS Pointer and the AC User. 182 Notice qualifiers. 184 The ACPS Pointer qualifier contains a pointer to an Attribute 185 Certification Practice Statement (ACPS) published by the AA. 186 The pointer is in the form of a URI. Processing requirements for 187 this qualifier are a local matter. 189 The AC User Notice is intended for display to a relying party when 190 an attribute certificate is used. The application software SHOULD 191 display the AC User Notice of the AC. The AC User Notice is defined 192 in [RFC3280]. It has two optional fields: the noticeRef field and 193 the explicitText field. 195 The noticeRef field, if used, names an organization and 196 identifies, by number, a particular textual statement prepared by 197 that organization. For example, it might identify the 198 organization's name and notice number 1. In a typical 199 implementation, the application software will have a notice file 200 containing the current set of notices for the AA; the 201 application will extract the notice text from the file and 202 display it. Messages MAY be multilingual, allowing the software 203 to select the particular language message for its own 204 environment. 206 An explicitText field includes the textual statement directly in 207 the certificate. The explicitText field is a string with a 208 maximum size of 200 characters. 210 If both the noticeRef and explicitText options are included in the 211 one qualifier and if the application software can locate the notice 212 text indicated by the noticeRef option, then that text SHOULD be 213 displayed; otherwise, the explicitText string SHOULD be displayed. 215 2.2 Attribute Certificate Policies 217 The scope of this document is not the definition of the detailed 218 content of ACPs themselves, therefore specific policies are not 219 defined in this document. 221 3. Security Considerations 223 The ACP defined in this document applies for all the attributes 224 that are included in one AC. AAs SHALL ensure that the ACP applies 225 to all the attributes which are included in the ACs they issue. 227 Attributes may be dynamically grouped in several ACs. It should 228 be observed that since an AC may be issued under more than one ACP, 229 the attributes included in a given AC MUST be compliant with all 230 the ACPs from that AC. 232 When verifying an AC, a relying party MUST determine that the AC 233 was issued by a trusted AA and then has the appropriate policy. 235 Failure of AAs to protect their private keys will permit an 236 attacker to masquerade as them, potentially generating false ACs 237 or revocation status. Existence of bogus ACs and revocation status 238 will undermine confidence in the system. If the compromise is 239 detected, all ACs issued by the AA MUST be revoked. 241 Rebuilding after such a compromise will be problematic, so AAs are 242 advised to implement a combination of strong technical measures 243 (e.g., tamper-resistant cryptographic modules) and appropriate 244 management procedures (e.g., separation of duties) to avoid such 245 an incident. 247 Loss of an AA's private signing key may also be problematic. 248 The AA would not be able to produce revocation status or 249 perform AC renewal (i.e. the issue of a new AC with the same set 250 of attributes with the same values, for the same holder, from the 251 same AA but with a different validity period). AC issuers are 252 advised to maintain secure backup for signing keys. The security 253 of the key backup procedures is a critical factor in avoiding key 254 compromise. 256 The availability and freshness of revocation status will affect the 257 degree of assurance that should be placed in a long-lived AC. While 258 long-lived ACs expire naturally, events may occur during its natural 259 lifetime which negate the binding between the AC holder and the 260 attributes. If revocation status is untimely or unavailable, the 261 assurance associated with the binding is clearly reduced. 263 The binding between an AC holder and attributes cannot be stronger 264 than the cryptographic module implementation and algorithms used to 265 generate the signature. Short key lengths or weak hash algorithms 266 will limit the utility of an AC. AAs are encouraged to note 267 advances in cryptology so they can employ strong cryptographic 268 techniques. 270 If an AC is tied to the holder's PKC using the baseCertificateID 271 component of the Holder field and the PKI in use includes a rogue 272 CA with the same issuer name specified in the baseCertificateID 273 component, this rogue CA could issue a PKC to a malicious party, 274 using the same issuer name and serial number as the proper 275 holder's PKC. Then the malicious party could use this PKC in 276 conjunction with the AC. This scenario SHOULD be avoided by 277 properly managing and configuring the PKI so that there cannot be 278 two CAs with the same name. Another alternative is to tie ACs to 279 PKCs using the publicKeyCert type in the ObjectDigestInfo field. 280 Failing this, AC verifiers have to establish (using other means) 281 that the potential collisions cannot actually occur, for example, 282 the Certificate Policy Statements (CPSs) of the CAs involved may 283 make it clear that no such name collisions can occur. 285 Implementers MUST ensure that following validation of an AC, only 286 attributes that the issuer is trusted to issue are used in 287 authorization decisions. Other attributes, which MAY be present 288 MUST be ignored. AC verifiers SHALL support means of being provided 289 with this information. The AA controls PKC extension (see 290 [RFC 3281]) is one possibility, but is optional to implement. 291 Configuration information is a likely alternative means, while 292 out-of-bands means is also another means. This becomes very 293 important if an AC verification application trusts more than one 294 AC issuer. 296 4. IANA Considerations 298 The AC policies extension is identified by an object identifier 299 (OID). The OID for the AC policies extension defined in this 300 document was assigned from an arc delegated by the IANA to the PKIX 301 Working Group. 303 No further action by the IANA is necessary for this document. 305 5. References 307 5.1 Normative references 309 [ITU-T Rec. X.660 | ITU-T Recommendation Rec X.660 (1992) 310 ISO/IEC 9834-1] | ISO/IEC 9834-1: 1993, Information 311 technology - Open Systems Interconnection 312 Procedures for the operation of OSI 313 Registration Authorities: General procedures. 315 [RFC3280] Certificate and Certificate Revocation List (CRL) Profile. 316 R. Housley, W.Polk, W.Ford, and D. Solo. April 2002. 318 [RFC3281] An Internet Attribute Certificate Profile for 319 Authorization. S. Farrell S. and R. Housley. April 2002. 321 [ASN1] X.680 - X.693 | ISO/IEC 8824: 1-4 Abstract Syntax 322 Notation One (ASN.1). 324 5.2 Informative reference 326 [X.509] ITU-T Recommendation X.509 (2000): Information Technology 327 Open Systems Interconnections - The Directory: 328 Public-key and Attribute Frameworks, March 2000 330 Author's Addresses 332 Christopher S. Francis 333 Raytheon 334 1501 72nd Street North, MS 25 335 St. Petersburg, Florida 33764 336 Email: Chris_S_Francis@Raytheon.com 338 Denis Pinkas 339 Bull 340 Rue Jean Jaures 341 78340 Les Clayes-sous-Bois 342 FRANCE 343 Email: Denis.Pinkas@bull.net 345 Full Copyright Statement 347 Copyright (C) The Internet Society (2006). 349 This document is subject to the rights, licenses and restrictions 350 contained in BCP 78, and except as set forth therein, the authors 351 retain all their rights. 353 This document and the information contained herein are provided on 354 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 355 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 356 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 357 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 358 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 359 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 361 Intellectual Property 363 The IETF takes no position regarding the validity or scope of any 364 Intellectual Property Rights or other rights that might be claimed 365 to pertain to the implementation or use of the technology described 366 in this document or the extent to which any license under such 367 rights might or might not be available; nor does it represent that 368 it has made any independent effort to identify any such rights. 369 Information on the procedures with respect to rights in RFC 370 documents can be found in BCP 78 and BCP 79. 372 Copies of IPR disclosures made to the IETF Secretariat and any 373 assurances of licenses to be made available, or the result of an 374 attempt made to obtain a general license or permission for the use 375 of such proprietary rights by implementers or users of this 376 specification can be obtained from the IETF on-line IPR repository 377 at http://www.ietf.org/ipr. 379 The IETF invites any interested party to bring to its attention 380 any copyrights, patents or patent applications, or other 381 proprietary rights that may cover technology that may be required 382 to implement this standard. Please address the information to the 383 IETF at ietf-ipr@ietf.org. 385 Acknowledgement 387 Funding for the RFC Editor function is currently provided by the 388 Internet Society. 390 Annex A (normative): ASN.1 Definitions 392 ASN.1 Module 394 AcPolicies { iso(1) identified-organization(3) dod(6) 395 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 396 id-mod-ac-policies(26) } 398 DEFINITIONS IMPLICIT TAGS ::= 400 BEGIN 402 -- EXPORTS ALL -- 404 IMPORTS 406 -- Imports from RFC 3280 [RFC3280], Appendix A 408 UserNotice 409 FROM PKIX1Implicit88 { iso(1) identified-organization(3) 410 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 411 id-mod(0) 19 } 413 id-pkix, id-pe 414 FROM PKIX1Explicit88 { iso(1) identified-organization(3) 415 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 416 id-mod(0) 18 }; 418 -- Locally defined OIDs 420 -- policyQualifierIds for Internet policy qualifiers 422 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 423 id-qt-acps OBJECT IDENTIFIER ::= { id-qt 4 } 424 id-qt-acunotice OBJECT IDENTIFIER ::= { id-qt 5 } 426 -- Attributes 428 id-pe-acPolicies OBJECT IDENTIFIER ::= { id-pe 15 } 430 AcPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 432 PolicyInformation ::= SEQUENCE { 433 policyIdentifier AcPolicyId, 434 policyQualifiers SEQUENCE SIZE (1..MAX) OF 435 PolicyQualifierInfo OPTIONAL } 437 AcPolicyId ::= OBJECT IDENTIFIER 439 PolicyQualifierInfo ::= SEQUENCE { 440 policyQualifierId PolicyQualifierId, 441 qualifier ANY DEFINED BY policyQualifierId } 443 PolicyQualifierId ::= 444 OBJECT IDENTIFIER ( id-qt-acps | id-qt-acunotice ) 445 -- ACPS pointer qualifier 447 ACPSuri ::= IA5String 448 -- ACP statement user notice qualifier 450 ACUserNotice ::= UserNotice 451 -- UserNotice is defined in [RFC3280] 453 END