idnits 2.17.1 draft-ietf-pkix-3281update-05.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? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 27, 2009) is 5449 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 2012 -- Looks like a reference, but probably isn't: '1' on line 2013 -- Looks like a reference, but probably isn't: '2' on line 2014 == Missing Reference: 'UNIVERSAL 12' is mentioned on line 1835, but not defined ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) -- Obsolete informational reference (is this intentional?): RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 3281 (Obsoleted by RFC 5755) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF PKIX WG S. Farrell, Trinity College Dublin 2 Internet Draft R. Housley, Vigil Security 3 Intended Status: Standards Track S. Turner, IECA 4 Obsoletes: 3281 (once approved) April 27, 2009 5 Expires: October 27, 2009 7 An Internet Attribute Certificate Profile for Authorization 8 draft-ietf-pkix-3281update-05.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. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on October 27, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This specification defines a profile for the use of X.509 Attribute 57 Certificates in Internet Protocols. Attribute certificates may be 58 used in a wide range of applications and environments covering a 59 broad spectrum of interoperability goals and a broader spectrum of 60 operational and assurance requirements. The goal of this document is 61 to establish a common baseline for generic applications requiring 62 broad interoperability as well as limited special purpose 63 requirements. The profile places emphasis on attribute certificate 64 support for Internet electronic mail, IPsec, and WWW security 65 applications. This document obsoletes RFC 3281. 67 Discussion 69 This draft is being discussed on the 'ietf-pkix' mailing list. To 70 subscribe, send a message to ietf-pkix-request@imc.org with the 71 single word subscribe in the body of the message. There is a Web site 72 for the mailing list at . 74 Table of Contents 76 1. Introduction...................................................3 77 1.1. Requirements Terminology..................................5 78 1.2. AC Path Delegation........................................5 79 1.3. Attribute Certificate Distribution ("push" vs. "pull")....5 80 1.4. Document Structure........................................7 81 2. Terminology....................................................7 82 3. Requirements...................................................8 83 4. Attribute Certificate Profile..................................9 84 4.1. X.509 Attribute Certificate Definition...................10 85 4.2. Profile of Standard Fields...............................12 86 4.2.1. Version.............................................12 87 4.2.2. Holder..............................................12 88 4.2.3. Issuer..............................................14 89 4.2.4. Signature...........................................14 90 4.2.5. Serial Number.......................................14 91 4.2.6. Validity Period.....................................15 92 4.2.7. Attributes..........................................15 93 4.2.8. Issuer Unique Identifier............................16 94 4.2.9. Extensions..........................................16 95 4.3. Extensions...............................................16 96 4.3.1. Audit Identity......................................16 97 4.3.2. AC Targeting........................................17 98 4.3.3. Authority Key Identifier............................19 99 4.3.4. Authority Information Access........................19 100 4.3.5. CRL Distribution Points.............................20 101 4.3.6. No Revocation Available.............................20 102 4.4. Attribute Types..........................................20 103 4.4.1. Service Authentication Information..................21 104 4.4.2. Access Identity.....................................22 105 4.4.3. Charging Identity...................................22 106 4.4.4. Group...............................................22 107 4.4.5. Role................................................23 108 4.4.6. Clearance...........................................23 109 4.5. Profile of AC issuer's PKC...............................26 110 5. Attribute Certificate Validation..............................26 111 6. Revocation....................................................27 112 7. Optional Features.............................................28 113 7.1. Attribute Encryption.....................................29 114 7.2. Proxying.................................................30 115 7.3. Use of ObjectDigestInfo..................................32 116 7.4. AA Controls..............................................33 117 8. Security Considerations.......................................34 118 9. IANA Considerations...........................................36 119 10. References...................................................36 120 10.1. Normative References....................................36 121 10.2. Informative References..................................37 122 Appendix A Object Identifiers....................................38 123 Appendix B ASN.1 Module..........................................39 124 Appendix C Errata Submitted to RFC 3281..........................45 125 Appendix D Changes Since RFC 3281................................46 126 Authors' Addresses...............................................48 128 1. Introduction 130 X.509 public key certificates (PKCs) [X.509-1997, X.509-2000, 131 PKIXPROF] bind an identity and a public key. An attribute 132 certificate (AC) is a structure similar to a PKC; the main difference 133 being that the AC contains no public key. An AC may contain 134 attributes that specify group membership, role, security clearance, 135 or other authorization information associated with the AC holder. 137 The syntax for the AC is defined in Recommendation X.509, making the 138 term "X.509 certificate" ambiguous. 140 Some people constantly confuse PKCs and ACs. An analogy may make the 141 distinction clear. A PKC can be considered to be like a passport: it 142 identifies the holder, tends to last for a long time, and should not 143 be trivial to obtain. An AC is more like an entry visa: it is 144 typically issued by a different authority and does not last for as 145 long a time. As acquiring an entry visa typically requires 146 presenting a passport, getting a visa can be a simpler process. 148 Authorization information may be placed in a PKC extension or placed 149 in a separate attribute certificate (AC). The placement of 150 authorization information in PKCs is usually undesirable for two 151 reasons. First, authorization information often does not have the 152 same lifetime as the binding of the identity and the public key. When 153 authorization information is placed in a PKC extension, the general 154 result is the shortening of the PKC useful lifetime. Second, the PKC 155 issuer is not usually authoritative for the authorization 156 information. This results in additional steps for the PKC issuer to 157 obtain authorization information from the authoritative source. 159 For these reasons, it is often better to separate authorization 160 information from the PKC. Yet, authorization information also needs 161 to be bound to an identity. An AC provides this binding; it is 162 simply a digitally signed (or certified) identity and set of 163 attributes. 165 An AC may be used with various security services, including access 166 control, data origin authentication, and non-repudiation. 168 PKCs can provide an identity to access control decision functions. 169 However, in many contexts the identity is not the criterion that is 170 used for access control decisions, rather the role or group- 171 membership of the accessor is the criterion used. Such access 172 control schemes are called role-based access control. 174 When making an access control decision based on an AC, an access 175 control decision function may need to ensure that the appropriate AC 176 holder is the entity that has requested access. One way in which the 177 linkage between the request or identity and the AC can be achieved is 178 the inclusion of a reference to a PKC within the AC and the use of 179 the private key corresponding to the PKC for authentication within 180 the access request. 182 ACs may also be used in the context of a data origin authentication 183 service and a non-repudiation service. In these contexts, the 184 attributes contained in the AC provide additional information about 185 the signing entity. This information can be used to make sure that 186 the entity is authorized to sign the data. This kind of checking 187 depends either on the context in which the data is exchanged or on 188 the data that has been digitally signed. 190 This document obsoletes [RFC3281]. Changes since [RFC3281] are listed 191 in Appendix D. 193 1.1. Requirements Terminology 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in [RFC2119]. 199 1.2. AC Path Delegation 201 The X.509 standard [X.509-2000] defines authorization as the 202 "conveyance of privilege from one entity that holds such privilege, 203 to another entity". An AC is one authorization mechanism. 205 An ordered sequence of ACs could be used to verify the authenticity 206 of a privilege asserter's privilege. In this way, chains or paths of 207 ACs could be employed to delegate authorization. 209 Since the administration and processing associated with such AC 210 chains is complex and the use of ACs in the Internet today is quite 211 limited, it is RECOMMENDED that implementations of this specification 212 not use AC chains. Other (future) specifications may address the use 213 of AC chains. This specification deals with the simple cases, where 214 one authority issues all of the ACs for a particular set of 215 attributes. However, this simplification does not preclude the use 216 of several different authorities, each of which manages a different 217 set of attributes. For example, group membership may be included in 218 one AC issued by one authority, and security clearance may be 219 included in another AC issued by another authority. 221 This means that conformant implementations are only REQUIRED to be 222 able to process a single AC at a time. Processing of more than one 223 AC, one after another, may be necessary. Note however, that 224 validation of an AC MAY require validation of a chain of PKCs, as 225 specified in [PKIXPROF]. 227 1.3. Attribute Certificate Distribution ("push" vs. "pull") 229 As discussed above, ACs provide a mechanism to securely provide 230 authorization information to, for example, access control decision 231 functions. However, there are a number of possible communication 232 paths for ACs. 234 In some environments, it is suitable for a client to "push" an AC to 235 a server. This means that no new connections between the client and 236 server are required. It also means that no search burden is imposed 237 on servers, which improves performance and that the AC verifier is 238 only presented with what it "needs to know". The "push" model is 239 especially suitable in inter-domain cases where the client's rights 240 should be assigned within the client's "home" domain. 242 In other cases, it is more suitable for a client to simply 243 authenticate to the server and for the server to request or "pull" 244 the client's AC from an AC issuer or a repository. A major benefit 245 of the "pull" model is that it can be implemented without changes to 246 the client or to the client-server protocol. The "pull" model is 247 especially suitable for inter-domain cases where the client's rights 248 should be assigned within the server's domain, rather than within the 249 client's domain. 251 There are a number of possible exchanges involving three entities: 252 the client, the server, and the AC issuer. In addition, a directory 253 service or other repository for AC retrieval MAY be supported. 255 Figure 1 shows an abstract view of the exchanges that may involve 256 ACs. This profile does not specify a protocol for these exchanges. 258 +--------------+ 259 | | Server Acquisition 260 | AC issuer +<---------------------------+ 261 | | | 262 +--+-----------+ | 263 ^ | 264 | Client | 265 | Acquisition | 266 v v 267 +--+-----------+ +--+------------+ 268 | | AC "push" | | 269 | Client +<------------------------| Server | 270 | | (part of app. protocol) | | 271 +--+-----------+ +--+------------+ 272 ^ ^ 273 | Client | Server 274 | Lookup +--------------+ | Lookup 275 | | | | 276 +-------------->+ Repository +<--------+ 277 | | 278 +--------------+ 280 Figure 1: AC Exchanges 282 1.4. Document Structure 284 Section 2 defines some terminology. Section 3 specifies the 285 requirements that this profile is intended to meet. Section 4 286 contains the profile of the X.509 AC. Section 5 specifies rules for 287 AC validation. Section 6 specifies rules for AC revocation checks. 288 Section 7 specifies optional features which MAY be supported; 289 however, support for these features is not required for conformance 290 to this profile. Finally, appendices contain the list of OIDs 291 required to support this specification and an ASN.1 module. 293 2. Terminology 295 For simplicity, we use the terms client and server in this 296 specification. This is not intended to indicate that ACs are only to 297 be used in client-server environments. For example, ACs may be used 298 in the S/MIME v3.2 context, where the mail user agent would be both a 299 "client" and a "server" in the sense the terms are used here. 301 Term Meaning 303 AA Attribute Authority, the entity that issues the 304 AC, synonymous in this specification with "AC 305 issuer". 307 AC Attribute Certificate. 309 AC user Any entity that parses or processes an AC. 311 AC verifier Any entity that checks the validity of an AC and 312 then makes use of the result. 314 AC issuer The entity which signs the AC, synonymous in this 315 specification with "AA". 317 AC holder The entity indicated (perhaps indirectly) in the 318 holder field of the AC. 320 Client The entity which is requesting the action for 321 which authorization checks are to be made. 323 Proxying In this specification, Proxying is used to mean 324 the situation where an application server acts as 325 an application client on behalf of a user. 326 Proxying here does not mean granting of authority. 328 PKC Public Key Certificate - uses the ASN.1 type 329 Certificate defined in X.509 and profiled in RFC 330 5280. This (non-standard) acronym is used in order 331 to avoid confusion about the term "X.509 332 certificate". 334 Server The entity which requires that the authorization 335 checks are made. 337 3. Requirements 339 This AC profile meets the following requirements. 341 Time/Validity requirements: 343 1. Support for short-lived as well as long-lived ACs. Typical 344 short-lived validity periods might be measured in hours, as 345 opposed to months for PKCs. Short validity periods allow ACs to 346 be useful without a revocation mechanism. 348 Attribute Types: 350 2. Issuers of ACs should be able to define their own attribute types 351 for use within closed domains. 353 3. Some standard attribute types, which can be contained within ACs, 354 should be defined. Examples include "access identity", "group", 355 "role", "clearance", "audit identity", and "charging identity". 357 4. Standard attribute types should be defined in a manner that 358 permits an AC verifier to distinguish between uses of the same 359 attribute in different domains. For example, the "Administrators 360 group" as defined by Baltimore and the "Administrators group" as 361 defined by SPYRUS should be easily distinguished. 363 Targeting of ACs: 365 5. It should be possible to "target" an AC at one, or a small number 366 of, servers. This means that a trustworthy non-target server will 367 reject the AC for authorization decisions. 369 Push vs. Pull 371 6. ACs should be defined so that they can either be "pushed" by the 372 client to the server, or "pulled" by the server from a repository 373 or other network service, including an online AC issuer. 375 4. Attribute Certificate Profile 377 ACs may be used in a wide range of applications and environments 378 covering a broad spectrum of interoperability goals and a broader 379 spectrum of operational and assurance requirements. The goal of this 380 document is to establish a common baseline for generic applications 381 requiring broad interoperability and limited special purpose 382 requirements. In particular, the emphasis will be on supporting the 383 use of attribute certificates for informal Internet electronic mail, 384 IPsec, and WWW applications. 386 This section presents a profile for ACs that will foster 387 interoperability. This section also defines some private extensions 388 for the Internet community. 390 While the ISO/IEC/ITU documents use the 1993 (or later) version of 391 ASN.1, this document uses the 1988 ASN.1 syntax, as has been done for 392 PKCs [PKIXPROF]. The encoded certificates and extensions from either 393 ASN.1 version are bit-wise identical. 395 Where maximum lengths for fields are specified, these lengths refer 396 to the DER encoding and do not include the ASN.1 tag or length 397 fields. 399 Conforming implementations MUST support the profile specified in this 400 section. 402 4.1. X.509 Attribute Certificate Definition 404 X.509 contains the definition of an AC given below. All types that 405 are not defined in this document can be found in [PKIXPROF]. 407 AttributeCertificate ::= SEQUENCE { 408 acinfo AttributeCertificateInfo, 409 signatureAlgorithm AlgorithmIdentifier, 410 signatureValue BIT STRING 411 } 413 AttributeCertificateInfo ::= SEQUENCE { 414 version AttCertVersion, -- version is v2 415 holder Holder, 416 issuer AttCertIssuer, 417 signature AlgorithmIdentifier, 418 serialNumber CertificateSerialNumber, 419 attrCertValidityPeriod AttCertValidityPeriod, 420 attributes SEQUENCE OF Attribute, 421 issuerUniqueID UniqueIdentifier OPTIONAL, 422 extensions Extensions OPTIONAL 423 } 425 AttCertVersion ::= INTEGER { v2(1) } 427 Holder ::= SEQUENCE { 428 baseCertificateID [0] IssuerSerial OPTIONAL, 429 -- the issuer and serial number of 430 -- the holder's Public Key Certificate 431 entityName [1] GeneralNames OPTIONAL, 432 -- the name of the claimant or role 433 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 434 -- used to directly authenticate the holder, 435 -- for example, an executable 436 } 437 ObjectDigestInfo ::= SEQUENCE { 438 digestedObjectType ENUMERATED { 439 publicKey (0), 440 publicKeyCert (1), 441 otherObjectTypes (2) }, 442 -- otherObjectTypes MUST NOT 443 -- be used in this profile 444 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 445 digestAlgorithm AlgorithmIdentifier, 446 objectDigest BIT STRING 447 } 449 AttCertIssuer ::= CHOICE { 450 v1Form GeneralNames, -- MUST NOT be used in this 451 -- profile 452 v2Form [0] V2Form -- v2 only 453 } 455 V2Form ::= SEQUENCE { 456 issuerName GeneralNames OPTIONAL, 457 baseCertificateID [0] IssuerSerial OPTIONAL, 458 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 459 -- issuerName MUST be present in this profile 460 -- baseCertificateID and objectDigestInfo MUST NOT 461 -- be present in this profile 462 } 464 IssuerSerial ::= SEQUENCE { 465 issuer GeneralNames, 466 serial CertificateSerialNumber, 467 issuerUID UniqueIdentifier OPTIONAL 468 } 470 AttCertValidityPeriod ::= SEQUENCE { 471 notBeforeTime GeneralizedTime, 472 notAfterTime GeneralizedTime 473 } 475 Although the Attribute syntax is defined in [PKIXPROF], we repeat the 476 definition here for convenience. 478 Attribute ::= SEQUENCE { 479 type AttributeType, 480 values SET OF AttributeValue 481 -- at least one value is required 482 } 483 AttributeType ::= OBJECT IDENTIFIER 485 AttributeValue ::= ANY DEFINED BY AttributeType 487 Implementers should note that the DER encoding (see [X.509- 488 1988],[X.690]) of the SET OF values requires ordering of the 489 encodings of the values. Though this issue arises with respect to 490 distinguished names, and has to be handled by [PKIXPROF] 491 implementations, it is much more significant in this context, since 492 the inclusion of multiple values is much more common in ACs. 494 4.2. Profile of Standard Fields 496 GeneralName offers great flexibility. To achieve interoperability, 497 in spite of this flexibility, this profile imposes constraints on the 498 use of GeneralName. 500 Conforming implementations MUST be able to support the dNSName, 501 directoryName, uniformResourceIdentifier, and iPAddress options. This 502 is compatible with the GeneralName requirements in [PKIXPROF] (mainly 503 in section 4.2.1.6). Implementations SHOULD also support the SRVName, 504 as defined in [X509-SRV]. 506 Conforming implementations MUST NOT use the x400Address, 507 ediPartyName, or registeredID options. 509 Conforming implementations MAY use the otherName option to convey 510 name forms defined in Internet Standards. For example, Kerberos 511 [KRB] format names can be encoded into the otherName, using a 512 Kerberos 5 principal name OID and a SEQUENCE of the Realm and the 513 PrincipalName. 515 4.2.1. Version 517 The version field MUST have the value of v2. That is, the version 518 field is present in the DER encoding. 520 Note: This version (v2) is not backwards compatible with the previous 521 attribute certificate definition (v1) from the 1997 X.509 standard 522 [X.509-1997], but is compatible with the v2 definition from X.509 523 (2000) [X.509-2000]. 525 4.2.2. Holder 527 The Holder field is a SEQUENCE allowing three different (optional) 528 syntaxes: baseCertificateID, entityName and objectDigestInfo. Where 529 only one option is present, the meaning of the Holder field is clear. 531 However, where more than one option is used, there is a potential for 532 confusion as to which option is "normative", which is a "hint" etc. 533 Since the correct position is not clear from [X.509-2000], this 534 specification RECOMMENDS that only one of the options be used in any 535 given AC. 537 For any environment where the AC is passed in an authenticated 538 message or session and where the authentication is based on the use 539 of an X.509 PKC, the holder field SHOULD use the baseCertificateID. 541 With the baseCertificateID option, the holder's PKC serialNumber and 542 issuer MUST be identical to the AC holder field. The PKC issuer MUST 543 have a non-empty distinguished name which is to be present as the 544 single value of the holder.baseCertificateID.issuer construct in the 545 directoryName field. The AC holder.baseCertificateID.issuerUID field 546 MUST only be used if the holder's PKC contains an issuerUniqueID 547 field. If both the AC holder.baseCertificateID.issuerUID and the PKC 548 issuerUniqueID fields are present, the same value MUST be present in 549 both fields. Thus, the baseCertificateID is only usable with PKC 550 profiles (like [PKIXPROF]) which mandate that the PKC issuer field 551 contain a non-empty distinguished name value. 553 Note: An empty distinguished name is a distinguished name where the 554 SEQUENCE OF relative distinguished names is of zero length. In a DER 555 encoding, this has the value '3000'H. 557 If the holder field uses the entityName option and the underlying 558 authentication is based on a PKC, the entityName MUST be the same as 559 the PKC subject field or one of the values of the PKC subjectAltName 560 field extension (if present). Note that [PKIXPROF] mandates that the 561 subjectAltName extension be present if the PKC subject is an empty 562 distinguished name. See the security considerations section which 563 mentions some name collision problems that may arise when using the 564 entityName option. 566 In any other case where the holder field uses the entityName option, 567 only one name SHOULD be present. 569 Implementations conforming to this profile are not required to 570 support the use of the objectDigest field. However, section 7.3 571 specifies how this optional feature MAY be used. 573 Any protocol conforming to this profile SHOULD specify which AC 574 holder option is to be used and how this fits with the supported 575 authentication schemes defined in that protocol. 577 4.2.3. Issuer 579 ACs conforming to this profile MUST use the v2Form choice, which MUST 580 contain one and only one GeneralName in the issuerName, which MUST 581 contain a non-empty distinguished name in the directoryName field. 582 This means that all AC issuers MUST have non-empty distinguished 583 names. ACs conforming to this profile MUST omit the 584 baseCertificateID and objectDigestInfo fields. 586 Part of the reason for the use of the v2Form containing only an 587 issuerName is that it means that the AC issuer does not have to know 588 which PKC the AC verifier will use for it (the AC issuer). Using the 589 baseCertificateID field to reference the AC issuer would mean that 590 the AC verifier would have to trust the PKC that the AC issuer chose 591 (for itself) at AC creation time. 593 4.2.4. Signature 595 Contains the algorithm identifier used to validate the AC signature. 597 This MUST be one of the signing algorithms defined in [PKIXALGS] or 598 defined in any IETF-approved update to [PKIXALGS]. Conforming 599 implementations MUST honor all MUST/SHOULD/MAY signing algorithm 600 statements specified in [PKIXALGS] or IETF-approved updates to 601 [PKIXALGS]. 603 4.2.5. Serial Number 605 For any conforming AC, the issuer/serialNumber pair MUST form a 606 unique combination, even if ACs are very short-lived. 608 AC issuers MUST force the serialNumber to be a positive integer, that 609 is, the sign bit in the DER encoding of the INTEGER value MUST be 610 zero - this can be done by adding a leading (leftmost) '00'H octet if 611 necessary. This removes a potential ambiguity in mapping between a 612 string of octets and an integer value. 614 Given the uniqueness and timing requirements above, serial numbers 615 can be expected to contain long integers. AC users MUST be able to 616 handle serialNumber values longer than 4 octets. Conformant ACs MUST 617 NOT contain serialNumber values longer than 20 octets. 619 There is no requirement that the serial numbers used by any AC issuer 620 follow any particular ordering. In particular, they need not be 621 monotonically increasing with time. Each AC issuer MUST ensure that 622 each AC that it issues contains a unique serial number. 624 4.2.6. Validity Period 626 The attrCertValidityPeriod (a.k.a. validity) field specifies the 627 period for which the AC issuer certifies that the binding between the 628 holder and the attributes fields will be valid. 630 The generalized time type, GeneralizedTime, is a standard ASN.1 type 631 for variable precision representation of time. The GeneralizedTime 632 field can optionally include a representation of the time 633 differential between the local time zone and Greenwich Mean Time. 635 For the purposes of this profile, GeneralizedTime values MUST be 636 expressed in Coordinated universal time (UTC) (also known as 637 Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times 638 are YYYYMMDDHHMMSSZ), even when the number of seconds is zero. 639 GeneralizedTime values MUST NOT include fractional seconds. 641 (Note: this is the same as specified in [PKIXPROF], section 642 4.1.2.5.2.) 644 AC users MUST be able to handle an AC which, at the time of 645 processing, has parts of its validity period or all its validity 646 period in the past or in the future (a post-dated AC). This is valid 647 for some applications, such as backup. 649 4.2.7. Attributes 651 The attributes field gives information about the AC holder. When the 652 AC is used for authorization, this will often contain a set of 653 privileges. 655 The attributes field contains a SEQUENCE OF Attribute. Each 656 Attribute contains the type of the attribute and a SET OF values. 657 For a given AC, each AttributeType OBJECT IDENTIFIER in the sequence 658 MUST be unique. That is, only one instance of each attribute can 659 occur in a single AC, but each instance can be multi-valued. 661 AC users MUST be able to handle multiple values for all attribute 662 types. 664 An AC MUST contain at least one attribute. That is, the SEQUENCE OF 665 Attributes MUST NOT be of zero length. 667 Some standard attribute types are defined in section 4.4. 669 4.2.8. Issuer Unique Identifier 671 This field MUST NOT be used unless it is also used in the AC issuer's 672 PKC, in which case it MUST be used. Note that [PKIXPROF] states that 673 this field SHOULD NOT be used by conforming CAs, but that 674 applications SHOULD be able to parse PKCs containing the field. 676 4.2.9. Extensions 678 The extensions field generally gives information about the AC as 679 opposed to information about the AC holder. 681 An AC that has no extensions conforms to the profile; however, 682 section 4.3 defines the extensions that MAY be used with this 683 profile, and whether or not they may be marked critical. If any 684 other critical extension is used, the AC does not conform to this 685 profile. However, if any other non-critical extension is used, the 686 AC does conform to this profile. 688 The extensions defined for ACs provide methods for associating 689 additional attributes with holders. This profile also allows 690 communities to define private extensions to carry information unique 691 to those communities. Each extension in an AC may be designated as 692 critical or non-critical. An AC using system MUST reject an AC if it 693 encounters a critical extension it does not recognize; however, a 694 non-critical extension may be ignored if it is not recognized. 695 Section 4.3 presents recommended extensions used within Internet ACs 696 and standard locations for information. Communities may elect to use 697 additional extensions; however, caution should be exercised in 698 adopting any critical extensions in ACs which might prevent use in a 699 general context. 701 4.3. Extensions 703 4.3.1. Audit Identity 705 In some circumstances, it is required (e.g. by data protection/data 706 privacy legislation) that audit trails not contain records which 707 directly identify individuals. This circumstance may make the use of 708 the AC holder field unsuitable for use in audit trails. 710 To allow for such cases, an AC MAY contain an audit identity 711 extension. Ideally it SHOULD be infeasible to derive the AC holder's 712 identity from the audit identity value without the cooperation of the 713 AC issuer. 715 The value of the audit identity, along with the AC issuer/serial, 716 SHOULD then be used for audit/logging purposes. If the value of the 717 audit identity is suitably chosen, a server/service administrator can 718 use audit trails to track the behavior of an AC holder without being 719 able to identify the AC holder. 721 The server/service administrator in combination with the AC issuer 722 MUST be able to identify the AC holder in cases where misbehavior is 723 detected. This means that the AC issuer MUST be able to determine 724 the actual identity of the AC holder from the audit identity. 726 Of course, auditing could be based on the AC issuer/serial pair; 727 however, this method does not allow tracking of the same AC holder 728 with multiple ACs. Thus, an audit identity is only useful if it 729 lasts for longer than the typical AC lifetime. Auditing could also 730 be based on the AC holder's PKC issuer/serial; however, this will 731 often allow the server/service administrator to identify the AC 732 holder. 734 As the AC verifier might otherwise use the AC holder or some other 735 identifying value for audit purposes, this extension MUST be critical 736 when used. 738 Protocols that use ACs will often expose the identity of the AC 739 holder in the bits on-the-wire. In such cases, an opaque audit 740 identity does not make use of the AC anonymous; it simply ensures 741 that the ensuing audit trails do not contain identifying information. 743 The value of an audit identity MUST be longer than zero octets. The 744 value of an audit identity MUST NOT be longer than 20 octets. 746 name id-pe-ac-auditIdentity 747 OID { id-pe 4 } 748 syntax OCTET STRING 749 criticality MUST be TRUE 751 4.3.2. AC Targeting 753 To target an AC, the target information extension, imported from 754 [X.509-2000], MAY be used to specify a number of servers/services. 755 The intent is that the AC SHOULD only be usable at the specified 756 servers/services. An (honest) AC verifier who is not amongst the 757 named servers/services MUST reject the AC. 759 If this extension is not present, the AC is not targeted and may be 760 accepted by any server. 762 In this profile, the targeting information simply consists of a list 763 of named targets or groups. 765 The following syntax is used to represent the targeting information: 767 Targets ::= SEQUENCE OF Target 769 Target ::= CHOICE { 770 targetName [0] GeneralName, 771 targetGroup [1] GeneralName, 772 targetCert [2] TargetCert 773 } 775 TargetCert ::= SEQUENCE { 776 targetCertificate IssuerSerial, 777 targetName GeneralName OPTIONAL, 778 certDigestInfo ObjectDigestInfo OPTIONAL 779 } 781 The targetCert CHOICE within the Target structure is only present to 782 allow future compatibility with [X.509-2000] and MUST NOT be used. 784 The targets check passes if the current server (recipient) is one of 785 the targetName fields in the Targets SEQUENCE, or if the current 786 server is a member of one of the targetGroup fields in the Targets 787 SEQUENCE. In this case, the current server is said to "match" the 788 targeting extension. 790 How the membership of a target within a targetGroup is determined is 791 not defined here. It is assumed that any given target "knows" the 792 names of the targetGroups to which it belongs or can otherwise 793 determine its membership. For example, the targetGroup specifies a 794 DNS domain, and the AC verifier knows the DNS domain to which it 795 belongs. For another example, the targetGroup specifies "PRINTERS", 796 and the AC verifier knows whether or not it is a printer or print 797 server. 799 Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF 800 Targets". Conforming AC issuer implementations MUST only produce one 801 "Targets" element. Conforming AC users MUST be able to accept a 802 "SEQUENCE OF Targets". If more than one Targets element is found in 803 an AC, the extension MUST be treated as if all Target elements had 804 been found within one Targets element. 806 name id-ce-targetInformation 807 OID { id-ce 55 } 808 syntax SEQUENCE OF Targets 809 criticality MUST be TRUE 811 4.3.3. Authority Key Identifier 813 The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY 814 be used to assist the AC verifier in checking the signature of the 815 AC. The [PKIXPROF] description should be read as if "CA" meant "AC 816 issuer". As with PKCs, this extension SHOULD be included in ACs. 818 Note: An AC, where the issuer field used the baseCertificateID 819 CHOICE, would not need an authorityKeyIdentifier extension, as it is 820 explicitly linked to the key in the referred certificate. However, 821 as this profile states (in section 4.2.3), ACs MUST use the v2Form 822 with issuerName CHOICE, this duplication does not arise. 824 name id-ce-authorityKeyIdentifier 825 OID { id-ce 35 } 826 syntax AuthorityKeyIdentifier 827 criticality MUST be FALSE 829 4.3.4. Authority Information Access 831 The authorityInfoAccess extension, as defined in [PKIXPROF], MAY be 832 used to assist the AC verifier in checking the revocation status of 833 the AC. Support for the id-ad-caIssuers accessMethod is OPTIONAL by 834 this profile since AC chains are not expected. 836 The following accessMethod is used to indicate that revocation status 837 checking is provided for this AC, using the OCSP protocol defined in 838 [OCSP]: 840 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 842 The accessLocation MUST contain a URI, and the URI MUST contain an 843 HTTP URL [HTTP-URL] that specifies the location of an OCSP responder. 844 The AC issuer MUST, of course, maintain an OCSP responder at this 845 location. 847 name id-ce-authorityInfoAccess 848 OID { id-pe 1 } 849 syntax AuthorityInfoAccessSyntax 850 criticality MUST be FALSE 852 4.3.5. CRL Distribution Points 854 The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY 855 be used to assist the AC verifier in checking the revocation status 856 of the AC. See section 6 for details on revocation. 858 If the crlDistributionPoints extension is present, then exactly one 859 distribution point MUST be present. The crlDistributionPoints 860 extension MUST use the DistributionPointName option, which MUST 861 contain a fullName, which MUST contain a single name form. That name 862 MUST contain either a distinguished name or a URI. The URI MUST be 863 either an HTTP URL [HTTP-URL] or an LDAP URL [LDAP-URL]. 865 name id-ce-cRLDistributionPoints 866 OID { id-ce 31 } 867 syntax CRLDistributionPoints 868 criticality MUST be FALSE 870 4.3.6. No Revocation Available 872 The noRevAvail extension, defined in [X.509-2000], allows an AC 873 issuer to indicate that no revocation information will be made 874 available for this AC. 876 This extension MUST be non-critical. An AC verifier that does not 877 understand this extension might be able to find a revocation list 878 from the AC issuer, but the revocation list will never include an 879 entry for the AC. 881 name id-ce-noRevAvail 882 OID { id-ce 56 } 883 syntax NULL (i.e. '0500'H is the DER encoding) 884 criticality MUST be FALSE 886 4.4. Attribute Types 888 Some of the attribute types defined below make use of the 889 IetfAttrSyntax type, also defined below. The reasons for using this 890 type are: 892 1. It allows a separation between the AC issuer and the attribute 893 policy authority. This is useful for situations where a single 894 policy authority (e.g. an organization) allocates attribute 895 values, but where multiple AC issuers are deployed for performance 896 or other reasons. 898 2. The syntaxes allowed for values are restricted to OCTET STRING, 899 OBJECT IDENTIFIER, and UTF8String, which significantly reduces the 900 complexity associated with matching more general syntaxes. All 901 multi-valued attributes using this syntax are restricted so that 902 each value MUST use the same choice of value syntax. For example, 903 AC issuers must not use one value with an oid and a second value 904 with a string. 906 IetfAttrSyntax ::= SEQUENCE { 907 policyAuthority [0] GeneralNames OPTIONAL, 908 values SEQUENCE OF CHOICE { 909 octets OCTET STRING, 910 oid OBJECT IDENTIFIER, 911 string UTF8String 912 } 913 } 915 In the descriptions below, each attribute type is either tagged 916 "Multiple Allowed" or "One Attribute value only; multiple values 917 within the IetfAttrSyntax". This refers to the SET OF 918 AttributeValues; the AttributeType still only occurs once, as 919 specified in section 4.2.7. 921 4.4.1. Service Authentication Information 923 The SvceAuthInfo attribute identifies the AC holder to the 924 server/service by a name, and the attribute MAY include optional 925 service specific authentication information. Typically this will 926 contain a username/password pair for a "legacy" application. 928 This attribute provides information that can be presented by the AC 929 verifier to be interpreted and authenticated by a separate 930 application within the target system. Note that this is a different 931 use to that intended for the accessIdentity attribute in 4.4.2 below. 933 This attribute type will typically be encrypted when the authInfo 934 field contains sensitive information, such as a password (see Section 935 7.1). 937 name id-aca-authenticationInfo 938 OID { id-aca 1 } 939 Syntax SvceAuthInfo 940 values: Multiple allowed 942 SvceAuthInfo ::= SEQUENCE { 943 service GeneralName, 944 ident GeneralName, 945 authInfo OCTET STRING OPTIONAL 946 } 948 4.4.2. Access Identity 950 The accessIdentity attribute identifies the AC holder to the 951 server/service. For this attribute the authInfo field MUST NOT be 952 present. 954 This attribute is intended to be used to provide information about 955 the AC holder, that can be used by the AC verifier (or a larger 956 system of which the AC verifier is a component) to authorize the 957 actions of the AC holder within the AC verifier's system. Note that 958 this is a different use to that intended for the svceAuthInfo 959 attribute described in 4.4.1 above. 961 name id-aca-accessIdentity 962 OID { id-aca 2 } 963 syntax SvceAuthInfo 964 values: Multiple allowed 966 4.4.3. Charging Identity 968 The chargingIdentity attribute identifies the AC holder for charging 969 purposes. In general, the charging identity will be different from 970 other identities of the holder. For example, the holder's company 971 may be charged for service. 973 name id-aca-chargingIdentity 974 OID { id-aca 3 } 975 syntax IetfAttrSyntax 976 values: One Attribute value only; multiple values within the 977 IetfAttrSyntax 979 4.4.4. Group 981 The group attribute carries information about group memberships of 982 the AC holder. 984 name id-aca-group 985 OID { id-aca 4 } 986 syntax IetfAttrSyntax 987 values: One Attribute value only; multiple values within the 988 IetfAttrSyntax 990 4.4.5. Role 992 The role attribute, specified in [X.509-2000], carries information 993 about role allocations of the AC holder. 995 The syntax used for this attribute is: 997 RoleSyntax ::= SEQUENCE { 998 roleAuthority [0] GeneralNames OPTIONAL, 999 roleName [1] GeneralName 1000 } 1002 The roleAuthority field MAY be used to specify the issuing authority 1003 for the role specification certificate. There is no requirement that 1004 a role specification certificate necessarily exists for the 1005 roleAuthority. This differs from [X.500-2000], where the 1006 roleAuthority field is assumed to name the issuer of a role 1007 specification certificate. For example, to distinguish the 1008 administrator role as defined by "Baltimore" from that defined by 1009 "SPYRUS", one could put the value "urn:administrator" in the roleName 1010 field and the value "Baltimore" or "SPYRUS" in the roleAuthority 1011 field. 1013 The roleName field MUST be present, and roleName MUST use the 1014 uniformResourceIdentifier CHOICE of the GeneralName. 1016 name id-at-role 1017 OID { id-at 72 } 1018 syntax RoleSyntax 1019 values: Multiple allowed 1021 4.4.6. Clearance 1023 The clearance attribute, specified in [X.501-1993], carries clearance 1024 (associated with security labeling) information about the AC holder. 1026 The policyId field is used to identify the security policy to which 1027 the clearance relates. The policyId indicates the semantics of the 1028 classList and securityCategories fields. 1030 This specification includes the classList field exactly as it is 1031 specified in [X.501-1993]. Additional security classification 1032 values, and their position in the classification hierarchy, may be 1033 defined by a security policy as a local matter or by bilateral 1034 agreement. The basic security classification hierarchy is, in 1035 ascending order: unmarked, unclassified, restricted, confidential, 1036 secret, and top-secret. 1038 An organization can develop its own security policy that defines 1039 security classification values and their meanings. However, the BIT 1040 STRING positions 0 through 5 are reserved for the basic security 1041 classification hierarchy. 1043 If present, the SecurityCategory field provides further authorization 1044 information. The security policy identified by the policyId field 1045 indicates the syntaxes that are allowed to be present in the 1046 securityCategories SET. An OBJECT IDENTIFIER identifies each of the 1047 allowed syntaxes. When one of these syntaxes is present in the 1048 securityCategories SET, the OBJECT IDENTIFIER associated with that 1049 syntax is carried in the SecurityCategory.type field. 1051 The object identifier for the clearance attribute from [RFC3281] is: 1053 id-at-clearance OBJECT IDENTIFIER ::= { 1054 joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5) 1055 clearance (55) } 1057 The associated syntax was originally (and erroneously) defined in 1058 [RFC3281] as: 1060 Clearance ::= SEQUENCE { 1061 policyId [0] OBJECT IDENTIFIER, 1062 classList [1] ClassList DEFAULT {unclassified}, 1063 securityCategories [2] SET OF SecurityCategory OPTIONAL 1064 } 1066 But, it was later corrected (to restore conformance with X.509) to: 1068 Clearance ::= SEQUENCE { 1069 policyId OBJECT IDENTIFIER, 1070 classList ClassList DEFAULT {unclassified}, 1071 securityCategories SET OF SecurityCategory OPTIONAL 1072 } 1074 The object identifier for the clearance attribute from [X.509-1997] 1075 is: 1077 id-at-clearance OBJECT IDENTIFIER ::= { 1078 joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) } 1080 The associated syntax is as follows: 1082 Clearance ::= SEQUENCE { 1083 policyId OBJECT IDENTIFIER, 1084 classList ClassList DEFAULT {unclassified}, 1085 securityCategories SET OF SecurityCategory OPTIONAL 1086 } 1088 Implementations MUST support the clearance attribute as defined in 1089 [X.501-1997]. Implementations SHOULD support decoding the clearance 1090 syntax from [RFC3281] and the errata against it (See Appendix C). 1091 Implementations MUST NOT output the clearance attribute as defined in 1092 [RFC3281]. 1094 ClassList ::= BIT STRING { 1095 unmarked (0), 1096 unclassified (1), 1097 restricted (2), 1098 confidential (3), 1099 secret (4), 1100 topSecret (5) 1101 } 1103 SecurityCategory ::= SEQUENCE { 1104 type [0] OBJECT IDENTIFIER, 1105 value [1] EXPLICIT ANY DEFINED BY type 1106 } 1108 -- Note that in [RFC3281] the SecurityCategory syntax was as 1109 -- follows: 1110 -- 1111 -- SecurityCategory ::= SEQUENCE { 1112 -- type [0] IMPLICIT OBJECT IDENTIFIER, 1113 -- value [1] ANY DEFINED BY type 1114 -- } 1115 -- 1116 -- The removal of the IMPLICIT from the type line and the 1117 -- addition of the EXPLICIT to the value line result in 1118 -- no changes to the encodings. 1120 -- This is the same as the original syntax which was defined 1121 -- using the MACRO construct, as follows: 1122 -- SecurityCategory ::= SEQUENCE { 1123 -- type [0] IMPLICIT SECURITY-CATEGORY, 1124 -- value [1] ANY DEFINED BY type 1125 -- } 1126 -- 1127 -- SECURITY-CATEGORY MACRO ::= 1128 -- BEGIN 1129 -- TYPE NOTATION ::= type | empty 1130 -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 1131 -- END 1133 name { id-at-clearance } 1134 OID { joint-iso-ccitt(2) ds(5) attribute-type (4) 1135 clearance (55) } 1136 syntax Clearance -- imported from [X.501-1997] 1137 values Multiple allowed 1139 4.5. Profile of AC issuer's PKC 1141 The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage 1142 extension in the PKC MUST NOT explicitly indicate that the AC 1143 issuer's public key cannot be used to validate a digital signature. 1144 In order to avoid confusion regarding serial numbers and revocations, 1145 an AC issuer MUST NOT also be a PKC Issuer. That is, an AC issuer 1146 cannot be a CA as well. So, the AC issuer's PKC MUST NOT have a 1147 basicConstraints extension with the cA BOOLEAN set to TRUE. 1149 5. Attribute Certificate Validation 1151 This section describes a basic set of rules that all valid ACs MUST 1152 satisfy. Some additional checks are also described which AC 1153 verifiers MAY choose to implement. 1155 To be valid an AC MUST satisfy all of the following: 1157 1. Where the holder uses a PKC to authenticate to the AC verifier, 1158 the AC holder's PKC MUST be found, and the entire certification 1159 path of that PKC MUST be verified in accordance with [PKIXPROF]. 1160 As noted in the security considerations section, if some other 1161 authentication scheme is used, AC verifiers need to be very 1162 careful mapping the identities (authenticated identity, holder 1163 field) involved. 1165 2. The AC signature must be cryptographically correct, and the AC 1166 issuer's entire PKC certification path MUST be verified in 1167 accordance with [PKIXPROF]. 1169 3. The AC issuer's PKC MUST also conform to the profile specified in 1170 section 4.5 above. 1172 4. The AC issuer MUST be directly trusted as an AC issuer (by 1173 configuration or otherwise). 1175 5. The time for which the AC is being evaluated MUST be within the AC 1176 validity. If the evaluation time is equal to either notBeforeTime 1177 or notAfterTime, then the AC is timely and this check succeeds. 1178 Note that in some applications, the evaluation time MAY not be the 1179 same as the current time. 1181 6. The AC targeting check MUST pass as specified in section 4.3.2. 1183 7. If the AC contains an unsupported critical extension, the AC MUST 1184 be rejected. 1186 Support for an extension in this context means: 1188 1. The AC verifier MUST be able to parse the extension value. 1190 2. Where the extension value causes the AC to be rejected, the 1191 AC verifier MUST reject the AC. 1193 Additional Checks: 1195 1. The AC MAY be rejected on the basis of further AC verifier 1196 configuration. For example, an AC verifier may be configured to 1197 reject ACs which contain or lack certain attributes. 1199 2. If the AC verifier provides an interface that allows applications 1200 to query the contents of the AC, then the AC verifier MAY filter 1201 the attributes from the AC on the basis of configured information. 1202 For example, an AC verifier might be configured not to return 1203 certain attributes to certain servers. 1205 6. Revocation 1207 In many environments, the validity period of an AC is less than the 1208 time required to issue and distribute revocation information. 1209 Therefore, short-lived ACs typically do not require revocation 1210 support. However, long-lived ACs and environments where ACs enable 1211 high value transactions MAY require revocation support. 1213 Two revocation schemes are defined, and the AC issuer should elect 1214 the one that is best suited to the environment in which the AC will 1215 be employed. 1217 "Never revoke" scheme: 1219 ACs may be marked so that the relying party understands that no 1220 revocation status information will be made available. The 1221 noRevAvail extension is defined in section 4.3.6, and the 1222 noRevAvail extension MUST be present in the AC to indicate use of 1223 this scheme. 1225 Where no noRevAvail is present, the AC issuer is implicitly stating 1226 that revocation status checks are supported, and some revocation 1227 method MUST be provided to allow AC verifiers to establish the 1228 revocation status of the AC. 1230 "Pointer in AC" scheme: 1232 ACs may "point" to sources of revocation status information, using 1233 either an authorityInfoAccess extension or a crlDistributionPoints 1234 extension within the AC. 1236 For AC users, the "never revoke" scheme MUST be supported, and the 1237 "pointer in AC" scheme SHOULD be supported. If only the "never 1238 revoke" scheme is supported, then all ACs that do not contain a 1239 noRevAvail extension, MUST be rejected. 1241 For AC issuers, the "never revoke" scheme MUST be supported. If all 1242 ACs that will ever be issued by that AC issuer contain a noRevAvail 1243 extension, the "pointer in AC" scheme need not be supported. If any 1244 AC can be issued that does not contain the noRevAvail extension, the 1245 "pointer in AC" scheme MUST be supported. 1247 An AC MUST NOT contain both a noRevAvail and a "pointer in AC". 1249 An AC verifier MAY use any source for AC revocation status 1250 information. 1252 7. Optional Features 1254 This section specifies features that MAY be implemented. Conformance 1255 to this profile does NOT require support for these features; however, 1256 if these features are offered, they MUST be offered as described 1257 below. 1259 7.1. Attribute Encryption 1261 Where an AC will be carried in clear within an application protocol 1262 or where an AC contains some sensitive information like a legacy 1263 application username/password, then encryption of AC attributes MAY 1264 be needed. 1266 When a set of attributes is to be encrypted within an AC, the 1267 Cryptographic Message Syntax, EnvelopedData structure [CMS] is used 1268 to carry the ciphertext and associated per-recipient keying 1269 information. 1271 This type of attribute encryption is targeted. Before the AC is 1272 signed, the attributes are encrypted for a set of predetermined 1273 recipients. 1275 Within EnvelopedData, the encapsulatedContentInfo identifies the 1276 content type carried withing the ciphertext. In this case, the 1277 contentType field of encapsulatedContentInfo MUST contain id-ct- 1278 attrCertEncAttrs, which has the following value: 1280 attrCertEncAttrs OBJECT IDENTIFIER ::= { 1281 iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1282 id-smime(16) id-ct(1) 14 } 1284 The ciphertext is included in the AC as the value of an encAttrs 1285 attribute. Only one encAttrs attribute can be present in an AC; 1286 however, the encAttrs attribute MAY be multi-valued, and each of its 1287 values will contain an independent EnvelopedData. 1289 Each value can contain a set of attributes (each possibly a multi- 1290 valued attribute) encrypted for a set of predetermined recipients. 1292 The cleartext that is encrypted has the type: 1294 ACClearAttrs ::= SEQUENCE { 1295 acIssuer GeneralName, 1296 acSerial INTEGER, 1297 attrs SEQUENCE OF Attribute 1298 } 1300 The DER encoding of the ACClearAttrs structure is used as the 1301 encryptedContent field of the EnvelopedData. The DER encoding MUST 1302 be embedded in an OCTET STRING. 1304 The acIssuer and acSerial fields are present to prevent ciphertext 1305 stealing. When an AC verifier has successfully decrypted an 1306 encrypted attribute, it MUST then check that the AC issuer and 1307 serialNumber fields contain the same values. This prevents a 1308 malicious AC issuer from copying ciphertext from another AC (without 1309 knowing its corresponding plaintext). 1311 The procedure for an AC issuer when encrypting attributes is 1312 illustrated by the following (any other procedure that gives the same 1313 result MAY be used): 1315 1. Identify the sets of attributes that are to be encrypted for 1316 each set of recipients. 1317 2. For each attribute set which is to be encrypted: 1318 2.1. Create an EnvelopedData structure for the data for this 1319 set of recipients. 1320 2.2. Encode the ContentInfo containing the EnvelopedData as a 1321 value of the encAttrs attribute. 1322 2.3. Ensure the cleartext attributes are not present in the 1323 to-be-signed AC. 1324 3. Add the encAttrs (with its multiple values) to the AC. 1326 Note that there may be more than one attribute of the same type (the 1327 same OBJECT IDENTIFIER) after decryption. That is, an AC MAY contain 1328 the same attribute type both in clear and in encrypted form (and 1329 indeed several times if the different recipients are associated with 1330 more than one EnvelopedData). For example, an AC could contain a 1331 cleartext clearance attribute saying the holder is cleared to SECRET, 1332 and, in addition, an encrypted clearance attribute whose value is 1333 some higher clearance that's not allowed to be known everywhere. One 1334 approach implementers may choose, would be to merge attribute values 1335 following decryption in order to re- establish the "once only" 1336 constraint. 1338 name id-aca-encAttrs 1339 OID { id-aca 6} 1340 Syntax ContentInfo 1341 values Multiple Allowed 1343 If an AC contains attributes apparently encrypted for the AC 1344 verifier, then the decryption process failure MUST cause the AC to be 1345 rejected. 1347 7.2. Proxying 1349 When a server acts as a client for another server on behalf of the AC 1350 holder, the server MAY need to proxy an AC. Such proxying MAY have 1351 to be done under the AC issuer's control, so that not every AC is 1352 proxiable and so that a given proxiable AC can be proxied in a 1353 targeted fashion. Support for chains of proxies (with more than one 1354 intermediate server) MAY also be required. Note that this does not 1355 involve a chain of ACs. 1357 In order to meet this requirement we define another extension, 1358 ProxyInfo, similar to the targeting extension. 1360 When this extension is present, the AC verifier must check that the 1361 entity from which the AC was received was allowed to send it and that 1362 the AC is allowed to be used by this verifier. 1364 The proxying information consists of a list of proxy information, 1365 each of which is a list of targeting information. If the verifier 1366 and the sender of the AC are both named in the same proxy list, the 1367 AC can then be accepted (the exact rule is given below). 1369 The effect is that the AC holder can send the AC to any valid target 1370 which can then only proxy to targets which are in one of the same 1371 proxy lists as itself. 1373 The following data structure is used to represent the 1374 targeting/proxying information. 1376 ProxyInfo ::= SEQUENCE OF Targets 1378 Targets is explained in Section 4.3.2. As in the case of targeting, 1379 the targetCert CHOICE MUST NOT be used. 1381 A proxy check succeeds if either one of the conditions below is met: 1383 1. The identity of the sender, as established by the underlying 1384 authentication service, matches the holder field of the AC, and 1385 the current server "matches" any one of the proxy sets. Recall 1386 that "matches" is as defined section 4.3.2. 1388 2. The identity of the sender, as established by the underlying 1389 authentication service, "matches" one of the proxy sets (call it 1390 set "A"), and the current server is one of the targetName fields 1391 in the set "A", or the current server is a member of one of the 1392 targetGroup fields in set "A". 1394 When an AC is proxied more than once, a number of targets will be on 1395 the path from the original client, which is normally, but not always, 1396 the AC holder. In such cases, prevention of AC "stealing" requires 1397 that the AC verifier MUST check that all targets on the path are 1398 members of the same proxy set. It is the responsibility of the AC- 1399 using protocol to ensure that a trustworthy list of targets on the 1400 path is available to the AC verifier. 1402 name id-pe-ac-proxying 1403 OID { id-pe 10 } 1404 syntax ProxyInfo 1405 criticality MUST be TRUE 1407 7.3. Use of ObjectDigestInfo 1409 In some environments, it may be required that the AC is not linked 1410 either to an identity (via entityName) or to a PKC (via 1411 baseCertificateID). The objectDigestInfo CHOICE in the holder field 1412 allows support for this requirement. 1414 If the holder is identified with the objectDigestInfo field, then the 1415 AC version field MUST contain v2 (the integer 1). 1417 The idea is to link the AC to an object by placing a hash of that 1418 object into the holder field of the AC. For example, this allows 1419 production of ACs that are linked to public keys rather than names. 1420 It also allows production of ACs which contain privileges associated 1421 with an executable object such as a Java class. However, this 1422 profile only specifies how to use a hash over a public key or PKC. 1423 That is, conformant ACs MUST NOT use the otherObjectTypes value for 1424 the digestedObjectType. 1426 To link an AC to a public key, the hash must be calculated over the 1427 representation of that public key which would be present in a PKC, 1428 specifically, the input for the hash algorithm MUST be the DER 1429 encoding of a SubjectPublicKeyInfo representation of the key. Note: 1430 This includes the AlgorithmIdentifier as well as the BIT STRING. The 1431 rules given in [PKIXALGS] for encoding keys MUST be followed. In 1432 this case, the digestedObjectType MUST be publicKey and the 1433 otherObjectTypeID field MUST NOT be present. 1435 Note that if the public key value used as input to the hash function 1436 has been extracted from a PKC, it is possible that the 1437 SubjectPublicKeyInfo from that PKC is NOT the value which should be 1438 hashed. This can occur if DSA Dss-parms are inherited as described 1439 in section 2.3.2 of [PKIXALGS]. The correct input for hashing in 1440 this context will include the value of the parameters inherited from 1441 the CA's PKC, and thus may differ from the SubjectPublicKeyInfo 1442 present in the PKC. 1444 Implementations which support this feature MUST be able to handle the 1445 representations of public keys for the algorithms specified in 1446 section 2.3 of [PKIXALGS]. 1448 In order to link an AC to a PKC via a digest, the digest MUST be 1449 calculated over the DER encoding of the entire PKC, including the 1450 signature value. In this case the digestedObjectType MUST be 1451 publicKeyCert and the otherObjectTypeID field MUST NOT be present. 1453 7.4. AA Controls 1455 During AC validation a relying party has to answer the question: is 1456 this AC issuer trusted to issue ACs containing this attribute? The 1457 AAControls PKC extension MAY be used to help answer the question. The 1458 AAControls extension is intended to be used in CA and AC issuer PKCs. 1460 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1462 AAControls ::= SEQUENCE { 1463 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1464 permittedAttrs [0] AttrSpec OPTIONAL, 1465 excludedAttrs [1] AttrSpec OPTIONAL, 1466 permitUnSpecified BOOLEAN DEFAULT TRUE 1467 } 1469 AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER 1471 The AAControls extension is used as follows: 1473 The pathLenConstraint, if present, is interpreted as in [PKIXPROF]. 1474 It restricts the allowed distance between the AA CA (a CA directly 1475 trusted to include AAControls in its PKCs), and the AC issuer. 1477 The permittedAttrs field specifies a list of attribute types that any 1478 AC issuer below this AA CA is allowed to include in ACs. If this 1479 field is not present, it means that no attribute types are explicitly 1480 allowed. 1482 The excludedAttrs field specifies a list of attribute types that no 1483 AC issuer below this AA CA is allowed to include in ACs. If this 1484 field is not present, it means that no attribute types are explicitly 1485 disallowed. 1487 The permitUnSpecified field specifies how to handle attribute types 1488 which are not present in either the permittedAttrs or excludedAttrs 1489 fields. TRUE (the default) means that any unspecified attribute type 1490 is allowed in ACs; FALSE means that no unspecified attribute type is 1491 allowed. 1493 When AAControls are used, the following additional checks on an AA's 1494 PKC chain MUST all succeed for the AC to be valid: 1496 1. Some CA on the AC's certificate path MUST be directly trusted to 1497 issue PKCs which precede the AC issuer in the certification path; 1498 call this CA the "AA CA". 1500 2. All PKCs on the path from the AA CA, down to and including the AC 1501 issuer's PKC, MUST contain an AAControls extension; however, the 1502 PKC of the AA CA need not contain this extension. 1504 3. Only those attributes in the AC which are allowed, according to 1505 all of the AAControls extension values in all of the PKCs from the 1506 AA CA to the AC issuer, may be used for authorization decisions; 1507 all other attributes MUST be ignored. This check MUST be applied 1508 to the list of attributes following attribute decryption, and the 1509 id-aca-encAttrs type MUST also be checked. 1511 name id-pe-aaControls 1512 OID { id-pe 6 } 1513 syntax AAControls 1514 criticality MAY be TRUE 1516 8. Security Considerations 1518 The protection afforded for private keys is a critical factor in 1519 maintaining security. Failure of AC issuers to protect their private 1520 keys will permit an attacker to masquerade as them, potentially 1521 generating false ACs or revocation status. Existence of bogus ACs 1522 and revocation status will undermine confidence in the system. If 1523 the compromise is detected, all ACs issued by the AC issuer MUST be 1524 revoked. Rebuilding after such a compromise will be problematic, so 1525 AC issuers are advised to implement a combination of strong technical 1526 measures (e.g., tamper-resistant cryptographic modules) and 1527 appropriate management procedures (e.g., separation of duties) to 1528 avoid such an incident. 1530 Loss of an AC issuer's private signing key may also be problematic. 1531 The AC issuer would not be able to produce revocation status or 1532 perform AC renewal. AC issuers are advised to maintain secure backup 1533 for signing keys. The security of the key backup procedures is a 1534 critical factor in avoiding key compromise. 1536 The availability and freshness of revocation status will affect the 1537 degree of assurance that should be placed in a long-lived AC. While 1538 long-lived ACs expire naturally, events may occur during its natural 1539 lifetime which negate the binding between the AC holder and the 1540 attributes. If revocation status is untimely or unavailable, the 1541 assurance associated with the binding is clearly reduced. 1543 The binding between an AC holder and attributes cannot be stronger 1544 than the cryptographic module implementation and algorithms used to 1545 generate the signature. Short key lengths or weak hash algorithms 1546 will limit the utility of an AC. AC issuers are encouraged to note 1547 advances in cryptology so they can employ strong cryptographic 1548 techniques. 1550 Inconsistent application of name comparison rules may result in 1551 acceptance of invalid targeted or proxied ACs, or rejection of valid 1552 ones. The X.500 series of specifications defines rules for comparing 1553 distinguished names. These rules require comparison of strings 1554 without regard to case, character set, multi-character white space 1555 substrings, or leading and trailing white space. This specification 1556 and [PKIXPROF] relaxes these requirements, requiring support for 1557 binary comparison at a minimum. 1559 AC issuers MUST encode the distinguished name in the AC 1560 holder.entityName field identically to the distinguished name in the 1561 holder's PKC. If different encodings are used, implementations of 1562 this specification may fail to recognize that the AC and PKC belong 1563 to the same entity. 1565 If an attribute certificate is tied to the holder's PKC using the 1566 baseCertificateID component of the Holder field and the PKI in use 1567 includes a rogue CA with the same issuer name specified in the 1568 baseCertificateID component, this rogue CA could issue a PKC to a 1569 malicious party, using the same issuer name and serial number as the 1570 proper holder's PKC. Then the malicious party could use this PKC in 1571 conjunction with the AC. This scenario SHOULD be avoided by properly 1572 managing and configuring the PKI so that there cannot be two CAs with 1573 the same name. Another alternative is to tie ACs to PKCs using the 1574 publicKeyCert type in the ObjectDigestInfo field. Failing this, AC 1575 verifiers have to establish (using other means) that the potential 1576 collisions cannot actually occur, for example, the Certificte 1577 Practice Statements (CPSs) of the CAs involved may make it clear that 1578 no such name collisions can occur. 1580 Implementers MUST ensure that following validation of an AC, only 1581 attributes that the issuer is trusted to issue are used in 1582 authorization decisions. Other attributes, which MAY be present MUST 1583 be ignored. Given that the AAControls PKC extension is optional to 1584 implement, AC verifiers MUST be provided with this information by 1585 other means. Configuration information is a likely alternative 1586 means. This becomes very important if an AC verifier trusts more 1587 than one AC issuer. 1589 There is often a requirement to map between the authentication 1590 supplied by a particular security protocol (e.g. TLS, S/MIME) and the 1591 AC holder's identity. If the authentication uses PKCs, then this 1592 mapping is straightforward. However, it is envisaged that ACs will 1593 also be used in environments where the holder may be authenticated 1594 using other means. Implementers SHOULD be very careful in mapping 1595 the authenticated identity to the AC holder, especially when the 1596 authenticated identity does not come from a public key certificate as 1597 link between identity and AC may not be as "strong". 1599 9. IANA Considerations 1601 Attributes and attribute certificate extensions are identified by 1602 object identifiers (OIDs). Many of the OIDs used in this document 1603 are copied from X.509 [X.509-2000]. Other OIDs were assigned from an 1604 arc delegated by the IANA to the PKIX working group. No further 1605 action by the IANA is necessary for this document or any anticipated 1606 updates. 1608 10. References 1610 10.1. Normative References 1612 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 3852, 1613 July 2004. 1615 [HTTP-URL] Housley, R., and P. Hoffman, "Internet X.509 Public 1616 Key Infrastructure Operational Protocols: FTP and 1617 HTTP", RFC 2585, May 1999. 1619 [LDAP-URL] Smith, E., and T. Howes, "Lightweight Directory Access 1620 Protocol (LDAP): Uniform Resource Locator", RFC 4516, 1621 June 2006. 1623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1624 Requirement Levels", BCP 14, RFC 2119, March 1997. 1626 [PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and 1627 Identifiers for the Internet X.509 Public Key 1628 Infrastructure Certificate and Certificate Revocation 1629 Lists CRL Profile", RFC 3279, April 2002. 1631 Turner, S., Polk, W., Hously, R., Yiu, K., D. Brown, 1632 "Elliptic Curve Cryptography Subject Public Key 1633 Information", RFC 5480, February 2009. 1635 Schaad, J., Kaliski, B., and R. Housley, "Additional 1636 Algorithms and Identifiers for RSA Cryptography for 1637 use in the Internet X.509 Public Key Infrastructure 1638 Certificate and Certificate Revocation List (CRL) 1639 Profile", RFC 4055, June 2005. 1641 Turner, S., Polk, W., Hously, R., Yiu, K., D. Brown, 1642 "Update for RSAES-OAEP Algorithm Parameters", draft- 1643 ietf-pkix-rfc4055-update-01.txt, work-in-progress. 1645 [PKIXPROF] Cooper, D., Santesson, S., Farrell, S., Boeyen, S. 1646 Housley, R., and W. Polk, "Internet X.509 Public Key 1647 Infrastructure Certificate and Certificate Revocation 1648 List (CRL) Profile", RFC 5280, May 2008. 1650 [X509-SRV] Santesson, S., "Internet X.509 Public Key 1651 Infrastructure Subject Alternative Name for Expression 1652 of Service Name", RFC 4985, August 2007. 1654 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- 1655 1:2002, Information technology - Abstract Syntax 1656 Notation One (ASN.1): Specification of basic 1657 notation. 1659 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825- 1660 1:2002, Information technology - ASN.1 encoding rules: 1661 Specification of Basic Encoding Rules (BER), Canonical 1662 Encoding Rules (CER) and Distinguished Encoding Rules 1663 (DER). 1665 10.2. Informative References 1667 [KRB] Yu, T., Hartman, S., Raeburn, K., and C. Neuman, "The 1668 Kerberos Network Authentication Service (V5)", RFC 1669 4120, July 2005. 1671 [LDAP] Sermersheim, J., "Lightweight Directory Access 1672 Protocol (LDAP): The Protocol", RFC 4511, June 2006. 1674 [OCSP] Myers, M., Ankney, R., Malpani A., Galperin, S., and 1675 C. Adams, "X.509 Internet Public Key Infrastructure 1676 Online Certificate Status Protocol - OCSP", RFC 2560, 1677 June 1999. 1679 [RFC3281] Farrell, S., and R. Housley, "An Internet Attribute 1680 Certificate Profile for Authorization", RFC 3281, 1681 April 2002. 1683 [X.509-1988] CCITT Recommendation X.509: The Directory - 1684 Authentication Framework. 1988. 1686 [X.509-1997] ITU-T Recommendation X.509: The Directory - 1687 Authentication Framework. 1997. 1689 [X.509-2000] ITU-T Recommendation X.509: The Directory - Public-Key 1690 and Attribute Certificate Frameworks. 2000 1692 Appendix A Object Identifiers 1694 This (normative) appendix lists the new object identifiers which are 1695 defined in this specification. Some of these are required only for 1696 support of optional features and are not required for conformance to 1697 this profile. This specification mandates support for OIDs which 1698 have arc elements with values that are less than 2^32, (i.e. they 1699 MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less 1700 than 2^31 (i.e. less than or equal to 2,147,483,647). This allows 1701 each arc element to be represented within a single 32 bit word. 1702 Implementations MUST also support OIDs where the length of the dotted 1703 decimal (see [LDAP], section 4.1.2) string representation can be up 1704 to 100 bytes (inclusive). Implementations MUST be able to handle 1705 OIDs with up to 20 elements (inclusive). AA's SHOULD NOT issue ACs 1706 which contain OIDs that breach these requirements. 1708 The following OIDs are imported from [PKIXPROF]: 1710 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1711 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 1712 id-mod OBJECT IDENTIFIER ::= { id-pkix 0 } 1713 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 1714 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 1715 id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } 1716 id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 } 1718 The following new ASN.1 module OID is defined: 1720 id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 } 1722 The following AC extension OIDs are defined: 1724 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1725 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 } 1726 id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 1728 The following PKC extension OIDs are defined: 1730 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1732 The following attribute OIDs are defined: 1734 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1735 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1736 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1737 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1738 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1739 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1740 id-at-role OBJECT IDENTIFIER ::= { id-at 72 } 1741 id-at-clearance OBJECT IDENTIFIER ::= { 1742 joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) } 1743 id-at-clearance OBJECT IDENTIFIER ::= { 1744 joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5) 1745 clearance (55) } 1747 As noted in Section 4.4.6, there are two OIDs for id-at-clearance. 1749 Appendix B ASN.1 Module 1751 This appendix describes data objects used by conforming PKI 1752 components in an "ASN.1-like" syntax. This syntax is a hybrid of the 1753 1988 and 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented 1754 with 1993 UNIVERSAL Types UniversalString, BMPString, and UTF8String. 1756 The ASN.1 syntax does not permit the inclusion of type statements in 1757 the ASN.1 module, and the 1993 ASN.1 standard does not permit use of 1758 the new UNIVERSAL types in modules using the 1988 syntax. As a 1759 result, this module does not conform to either version of the ASN.1 1760 standard. 1762 This appendix may be converted into 1988 ASN.1 by replacing the 1763 definitions for the UNIVERSAL Types with the 1988 catch-all "ANY". 1765 PKIXAttributeCertificate-2008 { iso(1) identified-organization(3) 1766 dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1767 id-mod-attribute-cert-v2(61) } 1769 DEFINITIONS IMPLICIT TAGS ::= 1770 BEGIN 1772 -- EXPORTS ALL -- 1774 IMPORTS 1776 -- IMPORTed module OIDs MAY change if [PKIXPROF] changes 1777 -- PKIX Certificate Extensions 1779 Attribute, AlgorithmIdentifier, CertificateSerialNumber, 1780 Extensions, UniqueIdentifier, id-pkix, id-pe, id-kp, id-ad, id-at 1781 FROM PKIX1Explicit88 1782 { iso(1) identified-organization(3) dod(6) internet(1) 1783 security(5) mechanisms(5) pkix(7) id-mod(0) 1784 id-pkix1-explicit-88(18) } 1786 GeneralName, GeneralNames, id-ce, AuthorityKeyIdentifier, 1787 AuthorityInfoAccessSyntax, CRLDistributionPoint 1788 FROM PKIX1Implicit88 1789 { iso(1) identified-organization(3) dod(6) internet(1) 1790 security(5) mechanisms(5) pkix(7) id-mod(0) 1791 id-pkix1-implicit-88(19) } 1793 ContentInfo 1794 FROM CryptographicMessageSyntax2004 1795 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1796 smime(16) modules(0) cms-2004(24) } 1798 ; 1800 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1802 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1804 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 } 1806 id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 1808 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1810 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1812 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1814 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1816 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1817 -- { id-aca 5 } is reserved 1819 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1821 id-at-role OBJECT IDENTIFIER ::= { id-at 72} 1823 id-at-clearance OBJECT IDENTIFIER ::= { 1824 joint-iso-ccitt(2) ds(5) attributeType(4) clearance (55) } 1826 -- Uncomment the following declaration and comment the above line if 1827 -- using the id-at-clearance attribute as defined in [RFC3281] 1829 -- id-at-clearance OBJECT IDENTIFIER ::= { 1830 -- joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5) 1831 -- clearance (55) } 1833 -- Uncomment this if using a 1988 level ASN.1 compiler 1835 -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 1837 AttributeCertificate ::= SEQUENCE { 1838 acinfo AttributeCertificateInfo, 1839 signatureAlgorithm AlgorithmIdentifier, 1840 signatureValue BIT STRING 1841 } 1843 AttributeCertificateInfo ::= SEQUENCE { 1844 version AttCertVersion, -- version is v2 1845 holder Holder, 1846 issuer AttCertIssuer, 1847 signature AlgorithmIdentifier, 1848 serialNumber CertificateSerialNumber, 1849 attrCertValidityPeriod AttCertValidityPeriod, 1850 attributes SEQUENCE OF Attribute, 1851 issuerUniqueID UniqueIdentifier OPTIONAL, 1852 extensions Extensions OPTIONAL 1853 } 1855 AttCertVersion ::= INTEGER { v2(1) } 1856 Holder ::= SEQUENCE { 1857 baseCertificateID [0] IssuerSerial OPTIONAL, 1858 -- the issuer and serial number of 1859 -- the holder's Public Key Certificate 1860 entityName [1] GeneralNames OPTIONAL, 1861 -- the name of the claimant or role 1862 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 1863 -- used to directly authenticate the 1864 -- holder, for example, an executable 1865 } 1867 ObjectDigestInfo ::= SEQUENCE { 1868 digestedObjectType ENUMERATED { 1869 publicKey (0), 1870 publicKeyCert (1), 1871 otherObjectTypes (2) }, 1872 -- otherObjectTypes MUST NOT 1873 -- MUST NOT be used in this profile 1874 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 1875 digestAlgorithm AlgorithmIdentifier, 1876 objectDigest BIT STRING 1877 } 1879 AttCertIssuer ::= CHOICE { 1880 v1Form GeneralNames, -- MUST NOT be used in this 1881 -- profile 1882 v2Form [0] V2Form -- v2 only 1883 } 1885 V2Form ::= SEQUENCE { 1886 issuerName GeneralNames OPTIONAL, 1887 baseCertificateID [0] IssuerSerial OPTIONAL, 1888 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 1889 -- issuerName MUST be present in this profile 1890 -- baseCertificateID and objectDigestInfo MUST 1891 -- NOT be present in this profile 1892 } 1894 IssuerSerial ::= SEQUENCE { 1895 issuer GeneralNames, 1896 serial CertificateSerialNumber, 1897 issuerUID UniqueIdentifier OPTIONAL 1898 } 1899 AttCertValidityPeriod ::= SEQUENCE { 1900 notBeforeTime GeneralizedTime, 1901 notAfterTime GeneralizedTime 1902 } 1904 Targets ::= SEQUENCE OF Target 1906 Target ::= CHOICE { 1907 targetName [0] GeneralName, 1908 targetGroup [1] GeneralName, 1909 targetCert [2] TargetCert 1910 } 1912 TargetCert ::= SEQUENCE { 1913 targetCertificate IssuerSerial, 1914 targetName GeneralName OPTIONAL, 1915 certDigestInfo ObjectDigestInfo OPTIONAL 1916 } 1918 IetfAttrSyntax ::= SEQUENCE { 1919 policyAuthority [0] GeneralNames OPTIONAL, 1920 values SEQUENCE OF CHOICE { 1921 octets OCTET STRING, 1922 oid OBJECT IDENTIFIER, 1923 string UTF8String 1924 } 1925 } 1927 SvceAuthInfo ::= SEQUENCE { 1928 service GeneralName, 1929 ident GeneralName, 1930 authInfo OCTET STRING OPTIONAL 1931 } 1933 RoleSyntax ::= SEQUENCE { 1934 roleAuthority [0] GeneralNames OPTIONAL, 1935 roleName [1] GeneralName 1936 } 1938 Clearance ::= SEQUENCE { 1939 policyId OBJECT IDENTIFIER, 1940 classList ClassList DEFAULT {unclassified}, 1941 securityCategories SET OF SecurityCategory OPTIONAL 1942 } 1944 -- Uncomment the following lines to support deprecated clearance 1945 -- syntax and comment out previous Clearance. 1947 -- Clearance ::= SEQUENCE { 1948 -- policyId [0] OBJECT IDENTIFIER, 1949 -- classList [1] ClassList DEFAULT {unclassified}, 1950 -- securityCategories [2] SET OF SecurityCategory OPTIONAL 1951 -- } 1953 ClassList ::= BIT STRING { 1954 unmarked (0), 1955 unclassified (1), 1956 restricted (2), 1957 confidential (3), 1958 secret (4), 1959 topSecret (5) 1960 } 1962 SecurityCategory ::= SEQUENCE { 1963 type [0] OBJECT IDENTIFIER, 1964 value [1] EXPLICIT ANY DEFINED BY type 1965 } 1967 -- Note that in [RFC3281] the syntax for SecurityCategory was 1968 -- as follows: 1969 -- 1970 -- SecurityCategory ::= SEQUENCE { 1971 -- type [0] IMPLICIT OBJECT IDENTIFIER, 1972 -- value [1] ANY DEFINED BY type 1973 -- } 1974 -- 1975 -- The removal of the IMPLICIT from the type line and the 1976 -- addition of the EXPLICIT to the value line result in 1977 -- no changes to the encoding. 1979 AAControls ::= SEQUENCE { 1980 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1981 permittedAttrs [0] AttrSpec OPTIONAL, 1982 excludedAttrs [1] AttrSpec OPTIONAL, 1983 permitUnSpecified BOOLEAN DEFAULT TRUE 1984 } 1986 AttrSpec ::= SEQUENCE OF OBJECT IDENTIFIER 1987 ACClearAttrs ::= SEQUENCE { 1988 acIssuer GeneralName, 1989 acSerial INTEGER, 1990 attrs SEQUENCE OF Attribute 1991 } 1993 ProxyInfo ::= SEQUENCE OF Targets 1995 END 1997 Appendix C Errata Submitted to RFC 3281 1999 The following is the errata submitted against RFC3281. 2001 Status: Verified 2003 Type: Technical 2005 Reported By: Stephen Farrell 2007 Date Reported: 2003-03-07 2009 Section 4.4.6 says: 2011 Clearance ::= SEQUENCE { 2012 policyId [0] OBJECT IDENTIFIER, 2013 classList [1] ClassList DEFAULT {unclassified}, 2014 securityCategories [2] SET OF SecurityCategory OPTIONAL 2015 } 2017 It should say: 2019 Clearance ::= SEQUENCE { 2020 policyId OBJECT IDENTIFIER, 2021 classList ClassList DEFAULT {unclassified}, 2022 securityCategories SET OF SecurityCategory OPTIONAL 2023 } 2025 Notes: 2027 The differences in tagging arose due to an unnoticed technical 2028 corrigendum (TC-2) being applied to the X.501 document during 2029 preparation of RFC 3281. The X.501 format is the correct form and 2030 will be included in a future update of RFC 3281. Implementers SHOULD 2031 modify their decoding functions to accept either format and, even if 2032 claiming RFC 3281 conformance, SHOULD output the (correct) X.501 2033 format pending the issuing of a corrected RFC at which point the 2034 incorrect RFC 3281 format will no longer be specified. 2036 Appendix D Changes Since RFC 3281 2038 1. Created a new Section 1.1 "Terminology", renumbered Section 1.1- 2039 1.3 to 1.2-1.4, and moved first paragraph of Section 1 to Section 2040 1.1. 2042 2. In Section 1.2, rephrased 1st sentence in 3rd paragraph. 2044 3. In Section 2, replace S/MIME v3 with S/MIME v3.2. 2046 4. In Section 4.1, moved "," from the right of the ASN.1 comment to 2047 the left of the ASN.1 comment on the line describing version in the 2048 AttributerCertificateInfo structure. Replaced reference to X.208 with 2049 X.690. 2051 5. In Section 4.2, replaced pointer to 4.2.1.7 of RFC 3280 with 2052 pointer to 4.2.1.6 of RFC 5280. Added requirement to support subject 2053 alternative name choice SRVName. 2055 6. In Section 4.3.2, replaced "Confirming" with "Conforming". 2057 7. In Section 4.3.4, replaced reference to RFC 1738, URL, with 2058 references to [HTTP-URL], "authorityInformationAccess" with 2059 "authorityInfoAccess", and "NOT REQUIRED" with "OPTIONAL." 2061 8. In Section 4.3.5, replaced "HTTP or an LDAP" with "HTTP [HTTP-URL] 2062 or an LDAP [LDAP-URL]". Also replaced "CRLDistPointsSyntax" with 2063 "CRLDistributionPoints". 2065 9. In Section 4.4.6, added text to address having two OIDs for the 2066 same syntax and two syntaxes for one OID. 2068 10. In Section 5, replaced "When the extension value SHOULD cause" 2069 with "When the extension value causes". 2071 11. In Section 7.1, replaced text that described encapsulating 2072 encrypted attribute with corrected text. Clarified that attributes 2073 can appear more than once if they apply to different recipients. 2074 Reworded last paragraph to more clearly describe the failure case. 2076 12. In Section 7.3, updated references to point to RFC 3279. 2078 13. In Section 8, updated last paragraph to better explain why 2079 implementers need to be careful when mapping authenticated identities 2080 to the AC holder. 2082 14. Updated References: 2083 a) split references in to informative/normative references 2084 b) added reference to RFC 3281 2085 c) replaced reference to X.501:1993 with X.501:1997 2086 d) replaced reference to RFC 1510 with RFC 4120 2087 e) replaced reference to RFC 1738 with RFC 4516 and 2585 2088 f) replaced reference to RFC 2251 with RFC 4511 2089 g) replaced reference to RFC 2459 with RFC 5280 2090 h) replaced reference to RFC 2510 with RFC 4210 2091 i) replaced reference to RFC 2630 with RFC 3852 2092 j) replaced reference to RFC 2797 with RFC 5272 2093 k) replaced reference to X.208-1988 with X.690 2094 l) added reference to X.680 2095 m) added reference to RFC 4985 2096 m) expanded reference to RFC 3279 by adding RFC 5480 and RFC 4055, 2097 which update RFC 3279 2098 n) deleted spurious reference to CMC, CMP, ESS, RFC 2026, 2099 X.209-88, and X.501:1988. 2101 15. In Appendix A, added 2nd clearance attribute object identifier. 2103 16. Appendix B, updated ASN.1 with changes 3, 8, 9, and 11: 2104 a) New OID for ASN.1 module. 2105 b) Updated module OIDs for PKIX1Explicit88 and PKIX1Implicit88. 2106 c) Added imports from PKIX1Implicit88 for AuthorityKeyIdentifier, 2107 AuthorityInfoAccessSyntax, CRLDistributionPoint 2108 d) Added imports from CryptographicMessageSyntax2004 for 2109 ContentInfo. 2110 e) Added comments and commented out ASN.1 for old clearance 2111 attribute syntax. 2112 f) Added preamble to ASN.1, which is taken from Appendix A of 2113 RFC5280. 2115 17. Added Appendix C. 2117 Authors' Addresses 2119 Sean Turner 2120 IECA, Inc. 2121 3057 Nutley Street, Suite 106 2122 Fairfax, VA 22031 2123 USA 2124 EMail: turners@ieca.com 2126 Russ Housley 2127 Vigil Security, LLC 2128 918 Spring Knoll Drive 2129 Herndon, VA 20170 2130 USA 2131 EMail: housley@vigilsec.com 2133 Stephen Farrell 2134 Distributed Systems Group 2135 Computer Science Department 2136 Trinity College Dublin 2137 Ireland 2138 EMail: stephen.farrell@cs.tcd.ie