1 2 3 4 5 6 7Network Working Group S. Farrell 8Request for Comments: 3281 Baltimore Technologies 9Category: Standards Track R. Housley 10 RSA Laboratories 11 April 2002 12 13 14 An Internet Attribute Certificate 15 Profile for Authorization 16 17Status of this Memo 18 19 This document specifies an Internet standards track protocol for the 20 Internet community, and requests discussion and suggestions for 21 improvements. Please refer to the current edition of the "Internet 22 Official Protocol Standards" (STD 1) for the standardization state 23 and status of this protocol. Distribution of this memo is unlimited. 24 25Copyright Notice 26 27 Copyright (C) The Internet Society (2002). All Rights Reserved. 28 29Abstract 30 31 This specification defines a profile for the use of X.509 Attribute 32 Certificates in Internet Protocols. Attribute certificates may be 33 used in a wide range of applications and environments covering a 34 broad spectrum of interoperability goals and a broader spectrum of 35 operational and assurance requirements. The goal of this document is 36 to establish a common baseline for generic applications requiring 37 broad interoperability as well as limited special purpose 38 requirements. The profile places emphasis on attribute certificate 39 support for Internet electronic mail, IPSec, and WWW security 40 applications. 41 42Table of Contents 43 44 1. Introduction................................................. 2 45 1.1 Delegation and AC chains............................... 4 46 1.2 Attribute Certificate Distribution ("push" vs. "pull"). 4 47 1.3 Document Structure..................................... 6 48 2. Terminology.................................................. 6 49 3. Requirements................................................. 7 50 4. Attribute Certificate Profile................................ 7 51 4.1 X.509 Attribute Certificate Definition................. 8 52 4.2 Profile of Standard Fields............................. 10 53 4.2.1 Version.......................................... 10 54 4.2.2 Holder........................................... 11 55 56 57 58Farrell & Housley Standards Track [Page 1] 59 60RFC 3281 An Internet Attribute Certificate April 2002 61 62 63 4.2.3 Issuer........................................... 12 64 4.2.4 Signature........................................ 12 65 4.2.5 Serial Number.................................... 12 66 4.2.6 Validity Period.................................. 13 67 4.2.7 Attributes....................................... 13 68 4.2.8 Issuer Unique Identifier......................... 14 69 4.2.9 Extensions....................................... 14 70 4.3 Extensions............................................. 14 71 4.3.1 Audit Identity................................... 14 72 4.3.2 AC Targeting..................................... 15 73 4.3.3 Authority Key Identifier......................... 17 74 4.3.4 Authority Information Access..................... 17 75 4.3.5 CRL Distribution Points.......................... 17 76 4.3.6 No Revocation Available.......................... 18 77 4.4 Attribute Types........................................ 18 78 4.4.1 Service Authentication Information............... 19 79 4.4.2 Access Identity.................................. 19 80 4.4.3 Charging Identity................................ 20 81 4.4.4 Group............................................ 20 82 4.4.5 Role............................................. 20 83 4.4.6 Clearance........................................ 21 84 4.5 Profile of AC issuer's PKC............................. 22 85 5. Attribute Certificate Validation............................. 23 86 6. Revocation................................................... 24 87 7. Optional Features............................................ 25 88 7.1 Attribute Encryption................................... 25 89 7.2 Proxying............................................... 27 90 7.3 Use of ObjectDigestInfo................................ 28 91 7.4 AA Controls............................................ 29 92 8. Security Considerations...................................... 30 93 9. IANA Considerations.......................................... 32 94 10. References.................................................. 32 95 Appendix A: Object Identifiers.................................. 34 96 Appendix B: ASN.1 Module........................................ 35 97 Author's Addresses.............................................. 39 98 Acknowledgements................................................ 39 99 Full Copyright Statement........................................ 40 100 1011. Introduction 102 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in BCP 14, RFC 2119. 106 107 X.509 public key certificates (PKCs) [X.509-1997, X.509-2000, 108 PKIXPROF] bind an identity and a public key. An attribute 109 certificate (AC) is a structure similar to a PKC; the main difference 110 being that the AC contains no public key. An AC may contain 111 112 113 114Farrell & Housley Standards Track [Page 2] 115 116RFC 3281 An Internet Attribute Certificate April 2002 117 118 119 attributes that specify group membership, role, security clearance, 120 or other authorization information associated with the AC holder. 121 The syntax for the AC is defined in Recommendation X.509, making the 122 term "X.509 certificate" ambiguous. 123 124 Some people constantly confuse PKCs and ACs. An analogy may make the 125 distinction clear. A PKC can be considered to be like a passport: it 126 identifies the holder, tends to last for a long time, and should not 127 be trivial to obtain. An AC is more like an entry visa: it is 128 typically issued by a different authority and does not last for as 129 long a time. As acquiring an entry visa typically requires 130 presenting a passport, getting a visa can be a simpler process. 131 132 Authorization information may be placed in a PKC extension or placed 133 in a separate attribute certificate (AC). The placement of 134 authorization information in PKCs is usually undesirable for two 135 reasons. First, authorization information often does not have the 136 same lifetime as the binding of the identity and the public key. 137 When authorization information is placed in a PKC extension, the 138 general result is the shortening of the PKC useful lifetime. Second, 139 the PKC issuer is not usually authoritative for the authorization 140 information. This results in additional steps for the PKC issuer to 141 obtain authorization information from the authoritative source. 142 143 For these reasons, it is often better to separate authorization 144 information from the PKC. Yet, authorization information also needs 145 to be bound to an identity. An AC provides this binding; it is 146 simply a digitally signed (or certified) identity and set of 147 attributes. 148 149 An AC may be used with various security services, including access 150 control, data origin authentication, and non-repudiation. 151 152 PKCs can provide an identity to access control decision functions. 153 However, in many contexts the identity is not the criterion that is 154 used for access control decisions, rather the role or group- 155 membership of the accessor is the criterion used. Such access 156 control schemes are called role-based access control. 157 158 When making an access control decision based on an AC, an access 159 control decision function may need to ensure that the appropriate AC 160 holder is the entity that has requested access. One way in which the 161 linkage between the request or identity and the AC can be achieved is 162 the inclusion of a reference to a PKC within the AC and the use of 163 the private key corresponding to the PKC for authentication within 164 the access request. 165 166 167 168 169 170Farrell & Housley Standards Track [Page 3] 171 172RFC 3281 An Internet Attribute Certificate April 2002 173 174 175 ACs may also be used in the context of a data origin authentication 176 service and a non-repudiation service. In these contexts, the 177 attributes contained in the AC provide additional information about 178 the signing entity. This information can be used to make sure that 179 the entity is authorized to sign the data. This kind of checking 180 depends either on the context in which the data is exchanged or on 181 the data that has been digitally signed. 182 1831.1 Delegation and AC chains 184 185 The X.509 standard [X.509-2000] defines authorization as the 186 "conveyance of privilege from one entity that holds such privilege, 187 to another entity". An AC is one authorization mechanism. 188 189 An ordered sequence of ACs could be used to verify the authenticity 190 of a privilege asserter's privilege. In this way, chains or paths of 191 ACs could be employed to delegate authorization. 192 193 Since the administration and processing associated with such AC 194 chains is complex and the use of ACs in the Internet today is quite 195 limited, this specification does NOT RECOMMEND the use of AC chains. 196 Other (future) specifications may address the use of AC chains. This 197 specification deals with the simple cases, where one authority issues 198 all of the ACs for a particular set of attributes. However, this 199 simplification does not preclude the use of several different 200 authorities, each of which manages a different set of attributes. 201 For example, group membership may be included in one AC issued by one 202 authority, and security clearance may be included in another AC 203 issued by another authority. 204 205 This means that conformant implementations are only REQUIRED to be 206 able to process a single AC at a time. Processing of more than one 207 AC, one after another, may be necessary. Note however, that 208 validation of an AC MAY require validation of a chain of PKCs, as 209 specified in [PKIXPROF]. 210 2111.2 Attribute Certificate Distribution ("push" vs. "pull") 212 213 As discussed above, ACs provide a mechanism to securely provide 214 authorization information to, for example, access control decision 215 functions. However, there are a number of possible communication 216 paths for ACs. 217 218 In some environments, it is suitable for a client to "push" an AC to 219 a server. This means that no new connections between the client and 220 server are required. It also means that no search burden is imposed 221 on servers, which improves performance and that the AC verifier is 222 223 224 225 226Farrell & Housley Standards Track [Page 4] 227 228RFC 3281 An Internet Attribute Certificate April 2002 229 230 231 only presented with what it "needs to know." The "push" model is 232 especially suitable in inter-domain cases where the client's rights 233 should be assigned within the client's "home" domain. 234 235 In other cases, it is more suitable for a client to simply 236 authenticate to the server and for the server to request or "pull" 237 the client's AC from an AC issuer or a repository. A major benefit 238 of the "pull" model is that it can be implemented without changes to 239 the client or to the client-server protocol. The "pull" model is 240 especially suitable for inter-domain cases where the client's rights 241 should be assigned within the server's domain, rather than within the 242 client's domain. 243 244 There are a number of possible exchanges involving three entities: 245 the client, the server, and the AC issuer. In addition, a directory 246 service or other repository for AC retrieval MAY be supported. 247 248 Figure 1 shows an abstract view of the exchanges that may involve 249 ACs. This profile does not specify a protocol for these exchanges. 250 251 +--------------+ 252 | | Server Acquisition 253 | AC issuer +----------------------------+ 254 | | | 255 +--+-----------+ | 256 | | 257 | Client | 258 | Acquisition | 259 | | 260 +--+-----------+ +--+------------+ 261 | | AC "push" | | 262 | Client +-------------------------+ Server | 263 | | (part of app. protocol) | | 264 +--+-----------+ +--+------------+ 265 | | 266 | Client | Server 267 | Lookup +--------------+ | Lookup 268 | | | | 269 +---------------+ Repository +---------+ 270 | | 271 +--------------+ 272 273 Figure 1: AC Exchanges 274 275 276 277 278 279 280 281 282Farrell & Housley Standards Track [Page 5] 283 284RFC 3281 An Internet Attribute Certificate April 2002 285 286 2871.3 Document Structure 288 289 Section 2 defines some terminology. Section 3 specifies the 290 requirements that this profile is intended to meet. Section 4 291 contains the profile of the X.509 AC. Section 5 specifies rules for 292 AC validation. Section 6 specifies rules for AC revocation checks. 293 Section 7 specifies optional features which MAY be supported; 294 however, support for these features is not required for conformance 295 to this profile. Finally, appendices contain the list of OIDs 296 required to support this specification and an ASN.1 module. 297 2982. Terminology 299 300 For simplicity, we use the terms client and server in this 301 specification. This is not intended to indicate that ACs are only to 302 be used in client-server environments. For example, ACs may be used 303 in the S/MIME v3 context, where the mail user agent would be both a 304 "client" and a "server" in the sense the terms are used here. 305 306 Term Meaning 307 308 AA Attribute Authority, the entity that issues the 309 AC, synonymous in this specification with "AC 310 issuer" 311 AC Attribute Certificate 312 AC user any entity that parses or processes an AC 313 AC verifier any entity that checks the validity of an AC and 314 then makes use of the result 315 AC issuer the entity which signs the AC, synonymous in this 316 specification with "AA" 317 AC holder the entity indicated (perhaps indirectly) in the 318 holder field of the AC 319 Client the entity which is requesting the action for 320 which authorization checks are to be made 321 Proxying In this specification, Proxying is used to mean 322 the situation where an application server acts as 323 an application client on behalf of a user. 324 Proxying here does not mean granting of authority. 325 PKC Public Key Certificate - uses the type ASN.1 326 Certificate defined in X.509 and profiled in RFC 327 2459. This (non-standard) acronym is used in order 328 to avoid confusion about the term "X.509 329 certificate". 330 Server the entity which requires that the authorization 331 checks are made 332 333 334 335 336 337 338Farrell & Housley Standards Track [Page 6] 339 340RFC 3281 An Internet Attribute Certificate April 2002 341 342 3433. Requirements 344 345 This AC profile meets the following requirements. 346 347 Time/Validity requirements: 348 349 1. Support for short-lived as well as long-lived ACs. Typical 350 short-lived validity periods might be measured in hours, as 351 opposed to months for PKCs. Short validity periods allow ACs to 352 be useful without a revocation mechanism. 353 354 Attribute Types: 355 356 2. Issuers of ACs should be able to define their own attribute types 357 for use within closed domains. 358 359 3. Some standard attribute types, which can be contained within ACs, 360 should be defined. Examples include "access identity," "group," 361 "role," "clearance," "audit identity," and "charging identity." 362 363 4. Standard attribute types should be defined in a manner that 364 permits an AC verifier to distinguish between uses of the same 365 attribute in different domains. For example, the "Administrators 366 group" as defined by Baltimore and the "Administrators group" as 367 defined by SPYRUS should be easily distinguished. 368 369 Targeting of ACs: 370 371 5. It should be possible to "target" an AC at one, or a small number 372 of, servers. This means that a trustworthy non-target server will 373 reject the AC for authorization decisions. 374 375 Push vs. Pull 376 377 6. ACs should be defined so that they can either be "pushed" by the 378 client to the server, or "pulled" by the server from a repository 379 or other network service, including an online AC issuer. 380 3814. Attribute Certificate Profile 382 383 ACs may be used in a wide range of applications and environments 384 covering a broad spectrum of interoperability goals and a broader 385 spectrum of operational and assurance requirements. The goal of this 386 document is to establish a common baseline for generic applications 387 requiring broad interoperability and limited special purpose 388 389 390 391 392 393 394Farrell & Housley Standards Track [Page 7] 395 396RFC 3281 An Internet Attribute Certificate April 2002 397 398 399 requirements. In particular, the emphasis will be on supporting the 400 use of attribute certificates for informal Internet electronic mail, 401 IPSec, and WWW applications. 402 403 This section presents a profile for ACs that will foster 404 interoperability. This section also defines some private extensions 405 for the Internet community. 406 407 While the ISO/IEC/ITU documents use the 1993 (or later) version of 408 ASN.1, this document uses the 1988 ASN.1 syntax, as has been done for 409 PKCs [PKIXPROF]. The encoded certificates and extensions from either 410 ASN.1 version are bit-wise identical. 411 412 Where maximum lengths for fields are specified, these lengths refer 413 to the DER encoding and do not include the ASN.1 tag or length 414 fields. 415 416 Conforming implementations MUST support the profile specified in this 417 section. 418 4194.1 X.509 Attribute Certificate Definition 420 421 X.509 contains the definition of an AC given below. All types that 422 are not defined in this document can be found in [PKIXPROF]. 423 424 AttributeCertificate ::= SEQUENCE { 425 acinfo AttributeCertificateInfo, 426 signatureAlgorithm AlgorithmIdentifier, 427 signatureValue BIT STRING 428 } 429 430 AttributeCertificateInfo ::= SEQUENCE { 431 version AttCertVersion -- version is v2, 432 holder Holder, 433 issuer AttCertIssuer, 434 signature AlgorithmIdentifier, 435 serialNumber CertificateSerialNumber, 436 attrCertValidityPeriod AttCertValidityPeriod, 437 attributes SEQUENCE OF Attribute, 438 issuerUniqueID UniqueIdentifier OPTIONAL, 439 extensions Extensions OPTIONAL 440 } 441 442 AttCertVersion ::= INTEGER { v2(1) } 443 Holder ::= SEQUENCE { 444 baseCertificateID [0] IssuerSerial OPTIONAL, 445 -- the issuer and serial number of 446 -- the holder's Public Key Certificate 447 448 449 450Farrell & Housley Standards Track [Page 8] 451 452RFC 3281 An Internet Attribute Certificate April 2002 453 454 455 entityName [1] GeneralNames OPTIONAL, 456 -- the name of the claimant or role 457 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 458 -- used to directly authenticate the holder, 459 -- for example, an executable 460 } 461 462 ObjectDigestInfo ::= SEQUENCE { 463 digestedObjectType ENUMERATED { 464 publicKey (0), 465 publicKeyCert (1), 466 otherObjectTypes (2) }, 467 -- otherObjectTypes MUST NOT 468 -- be used in this profile 469 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 470 digestAlgorithm AlgorithmIdentifier, 471 objectDigest BIT STRING 472 } 473 474 AttCertIssuer ::= CHOICE { 475 v1Form GeneralNames, -- MUST NOT be used in this 476 -- profile 477 v2Form [0] V2Form -- v2 only 478 } 479 480 V2Form ::= SEQUENCE { 481 issuerName GeneralNames OPTIONAL, 482 baseCertificateID [0] IssuerSerial OPTIONAL, 483 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 484 -- issuerName MUST be present in this profile 485 -- baseCertificateID and objectDigestInfo MUST NOT 486 -- be present in this profile 487 } 488 489 IssuerSerial ::= SEQUENCE { 490 issuer GeneralNames, 491 serial CertificateSerialNumber, 492 issuerUID UniqueIdentifier OPTIONAL 493 } 494 495 AttCertValidityPeriod ::= SEQUENCE { 496 notBeforeTime GeneralizedTime, 497 notAfterTime GeneralizedTime 498 } 499 500 501 502 503 504 505 506Farrell & Housley Standards Track [Page 9] 507 508RFC 3281 An Internet Attribute Certificate April 2002 509 510 511 Although the Attribute syntax is defined in [PKIXPROF], we repeat 512 the definition here for convenience. 513 514 Attribute ::= SEQUENCE { 515 type AttributeType, 516 values SET OF AttributeValue 517 -- at least one value is required 518 } 519 520 AttributeType ::= OBJECT IDENTIFIER 521 522 AttributeValue ::= ANY DEFINED BY AttributeType 523 524 Implementers should note that the DER encoding (see [X.509- 525 1988],[X.208-1988]) of the SET OF values requires ordering of the 526 encodings of the values. Though this issue arises with respect to 527 distinguished names, and has to be handled by [PKIXPROF] 528 implementations, it is much more significant in this context, since 529 the inclusion of multiple values is much more common in ACs. 530 5314.2 Profile of Standard Fields 532 533 GeneralName offers great flexibility. To achieve interoperability, 534 in spite of this flexibility, this profile imposes constraints on the 535 use of GeneralName. 536 537 Conforming implementations MUST be able to support the dNSName, 538 directoryName, uniformResourceIdentifier, and iPAddress options. 539 This is compatible with the GeneralName requirements in [PKIXPROF] 540 (mainly in section 4.2.1.7). 541 542 Conforming implementations MUST NOT use the x400Address, 543 ediPartyName, or registeredID options. 544 545 Conforming implementations MAY use the otherName option to convey 546 name forms defined in Internet Standards. For example, Kerberos 547 [KRB] format names can be encoded into the otherName, using a 548 Kerberos 5 principal name OID and a SEQUENCE of the Realm and the 549 PrincipalName. 550 5514.2.1 Version 552 553 The version field MUST have the value of v2. That is, the version 554 field is present in the DER encoding. 555 556 557 558 559 560 561 562Farrell & Housley Standards Track [Page 10] 563 564RFC 3281 An Internet Attribute Certificate April 2002 565 566 567 Note: This version (v2) is not backwards compatible with the previous 568 attribute certificate definition (v1) from the 1997 X.509 standard 569 [X.509-1997], but is compatible with the v2 definition from X.509 570 (2000) [X.509-2000]. 571 5724.2.2 Holder 573 574 The Holder field is a SEQUENCE allowing three different (optional) 575 syntaxes: baseCertificateID, entityName and objectDigestInfo. Where 576 only one option is present, the meaning of the Holder field is clear. 577 However, where more than one option is used, there is a potential for 578 confusion as to which option is "normative", which is a "hint" etc. 579 Since the correct position is not clear from [X.509-2000], this 580 specification RECOMMENDS that only one of the options be used in any 581 given AC. 582 583 For any environment where the AC is passed in an authenticated 584 message or session and where the authentication is based on the use 585 of an X.509 PKC, the holder field SHOULD use the baseCertificateID. 586 587 With the baseCertificateID option, the holder's PKC serialNumber and 588 issuer MUST be identical to the AC holder field. The PKC issuer MUST 589 have a non-empty distinguished name which is to be present as the 590 single value of the holder.baseCertificateID.issuer construct in the 591 directoryName field. The AC holder.baseCertificateID.issuerUID field 592 MUST only be used if the holder's PKC contains an issuerUniqueID 593 field. If both the AC holder.baseCertificateID.issuerUID and the PKC 594 issuerUniqueID fields are present, the same value MUST be present in 595 both fields. Thus, the baseCertificateID is only usable with PKC 596 profiles (like [PKIXPROF]) which mandate that the PKC issuer field 597 contain a non-empty distinguished name value. 598 599 Note: An empty distinguished name is a distinguished name where the 600 SEQUENCE OF relative distinguished names is of zero length. In a DER 601 encoding, this has the value '3000'H. 602 603 If the holder field uses the entityName option and the underlying 604 authentication is based on a PKC, the entityName MUST be the same as 605 the PKC subject field or one of the values of the PKC subjectAltName 606 field extension (if present). Note that [PKIXPROF] mandates that the 607 subjectAltName extension be present if the PKC subject is an empty 608 distinguished name. See the security considerations section which 609 mentions some name collision problems that may arise when using the 610 entityName option. 611 612 In any other case where the holder field uses the entityName option, 613 only one name SHOULD be present. 614 615 616 617 618Farrell & Housley Standards Track [Page 11] 619 620RFC 3281 An Internet Attribute Certificate April 2002 621 622 623 Implementations conforming to this profile are not required to 624 support the use of the objectDigest field. However, section 7.3 625 specifies how this optional feature MAY be used. 626 627 Any protocol conforming to this profile SHOULD specify which AC 628 holder option is to be used and how this fits with the supported 629 authentication schemes defined in that protocol. 630 6314.2.3 Issuer 632 633 ACs conforming to this profile MUST use the v2Form choice, which MUST 634 contain one and only one GeneralName in the issuerName, which MUST 635 contain a non-empty distinguished name in the directoryName field. 636 This means that all AC issuers MUST have non-empty distinguished 637 names. ACs conforming to this profile MUST omit the 638 baseCertificateID and objectDigestInfo fields. 639 640 Part of the reason for the use of the v2Form containing only an 641 issuerName is that it means that the AC issuer does not have to know 642 which PKC the AC verifier will use for it (the AC issuer). Using the 643 baseCertificateID field to reference the AC issuer would mean that 644 the AC verifier would have to trust the PKC that the AC issuer chose 645 (for itself) at AC creation time. 646 6474.2.4 Signature 648 649 Contains the algorithm identifier used to validate the AC signature. 650 651 This MUST be one of the signing algorithms defined in [PKIXALGS]. 652 Conforming implementations MUST honor all MUST/SHOULD/MAY signing 653 algorithm statements specified in [PKIXALGS]. 654 6554.2.5 Serial Number 656 657 For any conforming AC, the issuer/serialNumber pair MUST form a 658 unique combination, even if ACs are very short-lived. 659 660 AC issuers MUST force the serialNumber to be a positive integer, that 661 is, the sign bit in the DER encoding of the INTEGER value MUST be 662 zero - this can be done by adding a leading (leftmost) '00'H octet if 663 necessary. This removes a potential ambiguity in mapping between a 664 string of octets and an integer value. 665 666 Given the uniqueness and timing requirements above, serial numbers 667 can be expected to contain long integers. AC users MUST be able to 668 handle serialNumber values longer than 4 octets. Conformant ACs MUST 669 NOT contain serialNumber values longer than 20 octets. 670 671 672 673 674Farrell & Housley Standards Track [Page 12] 675 676RFC 3281 An Internet Attribute Certificate April 2002 677 678 679 There is no requirement that the serial numbers used by any AC issuer 680 follow any particular ordering. In particular, they need not be 681 monotonically increasing with time. Each AC issuer MUST ensure that 682 each AC that it issues contains a unique serial number. 683 6844.2.6 Validity Period 685 686 The attrCertValidityPeriod (a.k.a. validity) field specifies the 687 period for which the AC issuer certifies that the binding between the 688 holder and the attributes fields will be valid. 689 690 The generalized time type, GeneralizedTime, is a standard ASN.1 type 691 for variable precision representation of time. The GeneralizedTime 692 field can optionally include a representation of the time 693 differential between the local time zone and Greenwich Mean Time. 694 695 For the purposes of this profile, GeneralizedTime values MUST be 696 expressed in Coordinated universal time (UTC) (also known as 697 Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times 698 are YYYYMMDDHHMMSSZ), even when the number of seconds is zero. 699 GeneralizedTime values MUST NOT include fractional seconds. 700 701 (Note: this is the same as specified in [PKIXPROF], section 702 4.1.2.5.2.) 703 704 AC users MUST be able to handle an AC which, at the time of 705 processing, has parts of its validity period or all its validity 706 period in the past or in the future (a post-dated AC). This is valid 707 for some applications, such as backup. 708 7094.2.7 Attributes 710 711 The attributes field gives information about the AC holder. When the 712 AC is used for authorization, this will often contain a set of 713 privileges. 714 715 The attributes field contains a SEQUENCE OF Attribute. Each 716 Attribute MAY contain a SET OF values. For a given AC, each 717 AttributeType OBJECT IDENTIFIER in the sequence MUST be unique. That 718 is, only one instance of each attribute can occur in a single AC, but 719 each instance can be multi-valued. 720 721 AC users MUST be able to handle multiple values for all attribute 722 types. 723 724 An AC MUST contain at least one attribute. That is, the SEQUENCE OF 725 Attributes MUST NOT be of zero length. 726 727 728 729 730Farrell & Housley Standards Track [Page 13] 731 732RFC 3281 An Internet Attribute Certificate April 2002 733 734 735 Some standard attribute types are defined in section 4.4. 736 7374.2.8 Issuer Unique Identifier 738 739 This field MUST NOT be used unless it is also used in the AC issuer's 740 PKC, in which case it MUST be used. Note that [PKIXPROF] states that 741 this field SHOULD NOT be used by conforming CAs, but that 742 applications SHOULD be able to parse PKCs containing the field. 743 7444.2.9 Extensions 745 746 The extensions field generally gives information about the AC as 747 opposed to information about the AC holder. 748 749 An AC that has no extensions conforms to the profile; however, 750 section 4.3 defines the extensions that MAY be used with this 751 profile, and whether or not they may be marked critical. If any 752 other critical extension is used, the AC does not conform to this 753 profile. However, if any other non-critical extension is used, the 754 AC does conform to this profile. 755 756 The extensions defined for ACs provide methods for associating 757 additional attributes with holders. This profile also allows 758 communities to define private extensions to carry information unique 759 to those communities. Each extension in an AC may be designated as 760 critical or non-critical. An AC using system MUST reject an AC if it 761 encounters a critical extension it does not recognize; however, a 762 non-critical extension may be ignored if it is not recognized. 763 Section 4.3 presents recommended extensions used within Internet ACs 764 and standard locations for information. Communities may elect to use 765 additional extensions; however, caution should be exercised in 766 adopting any critical extensions in ACs which might prevent use in a 767 general context. 768 7694.3 Extensions 770 7714.3.1 Audit Identity 772 773 In some circumstances, it is required (e.g. by data protection/data 774 privacy legislation) that audit trails not contain records which 775 directly identify individuals. This circumstance may make the use of 776 the AC holder field unsuitable for use in audit trails. 777 778 To allow for such cases, an AC MAY contain an audit identity 779 extension. Ideally it SHOULD be infeasible to derive the AC holder's 780 identity from the audit identity value without the cooperation of the 781 AC issuer. 782 783 784 785 786Farrell & Housley Standards Track [Page 14] 787 788RFC 3281 An Internet Attribute Certificate April 2002 789 790 791 The value of the audit identity, along with the AC issuer/serial, 792 SHOULD then be used for audit/logging purposes. If the value of the 793 audit identity is suitably chosen, a server/service administrator can 794 use audit trails to track the behavior of an AC holder without being 795 able to identify the AC holder. 796 797 The server/service administrator in combination with the AC issuer 798 MUST be able to identify the AC holder in cases where misbehavior is 799 detected. This means that the AC issuer MUST be able to determine 800 the actual identity of the AC holder from the audit identity. 801 802 Of course, auditing could be based on the AC issuer/serial pair; 803 however, this method does not allow tracking of the same AC holder 804 with multiple ACs. Thus, an audit identity is only useful if it 805 lasts for longer than the typical AC lifetime. Auditing could also 806 be based on the AC holder's PKC issuer/serial; however, this will 807 often allow the server/service administrator to identify the AC 808 holder. 809 810 As the AC verifier might otherwise use the AC holder or some other 811 identifying value for audit purposes, this extension MUST be critical 812 when used. 813 814 Protocols that use ACs will often expose the identity of the AC 815 holder in the bits on-the-wire. In such cases, an opaque audit 816 identity does not make use of the AC anonymous; it simply ensures 817 that the ensuing audit trails do not contain identifying information. 818 819 The value of an audit identity MUST be longer than zero octets. The 820 value of an audit identity MUST NOT be longer than 20 octets. 821 822 name id-pe-ac-auditIdentity 823 OID { id-pe 4 } 824 syntax OCTET STRING 825 criticality MUST be TRUE 826 8274.3.2 AC Targeting 828 829 To target an AC, the target information extension, imported from 830 [X.509-2000], MAY be used to specify a number of servers/services. 831 The intent is that the AC SHOULD only be usable at the specified 832 servers/services. An (honest) AC verifier who is not amongst the 833 named servers/services MUST reject the AC. 834 835 If this extension is not present, the AC is not targeted and may be 836 accepted by any server. 837 838 839 840 841 842Farrell & Housley Standards Track [Page 15] 843 844RFC 3281 An Internet Attribute Certificate April 2002 845 846 847 In this profile, the targeting information simply consists of a list 848 of named targets or groups. 849 850 The following syntax is used to represent the targeting information: 851 852 Targets ::= SEQUENCE OF Target 853 854 Target ::= CHOICE { 855 targetName [0] GeneralName, 856 targetGroup [1] GeneralName, 857 targetCert [2] TargetCert 858 } 859 860 TargetCert ::= SEQUENCE { 861 targetCertificate IssuerSerial, 862 targetName GeneralName OPTIONAL, 863 certDigestInfo ObjectDigestInfo OPTIONAL 864 } 865 866 The targetCert CHOICE within the Target structure is only present to 867 allow future compatibility with [X.509-2000] and MUST NOT be used. 868 869 The targets check passes if the current server (recipient) is one of 870 the targetName fields in the Targets SEQUENCE, or if the current 871 server is a member of one of the targetGroup fields in the Targets 872 SEQUENCE. In this case, the current server is said to "match" the 873 targeting extension. 874 875 How the membership of a target within a targetGroup is determined is 876 not defined here. It is assumed that any given target "knows" the 877 names of the targetGroups to which it belongs or can otherwise 878 determine its membership. For example, the targetGroup specifies a 879 DNS domain, and the AC verifier knows the DNS domain to which it 880 belongs. For another example, the targetGroup specifies "PRINTERS," 881 and the AC verifier knows whether or not it is a printer or print 882 server. 883 884 Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF 885 Targets". Conforming AC issuer implementations MUST only produce one 886 "Targets" element. Confirming AC users MUST be able to accept a 887 "SEQUENCE OF Targets". If more than one Targets element is found in 888 an AC, the extension MUST be treated as if all Target elements had 889 been found within one Targets element. 890 891 name id-ce-targetInformation 892 OID { id-ce 55 } 893 syntax SEQUENCE OF Targets 894 criticality MUST be TRUE 895 896 897 898Farrell & Housley Standards Track [Page 16] 899 900RFC 3281 An Internet Attribute Certificate April 2002 901 902 9034.3.3 Authority Key Identifier 904 905 The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY 906 be used to assist the AC verifier in checking the signature of the 907 AC. The [PKIXPROF] description should be read as if "CA" meant "AC 908 issuer." As with PKCs, this extension SHOULD be included in ACs. 909 910 Note: An AC, where the issuer field used the baseCertificateID 911 CHOICE, would not need an authorityKeyIdentifier extension, as it is 912 explicitly linked to the key in the referred certificate. However, 913 as this profile states (in section 4.2.3), ACs MUST use the v2Form 914 with issuerName CHOICE, this duplication does not arise. 915 916 name id-ce-authorityKeyIdentifier 917 OID { id-ce 35 } 918 syntax AuthorityKeyIdentifier 919 criticality MUST be FALSE 920 9214.3.4 Authority Information Access 922 923 The authorityInformationAccess extension, as defined in [PKIXPROF], 924 MAY be used to assist the AC verifier in checking the revocation 925 status of the AC. Support for the id-ad-caIssuers accessMethod is 926 NOT REQUIRED by this profile since AC chains are not expected. 927 928 The following accessMethod is used to indicate that revocation status 929 checking is provided for this AC, using the OCSP protocol defined in 930 [OCSP]: 931 932 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 933 934 The accessLocation MUST contain a URI, and the URI MUST contain an 935 HTTP URL [URL] that specifies the location of an OCSP responder. The 936 AC issuer MUST, of course, maintain an OCSP responder at this 937 location. 938 939 name id-ce-authorityInfoAccess 940 OID { id-pe 1 } 941 syntax AuthorityInfoAccessSyntax 942 criticality MUST be FALSE 943 9444.3.5 CRL Distribution Points 945 946 The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY 947 be used to assist the AC verifier in checking the revocation status 948 of the AC. See section 6 for details on revocation. 949 950 951 952 953 954Farrell & Housley Standards Track [Page 17] 955 956RFC 3281 An Internet Attribute Certificate April 2002 957 958 959 If the crlDistributionPoints extension is present, then exactly one 960 distribution point MUST be present. The crlDistributionPoints 961 extension MUST use the DistributionPointName option, which MUST 962 contain a fullName, which MUST contain a single name form. That name 963 MUST contain either a distinguished name or a URI. The URI MUST be 964 either an HTTP URL or an LDAP URL [URL]. 965 966 name id-ce-cRLDistributionPoints 967 OID { id-ce 31 } 968 syntax CRLDistPointsSyntax 969 criticality MUST be FALSE 970 9714.3.6 No Revocation Available 972 973 The noRevAvail extension, defined in [X.509-2000], allows an AC 974 issuer to indicate that no revocation information will be made 975 available for this AC. 976 977 This extension MUST be non-critical. An AC verifier that does not 978 understand this extension might be able to find a revocation list 979 from the AC issuer, but the revocation list will never include an 980 entry for the AC. 981 982 name id-ce-noRevAvail 983 OID { id-ce 56 } 984 syntax NULL (i.e. '0500'H is the DER encoding) 985 criticality MUST be FALSE 986 9874.4 Attribute Types 988 989 Some of the attribute types defined below make use of the 990 IetfAttrSyntax type, also defined below. The reasons for using this 991 type are: 992 993 1. It allows a separation between the AC issuer and the attribute 994 policy authority. This is useful for situations where a single 995 policy authority (e.g. an organization) allocates attribute 996 values, but where multiple AC issuers are deployed for performance 997 or other reasons. 998 999 2. The syntaxes allowed for values are restricted to OCTET STRING, 1000 OBJECT IDENTIFIER, and UTF8String, which significantly reduces the 1001 complexity associated with matching more general syntaxes. All 1002 multi-valued attributes using this syntax are restricted so that 1003 each value MUST use the same choice of value syntax. For example, 1004 AC issuers must not use one value with an oid and a second value 1005 with a string. 1006 1007 1008 1009 1010Farrell & Housley Standards Track [Page 18] 1011 1012RFC 3281 An Internet Attribute Certificate April 2002 1013 1014 1015 IetfAttrSyntax ::= SEQUENCE { 1016 policyAuthority [0] GeneralNames OPTIONAL, 1017 values SEQUENCE OF CHOICE { 1018 octets OCTET STRING, 1019 oid OBJECT IDENTIFIER, 1020 string UTF8String 1021 } 1022 } 1023 1024 In the descriptions below, each attribute type is either tagged 1025 "Multiple Allowed" or "One Attribute value only; multiple values 1026 within the IetfAttrSyntax". This refers to the SET OF 1027 AttributeValues; the AttributeType still only occurs once, as 1028 specified in section 4.2.7. 1029 10304.4.1 Service Authentication Information 1031 1032 The SvceAuthInfo attribute identifies the AC holder to the 1033 server/service by a name, and the attribute MAY include optional 1034 service specific authentication information. Typically this will 1035 contain a username/password pair for a "legacy" application. 1036 1037 This attribute provides information that can be presented by the AC 1038 verifier to be interpreted and authenticated by a separate 1039 application within the target system. Note that this is a different 1040 use to that intended for the accessIdentity attribute in 4.4.2 below. 1041 1042 This attribute type will typically be encrypted when the authInfo 1043 field contains sensitive information, such as a password. 1044 1045 name id-aca-authenticationInfo 1046 OID { id-aca 1 } 1047 Syntax SvceAuthInfo 1048 values: Multiple allowed 1049 1050 SvceAuthInfo ::= SEQUENCE { 1051 service GeneralName, 1052 ident GeneralName, 1053 authInfo OCTET STRING OPTIONAL 1054 } 1055 10564.4.2 Access Identity 1057 1058 The accessIdentity attribute identifies the AC holder to the 1059 server/service. For this attribute the authInfo field MUST NOT be 1060 present. 1061 1062 1063 1064 1065 1066Farrell & Housley Standards Track [Page 19] 1067 1068RFC 3281 An Internet Attribute Certificate April 2002 1069 1070 1071 This attribute is intended to be used to provide information about 1072 the AC holder, that can be used by the AC verifier (or a larger 1073 system of which the AC verifier is a component) to authorize the 1074 actions of the AC holder within the AC verifier's system. Note that 1075 this is a different use to that intended for the svceAuthInfo 1076 attribute described in 4.4.1 above. 1077 1078 name id-aca-accessIdentity 1079 OID { id-aca 2 } 1080 syntax SvceAuthInfo 1081 values: Multiple allowed 1082 10834.4.3 Charging Identity 1084 1085 The chargingIdentity attribute identifies the AC holder for charging 1086 purposes. In general, the charging identity will be different from 1087 other identities of the holder. For example, the holder's company 1088 may be charged for service. 1089 1090 name id-aca-chargingIdentity 1091 OID { id-aca 3 } 1092 syntax IetfAttrSyntax 1093 values: One Attribute value only; multiple values within the 1094 IetfAttrSyntax 1095 10964.4.4 Group 1097 1098 The group attribute carries information about group memberships of 1099 the AC holder. 1100 1101 name id-aca-group 1102 OID { id-aca 4 } 1103 syntax IetfAttrSyntax 1104 values: One Attribute value only; multiple values within the 1105 IetfAttrSyntax 1106 11074.4.5 Role 1108 1109 The role attribute, specified in [X.509-2000], carries information 1110 about role allocations of the AC holder. 1111 1112 The syntax used for this attribute is: 1113 1114 RoleSyntax ::= SEQUENCE { 1115 roleAuthority [0] GeneralNames OPTIONAL, 1116 roleName [1] GeneralName 1117 } 1118 1119 1120 1121 1122Farrell & Housley Standards Track [Page 20] 1123 1124RFC 3281 An Internet Attribute Certificate April 2002 1125 1126 1127 The roleAuthority field MAY be used to specify the issuing authority 1128 for the role specification certificate. There is no requirement that 1129 a role specification certificate necessarily exists for the 1130 roleAuthority. This differs from [X.500-2000], where the 1131 roleAuthority field is assumed to name the issuer of a role 1132 specification certificate. For example, to distinguish the 1133 administrator role as defined by "Baltimore" from that defined by 1134 "SPYRUS", one could put the value "urn:administrator" in the roleName 1135 field and the value "Baltimore" or "SPYRUS" in the roleAuthority 1136 field. 1137 1138 The roleName field MUST be present, and roleName MUST use the 1139 uniformResourceIdentifier CHOICE of the GeneralName. 1140 1141 name id-at-role 1142 OID { id-at 72 } 1143 syntax RoleSyntax 1144 values: Multiple allowed 1145 11464.4.6 Clearance 1147 1148 The clearance attribute, specified in [X.501-1993], carries clearance 1149 (associated with security labeling) information about the AC holder. 1150 1151 The policyId field is used to identify the security policy to which 1152 the clearance relates. The policyId indicates the semantics of the 1153 classList and securityCategories fields. 1154 1155 This specification includes the classList field exactly as it is 1156 specified in [X.501-1993]. Additional security classification 1157 values, and their position in the classification hierarchy, may be 1158 defined by a security policy as a local matter or by bilateral 1159 agreement. The basic security classification hierarchy is, in 1160 ascending order: unmarked, unclassified, restricted, confidential, 1161 secret, and top-secret. 1162 1163 An organization can develop its own security policy that defines 1164 security classification values and their meanings. However, the BIT 1165 STRING positions 0 through 5 are reserved for the basic security 1166 classification hierarchy. 1167 1168 If present, the SecurityCategory field provides further authorization 1169 information. The security policy identified by the policyId field 1170 indicates the syntaxes that are allowed to be present in the 1171 securityCategories SET. An OBJECT IDENTIFIER identifies each of the 1172 allowed syntaxes. When one of these syntaxes is present in the 1173 securityCategories SET, the OBJECT IDENTIFIER associated with that 1174 syntax is carried in the SecurityCategory.type field. 1175 1176 1177 1178Farrell & Housley Standards Track [Page 21] 1179 1180RFC 3281 An Internet Attribute Certificate April 2002 1181 1182 1183 Clearance ::= SEQUENCE { 1184 policyId [0] OBJECT IDENTIFIER, 1185 classList [1] ClassList DEFAULT {unclassified}, 1186 securityCategories 1187 [2] SET OF SecurityCategory OPTIONAL 1188 } 1189 1190 ClassList ::= BIT STRING { 1191 unmarked (0), 1192 unclassified (1), 1193 restricted (2) 1194 confidential (3), 1195 secret (4), 1196 topSecret (5) 1197 } 1198 1199 SecurityCategory ::= SEQUENCE { 1200 type [0] IMPLICIT OBJECT IDENTIFIER, 1201 value [1] ANY DEFINED BY type 1202 } 1203 1204 -- This is the same as the original syntax which was defined 1205 -- using the MACRO construct, as follows: 1206 -- SecurityCategory ::= SEQUENCE { 1207 -- type [0] IMPLICIT SECURITY-CATEGORY, 1208 -- value [1] ANY DEFINED BY type 1209 -- } 1210 -- 1211 -- SECURITY-CATEGORY MACRO ::= 1212 -- BEGIN 1213 -- TYPE NOTATION ::= type | empty 1214 -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 1215 -- END 1216 1217 1218 1219 name { id-at-clearance } 1220 OID { joint-iso-ccitt(2) ds(5) module(1) 1221 selected-attribute-types(5) clearance (55) } 1222 syntax Clearance - imported from [X.501-1993] 1223 values Multiple allowed 1224 12254.5 Profile of AC issuer's PKC 1226 1227 The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage 1228 extension in the PKC MUST NOT explicitly indicate that the AC 1229 issuer's public key cannot be used to validate a digital signature. 1230 In order to avoid confusion regarding serial numbers and revocations, 1231 1232 1233 1234Farrell & Housley Standards Track [Page 22] 1235 1236RFC 3281 An Internet Attribute Certificate April 2002 1237 1238 1239 an AC issuer MUST NOT also be a PKC Issuer. That is, an AC issuer 1240 cannot be a CA as well. So, the AC issuer's PKC MUST NOT have a 1241 basicConstraints extension with the cA BOOLEAN set to TRUE. 1242 12435. Attribute Certificate Validation 1244 1245 This section describes a basic set of rules that all valid ACs MUST 1246 satisfy. Some additional checks are also described which AC 1247 verifiers MAY choose to implement. 1248 1249 To be valid an AC MUST satisfy all of the following: 1250 1251 1. Where the holder uses a PKC to authenticate to the AC verifier, 1252 the AC holder's PKC MUST be found, and the entire certification 1253 path of that PKC MUST be verified in accordance with [PKIXPROF]. 1254 As noted in the security considerations section, if some other 1255 authentication scheme is used, AC verifiers need to be very 1256 careful mapping the identities (authenticated identity, holder 1257 field) involved. 1258 1259 2. The AC signature must be cryptographically correct, and the AC 1260 issuer's entire PKC certification path MUST be verified in 1261 accordance with [PKIXPROF]. 1262 1263 3. The AC issuer's PKC MUST also conform to the profile specified in 1264 section 4.5 above. 1265 1266 4. The AC issuer MUST be directly trusted as an AC issuer (by 1267 configuration or otherwise). 1268 1269 5. The time for which the AC is being evaluated MUST be within the AC 1270 validity. If the evaluation time is equal to either notBeforeTime 1271 or notAfterTime, then the AC is timely and this check succeeds. 1272 Note that in some applications, the evaluation time MAY not be the 1273 same as the current time. 1274 1275 6. The AC targeting check MUST pass as specified in section 4.3.2. 1276 1277 7. If the AC contains an unsupported critical extension, the AC MUST 1278 be rejected. 1279 1280 Support for an extension in this context means: 1281 1282 1. The AC verifier MUST be able to parse the extension value. 1283 1284 2. Where the extension value SHOULD cause the AC to be rejected, the 1285 AC verifier MUST reject the AC. 1286 1287 1288 1289 1290Farrell & Housley Standards Track [Page 23] 1291 1292RFC 3281 An Internet Attribute Certificate April 2002 1293 1294 1295 Additional Checks: 1296 1297 1. The AC MAY be rejected on the basis of further AC verifier 1298 configuration. For example, an AC verifier may be configured to 1299 reject ACs which contain or lack certain attributes. 1300 1301 2. If the AC verifier provides an interface that allows applications 1302 to query the contents of the AC, then the AC verifier MAY filter 1303 the attributes from the AC on the basis of configured information. 1304 For example, an AC verifier might be configured not to return 1305 certain attributes to certain servers. 1306 13076. Revocation 1308 1309 In many environments, the validity period of an AC is less than the 1310 time required to issue and distribute revocation information. 1311 Therefore, short-lived ACs typically do not require revocation 1312 support. However, long-lived ACs and environments where ACs enable 1313 high value transactions MAY require revocation support. 1314 1315 Two revocation schemes are defined, and the AC issuer should elect 1316 the one that is best suited to the environment in which the AC will 1317 be employed. 1318 1319 "Never revoke" scheme: 1320 1321 ACs may be marked so that the relying party understands that no 1322 revocation status information will be made available. The 1323 noRevAvail extension is defined in section 4.3.6, and the 1324 noRevAvail extension MUST be present in the AC to indicate use of 1325 this scheme. 1326 1327 Where no noRevAvail is present, the AC issuer is implicitly 1328 stating that revocation status checks are supported, and some 1329 revocation method MUST be provided to allow AC verifiers to 1330 establish the revocation status of the AC. 1331 1332 "Pointer in AC" scheme: 1333 1334 ACs may "point" to sources of revocation status information, using 1335 either an authorityInfoAccess extension or a crlDistributionPoints 1336 extension within the AC. 1337 1338 For AC users, the "never revoke" scheme MUST be supported, and the 1339 "pointer in AC" scheme SHOULD be supported. If only the "never 1340 revoke" scheme is supported, then all ACs that do not contain a 1341 noRevAvail extension, MUST be rejected. 1342 1343 1344 1345 1346Farrell & Housley Standards Track [Page 24] 1347 1348RFC 3281 An Internet Attribute Certificate April 2002 1349 1350 1351 For AC issuers, the "never revoke" scheme MUST be supported. If all 1352 ACs that will ever be issued by that AC issuer, contains a noRevAvail 1353 extension, the "pointer in AC" scheme need not be supported. If any 1354 AC can be issued that does not contain the noRevAvail extension, the 1355 "pointer in AC" scheme MUST be supported. 1356 1357 An AC MUST NOT contain both a noRevAvail and a "pointer in AC". 1358 1359 An AC verifier MAY use any source for AC revocation status 1360 information. 1361 13627. Optional Features 1363 1364 This section specifies features that MAY be implemented. Conformance 1365 to this profile does NOT require support for these features; however, 1366 if these features are offered, they MUST be offered as described 1367 below. 1368 13697.1 Attribute Encryption 1370 1371 Where an AC will be carried in clear within an application protocol 1372 or where an AC contains some sensitive information like a legacy 1373 application username/password, then encryption of AC attributes MAY 1374 be needed. 1375 1376 When a set of attributes are to be encrypted within an AC, the 1377 Cryptographic Message Syntax, EnvelopedData structure [CMS] is used 1378 to carry the ciphertext and associated per-recipient keying 1379 information. 1380 1381 This type of attribute encryption is targeted. Before the AC is 1382 signed, the attributes are encrypted for a set of predetermined 1383 recipients. 1384 1385 The AC then contains the ciphertext inside its signed data. The 1386 EnvelopedData (id-envelopedData) ContentType is used, and the content 1387 field will contain the EnvelopedData type. 1388 1389 The ciphertext is included in the AC as the value of an encAttrs 1390 attribute. Only one encAttrs attribute can be present in an AC; 1391 however, the encAttrs attribute MAY be multi-valued, and each of its 1392 values will contain an independent EnvelopedData. 1393 1394 Each value can contain a set of attributes (each possibly a multi- 1395 valued attribute) encrypted for a set of predetermined recipients. 1396 1397 1398 1399 1400 1401 1402Farrell & Housley Standards Track [Page 25] 1403 1404RFC 3281 An Internet Attribute Certificate April 2002 1405 1406 1407 The cleartext that is encrypted has the type: 1408 1409 ACClearAttrs ::= SEQUENCE { 1410 acIssuer GeneralName, 1411 acSerial INTEGER, 1412 attrs SEQUENCE OF Attribute 1413 } 1414 1415 The DER encoding of the ACClearAttrs structure is used as the 1416 encryptedContent field of the EnvelopedData. The DER encoding MUST 1417 be embedded in an OCTET STRING. 1418 1419 The acIssuer and acSerial fields are present to prevent ciphertext 1420 stealing. When an AC verifier has successfully decrypted an 1421 encrypted attribute, it MUST then check that the AC issuer and 1422 serialNumber fields contain the same values. This prevents a 1423 malicious AC issuer from copying ciphertext from another AC (without 1424 knowing its corresponding plaintext). 1425 1426 The procedure for an AC issuer when encrypting attributes is 1427 illustrated by the following (any other procedure that gives the same 1428 result MAY be used): 1429 1430 1. Identify the sets of attributes that are to be encrypted for 1431 each set of recipients. 1432 2. For each attribute set which is to be encrypted: 1433 2.1. Create an EnvelopedData structure for the data for this 1434 set of recipients. 1435 2.2. Encode the ContentInfo containing the EnvelopedData as a 1436 value of the encAttrs attribute. 1437 2.3. Ensure the cleartext attributes are not present in the 1438 to-be-signed AC. 1439 3. Add the encAttrs (with its multiple values) to the AC. 1440 1441 Note that there may be more than one attribute of the same type (the 1442 same OBJECT IDENTIFIER) after decryption. That is, an AC MAY contain 1443 the same attribute type both in clear and in encrypted form (and 1444 indeed several times if the same recipient is associated with more 1445 than one EnvelopedData). One approach implementers may choose, would 1446 be to merge attribute values following decryption in order to re- 1447 establish the "once only" constraint. 1448 1449 name id-aca-encAttrs 1450 OID { id-aca 6} 1451 Syntax ContentInfo 1452 values Multiple Allowed 1453 1454 1455 1456 1457 1458Farrell & Housley Standards Track [Page 26] 1459 1460RFC 3281 An Internet Attribute Certificate April 2002 1461 1462 1463 If an AC contains attributes, apparently encrypted for the AC 1464 verifier, the decryption process MUST not fail. If decryption does 1465 fail, the AC MUST be rejected. 1466 14677.2 Proxying 1468 1469 When a server acts as a client for another server on behalf of the AC 1470 holder, the server MAY need to proxy an AC. Such proxying MAY have 1471 to be done under the AC issuer's control, so that not every AC is 1472 proxiable and so that a given proxiable AC can be proxied in a 1473 targeted fashion. Support for chains of proxies (with more than one 1474 intermediate server) MAY also be required. Note that this does not 1475 involve a chain of ACs. 1476 1477 In order to meet this requirement we define another extension, 1478 ProxyInfo, similar to the targeting extension. 1479 1480 When this extension is present, the AC verifier must check that the 1481 entity from which the AC was received was allowed to send it and that 1482 the AC is allowed to be used by this verifier. 1483 1484 The proxying information consists of a set of proxy information, each 1485 of which is a set of targeting information. If the verifier and the 1486 sender of the AC are both named in the same proxy set, the AC can 1487 then be accepted (the exact rule is given below). 1488 1489 The effect is that the AC holder can send the AC to any valid target 1490 which can then only proxy to targets which are in one of the same 1491 proxy sets as itself. 1492 1493 The following data structure is used to represent the 1494 targeting/proxying information. 1495 1496 ProxyInfo ::= SEQUENCE OF Targets 1497 1498 As in the case of targeting, the targetCert CHOICE MUST NOT be used. 1499 1500 A proxy check succeeds if either one of the conditions below is met: 1501 1502 1. The identity of the sender, as established by the underlying 1503 authentication service, matches the holder field of the AC, and 1504 the current server "matches" any one of the proxy sets. Recall 1505 that "matches" is as defined section 4.3.2. 1506 1507 1508 1509 1510 1511 1512 1513 1514Farrell & Housley Standards Track [Page 27] 1515 1516RFC 3281 An Internet Attribute Certificate April 2002 1517 1518 1519 2. The identity of the sender, as established by the underlying 1520 authentication service, "matches" one of the proxy sets (call it 1521 set "A"), and the current server is one of the targetName fields 1522 in the set "A", or the current server is a member of one of the 1523 targetGroup fields in set "A". 1524 1525 When an AC is proxied more than once, a number of targets will be on 1526 the path from the original client, which is normally, but not always, 1527 the AC holder. In such cases, prevention of AC "stealing" requires 1528 that the AC verifier MUST check that all targets on the path are 1529 members of the same proxy set. It is the responsibility of the AC- 1530 using protocol to ensure that a trustworthy list of targets on the 1531 path is available to the AC verifier. 1532 1533 name id-pe-ac-proxying 1534 OID { id-pe 10 } 1535 syntax ProxyInfo 1536 criticality MUST be TRUE 1537 15387.3 Use of ObjectDigestInfo 1539 1540 In some environments, it may be required that the AC is not linked 1541 either to an identity (via entityName) or to a PKC (via 1542 baseCertificateID). The objectDigestInfo CHOICE in the holder field 1543 allows support for this requirement. 1544 1545 If the holder is identified with the objectDigestInfo field, then the 1546 AC version field MUST contain v2 (the integer 1). 1547 1548 The idea is to link the AC to an object by placing a hash of that 1549 object into the holder field of the AC. For example, this allows 1550 production of ACs that are linked to public keys rather than names. 1551 It also allows production of ACs which contain privileges associated 1552 with an executable object such as a Java class. However, this 1553 profile only specifies how to use a hash over a public key or PKC. 1554 That is, conformant ACs MUST NOT use the otherObjectTypes value for 1555 the digestedObjectType. 1556 1557 To link an AC to a public key, the hash must be calculated over the 1558 representation of that public key which would be present in a PKC, 1559 specifically, the input for the hash algorithm MUST be the DER 1560 encoding of a SubjectPublicKeyInfo representation of the key. Note: 1561 This includes the AlgorithmIdentifier as well as the BIT STRING. The 1562 rules given in [PKIXPROF] for encoding keys MUST be followed. In 1563 this case, the digestedObjectType MUST be publicKey and the 1564 otherObjectTypeID field MUST NOT be present. 1565 1566 1567 1568 1569 1570Farrell & Housley Standards Track [Page 28] 1571 1572RFC 3281 An Internet Attribute Certificate April 2002 1573 1574 1575 Note that if the public key value used as input to the hash function 1576 has been extracted from a PKC, it is possible that the 1577 SubjectPublicKeyInfo from that PKC is NOT the value which should be 1578 hashed. This can occur if DSA Dss-parms are inherited as described 1579 in section 7.3.3 of [PKIXPROF]. The correct input for hashing in 1580 this context will include the value of the parameters inherited from 1581 the CA's PKC, and thus may differ from the SubjectPublicKeyInfo 1582 present in the PKC. 1583 1584 Implementations which support this feature MUST be able to handle the 1585 representations of public keys for the algorithms specified in 1586 section 7.3 of [PKIXPROF]. In this case, the digestedObjectType MUST 1587 be publicKey and the otherObjectTypeID field MUST NOT be present. 1588 1589 In order to link an AC to a PKC via a digest, the digest MUST be 1590 calculated over the DER encoding of the entire PKC, including the 1591 signature value. In this case the digestedObjectType MUST be 1592 publicKeyCert and the otherObjectTypeID field MUST NOT be present. 1593 15947.4 AA Controls 1595 1596 During AC validation a relying party has to answer the question: is 1597 this AC issuer trusted to issue ACs containing this attribute? The 1598 AAControls PKC extension MAY be used to help answer the question. 1599 The AAControls extension is intended to be used in CA and AC issuer 1600 PKCs. 1601 1602 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1603 1604 AAControls ::= SEQUENCE { 1605 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1606 permittedAttrs [0] AttrSpec OPTIONAL, 1607 excludedAttrs [1] AttrSpec OPTIONAL, 1608 permitUnSpecified BOOLEAN DEFAULT TRUE 1609 } 1610 1611 AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER 1612 1613 The AAControls extension is used as follows: 1614 1615 The pathLenConstraint, if present, is interpreted as in [PKIXPROF]. 1616 It restricts the allowed distance between the AA CA (a CA directly 1617 trusted to include AAControls in its PKCs), and the AC issuer. 1618 1619 The permittedAttrs field specifies a set of attribute types that any 1620 AC issuer below this AA CA is allowed to include in ACs. If this 1621 field is not present, it means that no attribute types are explicitly 1622 allowed. 1623 1624 1625 1626Farrell & Housley Standards Track [Page 29] 1627 1628RFC 3281 An Internet Attribute Certificate April 2002 1629 1630 1631 The excludedAttrs field specifies a set of attribute types that no AC 1632 issuer is allowed to include in ACs. If this field is not present, 1633 it means that no attribute types are explicitly disallowed. 1634 1635 The permitUnSpecified field specifies how to handle attribute types 1636 which are not present in either the permittedAttrs or excludedAttrs 1637 fields. TRUE (the default) means that any unspecified attribute type 1638 is allowed in ACs; FALSE means that no unspecified attribute type is 1639 allowed. 1640 1641 When AAControls are used, the following additional checks on an AA's 1642 PKC chain MUST all succeed for the AC to be valid: 1643 1644 1. Some CA on the ACs certificate path MUST be directly trusted to 1645 issue PKCs which precede the AC issuer in the certification path; 1646 call this CA the "AA CA". 1647 1648 2. All PKCs on the path from the AA CA, down to and including the AC 1649 issuer's PKC, MUST contain an AAControls extension; however, the 1650 AA CA's PKC need not contain this extension. 1651 1652 3. Only those attributes in the AC which are allowed, according to 1653 all of the AAControls extension values in all of the PKCs from the 1654 AA CA to the AC issuer, may be used for authorization decisions; 1655 all other attributes MUST be ignored. This check MUST be applied 1656 to the set of attributes following attribute decryption, and the 1657 id-aca-encAttrs type MUST also be checked. 1658 1659 name id-pe-aaControls 1660 OID { id-pe 6 } 1661 syntax AAControls 1662 criticality MAY be TRUE 1663 16648. Security Considerations 1665 1666 The protection afforded for private keys is a critical factor in 1667 maintaining security. Failure of AC issuers to protect their private 1668 keys will permit an attacker to masquerade as them, potentially 1669 generating false ACs or revocation status. Existence of bogus ACs 1670 and revocation status will undermine confidence in the system. If 1671 the compromise is detected, all ACs issued by the AC issuer MUST be 1672 revoked. Rebuilding after such a compromise will be problematic, so 1673 AC issuers are advised to implement a combination of strong technical 1674 measures (e.g., tamper-resistant cryptographic modules) and 1675 appropriate management procedures (e.g., separation of duties) to 1676 avoid such an incident. 1677 1678 1679 1680 1681 1682Farrell & Housley Standards Track [Page 30] 1683 1684RFC 3281 An Internet Attribute Certificate April 2002 1685 1686 1687 Loss of an AC issuer's private signing key may also be problematic. 1688 The AC issuer would not be able to produce revocation status or 1689 perform AC renewal. AC issuers are advised to maintain secure backup 1690 for signing keys. The security of the key backup procedures is a 1691 critical factor in avoiding key compromise. 1692 1693 The availability and freshness of revocation status will affect the 1694 degree of assurance that should be placed in a long-lived AC. While 1695 long-lived ACs expire naturally, events may occur during its natural 1696 lifetime which negate the binding between the AC holder and the 1697 attributes. If revocation status is untimely or unavailable, the 1698 assurance associated with the binding is clearly reduced. 1699 1700 The binding between an AC holder and attributes cannot be stronger 1701 than the cryptographic module implementation and algorithms used to 1702 generate the signature. Short key lengths or weak hash algorithms 1703 will limit the utility of an AC. AC issuers are encouraged to note 1704 advances in cryptology so they can employ strong cryptographic 1705 techniques. 1706 1707 Inconsistent application of name comparison rules may result in 1708 acceptance of invalid targeted or proxied ACs, or rejection of valid 1709 ones. The X.500 series of specifications defines rules for comparing 1710 distinguished names. These rules require comparison of strings 1711 without regard to case, character set, multi-character white space 1712 substrings, or leading and trailing white space. This specification 1713 and [PKIXPROF] relaxes these requirements, requiring support for 1714 binary comparison at a minimum. 1715 1716 AC issuers MUST encode the distinguished name in the AC 1717 holder.entityName field identically to the distinguished name in the 1718 holder's PKC. If different encodings are used, implementations of 1719 this specification may fail to recognize that the AC and PKC belong 1720 to the same entity. 1721 1722 If an attribute certificate is tied to the holder's PKC using the 1723 baseCertificateID component of the Holder field and the PKI in use 1724 includes a rogue CA with the same issuer name specified in the 1725 baseCertificateID component, this rogue CA could issue a PKC to a 1726 malicious party, using the same issuer name and serial number as the 1727 proper holder's PKC. Then the malicious party could use this PKC in 1728 conjunction with the AC. This scenario SHOULD be avoided by properly 1729 managing and configuring the PKI so that there cannot be two CAs with 1730 the same name. Another alternative is to tie ACs to PKCs using the 1731 publicKeyCert type in the ObjectDigestInfo field. Failing this, AC 1732 verifiers have to establish (using other means) that the potential 1733 collisions cannot actually occur, for example, the CPSs of the CAs 1734 involved may make it clear that no such name collisions can occur. 1735 1736 1737 1738Farrell & Housley Standards Track [Page 31] 1739 1740RFC 3281 An Internet Attribute Certificate April 2002 1741 1742 1743 Implementers MUST ensure that following validation of an AC, only 1744 attributes that the issuer is trusted to issue are used in 1745 authorization decisions. Other attributes, which MAY be present MUST 1746 be ignored. Given that the AA controls PKC extension is optional to 1747 implement, AC verifiers MUST be provided with this information by 1748 other means. Configuration information is a likely alternative 1749 means. This becomes very important if an AC verifier trusts more 1750 than one AC issuer. 1751 1752 There is often a requirement to map between the authentication 1753 supplied by a particular security protocol (e.g. TLS, S/MIME) and the 1754 AC holder's identity. If the authentication uses PKCs, then this 1755 mapping is straightforward. However, it is envisaged that ACs will 1756 also be used in environments where the holder may be authenticated 1757 using other means. Implementers SHOULD be very careful in mapping 1758 the authenticated identity to the AC holder. 1759 17609. IANA Considerations 1761 1762 Attributes and attribute certificate extensions are identified by 1763 object identifiers (OIDs). Many of the OIDs used in this document 1764 are copied from X.509 [X.509-2000]. Other OIDs were assigned from an 1765 arc delegated by the IANA. No further action by the IANA is 1766 necessary for this document or any anticipated updates. 1767 176810. References 1769 1770 [CMC] Myers, M., Liu, X., Schaad, J. and J. Weinstein, 1771 "Certificate Management Messages over CMS", RFC 2797, 1772 April 2000. 1773 1774 [CMP] Adams, C. and S. Farrell, "Internet X.509 Public Key 1775 Infrastructure - Certificate Management Protocols", RFC 1776 2510, March 1999. 1777 1778 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, 1779 June 1999. 1780 1781 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 1782 RFC 2634, June 1999. 1783 1784 [KRB] Kohl, J. and C. Neuman, "The Kerberos Network 1785 Authentication Service (V5)", RFC 1510, September 1993. 1786 1787 [LDAP] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory 1788 Access Protocol (v3)", RFC 2251, December 1997. 1789 1790 1791 1792 1793 1794Farrell & Housley Standards Track [Page 32] 1795 1796RFC 3281 An Internet Attribute Certificate April 2002 1797 1798 1799 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. 1800 Adams, "X.509 Internet Public Key Infrastructure - 1801 Online Certificate Status Protocol - OCSP", RFC 2560, 1802 June 1999. 1803 1804 [PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and 1805 Identifiers for the Internet X.509 Public Key 1806 Infrastructure Certificate and Certificate Revocation 1807 Lists CRL Profile", RFC 3279, April 2002. 1808 1809 [PKIXPROF] Housley, R., Polk, T, Ford, W. and Solo, D., "Internet 1810 X.509 Public Key Infrastructure Certificate and 1811 Certificate Revocation List (CRL) Profile", RFC 3280, 1812 April 2002. 1813 1814 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1815 3", BCP 9, RFC 2026, October 1996. 1816 1817 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1818 Requirement Levels", BCP 14, RFC 2119, March 1997. 1819 1820 [URL] Berners-Lee, T., Masinter L. and M. McCahill, "Uniform 1821 Resource Locators (URL)", RFC 1738, December 1994. 1822 1823 [X.208-1988] CCITT Recommendation X.208: Specification of Abstract 1824 Syntax Notation One (ASN.1). 1988. 1825 1826 [X.209-88] CCITT Recommendation X.209: Specification of Basic 1827 Encoding Rules for Abstract Syntax Notation One (ASN.1). 1828 1988. 1829 1830 [X.501-88] CCITT Recommendation X.501: The Directory - Models. 1831 1988. 1832 1833 [X.501-1993] ITU-T Recommendation X.501 : Information Technology - 1834 Open Systems Interconnection - The Directory: Models, 1835 1993. 1836 1837 [X.509-1988] CCITT Recommendation X.509: The Directory - 1838 Authentication Framework. 1988. 1839 1840 [X.509-1997] ITU-T Recommendation X.509: The Directory - 1841 Authentication Framework. 1997. 1842 1843 [X.509-2000] ITU-T Recommendation X.509: The Directory - Public-Key 1844 and Attribute Certificate Frameworks. 2000 1845 1846 1847 1848 1849 1850Farrell & Housley Standards Track [Page 33] 1851 1852RFC 3281 An Internet Attribute Certificate April 2002 1853 1854 1855Appendix A: Object Identifiers 1856 1857 This (normative) appendix lists the new object identifiers which are 1858 defined in this specification. Some of these are required only for 1859 support of optional features and are not required for conformance to 1860 this profile. This specification mandates support for OIDs which 1861 have arc elements with values that are less than 2^32, (i.e. they 1862 MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less 1863 than 2^31 (i.e. less than or equal to 2,147,483,647). This allows 1864 each arc element to be represented within a single 32 bit word. 1865 Implementations MUST also support OIDs where the length of the dotted 1866 decimal (see [LDAP], section 4.1.2) string representation can be up 1867 to 100 bytes (inclusive). Implementations MUST be able to handle 1868 OIDs with up to 20 elements (inclusive). AA's SHOULD NOT issue ACs 1869 which contain OIDs that breach these requirements. 1870 1871 The following OIDs are imported from [PKIXPROF]: 1872 1873 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1874 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 1875 id-mod OBJECT IDENTIFIER ::= { id-pkix 0 } 1876 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 1877 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 1878 id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } 1879 id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 } 1880 1881 The following new ASN.1 module OID is defined: 1882 1883 id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 } 1884 1885 The following AC extension OIDs are defined: 1886 1887 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1888 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 } 1889 id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 1890 1891 The following PKC extension OIDs are defined: 1892 1893 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906Farrell & Housley Standards Track [Page 34] 1907 1908RFC 3281 An Internet Attribute Certificate April 2002 1909 1910 1911 The following attribute OIDs are defined: 1912 1913 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1914 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1915 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1916 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1917 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1918 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1919 id-at-role OBJECT IDENTIFIER ::= { id-at 72 } 1920 id-at-clearance OBJECT IDENTIFIER ::= 1921 { joint-iso-ccitt(2) ds(5) module(1) 1922 selected-attribute-types(5) clearance (55) } 1923 1924Appendix B: ASN.1 Module 1925 1926 PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) 1927 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1928 id-mod-attribute-cert(12)} 1929 1930 DEFINITIONS IMPLICIT TAGS ::= 1931 1932 BEGIN 1933 1934 -- EXPORTS ALL -- 1935 1936 IMPORTS 1937 1938 -- IMPORTed module OIDs MAY change if [PKIXPROF] changes 1939 -- PKIX Certificate Extensions 1940 Attribute, AlgorithmIdentifier, CertificateSerialNumber, 1941 Extensions, UniqueIdentifier, 1942 id-pkix, id-pe, id-kp, id-ad, id-at 1943 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 1944 dod(6) internet(1) security(5) mechanisms(5) 1945 pkix(7) id-mod(0) id-pkix1-explicit-88(1)} 1946 1947 GeneralName, GeneralNames, id-ce 1948 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 1949 dod(6) internet(1) security(5) mechanisms(5) 1950 pkix(7) id-mod(0) id-pkix1-implicit-88(2)} ; 1951 1952 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1953 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1954 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 } 1955 id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 1956 1957 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1958 1959 1960 1961 1962Farrell & Housley Standards Track [Page 35] 1963 1964RFC 3281 An Internet Attribute Certificate April 2002 1965 1966 1967 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1968 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1969 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1970 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1971 -- { id-aca 5 } is reserved 1972 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1973 1974 id-at-role OBJECT IDENTIFIER ::= { id-at 72} 1975 id-at-clearance OBJECT IDENTIFIER ::= 1976 { joint-iso-ccitt(2) ds(5) module(1) 1977 selected-attribute-types(5) clearance (55) } 1978 1979 -- Uncomment this if using a 1988 level ASN.1 compiler 1980 -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 1981 1982 AttributeCertificate ::= SEQUENCE { 1983 acinfo AttributeCertificateInfo, 1984 signatureAlgorithm AlgorithmIdentifier, 1985 signatureValue BIT STRING 1986 } 1987 1988 AttributeCertificateInfo ::= SEQUENCE { 1989 version AttCertVersion -- version is v2, 1990 holder Holder, 1991 issuer AttCertIssuer, 1992 signature AlgorithmIdentifier, 1993 serialNumber CertificateSerialNumber, 1994 attrCertValidityPeriod AttCertValidityPeriod, 1995 attributes SEQUENCE OF Attribute, 1996 issuerUniqueID UniqueIdentifier OPTIONAL, 1997 extensions Extensions OPTIONAL 1998 } 1999 2000 AttCertVersion ::= INTEGER { v2(1) } 2001 2002 Holder ::= SEQUENCE { 2003 baseCertificateID [0] IssuerSerial OPTIONAL, 2004 -- the issuer and serial number of 2005 -- the holder's Public Key Certificate 2006 entityName [1] GeneralNames OPTIONAL, 2007 -- the name of the claimant or role 2008 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 2009 -- used to directly authenticate the 2010 -- holder, for example, an executable 2011 } 2012 2013 2014 2015 2016 2017 2018Farrell & Housley Standards Track [Page 36] 2019 2020RFC 3281 An Internet Attribute Certificate April 2002 2021 2022 2023 ObjectDigestInfo ::= SEQUENCE { 2024 digestedObjectType ENUMERATED { 2025 publicKey (0), 2026 publicKeyCert (1), 2027 otherObjectTypes (2) }, 2028 -- otherObjectTypes MUST NOT 2029 -- MUST NOT be used in this profile 2030 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 2031 digestAlgorithm AlgorithmIdentifier, 2032 objectDigest BIT STRING 2033 } 2034 2035 AttCertIssuer ::= CHOICE { 2036 v1Form GeneralNames, -- MUST NOT be used in this 2037 -- profile 2038 v2Form [0] V2Form -- v2 only 2039 } 2040 2041 V2Form ::= SEQUENCE { 2042 issuerName GeneralNames OPTIONAL, 2043 baseCertificateID [0] IssuerSerial OPTIONAL, 2044 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 2045 -- issuerName MUST be present in this profile 2046 -- baseCertificateID and objectDigestInfo MUST 2047 -- NOT be present in this profile 2048 } 2049 2050 IssuerSerial ::= SEQUENCE { 2051 issuer GeneralNames, 2052 serial CertificateSerialNumber, 2053 issuerUID UniqueIdentifier OPTIONAL 2054 } 2055 2056 AttCertValidityPeriod ::= SEQUENCE { 2057 notBeforeTime GeneralizedTime, 2058 notAfterTime GeneralizedTime 2059 } 2060 2061 Targets ::= SEQUENCE OF Target 2062 2063 Target ::= CHOICE { 2064 targetName [0] GeneralName, 2065 targetGroup [1] GeneralName, 2066 targetCert [2] TargetCert 2067 } 2068 2069 2070 2071 2072 2073 2074Farrell & Housley Standards Track [Page 37] 2075 2076RFC 3281 An Internet Attribute Certificate April 2002 2077 2078 2079 TargetCert ::= SEQUENCE { 2080 targetCertificate IssuerSerial, 2081 targetName GeneralName OPTIONAL, 2082 certDigestInfo ObjectDigestInfo OPTIONAL 2083 } 2084 2085 IetfAttrSyntax ::= SEQUENCE { 2086 policyAuthority[0] GeneralNames OPTIONAL, 2087 values SEQUENCE OF CHOICE { 2088 octets OCTET STRING, 2089 oid OBJECT IDENTIFIER, 2090 string UTF8String 2091 } 2092 } 2093 2094 SvceAuthInfo ::= SEQUENCE { 2095 service GeneralName, 2096 ident GeneralName, 2097 authInfo OCTET STRING OPTIONAL 2098 } 2099 2100 RoleSyntax ::= SEQUENCE { 2101 roleAuthority [0] GeneralNames OPTIONAL, 2102 roleName [1] GeneralName 2103 } 2104 2105 Clearance ::= SEQUENCE { 2106 policyId [0] OBJECT IDENTIFIER, 2107 classList [1] ClassList DEFAULT {unclassified}, 2108 securityCategories 2109 [2] SET OF SecurityCategory OPTIONAL 2110 } 2111 2112 ClassList ::= BIT STRING { 2113 unmarked (0), 2114 unclassified (1), 2115 restricted (2), 2116 confidential (3), 2117 secret (4), 2118 topSecret (5) 2119 } 2120 2121 SecurityCategory ::= SEQUENCE { 2122 type [0] IMPLICIT OBJECT IDENTIFIER, 2123 value [1] ANY DEFINED BY type 2124 } 2125 2126 2127 2128 2129 2130Farrell & Housley Standards Track [Page 38] 2131 2132RFC 3281 An Internet Attribute Certificate April 2002 2133 2134 2135 AAControls ::= SEQUENCE { 2136 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 2137 permittedAttrs [0] AttrSpec OPTIONAL, 2138 excludedAttrs [1] AttrSpec OPTIONAL, 2139 permitUnSpecified BOOLEAN DEFAULT TRUE 2140 } 2141 2142 AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER 2143 2144 ACClearAttrs ::= SEQUENCE { 2145 acIssuer GeneralName, 2146 acSerial INTEGER, 2147 attrs SEQUENCE OF Attribute 2148 } 2149 2150 ProxyInfo ::= SEQUENCE OF Targets 2151 2152 END 2153 2154Author's Addresses 2155 2156 Stephen Farrell 2157 Baltimore Technologies 2158 39/41 Parkgate Street 2159 Dublin 8 2160 IRELAND 2161 2162 EMail: stephen.farrell@baltimore.ie 2163 2164 Russell Housley 2165 RSA Laboratories 2166 918 Spring Knoll Drive 2167 Herndon, VA 20170 2168 USA 2169 2170 EMail: rhousley@rsasecurity.com 2171 2172Acknowledgements 2173 2174 Russ Housley thanks the management at SPYRUS, who supported the 2175 development of this specification while he was employed at SPYRUS. 2176 Russ Housley also thanks the management at RSA Laboratories, who 2177 supported the completion of the specification after a job change. 2178 2179 2180 2181 2182 2183 2184 2185 2186Farrell & Housley Standards Track [Page 39] 2187 2188RFC 3281 An Internet Attribute Certificate April 2002 2189 2190 2191Full Copyright Statement 2192 2193 Copyright (C) The Internet Society (2002). All Rights Reserved. 2194 2195 This document and translations of it may be copied and furnished to 2196 others, and derivative works that comment on or otherwise explain it 2197 or assist in its implementation may be prepared, copied, published 2198 and distributed, in whole or in part, without restriction of any 2199 kind, provided that the above copyright notice and this paragraph are 2200 included on all such copies and derivative works. However, this 2201 document itself may not be modified in any way, such as by removing 2202 the copyright notice or references to the Internet Society or other 2203 Internet organizations, except as needed for the purpose of 2204 developing Internet standards in which case the procedures for 2205 copyrights defined in the Internet Standards process must be 2206 followed, or as required to translate it into languages other than 2207 English. 2208 2209 The limited permissions granted above are perpetual and will not be 2210 revoked by the Internet Society or its successors or assigns. 2211 2212 This document and the information contained herein is provided on an 2213 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2214 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2215 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2216 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2217 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2218 2219Acknowledgement 2220 2221 Funding for the RFC Editor function is currently provided by the 2222 Internet Society. 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242Farrell & Housley Standards Track [Page 40] 2243 2244