idnits 2.17.1 draft-ietf-pkix-3281update-02.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 2021. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2032. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2039. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2045. 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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- 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 (December 11, 2008) is 5614 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '0' on line 1905 -- Looks like a reference, but probably isn't: '1' on line 1906 -- Looks like a reference, but probably isn't: '2' on line 1875 == Missing Reference: 'UNIVERSAL 12' is mentioned on line 1760, but not defined ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) -- Obsolete informational reference (is this intentional?): RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 3281 (Obsoleted by RFC 5755) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 14 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 Obsoletes: 3281 (once approved) December 11, 2008 5 Expires: June 11, 2009 7 An Internet Attribute Certificate Profile for Authorization 8 draft-ietf-pkix-3281update-02.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 June 11, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This specification defines a profile for the use of X.509 Attribute 42 Certificates in Internet Protocols. Attribute certificates may be 43 used in a wide range of applications and environments covering a 44 broad spectrum of interoperability goals and a broader spectrum of 45 operational and assurance requirements. The goal of this document is 46 to establish a common baseline for generic applications requiring 47 broad interoperability as well as limited special purpose 48 requirements. The profile places emphasis on attribute certificate 49 support for Internet electronic mail, IPSec, and WWW security 50 applications. This document obsoletes RFC 3281. 52 Discussion 54 This draft is being discussed on the 'ietf-pkix' mailing list. To 55 subscribe, send a message to ietf-pkix-request@imc.org with the 56 single word subscribe in the body of the message. There is a Web site 57 for the mailing list at . 59 Table of Contents 61 1. Introduction...................................................3 62 1.1. Requirements Terminology..................................4 63 1.2. AC Path Delegation........................................4 64 1.3. Attribute Certificate Distribution ("push" vs. "pull")....5 65 1.4. Document Structure........................................6 66 2. Terminology....................................................7 67 3. Requirements...................................................7 68 4. Attribute Certificate Profile..................................8 69 4.1. X.509 Attribute Certificate Definition....................9 70 4.2. Profile of Standard Fields...............................11 71 4.2.1. Version.............................................12 72 4.2.2. Holder..............................................12 73 4.2.3. Issuer..............................................13 74 4.2.4. Signature...........................................13 75 4.2.5. Serial Number.......................................13 76 4.2.6. Validity Period.....................................14 77 4.2.7. Attributes..........................................14 78 4.2.8. Issuer Unique Identifier............................15 79 4.2.9. Extensions..........................................15 80 4.3. Extensions...............................................16 81 4.3.1. Audit Identity......................................16 82 4.3.2. AC Targeting........................................17 83 4.3.3. Authority Key Identifier............................18 84 4.3.4. Authority Information Access........................18 85 4.3.5. CRL Distribution Points.............................19 86 4.3.6. No Revocation Available.............................19 87 4.4. Attribute Types..........................................20 88 4.4.1. Service Authentication Information..................20 89 4.4.2. Access Identity.....................................21 90 4.4.3. Charging Identity...................................21 91 4.4.4. Group...............................................22 92 4.4.5. Role................................................22 93 4.4.6. Clearance...........................................22 94 4.5. Profile of AC issuer's PKC...............................25 95 5. Attribute Certificate Validation..............................25 96 6. Revocation....................................................26 97 7. Optional Features.............................................27 98 7.1. Attribute Encryption.....................................28 99 7.2. Proxying.................................................29 100 7.3. Use of ObjectDigestInfo..................................31 101 7.4. AA Controls..............................................32 102 8. Security Considerations.......................................33 103 9. IANA Considerations...........................................35 104 10. References...................................................35 105 10.1. Normative References....................................35 106 10.2. Informative References..................................35 107 Appendix A Object Identifiers....................................36 108 Appendix B ASN.1 Module..........................................37 109 Appendix C Changes Since RFC 3281................................43 110 Author's Addresses...............................................44 112 1. Introduction 114 X.509 public key certificates (PKCs) [X.509-1997, X.509-2000, 115 PKIXPROF] bind an identity and a public key. An attribute 116 certificate (AC) is a structure similar to a PKC; the main difference 117 being that the AC contains no public key. An AC may contain 118 attributes that specify group membership, role, security clearance, 119 or other authorization information associated with the AC holder. 120 The syntax for the AC is defined in Recommendation X.509, making the 121 term "X.509 certificate" ambiguous. 123 Some people constantly confuse PKCs and ACs. An analogy may make the 124 distinction clear. A PKC can be considered to be like a passport: it 125 identifies the holder, tends to last for a long time, and should not 126 be trivial to obtain. An AC is more like an entry visa: it is 127 typically issued by a different authority and does not last for as 128 long a time. As acquiring an entry visa typically requires 129 presenting a passport, getting a visa can be a simpler process. 131 Authorization information may be placed in a PKC extension or placed 132 in a separate attribute certificate (AC). The placement of 133 authorization information in PKCs is usually undesirable for two 134 reasons. First, authorization information often does not have the 135 same lifetime as the binding of the identity and the public key. When 136 authorization information is placed in a PKC extension, the general 137 result is the shortening of the PKC useful lifetime. Second, the PKC 138 issuer is not usually authoritative for the authorization 139 information. This results in additional steps for the PKC issuer to 140 obtain authorization information from the authoritative source. 142 For these reasons, it is often better to separate authorization 143 information from the PKC. Yet, authorization information also needs 144 to be bound to an identity. An AC provides this binding; it is 145 simply a digitally signed (or certified) identity and set of 146 attributes. 148 An AC may be used with various security services, including access 149 control, data origin authentication, and non-repudiation. 151 PKCs can provide an identity to access control decision functions. 152 However, in many contexts the identity is not the criterion that is 153 used for access control decisions, rather the role or group- 154 membership of the accessor is the criterion used. Such access 155 control schemes are called role-based access control. 157 When making an access control decision based on an AC, an access 158 control decision function may need to ensure that the appropriate AC 159 holder is the entity that has requested access. One way in which the 160 linkage between the request or identity and the AC can be achieved is 161 the inclusion of a reference to a PKC within the AC and the use of 162 the private key corresponding to the PKC for authentication within 163 the access request. 165 ACs may also be used in the context of a data origin authentication 166 service and a non-repudiation service. In these contexts, the 167 attributes contained in the AC provide additional information about 168 the signing entity. This information can be used to make sure that 169 the entity is authorized to sign the data. This kind of checking 170 depends either on the context in which the data is exchanged or on 171 the data that has been digitally signed. 173 This document obsoletes [RFC3281]. 175 1.1. Requirements Terminology 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in [RFC2119]. 181 1.2. AC Path Delegation 183 The X.509 standard [X.509-2000] defines authorization as the 184 "conveyance of privilege from one entity that holds such privilege, 185 to another entity". An AC is one authorization mechanism. 187 An ordered sequence of ACs could be used to verify the authenticity 188 of a privilege asserter's privilege. In this way, chains or paths of 189 ACs could be employed to delegate authorization. 191 Since the administration and processing associated with such AC 192 chains is complex and the use of ACs in the Internet today is quite 193 limited, this specification does NOT RECOMMEND the use of AC chains. 194 Other (future) specifications may address the use of AC chains. This 195 specification deals with the simple cases, where one authority issues 196 all of the ACs for a particular set of attributes. However, this 197 simplification does not preclude the use of several different 198 authorities, each of which manages a different set of attributes. 199 For example, group membership may be included in one AC issued by one 200 authority, and security clearance may be included in another AC 201 issued by another authority. 203 This means that conformant implementations are only REQUIRED to be 204 able to process a single AC at a time. Processing of more than one 205 AC, one after another, may be necessary. Note however, that 206 validation of an AC MAY require validation of a chain of PKCs, as 207 specified in [PKIXPROF]. 209 1.3. Attribute Certificate Distribution ("push" vs. "pull") 211 As discussed above, ACs provide a mechanism to securely provide 212 authorization information to, for example, access control decision 213 functions. However, there are a number of possible communication 214 paths for ACs. 216 In some environments, it is suitable for a client to "push" an AC to 217 a server. This means that no new connections between the client and 218 server are required. It also means that no search burden is imposed 219 on servers, which improves performance and that the AC verifier is 220 only presented with what it "needs to know." The "push" model is 221 especially suitable in inter-domain cases where the client's rights 222 should be assigned within the client's "home" domain. 224 In other cases, it is more suitable for a client to simply 225 authenticate to the server and for the server to request or "pull" 226 the client's AC from an AC issuer or a repository. A major benefit 227 of the "pull" model is that it can be implemented without changes to 228 the client or to the client-server protocol. The "pull" model is 229 especially suitable for inter-domain cases where the client's rights 230 should be assigned within the server's domain, rather than within the 231 client's domain. 233 There are a number of possible exchanges involving three entities: 234 the client, the server, and the AC issuer. In addition, a directory 235 service or other repository for AC retrieval MAY be supported. 237 Figure 1 shows an abstract view of the exchanges that may involve 238 ACs. This profile does not specify a protocol for these exchanges. 240 +--------------+ 241 | | Server Acquisition 242 | AC issuer +----------------------------+ 243 | | | 244 +--+-----------+ | 245 | | 246 | Client | 247 | Acquisition | 248 | | 249 +--+-----------+ +--+------------+ 250 | | AC "push" | | 251 | Client +-------------------------+ Server | 252 | | (part of app. protocol) | | 253 +--+-----------+ +--+------------+ 254 | | 255 | Client | Server 256 | Lookup +--------------+ | Lookup 257 | | | | 258 +---------------+ Repository +---------+ 259 | | 260 +--------------+ 262 Figure 1: AC Exchanges 264 1.4. Document Structure 266 Section 2 defines some terminology. Section 3 specifies the 267 requirements that this profile is intended to meet. Section 4 268 contains the profile of the X.509 AC. Section 5 specifies rules for 269 AC validation. Section 6 specifies rules for AC revocation checks. 270 Section 7 specifies optional features which MAY be supported; 271 however, support for these features is not required for conformance 272 to this profile. Finally, appendices contain the list of OIDs 273 required to support this specification and an ASN.1 module. 275 2. Terminology 277 For simplicity, we use the terms client and server in this 278 specification. This is not intended to indicate that ACs are only to 279 be used in client-server environments. For example, ACs may be used 280 in the S/MIME v3.2 context, where the mail user agent would be both a 281 "client" and a "server" in the sense the terms are used here. 283 Term Meaning 285 AA Attribute Authority, the entity that issues the 286 AC, synonymous in this specification with "AC 287 issuer" 289 AC Attribute Certificate 291 AC user Any entity that parses or processes an AC 293 AC verifier Any entity that checks the validity of an AC and 294 then makes use of the result 296 AC issuer The entity which signs the AC, synonymous in this 297 specification with "AA" 299 AC holder The entity indicated (perhaps indirectly) in the 300 holder field of the AC 302 Client The entity which is requesting the action for 303 which authorization checks are to be made 305 Proxying In this specification, Proxying is used to mean 306 the situation where an application server acts as 307 an application client on behalf of a user. 308 Proxying here does not mean granting of authority. 310 PKC Public Key Certificate - uses the type ASN.1 311 Certificate defined in X.509 and profiled in RFC 312 2459. This (non-standard) acronym is used in order 313 to avoid confusion about the term "X.509 314 certificate". 316 Server The entity which requires that the authorization 317 checks are made. 319 3. Requirements 321 This AC profile meets the following requirements. 323 Time/Validity requirements: 325 1. Support for short-lived as well as long-lived ACs. Typical 326 short-lived validity periods might be measured in hours, as 327 opposed to months for PKCs. Short validity periods allow ACs to 328 be useful without a revocation mechanism. 330 Attribute Types: 332 2. Issuers of ACs should be able to define their own attribute types 333 for use within closed domains. 335 3. Some standard attribute types, which can be contained within ACs, 336 should be defined. Examples include "access identity," "group," 337 "role," "clearance," "audit identity," and "charging identity." 339 4. Standard attribute types should be defined in a manner that 340 permits an AC verifier to distinguish between uses of the same 341 attribute in different domains. For example, the "Administrators 342 group" as defined by Baltimore and the "Administrators group" as 343 defined by SPYRUS should be easily distinguished. 345 Targeting of ACs: 347 5. It should be possible to "target" an AC at one, or a small number 348 of, servers. This means that a trustworthy non-target server will 349 reject the AC for authorization decisions. 351 Push vs. Pull 353 6. ACs should be defined so that they can either be "pushed" by the 354 client to the server, or "pulled" by the server from a repository 355 or other network service, including an online AC issuer. 357 4. Attribute Certificate Profile 359 ACs may be used in a wide range of applications and environments 360 covering a broad spectrum of interoperability goals and a broader 361 spectrum of operational and assurance requirements. The goal of this 362 document is to establish a common baseline for generic applications 363 requiring broad interoperability and limited special purpose 364 requirements. In particular, the emphasis will be on supporting the 365 use of attribute certificates for informal Internet electronic mail, 366 IPSec, and WWW applications. 368 This section presents a profile for ACs that will foster 369 interoperability. This section also defines some private extensions 370 for the Internet community. 372 While the ISO/IEC/ITU documents use the 1993 (or later) version of 373 ASN.1, this document uses the 1988 ASN.1 syntax, as has been done for 374 PKCs [PKIXPROF]. The encoded certificates and extensions from either 375 ASN.1 version are bit-wise identical. 377 Where maximum lengths for fields are specified, these lengths refer 378 to the DER encoding and do not include the ASN.1 tag or length 379 fields. 381 Conforming implementations MUST support the profile specified in this 382 section. 384 4.1. X.509 Attribute Certificate Definition 386 X.509 contains the definition of an AC given below. All types that 387 are not defined in this document can be found in [PKIXPROF]. 389 AttributeCertificate ::= SEQUENCE { 390 acinfo AttributeCertificateInfo, 391 signatureAlgorithm AlgorithmIdentifier, 392 signatureValue BIT STRING 393 } 395 AttributeCertificateInfo ::= SEQUENCE { 396 version AttCertVersion, -- version is v2 397 holder Holder, 398 issuer AttCertIssuer, 399 signature AlgorithmIdentifier, 400 serialNumber CertificateSerialNumber, 401 attrCertValidityPeriod AttCertValidityPeriod, 402 attributes SEQUENCE OF Attribute, 403 issuerUniqueID UniqueIdentifier OPTIONAL, 404 extensions Extensions OPTIONAL 405 } 407 AttCertVersion ::= INTEGER { v2(1) } 408 Holder ::= SEQUENCE { 409 baseCertificateID [0] IssuerSerial OPTIONAL, 410 -- the issuer and serial number of 411 -- the holder's Public Key Certificate 412 entityName [1] GeneralNames OPTIONAL, 413 -- the name of the claimant or role 414 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 415 -- used to directly authenticate the holder, 416 -- for example, an executable 417 } 419 ObjectDigestInfo ::= SEQUENCE { 420 digestedObjectType ENUMERATED { 421 publicKey (0), 422 publicKeyCert (1), 423 otherObjectTypes (2) }, 424 -- otherObjectTypes MUST NOT 425 -- be used in this profile 426 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 427 digestAlgorithm AlgorithmIdentifier, 428 objectDigest BIT STRING 429 } 431 AttCertIssuer ::= CHOICE { 432 v1Form GeneralNames, -- MUST NOT be used in this 433 -- profile 434 v2Form [0] V2Form -- v2 only 435 } 437 V2Form ::= SEQUENCE { 438 issuerName GeneralNames OPTIONAL, 439 baseCertificateID [0] IssuerSerial OPTIONAL, 440 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 441 -- issuerName MUST be present in this profile 442 -- baseCertificateID and objectDigestInfo MUST NOT 443 -- be present in this profile 444 } 446 IssuerSerial ::= SEQUENCE { 447 issuer GeneralNames, 448 serial CertificateSerialNumber, 449 issuerUID UniqueIdentifier OPTIONAL 450 } 451 AttCertValidityPeriod ::= SEQUENCE { 452 notBeforeTime GeneralizedTime, 453 notAfterTime GeneralizedTime 454 } 456 Although the Attribute syntax is defined in [PKIXPROF], we repeat the 457 definition here for convenience. 459 Attribute ::= SEQUENCE { 460 type AttributeType, 461 values SET OF AttributeValue 462 -- at least one value is required 463 } 465 AttributeType ::= OBJECT IDENTIFIER 467 AttributeValue ::= ANY DEFINED BY AttributeType 469 Implementers should note that the DER encoding (see [X.509- 470 1988],[X.208-1988]) of the SET OF values requires ordering of the 471 encodings of the values. Though this issue arises with respect to 472 distinguished names, and has to be handled by [PKIXPROF] 473 implementations, it is much more significant in this context, since 474 the inclusion of multiple values is much more common in ACs. 476 4.2. Profile of Standard Fields 478 GeneralName offers great flexibility. To achieve interoperability, 479 in spite of this flexibility, this profile imposes constraints on the 480 use of GeneralName. 482 Conforming implementations MUST be able to support the dNSName, 483 directoryName, uniformResourceIdentifier, and iPAddress options. This 484 is compatible with the GeneralName requirements in [PKIXPROF] (mainly 485 in section 4.2.1.6). 487 Conforming implementations MUST NOT use the x400Address, 488 ediPartyName, or registeredID options. 490 Conforming implementations MAY use the otherName option to convey 491 name forms defined in Internet Standards. For example, Kerberos 492 [KRB] format names can be encoded into the otherName, using a 493 Kerberos 5 principal name OID and a SEQUENCE of the Realm and the 494 PrincipalName. 496 4.2.1. Version 498 The version field MUST have the value of v2. That is, the version 499 field is present in the DER encoding. 501 Note: This version (v2) is not backwards compatible with the previous 502 attribute certificate definition (v1) from the 1997 X.509 standard 503 [X.509-1997], but is compatible with the v2 definition from X.509 504 (2000) [X.509-2000]. 506 4.2.2. Holder 508 The Holder field is a SEQUENCE allowing three different (optional) 509 syntaxes: baseCertificateID, entityName and objectDigestInfo. Where 510 only one option is present, the meaning of the Holder field is clear. 511 However, where more than one option is used, there is a potential for 512 confusion as to which option is "normative", which is a "hint" etc. 513 Since the correct position is not clear from [X.509-2000], this 514 specification RECOMMENDS that only one of the options be used in any 515 given AC. 517 For any environment where the AC is passed in an authenticated 518 message or session and where the authentication is based on the use 519 of an X.509 PKC, the holder field SHOULD use the baseCertificateID. 521 With the baseCertificateID option, the holder's PKC serialNumber and 522 issuer MUST be identical to the AC holder field. The PKC issuer MUST 523 have a non-empty distinguished name which is to be present as the 524 single value of the holder.baseCertificateID.issuer construct in the 525 directoryName field. The AC holder.baseCertificateID.issuerUID field 526 MUST only be used if the holder's PKC contains an issuerUniqueID 527 field. If both the AC holder.baseCertificateID.issuerUID and the PKC 528 issuerUniqueID fields are present, the same value MUST be present in 529 both fields. Thus, the baseCertificateID is only usable with PKC 530 profiles (like [PKIXPROF]) which mandate that the PKC issuer field 531 contain a non-empty distinguished name value. 533 Note: An empty distinguished name is a distinguished name where the 534 SEQUENCE OF relative distinguished names is of zero length. In a DER 535 encoding, this has the value '3000'H. 537 If the holder field uses the entityName option and the underlying 538 authentication is based on a PKC, the entityName MUST be the same as 539 the PKC subject field or one of the values of the PKC subjectAltName 540 field extension (if present). Note that [PKIXPROF] mandates that the 541 subjectAltName extension be present if the PKC subject is an empty 542 distinguished name. See the security considerations section which 543 mentions some name collision problems that may arise when using the 544 entityName option. 546 In any other case where the holder field uses the entityName option, 547 only one name SHOULD be present. 549 Implementations conforming to this profile are not required to 550 support the use of the objectDigest field. However, section 7.3 551 specifies how this optional feature MAY be used. 553 Any protocol conforming to this profile SHOULD specify which AC 554 holder option is to be used and how this fits with the supported 555 authentication schemes defined in that protocol. 557 4.2.3. Issuer 559 ACs conforming to this profile MUST use the v2Form choice, which MUST 560 contain one and only one GeneralName in the issuerName, which MUST 561 contain a non-empty distinguished name in the directoryName field. 562 This means that all AC issuers MUST have non-empty distinguished 563 names. ACs conforming to this profile MUST omit the 564 baseCertificateID and objectDigestInfo fields. 566 Part of the reason for the use of the v2Form containing only an 567 issuerName is that it means that the AC issuer does not have to know 568 which PKC the AC verifier will use for it (the AC issuer). Using the 569 baseCertificateID field to reference the AC issuer would mean that 570 the AC verifier would have to trust the PKC that the AC issuer chose 571 (for itself) at AC creation time. 573 4.2.4. Signature 575 Contains the algorithm identifier used to validate the AC signature. 577 This MUST be one of the signing algorithms defined in [PKIXALGS]. 578 Conforming implementations MUST honor all MUST/SHOULD/MAY signing 579 algorithm statements specified in [PKIXALGS]. 581 4.2.5. Serial Number 583 For any conforming AC, the issuer/serialNumber pair MUST form a 584 unique combination, even if ACs are very short-lived. 586 AC issuers MUST force the serialNumber to be a positive integer, that 587 is, the sign bit in the DER encoding of the INTEGER value MUST be 588 zero - this can be done by adding a leading (leftmost) '00'H octet if 589 necessary. This removes a potential ambiguity in mapping between a 590 string of octets and an integer value. 592 Given the uniqueness and timing requirements above, serial numbers 593 can be expected to contain long integers. AC users MUST be able to 594 handle serialNumber values longer than 4 octets. Conformant ACs MUST 595 NOT contain serialNumber values longer than 20 octets. 597 There is no requirement that the serial numbers used by any AC issuer 598 follow any particular ordering. In particular, they need not be 599 monotonically increasing with time. Each AC issuer MUST ensure that 600 each AC that it issues contains a unique serial number. 602 4.2.6. Validity Period 604 The attrCertValidityPeriod (a.k.a. validity) field specifies the 605 period for which the AC issuer certifies that the binding between the 606 holder and the attributes fields will be valid. 608 The generalized time type, GeneralizedTime, is a standard ASN.1 type 609 for variable precision representation of time. The GeneralizedTime 610 field can optionally include a representation of the time 611 differential between the local time zone and Greenwich Mean Time. 613 For the purposes of this profile, GeneralizedTime values MUST be 614 expressed in Coordinated universal time (UTC) (also known as 615 Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times 616 are YYYYMMDDHHMMSSZ), even when the number of seconds is zero. 617 GeneralizedTime values MUST NOT include fractional seconds. 619 (Note: this is the same as specified in [PKIXPROF], section 620 4.1.2.5.2.) 622 AC users MUST be able to handle an AC which, at the time of 623 processing, has parts of its validity period or all its validity 624 period in the past or in the future (a post-dated AC). This is valid 625 for some applications, such as backup. 627 4.2.7. Attributes 629 The attributes field gives information about the AC holder. When the 630 AC is used for authorization, this will often contain a set of 631 privileges. 633 The attributes field contains a SEQUENCE OF Attribute. Each 634 Attribute MAY contain a SET OF values. For a given AC, each 635 AttributeType OBJECT IDENTIFIER in the sequence MUST be unique. That 636 is, only one instance of each attribute can occur in a single AC, but 637 each instance can be multi-valued. 639 AC users MUST be able to handle multiple values for all attribute 640 types. 642 An AC MUST contain at least one attribute. That is, the SEQUENCE OF 643 Attributes MUST NOT be of zero length. 645 Some standard attribute types are defined in section 4.4. 647 4.2.8. Issuer Unique Identifier 649 This field MUST NOT be used unless it is also used in the AC issuer's 650 PKC, in which case it MUST be used. Note that [PKIXPROF] states that 651 this field SHOULD NOT be used by conforming CAs, but that 652 applications SHOULD be able to parse PKCs containing the field. 654 4.2.9. Extensions 656 The extensions field generally gives information about the AC as 657 opposed to information about the AC holder. 659 An AC that has no extensions conforms to the profile; however, 660 section 4.3 defines the extensions that MAY be used with this 661 profile, and whether or not they may be marked critical. If any 662 other critical extension is used, the AC does not conform to this 663 profile. However, if any other non-critical extension is used, the 664 AC does conform to this profile. 666 The extensions defined for ACs provide methods for associating 667 additional attributes with holders. This profile also allows 668 communities to define private extensions to carry information unique 669 to those communities. Each extension in an AC may be designated as 670 critical or non-critical. An AC using system MUST reject an AC if it 671 encounters a critical extension it does not recognize; however, a 672 non-critical extension may be ignored if it is not recognized. 673 Section 4.3 presents recommended extensions used within Internet ACs 674 and standard locations for information. Communities may elect to use 675 additional extensions; however, caution should be exercised in 676 adopting any critical extensions in ACs which might prevent use in a 677 general context. 679 4.3. Extensions 681 4.3.1. Audit Identity 683 In some circumstances, it is required (e.g. by data protection/data 684 privacy legislation) that audit trails not contain records which 685 directly identify individuals. This circumstance may make the use of 686 the AC holder field unsuitable for use in audit trails. 688 To allow for such cases, an AC MAY contain an audit identity 689 extension. Ideally it SHOULD be infeasible to derive the AC holder's 690 identity from the audit identity value without the cooperation of the 691 AC issuer. 693 The value of the audit identity, along with the AC issuer/serial, 694 SHOULD then be used for audit/logging purposes. If the value of the 695 audit identity is suitably chosen, a server/service administrator can 696 use audit trails to track the behavior of an AC holder without being 697 able to identify the AC holder. 699 The server/service administrator in combination with the AC issuer 700 MUST be able to identify the AC holder in cases where misbehavior is 701 detected. This means that the AC issuer MUST be able to determine 702 the actual identity of the AC holder from the audit identity. 704 Of course, auditing could be based on the AC issuer/serial pair; 705 however, this method does not allow tracking of the same AC holder 706 with multiple ACs. Thus, an audit identity is only useful if it 707 lasts for longer than the typical AC lifetime. Auditing could also 708 be based on the AC holder's PKC issuer/serial; however, this will 709 often allow the server/service administrator to identify the AC 710 holder. 712 As the AC verifier might otherwise use the AC holder or some other 713 identifying value for audit purposes, this extension MUST be critical 714 when used. 716 Protocols that use ACs will often expose the identity of the AC 717 holder in the bits on-the-wire. In such cases, an opaque audit 718 identity does not make use of the AC anonymous; it simply ensures 719 that the ensuing audit trails do not contain identifying information. 721 The value of an audit identity MUST be longer than zero octets. The 722 value of an audit identity MUST NOT be longer than 20 octets. 724 name id-pe-ac-auditIdentity 725 OID { id-pe 4 } 726 syntax OCTET STRING 727 criticality MUST be TRUE 729 4.3.2. AC Targeting 731 To target an AC, the target information extension, imported from 732 [X.509-2000], MAY be used to specify a number of servers/services. 733 The intent is that the AC SHOULD only be usable at the specified 734 servers/services. An (honest) AC verifier who is not amongst the 735 named servers/services MUST reject the AC. 737 If this extension is not present, the AC is not targeted and may be 738 accepted by any server. 740 In this profile, the targeting information simply consists of a list 741 of named targets or groups. 743 The following syntax is used to represent the targeting information: 745 Targets ::= SEQUENCE OF Target 747 Target ::= CHOICE { 748 targetName [0] GeneralName, 749 targetGroup [1] GeneralName, 750 targetCert [2] TargetCert 751 } 753 TargetCert ::= SEQUENCE { 754 targetCertificate IssuerSerial, 755 targetName GeneralName OPTIONAL, 756 certDigestInfo ObjectDigestInfo OPTIONAL 757 } 759 The targetCert CHOICE within the Target structure is only present to 760 allow future compatibility with [X.509-2000] and MUST NOT be used. 762 The targets check passes if the current server (recipient) is one of 763 the targetName fields in the Targets SEQUENCE, or if the current 764 server is a member of one of the targetGroup fields in the Targets 765 SEQUENCE. In this case, the current server is said to "match" the 766 targeting extension. 768 How the membership of a target within a targetGroup is determined is 769 not defined here. It is assumed that any given target "knows" the 770 names of the targetGroups to which it belongs or can otherwise 771 determine its membership. For example, the targetGroup specifies a 772 DNS domain, and the AC verifier knows the DNS domain to which it 773 belongs. For another example, the targetGroup specifies "PRINTERS," 774 and the AC verifier knows whether or not it is a printer or print 775 server. 777 Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF 778 Targets". Conforming AC issuer implementations MUST only produce one 779 "Targets" element. Conforming AC users MUST be able to accept a 780 "SEQUENCE OF Targets". If more than one Targets element is found in 781 an AC, the extension MUST be treated as if all Target elements had 782 been found within one Targets element. 784 name id-ce-targetInformation 785 OID { id-ce 55 } 786 syntax SEQUENCE OF Targets 787 criticality MUST be TRUE 789 4.3.3. Authority Key Identifier 791 The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY 792 be used to assist the AC verifier in checking the signature of the 793 AC. The [PKIXPROF] description should be read as if "CA" meant "AC 794 issuer." As with PKCs, this extension SHOULD be included in ACs. 796 Note: An AC, where the issuer field used the baseCertificateID 797 CHOICE, would not need an authorityKeyIdentifier extension, as it is 798 explicitly linked to the key in the referred certificate. However, 799 as this profile states (in section 4.2.3), ACs MUST use the v2Form 800 with issuerName CHOICE, this duplication does not arise. 802 name id-ce-authorityKeyIdentifier 803 OID { id-ce 35 } 804 syntax AuthorityKeyIdentifier 805 criticality MUST be FALSE 807 4.3.4. Authority Information Access 809 The authorityInformationAccess extension, as defined in [PKIXPROF], 810 MAY be used to assist the AC verifier in checking the revocation 811 status of the AC. Support for the id-ad-caIssuers accessMethod is 812 NOT REQUIRED by this profile since AC chains are not expected. 814 The following accessMethod is used to indicate that revocation status 815 checking is provided for this AC, using the OCSP protocol defined in 816 [OCSP]: 818 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 820 The accessLocation MUST contain a URI, and the URI MUST contain an 821 HTTP URL [HTTP-URL] that specifies the location of an OCSP responder. 822 The AC issuer MUST, of course, maintain an OCSP responder at this 823 location. 825 name id-ce-authorityInfoAccess 826 OID { id-pe 1 } 827 syntax AuthorityInfoAccessSyntax 828 criticality MUST be FALSE 830 4.3.5. CRL Distribution Points 832 The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY 833 be used to assist the AC verifier in checking the revocation status 834 of the AC. See section 6 for details on revocation. 836 If the crlDistributionPoints extension is present, then exactly one 837 distribution point MUST be present. The crlDistributionPoints 838 extension MUST use the DistributionPointName option, which MUST 839 contain a fullName, which MUST contain a single name form. That name 840 MUST contain either a distinguished name or a URI. The URI MUST be 841 either an HTTP URL [HTTP-URL] or an LDAP URL [LDAP-URL]. 843 name id-ce-cRLDistributionPoints 844 OID { id-ce 31 } 845 syntax CRLDistributionPoints 846 criticality MUST be FALSE 848 4.3.6. No Revocation Available 850 The noRevAvail extension, defined in [X.509-2000], allows an AC 851 issuer to indicate that no revocation information will be made 852 available for this AC. 854 This extension MUST be non-critical. An AC verifier that does not 855 understand this extension might be able to find a revocation list 856 from the AC issuer, but the revocation list will never include an 857 entry for the AC. 859 name id-ce-noRevAvail 860 OID { id-ce 56 } 861 syntax NULL (i.e. '0500'H is the DER encoding) 862 criticality MUST be FALSE 864 4.4. Attribute Types 866 Some of the attribute types defined below make use of the 867 IetfAttrSyntax type, also defined below. The reasons for using this 868 type are: 870 1. It allows a separation between the AC issuer and the attribute 871 policy authority. This is useful for situations where a single 872 policy authority (e.g. an organization) allocates attribute 873 values, but where multiple AC issuers are deployed for performance 874 or other reasons. 876 2. The syntaxes allowed for values are restricted to OCTET STRING, 877 OBJECT IDENTIFIER, and UTF8String, which significantly reduces the 878 complexity associated with matching more general syntaxes. All 879 multi-valued attributes using this syntax are restricted so that 880 each value MUST use the same choice of value syntax. For example, 881 AC issuers must not use one value with an oid and a second value 882 with a string. 884 IetfAttrSyntax ::= SEQUENCE { 885 policyAuthority [0] GeneralNames OPTIONAL, 886 values SEQUENCE OF CHOICE { 887 octets OCTET STRING, 888 oid OBJECT IDENTIFIER, 889 string UTF8String 890 } 891 } 893 In the descriptions below, each attribute type is either tagged 894 "Multiple Allowed" or "One Attribute value only; multiple values 895 within the IetfAttrSyntax". This refers to the SET OF 896 AttributeValues; the AttributeType still only occurs once, as 897 specified in section 4.2.7. 899 4.4.1. Service Authentication Information 901 The SvceAuthInfo attribute identifies the AC holder to the 902 server/service by a name, and the attribute MAY include optional 903 service specific authentication information. Typically this will 904 contain a username/password pair for a "legacy" application. 906 This attribute provides information that can be presented by the AC 907 verifier to be interpreted and authenticated by a separate 908 application within the target system. Note that this is a different 909 use to that intended for the accessIdentity attribute in 4.4.2 below. 911 This attribute type will typically be encrypted when the authInfo 912 field contains sensitive information, such as a password. 914 name id-aca-authenticationInfo 915 OID { id-aca 1 } 916 Syntax SvceAuthInfo 917 values: Multiple allowed 919 SvceAuthInfo ::= SEQUENCE { 920 service GeneralName, 921 ident GeneralName, 922 authInfo OCTET STRING OPTIONAL 923 } 925 4.4.2. Access Identity 927 The accessIdentity attribute identifies the AC holder to the 928 server/service. For this attribute the authInfo field MUST NOT be 929 present. 931 This attribute is intended to be used to provide information about 932 the AC holder, that can be used by the AC verifier (or a larger 933 system of which the AC verifier is a component) to authorize the 934 actions of the AC holder within the AC verifier's system. Note that 935 this is a different use to that intended for the svceAuthInfo 936 attribute described in 4.4.1 above. 938 name id-aca-accessIdentity 939 OID { id-aca 2 } 940 syntax SvceAuthInfo 941 values: Multiple allowed 943 4.4.3. Charging Identity 945 The chargingIdentity attribute identifies the AC holder for charging 946 purposes. In general, the charging identity will be different from 947 other identities of the holder. For example, the holder's company 948 may be charged for service. 950 name id-aca-chargingIdentity 951 OID { id-aca 3 } 952 syntax IetfAttrSyntax 953 values: One Attribute value only; multiple values within the 954 IetfAttrSyntax 956 4.4.4. Group 958 The group attribute carries information about group memberships of 959 the AC holder. 961 name id-aca-group 962 OID { id-aca 4 } 963 syntax IetfAttrSyntax 964 values: One Attribute value only; multiple values within the 965 IetfAttrSyntax 967 4.4.5. Role 969 The role attribute, specified in [X.509-2000], carries information 970 about role allocations of the AC holder. 972 The syntax used for this attribute is: 974 RoleSyntax ::= SEQUENCE { 975 roleAuthority [0] GeneralNames OPTIONAL, 976 roleName [1] GeneralName 977 } 979 The roleAuthority field MAY be used to specify the issuing authority 980 for the role specification certificate. There is no requirement that 981 a role specification certificate necessarily exists for the 982 roleAuthority. This differs from [X.500-2000], where the 983 roleAuthority field is assumed to name the issuer of a role 984 specification certificate. For example, to distinguish the 985 administrator role as defined by "Baltimore" from that defined by 986 "SPYRUS", one could put the value "urn:administrator" in the roleName 987 field and the value "Baltimore" or "SPYRUS" in the roleAuthority 988 field. 990 The roleName field MUST be present, and roleName MUST use the 991 uniformResourceIdentifier CHOICE of the GeneralName. 993 name id-at-role 994 OID { id-at 72 } 995 syntax RoleSyntax 996 values: Multiple allowed 998 4.4.6. Clearance 1000 The clearance attribute, specified in [X.501-1993], carries clearance 1001 (associated with security labeling) information about the AC holder. 1003 The policyId field is used to identify the security policy to which 1004 the clearance relates. The policyId indicates the semantics of the 1005 classList and securityCategories fields. 1007 This specification includes the classList field exactly as it is 1008 specified in [X.501-1993]. Additional security classification 1009 values, and their position in the classification hierarchy, may be 1010 defined by a security policy as a local matter or by bilateral 1011 agreement. The basic security classification hierarchy is, in 1012 ascending order: unmarked, unclassified, restricted, confidential, 1013 secret, and top-secret. 1015 An organization can develop its own security policy that defines 1016 security classification values and their meanings. However, the BIT 1017 STRING positions 0 through 5 are reserved for the basic security 1018 classification hierarchy. 1020 If present, the SecurityCategory field provides further authorization 1021 information. The security policy identified by the policyId field 1022 indicates the syntaxes that are allowed to be present in the 1023 securityCategories SET. An OBJECT IDENTIFIER identifies each of the 1024 allowed syntaxes. When one of these syntaxes is present in the 1025 securityCategories SET, the OBJECT IDENTIFIER associated with that 1026 syntax is carried in the SecurityCategory.type field. 1028 The object identifier for the clearance attribute from [RFC3281] is: 1030 id-at-clearance OBJECT IDENTIFIER ::= { 1031 joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5) 1032 clearance (55) } 1034 The associated syntax is: 1036 Clearance ::= SEQUENCE { 1037 policyId [0] OBJECT IDENTIFIER, 1038 classList [1] ClassList DEFAULT {unclassified}, 1039 securityCategories [2] SET OF SecurityCategory OPTIONAL 1040 } 1042 But, it was later amended to: 1044 Clearance ::= SEQUENCE { 1045 policyId OBJECT IDENTIFIER, 1046 classList ClassList DEFAULT {unclassified}, 1047 securityCategories SET OF SecurityCategory OPTIONAL 1048 } 1050 The object identifier for the clearance attribute from [X.509-1997] 1051 is: 1053 id-at-clearance OBJECT IDENTIFIER ::= { 1054 joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) } 1056 The associated syntax is as follows: 1058 Clearance ::= SEQUENCE { 1059 policyId OBJECT IDENTIFIER, 1060 classList ClassList DEFAULT {unclassified}, 1061 securityCategories SET OF SecurityCategory OPTIONAL 1062 } 1064 Implementations MUST support the clearance attribute as defined in 1065 [X.501-1997]. Implementations SHOULD support decoding both clearance 1066 syntaxes from [RFC3281]. Implementations MUST NOT output the 1067 clearance attribute as defined in [RFC3281]. 1069 ClassList ::= BIT STRING { 1070 unmarked (0), 1071 unclassified (1), 1072 restricted (2), 1073 confidential (3), 1074 secret (4), 1075 topSecret (5) 1076 } 1078 SecurityCategory ::= SEQUENCE { 1079 type [0] OBJECT IDENTIFIER, 1080 value [1] EXPLICIT ANY DEFINED BY type 1081 } 1083 -- Note that in [RFC3281] the SecurityCategory syntax was as 1084 -- follows: 1085 -- 1086 -- SecurityCategory ::= SEQUENCE { 1087 -- type [0] OBJECT IDENTIFIER, 1088 -- value [1] EXPLICIT ANY DEFINED BY type 1089 -- } 1090 -- 1091 -- The removal of the IMPLICIT from the type line and the 1092 -- addition of the EXPLICIT to the value line result in 1093 -- no changes to the encodings. 1095 -- This is the same as the original syntax which was defined 1096 -- using the MACRO construct, as follows: 1097 -- SecurityCategory ::= SEQUENCE { 1098 -- type [0] IMPLICIT SECURITY-CATEGORY, 1099 -- value [1] ANY DEFINED BY type 1100 -- } 1101 -- 1102 -- SECURITY-CATEGORY MACRO ::= 1103 -- BEGIN 1104 -- TYPE NOTATION ::= type | empty 1105 -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 1106 -- END 1108 name { id-at-clearance } 1109 OID { joint-iso-ccitt(2) ds(5) module(1) 1110 selected-attribute-types(5) clearance (55) } 1111 syntax Clearance - imported from [X.501-1997] 1112 values Multiple allowed 1114 4.5. Profile of AC issuer's PKC 1116 The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage 1117 extension in the PKC MUST NOT explicitly indicate that the AC 1118 issuer's public key cannot be used to validate a digital signature. 1119 In order to avoid confusion regarding serial numbers and revocations, 1120 an AC issuer MUST NOT also be a PKC Issuer. That is, an AC issuer 1121 cannot be a CA as well. So, the AC issuer's PKC MUST NOT have a 1122 basicConstraints extension with the cA BOOLEAN set to TRUE. 1124 5. Attribute Certificate Validation 1126 This section describes a basic set of rules that all valid ACs MUST 1127 satisfy. Some additional checks are also described which AC 1128 verifiers MAY choose to implement. 1130 To be valid an AC MUST satisfy all of the following: 1132 1. Where the holder uses a PKC to authenticate to the AC verifier, 1133 the AC holder's PKC MUST be found, and the entire certification 1134 path of that PKC MUST be verified in accordance with [PKIXPROF]. 1135 As noted in the security considerations section, if some other 1136 authentication scheme is used, AC verifiers need to be very 1137 careful mapping the identities (authenticated identity, holder 1138 field) involved. 1140 2. The AC signature must be cryptographically correct, and the AC 1141 issuer's entire PKC certification path MUST be verified in 1142 accordance with [PKIXPROF]. 1144 3. The AC issuer's PKC MUST also conform to the profile specified in 1145 section 4.5 above. 1147 4. The AC issuer MUST be directly trusted as an AC issuer (by 1148 configuration or otherwise). 1150 5. The time for which the AC is being evaluated MUST be within the AC 1151 validity. If the evaluation time is equal to either notBeforeTime 1152 or notAfterTime, then the AC is timely and this check succeeds. 1153 Note that in some applications, the evaluation time MAY not be the 1154 same as the current time. 1156 6. The AC targeting check MUST pass as specified in section 4.3.2. 1158 7. If the AC contains an unsupported critical extension, the AC MUST 1159 be rejected. 1161 Support for an extension in this context means: 1163 1. The AC verifier MUST be able to parse the extension value. 1165 2. Where the extension value SHOULD cause the AC to be rejected, the 1166 AC verifier MUST reject the AC. 1168 Additional Checks: 1170 1. The AC MAY be rejected on the basis of further AC verifier 1171 configuration. For example, an AC verifier may be configured to 1172 reject ACs which contain or lack certain attributes. 1174 2. If the AC verifier provides an interface that allows applications 1175 to query the contents of the AC, then the AC verifier MAY filter 1176 the attributes from the AC on the basis of configured information. 1177 For example, an AC verifier might be configured not to return 1178 certain attributes to certain servers. 1180 6. Revocation 1182 In many environments, the validity period of an AC is less than the 1183 time required to issue and distribute revocation information. 1184 Therefore, short-lived ACs typically do not require revocation 1185 support. However, long-lived ACs and environments where ACs enable 1186 high value transactions MAY require revocation support. 1188 Two revocation schemes are defined, and the AC issuer should elect 1189 the one that is best suited to the environment in which the AC will 1190 be employed. 1192 "Never revoke" scheme: 1194 ACs may be marked so that the relying party understands that no 1195 revocation status information will be made available. The 1196 noRevAvail extension is defined in section 4.3.6, and the 1197 noRevAvail extension MUST be present in the AC to indicate use of 1198 this scheme. 1200 Where no noRevAvail is present, the AC issuer is implicitly stating 1201 that revocation status checks are supported, and some revocation 1202 method MUST be provided to allow AC verifiers to establish the 1203 revocation status of the AC. 1205 "Pointer in AC" scheme: 1207 ACs may "point" to sources of revocation status information, using 1208 either an authorityInfoAccess extension or a crlDistributionPoints 1209 extension within the AC. 1211 For AC users, the "never revoke" scheme MUST be supported, and the 1212 "pointer in AC" scheme SHOULD be supported. If only the "never 1213 revoke" scheme is supported, then all ACs that do not contain a 1214 noRevAvail extension, MUST be rejected. 1216 For AC issuers, the "never revoke" scheme MUST be supported. If all 1217 ACs that will ever be issued by that AC issuer, contains a noRevAvail 1218 extension, the "pointer in AC" scheme need not be supported. If any 1219 AC can be issued that does not contain the noRevAvail extension, the 1220 "pointer in AC" scheme MUST be supported. 1222 An AC MUST NOT contain both a noRevAvail and a "pointer in AC". 1224 An AC verifier MAY use any source for AC revocation status 1226 7. Optional Features 1228 This section specifies features that MAY be implemented. Conformance 1229 to this profile does NOT require support for these features; however, 1230 if these features are offered, they MUST be offered as described 1231 below. 1233 7.1. Attribute Encryption 1235 Where an AC will be carried in clear within an application protocol 1236 or where an AC contains some sensitive information like a legacy 1237 application username/password, then encryption of AC attributes MAY 1238 be needed. 1240 When a set of attributes are to be encrypted within an AC, the 1241 Cryptographic Message Syntax, EnvelopedData structure [CMS] is used 1242 to carry the ciphertext and associated per-recipient keying 1243 information. 1245 This type of attribute encryption is targeted. Before the AC is 1246 signed, the attributes are encrypted for a set of predetermined 1247 recipients. 1249 Within EnvelopedData, the encapsulatedContentInfo identifies the 1250 content type carried withing the ciphertext. In this case, the 1251 contentType field of encapsulatedContentInfo MUST contain id-ct- 1252 attrCertEncAttrs, which has the following value: 1254 attrCertEncAttrs OBJECT IDENTIFIER ::= { 1255 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1256 id-smime(16) id-ct(1) 14 } 1258 The ciphertext is included in the AC as the value of an encAttrs 1259 attribute. Only one encAttrs attribute can be present in an AC; 1260 however, the encAttrs attribute MAY be multi-valued, and each of its 1261 values will contain an independent EnvelopedData. 1263 Each value can contain a set of attributes (each possibly a multi- 1264 valued attribute) encrypted for a set of predetermined recipients. 1266 The cleartext that is encrypted has the type: 1268 ACClearAttrs ::= SEQUENCE { 1269 acIssuer GeneralName, 1270 acSerial INTEGER, 1271 attrs SEQUENCE OF Attribute 1272 } 1274 The DER encoding of the ACClearAttrs structure is used as the 1275 encryptedContent field of the EnvelopedData. The DER encoding MUST 1276 be embedded in an OCTET STRING. 1278 The acIssuer and acSerial fields are present to prevent ciphertext 1279 stealing. When an AC verifier has successfully decrypted an 1280 encrypted attribute, it MUST then check that the AC issuer and 1281 serialNumber fields contain the same values. This prevents a 1282 malicious AC issuer from copying ciphertext from another AC (without 1283 knowing its corresponding plaintext). 1285 The procedure for an AC issuer when encrypting attributes is 1286 illustrated by the following (any other procedure that gives the same 1287 result MAY be used): 1289 1. Identify the sets of attributes that are to be encrypted for 1290 each set of recipients. 1291 2. For each attribute set which is to be encrypted: 1292 2.1. Create an EnvelopedData structure for the data for this 1293 set of recipients. 1294 2.2. Encode the ContentInfo containing the EnvelopedData as a 1295 value of the encAttrs attribute. 1296 2.3. Ensure the cleartext attributes are not present in the 1297 to-be-signed AC. 1298 3. Add the encAttrs (with its multiple values) to the AC. 1300 Note that there may be more than one attribute of the same type (the 1301 same OBJECT IDENTIFIER) after decryption. That is, an AC MAY contain 1302 the same attribute type both in clear and in encrypted form (and 1303 indeed several times if the same recipient is associated with more 1304 than one EnvelopedData). One approach implementers may choose, would 1305 be to merge attribute values following decryption in order to re- 1306 establish the "once only" constraint. 1308 name id-aca-encAttrs 1309 OID { id-aca 6} 1310 Syntax ContentInfo 1311 values Multiple Allowed 1313 If an AC contains attributes, apparently encrypted for the AC 1314 verifier, the decryption process MUST NOT fail. If decryption does 1315 fail, the AC MUST be rejected. 1317 7.2. Proxying 1319 When a server acts as a client for another server on behalf of the AC 1320 holder, the server MAY need to proxy an AC. Such proxying MAY have 1321 to be done under the AC issuer's control, so that not every AC is 1322 proxiable and so that a given proxiable AC can be proxied in a 1323 targeted fashion. Support for chains of proxies (with more than one 1324 intermediate server) MAY also be required. Note that this does not 1325 involve a chain of ACs. 1327 In order to meet this requirement we define another extension, 1328 ProxyInfo, similar to the targeting extension. 1330 When this extension is present, the AC verifier must check that the 1331 entity from which the AC was received was allowed to send it and that 1332 the AC is allowed to be used by this verifier. 1334 The proxying information consists of a set of proxy information, each 1335 of which is a set of targeting information. If the verifier and the 1336 sender of the AC are both named in the same proxy set, the AC can 1337 then be accepted (the exact rule is given below). 1339 The effect is that the AC holder can send the AC to any valid target 1340 which can then only proxy to targets which are in one of the same 1341 proxy sets as itself. 1343 The following data structure is used to represent the 1344 targeting/proxying information. 1346 ProxyInfo ::= SEQUENCE OF Targets 1348 As in the case of targeting, the targetCert CHOICE MUST NOT be used. 1350 A proxy check succeeds if either one of the conditions below is met: 1352 1. The identity of the sender, as established by the underlying 1353 authentication service, matches the holder field of the AC, and 1354 the current server "matches" any one of the proxy sets. Recall 1355 that "matches" is as defined section 4.3.2. 1357 2. The identity of the sender, as established by the underlying 1358 authentication service, "matches" one of the proxy sets (call it 1359 set "A"), and the current server is one of the targetName fields 1360 in the set "A", or the current server is a member of one of the 1361 targetGroup fields in set "A". 1363 When an AC is proxied more than once, a number of targets will be on 1364 the path from the original client, which is normally, but not always, 1365 the AC holder. In such cases, prevention of AC "stealing" requires 1366 that the AC verifier MUST check that all targets on the path are 1367 members of the same proxy set. It is the responsibility of the AC- 1368 using protocol to ensure that a trustworthy list of targets on the 1369 path is available to the AC verifier. 1371 name id-pe-ac-proxying 1372 OID { id-pe 10 } 1373 syntax ProxyInfo 1374 criticality MUST be TRUE 1376 7.3. Use of ObjectDigestInfo 1378 In some environments, it may be required that the AC is not linked 1379 either to an identity (via entityName) or to a PKC (via 1380 baseCertificateID). The objectDigestInfo CHOICE in the holder field 1381 allows support for this requirement. 1383 If the holder is identified with the objectDigestInfo field, then the 1384 AC version field MUST contain v2 (the integer 1). 1386 The idea is to link the AC to an object by placing a hash of that 1387 object into the holder field of the AC. For example, this allows 1388 production of ACs that are linked to public keys rather than names. 1389 It also allows production of ACs which contain privileges associated 1390 with an executable object such as a Java class. However, this 1391 profile only specifies how to use a hash over a public key or PKC. 1392 That is, conformant ACs MUST NOT use the otherObjectTypes value for 1393 the digestedObjectType. 1395 To link an AC to a public key, the hash must be calculated over the 1396 representation of that public key which would be present in a PKC, 1397 specifically, the input for the hash algorithm MUST be the DER 1398 encoding of a SubjectPublicKeyInfo representation of the key. Note: 1399 This includes the AlgorithmIdentifier as well as the BIT STRING. The 1400 rules given in [PKIXPROF] for encoding keys MUST be followed. In 1401 this case, the digestedObjectType MUST be publicKey and the 1402 otherObjectTypeID field MUST NOT be present. 1404 Note that if the public key value used as input to the hash function 1405 has been extracted from a PKC, it is possible that the 1406 SubjectPublicKeyInfo from that PKC is NOT the value which should be 1407 hashed. This can occur if DSA Dss-parms are inherited as described 1408 in section 7.3.3 of [PKIXPROF]. The correct input for hashing in 1409 this context will include the value of the parameters inherited from 1410 the CA's PKC, and thus may differ from the SubjectPublicKeyInfo 1411 present in the PKC. 1413 Implementations which support this feature MUST be able to handle the 1414 representations of public keys for the algorithms specified in 1415 section 7.3 of [PKIXPROF]. In this case, the digestedObjectType MUST 1416 be publicKey and the otherObjectTypeID field MUST NOT be present. 1418 In order to link an AC to a PKC via a digest, the digest MUST be 1419 calculated over the DER encoding of the entire PKC, including the 1420 signature value. In this case the digestedObjectType MUST be 1421 publicKeyCert and the otherObjectTypeID field MUST NOT be present. 1423 7.4. AA Controls 1425 During AC validation a relying party has to answer the question: is 1426 this AC issuer trusted to issue ACs containing this attribute? The 1427 AAControls PKC extension MAY be used to help answer the question. The 1428 AAControls extension is intended to be used in CA and AC issuer PKCs. 1430 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1432 AAControls ::= SEQUENCE { 1433 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1434 permittedAttrs [0] AttrSpec OPTIONAL, 1435 excludedAttrs [1] AttrSpec OPTIONAL, 1436 permitUnSpecified BOOLEAN DEFAULT TRUE 1437 } 1439 AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER 1441 The AAControls extension is used as follows: 1443 The pathLenConstraint, if present, is interpreted as in [PKIXPROF]. 1444 It restricts the allowed distance between the AA CA (a CA directly 1445 trusted to include AAControls in its PKCs), and the AC issuer. 1447 The permittedAttrs field specifies a set of attribute types that any 1448 AC issuer below this AA CA is allowed to include in ACs. If this 1449 field is not present, it means that no attribute types are explicitly 1450 allowed. 1452 The excludedAttrs field specifies a set of attribute types that no AC 1453 issuer is allowed to include in ACs. If this field is not present, 1454 it means that no attribute types are explicitly disallowed. 1456 The permitUnSpecified field specifies how to handle attribute types 1457 which are not present in either the permittedAttrs or excludedAttrs 1458 fields. TRUE (the default) means that any unspecified attribute type 1459 is allowed in ACs; FALSE means that no unspecified attribute type is 1460 allowed. 1462 When AAControls are used, the following additional checks on an AA's 1463 PKC chain MUST all succeed for the AC to be valid: 1465 1. Some CA on the ACs certificate path MUST be directly trusted to 1466 issue PKCs which precede the AC issuer in the certification path; 1467 call this CA the "AA CA". 1469 2. All PKCs on the path from the AA CA, down to and including the AC 1470 issuer's PKC, MUST contain an AAControls extension; however, the 1471 AA CA's PKC need not contain this extension. 1473 3. Only those attributes in the AC which are allowed, according to 1474 all of the AAControls extension values in all of the PKCs from the 1475 AA CA to the AC issuer, may be used for authorization decisions; 1476 all other attributes MUST be ignored. This check MUST be applied 1477 to the set of attributes following attribute decryption, and the 1478 id-aca-encAttrs type MUST also be checked. 1480 name id-pe-aaControls 1481 OID { id-pe 6 } 1482 syntax AAControls 1483 criticality MAY be TRUE 1485 8. Security Considerations 1487 The protection afforded for private keys is a critical factor in 1488 maintaining security. Failure of AC issuers to protect their private 1489 keys will permit an attacker to masquerade as them, potentially 1490 generating false ACs or revocation status. Existence of bogus ACs 1491 and revocation status will undermine confidence in the system. If 1492 the compromise is detected, all ACs issued by the AC issuer MUST be 1493 revoked. Rebuilding after such a compromise will be problematic, so 1494 AC issuers are advised to implement a combination of strong technical 1495 measures (e.g., tamper-resistant cryptographic modules) and 1496 appropriate management procedures (e.g., separation of duties) to 1497 avoid such an incident. 1499 Loss of an AC issuer's private signing key may also be problematic. 1500 The AC issuer would not be able to produce revocation status or 1501 perform AC renewal. AC issuers are advised to maintain secure backup 1502 for signing keys. The security of the key backup procedures is a 1503 critical factor in avoiding key compromise. 1505 The availability and freshness of revocation status will affect the 1506 degree of assurance that should be placed in a long-lived AC. While 1507 long-lived ACs expire naturally, events may occur during its natural 1508 lifetime which negate the binding between the AC holder and the 1509 attributes. If revocation status is untimely or unavailable, the 1510 assurance associated with the binding is clearly reduced. 1512 The binding between an AC holder and attributes cannot be stronger 1513 than the cryptographic module implementation and algorithms used to 1514 generate the signature. Short key lengths or weak hash algorithms 1515 will limit the utility of an AC. AC issuers are encouraged to note 1516 advances in cryptology so they can employ strong cryptographic 1517 techniques. 1519 Inconsistent application of name comparison rules may result in 1520 acceptance of invalid targeted or proxied ACs, or rejection of valid 1521 ones. The X.500 series of specifications defines rules for comparing 1522 distinguished names. These rules require comparison of strings 1523 without regard to case, character set, multi-character white space 1524 substrings, or leading and trailing white space. This specification 1525 and [PKIXPROF] relaxes these requirements, requiring support for 1526 binary comparison at a minimum. 1528 AC issuers MUST encode the distinguished name in the AC 1529 holder.entityName field identically to the distinguished name in the 1530 holder's PKC. If different encodings are used, implementations of 1531 this specification may fail to recognize that the AC and PKC belong 1532 to the same entity. 1534 If an attribute certificate is tied to the holder's PKC using the 1535 baseCertificateID component of the Holder field and the PKI in use 1536 includes a rogue CA with the same issuer name specified in the 1537 baseCertificateID component, this rogue CA could issue a PKC to a 1538 malicious party, using the same issuer name and serial number as the 1539 proper holder's PKC. Then the malicious party could use this PKC in 1540 conjunction with the AC. This scenario SHOULD be avoided by properly 1541 managing and configuring the PKI so that there cannot be two CAs with 1542 the same name. Another alternative is to tie ACs to PKCs using the 1543 publicKeyCert type in the ObjectDigestInfo field. Failing this, AC 1544 verifiers have to establish (using other means) that the potential 1545 collisions cannot actually occur, for example, the CPSs of the CAs 1546 involved may make it clear that no such name collisions can occur. 1548 Implementers MUST ensure that following validation of an AC, only 1549 attributes that the issuer is trusted to issue are used in 1550 authorization decisions. Other attributes, which MAY be present MUST 1551 be ignored. Given that the AA controls PKC extension is optional to 1552 implement, AC verifiers MUST be provided with this information by 1553 other means. Configuration information is a likely alternative 1554 means. This becomes very important if an AC verifier trusts more 1555 than one AC issuer. 1557 There is often a requirement to map between the authentication 1558 supplied by a particular security protocol (e.g. TLS, S/MIME) and the 1559 AC holder's identity. If the authentication uses PKCs, then this 1560 mapping is straightforward. However, it is envisaged that ACs will 1561 also be used in environments where the holder may be authenticated 1562 using other means. Implementers SHOULD be very careful in mapping 1563 the authenticated identity to the AC holder. 1565 9. IANA Considerations 1567 Attributes and attribute certificate extensions are identified by 1568 object identifiers (OIDs). Many of the OIDs used in this document 1569 are copied from X.509 [X.509-2000]. Other OIDs were assigned from an 1570 arc delegated by the IANA. No further action by the IANA is 1571 necessary for this document or any anticipated updates. 1573 10. References 1575 10.1. Normative References 1577 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 3852, July 1578 2004. 1580 [HTTP-URL] Housley, R., and P. Hoffman, "Internet X.509 Public Key 1581 Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, ay 1582 1999. 1584 [LDAP-URL] Smith, E., and T. Howes, "Lightweight Directory Acces 1585 Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006. 1587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1588 Requirement Levels", BCP 14, RFC 2119, March 1997. 1590 [PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and 1591 Identifiers for the Internet X.509 Public Key Infrastructure 1592 Certificate and Certificate Revocation Lists CRL Profile", RFC 3279, 1593 April 2002. 1595 [PKIXPROF] Cooper, D., Santesson, S., Farrell, S., Boeyen, S. 1596 Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure 1597 Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, 1598 May 2008. 1600 10.2. Informative References 1602 [KRB] Yu, T., Hartman, S., Raeburn, K., and C. Neuman, "The Kerberos 1603 Network Authentication Service (V5)", RFC 4120, July 2005. 1605 [LDAP] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): 1606 Directory Information Models", RFC 4510, June 2006. 1608 [OCSP] Myers, M., Ankney, R., Malpani A., Galperin, S., and C. 1609 Adams, "X.509 Internet Public Key Infrastructure Online Certificate 1610 Status Protocol - OCSP", RFC 2560, June 1999. 1612 [RFC3281] Farrell, S., and R. Housley, "An Internet Attribute 1613 Certificate Profile for Authorization", RFC 3281, April 2002. 1615 [X.208-1988] CCITT Recommendation X.208: Specification of Abstract 1616 Syntax Notation One (ASN.1). 1988. 1618 [X.509-1988] CCITT Recommendation X.509: The Directory - 1619 Authentication Framework. 1988. 1621 [X.509-1997] ITU-T Recommendation X.509: The Directory - 1622 Authentication Framework. 1997. 1624 [X.509-2000] ITU-T Recommendation X.509: The Directory - Public-Key 1625 and Attribute Certificate Frameworks. 2000 1627 Appendix A Object Identifiers 1629 This (normative) appendix lists the new object identifiers which are 1630 defined in this specification. Some of these are required only for 1631 support of optional features and are not required for conformance to 1632 this profile. This specification mandates support for OIDs which 1633 have arc elements with values that are less than 2^32, (i.e. they 1634 MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less 1635 than 2^31 (i.e. less than or equal to 2,147,483,647). This allows 1636 each arc element to be represented within a single 32 bit word. 1637 Implementations MUST also support OIDs where the length of the dotted 1638 decimal (see [LDAP], section 4.1.2) string representation can be up 1639 to 100 bytes (inclusive). Implementations MUST be able to handle 1640 OIDs with up to 20 elements (inclusive). AA's SHOULD NOT issue ACs 1641 which contain OIDs that breach these requirements. 1643 The following OIDs are imported from [PKIXPROF]: 1645 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1646 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 1647 id-mod OBJECT IDENTIFIER ::= { id-pkix 0 } 1648 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 1649 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 1650 id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } 1651 id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 } 1653 The following new ASN.1 module OID is defined: 1655 id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 } 1657 The following AC extension OIDs are defined: 1659 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1660 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 } 1661 id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 1663 The following PKC extension OIDs are defined: 1665 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1667 The following attribute OIDs are defined: 1669 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1670 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1671 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1672 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1673 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1674 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1675 id-at-role OBJECT IDENTIFIER ::= { id-at 72 } 1676 id-at-clearance OBJECT IDENTIFIER ::= { 1677 joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) } 1678 id-at-clearance OBJECT IDENTIFIER ::= { 1679 joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5) 1680 clearance (55) } 1682 As noted in Section 4.2.6, there are two OIDs for id-at-clearance. 1684 Appendix B ASN.1 Module 1686 NOTE: The value for TBA will be included during AUTH48. 1688 //** RFC Editor: Remove this note prior to publication **// 1690 PKIXAttributeCertificate-2008 { iso(1) identified-organization(3) 1691 dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1692 id-mod-attribute-cert2(TBA) } 1694 DEFINITIONS IMPLICIT TAGS ::= 1696 BEGIN 1698 -- EXPORTS ALL -- 1699 IMPORTS 1701 -- IMPORTed module OIDs MAY change if [PKIXPROF] changes 1702 -- PKIX Certificate Extensions 1704 Attribute, AlgorithmIdentifier, CertificateSerialNumber, 1705 Extensions, UniqueIdentifier, id-pkix, id-pe, id-kp, id-ad, id-at 1706 FROM PKIX1Explicit88 1707 { iso(1) identified-organization(3) dod(6) internet(1) 1708 security(5) mechanisms(5) pkix(7) id-mod(0) 1709 id-pkix1-explicit-88(18) } 1711 GeneralName, GeneralNames, id-ce, AuthorityKeyIdentifier, 1712 AuthorityInfoAccessSyntax, CRLDistributionPoint 1713 FROM PKIX1Implicit88 1714 { iso(1) identified-organization(3) dod(6) internet(1) 1715 security(5) mechanisms(5) pkix(7) id-mod(0) 1716 id-pkix1-implicit-88(19) } 1718 ContentInfo 1719 FROM CryptographicMessageSyntax2004 1720 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1721 smime(16) modules(0) cms-2004(24) } 1723 ; 1725 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1727 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1729 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 } 1731 id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 1733 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1735 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1737 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1739 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1741 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1743 -- { id-aca 5 } is reserved 1745 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1746 id-at-role OBJECT IDENTIFIER ::= { id-at 72} 1748 id-at-clearance OBJECT IDENTIFIER ::= { 1749 joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) } 1751 -- Uncomment the following line and comment the above line if using 1752 -- the id-at-clearance attribe as defined in [RFC3281] 1754 -- id-at-clearance OBJECT IDENTIFIER ::= { 1755 -- joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5) 1756 -- clearance (55) } 1758 -- Uncomment this if using a 1988 level ASN.1 compiler 1760 -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 1762 AttributeCertificate ::= SEQUENCE { 1763 acinfo AttributeCertificateInfo, 1764 signatureAlgorithm AlgorithmIdentifier, 1765 signatureValue BIT STRING 1766 } 1768 AttributeCertificateInfo ::= SEQUENCE { 1769 version AttCertVersion, -- version is v2 1770 holder Holder, 1771 issuer AttCertIssuer, 1772 signature AlgorithmIdentifier, 1773 serialNumber CertificateSerialNumber, 1774 attrCertValidityPeriod AttCertValidityPeriod, 1775 attributes SEQUENCE OF Attribute, 1776 issuerUniqueID UniqueIdentifier OPTIONAL, 1777 extensions Extensions OPTIONAL 1778 } 1780 AttCertVersion ::= INTEGER { v2(1) } 1782 Holder ::= SEQUENCE { 1783 baseCertificateID [0] IssuerSerial OPTIONAL, 1784 -- the issuer and serial number of 1785 -- the holder's Public Key Certificate 1786 entityName [1] GeneralNames OPTIONAL, 1787 -- the name of the claimant or role 1788 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 1789 -- used to directly authenticate the 1790 -- holder, for example, an executable 1791 } 1792 ObjectDigestInfo ::= SEQUENCE { 1793 digestedObjectType ENUMERATED { 1794 publicKey (0), 1795 publicKeyCert (1), 1796 otherObjectTypes (2) }, 1797 -- otherObjectTypes MUST NOT 1798 -- MUST NOT be used in this profile 1799 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 1800 digestAlgorithm AlgorithmIdentifier, 1801 objectDigest BIT STRING 1802 } 1804 AttCertIssuer ::= CHOICE { 1805 v1Form GeneralNames, -- MUST NOT be used in this 1806 -- profile 1807 v2Form [0] V2Form -- v2 only 1808 } 1810 V2Form ::= SEQUENCE { 1811 issuerName GeneralNames OPTIONAL, 1812 baseCertificateID [0] IssuerSerial OPTIONAL, 1813 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 1814 -- issuerName MUST be present in this profile 1815 -- baseCertificateID and objectDigestInfo MUST 1816 -- NOT be present in this profile 1817 } 1819 IssuerSerial ::= SEQUENCE { 1820 issuer GeneralNames, 1821 serial CertificateSerialNumber, 1822 issuerUID UniqueIdentifier OPTIONAL 1823 } 1825 AttCertValidityPeriod ::= SEQUENCE { 1826 notBeforeTime GeneralizedTime, 1827 notAfterTime GeneralizedTime 1828 } 1830 Targets ::= SEQUENCE OF Target 1832 Target ::= CHOICE { 1833 targetName [0] GeneralName, 1834 targetGroup [1] GeneralName, 1835 targetCert [2] TargetCert 1836 } 1837 TargetCert ::= SEQUENCE { 1838 targetCertificate IssuerSerial, 1839 targetName GeneralName OPTIONAL, 1840 certDigestInfo ObjectDigestInfo OPTIONAL 1841 } 1843 IetfAttrSyntax ::= SEQUENCE { 1844 policyAuthority [0] GeneralNames OPTIONAL, 1845 values SEQUENCE OF CHOICE { 1846 octets OCTET STRING, 1847 oid OBJECT IDENTIFIER, 1848 string UTF8String 1849 } 1850 } 1852 SvceAuthInfo ::= SEQUENCE { 1853 service GeneralName, 1854 ident GeneralName, 1855 authInfo OCTET STRING OPTIONAL 1856 } 1858 RoleSyntax ::= SEQUENCE { 1859 roleAuthority [0] GeneralNames OPTIONAL, 1860 roleName [1] GeneralName 1861 } 1863 Clearance ::= SEQUENCE { 1864 policyId OBJECT IDENTIFIER, 1865 classList ClassList DEFAULT {unclassified}, 1866 securityCategories SET OF SecurityCategory OPTIONAL 1867 } 1869 -- Uncomment the following lines to support deprecated clearance 1870 -- syntax and comment out previous Clearance. 1872 -- Clearance ::= SEQUENCE { 1873 -- policyId [0] OBJECT IDENTIFIER, 1874 -- classList [1] ClassList DEFAULT {unclassified}, 1875 -- securityCategories [2] SET OF SecurityCategory OPTIONAL 1876 -- } 1877 ClassList ::= BIT STRING { 1878 unmarked (0), 1879 unclassified (1), 1880 restricted (2), 1881 confidential (3), 1882 secret (4), 1883 topSecret (5) 1884 } 1886 SecurityCategory ::= SEQUENCE { 1887 type [0] OBJECT IDENTIFIER, 1888 value [1] EXPLICIT ANY DEFINED BY type 1889 } 1891 -- Note that in [RFC3281] the syntax for SecurityCategory was 1892 -- as follows: 1893 -- 1894 -- SecurityCategory ::= SEQUENCE { 1895 -- type [0] OBJECT IDENTIFIER, 1896 -- value [1] EXPLICIT ANY DEFINED BY type 1897 -- } 1898 -- 1899 -- The removal of the IMPLICIT from the type line and the 1900 -- addition of the EXPLICIT to the value line result in 1901 -- no changes to the encoding. 1903 AAControls ::= SEQUENCE { 1904 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1905 permittedAttrs [0] AttrSpec OPTIONAL, 1906 excludedAttrs [1] AttrSpec OPTIONAL, 1907 permitUnSpecified BOOLEAN DEFAULT TRUE 1908 } 1910 AttrSpec ::= SEQUENCE OF OBJECT IDENTIFIER 1912 ACClearAttrs ::= SEQUENCE { 1913 acIssuer GeneralName, 1914 acSerial INTEGER, 1915 attrs SEQUENCE OF Attribute 1916 } 1918 ProxyInfo ::= SEQUENCE OF Targets 1920 END 1922 Appendix C Changes Since RFC 3281 1924 1. Created a new Section 1.1 "Terminology", renumbered Section 1.1- 1925 1.3 to 1.2-1.4, and moved first paragraph of Section 1 to Section 1926 1.1. 1928 2. In Section 2, replace S/MIME v3 with S/MIME v3.2. 1930 3. In Section 4.1, moved "," from the right of the ASN.1 comment to 1931 the left of the ASN.1 comment on the line describing version in the 1932 AttributerCertificateInfo structure. 1934 4. In Section 4.2, replaced pointer to 4.2.1.7 of RFC 3280 with 1935 pointer to 4.2.1.6 of RFC 5280. 1937 5. In Section 4.3.2, replaced "Confirming" with "Conforming". 1939 6. In Section 4.3.4, replaced reference to RFC 1738, URL, with 1940 references to [HTTP-URL]. 1942 7. In Section 4.3.5, replaced "HTTP or an LDAP" with "HTTP [HTTP-URL] 1943 or an LDAP [LDAP-URL]." Also replaced "CRLDistPointsSyntax" with 1944 "CRLDistributionPoints". 1946 8. In Section 4.4.6, added text to address having two OIDs for the 1947 same syntax and two syntaxes for one OID. 1949 9. In Section 7.1, replaced text that described encapsulating 1950 encrypted attribute with corrected text. 1952 10. Updated References: 1953 a) split references in to informative/normative references 1954 b) added reference to RFC 3281 1955 c) replaced reference to X.501:1993 with X.501:1997 1956 d) replaced reference to RFC 1510 with RFC 4120 1957 e) replaced reference to RFC 1738 with RFC 4516 and 2585 1958 f) replaced reference to RFC 2251 with RFC 4510 1959 g) replaced reference to RFC 2459 with RFC 5280 1960 h) replaced reference to RFC 2510 with RFC 4210 1961 i) replaced reference to RFC 2630 with RFC 3852 1962 j) replaced reference to RFC 2797 with RFC 5272 1963 k) deleted spurious reference to CMC, CMP, ESS, RFC 2026, 1964 X.209-88, and X.501:1988. 1966 11. In Appendix A, added 2nd clearance attribute object identifier. 1968 12. Appendix B, updated ASN.1 with changes 3, 8, 9, and 11: 1969 a) New OID for ASN.1 module. 1970 b) Updated module OIDs for PKIX1Implicit88 and PKIX1Implicit88. 1971 c) Added imports from PKIX1Implicit88 for AuthorityKeyIdentifier, 1972 AuthorityInfoAccessSyntax, CRLDistributionPoint 1973 d) Added imports from CryptographicMessageSyntax2004 for 1974 ContentInfo. 1975 e) Added comments and commented out ASN.1 for old clearance 1976 attribute syntax. 1978 Author's Addresses 1980 Sean Turner 1982 IECA, Inc. 1983 3057 Nutley Street, Suite 106 1984 Fairfax, VA 22031 1985 USA 1987 Email: turners@ieca.com 1989 Russ Housley 1991 Vigil Security, LLC 1992 918 Spring Knoll Drive 1993 Herndon, VA 20170 1994 USA 1996 EMail: housley@vigilsec.com 1998 Stephen Farrell 2000 Distributed Systems Group 2001 Computer Science Department 2002 Trinity College Dublin 2003 Ireland 2005 Email: stephen.farrell@cs.tcd.ie 2007 Full Copyright Statement 2009 Copyright (C) The IETF Trust (2008). 2011 This document is subject to the rights, licenses and restrictions 2012 contained in BCP 78, and except as set forth therein, the authors 2013 retain all their rights. 2015 This document and the information contained herein are provided on an 2016 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2017 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2018 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2019 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2020 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2021 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2023 Intellectual Property 2025 The IETF takes no position regarding the validity or scope of any 2026 Intellectual Property Rights or other rights that might be claimed to 2027 pertain to the implementation or use of the technology described in 2028 this document or the extent to which any license under such rights 2029 might or might not be available; nor does it represent that it has 2030 made any independent effort to identify any such rights. Information 2031 on the procedures with respect to rights in RFC documents can be 2032 found in BCP 78 and BCP 79. 2034 Copies of IPR disclosures made to the IETF Secretariat and any 2035 assurances of licenses to be made available, or the result of an 2036 attempt made to obtain a general license or permission for the use of 2037 such proprietary rights by implementers or users of this 2038 specification can be obtained from the IETF on-line IPR repository at 2039 http://www.ietf.org/ipr. 2041 The IETF invites any interested party to bring to its attention any 2042 copyrights, patents or patent applications, or other proprietary 2043 rights that may cover technology that may be required to implement 2044 this standard. Please address the information to the IETF at 2045 ietf-ipr@ietf.org. 2047 Acknowledgment 2049 Funding for the RFC Editor function is provided by the IETF 2050 Administrative Support Activity (IASA).