idnits 2.17.1 draft-ietf-pkix-3281update-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 and authors 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 20, 2008) is 5606 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 1917 -- Looks like a reference, but probably isn't: '1' on line 1918 -- Looks like a reference, but probably isn't: '2' on line 1887 == Missing Reference: 'UNIVERSAL 12' is mentioned on line 1773, but not defined ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 3281 (Obsoleted by RFC 5755) -- Duplicate reference: RFC3281, mentioned in 'RFC3281-ERR', was also mentioned in 'RFC3281'. ** Obsolete normative reference: RFC 3281 (Obsoleted by RFC 5755) -- Obsolete informational reference (is this intentional?): RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) Summary: 4 errors (**), 0 flaws (~~), 3 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 Obsoletes: 3281 (once approved) December 20, 2008 5 Expires: June 20, 2009 7 An Internet Attribute Certificate Profile for Authorization 8 draft-ietf-pkix-3281update-03.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on June 20, 2008. 33 Copyright Notice 35 Copyright (c) 2008 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 This specification defines a profile for the use of X.509 Attribute 48 Certificates in Internet Protocols. Attribute certificates may be 49 used in a wide range of applications and environments covering a 50 broad spectrum of interoperability goals and a broader spectrum of 51 operational and assurance requirements. The goal of this document is 52 to establish a common baseline for generic applications requiring 53 broad interoperability as well as limited special purpose 54 requirements. The profile places emphasis on attribute certificate 55 support for Internet electronic mail, IPSec, and WWW security 56 applications. This document obsoletes RFC 3281. 58 Discussion 60 This draft is being discussed on the 'ietf-pkix' mailing list. To 61 subscribe, send a message to ietf-pkix-request@imc.org with the 62 single word subscribe in the body of the message. There is a Web site 63 for the mailing list at . 65 Table of Contents 67 1. Introduction...................................................3 68 1.1. Requirements Terminology..................................5 69 1.2. AC Path Delegation........................................5 70 1.3. Attribute Certificate Distribution ("push" vs. "pull")....5 71 1.4. Document Structure........................................7 72 2. Terminology....................................................7 73 3. Requirements...................................................8 74 4. Attribute Certificate Profile..................................9 75 4.1. X.509 Attribute Certificate Definition....................9 76 4.2. Profile of Standard Fields...............................11 77 4.2.1. Version.............................................12 78 4.2.2. Holder..............................................12 79 4.2.3. Issuer..............................................13 80 4.2.4. Signature...........................................13 81 4.2.5. Serial Number.......................................14 82 4.2.6. Validity Period.....................................14 83 4.2.7. Attributes..........................................15 84 4.2.8. Issuer Unique Identifier............................15 85 4.2.9. Extensions..........................................15 86 4.3. Extensions...............................................16 87 4.3.1. Audit Identity......................................16 88 4.3.2. AC Targeting........................................17 89 4.3.3. Authority Key Identifier............................18 90 4.3.4. Authority Information Access........................18 91 4.3.5. CRL Distribution Points.............................19 92 4.3.6. No Revocation Available.............................19 93 4.4. Attribute Types..........................................20 94 4.4.1. Service Authentication Information..................20 95 4.4.2. Access Identity.....................................21 96 4.4.3. Charging Identity...................................21 97 4.4.4. Group...............................................22 98 4.4.5. Role................................................22 99 4.4.6. Clearance...........................................22 100 4.5. Profile of AC issuer's PKC...............................25 101 5. Attribute Certificate Validation..............................25 102 6. Revocation....................................................26 103 7. Optional Features.............................................27 104 7.1. Attribute Encryption.....................................28 105 7.2. Proxying.................................................29 106 7.3. Use of ObjectDigestInfo..................................31 107 7.4. AA Controls..............................................32 108 8. Security Considerations.......................................33 109 9. IANA Considerations...........................................35 110 10. References...................................................35 111 10.1. Normative References....................................35 112 10.2. Informative References..................................36 113 Appendix A Object Identifiers....................................36 114 Appendix B ASN.1 Module..........................................38 115 Appendix C Changes Since RFC 3281................................43 116 Author's Addresses...............................................45 118 1. Introduction 120 X.509 public key certificates (PKCs) [X.509-1997, X.509-2000, 121 PKIXPROF] bind an identity and a public key. An attribute 122 certificate (AC) is a structure similar to a PKC; the main difference 123 being that the AC contains no public key. An AC may contain 124 attributes that specify group membership, role, security clearance, 125 or other authorization information associated with the AC holder. 126 The syntax for the AC is defined in Recommendation X.509, making the 127 term "X.509 certificate" ambiguous. 129 Some people constantly confuse PKCs and ACs. An analogy may make the 130 distinction clear. A PKC can be considered to be like a passport: it 131 identifies the holder, tends to last for a long time, and should not 132 be trivial to obtain. An AC is more like an entry visa: it is 133 typically issued by a different authority and does not last for as 134 long a time. As acquiring an entry visa typically requires 135 presenting a passport, getting a visa can be a simpler process. 137 Authorization information may be placed in a PKC extension or placed 138 in a separate attribute certificate (AC). The placement of 139 authorization information in PKCs is usually undesirable for two 140 reasons. First, authorization information often does not have the 141 same lifetime as the binding of the identity and the public key. When 142 authorization information is placed in a PKC extension, the general 143 result is the shortening of the PKC useful lifetime. Second, the PKC 144 issuer is not usually authoritative for the authorization 145 information. This results in additional steps for the PKC issuer to 146 obtain authorization information from the authoritative source. 148 For these reasons, it is often better to separate authorization 149 information from the PKC. Yet, authorization information also needs 150 to be bound to an identity. An AC provides this binding; it is 151 simply a digitally signed (or certified) identity and set of 152 attributes. 154 An AC may be used with various security services, including access 155 control, data origin authentication, and non-repudiation. 157 PKCs can provide an identity to access control decision functions. 158 However, in many contexts the identity is not the criterion that is 159 used for access control decisions, rather the role or group- 160 membership of the accessor is the criterion used. Such access 161 control schemes are called role-based access control. 163 When making an access control decision based on an AC, an access 164 control decision function may need to ensure that the appropriate AC 165 holder is the entity that has requested access. One way in which the 166 linkage between the request or identity and the AC can be achieved is 167 the inclusion of a reference to a PKC within the AC and the use of 168 the private key corresponding to the PKC for authentication within 169 the access request. 171 ACs may also be used in the context of a data origin authentication 172 service and a non-repudiation service. In these contexts, the 173 attributes contained in the AC provide additional information about 174 the signing entity. This information can be used to make sure that 175 the entity is authorized to sign the data. This kind of checking 176 depends either on the context in which the data is exchanged or on 177 the data that has been digitally signed. 179 This document obsoletes [RFC3281]. Changes since [RFC3281] are listed 180 in Appendix C. 182 1.1. Requirements Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 1.2. AC Path Delegation 190 The X.509 standard [X.509-2000] defines authorization as the 191 "conveyance of privilege from one entity that holds such privilege, 192 to another entity". An AC is one authorization mechanism. 194 An ordered sequence of ACs could be used to verify the authenticity 195 of a privilege asserter's privilege. In this way, chains or paths of 196 ACs could be employed to delegate authorization. 198 Since the administration and processing associated with such AC 199 chains is complex and the use of ACs in the Internet today is quite 200 limited, this specification does NOT RECOMMEND the use of AC chains. 201 Other (future) specifications may address the use of AC chains. This 202 specification deals with the simple cases, where one authority issues 203 all of the ACs for a particular set of attributes. However, this 204 simplification does not preclude the use of several different 205 authorities, each of which manages a different set of attributes. 206 For example, group membership may be included in one AC issued by one 207 authority, and security clearance may be included in another AC 208 issued by another authority. 210 This means that conformant implementations are only REQUIRED to be 211 able to process a single AC at a time. Processing of more than one 212 AC, one after another, may be necessary. Note however, that 213 validation of an AC MAY require validation of a chain of PKCs, as 214 specified in [PKIXPROF]. 216 1.3. Attribute Certificate Distribution ("push" vs. "pull") 218 As discussed above, ACs provide a mechanism to securely provide 219 authorization information to, for example, access control decision 220 functions. However, there are a number of possible communication 221 paths for ACs. 223 In some environments, it is suitable for a client to "push" an AC to 224 a server. This means that no new connections between the client and 225 server are required. It also means that no search burden is imposed 226 on servers, which improves performance and that the AC verifier is 227 only presented with what it "needs to know." The "push" model is 228 especially suitable in inter-domain cases where the client's rights 229 should be assigned within the client's "home" domain. 231 In other cases, it is more suitable for a client to simply 232 authenticate to the server and for the server to request or "pull" 233 the client's AC from an AC issuer or a repository. A major benefit 234 of the "pull" model is that it can be implemented without changes to 235 the client or to the client-server protocol. The "pull" model is 236 especially suitable for inter-domain cases where the client's rights 237 should be assigned within the server's domain, rather than within the 238 client's domain. 240 There are a number of possible exchanges involving three entities: 241 the client, the server, and the AC issuer. In addition, a directory 242 service or other repository for AC retrieval MAY be supported. 244 Figure 1 shows an abstract view of the exchanges that may involve 245 ACs. This profile does not specify a protocol for these exchanges. 247 +--------------+ 248 | | Server Acquisition 249 | AC issuer +----------------------------+ 250 | | | 251 +--+-----------+ | 252 | | 253 | Client | 254 | Acquisition | 255 | | 256 +--+-----------+ +--+------------+ 257 | | AC "push" | | 258 | Client +-------------------------+ Server | 259 | | (part of app. protocol) | | 260 +--+-----------+ +--+------------+ 261 | | 262 | Client | Server 263 | Lookup +--------------+ | Lookup 264 | | | | 265 +---------------+ Repository +---------+ 266 | | 267 +--------------+ 269 Figure 1: AC Exchanges 271 1.4. Document Structure 273 Section 2 defines some terminology. Section 3 specifies the 274 requirements that this profile is intended to meet. Section 4 275 contains the profile of the X.509 AC. Section 5 specifies rules for 276 AC validation. Section 6 specifies rules for AC revocation checks. 277 Section 7 specifies optional features which MAY be supported; 278 however, support for these features is not required for conformance 279 to this profile. Finally, appendices contain the list of OIDs 280 required to support this specification and an ASN.1 module. 282 2. Terminology 284 For simplicity, we use the terms client and server in this 285 specification. This is not intended to indicate that ACs are only to 286 be used in client-server environments. For example, ACs may be used 287 in the S/MIME v3.2 context, where the mail user agent would be both a 288 "client" and a "server" in the sense the terms are used here. 290 Term Meaning 292 AA Attribute Authority, the entity that issues the 293 AC, synonymous in this specification with "AC 294 issuer". 296 AC Attribute Certificate. 298 AC user Any entity that parses or processes an AC. 300 AC verifier Any entity that checks the validity of an AC and 301 then makes use of the result. 303 AC issuer The entity which signs the AC, synonymous in this 304 specification with "AA". 306 AC holder The entity indicated (perhaps indirectly) in the 307 holder field of the AC. 309 Client The entity which is requesting the action for 310 which authorization checks are to be made. 312 Proxying In this specification, Proxying is used to mean 313 the situation where an application server acts as 314 an application client on behalf of a user. 315 Proxying here does not mean granting of authority. 317 PKC Public Key Certificate - uses the type ASN.1 318 Certificate defined in X.509 and profiled in RFC 319 2459. This (non-standard) acronym is used in order 320 to avoid confusion about the term "X.509 321 certificate". 323 Server The entity which requires that the authorization 324 checks are made. 326 3. Requirements 328 This AC profile meets the following requirements. 330 Time/Validity requirements: 332 1. Support for short-lived as well as long-lived ACs. Typical 333 short-lived validity periods might be measured in hours, as 334 opposed to months for PKCs. Short validity periods allow ACs to 335 be useful without a revocation mechanism. 337 Attribute Types: 339 2. Issuers of ACs should be able to define their own attribute types 340 for use within closed domains. 342 3. Some standard attribute types, which can be contained within ACs, 343 should be defined. Examples include "access identity," "group," 344 "role," "clearance," "audit identity," and "charging identity." 346 4. Standard attribute types should be defined in a manner that 347 permits an AC verifier to distinguish between uses of the same 348 attribute in different domains. For example, the "Administrators 349 group" as defined by Baltimore and the "Administrators group" as 350 defined by SPYRUS should be easily distinguished. 352 Targeting of ACs: 354 5. It should be possible to "target" an AC at one, or a small number 355 of, servers. This means that a trustworthy non-target server will 356 reject the AC for authorization decisions. 358 Push vs. Pull 360 6. ACs should be defined so that they can either be "pushed" by the 361 client to the server, or "pulled" by the server from a repository 362 or other network service, including an online AC issuer. 364 4. Attribute Certificate Profile 366 ACs may be used in a wide range of applications and environments 367 covering a broad spectrum of interoperability goals and a broader 368 spectrum of operational and assurance requirements. The goal of this 369 document is to establish a common baseline for generic applications 370 requiring broad interoperability and limited special purpose 371 requirements. In particular, the emphasis will be on supporting the 372 use of attribute certificates for informal Internet electronic mail, 373 IPSec, and WWW applications. 375 This section presents a profile for ACs that will foster 376 interoperability. This section also defines some private extensions 377 for the Internet community. 379 While the ISO/IEC/ITU documents use the 1993 (or later) version of 380 ASN.1, this document uses the 1988 ASN.1 syntax, as has been done for 381 PKCs [PKIXPROF]. The encoded certificates and extensions from either 382 ASN.1 version are bit-wise identical. 384 Where maximum lengths for fields are specified, these lengths refer 385 to the DER encoding and do not include the ASN.1 tag or length 386 fields. 388 Conforming implementations MUST support the profile specified in this 389 section. 391 4.1. X.509 Attribute Certificate Definition 393 X.509 contains the definition of an AC given below. All types that 394 are not defined in this document can be found in [PKIXPROF]. 396 AttributeCertificate ::= SEQUENCE { 397 acinfo AttributeCertificateInfo, 398 signatureAlgorithm AlgorithmIdentifier, 399 signatureValue BIT STRING 400 } 401 AttributeCertificateInfo ::= SEQUENCE { 402 version AttCertVersion, -- version is v2 403 holder Holder, 404 issuer AttCertIssuer, 405 signature AlgorithmIdentifier, 406 serialNumber CertificateSerialNumber, 407 attrCertValidityPeriod AttCertValidityPeriod, 408 attributes SEQUENCE OF Attribute, 409 issuerUniqueID UniqueIdentifier OPTIONAL, 410 extensions Extensions OPTIONAL 411 } 413 AttCertVersion ::= INTEGER { v2(1) } 415 Holder ::= SEQUENCE { 416 baseCertificateID [0] IssuerSerial OPTIONAL, 417 -- the issuer and serial number of 418 -- the holder's Public Key Certificate 419 entityName [1] GeneralNames OPTIONAL, 420 -- the name of the claimant or role 421 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 422 -- used to directly authenticate the holder, 423 -- for example, an executable 424 } 426 ObjectDigestInfo ::= SEQUENCE { 427 digestedObjectType ENUMERATED { 428 publicKey (0), 429 publicKeyCert (1), 430 otherObjectTypes (2) }, 431 -- otherObjectTypes MUST NOT 432 -- be used in this profile 433 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 434 digestAlgorithm AlgorithmIdentifier, 435 objectDigest BIT STRING 436 } 438 AttCertIssuer ::= CHOICE { 439 v1Form GeneralNames, -- MUST NOT be used in this 440 -- profile 441 v2Form [0] V2Form -- v2 only 442 } 444 V2Form ::= SEQUENCE { 445 issuerName GeneralNames OPTIONAL, 446 baseCertificateID [0] IssuerSerial OPTIONAL, 447 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 448 -- issuerName MUST be present in this profile 449 -- baseCertificateID and objectDigestInfo MUST NOT 450 -- be present in this profile 451 } 453 IssuerSerial ::= SEQUENCE { 454 issuer GeneralNames, 455 serial CertificateSerialNumber, 456 issuerUID UniqueIdentifier OPTIONAL 457 } 459 AttCertValidityPeriod ::= SEQUENCE { 460 notBeforeTime GeneralizedTime, 461 notAfterTime GeneralizedTime 462 } 464 Although the Attribute syntax is defined in [PKIXPROF], we repeat the 465 definition here for convenience. 467 Attribute ::= SEQUENCE { 468 type AttributeType, 469 values SET OF AttributeValue 470 -- at least one value is required 471 } 473 AttributeType ::= OBJECT IDENTIFIER 475 AttributeValue ::= ANY DEFINED BY AttributeType 477 Implementers should note that the DER encoding (see [X.509- 478 1988],[X.208-1988]) of the SET OF values requires ordering of the 479 encodings of the values. Though this issue arises with respect to 480 distinguished names, and has to be handled by [PKIXPROF] 481 implementations, it is much more significant in this context, since 482 the inclusion of multiple values is much more common in ACs. 484 4.2. Profile of Standard Fields 486 GeneralName offers great flexibility. To achieve interoperability, 487 in spite of this flexibility, this profile imposes constraints on the 488 use of GeneralName. 490 Conforming implementations MUST be able to support the dNSName, 491 directoryName, uniformResourceIdentifier, and iPAddress options. This 492 is compatible with the GeneralName requirements in [PKIXPROF] (mainly 493 in section 4.2.1.6). 495 Conforming implementations MUST NOT use the x400Address, 496 ediPartyName, or registeredID options. 498 Conforming implementations MAY use the otherName option to convey 499 name forms defined in Internet Standards. For example, Kerberos 500 [KRB] format names can be encoded into the otherName, using a 501 Kerberos 5 principal name OID and a SEQUENCE of the Realm and the 502 PrincipalName. 504 4.2.1. Version 506 The version field MUST have the value of v2. That is, the version 507 field is present in the DER encoding. 509 Note: This version (v2) is not backwards compatible with the previous 510 attribute certificate definition (v1) from the 1997 X.509 standard 511 [X.509-1997], but is compatible with the v2 definition from X.509 512 (2000) [X.509-2000]. 514 4.2.2. Holder 516 The Holder field is a SEQUENCE allowing three different (optional) 517 syntaxes: baseCertificateID, entityName and objectDigestInfo. Where 518 only one option is present, the meaning of the Holder field is clear. 519 However, where more than one option is used, there is a potential for 520 confusion as to which option is "normative", which is a "hint" etc. 521 Since the correct position is not clear from [X.509-2000], this 522 specification RECOMMENDS that only one of the options be used in any 523 given AC. 525 For any environment where the AC is passed in an authenticated 526 message or session and where the authentication is based on the use 527 of an X.509 PKC, the holder field SHOULD use the baseCertificateID. 529 With the baseCertificateID option, the holder's PKC serialNumber and 530 issuer MUST be identical to the AC holder field. The PKC issuer MUST 531 have a non-empty distinguished name which is to be present as the 532 single value of the holder.baseCertificateID.issuer construct in the 533 directoryName field. The AC holder.baseCertificateID.issuerUID field 534 MUST only be used if the holder's PKC contains an issuerUniqueID 535 field. If both the AC holder.baseCertificateID.issuerUID and the PKC 536 issuerUniqueID fields are present, the same value MUST be present in 537 both fields. Thus, the baseCertificateID is only usable with PKC 538 profiles (like [PKIXPROF]) which mandate that the PKC issuer field 539 contain a non-empty distinguished name value. 541 Note: An empty distinguished name is a distinguished name where the 542 SEQUENCE OF relative distinguished names is of zero length. In a DER 543 encoding, this has the value '3000'H. 545 If the holder field uses the entityName option and the underlying 546 authentication is based on a PKC, the entityName MUST be the same as 547 the PKC subject field or one of the values of the PKC subjectAltName 548 field extension (if present). Note that [PKIXPROF] mandates that the 549 subjectAltName extension be present if the PKC subject is an empty 550 distinguished name. See the security considerations section which 551 mentions some name collision problems that may arise when using the 552 entityName option. 554 In any other case where the holder field uses the entityName option, 555 only one name SHOULD be present. 557 Implementations conforming to this profile are not required to 558 support the use of the objectDigest field. However, section 7.3 559 specifies how this optional feature MAY be used. 561 Any protocol conforming to this profile SHOULD specify which AC 562 holder option is to be used and how this fits with the supported 563 authentication schemes defined in that protocol. 565 4.2.3. Issuer 567 ACs conforming to this profile MUST use the v2Form choice, which MUST 568 contain one and only one GeneralName in the issuerName, which MUST 569 contain a non-empty distinguished name in the directoryName field. 570 This means that all AC issuers MUST have non-empty distinguished 571 names. ACs conforming to this profile MUST omit the 572 baseCertificateID and objectDigestInfo fields. 574 Part of the reason for the use of the v2Form containing only an 575 issuerName is that it means that the AC issuer does not have to know 576 which PKC the AC verifier will use for it (the AC issuer). Using the 577 baseCertificateID field to reference the AC issuer would mean that 578 the AC verifier would have to trust the PKC that the AC issuer chose 579 (for itself) at AC creation time. 581 4.2.4. Signature 583 Contains the algorithm identifier used to validate the AC signature. 585 This MUST be one of the signing algorithms defined in [PKIXALGS]. 586 Conforming implementations MUST honor all MUST/SHOULD/MAY signing 587 algorithm statements specified in [PKIXALGS]. 589 4.2.5. Serial Number 591 For any conforming AC, the issuer/serialNumber pair MUST form a 592 unique combination, even if ACs are very short-lived. 594 AC issuers MUST force the serialNumber to be a positive integer, that 595 is, the sign bit in the DER encoding of the INTEGER value MUST be 596 zero - this can be done by adding a leading (leftmost) '00'H octet if 597 necessary. This removes a potential ambiguity in mapping between a 598 string of octets and an integer value. 600 Given the uniqueness and timing requirements above, serial numbers 601 can be expected to contain long integers. AC users MUST be able to 602 handle serialNumber values longer than 4 octets. Conformant ACs MUST 603 NOT contain serialNumber values longer than 20 octets. 605 There is no requirement that the serial numbers used by any AC issuer 606 follow any particular ordering. In particular, they need not be 607 monotonically increasing with time. Each AC issuer MUST ensure that 608 each AC that it issues contains a unique serial number. 610 4.2.6. Validity Period 612 The attrCertValidityPeriod (a.k.a. validity) field specifies the 613 period for which the AC issuer certifies that the binding between the 614 holder and the attributes fields will be valid. 616 The generalized time type, GeneralizedTime, is a standard ASN.1 type 617 for variable precision representation of time. The GeneralizedTime 618 field can optionally include a representation of the time 619 differential between the local time zone and Greenwich Mean Time. 621 For the purposes of this profile, GeneralizedTime values MUST be 622 expressed in Coordinated universal time (UTC) (also known as 623 Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times 624 are YYYYMMDDHHMMSSZ), even when the number of seconds is zero. 625 GeneralizedTime values MUST NOT include fractional seconds. 627 (Note: this is the same as specified in [PKIXPROF], section 628 4.1.2.5.2.) 630 AC users MUST be able to handle an AC which, at the time of 631 processing, has parts of its validity period or all its validity 632 period in the past or in the future (a post-dated AC). This is valid 633 for some applications, such as backup. 635 4.2.7. Attributes 637 The attributes field gives information about the AC holder. When the 638 AC is used for authorization, this will often contain a set of 639 privileges. 641 The attributes field contains a SEQUENCE OF Attribute. Each 642 Attribute MAY contain a SET OF values. For a given AC, each 643 AttributeType OBJECT IDENTIFIER in the sequence MUST be unique. That 644 is, only one instance of each attribute can occur in a single AC, but 645 each instance can be multi-valued. 647 AC users MUST be able to handle multiple values for all attribute 648 types. 650 An AC MUST contain at least one attribute. That is, the SEQUENCE OF 651 Attributes MUST NOT be of zero length. 653 Some standard attribute types are defined in section 4.4. 655 4.2.8. Issuer Unique Identifier 657 This field MUST NOT be used unless it is also used in the AC issuer's 658 PKC, in which case it MUST be used. Note that [PKIXPROF] states that 659 this field SHOULD NOT be used by conforming CAs, but that 660 applications SHOULD be able to parse PKCs containing the field. 662 4.2.9. Extensions 664 The extensions field generally gives information about the AC as 665 opposed to information about the AC holder. 667 An AC that has no extensions conforms to the profile; however, 668 section 4.3 defines the extensions that MAY be used with this 669 profile, and whether or not they may be marked critical. If any 670 other critical extension is used, the AC does not conform to this 671 profile. However, if any other non-critical extension is used, the 672 AC does conform to this profile. 674 The extensions defined for ACs provide methods for associating 675 additional attributes with holders. This profile also allows 676 communities to define private extensions to carry information unique 677 to those communities. Each extension in an AC may be designated as 678 critical or non-critical. An AC using system MUST reject an AC if it 679 encounters a critical extension it does not recognize; however, a 680 non-critical extension may be ignored if it is not recognized. 681 Section 4.3 presents recommended extensions used within Internet ACs 682 and standard locations for information. Communities may elect to use 683 additional extensions; however, caution should be exercised in 684 adopting any critical extensions in ACs which might prevent use in a 685 general context. 687 4.3. Extensions 689 4.3.1. Audit Identity 691 In some circumstances, it is required (e.g. by data protection/data 692 privacy legislation) that audit trails not contain records which 693 directly identify individuals. This circumstance may make the use of 694 the AC holder field unsuitable for use in audit trails. 696 To allow for such cases, an AC MAY contain an audit identity 697 extension. Ideally it SHOULD be infeasible to derive the AC holder's 698 identity from the audit identity value without the cooperation of the 699 AC issuer. 701 The value of the audit identity, along with the AC issuer/serial, 702 SHOULD then be used for audit/logging purposes. If the value of the 703 audit identity is suitably chosen, a server/service administrator can 704 use audit trails to track the behavior of an AC holder without being 705 able to identify the AC holder. 707 The server/service administrator in combination with the AC issuer 708 MUST be able to identify the AC holder in cases where misbehavior is 709 detected. This means that the AC issuer MUST be able to determine 710 the actual identity of the AC holder from the audit identity. 712 Of course, auditing could be based on the AC issuer/serial pair; 713 however, this method does not allow tracking of the same AC holder 714 with multiple ACs. Thus, an audit identity is only useful if it 715 lasts for longer than the typical AC lifetime. Auditing could also 716 be based on the AC holder's PKC issuer/serial; however, this will 717 often allow the server/service administrator to identify the AC 718 holder. 720 As the AC verifier might otherwise use the AC holder or some other 721 identifying value for audit purposes, this extension MUST be critical 722 when used. 724 Protocols that use ACs will often expose the identity of the AC 725 holder in the bits on-the-wire. In such cases, an opaque audit 726 identity does not make use of the AC anonymous; it simply ensures 727 that the ensuing audit trails do not contain identifying information. 729 The value of an audit identity MUST be longer than zero octets. The 730 value of an audit identity MUST NOT be longer than 20 octets. 732 name id-pe-ac-auditIdentity 733 OID { id-pe 4 } 734 syntax OCTET STRING 735 criticality MUST be TRUE 737 4.3.2. AC Targeting 739 To target an AC, the target information extension, imported from 740 [X.509-2000], MAY be used to specify a number of servers/services. 741 The intent is that the AC SHOULD only be usable at the specified 742 servers/services. An (honest) AC verifier who is not amongst the 743 named servers/services MUST reject the AC. 745 If this extension is not present, the AC is not targeted and may be 746 accepted by any server. 748 In this profile, the targeting information simply consists of a list 749 of named targets or groups. 751 The following syntax is used to represent the targeting information: 753 Targets ::= SEQUENCE OF Target 755 Target ::= CHOICE { 756 targetName [0] GeneralName, 757 targetGroup [1] GeneralName, 758 targetCert [2] TargetCert 759 } 761 TargetCert ::= SEQUENCE { 762 targetCertificate IssuerSerial, 763 targetName GeneralName OPTIONAL, 764 certDigestInfo ObjectDigestInfo OPTIONAL 765 } 767 The targetCert CHOICE within the Target structure is only present to 768 allow future compatibility with [X.509-2000] and MUST NOT be used. 770 The targets check passes if the current server (recipient) is one of 771 the targetName fields in the Targets SEQUENCE, or if the current 772 server is a member of one of the targetGroup fields in the Targets 773 SEQUENCE. In this case, the current server is said to "match" the 774 targeting extension. 776 How the membership of a target within a targetGroup is determined is 777 not defined here. It is assumed that any given target "knows" the 778 names of the targetGroups to which it belongs or can otherwise 779 determine its membership. For example, the targetGroup specifies a 780 DNS domain, and the AC verifier knows the DNS domain to which it 781 belongs. For another example, the targetGroup specifies "PRINTERS," 782 and the AC verifier knows whether or not it is a printer or print 783 server. 785 Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF 786 Targets". Conforming AC issuer implementations MUST only produce one 787 "Targets" element. Conforming AC users MUST be able to accept a 788 "SEQUENCE OF Targets". If more than one Targets element is found in 789 an AC, the extension MUST be treated as if all Target elements had 790 been found within one Targets element. 792 name id-ce-targetInformation 793 OID { id-ce 55 } 794 syntax SEQUENCE OF Targets 795 criticality MUST be TRUE 797 4.3.3. Authority Key Identifier 799 The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY 800 be used to assist the AC verifier in checking the signature of the 801 AC. The [PKIXPROF] description should be read as if "CA" meant "AC 802 issuer." As with PKCs, this extension SHOULD be included in ACs. 804 Note: An AC, where the issuer field used the baseCertificateID 805 CHOICE, would not need an authorityKeyIdentifier extension, as it is 806 explicitly linked to the key in the referred certificate. However, 807 as this profile states (in section 4.2.3), ACs MUST use the v2Form 808 with issuerName CHOICE, this duplication does not arise. 810 name id-ce-authorityKeyIdentifier 811 OID { id-ce 35 } 812 syntax AuthorityKeyIdentifier 813 criticality MUST be FALSE 815 4.3.4. Authority Information Access 817 The authorityInformationAccess extension, as defined in [PKIXPROF], 818 MAY be used to assist the AC verifier in checking the revocation 819 status of the AC. Support for the id-ad-caIssuers accessMethod is 820 NOT REQUIRED by this profile since AC chains are not expected. 822 The following accessMethod is used to indicate that revocation status 823 checking is provided for this AC, using the OCSP protocol defined in 824 [OCSP]: 826 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 828 The accessLocation MUST contain a URI, and the URI MUST contain an 829 HTTP URL [HTTP-URL] that specifies the location of an OCSP responder. 830 The AC issuer MUST, of course, maintain an OCSP responder at this 831 location. 833 name id-ce-authorityInfoAccess 834 OID { id-pe 1 } 835 syntax AuthorityInfoAccessSyntax 836 criticality MUST be FALSE 838 4.3.5. CRL Distribution Points 840 The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY 841 be used to assist the AC verifier in checking the revocation status 842 of the AC. See section 6 for details on revocation. 844 If the crlDistributionPoints extension is present, then exactly one 845 distribution point MUST be present. The crlDistributionPoints 846 extension MUST use the DistributionPointName option, which MUST 847 contain a fullName, which MUST contain a single name form. That name 848 MUST contain either a distinguished name or a URI. The URI MUST be 849 either an HTTP URL [HTTP-URL] or an LDAP URL [LDAP-URL]. 851 name id-ce-cRLDistributionPoints 852 OID { id-ce 31 } 853 syntax CRLDistributionPoints 854 criticality MUST be FALSE 856 4.3.6. No Revocation Available 858 The noRevAvail extension, defined in [X.509-2000], allows an AC 859 issuer to indicate that no revocation information will be made 860 available for this AC. 862 This extension MUST be non-critical. An AC verifier that does not 863 understand this extension might be able to find a revocation list 864 from the AC issuer, but the revocation list will never include an 865 entry for the AC. 867 name id-ce-noRevAvail 868 OID { id-ce 56 } 869 syntax NULL (i.e. '0500'H is the DER encoding) 870 criticality MUST be FALSE 872 4.4. Attribute Types 874 Some of the attribute types defined below make use of the 875 IetfAttrSyntax type, also defined below. The reasons for using this 876 type are: 878 1. It allows a separation between the AC issuer and the attribute 879 policy authority. This is useful for situations where a single 880 policy authority (e.g. an organization) allocates attribute 881 values, but where multiple AC issuers are deployed for performance 882 or other reasons. 884 2. The syntaxes allowed for values are restricted to OCTET STRING, 885 OBJECT IDENTIFIER, and UTF8String, which significantly reduces the 886 complexity associated with matching more general syntaxes. All 887 multi-valued attributes using this syntax are restricted so that 888 each value MUST use the same choice of value syntax. For example, 889 AC issuers must not use one value with an oid and a second value 890 with a string. 892 IetfAttrSyntax ::= SEQUENCE { 893 policyAuthority [0] GeneralNames OPTIONAL, 894 values SEQUENCE OF CHOICE { 895 octets OCTET STRING, 896 oid OBJECT IDENTIFIER, 897 string UTF8String 898 } 899 } 901 In the descriptions below, each attribute type is either tagged 902 "Multiple Allowed" or "One Attribute value only; multiple values 903 within the IetfAttrSyntax". This refers to the SET OF 904 AttributeValues; the AttributeType still only occurs once, as 905 specified in section 4.2.7. 907 4.4.1. Service Authentication Information 909 The SvceAuthInfo attribute identifies the AC holder to the 910 server/service by a name, and the attribute MAY include optional 911 service specific authentication information. Typically this will 912 contain a username/password pair for a "legacy" application. 914 This attribute provides information that can be presented by the AC 915 verifier to be interpreted and authenticated by a separate 916 application within the target system. Note that this is a different 917 use to that intended for the accessIdentity attribute in 4.4.2 below. 919 This attribute type will typically be encrypted when the authInfo 920 field contains sensitive information, such as a password. 922 name id-aca-authenticationInfo 923 OID { id-aca 1 } 924 Syntax SvceAuthInfo 925 values: Multiple allowed 927 SvceAuthInfo ::= SEQUENCE { 928 service GeneralName, 929 ident GeneralName, 930 authInfo OCTET STRING OPTIONAL 931 } 933 4.4.2. Access Identity 935 The accessIdentity attribute identifies the AC holder to the 936 server/service. For this attribute the authInfo field MUST NOT be 937 present. 939 This attribute is intended to be used to provide information about 940 the AC holder, that can be used by the AC verifier (or a larger 941 system of which the AC verifier is a component) to authorize the 942 actions of the AC holder within the AC verifier's system. Note that 943 this is a different use to that intended for the svceAuthInfo 944 attribute described in 4.4.1 above. 946 name id-aca-accessIdentity 947 OID { id-aca 2 } 948 syntax SvceAuthInfo 949 values: Multiple allowed 951 4.4.3. Charging Identity 953 The chargingIdentity attribute identifies the AC holder for charging 954 purposes. In general, the charging identity will be different from 955 other identities of the holder. For example, the holder's company 956 may be charged for service. 958 name id-aca-chargingIdentity 959 OID { id-aca 3 } 960 syntax IetfAttrSyntax 961 values: One Attribute value only; multiple values within the 962 IetfAttrSyntax 964 4.4.4. Group 966 The group attribute carries information about group memberships of 967 the AC holder. 969 name id-aca-group 970 OID { id-aca 4 } 971 syntax IetfAttrSyntax 972 values: One Attribute value only; multiple values within the 973 IetfAttrSyntax 975 4.4.5. Role 977 The role attribute, specified in [X.509-2000], carries information 978 about role allocations of the AC holder. 980 The syntax used for this attribute is: 982 RoleSyntax ::= SEQUENCE { 983 roleAuthority [0] GeneralNames OPTIONAL, 984 roleName [1] GeneralName 985 } 987 The roleAuthority field MAY be used to specify the issuing authority 988 for the role specification certificate. There is no requirement that 989 a role specification certificate necessarily exists for the 990 roleAuthority. This differs from [X.500-2000], where the 991 roleAuthority field is assumed to name the issuer of a role 992 specification certificate. For example, to distinguish the 993 administrator role as defined by "Baltimore" from that defined by 994 "SPYRUS", one could put the value "urn:administrator" in the roleName 995 field and the value "Baltimore" or "SPYRUS" in the roleAuthority 996 field. 998 The roleName field MUST be present, and roleName MUST use the 999 uniformResourceIdentifier CHOICE of the GeneralName. 1001 name id-at-role 1002 OID { id-at 72 } 1003 syntax RoleSyntax 1004 values: Multiple allowed 1006 4.4.6. Clearance 1008 The clearance attribute, specified in [X.501-1993], carries clearance 1009 (associated with security labeling) information about the AC holder. 1011 The policyId field is used to identify the security policy to which 1012 the clearance relates. The policyId indicates the semantics of the 1013 classList and securityCategories fields. 1015 This specification includes the classList field exactly as it is 1016 specified in [X.501-1993]. Additional security classification 1017 values, and their position in the classification hierarchy, may be 1018 defined by a security policy as a local matter or by bilateral 1019 agreement. The basic security classification hierarchy is, in 1020 ascending order: unmarked, unclassified, restricted, confidential, 1021 secret, and top-secret. 1023 An organization can develop its own security policy that defines 1024 security classification values and their meanings. However, the BIT 1025 STRING positions 0 through 5 are reserved for the basic security 1026 classification hierarchy. 1028 If present, the SecurityCategory field provides further authorization 1029 information. The security policy identified by the policyId field 1030 indicates the syntaxes that are allowed to be present in the 1031 securityCategories SET. An OBJECT IDENTIFIER identifies each of the 1032 allowed syntaxes. When one of these syntaxes is present in the 1033 securityCategories SET, the OBJECT IDENTIFIER associated with that 1034 syntax is carried in the SecurityCategory.type field. 1036 The object identifier for the clearance attribute from [RFC3281] is: 1038 id-at-clearance OBJECT IDENTIFIER ::= { 1039 joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5) 1040 clearance (55) } 1042 The associated syntax is: 1044 Clearance ::= SEQUENCE { 1045 policyId [0] OBJECT IDENTIFIER, 1046 classList [1] ClassList DEFAULT {unclassified}, 1047 securityCategories [2] SET OF SecurityCategory OPTIONAL 1048 } 1050 But, it was later amended to: 1052 Clearance ::= SEQUENCE { 1053 policyId OBJECT IDENTIFIER, 1054 classList ClassList DEFAULT {unclassified}, 1055 securityCategories SET OF SecurityCategory OPTIONAL 1056 } 1058 The object identifier for the clearance attribute from [X.509-1997] 1059 is: 1061 id-at-clearance OBJECT IDENTIFIER ::= { 1062 joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) } 1064 The associated syntax is as follows: 1066 Clearance ::= SEQUENCE { 1067 policyId OBJECT IDENTIFIER, 1068 classList ClassList DEFAULT {unclassified}, 1069 securityCategories SET OF SecurityCategory OPTIONAL 1070 } 1072 Implementations MUST support the clearance attribute as defined in 1073 [X.501-1997]. Implementations SHOULD support decoding the clearance 1074 syntax from [RFC3281] and the errata against it [RFC3281-ERR]. 1075 Implementations MUST NOT output the clearance attribute as defined in 1076 [RFC3281]. 1078 ClassList ::= BIT STRING { 1079 unmarked (0), 1080 unclassified (1), 1081 restricted (2), 1082 confidential (3), 1083 secret (4), 1084 topSecret (5) 1085 } 1087 SecurityCategory ::= SEQUENCE { 1088 type [0] OBJECT IDENTIFIER, 1089 value [1] EXPLICIT ANY DEFINED BY type 1090 } 1092 -- Note that in [RFC3281] the SecurityCategory syntax was as 1093 -- follows: 1094 -- 1095 -- SecurityCategory ::= SEQUENCE { 1096 -- type [0] OBJECT IDENTIFIER, 1097 -- value [1] EXPLICIT ANY DEFINED BY type 1098 -- } 1099 -- 1100 -- The removal of the IMPLICIT from the type line and the 1101 -- addition of the EXPLICIT to the value line result in 1102 -- no changes to the encodings. 1104 -- This is the same as the original syntax which was defined 1105 -- using the MACRO construct, as follows: 1106 -- SecurityCategory ::= SEQUENCE { 1107 -- type [0] IMPLICIT SECURITY-CATEGORY, 1108 -- value [1] ANY DEFINED BY type 1109 -- } 1110 -- 1111 -- SECURITY-CATEGORY MACRO ::= 1112 -- BEGIN 1113 -- TYPE NOTATION ::= type | empty 1114 -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 1115 -- END 1117 name { id-at-clearance } 1118 OID { joint-iso-ccitt(2) ds(5) module(1) 1119 selected-attribute-types(5) clearance (55) } 1120 syntax Clearance -- imported from [X.501-1997] 1121 values Multiple allowed 1123 4.5. Profile of AC issuer's PKC 1125 The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage 1126 extension in the PKC MUST NOT explicitly indicate that the AC 1127 issuer's public key cannot be used to validate a digital signature. 1128 In order to avoid confusion regarding serial numbers and revocations, 1129 an AC issuer MUST NOT also be a PKC Issuer. That is, an AC issuer 1130 cannot be a CA as well. So, the AC issuer's PKC MUST NOT have a 1131 basicConstraints extension with the cA BOOLEAN set to TRUE. 1133 5. Attribute Certificate Validation 1135 This section describes a basic set of rules that all valid ACs MUST 1136 satisfy. Some additional checks are also described which AC 1137 verifiers MAY choose to implement. 1139 To be valid an AC MUST satisfy all of the following: 1141 1. Where the holder uses a PKC to authenticate to the AC verifier, 1142 the AC holder's PKC MUST be found, and the entire certification 1143 path of that PKC MUST be verified in accordance with [PKIXPROF]. 1144 As noted in the security considerations section, if some other 1145 authentication scheme is used, AC verifiers need to be very 1146 careful mapping the identities (authenticated identity, holder 1147 field) involved. 1149 2. The AC signature must be cryptographically correct, and the AC 1150 issuer's entire PKC certification path MUST be verified in 1151 accordance with [PKIXPROF]. 1153 3. The AC issuer's PKC MUST also conform to the profile specified in 1154 section 4.5 above. 1156 4. The AC issuer MUST be directly trusted as an AC issuer (by 1157 configuration or otherwise). 1159 5. The time for which the AC is being evaluated MUST be within the AC 1160 validity. If the evaluation time is equal to either notBeforeTime 1161 or notAfterTime, then the AC is timely and this check succeeds. 1162 Note that in some applications, the evaluation time MAY not be the 1163 same as the current time. 1165 6. The AC targeting check MUST pass as specified in section 4.3.2. 1167 7. If the AC contains an unsupported critical extension, the AC MUST 1168 be rejected. 1170 Support for an extension in this context means: 1172 1. The AC verifier MUST be able to parse the extension value. 1174 2. Where the extension value SHOULD cause the AC to be rejected, the 1175 AC verifier MUST reject the AC. 1177 Additional Checks: 1179 1. The AC MAY be rejected on the basis of further AC verifier 1180 configuration. For example, an AC verifier may be configured to 1181 reject ACs which contain or lack certain attributes. 1183 2. If the AC verifier provides an interface that allows applications 1184 to query the contents of the AC, then the AC verifier MAY filter 1185 the attributes from the AC on the basis of configured information. 1186 For example, an AC verifier might be configured not to return 1187 certain attributes to certain servers. 1189 6. Revocation 1191 In many environments, the validity period of an AC is less than the 1192 time required to issue and distribute revocation information. 1193 Therefore, short-lived ACs typically do not require revocation 1194 support. However, long-lived ACs and environments where ACs enable 1195 high value transactions MAY require revocation support. 1197 Two revocation schemes are defined, and the AC issuer should elect 1198 the one that is best suited to the environment in which the AC will 1199 be employed. 1201 "Never revoke" scheme: 1203 ACs may be marked so that the relying party understands that no 1204 revocation status information will be made available. The 1205 noRevAvail extension is defined in section 4.3.6, and the 1206 noRevAvail extension MUST be present in the AC to indicate use of 1207 this scheme. 1209 Where no noRevAvail is present, the AC issuer is implicitly stating 1210 that revocation status checks are supported, and some revocation 1211 method MUST be provided to allow AC verifiers to establish the 1212 revocation status of the AC. 1214 "Pointer in AC" scheme: 1216 ACs may "point" to sources of revocation status information, using 1217 either an authorityInfoAccess extension or a crlDistributionPoints 1218 extension within the AC. 1220 For AC users, the "never revoke" scheme MUST be supported, and the 1221 "pointer in AC" scheme SHOULD be supported. If only the "never 1222 revoke" scheme is supported, then all ACs that do not contain a 1223 noRevAvail extension, MUST be rejected. 1225 For AC issuers, the "never revoke" scheme MUST be supported. If all 1226 ACs that will ever be issued by that AC issuer, contains a noRevAvail 1227 extension, the "pointer in AC" scheme need not be supported. If any 1228 AC can be issued that does not contain the noRevAvail extension, the 1229 "pointer in AC" scheme MUST be supported. 1231 An AC MUST NOT contain both a noRevAvail and a "pointer in AC". 1233 An AC verifier MAY use any source for AC revocation status 1234 information. 1236 7. Optional Features 1238 This section specifies features that MAY be implemented. Conformance 1239 to this profile does NOT require support for these features; however, 1240 if these features are offered, they MUST be offered as described 1241 below. 1243 7.1. Attribute Encryption 1245 Where an AC will be carried in clear within an application protocol 1246 or where an AC contains some sensitive information like a legacy 1247 application username/password, then encryption of AC attributes MAY 1248 be needed. 1250 When a set of attributes are to be encrypted within an AC, the 1251 Cryptographic Message Syntax, EnvelopedData structure [CMS] is used 1252 to carry the ciphertext and associated per-recipient keying 1253 information. 1255 This type of attribute encryption is targeted. Before the AC is 1256 signed, the attributes are encrypted for a set of predetermined 1257 recipients. 1259 Within EnvelopedData, the encapsulatedContentInfo identifies the 1260 content type carried withing the ciphertext. In this case, the 1261 contentType field of encapsulatedContentInfo MUST contain id-ct- 1262 attrCertEncAttrs, which has the following value: 1264 attrCertEncAttrs OBJECT IDENTIFIER ::= { 1265 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1266 id-smime(16) id-ct(1) 14 } 1268 The ciphertext is included in the AC as the value of an encAttrs 1269 attribute. Only one encAttrs attribute can be present in an AC; 1270 however, the encAttrs attribute MAY be multi-valued, and each of its 1271 values will contain an independent EnvelopedData. 1273 Each value can contain a set of attributes (each possibly a multi- 1274 valued attribute) encrypted for a set of predetermined recipients. 1276 The cleartext that is encrypted has the type: 1278 ACClearAttrs ::= SEQUENCE { 1279 acIssuer GeneralName, 1280 acSerial INTEGER, 1281 attrs SEQUENCE OF Attribute 1282 } 1284 The DER encoding of the ACClearAttrs structure is used as the 1285 encryptedContent field of the EnvelopedData. The DER encoding MUST 1286 be embedded in an OCTET STRING. 1288 The acIssuer and acSerial fields are present to prevent ciphertext 1289 stealing. When an AC verifier has successfully decrypted an 1290 encrypted attribute, it MUST then check that the AC issuer and 1291 serialNumber fields contain the same values. This prevents a 1292 malicious AC issuer from copying ciphertext from another AC (without 1293 knowing its corresponding plaintext). 1295 The procedure for an AC issuer when encrypting attributes is 1296 illustrated by the following (any other procedure that gives the same 1297 result MAY be used): 1299 1. Identify the sets of attributes that are to be encrypted for 1300 each set of recipients. 1301 2. For each attribute set which is to be encrypted: 1302 2.1. Create an EnvelopedData structure for the data for this 1303 set of recipients. 1304 2.2. Encode the ContentInfo containing the EnvelopedData as a 1305 value of the encAttrs attribute. 1306 2.3. Ensure the cleartext attributes are not present in the 1307 to-be-signed AC. 1308 3. Add the encAttrs (with its multiple values) to the AC. 1310 Note that there may be more than one attribute of the same type (the 1311 same OBJECT IDENTIFIER) after decryption. That is, an AC MAY contain 1312 the same attribute type both in clear and in encrypted form (and 1313 indeed several times if the same recipient is associated with more 1314 than one EnvelopedData). One approach implementers may choose, would 1315 be to merge attribute values following decryption in order to re- 1316 establish the "once only" constraint. 1318 name id-aca-encAttrs 1319 OID { id-aca 6} 1320 Syntax ContentInfo 1321 values Multiple Allowed 1323 If an AC contains attributes apparently encrypted for the AC 1324 verifier, then the decryption process failure MUST cause the AC to be 1325 rejected. 1327 7.2. Proxying 1329 When a server acts as a client for another server on behalf of the AC 1330 holder, the server MAY need to proxy an AC. Such proxying MAY have 1331 to be done under the AC issuer's control, so that not every AC is 1332 proxiable and so that a given proxiable AC can be proxied in a 1333 targeted fashion. Support for chains of proxies (with more than one 1334 intermediate server) MAY also be required. Note that this does not 1335 involve a chain of ACs. 1337 In order to meet this requirement we define another extension, 1338 ProxyInfo, similar to the targeting extension. 1340 When this extension is present, the AC verifier must check that the 1341 entity from which the AC was received was allowed to send it and that 1342 the AC is allowed to be used by this verifier. 1344 The proxying information consists of a set of proxy information, each 1345 of which is a set of targeting information. If the verifier and the 1346 sender of the AC are both named in the same proxy set, the AC can 1347 then be accepted (the exact rule is given below). 1349 The effect is that the AC holder can send the AC to any valid target 1350 which can then only proxy to targets which are in one of the same 1351 proxy sets as itself. 1353 The following data structure is used to represent the 1354 targeting/proxying information. 1356 ProxyInfo ::= SEQUENCE OF Targets 1358 As in the case of targeting, the targetCert CHOICE MUST NOT be used. 1360 A proxy check succeeds if either one of the conditions below is met: 1362 1. The identity of the sender, as established by the underlying 1363 authentication service, matches the holder field of the AC, and 1364 the current server "matches" any one of the proxy sets. Recall 1365 that "matches" is as defined section 4.3.2. 1367 2. The identity of the sender, as established by the underlying 1368 authentication service, "matches" one of the proxy sets (call it 1369 set "A"), and the current server is one of the targetName fields 1370 in the set "A", or the current server is a member of one of the 1371 targetGroup fields in set "A". 1373 When an AC is proxied more than once, a number of targets will be on 1374 the path from the original client, which is normally, but not always, 1375 the AC holder. In such cases, prevention of AC "stealing" requires 1376 that the AC verifier MUST check that all targets on the path are 1377 members of the same proxy set. It is the responsibility of the AC- 1378 using protocol to ensure that a trustworthy list of targets on the 1379 path is available to the AC verifier. 1381 name id-pe-ac-proxying 1382 OID { id-pe 10 } 1383 syntax ProxyInfo 1384 criticality MUST be TRUE 1386 7.3. Use of ObjectDigestInfo 1388 In some environments, it may be required that the AC is not linked 1389 either to an identity (via entityName) or to a PKC (via 1390 baseCertificateID). The objectDigestInfo CHOICE in the holder field 1391 allows support for this requirement. 1393 If the holder is identified with the objectDigestInfo field, then the 1394 AC version field MUST contain v2 (the integer 1). 1396 The idea is to link the AC to an object by placing a hash of that 1397 object into the holder field of the AC. For example, this allows 1398 production of ACs that are linked to public keys rather than names. 1399 It also allows production of ACs which contain privileges associated 1400 with an executable object such as a Java class. However, this 1401 profile only specifies how to use a hash over a public key or PKC. 1402 That is, conformant ACs MUST NOT use the otherObjectTypes value for 1403 the digestedObjectType. 1405 To link an AC to a public key, the hash must be calculated over the 1406 representation of that public key which would be present in a PKC, 1407 specifically, the input for the hash algorithm MUST be the DER 1408 encoding of a SubjectPublicKeyInfo representation of the key. Note: 1409 This includes the AlgorithmIdentifier as well as the BIT STRING. The 1410 rules given in [PKIXPROF] for encoding keys MUST be followed. In 1411 this case, the digestedObjectType MUST be publicKey and the 1412 otherObjectTypeID field MUST NOT be present. 1414 Note that if the public key value used as input to the hash function 1415 has been extracted from a PKC, it is possible that the 1416 SubjectPublicKeyInfo from that PKC is NOT the value which should be 1417 hashed. This can occur if DSA Dss-parms are inherited as described 1418 in section 7.3.3 of [PKIXPROF]. The correct input for hashing in 1419 this context will include the value of the parameters inherited from 1420 the CA's PKC, and thus may differ from the SubjectPublicKeyInfo 1421 present in the PKC. 1423 Implementations which support this feature MUST be able to handle the 1424 representations of public keys for the algorithms specified in 1425 section 7.3 of [PKIXPROF]. In this case, the digestedObjectType MUST 1426 be publicKey and the otherObjectTypeID field MUST NOT be present. 1428 In order to link an AC to a PKC via a digest, the digest MUST be 1429 calculated over the DER encoding of the entire PKC, including the 1430 signature value. In this case the digestedObjectType MUST be 1431 publicKeyCert and the otherObjectTypeID field MUST NOT be present. 1433 7.4. AA Controls 1435 During AC validation a relying party has to answer the question: is 1436 this AC issuer trusted to issue ACs containing this attribute? The 1437 AAControls PKC extension MAY be used to help answer the question. The 1438 AAControls extension is intended to be used in CA and AC issuer PKCs. 1440 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1442 AAControls ::= SEQUENCE { 1443 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1444 permittedAttrs [0] AttrSpec OPTIONAL, 1445 excludedAttrs [1] AttrSpec OPTIONAL, 1446 permitUnSpecified BOOLEAN DEFAULT TRUE 1447 } 1449 AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER 1451 The AAControls extension is used as follows: 1453 The pathLenConstraint, if present, is interpreted as in [PKIXPROF]. 1454 It restricts the allowed distance between the AA CA (a CA directly 1455 trusted to include AAControls in its PKCs), and the AC issuer. 1457 The permittedAttrs field specifies a set of attribute types that any 1458 AC issuer below this AA CA is allowed to include in ACs. If this 1459 field is not present, it means that no attribute types are explicitly 1460 allowed. 1462 The excludedAttrs field specifies a set of attribute types that no AC 1463 issuer is allowed to include in ACs. If this field is not present, 1464 it means that no attribute types are explicitly disallowed. 1466 The permitUnSpecified field specifies how to handle attribute types 1467 which are not present in either the permittedAttrs or excludedAttrs 1468 fields. TRUE (the default) means that any unspecified attribute type 1469 is allowed in ACs; FALSE means that no unspecified attribute type is 1470 allowed. 1472 When AAControls are used, the following additional checks on an AA's 1473 PKC chain MUST all succeed for the AC to be valid: 1475 1. Some CA on the ACs certificate path MUST be directly trusted to 1476 issue PKCs which precede the AC issuer in the certification path; 1477 call this CA the "AA CA". 1479 2. All PKCs on the path from the AA CA, down to and including the AC 1480 issuer's PKC, MUST contain an AAControls extension; however, the 1481 AA CA's PKC need not contain this extension. 1483 3. Only those attributes in the AC which are allowed, according to 1484 all of the AAControls extension values in all of the PKCs from the 1485 AA CA to the AC issuer, may be used for authorization decisions; 1486 all other attributes MUST be ignored. This check MUST be applied 1487 to the set of attributes following attribute decryption, and the 1488 id-aca-encAttrs type MUST also be checked. 1490 name id-pe-aaControls 1491 OID { id-pe 6 } 1492 syntax AAControls 1493 criticality MAY be TRUE 1495 8. Security Considerations 1497 The protection afforded for private keys is a critical factor in 1498 maintaining security. Failure of AC issuers to protect their private 1499 keys will permit an attacker to masquerade as them, potentially 1500 generating false ACs or revocation status. Existence of bogus ACs 1501 and revocation status will undermine confidence in the system. If 1502 the compromise is detected, all ACs issued by the AC issuer MUST be 1503 revoked. Rebuilding after such a compromise will be problematic, so 1504 AC issuers are advised to implement a combination of strong technical 1505 measures (e.g., tamper-resistant cryptographic modules) and 1506 appropriate management procedures (e.g., separation of duties) to 1507 avoid such an incident. 1509 Loss of an AC issuer's private signing key may also be problematic. 1510 The AC issuer would not be able to produce revocation status or 1511 perform AC renewal. AC issuers are advised to maintain secure backup 1512 for signing keys. The security of the key backup procedures is a 1513 critical factor in avoiding key compromise. 1515 The availability and freshness of revocation status will affect the 1516 degree of assurance that should be placed in a long-lived AC. While 1517 long-lived ACs expire naturally, events may occur during its natural 1518 lifetime which negate the binding between the AC holder and the 1519 attributes. If revocation status is untimely or unavailable, the 1520 assurance associated with the binding is clearly reduced. 1522 The binding between an AC holder and attributes cannot be stronger 1523 than the cryptographic module implementation and algorithms used to 1524 generate the signature. Short key lengths or weak hash algorithms 1525 will limit the utility of an AC. AC issuers are encouraged to note 1526 advances in cryptology so they can employ strong cryptographic 1527 techniques. 1529 Inconsistent application of name comparison rules may result in 1530 acceptance of invalid targeted or proxied ACs, or rejection of valid 1531 ones. The X.500 series of specifications defines rules for comparing 1532 distinguished names. These rules require comparison of strings 1533 without regard to case, character set, multi-character white space 1534 substrings, or leading and trailing white space. This specification 1535 and [PKIXPROF] relaxes these requirements, requiring support for 1536 binary comparison at a minimum. 1538 AC issuers MUST encode the distinguished name in the AC 1539 holder.entityName field identically to the distinguished name in the 1540 holder's PKC. If different encodings are used, implementations of 1541 this specification may fail to recognize that the AC and PKC belong 1542 to the same entity. 1544 If an attribute certificate is tied to the holder's PKC using the 1545 baseCertificateID component of the Holder field and the PKI in use 1546 includes a rogue CA with the same issuer name specified in the 1547 baseCertificateID component, this rogue CA could issue a PKC to a 1548 malicious party, using the same issuer name and serial number as the 1549 proper holder's PKC. Then the malicious party could use this PKC in 1550 conjunction with the AC. This scenario SHOULD be avoided by properly 1551 managing and configuring the PKI so that there cannot be two CAs with 1552 the same name. Another alternative is to tie ACs to PKCs using the 1553 publicKeyCert type in the ObjectDigestInfo field. Failing this, AC 1554 verifiers have to establish (using other means) that the potential 1555 collisions cannot actually occur, for example, the CPSs of the CAs 1556 involved may make it clear that no such name collisions can occur. 1558 Implementers MUST ensure that following validation of an AC, only 1559 attributes that the issuer is trusted to issue are used in 1560 authorization decisions. Other attributes, which MAY be present MUST 1561 be ignored. Given that the AA controls PKC extension is optional to 1562 implement, AC verifiers MUST be provided with this information by 1563 other means. Configuration information is a likely alternative 1564 means. This becomes very important if an AC verifier trusts more 1565 than one AC issuer. 1567 There is often a requirement to map between the authentication 1568 supplied by a particular security protocol (e.g. TLS, S/MIME) and the 1569 AC holder's identity. If the authentication uses PKCs, then this 1570 mapping is straightforward. However, it is envisaged that ACs will 1571 also be used in environments where the holder may be authenticated 1572 using other means. Implementers SHOULD be very careful in mapping 1573 the authenticated identity to the AC holder. 1575 9. IANA Considerations 1577 Attributes and attribute certificate extensions are identified by 1578 object identifiers (OIDs). Many of the OIDs used in this document 1579 are copied from X.509 [X.509-2000]. Other OIDs were assigned from an 1580 arc delegated by the IANA. No further action by the IANA is 1581 necessary for this document or any anticipated updates. 1583 10. References 1585 10.1. Normative References 1587 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 3852, July 1588 2004. 1590 [HTTP-URL] Housley, R., and P. Hoffman, "Internet X.509 Public Key 1591 Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, ay 1592 1999. 1594 [LDAP-URL] Smith, E., and T. Howes, "Lightweight Directory Acces 1595 Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006. 1597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1598 Requirement Levels", BCP 14, RFC 2119, March 1997. 1600 [RFC3281] Farrell, S., and R. Housley, "An Internet Attribute 1601 Certificate Profile for Authorization", RFC 3281, April 2002. 1603 [RFC3281-ERR] http://www.rfc-editor.org/errata_search.php?eid=302 1605 [PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and 1606 Identifiers for the Internet X.509 Public Key Infrastructure 1607 Certificate and Certificate Revocation Lists CRL Profile", RFC 3279, 1608 April 2002. 1610 [PKIXPROF] Cooper, D., Santesson, S., Farrell, S., Boeyen, S. 1611 Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure 1612 Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, 1613 May 2008. 1615 10.2. Informative References 1617 [KRB] Yu, T., Hartman, S., Raeburn, K., and C. Neuman, "The Kerberos 1618 Network Authentication Service (V5)", RFC 4120, July 2005. 1620 [LDAP] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): 1621 Directory Information Models", RFC 4510, June 2006. 1623 [OCSP] Myers, M., Ankney, R., Malpani A., Galperin, S., and C. 1624 Adams, "X.509 Internet Public Key Infrastructure Online Certificate 1625 Status Protocol - OCSP", RFC 2560, June 1999. 1627 [X.208-1988] CCITT Recommendation X.208: Specification of Abstract 1628 Syntax Notation One (ASN.1). 1988. 1630 [X.509-1988] CCITT Recommendation X.509: The Directory - 1631 Authentication Framework. 1988. 1633 [X.509-1997] ITU-T Recommendation X.509: The Directory - 1634 Authentication Framework. 1997. 1636 [X.509-2000] ITU-T Recommendation X.509: The Directory - Public-Key 1637 and Attribute Certificate Frameworks. 2000 1639 Appendix A Object Identifiers 1641 This (normative) appendix lists the new object identifiers which are 1642 defined in this specification. Some of these are required only for 1643 support of optional features and are not required for conformance to 1644 this profile. This specification mandates support for OIDs which 1645 have arc elements with values that are less than 2^32, (i.e. they 1646 MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less 1647 than 2^31 (i.e. less than or equal to 2,147,483,647). This allows 1648 each arc element to be represented within a single 32 bit word. 1649 Implementations MUST also support OIDs where the length of the dotted 1650 decimal (see [LDAP], section 4.1.2) string representation can be up 1651 to 100 bytes (inclusive). Implementations MUST be able to handle 1652 OIDs with up to 20 elements (inclusive). AA's SHOULD NOT issue ACs 1653 which contain OIDs that breach these requirements. 1655 The following OIDs are imported from [PKIXPROF]: 1657 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1658 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 1659 id-mod OBJECT IDENTIFIER ::= { id-pkix 0 } 1660 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 1661 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 1662 id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } 1663 id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 } 1665 The following new ASN.1 module OID is defined: 1667 id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 } 1669 The following AC extension OIDs are defined: 1671 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1672 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 } 1673 id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 1675 The following PKC extension OIDs are defined: 1677 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1679 The following attribute OIDs are defined: 1681 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1682 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1683 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1684 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1685 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1686 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1687 id-at-role OBJECT IDENTIFIER ::= { id-at 72 } 1688 id-at-clearance OBJECT IDENTIFIER ::= { 1689 joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) } 1690 id-at-clearance OBJECT IDENTIFIER ::= { 1691 joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5) 1692 clearance (55) } 1694 As noted in Section 4.2.6, there are two OIDs for id-at-clearance. 1696 Appendix B ASN.1 Module 1698 NOTE: The value for TBA will be included during AUTH48. 1700 //** RFC Editor: Remove this note prior to publication **// 1702 PKIXAttributeCertificate-2008 { iso(1) identified-organization(3) 1703 dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1704 id-mod-attribute-cert2(TBA) } 1706 DEFINITIONS IMPLICIT TAGS ::= 1708 BEGIN 1710 -- EXPORTS ALL -- 1712 IMPORTS 1714 -- IMPORTed module OIDs MAY change if [PKIXPROF] changes 1715 -- PKIX Certificate Extensions 1717 Attribute, AlgorithmIdentifier, CertificateSerialNumber, 1718 Extensions, UniqueIdentifier, id-pkix, id-pe, id-kp, id-ad, id-at 1719 FROM PKIX1Explicit88 1720 { iso(1) identified-organization(3) dod(6) internet(1) 1721 security(5) mechanisms(5) pkix(7) id-mod(0) 1722 id-pkix1-explicit-88(18) } 1724 GeneralName, GeneralNames, id-ce, AuthorityKeyIdentifier, 1725 AuthorityInfoAccessSyntax, CRLDistributionPoint 1726 FROM PKIX1Implicit88 1727 { iso(1) identified-organization(3) dod(6) internet(1) 1728 security(5) mechanisms(5) pkix(7) id-mod(0) 1729 id-pkix1-implicit-88(19) } 1731 ContentInfo 1732 FROM CryptographicMessageSyntax2004 1733 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1734 smime(16) modules(0) cms-2004(24) } 1736 ; 1738 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1740 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1742 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 } 1743 id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 1745 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1747 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1749 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1751 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1753 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1755 -- { id-aca 5 } is reserved 1757 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1759 id-at-role OBJECT IDENTIFIER ::= { id-at 72} 1761 id-at-clearance OBJECT IDENTIFIER ::= { 1762 joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) } 1764 -- Uncomment the following line and comment the above line if using 1765 -- the id-at-clearance attribe as defined in [RFC3281] 1767 -- id-at-clearance OBJECT IDENTIFIER ::= { 1768 -- joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5) 1769 -- clearance (55) } 1771 -- Uncomment this if using a 1988 level ASN.1 compiler 1773 -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 1775 AttributeCertificate ::= SEQUENCE { 1776 acinfo AttributeCertificateInfo, 1777 signatureAlgorithm AlgorithmIdentifier, 1778 signatureValue BIT STRING 1779 } 1780 AttributeCertificateInfo ::= SEQUENCE { 1781 version AttCertVersion, -- version is v2 1782 holder Holder, 1783 issuer AttCertIssuer, 1784 signature AlgorithmIdentifier, 1785 serialNumber CertificateSerialNumber, 1786 attrCertValidityPeriod AttCertValidityPeriod, 1787 attributes SEQUENCE OF Attribute, 1788 issuerUniqueID UniqueIdentifier OPTIONAL, 1789 extensions Extensions OPTIONAL 1790 } 1792 AttCertVersion ::= INTEGER { v2(1) } 1794 Holder ::= SEQUENCE { 1795 baseCertificateID [0] IssuerSerial OPTIONAL, 1796 -- the issuer and serial number of 1797 -- the holder's Public Key Certificate 1798 entityName [1] GeneralNames OPTIONAL, 1799 -- the name of the claimant or role 1800 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 1801 -- used to directly authenticate the 1802 -- holder, for example, an executable 1803 } 1805 ObjectDigestInfo ::= SEQUENCE { 1806 digestedObjectType ENUMERATED { 1807 publicKey (0), 1808 publicKeyCert (1), 1809 otherObjectTypes (2) }, 1810 -- otherObjectTypes MUST NOT 1811 -- MUST NOT be used in this profile 1812 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 1813 digestAlgorithm AlgorithmIdentifier, 1814 objectDigest BIT STRING 1815 } 1817 AttCertIssuer ::= CHOICE { 1818 v1Form GeneralNames, -- MUST NOT be used in this 1819 -- profile 1820 v2Form [0] V2Form -- v2 only 1821 } 1822 V2Form ::= SEQUENCE { 1823 issuerName GeneralNames OPTIONAL, 1824 baseCertificateID [0] IssuerSerial OPTIONAL, 1825 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 1826 -- issuerName MUST be present in this profile 1827 -- baseCertificateID and objectDigestInfo MUST 1828 -- NOT be present in this profile 1829 } 1831 IssuerSerial ::= SEQUENCE { 1832 issuer GeneralNames, 1833 serial CertificateSerialNumber, 1834 issuerUID UniqueIdentifier OPTIONAL 1835 } 1837 AttCertValidityPeriod ::= SEQUENCE { 1838 notBeforeTime GeneralizedTime, 1839 notAfterTime GeneralizedTime 1840 } 1842 Targets ::= SEQUENCE OF Target 1844 Target ::= CHOICE { 1845 targetName [0] GeneralName, 1846 targetGroup [1] GeneralName, 1847 targetCert [2] TargetCert 1848 } 1850 TargetCert ::= SEQUENCE { 1851 targetCertificate IssuerSerial, 1852 targetName GeneralName OPTIONAL, 1853 certDigestInfo ObjectDigestInfo OPTIONAL 1854 } 1856 IetfAttrSyntax ::= SEQUENCE { 1857 policyAuthority [0] GeneralNames OPTIONAL, 1858 values SEQUENCE OF CHOICE { 1859 octets OCTET STRING, 1860 oid OBJECT IDENTIFIER, 1861 string UTF8String 1862 } 1863 } 1864 SvceAuthInfo ::= SEQUENCE { 1865 service GeneralName, 1866 ident GeneralName, 1867 authInfo OCTET STRING OPTIONAL 1868 } 1870 RoleSyntax ::= SEQUENCE { 1871 roleAuthority [0] GeneralNames OPTIONAL, 1872 roleName [1] GeneralName 1873 } 1875 Clearance ::= SEQUENCE { 1876 policyId OBJECT IDENTIFIER, 1877 classList ClassList DEFAULT {unclassified}, 1878 securityCategories SET OF SecurityCategory OPTIONAL 1879 } 1881 -- Uncomment the following lines to support deprecated clearance 1882 -- syntax and comment out previous Clearance. 1884 -- Clearance ::= SEQUENCE { 1885 -- policyId [0] OBJECT IDENTIFIER, 1886 -- classList [1] ClassList DEFAULT {unclassified}, 1887 -- securityCategories [2] SET OF SecurityCategory OPTIONAL 1888 -- } 1890 ClassList ::= BIT STRING { 1891 unmarked (0), 1892 unclassified (1), 1893 restricted (2), 1894 confidential (3), 1895 secret (4), 1896 topSecret (5) 1897 } 1899 SecurityCategory ::= SEQUENCE { 1900 type [0] OBJECT IDENTIFIER, 1901 value [1] EXPLICIT ANY DEFINED BY type 1902 } 1903 -- Note that in [RFC3281] the syntax for SecurityCategory was 1904 -- as follows: 1905 -- 1906 -- SecurityCategory ::= SEQUENCE { 1907 -- type [0] OBJECT IDENTIFIER, 1908 -- value [1] EXPLICIT ANY DEFINED BY type 1909 -- } 1910 -- 1911 -- The removal of the IMPLICIT from the type line and the 1912 -- addition of the EXPLICIT to the value line result in 1913 -- no changes to the encoding. 1915 AAControls ::= SEQUENCE { 1916 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1917 permittedAttrs [0] AttrSpec OPTIONAL, 1918 excludedAttrs [1] AttrSpec OPTIONAL, 1919 permitUnSpecified BOOLEAN DEFAULT TRUE 1920 } 1922 AttrSpec ::= SEQUENCE OF OBJECT IDENTIFIER 1924 ACClearAttrs ::= SEQUENCE { 1925 acIssuer GeneralName, 1926 acSerial INTEGER, 1927 attrs SEQUENCE OF Attribute 1928 } 1930 ProxyInfo ::= SEQUENCE OF Targets 1932 END 1934 Appendix C Changes Since RFC 3281 1936 1. Created a new Section 1.1 "Terminology", renumbered Section 1.1- 1937 1.3 to 1.2-1.4, and moved first paragraph of Section 1 to Section 1938 1.1. 1940 2. In Section 2, replace S/MIME v3 with S/MIME v3.2. 1942 3. In Section 4.1, moved "," from the right of the ASN.1 comment to 1943 the left of the ASN.1 comment on the line describing version in the 1944 AttributerCertificateInfo structure. 1946 4. In Section 4.2, replaced pointer to 4.2.1.7 of RFC 3280 with 1947 pointer to 4.2.1.6 of RFC 5280. 1949 5. In Section 4.3.2, replaced "Confirming" with "Conforming". 1951 6. In Section 4.3.4, replaced reference to RFC 1738, URL, with 1952 references to [HTTP-URL]. 1954 7. In Section 4.3.5, replaced "HTTP or an LDAP" with "HTTP [HTTP-URL] 1955 or an LDAP [LDAP-URL]." Also replaced "CRLDistPointsSyntax" with 1956 "CRLDistributionPoints". 1958 8. In Section 4.4.6, added text to address having two OIDs for the 1959 same syntax and two syntaxes for one OID. 1961 9. In Section 7.1, replaced text that described encapsulating 1962 encrypted attribute with corrected text. Reworded last paragraph to 1963 more clearly describe the failure case. 1965 10. Updated References: 1966 a) split references in to informative/normative references 1967 b) added reference to RFC 3281 1968 c) replaced reference to X.501:1993 with X.501:1997 1969 d) replaced reference to RFC 1510 with RFC 4120 1970 e) replaced reference to RFC 1738 with RFC 4516 and 2585 1971 f) replaced reference to RFC 2251 with RFC 4510 1972 g) replaced reference to RFC 2459 with RFC 5280 1973 h) replaced reference to RFC 2510 with RFC 4210 1974 i) replaced reference to RFC 2630 with RFC 3852 1975 j) replaced reference to RFC 2797 with RFC 5272 1976 k) deleted spurious reference to CMC, CMP, ESS, RFC 2026, 1977 X.209-88, and X.501:1988. 1979 11. In Appendix A, added 2nd clearance attribute object identifier. 1981 12. Appendix B, updated ASN.1 with changes 3, 8, 9, and 11: 1982 a) New OID for ASN.1 module. 1983 b) Updated module OIDs for PKIX1Implicit88 and PKIX1Implicit88. 1984 c) Added imports from PKIX1Implicit88 for AuthorityKeyIdentifier, 1985 AuthorityInfoAccessSyntax, CRLDistributionPoint 1986 d) Added imports from CryptographicMessageSyntax2004 for 1987 ContentInfo. 1988 e) Added comments and commented out ASN.1 for old clearance 1989 attribute syntax. 1991 Author's Addresses 1993 Sean Turner 1995 IECA, Inc. 1996 3057 Nutley Street, Suite 106 1997 Fairfax, VA 22031 1998 USA 2000 Email: turners@ieca.com 2002 Russ Housley 2004 Vigil Security, LLC 2005 918 Spring Knoll Drive 2006 Herndon, VA 20170 2007 USA 2009 EMail: housley@vigilsec.com 2011 Stephen Farrell 2013 Distributed Systems Group 2014 Computer Science Department 2015 Trinity College Dublin 2016 Ireland 2018 Email: stephen.farrell@cs.tcd.ie