idnits 2.17.00 (12 Aug 2021) /tmp/idnits30435/draft-ietf-pkix-ac509prof-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 271 has weird spacing: '...erifier any ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If an AC contains attributes apparently encrypted for the AC verifier, then the decryption process MUST not fail. If decryption does fail, then the AC MUST be rejected. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2001) is 7644 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 1800 -- Looks like a reference, but probably isn't: '1' on line 1801 -- Looks like a reference, but probably isn't: '2' on line 1781 == Missing Reference: 'UNIVERSAL 12' is mentioned on line 1676, but not defined == Unused Reference: 'CMC' is defined on line 1478, but no explicit reference was found in the text == Unused Reference: 'CMP' is defined on line 1480, but no explicit reference was found in the text == Unused Reference: 'ESS' is defined on line 1484, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2797 (ref. 'CMC') (Obsoleted by RFC 5272) ** Obsolete normative reference: RFC 2510 (ref. 'CMP') (Obsoleted by RFC 4210) ** Obsolete normative reference: RFC 2630 (ref. 'CMS') (Obsoleted by RFC 3369, RFC 3370) ** Obsolete normative reference: RFC 1510 (ref. 'KRB') (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 2251 (ref. 'LDAP') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) -- No information found for draft-ietf-pkix-pkalgs - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PKIXALGS' == Outdated reference: draft-ietf-cat-kerberos-pk-init has been published as RFC 4556 == Outdated reference: draft-ietf-pkix-new-part1 has been published as RFC 3280 ** Obsolete normative reference: RFC 1738 (ref. 'URL') (Obsoleted by RFC 4248, RFC 4266) Summary: 11 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group S. Farrell 3 INTERNET-DRAFT Baltimore Technologies 4 Expires in six months R. Housley 5 SPYRUS 6 1st June 2001 8 An Internet Attribute Certificate 9 Profile for Authorization 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of [RFC2026]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This specification defines a profile for the use of X.509 Attribute 35 Certificates in Internet Protocols. Attribute certificates may be 36 used in a wide range of applications and environments covering a 37 broad spectrum of interoperability goals and a broader spectrum of 38 operational and assurance requirements. The goal of this document is 39 to establish a common baseline for generic applications requiring 40 broad interoperability as well as limited special purpose 41 requirements. The profile places emphasis on attribute certificate 42 support for Internet electronic mail, IPSec, and WWW security 43 applications. 45 Table of Contents 47 Status of this Memo.............................................1 48 Abstract........................................................1 49 Table of Contents...............................................2 50 1. Introduction.................................................3 51 1.1 Delegation and AC chains...............................4 52 1.2 Attribute Certificate Distribution ("push" vs. "pull").4 53 1.3 Document Structure.....................................5 54 2. Terminology..................................................6 55 3. Requirements.................................................7 56 4. Attribute Certificate Profile................................8 57 4.1 X.509 Attribute Certificate Definition.................8 58 4.2 Profile of Standard Fields............................10 59 4.2.1 Version.........................................10 60 4.2.2 Holder..........................................10 61 4.2.3 Issuer..........................................11 62 4.2.4 Signature.......................................12 63 4.2.5 Serial Number...................................12 64 4.2.6 Validity Period.................................12 65 4.2.7 Attributes......................................13 66 4.2.8 Issuer Unique Identifier........................13 67 4.2.9 Extensions......................................13 68 4.3 Extensions............................................14 69 4.3.1 Audit Identity..................................14 70 4.3.2 AC Targeting....................................15 71 4.3.3 Authority Key Identifier........................16 72 4.3.4 Authority Information Access....................16 73 4.3.5 CRL Distribution Points.........................17 74 4.3.6 No Revocation Available.........................17 75 4.4 Attribute Types.......................................17 76 4.4.1 Service Authentication Information..............18 77 4.4.2 Access Identity.................................18 78 4.4.3 Charging Identity...............................19 79 4.4.4 Group...........................................19 80 4.4.5 Role............................................19 81 4.4.6 Clearance.......................................20 82 4.5 Profile of AC issuer's PKC............................21 83 5. Attribute Certificate Validation............................22 84 6. Revocation..................................................23 85 7. Optional Features...........................................24 86 7.1 Attribute Encryption..................................24 87 7.2 Proxying..............................................25 88 7.3 Use of ObjectDigestInfo...............................26 89 7.4 AA Controls...........................................27 90 8. Security Considerations.....................................29 91 9. IANA Considerations.........................................30 92 10.References..................................................30 93 Author's Addresses.............................................32 94 Full Copyright Statement.......................................32 95 Appendix A: Object Identifiers.................................33 96 Appendix B: ASN.1 Module.......................................34 98 1. Introduction 100 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 101 in this document are to be interpreted as described in [RFC2119]. 103 X.509 public key certificates (PKCs) [X.509-1997, X.509-2000, 104 PKIXPROF] bind an identity and a public key. An attribute 105 certificate (AC) is a structure similar to a PKC; the main 106 difference being that the AC contains no public key. An AC may 107 contain attributes that specify group membership, role, security 108 clearance, or other authorization information associated with the AC 109 holder. The syntax for the AC is defined in Recommendation X.509, 110 making the term "X.509 certificate" ambiguous. 112 Some people constantly confuse PKCs and ACs. An analogy may make the 113 distinction clear. A PKC can be considered to be like a passport: it 114 identifies the holder, tends to last for a long time, and should not 115 be trivial to obtain. An AC is more like an entry visa: it is 116 typically issued by a different authority and does not last for as 117 long a time. As acquiring an entry visa typically requires 118 presenting a passport, getting a visa can be a simpler process. 120 Authorization information may be placed in a PKC extension or placed 121 in a separate attribute certificate (AC). The placement of 122 authorization information in PKCs is usually undesirable for two 123 reasons. First, authorization information often does not have the 124 same lifetime as the binding of the identity and the public key. 125 When authorization information is placed in a PKC extension, the 126 general result is the shortening of the PKC useful lifetime. Second, 127 the PKC issuer is not usually authoritative for the authorization 128 information. This results in additional steps for the PKC issuer to 129 obtain authorization information from the authoritative source. 131 For these reasons, it is often better to separate authorization 132 information from the PKC. Yet, authorization information also needs 133 to be bound to an identity. An AC provides this binding; it is 134 simply a digitally signed (or certified) identity and set of 135 attributes. 137 An AC may be used with various security services, including access 138 control, data origin authentication, and non-repudiation. 140 PKCs can provide an identity to access control decision functions. 141 However, in many contexts the identity is not the criterion that is 142 used for access control decisions, rather the role or group- 143 membership of the accessor is the criterion used. Such access 144 control schemes are called role-based access control. 146 When making an access control decision based on an AC, an access 147 control decision function may need to ensure that the appropriate AC 148 holder is the entity that has requested access. One way in which the 149 linkage between the request or identity and the AC can be achieved 150 is the inclusion of a reference to a PKC within the AC and the use 151 of the private key corresponding to the PKC for authentication 152 within the access request. 154 ACs may also be used in the context of a data origin authentication 155 service and a non-repudiation service. In these contexts, the 156 attributes contained in the AC provide additional information about 157 the signing entity. This information can be used to make sure that 158 the entity is authorized to sign the data. This kind of checking 159 depends either on the context in which the data is exchanged or on 160 the data that has been digitally signed. 162 1.1 Delegation and AC chains 164 The X.509 standard [X.509-2000] defines authorization as the 165 "conveyance of privilege from one entity that holds such privilege, 166 to another entity". An AC is one authorization mechanism. 168 An ordered sequence of ACs could be used to verify the authenticity 169 of a privilege asserter's privilege. In this way, chains or paths of 170 ACs could be employed to delegate authorization. 172 Since the administration and processing associated with such AC 173 chains is complex and the use of ACs in the Internet today is quite 174 limited, this specification does NOT RECOMMEND the use of AC chains. 175 Other (future) specifications may address the use of AC chains. This 176 specification deals with the simple cases where one authority issues 177 all of the ACs for a particular set of attributes. However, this 178 simplification does not preclude the use of several different 179 authorities, each of which manages a different set of attributes. 180 For example, group membership may be included in one AC issued by 181 one authority, and security clearance may be included in another AC 182 issued by another authority. 184 This means that conformant implementations are only REQUIRED to be 185 able to process a single AC at a time. Processing of more than one 186 AC, one after another, may be necessary. Note however, that 187 validation of an AC MAY require validation of a chain of PKCs, as 188 specified in [PKIXPROF]. 190 1.2 Attribute Certificate Distribution ("push" vs. "pull") 192 As discussed above, ACs provide a mechanism to securely provide 193 authorization information to, for example, access control decision 194 functions. However, there are a number of possible communication 195 paths for ACs. 197 In some environments it is suitable for a client to "push" an AC to 198 a server. This means that no new connections between the client and 199 server are required. It also means that no search burden is imposed 200 on servers, which improves performance and that the AC verifier is 201 only presented with what it "needs to know." In inter-domain cases 202 where the client's rights should be assigned within client's "home" 203 domain, the "push" model is especially suitable. 205 In other cases, it is more suitable for a client simply to 206 authenticate to the server and for the server to request or "pull" 207 the client's AC from an AC issuer or a repository. A major benefit 208 of the "pull" model is that it can be implemented without changes to 209 the client or to the client-server protocol. The "pull" model is 210 especially suitable for inter-domain cases where the client's rights 211 should be assigned within the server's domain, rather than within 212 the client's domain. 214 There are a number of possible exchanges involving three entities: 215 the client, the server, and the AC issuer. In addition, a directory 216 service or other repository for AC retrieval MAY be supported. 218 Figure 1 shows an abstract view of the exchanges that may involve 219 ACs. This profile does not specify a protocol for these exchanges. 221 +--------------+ 222 | | Server Acquisition 223 | AC issuer +----------------------------+ 224 | | | 225 +--+-----------+ | 226 | | 227 | Client | 228 | Acquisition | 229 | | 230 +--+-----------+ +--+------------+ 231 | | AC "push" | | 232 | Client +-------------------------+ Server | 233 | | (part of app. protocol) | | 234 +--+-----------+ +--+------------+ 235 | | 236 | Client | Server 237 | Lookup +--------------+ | Lookup 238 | | | | 239 +---------------+ Repository +---------+ 240 | | 241 +--------------+ 243 Figure 1: AC Exchanges 245 1.3 Document Structure 247 Section 2 defines some terminology. Section 3 specifies the 248 requirements that this profile is intended to meet.; Section 4 249 contains the profile of the X.509 AC. Section 5 specifies rules for 250 AC validation. Section 6 specifies rules for AC revocation checks. 251 Section 7 specifies optional features which MAY be supported; 252 however, support for these features is not required for conformance 253 to this profile. Finally, appendices contain the list of OIDs 254 required to support this specification and an ASN.1 module. 256 2. Terminology 258 For simplicity, we use the terms client and server in this 259 specification. This is not intended to indicate that ACs are only to 260 be used in client-server environments. For example, ACs may be used 261 in the S/MIME v3 context, where the mail user agent would be both a 262 "client" and a "server" in the sense the terms are used here. 264 Term Meaning 266 AA Attribute Authority, the entity that issues the 267 AC, synonymous in this specification with "AC 268 issuer" 269 AC Attribute Certificate 270 AC user any entity that parses or processes an AC 271 AC verifier any entity that checks the validity of an AC and 272 then makes use of the result 273 AC issuer the entity which signs the AC, synonymous in this 274 specification with "AA" 275 AC holder the entity indicated (perhaps indirectly) in the 276 holder field of the AC 277 Client the entity which is requesting the action for 278 which authorization checks are to be made 279 Proxying In this specification, Proxying is used to mean 280 the situation where an application server acts as 281 an application client on behalf of a user. 282 Proxying here does not mean granting of authority. 283 PKC Public Key Certificate - uses the type ASN.1 284 Certificate defined in X.509 and profiled in RFC 285 2459. This (non-standard) acronym is used in order 286 to avoid confusion about the term "X.509 287 certificate". 288 Server the entity which requires that the authorization 289 checks are made 291 3. Requirements 293 This AC profile meets the following requirements. 295 Time/Validity requirements: 297 1. Support for short-lived as well as long-lived ACs. Typical 298 short-lived validity periods might be measured in hours, as 299 opposed to months for PKCs. Short validity periods allow ACs to 300 be useful without a revocation mechanism. 302 Attribute Types: 304 2. Issuers of ACs should be able to define their own attribute 305 types for use within closed domains. 306 3. Some standard attribute types should be defined which can be 307 contained within ACs. Examples include "access identity," 308 "group," "role," "clearance," "audit identity," and "charging 309 identity." 310 4. Standard attribute types should be defined in a manner that 311 permits an AC verifier to distinguish between uses of the same 312 attribute in different domains. For example, the 313 "Administrators group" as defined by Baltimore and the 314 "Administrators group" as defined by SPYRUS should be easily 315 distinguished. 317 Targeting of ACs: 319 5. It should be possible to "target" an AC at one, or a small 320 number of, servers. This means that a trustworthy non-target 321 server will reject the AC for authorization decisions. 323 Push vs. Pull 325 6. ACs should be defined so that they can either be "pushed" by 326 the client to the server, or "pulled" by the server from a 327 repository or other network service, including an online AC 328 issuer. 330 4. Attribute Certificate Profile 332 ACs may be used in a wide range of applications and environments 333 covering a broad spectrum of interoperability goals and a broader 334 spectrum of operational and assurance requirements. The goal of 335 this document is to establish a common baseline for generic 336 applications requiring broad interoperability and limited special 337 purpose requirements. In particular, the emphasis will be on 338 supporting the use of attribute certificates for informal Internet 339 electronic mail, IPSec, and WWW applications. 341 This section presents a profile for ACs that will foster 342 interoperability. This section also defines some private extensions 343 for the Internet community. 345 While the ISO/IEC/ITU documents use the 1993 (or later) version of 346 ASN.1; this document uses the 1988 ASN.1 syntax, as has been done 347 for PKCs [PKIXPROF]. The encoded certificates and extensions from 348 either ASN.1 version are bit-wise identical. 350 Where maximum lengths for fields are specified, these lengths refer 351 to the DER encoding and do not include the ASN.1 tag or length 352 fields. 354 Conforming implementations MUST support the profile specified in 355 this section. 357 4.1 X.509 Attribute Certificate Definition 359 X.509 contains the definition of an AC given below. All types that 360 are not defined in this document can be found in [PKIXPROF]. 362 AttributeCertificate ::= SEQUENCE { 363 acinfo AttributeCertificateInfo, 364 signatureAlgorithm AlgorithmIdentifier, 365 signatureValue BIT STRING 366 } 368 AttributeCertificateInfo ::= SEQUENCE { 369 version AttCertVersion -- version is v2, 370 holder Holder, 371 issuer AttCertIssuer, 372 signature AlgorithmIdentifier, 373 serialNumber CertificateSerialNumber, 374 attrCertValidityPeriod AttCertValidityPeriod, 375 attributes SEQUENCE OF Attribute, 376 issuerUniqueID UniqueIdentifier OPTIONAL, 377 extensions Extensions OPTIONAL 378 } 380 AttCertVersion ::= INTEGER { v2(1) } 381 Holder ::= SEQUENCE { 382 baseCertificateID [0] IssuerSerial OPTIONAL, 383 -- the issuer and serial number of 384 -- the holder's Public Key Certificate 385 entityName [1] GeneralNames OPTIONAL, 386 -- the name of the claimant or role 387 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 388 -- if present, version must be v2 389 } 391 ObjectDigestInfo ::= SEQUENCE { 392 digestedObjectType ENUMERATED { 393 publicKey (0), 394 publicKeyCert (1), 395 otherObjectTypes (2) }, 396 -- otherObjectTypes MUST NOT 397 -- be used in this profile 398 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 399 digestAlgorithm AlgorithmIdentifier, 400 objectDigest BIT STRING 401 } 403 AttCertIssuer ::= CHOICE { 404 v1Form GeneralNames, -- v1 or v2 405 v2Form [0] V2Form -- v2 only 406 } 408 V2Form ::= SEQUENCE { 409 issuerName GeneralNames OPTIONAL, 410 baseCertificateID [0] IssuerSerial OPTIONAL, 411 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 412 -- at least one of issuerName, baseCertificateID 413 -- or objectDigestInfo MUST be present 414 } 416 IssuerSerial ::= SEQUENCE { 417 issuer GeneralNames, 418 serial CertificateSerialNumber, 419 issuerUID UniqueIdentifier OPTIONAL 420 } 422 AttCertValidityPeriod ::= SEQUENCE { 423 notBeforeTime GeneralizedTime, 424 notAfterTime GeneralizedTime 425 } 427 Although the Attribute syntax is defined in [PKIXPROF], we repeat 428 the definition here for convenience. 430 Attribute ::= SEQUENCE { 431 type AttributeType, 432 values SET OF AttributeValue 433 -- at least one value is required 434 } 436 AttributeType ::= OBJECT IDENTIFIER 438 AttributeValue ::= ANY DEFINED BY AttributeType 440 Implementers should note that the DER encoding (see [X.509- 441 1988],[X.208-1988]) of the SET OF values requires ordering of the 442 encodings of the values. Though this issue arises with respect to 443 distinguished names, and has to be handled by [PKIXPROF] 444 implementations, its is much more significant in this context, since 445 the inclusion of multiple values is much more common in ACs. 447 4.2 Profile of Standard Fields 449 For all GeneralName fields in this profile the otherName (except as 450 noted below), x400Address, ediPartyName and registeredID options 451 MUST NOT be used. The use of Kerberos [KRB] principal names, 452 encoded into the otherName, SHOULD however, be supported using the 453 krb5PrincipalName OID and the KerberosName syntax as defined in 454 [PKINIT]. 456 Conforming implementations MUST be able to support the dNSName, 457 directoryName, uniformResourceIdentifier, and iPAddress fields in 458 all cases where GeneralName is used. This is compatible with the 459 GeneralName requirements in [PKIXPROF] (mainly in section 4.2.1.7). 461 4.2.1 Version 463 The version field MUST be have the value of v2. That is, the 464 version field is present in the DER encoding. 466 Note: This version (v2) is not backwards compatible with the 467 previous attribute certificate definition (v1) from the 1997 X.509 468 standard [X.509-1997], but is compatible with the v2 definition from 469 X.509 (2000) [X.509-2000]. 471 4.2.2 Holder 473 The Holder field is a SEQUENCE allowing three different (optional) 474 syntaxes: baseCertificateID, entityName and objectDigestInfo. Where 475 only one option is present the meaning of the Holder field is clear. 476 However, where more than one option is used, there is potential for 477 confusion as to which option is "normative", which is a "hint" etc. 478 Since the correct position is not clear from [X.509-2000] this 479 specification RECOMMENDS that only one of the options be used in any 480 given AC. 482 For any environment where the AC is passed in an authenticated 483 message or session and where the authentication is based on the use 484 of an X.509 PKC, the holder field SHOULD use the baseCertificateID. 486 With the baseCertificateID option, the holder's PKC serialNumber and 487 issuer MUST be identical to the AC holder field. The PKC issuer MUST 488 have a non-empty distinguished name which is to be present as the 489 single value of the holder.baseCertificateID.issuer construct in the 490 directoryName field. The AC holder.baseCertificateID.issuerUID field 491 MUST only be used if the holder's PKC contains an issuerUniqueID 492 field. If both the AC holder.baseCertificateID.issuerUID and the PKC 493 issuerUniqueID fields are present, then the same value MUST be 494 present in both fields. Thus, the baseCertificateID is only usable 495 with PKC profiles (like [PKIXPROF]) which mandate that the PKC 496 issuer field contain a non-empty distinguished name value. 498 Note: An empty distinguished name is a distinguished name where the 499 SEQUENCE OF relative distinguished names is of zero length. In a DER 500 encoding this has the value '3000'H. 502 If the holder field uses the entityName option and the underlying 503 authentication is based on a PKC, then the entityName MUST be the 504 same as the PKC subject field or one of the values of the PKC 505 subjectAltName field extension (if present). Note that [PKIXPROF] 506 mandates that the subjectAltName extension be present if the PKC 507 subject is an empty distinguished name. See the security 508 consideration section which mentions some name collision problems 509 that may arise when using the entityName option. 511 In any other case where the holder field uses the entityName option, 512 then only one name SHOULD be present. 514 Implementations conforming to this profile are not required to 515 support the use of the objectDigest field. However, section 7.3 516 specifies how this optional feature MAY be used. 518 Any protocol conforming to this profile SHOULD specify which AC 519 holder option is to be used and how this fits with the supported 520 authentication schemes defined in that protocol. 522 4.2.3 Issuer 524 ACs conforming to this profile MUST use the v1Form choice, which 525 MUST contain one and only one GeneralName, which MUST contain a non- 526 empty distinguished name in the directoryName field. This means that 527 all AC issuers MUST have non-empty distinguished names. 529 Part of the reason for the use of the v1Form field is that it means 530 that the AC issuer does not have to know which PKC the AC verifier 531 will use for it (the AC issuer). Using the baseCertificateID field 532 to reference the AC issuer would mean that the AC verifier would 533 have to trust the PKC that the AC issuer chose (for itself) at AC 534 creation time. 536 4.2.4 Signature 538 Contains the algorithm identifier used to validate the AC signature. 540 This MUST be one of the signing algorithms defined in [PKIXALGS]. 541 Conforming implementations MUST honor all MUST/SHOULD/MAY signing 542 algorithm statements specified in [PKIXALGS]. 544 4.2.5 Serial Number 546 For any conforming AC, the issuer/serialNumber pair MUST form a 547 unique combination, even if ACs are very short-lived. 549 AC issuers MUST force the serialNumber to be a positive integer, 550 that is, the sign bit in the DER encoding of the INTEGER value MUST 551 be zero - this can be done by adding a leading (leftmost) '00'H 552 octet if necessary. This removes a potential ambiguity in mapping 553 between a string of octets and an integer value. 555 Given the uniqueness and timing requirements above serial numbers 556 can be expected to contain long integers. AC users MUST be able to 557 handle serialNumber values longer than 4 octets. Conformant ACs MUST 558 NOT contain serialNumber values longer than 20 octets. 560 There is no requirement that the serial numbers used by any AC 561 issuer follow any particular ordering, in particular, they need not 562 be monotonically increasing with time. Each AC issuer MUST ensure 563 that each AC that it issues contain a unique serial number. 565 4.2.6 Validity Period 567 The attrCertValidityPeriod (a.k.a. validity) field specifies the 568 period for which the AC issuer certifies that the binding between 569 the holder and the attributes fields will be valid. 571 The generalized time type, GeneralizedTime, is a standard ASN.1 type 572 for variable precision representation of time. The GeneralizedTime 573 field can optionally include a representation of the time 574 differential between the local time zone and Greenwich Mean Time. 576 For the purposes of this profile, GeneralizedTime values MUST be 577 expressed in Coordinated universal time (UTC) (also known as 578 Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times 579 are YYYYMMDDHHMMSSZ), even when the number of seconds is zero. 580 GeneralizedTime values MUST NOT include fractional seconds. 581 (Note: this is the same as specified in [PKIXPROF], section 582 4.1.2.5.2.) 583 AC users MUST be able to handle an AC which, at the time of 584 processing, has parts of its validity period or all its validity 585 period in the past or in the future (a post-dated AC). This is valid 586 for some applications, such as backup. 588 4.2.7 Attributes 590 The attributes field gives information about the AC holder. When the 591 AC is used for authorization this will often contain a set of 592 privileges. 594 The attributes field contains a SEQUENCE OF Attribute. Each 595 Attribute MAY contain a SET OF values. For a given AC, each 596 AttributeType OBJECT IDENTIFIER in the sequence MUST be unique. That 597 is, only one instance of each attribute can occur in a single AC, 598 but each instance can be multi-valued. 600 AC users MUST be able to handle multiple values for all attribute 601 types. 603 An AC MUST contain at least one attribute. That is, the SEQUENCE OF 604 Attributes MUST NOT be of zero length. 606 Some standard attribute types are defined in section 4.5. 608 4.2.8 Issuer Unique Identifier 610 This field MUST NOT be used unless it is also used in the AC 611 issuer's PKC, in which case it MUST be used. Note that [PKIXPROF] 612 states that this field SHOULD NOT be used by conforming CAs, but 613 that applications SHOULD be able to parse PKCs containing the field. 615 4.2.9 Extensions 617 The extensions field generally gives information about the AC as 618 opposed to information about the AC holder. 620 An AC that has no extensions conforms to the profile; however, 621 section 4.3 defines the extensions that MAY be used with this 622 profile, and whether or not they may be marked critical. If any 623 other critical extension is used, then the AC does not conform to 624 this profile. However, if any other non-critical extension is used, 625 then the AC does conform to this profile. 627 The extensions defined for ACs provide methods for associating 628 additional attributes with holders. This profile also allows 629 communities to define private extensions to carry information unique 630 to those communities. Each extension in an AC may be designated as 631 critical or non-critical. An AC using system MUST reject an AC if 632 it encounters a critical extension it does not recognize; however, a 633 non-critical extension may be ignored if it is not recognized. 634 Section 4.3 presents recommended extensions used within Internet ACs 635 and standard locations for information. Communities may elect to 636 use additional extensions; however, caution should be exercised in 637 adopting any critical extensions in ACs, which might prevent use in 638 a general context. 640 4.3 Extensions 642 4.3.1 Audit Identity 644 In some circumstances it is required (e.g. by data protection/data 645 privacy legislation) that audit trails do not contain records which 646 directly identify individuals. This circumstance may make the use of 647 the AC holder field unsuitable for use in audit trails. 649 To allow for such cases, an AC MAY contain an audit identity 650 extension. Ideally it SHOULD be infeasible to derive the AC holder's 651 identity from the audit identity value without the co-operation of 652 the AC issuer. 654 The value of the audit identity along with the AC issuer/serial 655 SHOULD then be used for audit/logging purposes. If the value of the 656 audit identity is suitably chosen, then a server/service 657 administrator can use audit trails to track the behavior of an AC 658 holder without being able to identify the AC holder. 660 The server/service administrator in combination with the AC issuer 661 MUST be able to identify the AC holder in cases where misbehavior is 662 detected. This means that the AC issuer MUST be able to determine 663 the actual identity of the AC holder from the audit identity. 665 Of course, auditing could be based on the AC issuer/serial pair; 666 however, this method doesn't allow tracking the same AC holder with 667 multiple ACs. Thus, an audit identity is only useful if it lasts for 668 longer than the typical AC lifetime. Auditing could also be based on 669 the AC holder's PKC issuer/serial; however, this will often allow 670 the server/service administrator to identify the AC holder. 672 As the AC verifier might otherwise use the AC holder or some other 673 identifying value for audit purposes, this extension MUST be 674 critical when used. 676 Protocols that use ACs will often expose the identity of the AC 677 holder in the bits on-the-wire. In such cases, an opaque audit 678 identity does not make use of the AC anonymous, it simply ensures 679 that the ensuing audit trails do not contain identifying 680 information. 682 The value of an audit identity MUST be longer than zero octets. The 683 value of an audit identity MUST NOT be longer than 20 octets. 685 name id-pe-ac-auditIdentity 686 OID { id-pe 4 } 687 syntax OCTET STRING 688 criticality MUST be TRUE 690 4.3.2 AC Targeting 692 To target an AC, the target information extension, imported from 693 [X.509-2000], MAY be used to specify a number of servers/services. 694 The intent is that the AC SHOULD only be usable at the specified 695 servers/services. An (honest) AC verifier who is not amongst the 696 named servers/services MUST reject the AC. 698 If this extension is not present, then the AC is not targeted and 699 may be accepted by any server. 701 In this profile, the targeting information simply consists of a list 702 of named targets or groups. 704 The following syntax is used to represent the targeting information: 706 Targets ::= SEQUENCE OF Target 708 Target ::= CHOICE { 709 targetName [0] GeneralName, 710 targetGroup [1] GeneralName, 711 targetCert [2] TargetCert 712 } 714 TargetCert ::= SEQUENCE { 715 targetCertificate IssuerSerial, 716 targetName GeneralName OPTIONAL, 717 certDigestInfo ObjectDigestInfo OPTIONAL 718 } 720 The targetCert CHOICE within the Target structure is only present to 721 allow future compatibility with [X.509-2000] and MUST NOT be used. 723 The targets check passes if the current server (recipient) is one of 724 the targetName fields in the Targets SEQUENCE, or if the current 725 server is a member of one of the targetGroup fields in the Targets 726 SEQUENCE. In this case, the current server is said to "match" the 727 targeting extension. 729 How the membership of a target within a targetGroup is determined is 730 not defined here. It is assumed that any given target "knows" the 731 names of the targetGroups to which it belongs or can otherwise 732 determine its membership. For example, the targetGroup specifies a 733 DNS domain, and the AC verifier knows the DNS domain to which it 734 belongs. For another example, the targetGroup specifies "PRINTERS," 735 and the AC verifier knows whether or not it is a printer or print 736 server. 738 Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF 739 Targets". Conforming AC issuer implementations MUST only produce one 740 "Targets" element. Confirming AC users MUST be able to accept a 741 "SEQUENCE OF Targets". If more than one Targets element is found in 742 an AC, then the extension MUST be treated as if all Target elements 743 had been found within one Targets element. 745 name id-ce-targetInformation 746 OID { id-ce 55 } 747 syntax SEQUENCE OF Targets 748 criticality MUST be TRUE 750 4.3.3 Authority Key Identifier 752 The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY 753 be used to assist the AC verifier in checking the signature of the 754 AC. The [PKIXPROF] description should be read as if "CA" meant "AC 755 issuer." As with PKCs this extension SHOULD be included in ACs. 757 Note: An AC where the issuer field used the baseCertificateID CHOICE 758 would not need an authorityKeyIdentifier extension as it is 759 explicitly linked to the key in the referred certificate. However, 760 as this profile states (in section 4.2.3) that ACs MUST use the 761 v1Form CHOICE, this duplication does not arise. 763 name id-ce-authorityKeyIdentifier 764 OID { id-ce 35 } 765 syntax AuthorityKeyIdentifier 766 criticality MUST be FALSE 768 4.3.4 Authority Information Access 770 The authorityInformationAccess extension, as defined in [PKIXPROF], 771 MAY be used to assist the AC verifier in checking the revocation 772 status of the AC. Support for the id-ad-caIssuers accessMethod is 773 NOT REQUIRED by this profile since AC chains are not expected. 775 The following accessMethod is used to indicate that revocation 776 status checking is provided for this AC, using the OCSP protocol 777 defined in [OCSP]: 779 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 781 The accessLocation MUST contain a URI, and the URI MUST contain an 782 HTTP URL [URL] that specifies the location of an OCSP responder. The 783 AC issuer MUST, of course, maintain an OCSP responder at this 784 location. 786 name id-ce-authorityInfoAccess 787 OID { id-pe 1 } 788 syntax AuthorityInfoAccessSyntax 789 criticality MUST be FALSE 791 4.3.5 CRL Distribution Points 793 The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY 794 be used to assist the AC verifier in checking the revocation status 795 of the AC. See section 6 for details on revocation. 797 If the crlDistributionPoints extension is present, then exactly one 798 distribution point MUST be present. The crlDistributionPoints 799 extension MUST use the DistributionPointName option, which MUST 800 contain a fullName, which MUST contain a single name form. That name 801 MUST contain either a distinguished name or a URI. The URI MUST be 802 either an HTTP URL or an LDAP URL [URL]. 804 name id-ce-cRLDistributionPoints 805 OID { id-ce 31 } 806 syntax CRLDistPointsSyntax 807 criticality MUST be FALSE 809 4.3.6 No Revocation Available 811 The noRevAvail extension, defined in [X.509-2000], allows an AC 812 issuer to indicate that no revocation information will be made 813 available for this AC. 815 This extension MUST be non-critical. An AC verifier that does not 816 understand this extension might be able to find a revocation list 817 from the AC issuer, but the revocation list will never include an 818 entry for the AC. 820 name id-ce-noRevAvail 821 OID { id-ce 56 } 822 syntax NULL (i.e. '0500'H is the DER encoding) 823 criticality MUST be FALSE 825 4.4 Attribute Types 827 Some of the attribute types defined below make use of the 828 IetfAttrSyntax type, also defined below. The reasons for using this 829 type are: 831 1. It allows a separation between the AC issuer and the attribute 832 policy authority. This is useful for situations where a single 833 policy authority (e.g. an organization) allocates attribute 834 values, but where multiple AC issuers are deployed for 835 performance or other reasons. 836 2. The syntaxes allowed for values are restricted to OCTET STRING, 837 OBJECT IDENTIFIER, and UTF8String, which significantly reduces 838 the complexity associated with matching more general syntaxes. 839 All multi-valued attributes using this syntax are restricted so 840 that each value MUST use the same choice of value syntax. For 841 example, AC issuers must not use one value with an oid and a 842 second value with a string. 844 IetfAttrSyntax ::= SEQUENCE { 845 policyAuthority [0] GeneralNames OPTIONAL, 846 values SEQUENCE OF CHOICE { 847 octets OCTET STRING, 848 oid OBJECT IDENTIFIER, 849 string UTF8String 850 } 851 } 853 In the descriptions below, each attribute type is tagged as either 854 "Multiple Allowed" or "One Attribute value only; multiple values 855 within the IetfAttrSyntax". This refers to the SET OF 856 AttributeValue, the AttributeType still only occurs once, as 857 specified in section 4.2.7. 859 4.4.1 Service Authentication Information 861 The SvceAuthInfo attribute identifies the AC holder to the 862 server/service by a name, and the attribute MAY include optional 863 service specific authentication information. Typically this will 864 contain a username/password pair for a "legacy" application. 866 This attribute provides information that can be presented by the AC 867 verifier to be interpreted and authenticated by a separate 868 application within the target system. Note that this is a different 869 use to that intended for the accessIdentity attribute in 4.4.2 870 below. 872 This attribute type will typically be encrypted when the authInfo 873 field contains sensitive information, such as a password. 875 name id-aca-authenticationInfo 876 OID { id-aca 1 } 877 Syntax SvceAuthInfo 878 values: Multiple allowed 880 SvceAuthInfo ::= SEQUENCE { 881 service GeneralName, 882 ident GeneralName, 883 authInfo OCTET STRING OPTIONAL 884 } 886 4.4.2 Access Identity 888 The accessIdentity attribute identifies the AC holder to the 889 server/service. For this attribute the authInfo field MUST NOT be 890 present. 892 This attribute is intended to be used to provide information about 893 the AC holder, that can be used by the AC verifier (or a larger 894 system of which the AC verifier is a component) to authorize the 895 actions of the AC holder within the AC verifier's system. Note that 896 this is a different use to that intended for the svceAuthInfo 897 attribute described in 4.4.1 above. 899 name id-aca-accessIdentity 900 OID { id-aca 2 } 901 syntax SvceAuthInfo 902 values: Multiple allowed 904 4.4.3 Charging Identity 906 The chargingIdentity attribute identifies the AC holder for charging 907 purposes. In general, the charging identity will be different from 908 other identities of the holder. For example, the holder's company 909 may be charged for service. 911 name id-aca-chargingIdentity 912 OID { id-aca 3 } 913 syntax IetfAttrSyntax 914 values: One Attribute value only; multiple values within the 915 IetfAttrSyntax 917 4.4.4 Group 919 The group attribute carries information about group memberships of 920 the AC holder. 922 name id-aca-group 923 OID { id-aca 4 } 924 syntax IetfAttrSyntax 925 values: One Attribute value only; multiple values within the 926 IetfAttrSyntax 928 4.4.5 Role 930 The role attribute, specified in [X.509-2000], carries information 931 about role allocations of the AC holder. 933 The syntax used for this attribute is: 935 RoleSyntax ::= SEQUENCE { 936 roleAuthority [0] GeneralNames OPTIONAL, 937 roleName [1] GeneralName 938 } 940 The roleAuthority field MAY be used to specify the issuing authority 941 for the role specification certificate. There is no requirement that 942 a role specification certificate necessarily exists for the 943 roleAuthority. This differs from [X.500-2000], where the 944 roleAuthority field is assumed to name the issuer of a role 945 specification certificate. For example, to distinguish the 946 administrator role as defined by "Baltimore" from that defined by 947 "SPYRUS", one could put the value "administrator" in the roleName 948 field and the value "Baltimore" or "SPYRUS" in the roleAuthority 949 field. 951 The roleName field MUST be present, and roleName MUST use the 952 uniformResourceIdentifier CHOICE of the GeneralName. 954 name id-at-role 955 OID { id-at 72 } 956 syntax RoleSyntax 957 values: Multiple allowed 959 4.4.6 Clearance 961 The clearance attribute, specified in [X.501-1993], carries 962 clearance (associated with security labeling) information about the 963 AC holder. 965 The policyId field is used to identify the security policy to which 966 the clearance relates. The policyId indicates the semantics of the 967 classList and securityCategories fields. 969 This specification includes the classList field exactly as is 970 specified in [X.501-1993]. Additional security classification 971 values, and their position in the classification hierarchy, may be 972 defined by a security policy as a local matter or by bilateral 973 agreement. The basic security classification hierarchy is, in 974 ascending order: unmarked, unclassified, restricted, confidential, 975 secret, and top-secret. 977 An organization can develop its own security policy that defines 978 security classification values and their meanings. However, the BIT 979 STRING positions 0 through 5 are reserved for the basic security 980 classification hierarchy. 982 If present, the SecurityCategory field provides further 983 authorization information. The security policy identified by the 984 policyId field indicates the syntaxes that are allowed to be present 985 in the securityCategories SET. An OBJECT IDENTIFIER identifies each 986 of the allowed syntaxes. When one of these syntaxes is present in 987 the securityCategories SET, the OBJECT IDENTIFIER associated with 988 that syntax is carried in the SecurityCategory.type field. 990 Clearance ::= SEQUENCE { 991 policyId [0] OBJECT IDENTIFIER, 992 classList [1] ClassList DEFAULT {unclassified}, 993 securityCategories 994 [2] SET OF SecurityCategory OPTIONAL 995 } 997 ClassList ::= BIT STRING { 998 unmarked (0), 999 unclassified (1), 1000 restricted (2) 1001 confidential (3), 1002 secret (4), 1003 topSecret (5) 1004 } 1006 SecurityCategory ::= SEQUENCE { 1007 type [0] IMPLICIT OBJECT IDENTIFIER, 1008 value [1] ANY DEFINED BY type 1009 } 1011 -- This is the same as the original syntax which was defined 1012 -- using the MACRO construct, as follows: 1013 -- SecurityCategory ::= SEQUENCE { 1014 -- type [0] IMPLICIT SECURITY-CATEGORY, 1015 -- value [1] ANY DEFINED BY type 1016 -- } 1017 -- 1018 -- SECURITY-CATEGORY MACRO ::= 1019 -- BEGIN 1020 -- TYPE NOTATION ::= type | empty 1021 -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 1022 -- END 1024 name { id-at-clearance } 1025 OID { joint-iso-ccitt(2) ds(5) module(1) 1026 selected-attribute-types(5) clearance (55) } 1027 syntax Clearance - imported from [X.501-1993] 1028 values Multiple allowed 1030 4.5 Profile of AC issuer's PKC 1032 The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage 1033 extension in the PKC MUST NOT explicitly indicate that the AC 1034 issuer's public key cannot be used to validate a digital signature. 1035 In order to avoid confusion regarding serial numbers and 1036 revocations, an AC issuer MUST NOT also be a PKC Issuer. That is, 1037 an AC issuer cannot be a CA as well. So, the AC issuer's PKC MUST 1038 NOT have a basicConstraints extension with the cA BOOLEAN set to 1039 TRUE. 1041 5. Attribute Certificate Validation 1043 This section describes a basic set of rules that all valid ACs MUST 1044 satisfy. Some additional checks are also described which AC 1045 verifiers MAY choose to implement. 1047 To be valid an AC MUST satisfy all of the following: 1049 1. Where the holder uses a PKC to authenticate to the AC verifier, 1050 then the AC holder's PKC MUST be found, and the entire 1051 certification path of that PKC MUST be verified in accordance 1052 with [PKIXPROF]. As noted in the security considerations 1053 section, if some other authentication scheme is used, AC 1054 verifiers need to be very careful mapping the 1055 identities(authenticated identity, holder field) involved. 1056 2. The AC signature must be cryptographically correct, and the AC 1057 issuer's entire PKC certification path MUST be verified in 1058 accordance with [PKIXPROF]. 1059 3. The AC issuer's PKC MUST also conform to the profile specified 1060 in section 4.5 above. 1061 4. The AC issuer MUST be directly trusted as an AC issuer (by 1062 configuration or otherwise). 1063 5. The time for which the AC is being evaluated MUST be within the 1064 AC validity. If the evaluation time is equal to either 1065 notBeforeTime or notAfterTime, then the AC is timely and this 1066 check succeeds. Note that in some applications, the evaluation 1067 time MAY not be the same as the current time. 1068 6. The AC targeting check MUST pass as specified in section 4.3.2. 1069 7. If the AC contains an unsupported critical extension, then the 1070 AC MUST be rejected. 1072 Support for an extension in this context means: 1074 1. The AC verifier MUST be able to parse the extension value. 1075 2. Where the extension value SHOULD cause the AC to be rejected, 1076 the AC verifier MUST reject the AC. 1078 Additional Checks: 1080 1. The AC MAY be rejected on the basis of further AC verifier 1081 configuration. For example, an AC verifier may be configured to 1082 reject ACs which contain or lack certain attributes. 1083 2. If the AC verifier provides an interface that allows 1084 applications to query the contents of the AC, then the AC 1085 verifier MAY filter the attributes from the AC on the basis of 1086 configured information. For example, an AC verifier might be 1087 configured not to return certain attributes to certain servers. 1089 6. Revocation 1091 In many environments, the validity period of an AC is less than the 1092 time required to issue and distribute revocation information. 1093 Therefore, short-lived ACs typically do not require revocation 1094 support. However, long-lived ACs and environments where ACs enable 1095 high value transactions MAY require revocation support. 1097 Two revocation schemes are defined, and the AC issuer should elect 1098 the one that is best suited to the environment in which the AC will 1099 be employed. 1101 "Never revoke" scheme: 1103 ACs may be marked so that the relying party understands that no 1104 revocation status information will be made available. The 1105 noRevAvail extension is defined in section 4.3.6, and the 1106 noRevAvail extension MUST be present in the AC to indicate use 1107 of this scheme. 1109 Where no noRevAvail is not present, then the AC issuer is 1110 implicitly stating that revocation status checks are supported, 1111 and some revocation method MUST be provided to allow AC 1112 verifiers to establish the revocation status of the AC. 1114 "Pointer in AC" scheme: 1116 ACs may "point" to sources of revocation status information, 1117 using either an authorityInfoAccess extension or a 1118 crlDistributionPoints extension within the AC. 1120 For AC users, the "never revoke" scheme MUST be supported, and the 1121 "pointer in AC" scheme SHOULD be supported. If only the "never 1122 revoke" scheme is supported, then all ACs that do not contain a 1123 noRevAvail extension, MUST be rejected. 1125 For AC issuers, the "never revoke" scheme MUST be supported. If all 1126 ACs that will ever be issued by that AC issuer, will contain a 1127 noRevAvail extension, then the "pointer in AC" scheme need not be 1128 supported. If any AC can be issued that does not contain the 1129 noRevAvail extension, then the "pointer in AC" scheme MUST be 1130 supported. 1132 An AC verifier MAY use any source for AC revocation status 1133 information. 1135 7. Optional Features 1137 This section specifies features that MAY be implemented. Conformance 1138 to this profile does NOT require support for these features; 1139 however, if these features are offered, they MUST be offered as 1140 described below. 1142 7.1 Attribute Encryption 1144 Where an AC will be carried in clear within an application protocol 1145 or where an AC contains some sensitive information like a legacy 1146 application username/password, then encryption of AC attributes MAY 1147 be needed. 1149 When a set of attributes are to be encrypted within an AC, the 1150 Cryptographic Message Syntax, EnvelopedData structure [CMS] is used 1151 to carry the ciphertext and associated per-recipient keying 1152 information. 1154 This type of attribute encryption is targeted. Before the AC is 1155 signed, the attributes are encrypted for a set of predetermined 1156 recipients. 1158 The AC then contains the ciphertext inside its signed data. The 1159 EenvelopedData (id-envelopedData) ContentType is used, and the 1160 content field will contain the EnvelopedData type. 1162 The ciphertext is included in the AC as the value of an encAttrs 1163 attribute. Only one encAttrs attribute can be present in an AC; 1164 however, the encAttrs attribute MAY be multi-valued, and each of its 1165 values will contain an independent EnvelopedData. 1167 Each value can contain a set of attributes (each possibly a multi- 1168 valued attribute) encrypted for a set of predetermined recipients. 1170 The cleartext that is encrypted has the type: 1172 ACClearAttrs ::= SEQUENCE { 1173 acIssuer GeneralName, 1174 acSerial INTEGER, 1175 attrs SEQUENCE OF Attribute 1176 } 1178 The DER encoding of the ACClearAttrs structure is used as the 1179 encryptedContent field of the EnvelopedData. The DER encoding MUST 1180 be embedded in an OCTET STRING. 1182 The acIssuer and acSerial fields are present to prevent ciphertext 1183 stealing. When an AC verifier has successfully decrypted an 1184 encrypted attribute it MUST then check that the AC issuer and 1185 serialNumber fields contain the same values. This prevents a 1186 malicious AC issuer from copying ciphertext from another AC (without 1187 knowing its corresponding plaintext). 1189 The procedure for an AC issuer when encrypting attributes is 1190 illustrated by the following (any other procedure that gives the 1191 same result MAY be used): 1193 1. Identify the sets of attributes that are to be encrypted for 1194 each set of recipients. 1195 2. For each attribute set which is to be encrypted: 1196 2.1. Create an EnvelopedData structure for the data for this 1197 set of recipients. 1198 2.2. Encode the ContentInfo containing the EnvelopedData as a 1199 value of the encAttrs attribute 1200 2.3. Ensure the cleartext attributes are not present in the 1201 to-be-signed AC 1202 3. Add the encAttrs (with its multiple values) to the AC 1204 Note that there may be more than one attribute of the same type (the 1205 same OBJECT IDENTIFIER) after decryption. That is, an AC MAY contain 1206 the same attribute type both in clear and in encrypted form (and 1207 indeed several times if the same recipient is associated with more 1208 than one EnvelopedData). One approach implementers may choose, would 1209 be to merge attributes values following decryption in order to re- 1210 establish the "once only" constraint. 1212 name id-aca-encAttrs 1213 OID { id-aca 6} 1214 Syntax ContentInfo 1215 values Multiple Allowed 1217 If an AC contains attributes apparently encrypted for the AC 1218 verifier, then the decryption process MUST not fail. If decryption 1219 does fail, then the AC MUST be rejected. 1221 7.2 Proxying 1223 When a server acts as a client for another server on behalf of the 1224 AC holder, the server MAY need to proxy an AC. Such proxying MAY 1225 have to be done under the AC issuer's control, so that not every AC 1226 is proxiable and so that a given proxiable AC can be proxied in a 1227 targeted fashion. Support for chains of proxies (with more than one 1228 intermediate server) MAY also be required. Note that this does not 1229 involve a chain of ACs. 1231 In order to meet this requirement we define another extension, 1232 ProxyInfo, similar to the targeting extension. 1234 When this extension is present, the AC verifier must check that the 1235 entity from which the AC was received was allowed to send it and 1236 that the AC is allowed to be used by this verifier. 1238 The proxying information consists of a set of proxy information, 1239 each of which is a set of targeting information. If the verifier and 1240 the sender of the AC are both named in the same proxy set then the 1241 AC can be accepted (the exact rule is given below). 1243 The effect is that the AC holder can send the AC to any valid target 1244 which can then only proxy to targets which are in one of the same 1245 proxy sets as itself. 1247 The following data structure is used to represent the 1248 targeting/proxying information. 1250 ProxyInfo ::= SEQUENCE OF Targets 1252 As in the case of targeting, the targetCert CHOICE MUST NOT be used. 1254 A proxy check succeeds if either one of the conditions below is met: 1256 1. The identity of the sender as established by the underlying 1257 authentication service matches the holder field of the AC, and the 1258 current server "matches" any one of the proxy sets. Recall that 1259 "matches" is as defined section 4.3.2. 1261 2. The identity of the sender as established by the underlying 1262 authentication service "matches" one of the proxy sets (call it 1263 set "A"), and the current server is one of the targetName fields 1264 in the set "A", or the current server is a member of one of the 1265 targetGroup fields in set "A". 1267 When an AC is proxied more than once, a number of targets will be on 1268 the path from the original client, which is normally, but not 1269 always, the AC holder. In such cases, prevention of AC "stealing" 1270 requires that the AC verifier MUST check that all targets on the 1271 path are members of the same proxy set. It is the responsibility of 1272 the AC using protocol to ensure that a trustworthy list of targets 1273 on the path is available to the AC verifier. 1275 name id-pe-ac-proxying 1276 OID { id-pe 10 } 1277 syntax ProxyInfo 1278 criticality MUST be TRUE 1280 7.3 Use of ObjectDigestInfo 1282 In some environments, it may be required that the AC is not linked 1283 either to an identity (via entityName) or to a PKC (via 1284 baseCertificateID). The objectDigestInfo CHOICE in the holder field 1285 allows support for this requirement. 1287 If the holder is identified with the objectDigestInfo field, then 1288 the AC version field MUST contain v2 (the integer 1). 1290 The idea is to link the AC to an object by placing a hash of that 1291 object into the holder field of the AC. For example, this allows 1292 production of ACs that are linked to public keys rather than names. 1294 It also allows production of ACs which contain privileges associated 1295 with an executable object such as a Java class. However, this 1296 profile only specifies how to use a hash over a public key or PKC. 1297 That is, conformant ACs MUST NOT use the otherObjectTypes value for 1298 the digestedObjectType. 1300 To link an AC to a public key, the hash must be calculated over the 1301 representation of that public key which would be present in a PKC, 1302 specifically, the input for the hash algorithm MUST be the DER 1303 encoding of a SubjectPublicKeyInfo representation of the key. Note: 1304 This includes the AlgorithmIdentifier as well as the BIT STRING. The 1305 rules given in [PKIXPROF] for encoding keys MUST be followed. In 1306 this case the digestedObjectType MUST be publicKey and the 1307 otherObjectTypeID field MUST NOT be present. 1309 Note that if the public key value used as input to the hash function 1310 has been extracted from a PKC, then it is possible that the 1311 SubjectPublicKeyInfo from that PKC is NOT the value which should be 1312 hashed. This can occur if DSA Dss-parms are inherited as described 1313 in section 7.3.3 of [PKIXPROF]. The correct input for hashing in 1314 this context will include the value of the parameters inherited from 1315 the CA's PKC, and thus may differ from the SubjectPublicKeyInfo 1316 present in the PKC. 1318 Implementations which support this feature MUST be able to handle 1319 the representations of public keys for the algorithms specified in 1320 section 7.3 of [PKIXPROF]. In this case the digestedObjectType MUST 1321 be publicKey and the otherObjectTypeID field MUST NOT be present. 1323 In order to link an AC to a PKC via a digest, the digest MUST be 1324 calculated over the DER encoding of the entire PKC, including the 1325 signature value. In this case the digestedObjectType MUST be 1326 publicKeyCert and the otherObjectTypeID field MUST NOT be present. 1328 7.4 AA Controls 1330 During AC validation a relying party has to answer the question: is 1331 this AC issuer trusted to issue ACs containing this attribute? The 1332 AAControls PKC extension MAY be used to help answer the question. 1333 The AAControls extension is intended to be used in CA and AC issuer 1334 PKCs. 1336 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1338 AAControls ::= SEQUENCE { 1339 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1340 permittedAttrs [0] AttrSpec OPTIONAL, 1341 excludedAttrs [1] AttrSpec OPTIONAL, 1342 permitUnSpecified BOOLEAN DEFAULT TRUE 1343 } 1345 AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER 1347 The AAControls extension is used as follows: 1349 The pathLenConstraint, if present, is interpreted as in [PKIXPROF]. 1350 It restricts the allowed distance between the AA CA, (a CA directly 1351 trusted to include AAControls in its PKCs), and the AC issuer. 1353 The permittedAttrs field specifies a set of attribute types that any 1354 AC issuer below this AA CA is allowed to include in ACs. If this 1355 field is not present, it means that no attribute types are 1356 explicitly allowed. 1358 The excludedAttrs field specifies a set of attribute types that no 1359 AC issuer is allowed to include in ACs. If this field is not 1360 present, it means that no attribute types are explicitly disallowed. 1362 The permitUnSpecified field specifies how to handle attribute types 1363 which are not present in either the permittedAttrs or excludedAttrs 1364 fields. TRUE (the default) means that any unspecified attribute type 1365 is allowed in ACs; FALSE means that no unspecified attribute type is 1366 allowed. 1368 When AAControls are used, the following additional checks on an AA's 1369 PKC chain MUST all succeed for the AC to be valid: 1371 1. Some CA on the ACs certificate path MUST be directly trusted to 1372 issue PKCs which precede the AC issuer in the certification 1373 path, call this CA the "AA CA". 1374 2. All PKCs on the path from the AA CA down to and including the 1375 AC issuer's PKC MUST contain an AAControls extension; however, 1376 the AA CA's PKC need not contain this extension. 1377 3. Only those attributes in the AC which are allowed according to 1378 all of the AAControls extension values in all of the PKCs from 1379 the AA CA to the AC issuer, may be used for authorization 1380 decisions, all other attributes MUST be ignored. This check 1381 MUST be applied to the set of attributes following attribute 1382 decryption, and the id-aca-encAttrs type MUST also be checked. 1384 name id-pe-aaControls 1385 OID { id-pe 6 } 1386 syntax AAControls 1387 criticality MAY be TRUE 1389 8. Security Considerations 1391 The protection afforded for private keys is a critical factor in 1392 maintaining security. Failure of AC issuers to protect their 1393 private keys will permit an attacker to masquerade as them, 1394 potentially generating false ACs or revocation status. Existence of 1395 bogus ACs and revocation status will undermine confidence in the 1396 system. If the compromise is detected, all ACs issued by the AC 1397 issuer MUST be revoked. Rebuilding after such a compromise will be 1398 problematic, so AC issuers are advised to implement a combination of 1399 strong technical measures (e.g., tamper-resistant cryptographic 1400 modules) and appropriate management procedures (e.g., separation of 1401 duties) to avoid such an incident. 1403 Loss of an AC issuer's private signing key may also be problematic. 1404 The AC issuer would not be able to produce revocation status or 1405 perform AC renewal. AC issuers are advised to maintain secure backup 1406 for signing keys. The security of the key backup procedures is a 1407 critical factor in avoiding key compromise. 1409 The availability and freshness of revocation status will affect the 1410 degree of assurance that should be placed in a long-lived AC. While 1411 long-lived ACs expire naturally, events may occur during its natural 1412 lifetime which negate the binding between the AC holder and the 1413 attributes. If revocation status is untimely or unavailable, the 1414 assurance associated with the binding is clearly reduced. 1416 The binding between an AC holder and attributes cannot be stronger 1417 than the cryptographic module implementation and algorithms used to 1418 generate the signature. Short key lengths or weak hash algorithms 1419 will limit the utility of an AC. AC issuers are encouraged to note 1420 advances in cryptology so they can employ strong cryptographic 1421 techniques. 1423 Inconsistent application of name comparison rules may result in 1424 acceptance of invalid targeted or proxied ACs, or rejection of valid 1425 ones. The X.500 series of specifications defines rules for 1426 comparing distinguished names. These rules require comparison of 1427 strings without regard to case, character set, multi-character white 1428 space substrings, or leading and trailing white space. This 1429 specification and [PKIXPROF] relaxes these requirements, requiring 1430 support for binary comparison at a minimum. 1432 AC issuers MUST encode the distinguished name in the AC 1433 holder.entityName field identically to the distinguished name in the 1434 holder's PKC. If different encodings are used, implementations of 1435 this specification may fail to recognize that the AC and PKC belong 1436 to the same entity. 1438 If an attribute certificate is tied to the holder's PKC using the 1439 baseCertificateID component of the Holder field and the PKI in use 1440 includes a rogue CA with the same issuer name specified in the 1441 baseCertificateID component, this rogue CA could issue a PKC to a 1442 malicious party, using the same issuer name and serial number as the 1443 proper holder's PKC. Then the malicious party could use this PKC in 1444 conjunction with the AC. This scenario SHOULD be avoided by properly 1445 managing and configuring the PKI so that there cannot be two CAs 1446 with the same name. Another alternative is to tie ACs to PKCs using 1447 the publicKeyCert type in the ObjectDigestInfo field. Failing this, 1448 AC verifiers have to establish (using other means) that the 1449 potential collisions cannot actually occur, for example, the CPSs of 1450 the CAs involved may make it clear that no such name collisions can 1451 occur. 1453 Implementers MUST ensure that following validation of an AC, only 1454 attributes that the issuer is trusted to issue are used in 1455 authorization decisions. Other attributes, which MAY be present MUST 1456 be ignored. Given that the AA controls PKC extension is optional to 1457 implement, AC verifiers MUST be provided with this information by 1458 other means. Configuration information is a likely alternative 1459 means. This becomes very important if an AC verifier trusts more 1460 than one AC issuer. 1462 There is often a requirement to map between the authentication 1463 supplied by a particular security protocol (e.g. TLS, S/MIME) and 1464 the AC holder's identity. If the authentication uses PKCs, then this 1465 mapping is straightforward. However, it is envisaged that ACs will 1466 also be used in environments where the holder may be authenticated 1467 using other means. Implementers SHOULD be very careful in mapping 1468 the authenticated identity to the AC holder. 1470 9. IANA Considerations 1472 The OIDs used in this document have been delegated by the IANA and 1473 no further action by the IANA is necessary for this document or any 1474 anticipated updates. 1476 10. References 1478 [CMC] Myers, M., et al. "Certificate Management Messages over 1479 CMS", RFC2797. 1480 [CMP] Adams, C., Farrell, S., "Internet X.509 Public Key 1481 Infrastructure - Certificate Management Protocols", 1482 RFC2510. 1483 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630. 1484 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 1485 RFC2634. 1486 [KRB] Kohl, J., Neuman, C., "The Kerberos Network 1487 Authentication Service (V5)", RFC 1510. 1488 [LDAP] Wahl, M., et al., "Lightweight Directory Access Protocol 1489 (v3)", RFC 2251. 1490 [OCSP] Myers, M., et al., " X.509 Internet Public Key 1491 Infrastructure - Online Certificate Status Protocol - 1492 OCSP", RFC 2560. 1493 [PKIXALGS] Polk, T., Bassham, L., "Internet X.509 Public Key 1494 Infrastructure Representation of Public Keys and Digital 1495 Signatures in Internet X.509 Public Key Infrastructure 1496 Certificates", draft-ietf-pkix-pkalgs-01.txt, work-in- 1497 progress. 1498 [PKINIT] Tung, B., et al., "Public Key Cryptography for Initial 1499 Authentication in Kerberos", draft-ietf-cat-kerberos-pk- 1500 init-12.txt, work-in-progress. 1501 [PKIXPROF] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet 1502 Public Key Infrastructure - X.509 Certificate and CRL 1503 Profile", draft-ietf-pkix-new-part1-03.txt, work-in- 1504 progress. 1505 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1506 3", RFC 2026, BCP 9, October 1996. 1507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1508 Requirement Levels", RFC 2119. 1509 [URL] Berners-Lee, T., Masinter L., and M. McCahill., "Uniform 1510 Resource Locators (URL)", RFC 1738. 1511 [X.208-1988]CCITT Recommendation X.208: Specification of Abstract 1512 Syntax Notation One (ASN.1). 1988. 1513 [X.209-88] CCITT Recommendation X.209: Specification of Basic 1514 Encoding Rules for Abstract Syntax Notation One (ASN.1). 1515 1988. 1516 [X.501-88] CCITT Recommendation X.501: The Directory - Models. 1517 1988. 1518 [X.501-1993]ITU-T Recommendation X.501 : Information Technology - 1519 Open Systems Interconnection - The Directory: Models, 1520 1993. 1521 [X.509-1988]CCITT Recommendation X.509: The Directory - 1522 Authentication Framework. 1988. 1523 [X.509-1997]ITU-T Recommendation X.509: The Directory - 1524 Authentication Framework. 1997. 1525 [X.509-2000]ITU-T Recommendation X.509: The Directory - Public-Key 1526 and Attribute Certificate Frameworks. 2000 1528 Author's Addresses 1530 Stephen Farrell 1531 Baltimore Technologies 1532 39/41 Parkgate Street 1533 Dublin 8 1534 IRELAND 1536 email: stephen.farrell@baltimore.ie 1538 Russell Housley 1539 RSA Laboratories 1540 918 Spring Knoll Drive 1541 Herndon, VA 20170 1542 USA 1544 email: rhousley@rsasecurity.com 1546 Full Copyright Statement 1548 Copyright (C) The Internet Society (date). All Rights Reserved. 1550 This document and translations of it may be copied and furnished to 1551 others, and derivative works that comment on or otherwise explain it 1552 or assist in its implementation may be prepared, copied, published 1553 and distributed, in whole or in part, without restriction of any 1554 kind, provided that the above copyright notice and this paragraph 1555 are included on all such copies and derivative works. In addition, 1556 the ASN.1 module presented in Appendix B may be used in whole or in 1557 part without inclusion of the copyright notice. However, this 1558 document itself may not be modified in any way, such as by removing 1559 the copyright notice or references to the Internet Society or other 1560 Internet organizations, except as needed for the purpose of 1561 developing Internet standards in which case the procedures for 1562 copyrights defined in the Internet Standards process shall be 1563 followed, or as required to translate it into languages other than 1564 English. 1566 The limited permissions granted above are perpetual and will not be 1567 revoked by the Internet Society or its successors or assigns. This 1568 document and the information contained herein is provided on an "AS 1569 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1570 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1571 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1572 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1573 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1575 Appendix A: Object Identifiers 1577 This (normative) appendix lists the new object identifiers which are 1578 defined in this specification. Some of these are required only for 1579 support of optional features and are not required for conformance to 1580 this profile. This specification mandates support for OIDs which 1581 have arc elements with values that are less than 2^32, (i.e. they 1582 MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less 1583 than 2^31 (i.e. less than or equal to 2,147,483,647). This allows 1584 each arc element to be represented within a single 32 bit word. 1585 Implementations MUST also support OIDs where the length of the 1586 dotted decimal (see [LDAP], section 4.1.2) string representation can 1587 be up to 100 bytes (inclusive). Implementations MUST be able to 1588 handle OIDs with up to 20 elements (inclusive). AA's SHOULD NOT 1589 issue ACs which contain OIDs that breach these requirements. 1591 The following OIDs are imported from [PKIXPROF]: 1593 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1594 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 1595 id-mod OBJECT IDENTIFIER ::= { id-pkix 0 } 1596 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 1597 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 1598 id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } 1599 id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 } 1601 The following new ASN.1 module OID is defined: 1603 id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 } 1605 The following AC extension OIDs are defined: 1607 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1608 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 } 1609 id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 1611 The following PKC extension OIDs are defined: 1613 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1615 The following attribute OIDs are defined: 1617 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1618 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1619 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1620 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1621 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1622 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1623 id-at-role OBJECT IDENTIFIER ::= { id-at 72 } 1624 id-at-clearance OBJECT IDENTIFIER ::= 1625 { joint-iso-ccitt(2) ds(5) module(1) 1626 selected-attribute-types(5) clearance (55) } 1628 Appendix B: ASN.1 Module 1630 PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) 1631 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1632 id-mod-attribute-cert(12)} 1634 DEFINITIONS IMPLICIT TAGS ::= 1636 BEGIN 1638 -- EXPORTS ALL -- 1640 IMPORTS 1642 -- IMPORTed module OIDs MAY change if [PKIXPROF] changes 1643 -- PKIX Certificate Extensions 1644 Attribute, AlgorithmIdentifier, CertificateSerialNumber, 1645 Extensions, UniqueIdentifier, 1646 id-pkix, id-pe, id-kp, id-ad, id-at 1647 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 1648 dod(6) internet(1) security(5) mechanisms(5) 1649 pkix(7) id-mod(0) id-pkix1-explicit-88(1)} 1651 GeneralName, GeneralNames, id-ce 1652 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 1653 dod(6) internet(1) security(5) mechanisms(5) 1654 pkix(7) id-mod(0) id-pkix1-implicit-88(2)} ; 1656 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1657 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1658 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 } 1659 id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 1661 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1663 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1664 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1665 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1666 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1667 -- { id-aca 5 } is reserved 1668 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1670 id-at-role OBJECT IDENTIFIER ::= { id-at 72} 1671 id-at-clearance OBJECT IDENTIFIER ::= 1672 { joint-iso-ccitt(2) ds(5) module(1) 1673 selected-attribute-types(5) clearance (55) } 1675 -- Uncomment this if using a 1988 level ASN.1 compiler 1676 -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 1678 AttributeCertificate ::= SEQUENCE { 1679 acinfo AttributeCertificateInfo, 1680 signatureAlgorithm AlgorithmIdentifier, 1681 signatureValue BIT STRING 1682 } 1684 AttributeCertificateInfo ::= SEQUENCE { 1685 version AttCertVersion -- version is v2, 1686 holder Holder, 1687 issuer AttCertIssuer, 1688 signature AlgorithmIdentifier, 1689 serialNumber CertificateSerialNumber, 1690 attrCertValidityPeriod AttCertValidityPeriod, 1691 attributes SEQUENCE OF Attribute, 1692 issuerUniqueID UniqueIdentifier OPTIONAL, 1693 extensions Extensions OPTIONAL 1694 } 1696 AttCertVersion ::= INTEGER { v2(1) } 1698 Holder ::= SEQUENCE { 1699 baseCertificateID [0] IssuerSerial OPTIONAL, 1700 -- the issuer and serial number of 1701 -- the holder's Public Key Certificate 1702 entityName [1] GeneralNames OPTIONAL, 1703 -- the name of the claimant or role 1704 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 1705 -- if present, version must be v2 1706 } 1708 ObjectDigestInfo ::= SEQUENCE { 1709 digestedObjectType ENUMERATED { 1710 publicKey (0), 1711 publicKeyCert (1), 1712 otherObjectTypes (2) }, 1713 -- otherObjectTypes MUST NOT 1714 -- MUST NOT be used in this profile 1715 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 1716 digestAlgorithm AlgorithmIdentifier, 1717 objectDigest BIT STRING 1718 } 1720 AttCertIssuer ::= CHOICE { 1721 v1Form GeneralNames, -- v1 or v2 1722 v2Form [0] V2Form -- v2 only 1723 } 1725 V2Form ::= SEQUENCE { 1726 issuerName GeneralNames OPTIONAL, 1727 baseCertificateID [0] IssuerSerial OPTIONAL, 1728 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 1729 -- at least one of issuerName, baseCertificateID 1730 -- or objectDigestInfo must be present 1731 } 1732 IssuerSerial ::= SEQUENCE { 1733 issuer GeneralNames, 1734 serial CertificateSerialNumber, 1735 issuerUID UniqueIdentifier OPTIONAL 1736 } 1738 AttCertValidityPeriod ::= SEQUENCE { 1739 notBeforeTime GeneralizedTime, 1740 notAfterTime GeneralizedTime 1741 } 1743 Targets ::= SEQUENCE OF Target 1745 Target ::= CHOICE { 1746 targetName [0] GeneralName, 1747 targetGroup [1] GeneralName, 1748 targetCert [2] TargetCert 1749 } 1751 TargetCert ::= SEQUENCE { 1752 targetCertificate IssuerSerial, 1753 targetName GeneralName OPTIONAL, 1754 certDigestInfo ObjectDigestInfo OPTIONAL 1755 } 1757 IetfAttrSyntax ::= SEQUENCE { 1758 policyAuthority[0] GeneralNames OPTIONAL, 1759 values SEQUENCE OF CHOICE { 1760 octets OCTET STRING, 1761 oid OBJECT IDENTIFIER, 1762 string UTF8String 1763 } 1764 } 1766 SvceAuthInfo ::= SEQUENCE { 1767 service GeneralName, 1768 ident GeneralName, 1769 authInfo OCTET STRING OPTIONAL 1770 } 1772 RoleSyntax ::= SEQUENCE { 1773 roleAuthority [0] GeneralNames OPTIONAL, 1774 roleName [1] GeneralName 1775 } 1777 Clearance ::= SEQUENCE { 1778 policyId [0] OBJECT IDENTIFIER, 1779 classList [1] ClassList DEFAULT {unclassified}, 1780 securityCategories 1781 [2] SET OF SecurityCategory OPTIONAL 1782 } 1784 ClassList ::= BIT STRING { 1785 unmarked (0), 1786 unclassified (1), 1787 restricted (2), 1788 confidential (3), 1789 secret (4), 1790 topSecret (5) 1791 } 1793 SecurityCategory ::= SEQUENCE { 1794 type [0] IMPLICIT OBJECT IDENTIFIER, 1795 value [1] ANY DEFINED BY type 1796 } 1798 AAControls ::= SEQUENCE { 1799 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1800 permittedAttrs [0] AttrSpec OPTIONAL, 1801 excludedAttrs [1] AttrSpec OPTIONAL, 1802 permitUnSpecified BOOLEAN DEFAULT TRUE 1803 } 1805 AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER 1807 ACClearAttrs ::= SEQUENCE { 1808 acIssuer GeneralName, 1809 acSerial INTEGER, 1810 attrs SEQUENCE OF Attribute 1811 } 1813 ProxyInfo ::= SEQUENCE OF Targets 1815 END 1817 Appendix C: Change History 1819 <> 1821 This appendix lists major changes since the previous revision. 1823 Major changes since last revision: 1825 Changes from -06 to -07: 1827 1. Added IANA considerations section 1828 2. Changed DEFAULT version to v2 1829 3. Further deprecated v1 syntax since X.509 did 1830 4. Fixed ASN.1 tagging nits 1832 Changes from -05 to -06: 1834 5. Added new item 1 to validation rules in section 5. 1835 6. Added security considerations text about "rogue" CAs. 1836 7. Changed to allow holder.entityName = PKC.subject or 1837 PKC.subjectAltName for the relevant cases & clarified that Holder 1838 should only have one value. 1839 8. Changed to insist on version 2 to avoid clash with possibly ISO 1840 syntax issue. 1841 9. Updated references. 1843 Changes from -04 to -05: 1845 1. Changed from referencing rfc2459 to new-part1 and pkalgs. 1847 Changes from -03 to -04 1849 1. Folding in last call comments. 1850 2. Last bits of synchronizing with X.509 2000 spec. 1852 Changes from -02 to -03 1854 1. Many minor editorial changes 1855 2. Changed OID max element arc text in app. A 1856 3. Removed restriction on Clearance SecurityValue syntaxes to allow 1857 support for various existing clearance schemes 1858 4. Finalized alignment with 4th edition of X.509 1860 Changes from -01 to -02 1862 1. Re-Synchronized with X.509 DAM 1863 2. Deleted AC chains concept 1864 3. Moved AAControls to "optional features" section 1865 4. Samples will be a separate draft 1866 5. Revocation: now using X.509 DAM (noRevAvail) and standard 2459 1867 mechanisms only 1869 6. Deleted the special wildcard target "ALL" 1871 Changes from -00 to -01 1873 1. Re-structured conformance to profile + options as per Oslo 1874 consensus 1875 2. Moved acquisition protocol (LAAP)_to separate I-D 1876 3. Removed restrictions entirely 1877 4. Added new AC revocation options 1878 5. Added optional support for use of objectDigestInfo for keys 1879 6. Added optional support for chains of ACs 1880 7. Changed some syntax: 1881 Added UTF8String to IetfAttrSyntax value choice 1882 Split target & proxy extensions, removed owner from proxyInfo 1883 8. Allocated PKIX OIDs (note: check with repository before using 1884 these, the PKIX arc is currently available at 1885 http://www.imc.org/ietf-pkix/pkix-oid.asn) 1886 9. Added compiled ASN.1 module