idnits 2.17.00 (12 Aug 2021) /tmp/idnits42686/draft-ietf-pkix-3281update-01.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 509. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 522. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3281, updated by this document, for RFC5378 checks: 1999-04-29) -- 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.) -- The document date (October 26, 2008) is 4954 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 403 -- Looks like a reference, but probably isn't: '0' on line 402 -- Looks like a reference, but probably isn't: '2' on line 353 == Missing Reference: 'UNIVERSAL 12' is mentioned on line 278, but not defined ** Obsolete normative reference: RFC 3281 (Obsoleted by RFC 5755) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF PKIX WG Stephen Farrell, Trinity College Dublin 2 Internet Draft Russ Housley, Vigil Security 3 Intended Status: Standards Track Sean Turner, IECA 4 Updates: 3281 (once approved) October 26, 2008 5 Expires: April 26, 2009 7 An Internet Attribute Certificate Profile for Authorization: Update 8 draft-ietf-pkix-3281update-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on April 26, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document updates RFC 3281. It incorporates verified errata. 43 Discussion 45 This draft is being discussed on the 'ietf-pkix' mailing list. To 46 subscribe, send a message to ietf-pkix-request@imc.org with the 47 single word subscribe in the body of the message. There is a Web site 48 for the mailing list at . 50 1. Introduction 52 This document updates [RFC3281]. It incorporates verified errata. 53 OLD text is replaced by NEW text. 55 1.1. Requirements Terminology 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 59 document are to be interpreted as described in [RFC2119]. 61 2. Changes to Section 4.1 63 Replace the following ASN.1 excerpt in section 4.1. This change 64 incorporates verified technical errata #303. 66 NOTE: The "," is moved on the version line. 68 OLD: 70 AttributeCertificateInfo ::= SEQUENCE { 71 version AttCertVersion -- version is v2, 72 holder Holder, 73 issuer AttCertIssuer, 74 signature AlgorithmIdentifier, 75 serialNumber CertificateSerialNumber, 76 attrCertValidityPeriod AttCertValidityPeriod, 77 attributes SEQUENCE OF Attribute, 78 issuerUniqueID UniqueIdentifier OPTIONAL, 79 extensions Extensions OPTIONAL 80 } 81 NEW: 83 AttributeCertificateInfo ::= SEQUENCE { 84 version AttCertVersion, -- version is v2 85 holder Holder, 86 issuer AttCertIssuer, 87 signature AlgorithmIdentifier, 88 serialNumber CertificateSerialNumber, 89 attrCertValidityPeriod AttCertValidityPeriod, 90 attributes SEQUENCE OF Attribute, 91 issuerUniqueID UniqueIdentifier OPTIONAL, 92 extensions Extensions OPTIONAL 93 } 95 3. Changes to Section 4.3.2 97 Replace the OLD text with the NEW text in section 4.3.2. This 98 incorporates verified technical errata #710. 100 NOTE: "Confirming" is replaced "Conforming". 102 OLD: 104 Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF 105 Targets". Conforming AC issuer implementations MUST only produce one 106 "Targets" element. Confirming AC users MUST be able to accept a 107 "SEQUENCE OF Targets". If more than one Targets element is found in 108 an AC, the extension MUST be treated as if all Target elements had 109 been found within one Targets element. 111 NEW: 113 Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF 114 Targets". Conforming AC issuer implementations MUST only produce one 115 "Targets" element. Conforming AC users MUST be able to accept a 116 "SEQUENCE OF Targets". If more than one Targets element is found in 117 an AC, the extension MUST be treated as if all Target elements had 118 been found within one Targets element. 120 4. Changes to Section 4.4.6 122 Replace OLD1 text with NEW1 text. This change incorporates verified 123 technical errata #302. Replace OLD2 text with NEW2 text. This change 124 incorporates reported technical errata #1479. 126 NOTE for OLD1: The differences in tagging arose due to an unnoticed 127 technical corrigendum (TC-2) being applied to the X.501 [X.501-1997] 128 document during preparation of [RFC3281]. The X.501 format is the 129 correct form. Implementers SHOULD modify their decoding functions to 130 accept either format and, even if claiming RFC 3281 conformance, 131 SHOULD output the (correct) X.501 format. 133 NOTE for OLD2: The two changes 1) removing the IMPLICIT from the type 134 line and 2) adding the EXPLICIT to the value line. Both changes are 135 for clarity, for alignment with X.501, and do not change the bits on 136 the wire. With respect to 1) the module uses IMPLICIT tags therefore 137 the IMPLICIT in the type line is extraneous and is removed 138 2) [1] ANY, [1] EXPLICIT ANY, and [1] IMPLICIT ANY all result in the 139 same encoding therefore for alignment purposes with X.501:1997 the 140 EXPLICIT is added. 142 OLD1: 144 Clearance ::= SEQUENCE { 145 policyId [0] OBJECT IDENTIFIER, 146 classList [1] ClassList DEFAULT {unclassified}, 147 securityCategories [2] SET OF SecurityCategory OPTIONAL 148 } 150 NEW1: 152 Clearance ::= SEQUENCE { 153 policyId OBJECT IDENTIFIER, 154 classList ClassList DEFAULT {unclassified}, 155 securityCategories SET OF SecurityCategory OPTIONAL 156 } 158 OLD2: 160 SecurityCategory ::= SEQUENCE { 161 type [0] IMPLICIT OBJECT IDENTIFIER, 162 value [1] ANY DEFINED BY type 163 } 165 NEW2: 167 SecurityCategory ::= SEQUENCE { 168 type [0] OBJECT IDENTIFIER, 169 value [1] EXPLICIT ANY DEFINED BY type 170 } 172 5. Changes to Section 7.1 174 Replace the OLD text with the NEW text. This change incorporates 175 reported technical errata #304. 177 OLD: 179 The AC then contains the ciphertext inside its signed data. The 180 EnvelopedData (id-envelopedData) ContentType is used, and the content 181 field will contain the EnvelopedData type. 183 NEW: 185 Within EnvelopedData, the encapsulatedContentInfo identifies the 186 content type carried withing the ciphertext. In this case, the 187 contentType field of encapsulatedContentInfo MUST contain id-ct- 188 attrCertEncAttrs, which has the following value: 190 attrCertEncAttrs OBJECT IDENTIFIER ::= { 191 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 192 id-smime(16) id-ct(1) 14 } 194 6. Changes to Section 10 196 Replace the reference to X.501:1993 to X.501:1997. This change 197 incorporates reported technical errata #1479. 199 NOTE: Clearance was defined in X.501:1993 not X.501:1997. 201 OLD: 203 [X.501-1993] ITU-T Recommendation X.501 : Information Technology - 204 Open Systems Interconnection - The Directory: Models, 205 1993. 207 NEW: 209 [X.501-1997] ITU-T Recommendation X.501 : Information Technology - 210 Open Systems Interconnection - The Directory: Models, 211 1997. 213 7. Changes to Annex B 215 This module replaces the module in Annex B of [RFC3281]. It 216 incorporates verified technical errata #302 and #1480 and verified 217 editorial errata #303. 219 PKIXAttributeCertificate-2008 { iso(1) identified-organization(3) 220 dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 221 id-mod-attribute-cert2(TBA) } 223 DEFINITIONS IMPLICIT TAGS ::= 225 BEGIN 227 -- EXPORTS ALL -- 229 IMPORTS 231 -- IMPORTed module OIDs MAY change if [PKIXPROF] changes 232 -- PKIX Certificate Extensions 234 Attribute, AlgorithmIdentifier, CertificateSerialNumber, 235 Extensions, UniqueIdentifier, id-pkix, id-pe, id-kp, id-ad, id-at 236 FROM PKIX1Explicit88 237 { iso(1) identified-organization(3) dod(6) internet(1) 238 security(5) mechanisms(5) pkix(7) id-mod(0) 239 id-pkix1-explicit-88(1) } 241 GeneralName, GeneralNames, id-ce 242 FROM PKIX1Implicit88 243 { iso(1) identified-organization(3) dod(6) internet(1) 244 security(5) mechanisms(5) pkix(7) id-mod(0) 245 id-pkix1-implicit-88(2) } 247 ; 249 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 251 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 253 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 } 255 id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 257 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 259 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 261 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 263 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 265 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 266 -- { id-aca 5 } is reserved 268 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 270 id-at-role OBJECT IDENTIFIER ::= { id-at 72} 272 id-at-clearance OBJECT IDENTIFIER ::= { 273 joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5) 274 clearance (55) } 276 -- Uncomment this if using a 1988 level ASN.1 compiler 278 -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 280 AttributeCertificate ::= SEQUENCE { 281 acinfo AttributeCertificateInfo, 282 signatureAlgorithm AlgorithmIdentifier, 283 signatureValue BIT STRING 284 } 286 AttributeCertificateInfo ::= SEQUENCE { 287 version AttCertVersion, -- version is v2 288 holder Holder, 289 issuer AttCertIssuer, 290 signature AlgorithmIdentifier, 291 serialNumber CertificateSerialNumber, 292 attrCertValidityPeriod AttCertValidityPeriod, 293 attributes SEQUENCE OF Attribute, 294 issuerUniqueID UniqueIdentifier OPTIONAL, 295 extensions Extensions OPTIONAL 296 } 298 AttCertVersion ::= INTEGER { v2(1) } 300 Holder ::= SEQUENCE { 301 baseCertificateID [0] IssuerSerial OPTIONAL, 302 -- the issuer and serial number of 303 -- the holder's Public Key Certificate 304 entityName [1] GeneralNames OPTIONAL, 305 -- the name of the claimant or role 306 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 307 -- used to directly authenticate the 308 -- holder, for example, an executable 309 } 310 ObjectDigestInfo ::= SEQUENCE { 311 digestedObjectType ENUMERATED { 312 publicKey (0), 313 publicKeyCert (1), 314 otherObjectTypes (2) }, 315 -- otherObjectTypes MUST NOT 316 -- MUST NOT be used in this profile 317 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 318 digestAlgorithm AlgorithmIdentifier, 319 objectDigest BIT STRING 320 } 322 AttCertIssuer ::= CHOICE { 323 v1Form GeneralNames, -- MUST NOT be used in this 324 -- profile 325 v2Form [0] V2Form -- v2 only 326 } 328 V2Form ::= SEQUENCE { 329 issuerName GeneralNames OPTIONAL, 330 baseCertificateID [0] IssuerSerial OPTIONAL, 331 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 332 -- issuerName MUST be present in this profile 333 -- baseCertificateID and objectDigestInfo MUST 334 -- NOT be present in this profile 335 } 337 IssuerSerial ::= SEQUENCE { 338 issuer GeneralNames, 339 serial CertificateSerialNumber, 340 issuerUID UniqueIdentifier OPTIONAL 341 } 343 AttCertValidityPeriod ::= SEQUENCE { 344 notBeforeTime GeneralizedTime, 345 notAfterTime GeneralizedTime 346 } 348 Targets ::= SEQUENCE OF Target 350 Target ::= CHOICE { 351 targetName [0] GeneralName, 352 targetGroup [1] GeneralName, 353 targetCert [2] TargetCert 354 } 355 TargetCert ::= SEQUENCE { 356 targetCertificate IssuerSerial, 357 targetName GeneralName OPTIONAL, 358 certDigestInfo ObjectDigestInfo OPTIONAL 359 } 361 IetfAttrSyntax ::= SEQUENCE { 362 policyAuthority [0] GeneralNames OPTIONAL, 363 values SEQUENCE OF CHOICE { 364 octets OCTET STRING, 365 oid OBJECT IDENTIFIER, 366 string UTF8String 367 } 368 } 370 SvceAuthInfo ::= SEQUENCE { 371 service GeneralName, 372 ident GeneralName, 373 authInfo OCTET STRING OPTIONAL 374 } 376 RoleSyntax ::= SEQUENCE { 377 roleAuthority [0] GeneralNames OPTIONAL, 378 roleName [1] GeneralName 379 } 381 Clearance ::= SEQUENCE { 382 policyId OBJECT IDENTIFIER, 383 classList ClassList DEFAULT {unclassified}, 384 securityCategories SET OF SecurityCategory OPTIONAL 385 } 387 ClassList ::= BIT STRING { 388 unmarked (0), 389 unclassified (1), 390 restricted (2), 391 confidential (3), 392 secret (4), 393 topSecret (5) 394 } 396 SecurityCategory ::= SEQUENCE { 397 type [0] OBJECT IDENTIFIER, 398 value [1] EXPLICIT ANY DEFINED BY type 399 } 400 AAControls ::= SEQUENCE { 401 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 402 permittedAttrs [0] AttrSpec OPTIONAL, 403 excludedAttrs [1] AttrSpec OPTIONAL, 404 permitUnSpecified BOOLEAN DEFAULT TRUE 405 } 407 AttrSpec ::= SEQUENCE OF OBJECT IDENTIFIER 409 ACClearAttrs ::= SEQUENCE { 410 acIssuer GeneralName, 411 acSerial INTEGER, 412 attrs SEQUENCE OF Attribute 413 } 415 ProxyInfo ::= SEQUENCE OF Targets 417 END 419 8. Security Considerations 421 The security considerations in [RFC3281] apply. No new security 422 considerations are added as a result of this document. 424 9. IANA Considerations 426 This document makes extensive use of object identifiers to register 427 extensions and attributes. Most are registered in an arc delegated 428 by IANA to the PKIX Working Group. Other are taken from ITU-T | ISO 429 arc. Additionally, an object identifier is used to identify the 430 ASN.1 module found in Section 7. No further action by IANA is 431 necessary for this document or any anticipated updates. 433 10. References 435 10.1. Normative 437 [PKIXPROF] Cooper, D., Santesson, S., Farrell, S., Boeyen, S. 438 Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure 439 Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, 440 May 2008. 442 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 443 Requirement Levels", BCP 14, RFC 2119, March 1997. 445 [RFC3281] Farrell, S., and R. Housley, "An Internet Attribute 446 Certificate Profile for Authorization", RFC 3281, April 2002. 448 [X.501-1997] ITU-T Recommendation X.501: Information Technology - 449 Open Systems Interconnection - The Directory: Models, 1997. 451 10.2. Informative 453 None. 455 Author's Addresses 457 Sean Turner 459 IECA, Inc. 460 3057 Nutley Street, Suite 106 461 Fairfax, VA 22031 462 USA 464 Email: turners@ieca.com 466 Russ Housley 468 Vigil Security, LLC 469 918 Spring Knoll Drive 470 Herndon, VA 20170 471 USA 473 EMail: housley@vigilsec.com 475 Stephen Farrell 477 Distributed Systems Group 478 Computer Science Department 479 Trinity College Dublin 480 Ireland 482 Email: stephen.farrell@cs.tcd.ie 484 Full Copyright Statement 486 Copyright (C) The IETF Trust (2008). 488 This document is subject to the rights, licenses and restrictions 489 contained in BCP 78, and except as set forth therein, the authors 490 retain all their rights. 492 This document and the information contained herein are provided on an 493 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 494 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 495 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 496 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 497 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 498 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 500 Intellectual Property 502 The IETF takes no position regarding the validity or scope of any 503 Intellectual Property Rights or other rights that might be claimed to 504 pertain to the implementation or use of the technology described in 505 this document or the extent to which any license under such rights 506 might or might not be available; nor does it represent that it has 507 made any independent effort to identify any such rights. Information 508 on the procedures with respect to rights in RFC documents can be 509 found in BCP 78 and BCP 79. 511 Copies of IPR disclosures made to the IETF Secretariat and any 512 assurances of licenses to be made available, or the result of an 513 attempt made to obtain a general license or permission for the use of 514 such proprietary rights by implementers or users of this 515 specification can be obtained from the IETF on-line IPR repository at 516 http://www.ietf.org/ipr. 518 The IETF invites any interested party to bring to its attention any 519 copyrights, patents or patent applications, or other proprietary 520 rights that may cover technology that may be required to implement 521 this standard. Please address the information to the IETF at 522 ietf-ipr@ietf.org. 524 Acknowledgment 526 Funding for the RFC Editor function is provided by the IETF 527 Administrative Support Activity (IASA).