idnits 2.17.1 draft-ietf-pkix-acpolicies-extn-05.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 8 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 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 -- 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 43, 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 (~~), 6 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 December 2003 D. Pinkas 4 Expires: June 2004 Bull 6 Attribute Certificate Policies 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 RFC 2026. 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. The goal of this document is to allow relying 34 parties to perform an additional test when validating an AC, i.e. to 35 assess whether a given AC carrying some attributes can be accepted on 36 the basis of references to one or more specific AC policies. 38 Conventions Used In This Document 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in [RFC 2119]. 44 1. Introduction 46 When issuing a PKC, a Certificate Authority (CA) can perform various 47 levels of verification with regard to the subject identity. A CA makes 48 its verification procedures, as well as other operational rules it 49 abides by, "visible" through a certificate policy, which may be 50 referenced by a certificate policies extension in the PKC. 52 The purpose of this document is to define an AC policies extension 53 able to explicitly state the AC policies that apply to a given AC, 54 but not the AC policies themselves. 56 2. AC Policies Extension Semantics 58 Attribute Certificates are defined in [RFC3281]. 60 An Attribute Certificate Policy (ACP) is a set of rules that indicates 61 generic rules for registering, verifying, delivering and revoking the 62 attributes contained in a particular Attribute Certificate. 64 It should thus be noticed that an AA does not necessarily support one 65 single policy. However, for each AC that is delivered it SHALL make 66 sure that the policy applies to all the attributes that are contained 67 in it. 69 An Attribute Certificate Policy may be used by a certificate user to 70 decide whether or not to trust the attributes contained in a 71 certificate for a particular purpose. 73 When a certificate contains an AC policies extension, the extension 74 MAY, at the option of the attribute certificate issuer, be either 75 critical or non-critical. 77 The AC Policies extension MAY be included in an attribute certificate. 78 Like all X.509 certificate extensions [X.509], the AC policies 79 extension is defined using ASN.1 [ASN1]. 81 The AC policies extension is identified by id-pe-acPolicies. 83 id-pe-acPolicies OBJECT IDENTIFIER ::= { id-pe 15 } 85 The AC policies extension includes a list of AC policies recognized by 86 the issuing authority that apply to the attributes included in the 87 attribute certificate. 89 AC Policies may be defined by any organization with a need. Object 90 identifiers used to identify AC Policies are assigned in accordance 91 with [ITU-T Rec. X660 | ISO/IEC 9834-1]. 93 The presence of this extension in an attribute certificate indicates 94 the AC policies for which the attribute certificate is valid. 96 An application that recognizes this extension and its content SHALL 97 process the extension regardless of the value of the criticality flag. 99 If the extension is both flagged non-critical and is not recognized, 100 then the application MAY ignore it. 102 If the extension is flagged critical or is recognized, it indicates 103 that the attributes contained in the attribute certificate SHALL only 104 be used for the purpose, and in accordance with the rules implied by 105 one of the indicated AC policies. If none of the AC policy identifiers 106 is adequate for the application, then the AC MUST be rejected. 108 If the extension is marked critical or is recognized, certificate 109 users MUST use the list of AC policies to determine whether it is 110 appropriate to use the attributes contained in that certificate for 111 a particular transaction. 113 2.1 AC Policy Extension Syntax 115 The syntax for the AC Policy extension is: 117 AcPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation 119 PolicyInformation ::= SEQUENCE { 120 policyIdentifier AcPolicyId, 121 policyQualifiers SEQUENCE SIZE (1..MAX) OF 122 PolicyQualifierInfo OPTIONAL} 124 AcPolicyId ::= OBJECT IDENTIFIER 126 PolicyQualifierInfo ::= SEQUENCE { 127 policyQualifierId PolicyQualifierId, 128 qualifier ANY DEFINED BY policyQualifierId } 130 -- policyQualifierIds for Internet policy qualifiers 132 id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } 133 id-qt-acps OBJECT IDENTIFIER ::= { id-qt 4 } 134 id-qt-acunotice OBJECT IDENTIFIER ::= { id-qt 5 } 136 PolicyQualifierId ::= 137 OBJECT IDENTIFIER ( id-qt-acps | id-qt-acunotice ) 139 -- ACPS pointer qualifier 141 ACPSuri ::= IA5String 143 -- AC user notice qualifier 145 ACUserNotice ::= UserNotice 147 -- UserNotice is defined in [RFC3280] 149 To promote interoperability, this document RECOMMENDS that policy 150 information terms consist of only an OID. When more than one policy 151 is used, the policy requirements have to be non conflicting, e.g. one 152 policy may refine the general requirements mandated by another policy. 154 When qualifiers are used with the special policy anyPolicy, they 155 MUST be limited to the qualifiers identified in this section. 157 This specification defines two policy qualifier types for use by 158 attribute certificate policy writers and attribute certificate 159 issuers. The qualifier types are the ACPS Pointer and AC User 160 Notice qualifiers. 162 The ACPS Pointer qualifier contains a pointer to an Attribute 163 Certification Practice Statement (ACPS) published by the AA. 164 The pointer is in the form of a URI. Processing requirements for 165 this qualifier are a local matter. 167 The AC User notice is intended for display to a relying party when 168 an attribute certificate is used. The application software SHOULD 169 display the AC user notice of the attribute certificate. The AC 170 user notice is defined in [RFC3280]. It has two optional fields: 171 the noticeRef field and the explicitText field. 173 The noticeRef field, if used, names an organization and 174 identifies, by number, a particular textual statement prepared by 175 that organization. For example, it might identify the 176 organization's name and notice number 1. In a typical 177 implementation, the application software will have a notice file 178 containing the current set of notices for the AA; the 179 application will extract the notice text from the file and 180 display it. Messages MAY be multilingual, allowing the software 181 to select the particular language message for its own 182 environment. 184 An explicitText field includes the textual statement directly in 185 the certificate. The explicitText field is a string with a 186 maximum size of 200 characters. 188 If both the noticeRef and explicitText options are included in the 189 one qualifier and if the application software can locate the notice 190 text indicated by the noticeRef option, then that text SHOULD be 191 displayed; otherwise, the explicitText string SHOULD be displayed. 193 2.2 Attribute Certificate Policies 195 The scope of this document is not the definition of the detailed 196 content of Attribute Certificate policies themselves, therefore 197 specific policies are not defined in this document. 199 3. Security Considerations 201 The Attribute Certification Policy defined in this document applies 202 for all the attributes that are included in one AC. AAs shall make 203 sure that the Attribute Certification Policy applies to all the 204 attributes which are included in the attribute certificates they 205 issue. 207 Attributes may be dynamically grouped in several ACs. It should be 208 observed that since the management of some attributes may be 209 different, different policies may be used by the same AA. 211 When verifying an Attribute Certificate, a relying party must 212 determine first that the AC was issued by a trusted AA and then 213 has the appropriate policy. 215 Failure of AC issuers to protect their private keys will permit 216 an attacker to masquerade as them, potentially generating false ACs 217 or revocation status. Existence of bogus ACs and revocation status 218 will undermine confidence in the system. If the compromise is 219 detected, all ACs issued by the AC issuer MUST be revoked. 220 Rebuilding after such a compromise will be problematic, so AC 221 issuers are advised to implement a combination of strong technical 222 measures (e.g., tamper-resistant cryptographic modules) and 223 appropriate management procedures (e.g., separation of duties) 224 to avoid such an incident. 226 Loss of an AC issuer's private signing key may also be problematic. 227 The AC issuer would not be able to produce revocation status or 228 perform AC renewal. AC issuers are advised to maintain secure 229 backup for signing keys. The security of the key backup procedures 230 is a critical factor in avoiding key compromise. 232 The availability and freshness of revocation status will affect the 233 degree of assurance that should be placed in a long-lived AC. While 234 long-lived ACs expire naturally, events may occur during its natural 235 lifetime which negate the binding between the AC holder and the 236 attributes. If revocation status is untimely or unavailable, the 237 assurance associated with the binding is clearly reduced. 239 The binding between an AC holder and attributes cannot be stronger 240 than the cryptographic module implementation and algorithms used to 241 generate the signature. Short key lengths or weak hash algorithms 242 will limit the utility of an AC. AC issuers are encouraged to note 243 advances in cryptology so they can employ strong cryptographic 244 techniques. 246 If an attribute certificate is tied to the holder's PKC using the 247 baseCertificateID component of the Holder field and the PKI in use 248 includes a rogue CA with the same issuer name specified in the 249 baseCertificateID component, this rogue CA could issue a PKC to a 250 malicious party, using the same issuer name and serial number as the 251 proper holder's PKC. Then the malicious party could use this PKC in 252 conjunction with the AC. This scenario SHOULD be avoided by 253 properly managing and configuring the PKI so that there cannot be 254 two CAs with the same name. Another alternative is to tie ACs to 255 PKCs using the publicKeyCert type in the ObjectDigestInfo field. 256 Failing this, AC verifiers have to establish (using other means) 257 that the potential collisions cannot actually occur, for example, 258 the CPSs of the CAs involved may make it clear that no such name 259 collisions can occur. 261 Implementers MUST ensure that following validation of an AC, only 262 attributes that the issuer is trusted to issue are used in 263 authorization decisions. Other attributes, which MAY be present 264 MUST be ignored. Given that the AA controls PKC extension is 265 optional to implement, AC verifiers MUST be provided with this 266 information by other means. Configuration information is a likely 267 alternative means. This becomes very important if an AC verifier 268 trusts more than one AC issuer. 270 4. References 272 4.1 Normative references 274 [ITU-T Rec. X660 | ITU-T Recommendation Rec X.660 (1992) 275 ISO/IEC 9834-1] | ISO/IEC 9834-1: 1993, Information 276 technology - Open Systems Interconnection 277 Procedures for the operation of OSI 278 Registration Authorities: General procedures. 280 [RFC3280] Certificate and Certificate Revocation List (CRL) Profile. 281 R. Housley, W.Polk, W.Ford, and D. Solo. April 2002. 283 [RFC3281] An Internet Attribute Certificate Profile for Authorization. 284 S. Farrell S. and R. Housley. April 2002. 286 [ASN1] X.680 - X.693 | ISO/IEC 8824: 1-4 Abstract Syntax 287 Notation One (ASN.1). See: 288 http://www.itu.int/ITU-T/studygroups/com17/languages/ and 289 http://asn1.elibel.tm.fr/en/standards/index.htm 291 4.2 Informative reference 293 [X.509] ITU-T Recommendation X.509 (2000): Information Technology � 294 Open Systems Interconnections - The Directory: 295 Public-key and Attribute Frameworks, March 2000 297 5. IPR Notice 299 The IETF takes no position regarding the validity or scope of any 300 intellectual property or other rights that might be claimed to pertain 301 to the implementation or use of the technology described in this 302 document or the extent to which any license under such rights might or 303 might not be available; neither does it represent that it has made any 304 effort to identify any such rights. Information on the IETF's 305 procedures with respect to rights in standards-track and standards- 306 related documentation can be found in BCP-11. Copies of claims of 307 rights made available for publication and any assurances of licenses to 308 be made available, or the result of an attempt made to obtain a general 309 license or permission for the use of such proprietary rights by 310 implementors or users of this specification can be obtained from the 311 IETF Secretariat. 313 The IETF invites any interested party to bring to its attention any 314 copyrights, patents or patent applications, or other proprietary rights 315 which may cover technology that may be required to practice this 316 standard. Please address the information to the IETF Executive 317 Director. 319 Author's Addresses 321 Christopher S. Francis 322 Raytheon 323 1501 72nd Street North, MS 25 324 St. Petersburg, Florida 33764 325 Email: Chris_S_Francis@Raytheon.com 327 Denis Pinkas 328 Bull 329 Rue Jean Jaures 330 78340 Les Clayes-sous-Bois 331 FRANCE 332 Email: Denis.Pinkas@bull.net 334 Full Copyright Statement 336 Copyright (C) The Internet Society 2002. All Rights Reserved. 338 This document and translations of it may be copied and furnished to 339 others, and derivative works that comment on or otherwise explain it or 340 assist in its implementation may be prepared, copied, published and 341 distributed, in whole or in part, without restriction of any kind, 342 provided that the above copyright notice and this paragraph are 343 included on all such copies and derivative works. However, this 344 document itself may not be modified in any way, such as by removing the 345 copyright notice or references to the Internet Society or other 346 Internet organizations, except as needed for the purpose of developing 347 Internet standards in which case the procedures for copyrights defined 348 in the Internet Standards process must be followed, or as required to 349 translate it into languages other than English. 351 The limited permissions granted above are perpetual and will not be 352 revoked by the Internet Society or its successors or assigns. 354 This document and the information contained herein is provided on an 355 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 356 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 357 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 358 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 359 FITNESS FOR A PARTICULAR PURPOSE. 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.1 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 ) 422 -- ACPS pointer qualifier 424 ACPSuri ::= IA5String 426 -- AC user notice qualifier 428 ACUserNotice ::= UserNotice 429 -- UserNotice is defined in [RFC3280] 431 END