idnits 2.17.1 draft-ietf-pkix-acpolicies-extn-06.txt: -(304): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 361. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 325), 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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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 (~~), 4 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 September 2005 D. Pinkas 4 Expires: March 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 a certificate user to decide whether or not 80 to trust the attributes contained in a certificate for a particular 81 purpose. 83 When a certificate contains an AC policies extension, the extension 84 MAY, at the option of the AA, be either critical or non-critical. 86 The AC Policies extension MAY be included in an attribute 87 certificate. Like all X.509 certificate extensions [X.509], the 88 AC policies extension is defined using ASN.1 [ASN1]. 90 The AC policies extension is identified by id-pe-acPolicies. 92 id-pe-acPolicies OBJECT IDENTIFIER ::= { id-pe 15 } 94 The AC policies extension includes a list of AC policies recognized 95 by the AA that apply to the attributes included in the AC. 97 AC Policies may be defined by any organization with a need. Object 98 identifiers used to identify AC Policies are assigned in accordance 99 with [ITU-T Rec. X660 | ISO/IEC 9834-1]. 101 The AC policies extension in an AC indicates the AC policies for 102 which the AC is valid. 104 An application that recognizes this extension and its content SHALL 105 process the extension regardless of the value of the criticality 106 flag. 108 If the extension is both flagged non-critical and is not recognized, 109 then the application MAY ignore it. 111 If the extension is flagged critical or is recognized, it indicates 112 that the attributes contained in the attribute certificate SHALL 113 only be used for the purpose, and in accordance with the rules 114 associated with one of the indicated AC policies. If none of the 115 ACP identifiers is adequate for the application, then the AC MUST 116 be rejected. 118 If the extension is marked critical or is recognized, certificate 119 users MUST use the list of AC policies to determine whether it is 120 appropriate to use the attributes contained in that certificate for 121 a particular transaction. 123 2.1 AC Policy Extension Syntax 125 The syntax for the AC Policy extension is: 127 AcPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 129 PolicyInformation ::= SEQUENCE { 130 policyIdentifier AcPolicyId, 131 policyQualifiers SEQUENCE SIZE (1..MAX) OF 132 PolicyQualifierInfo OPTIONAL} 134 AcPolicyId ::= OBJECT IDENTIFIER 136 PolicyQualifierInfo ::= SEQUENCE { 137 policyQualifierId PolicyQualifierId, 138 qualifier ANY DEFINED BY policyQualifierId } 140 -- policyQualifierIds for Internet policy qualifiers 142 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 143 id-qt-acps OBJECT IDENTIFIER ::= { id-qt 4 } 144 id-qt-acunotice OBJECT IDENTIFIER ::= { id-qt 5 } 146 PolicyQualifierId ::= 147 OBJECT IDENTIFIER ( id-qt-acps | id-qt-acunotice ) 149 -- ACPS pointer qualifier 151 ACPSuri ::= IA5String 152 -- ACP statement user notice qualifier 154 ACUserNotice ::= UserNotice 155 -- UserNotice is defined in [RFC3280] 156 To promote interoperability, this document RECOMMENDS that policy 157 information terms consist of only an OID. When more than one policy 158 is used, the policy requirements have to be non-conflicting, e.g. 159 one policy may refine the general requirements mandated by another 160 policy. 162 When qualifiers are used with the special policy anyPolicy, they 163 MUST be limited to the qualifiers identified in this section. 165 This specification defines two policy qualifier types for use by 166 ACP writers and AAs. The qualifier types are the ACPS Pointer and 167 the AC User 169 Notice qualifiers. 171 The ACPS Pointer qualifier contains a pointer to an Attribute 172 Certification Practice Statement (ACPS) published by the AA. 173 The pointer is in the form of a URI. Processing requirements for 174 this qualifier are a local matter. 176 The AC User Notice is intended for display to a relying party when 177 an attribute certificate is used. The application software SHOULD 178 display the AC user Notice of the AC. The AC user Notice is 179 defined in [RFC3280]. It has two optional fields: 181 the noticeRef field and the explicitText field. 183 The noticeRef field, if used, names an organization and 184 identifies, by number, a particular textual statement prepared by 185 that organization. For example, it might identify the 186 organization's name and notice number 1. In a typical 187 implementation, the application software will have a notice file 188 containing the current set of notices for the AA; the 189 application will extract the notice text from the file and 190 display it. Messages MAY be multilingual, allowing the software 191 to select the particular language message for its own 192 environment. 194 An explicitText field includes the textual statement directly in 195 the certificate. The explicitText field is a string with a 196 maximum size of 200 characters. 198 If both the noticeRef and explicitText options are included in the 199 one qualifier and if the application software can locate the notice 200 text indicated by the noticeRef option, then that text SHOULD be 201 displayed; otherwise, the explicitText string SHOULD be displayed. 203 2.2 Attribute Certificate Policies 205 The scope of this document is not the definition of the detailed 206 content of Attribute Certificate policies themselves, therefore 207 specific policies are not defined in this document. 209 3. Security Considerations 211 The ACP defined in this document applies for all the attributes 212 that are included in one AC. AAs shall make sure that the ACP 213 applies to all the attributes which are included in the ACs they 214 issue. 216 Attributes may be dynamically grouped in several ACs. It should 217 be observed that since an AC may be issued under more than one ACP, 218 the attributes included in a given AC must be compliant with all 219 the ACPs from that AC. 221 When verifying an AC, a relying party MUST determine that the AC 222 was issued by a trusted AA and then has the appropriate policy. 224 Failure of AAs to protect their private keys will permit an 225 attacker to masquerade as them, potentially generating false ACs 226 or revocation status. Existence of bogus ACs and revocation status 227 will undermine confidence in the system. If the compromise is 228 detected, all ACs issued by the AA MUST be revoked. 230 Rebuilding after such a compromise will be problematic, so AC 231 issuers are advised to implement a combination of strong technical 232 measures (e.g., tamper-resistant cryptographic modules) and 233 appropriate management procedures (e.g., separation of duties) 234 to avoid such an incident. 236 Loss of an AA's private signing key may also be problematic. 237 The AA would not be able to produce revocation status or 238 perform AC renewal (i.e. the issue of a new AC with the same set 239 of attributes with the same values, for the same holder, from the 240 same AA but with a different validity period). AC issuers are 241 advised to maintain secure backup for signing keys. The security 242 of the key backup procedures is a critical factor in avoiding key 243 compromise. 245 The availability and freshness of revocation status will affect the 246 degree of assurance that should be placed in a long-lived AC. While 247 long-lived ACs expire naturally, events may occur during its natural 248 lifetime which negate the binding between the AC holder and the 249 attributes. If revocation status is untimely or unavailable, the 250 assurance associated with the binding is clearly reduced. 252 The binding between an AC holder and attributes cannot be stronger 253 than the cryptographic module implementation and algorithms used to 254 generate the signature. Short key lengths or weak hash algorithms 255 will limit the utility of an AC. AAs are encouraged to note 256 advances in cryptology so they can employ strong cryptographic 257 techniques. 259 If an AC is tied to the holder's PKC using the baseCertificateID 260 component of the Holder field and the PKI in use includes a rogue 261 CA with the same issuer name specified in the baseCertificateID 262 component, this rogue CA could issue a PKC to a malicious party, 263 using the same issuer name and serial number as the proper 264 holder's PKC. Then the malicious party could use this PKC in 265 conjunction with the AC. This scenario SHOULD be avoided by 266 properly managing and configuring the PKI so that there cannot be 267 two CAs with the same name. Another alternative is to tie ACs to 268 PKCs using the publicKeyCert type in the ObjectDigestInfo field. 269 Failing this, AC verifiers have to establish (using other means) 270 that the potential collisions cannot actually occur, for example, 271 the CPSs of the CAs involved may make it clear that no such name 272 collisions can occur. 274 Implementers MUST ensure that following validation of an AC, only 275 attributes that the issuer is trusted to issue are used in 276 authorization decisions. Other attributes, which MAY be present 277 MUST be ignored. Given that the AA controls PKC extension is 278 optional to implement, AC verifiers MUST be provided with this 279 information by other means. Configuration information is a likely 280 alternative means. This becomes very important if an AC verifier 281 trusts more than one AC issuer. 283 4. References 285 4.1 Normative references 287 [ITU-T Rec. X660 | ITU-T Recommendation Rec X.660 (1992) 288 ISO/IEC 9834-1] | ISO/IEC 9834-1: 1993, Information 289 technology - Open Systems Interconnection 290 Procedures for the operation of OSI 291 Registration Authorities: General procedures. 293 [RFC3280] Certificate and Certificate Revocation List (CRL) Profile. 294 R. Housley, W.Polk, W.Ford, and D. Solo. April 2002. 296 [RFC3281] An Internet Attribute Certificate Profile for Authorization. 297 S. Farrell S. and R. Housley. April 2002. 299 [ASN1] X.680 - X.693 | ISO/IEC 8824: 1-4 Abstract Syntax 300 Notation One (ASN.1). 302 4.2 Informative reference 304 [X.509] ITU-T Recommendation X.509 (2000): Information Technology � 305 Open Systems Interconnections - The Directory: 306 Public-key and Attribute Frameworks, March 2000 308 Author's Addresses 310 Christopher S. Francis 311 Raytheon 312 1501 72nd Street North, MS 25 313 St. Petersburg, Florida 33764 314 Email: Chris_S_Francis@Raytheon.com 316 Denis Pinkas 317 Bull 318 Rue Jean Jaures 319 78340 Les Clayes-sous-Bois 320 FRANCE 321 Email: Denis.Pinkas@bull.net 323 Full Copyright Statement 325 Copyright (C) The Internet Society (2005). 327 This document is subject to the rights, licenses and restrictions 328 contained in BCP 78, and except as set forth therein, the authors 329 retain all their rights. 331 This document and the information contained herein are provided on an 332 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 333 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 334 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 335 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 336 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 337 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 339 Intellectual Property 341 The IETF takes no position regarding the validity or scope of any 342 Intellectual Property Rights or other rights that might be claimed 343 to pertain to the implementation or use of the technology described 344 in this document or the extent to which any license under such 345 rights might or might not be available; nor does it represent that 346 it has made any independent effort to identify any such rights. 347 Information on the procedures with respect to rights in RFC 348 documents can be found in BCP 78 and BCP 79. 350 Copies of IPR disclosures made to the IETF Secretariat and any 351 assurances of licenses to be made available, or the result of an 352 attempt made to obtain a general license or permission for the use 353 of such proprietary rights by implementers or users of this 354 specification can be obtained from the IETF on-line IPR repository 355 at http://www.ietf.org/ipr. 357 The IETF invites any interested party to bring to its attention 358 any copyrights, patents or patent applications, or other 359 proprietary rights that may cover technology that may be required 360 to implement this standard. Please address the information to the 361 IETF at ietf-ipr@ietf.org. 363 Acknowledgement 365 Funding for the RFC Editor function is currently provided by the 366 Internet Society. 368 Annex A (normative): ASN.1 Definitions 370 ASN.1 Module 372 AcPolicies { iso(1) identified-organization(3) dod(6) 373 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 374 id-mod-ac-policies(26) } 376 DEFINITIONS IMPLICIT TAGS ::= 378 BEGIN 380 -- EXPORTS ALL -- 382 IMPORTS 384 -- Imports from RFC 3280 [RFC3280], Appendix A.1 386 UserNotice, anyPolicy 387 FROM PKIX1Implicit88 { iso(1) identified-organization(3) 388 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 389 id-mod(0) id-pkix1-implicit(19) } 391 id-pkix, id-pe 392 FROM PKIX1Explicit88 { iso(1) identified-organization(3) 393 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 394 id-mod(0) id-pkix1-explicit(18) }; 396 -- Locally defined OIDs 398 -- policyQualifierIds for Internet policy qualifiers 400 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 401 id-qt-acps OBJECT IDENTIFIER ::= { id-qt 4 } 402 id-qt-acunotice OBJECT IDENTIFIER ::= { id-qt 5 } 404 -- Attributes 406 id-pe-acPolicies OBJECT IDENTIFIER ::= { id-pe 15 } 408 AcPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 410 PolicyInformation ::= SEQUENCE { 411 policyIdentifier AcPolicyId, 412 policyQualifiers SEQUENCE SIZE (1..MAX) OF 413 PolicyQualifierInfo OPTIONAL} 415 AcPolicyId ::= OBJECT IDENTIFIER 417 PolicyQualifierInfo ::= SEQUENCE { 418 policyQualifierId PolicyQualifierId, 419 qualifier ANY DEFINED BY policyQualifierId } 421 PolicyQualifierId ::= 422 OBJECT IDENTIFIER ( id-qt-acps | id-qt-acunotice ) 423 -- ACPS pointer qualifier 425 ACPSuri ::= IA5String 426 -- ACP statement user notice qualifier 428 ACUserNotice ::= UserNotice 429 -- UserNotice is defined in [RFC3280] 431 END