idnits 2.17.00 (12 Aug 2021) /tmp/idnits32989/draft-ietf-pkix-ac509prof-06.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 270 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 (January 2001) is 7795 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 1791 -- Looks like a reference, but probably isn't: '1' on line 1792 -- Looks like a reference, but probably isn't: '2' on line 1739 == Missing Reference: 'UNIVERSAL 12' is mentioned on line 1667, but not defined == Unused Reference: 'CMC' is defined on line 1466, but no explicit reference was found in the text == Unused Reference: 'CMP' is defined on line 1468, but no explicit reference was found in the text == Unused Reference: 'ESS' is defined on line 1472, 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: 12 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 10th January 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............................................13 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. References..................................................31 92 Author's Addresses.............................................32 93 Full Copyright Statement.......................................32 94 Appendix A: Object Identifiers.................................33 95 Appendix B: ASN.1 Module.......................................34 97 1. Introduction 99 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 100 in this document are to be interpreted as described in [RFC2119]. 102 X.509 public key certificates (PKCs) [X.509-1997, X.509-2000, 103 PKIXPROF] bind an identity and a public key. An attribute 104 certificate (AC) is a structure similar to a PKC; the main 105 difference being that the AC contains no public key. An AC may 106 contain attributes that specify group membership, role, security 107 clearance, or other authorization information associated with the AC 108 holder. The syntax for the AC is defined in Recommendation X.509, 109 making the term "X.509 certificate" ambiguous. 111 Some people constantly confuse PKCs and ACs. An analogy may make the 112 distinction clear. A PKC can be considered to be like a passport: it 113 identifies the holder, tends to last for a long time, and should not 114 be trivial to obtain. An AC is more like an entry visa: it is 115 typically issued by a different authority and does not last for as 116 long a time. As acquiring an entry visa typically requires 117 presenting a passport, getting a visa can be a simpler process. 119 Authorization information may be placed in a PKC extension or placed 120 in a separate attribute certificate (AC). The placement of 121 authorization information in PKCs is usually undesirable for two 122 reasons. First, authorization information often does not have the 123 same lifetime as the binding of the identity and the public key. 124 When authorization information is placed in a PKC extension, the 125 general result is the shortening of the PKC useful lifetime. Second, 126 the PKC issuer is not usually authoritative for the authorization 127 information. This results in additional steps for the PKC issuer to 128 obtain authorization information from the authoritative source. 130 For these reasons, it is often better to separate authorization 131 information from the PKC. Yet, authorization information also needs 132 to be bound to an identity. An AC provides this binding; it is 133 simply a digitally signed (or certified) identity and set of 134 attributes. 136 An AC may be used with various security services, including access 137 control, data origin authentication, and non-repudiation. 139 PKCs can provide an identity to access control decision functions. 140 However, in many contexts the identity is not the criterion that is 141 used for access control decisions, rather the role or group- 142 membership of the accessor is the criterion used. Such access 143 control schemes are called role-based access control. 145 When making an access control decision based on an AC, an access 146 control decision function may need to ensure that the appropriate AC 147 holder is the entity that has requested access. One way in which the 148 linkage between the request or identity and the AC can be achieved 149 is the inclusion of a reference to a PKC within the AC and the use 150 of the private key corresponding to the PKC for authentication 151 within the access request. 153 ACs may also be used in the context of a data origin authentication 154 service and a non-repudiation service. In these contexts, the 155 attributes contained in the AC provide additional information about 156 the signing entity. This information can be used to make sure that 157 the entity is authorized to sign the data. This kind of checking 158 depends either on the context in which the data is exchanged or on 159 the data that has been digitally signed. 161 1.1 Delegation and AC chains 163 The X.509 standard [X.509-2000] defines authorization as the 164 "conveyance of privilege from one entity that holds such privilege, 165 to another entity". An AC is one authorization mechanism. 167 An ordered sequence of ACs could be used to verify the authenticity 168 of a privilege asserter's privilege. In this way, chains or paths of 169 ACs could be employed to delegate authorization. 171 Since the administration and processing associated with such AC 172 chains is complex and the use of ACs in the Internet today is quite 173 limited, this specification does NOT RECOMMEND the use of AC chains. 174 Other (future) specifications may address the use of AC chains. This 175 specification deals with the simple cases where one authority issues 176 all of the ACs for a particular set of attributes. However, this 177 simplification does not preclude the use of several different 178 authorities, each of which manages a different set of attributes. 179 For example, group membership may be included in one AC issued by 180 one authority, and security clearance may be included in another AC 181 issued by another authority. 183 This means that conformant implementations are only REQUIRED to be 184 able to process a single AC at a time. Processing of more than one 185 AC, one after another, may be necessary. Note however, that 186 validation of an AC MAY require validation of a chain of PKCs, as 187 specified in [PKIXPROF]. 189 1.2 Attribute Certificate Distribution ("push" vs. "pull") 191 As discussed above, ACs provide a mechanism to securely provide 192 authorization information to, for example, access control decision 193 functions. However, there are a number of possible communication 194 paths for ACs. 196 In some environments it is suitable for a client to "push" an AC to 197 a server. This means that no new connections between the client and 198 server are required. It also means that no search burden is imposed 199 on servers, which improves performance and that the AC verifier is 200 only presented with what it "needs to know." In inter-domain cases 201 where the client's rights should be assigned within client's "home" 202 domain, the "push" model is especially suitable. 204 In other cases, it is more suitable for a client simply to 205 authenticate to the server and for the server to request or "pull" 206 the client's AC from an AC issuer or a repository. A major benefit 207 of the "pull" model is that it can be implemented without changes to 208 the client or to the client-server protocol. The "pull" model is 209 especially suitable for inter-domain cases where the client's rights 210 should be assigned within the server's domain, rather than within 211 the client's domain. 213 There are a number of possible exchanges involving three entities: 214 the client, the server, and the AC issuer. In addition, a directory 215 service or other repository for AC retrieval MAY be supported. 217 Figure 1 shows an abstract view of the exchanges that may involve 218 ACs. This profile does not specify a protocol for these exchanges. 220 +--------------+ 221 | | Server Acquisition 222 | AC issuer +----------------------------+ 223 | | | 224 +--+-----------+ | 225 | | 226 | Client | 227 | Acquisition | 228 | | 229 +--+-----------+ +--+------------+ 230 | | AC "push" | | 231 | Client +-------------------------+ Server | 232 | | (part of app. protocol) | | 233 +--+-----------+ +--+------------+ 234 | | 235 | Client | Server 236 | Lookup +--------------+ | Lookup 237 | | | | 238 +---------------+ Repository +---------+ 239 | | 240 +--------------+ 242 Figure 1: AC Exchanges 244 1.3 Document Structure 246 Section 2 defines some terminology. Section 3 specifies the 247 requirements that this profile is intended to meet.; Section 4 248 contains the profile of the X.509 AC. Section 5 specifies rules for 249 AC validation. Section 6 specifies rules for AC revocation checks. 250 Section 7 specifies optional features which MAY be supported; 251 however, support for these features is not required for conformance 252 to this profile. Finally, appendices contain the list of OIDs 253 required to support this specification and an ASN.1 module. 255 2. Terminology 257 For simplicity, we use the terms client and server in this 258 specification. This is not intended to indicate that ACs are only to 259 be used in client-server environments. For example, ACs may be used 260 in the S/MIME v3 context, where the mail user agent would be both a 261 "client" and a "server" in the sense the terms are used here. 263 Term Meaning 265 AA Attribute Authority, the entity that issues the 266 AC, synonymous in this specification with "AC 267 issuer" 268 AC Attribute Certificate 269 AC user any entity that parses or processes an AC 270 AC verifier any entity that checks the validity of an AC and 271 then makes use of the result 272 AC issuer the entity which signs the AC, synonymous in this 273 specification with "AA" 274 AC holder the entity indicated (perhaps indirectly) in the 275 holder field of the AC 276 Client the entity which is requesting the action for 277 which authorization checks are to be made 278 Proxying In this specification, Proxying is used to mean 279 the situation where an application server acts as 280 an application client on behalf of a user. 281 Proxying here does not mean granting of authority. 282 PKC Public Key Certificate - uses the type ASN.1 283 Certificate defined in X.509 and profiled in RFC 284 2459. This (non-standard) acronym is used in order 285 to avoid confusion about the term "X.509 286 certificate". 287 Server the entity which requires that the authorization 288 checks are made 290 3. Requirements 292 This AC profile meets the following requirements. 294 Time/Validity requirements: 296 1. Support for short-lived as well as long-lived ACs. Typical 297 short-lived validity periods might be measured in hours, as 298 opposed to months for PKCs. Short validity periods allow ACs to 299 be useful without a revocation mechanism. 301 Attribute Types: 303 2. Issuers of ACs should be able to define their own attribute 304 types for use within closed domains. 305 3. Some standard attribute types should be defined which can be 306 contained within ACs. Examples include "access identity," 307 "group," "role," "clearance," "audit identity," and "charging 308 identity." 309 4. Standard attribute types should be defined in a manner that 310 permits an AC verifier to distinguish between uses of the same 311 attribute in different domains. For example, the 312 "Administrators group" as defined by Baltimore and the 313 "Administrators group" as defined by SPYRUS should be easily 314 distinguished. 316 Targeting of ACs: 318 5. It should be possible to "target" an AC at one, or a small 319 number of, servers. This means that a trustworthy non-target 320 server will reject the AC for authorization decisions. 322 Push vs. Pull 324 6. ACs should be defined so that they can either be "pushed" by 325 the client to the server, or "pulled" by the server from a 326 repository or other network service, including an online AC 327 issuer. 329 4. Attribute Certificate Profile 331 ACs may be used in a wide range of applications and environments 332 covering a broad spectrum of interoperability goals and a broader 333 spectrum of operational and assurance requirements. The goal of 334 this document is to establish a common baseline for generic 335 applications requiring broad interoperability and limited special 336 purpose requirements. In particular, the emphasis will be on 337 supporting the use of attribute certificates for informal Internet 338 electronic mail, IPSec, and WWW applications. 340 This section presents a profile for ACs that will foster 341 interoperability. This section also defines some private extensions 342 for the Internet community. 344 While the ISO/IEC/ITU documents use the 1993 (or later) version of 345 ASN.1; this document uses the 1988 ASN.1 syntax, as has been done 346 for PKCs [PKIXPROF]. The encoded certificates and extensions from 347 either ASN.1 version are bit-wise identical. 349 Where maximum lengths for fields are specified, these lengths refer 350 to the DER encoding and do not include the ASN.1 tag or length 351 fields. 353 Conforming implementations MUST support the profile specified in 354 this section. 356 4.1 X.509 Attribute Certificate Definition 358 X.509 contains the definition of an AC given below. All types that 359 are not defined in this document can be found in [PKIXPROF]. 361 AttributeCertificate ::= SEQUENCE { 362 acinfo AttributeCertificateInfo, 363 signatureAlgorithm AlgorithmIdentifier, 364 signatureValue BIT STRING 365 } 367 AttributeCertificateInfo ::= SEQUENCE { 368 version AttCertVersion DEFAULT v1, 369 holder Holder, 370 issuer AttCertIssuer, 371 signature AlgorithmIdentifier, 372 serialNumber CertificateSerialNumber, 373 attrCertValidityPeriod AttCertValidityPeriod, 374 attributes SEQUENCE OF Attribute, 375 issuerUniqueID UniqueIdentifier OPTIONAL, 376 extensions Extensions OPTIONAL 377 } 379 AttCertVersion ::= INTEGER { v1(0), v2(1) } 380 Holder ::= SEQUENCE { 381 baseCertificateID [0] IssuerSerial OPTIONAL, 382 -- the issuer and serial number of 383 -- the holder's Public Key Certificate 384 entityName [1] GeneralNames OPTIONAL, 385 -- the name of the claimant or role 386 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 387 -- if present, version must be v2 388 } 390 ObjectDigestInfo ::= SEQUENCE { 391 digestedObjectType ENUMERATED { 392 publicKey (0), 393 publicKeyCert (1), 394 otherObjectTypes (2) }, 395 -- otherObjectTypes MUST NOT 396 -- be used in this profile 397 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 398 digestAlgorithm AlgorithmIdentifier, 399 objectDigest BIT STRING 400 } 402 AttCertIssuer ::= CHOICE { 403 v1Form GeneralNames, -- v1 or v2 404 v2Form [0] V2Form -- v2 only 405 } 407 V2Form ::= SEQUENCE { 408 issuerName GeneralNames OPTIONAL, 409 baseCertificateID [0] IssuerSerial OPTIONAL, 410 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 411 -- at least one of issuerName, baseCertificateID 412 -- or objectDigestInfo MUST be present 413 } 415 IssuerSerial ::= SEQUENCE { 416 issuer GeneralNames, 417 serial CertificateSerialNumber, 418 issuerUID UniqueIdentifier OPTIONAL 419 } 421 AttCertValidityPeriod ::= SEQUENCE { 422 notBeforeTime GeneralizedTime, 423 notAfterTime GeneralizedTime 424 } 426 Although the Attribute syntax is defined in [PKIXPROF], we repeat 427 the definition here for convenience. 429 Attribute ::= SEQUENCE { 430 type AttributeType, 431 values SET OF AttributeValue 432 -- at least one value is required 433 } 435 AttributeType ::= OBJECT IDENTIFIER 437 AttributeValue ::= ANY DEFINED BY AttributeType 439 Implementers should note that the DER encoding (see [X.509- 440 1988],[X.208-1988]) of the SET OF values requires ordering of the 441 encodings of the values. Though this issue arises with respect to 442 distinguished names, and has to be handled by [PKIXPROF] 443 implementations, its is much more significant in this context, since 444 the inclusion of multiple values is much more common in ACs. 446 4.2 Profile of Standard Fields 448 For all GeneralName fields in this profile the otherName (except as 449 noted below), x400Address, ediPartyName and registeredID options 450 MUST NOT be used. The use of Kerberos [KRB] principal names, 451 encoded into the otherName, SHOULD however, be supported using the 452 krb5PrincipalName OID and the KerberosName syntax as defined in 453 [PKINIT]. 455 Conforming implementations MUST be able to support the dNSName, 456 directoryName, uniformResourceIdentifier, and iPAddress fields in 457 all cases where GeneralName is used. This is compatible with the 458 GeneralName requirements in [PKIXPROF] (mainly in section 4.2.1.7). 460 4.2.1 Version 462 The version field MUST be the (non-default) value of v2. That is, 463 the version field is present in the DER encoding. 465 4.2.2 Holder 467 The Holder field is a SEQUENCE allowing three different (optional) 468 syntaxes: baseCertificateID, entityName and objectDigestInfo. Where 469 only one option is present the meaning of the Holder field is clear. 470 However, where more than one option is used, there is potential for 471 confusion as to which option is "normative", which is a "hint" etc. 472 Since the correct position is not clear from [X.509-2000] this 473 specification RECOMMENDS that only one of the options be used in any 474 given AC. 476 For any environment where the AC is passed in an authenticated 477 message or session and where the authentication is based on the use 478 of an X.509 PKC, the holder field SHOULD use the baseCertificateID. 480 With the baseCertificateID option, the holder's PKC serialNumber and 481 issuer MUST be identical to the AC holder field. The PKC issuer MUST 482 have a non-empty distinguished name which is to be present as the 483 single value of the holder.baseCertificateID.issuer construct in the 484 directoryName field. The AC holder.baseCertificateID.issuerUID field 485 MUST only be used if the holder's PKC contains an issuerUniqueID 486 field. If both the AC holder.baseCertificateID.issuerUID and the PKC 487 issuerUniqueID fields are present, then the same value MUST be 488 present in both fields. Thus, the baseCertificateID is only usable 489 with PKC profiles (like [PKIXPROF]) which mandate that the PKC 490 issuer field contain a non-empty distinguished name value. 492 Note: An empty distinguished name is a distinguished name where the 493 SEQUENCE OF relative distinguished names is of zero length. In a DER 494 encoding this has the value '3000'H. 496 If the holder field uses the entityName option and the underlying 497 authentication is based on a PKC, then the entityName MUST be the 498 same as the PKC subject field or one of the values of the PKC 499 subjectAltName field extension (if present). Note that [PKIXPROF] 500 mandates that the subjectAltName extension be present if the PKC 501 subject is an empty distinguished name. See the security 502 consideration section which mentions some name collision problems 503 that may arise when using the entityName option. 505 In any other case where the holder field uses the entityName option, 506 then only one name SHOULD be present. 508 Implementations conforming to this profile are not required to 509 support the use of the objectDigest field. However, section 7.3 510 specifies how this optional feature MAY be used. 512 Any protocol conforming to this profile SHOULD specify which AC 513 holder option is to be used and how this fits with the supported 514 authentication schemes defined in that protocol. 516 4.2.3 Issuer 518 ACs conforming to this profile MUST use the v1Form choice, which 519 MUST contain one and only one GeneralName, which MUST contain a non- 520 empty distinguished name in the directoryName field. This means that 521 all AC issuers MUST have non-empty distinguished names. 523 Part of the reason for the use of the v1Form field is that it means 524 that the AC issuer does not have to know which PKC the AC verifier 525 will use for it (the AC issuer). Using the baseCertificateID field 526 to reference the AC issuer would mean that the AC verifier would 527 have to trust the PKC that the AC issuer chose (for itself) at AC 528 creation time. 530 4.2.4 Signature 532 Contains the algorithm identifier used to validate the AC signature. 534 This MUST be one of the signing algorithms defined in [PKIXALGS]. 535 Conforming implementations MUST honor all MUST/SHOULD/MAY signing 536 algorithm statements specified in [PKIXALGS]. 538 4.2.5 Serial Number 540 For any conforming AC, the issuer/serialNumber pair MUST form a 541 unique combination, even if ACs are very short-lived. 543 AC issuers MUST force the serialNumber to be a positive integer, 544 that is, the sign bit in the DER encoding of the INTEGER value MUST 545 be zero - this can be done by adding a leading (leftmost) '00'H 546 octet if necessary. This removes a potential ambiguity in mapping 547 between a string of octets and an integer value. 549 Given the uniqueness and timing requirements above serial numbers 550 can be expected to contain long integers. AC users MUST be able to 551 handle serialNumber values longer than 4 octets. Conformant ACs MUST 552 NOT contain serialNumber values longer than 20 octets. 554 There is no requirement that the serial numbers used by any AC 555 issuer follow any particular ordering, in particular, they need not 556 be monotonically increasing with time. Each AC issuer MUST ensure 557 that each AC that it issues contain a unique serial number. 559 4.2.6 Validity Period 561 The attrCertValidityPeriod (a.k.a. validity) field specifies the 562 period for which the AC issuer certifies that the binding between 563 the holder and the attributes fields will be valid. 565 The generalized time type, GeneralizedTime, is a standard ASN.1 type 566 for variable precision representation of time. The GeneralizedTime 567 field can optionally include a representation of the time 568 differential between the local time zone and Greenwich Mean Time. 570 For the purposes of this profile, GeneralizedTime values MUST be 571 expressed in Coordinated universal time (UTC) (also known as 572 Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times 573 are YYYYMMDDHHMMSSZ), even when the number of seconds is zero. 574 GeneralizedTime values MUST NOT include fractional seconds. 575 (Note: this is the same as specified in [PKIXPROF], section 576 4.1.2.5.2.) 578 AC users MUST be able to handle an AC which, at the time of 579 processing, has parts of its validity period or all its validity 580 period in the past or in the future (a post-dated AC). This is valid 581 for some applications, such as backup. 583 4.2.7 Attributes 585 The attributes field gives information about the AC holder. When the 586 AC is used for authorization this will often contain a set of 587 privileges. 589 The attributes field contains a SEQUENCE OF Attribute. Each 590 Attribute MAY contain a SET OF values. For a given AC, each 591 AttributeType OBJECT IDENTIFIER in the sequence MUST be unique. That 592 is, only one instance of each attribute can occur in a single AC, 593 but each instance can be multi-valued. 595 AC users MUST be able to handle multiple values for all attribute 596 types. 598 An AC MUST contain at least one attribute. That is, the SEQUENCE OF 599 Attributes MUST NOT be of zero length. 601 Some standard attribute types are defined in section 4.5. 603 4.2.8 Issuer Unique Identifier 605 This field MUST NOT be used unless it is also used in the AC 606 issuer's PKC, in which case it MUST be used. Note that [PKIXPROF] 607 states that this field SHOULD NOT be used by conforming CAs, but 608 that applications SHOULD be able to parse PKCs containing the field. 610 4.2.9 Extensions 612 The extensions field generally gives information about the AC as 613 opposed to information about the AC holder. 615 An AC that has no extensions conforms to the profile; however, 616 section 4.3 defines the extensions that MAY be used with this 617 profile, and whether or not they may be marked critical. If any 618 other critical extension is used, then the AC does not conform to 619 this profile. However, if any other non-critical extension is used, 620 then the AC does conform to this profile. 622 The extensions defined for ACs provide methods for associating 623 additional attributes with holders. This profile also allows 624 communities to define private extensions to carry information unique 625 to those communities. Each extension in an AC may be designated as 626 critical or non-critical. An AC using system MUST reject an AC if 627 it encounters a critical extension it does not recognize; however, a 628 non-critical extension may be ignored if it is not recognized. 629 Section 4.3 presents recommended extensions used within Internet ACs 630 and standard locations for information. Communities may elect to 631 use additional extensions; however, caution should be exercised in 632 adopting any critical extensions in ACs, which might prevent use in 633 a general context. 635 4.3 Extensions 636 4.3.1 Audit Identity 638 In some circumstances it is required (e.g. by data protection/data 639 privacy legislation) that audit trails do not contain records which 640 directly identify individuals. This circumstance may make the use of 641 the AC holder field unsuitable for use in audit trails. 643 To allow for such cases, an AC MAY contain an audit identity 644 extension. Ideally it SHOULD be infeasible to derive the AC holder's 645 identity from the audit identity value without the co-operation of 646 the AC issuer. 648 The value of the audit identity along with the AC issuer/serial 649 SHOULD then be used for audit/logging purposes. If the value of the 650 audit identity is suitably chosen, then a server/service 651 administrator can use audit trails to track the behavior of an AC 652 holder without being able to identify the AC holder. 654 The server/service administrator in combination with the AC issuer 655 MUST be able to identify the AC holder in cases where misbehavior is 656 detected. This means that the AC issuer MUST be able to determine 657 the actual identity of the AC holder from the audit identity. 659 Of course, auditing could be based on the AC issuer/serial pair; 660 however, this method doesn't allow tracking the same AC holder with 661 multiple ACs. Thus, an audit identity is only useful if it lasts for 662 longer than the typical AC lifetime. Auditing could also be based on 663 the AC holder's PKC issuer/serial; however, this will often allow 664 the server/service administrator to identify the AC holder. 666 As the AC verifier might otherwise use the AC holder or some other 667 identifying value for audit purposes, this extension MUST be 668 critical when used. 670 Protocols that use ACs will often expose the identity of the AC 671 holder in the bits on-the-wire. In such cases, an opaque audit 672 identity does not make use of the AC anonymous, it simply ensures 673 that the ensuing audit trails do not contain identifying 674 information. 676 The value of an audit identity MUST be longer than zero octets. The 677 value of an audit identity MUST NOT be longer than 20 octets. 679 name id-pe-ac-auditIdentity 680 OID { id-pe 4 } 681 syntax OCTET STRING 682 criticality MUST be TRUE 684 4.3.2 AC Targeting 686 To target an AC, the target information extension, imported from 687 [X.509-2000], MAY be used to specify a number of servers/services. 688 The intent is that the AC SHOULD only be usable at the specified 689 servers/services. An (honest) AC verifier who is not amongst the 690 named servers/services MUST reject the AC. 692 If this extension is not present, then the AC is not targeted and 693 may be accepted by any server. 695 In this profile, the targeting information simply consists of a list 696 of named targets or groups. 698 The following syntax is used to represent the targeting information: 700 Targets ::= SEQUENCE OF Target 702 Target ::= CHOICE { 703 targetName [0] GeneralName, 704 targetGroup [1] GeneralName, 705 targetCert [2] TargetCert 706 } 708 TargetCert ::= SEQUENCE { 709 targetCertificate IssuerSerial, 710 targetName GeneralName OPTIONAL, 711 certDigestInfo ObjectDigestInfo OPTIONAL 712 } 714 The targetCert CHOICE within the Target structure is only present to 715 allow future compatibility with [X.509-2000] and MUST NOT be used. 717 The targets check passes if the current server (recipient) is one of 718 the targetName fields in the Targets SEQUENCE, or if the current 719 server is a member of one of the targetGroup fields in the Targets 720 SEQUENCE. In this case, the current server is said to "match" the 721 targeting extension. 723 How the membership of a target within a targetGroup is determined is 724 not defined here. It is assumed that any given target "knows" the 725 names of the targetGroups to which it belongs or can otherwise 726 determine its membership. For example, the targetGroup specifies a 727 DNS domain, and the AC verifier knows the DNS domain to which it 728 belongs. For another example, the targetGroup specifies "PRINTERS," 729 and the AC verifier knows whether or not it is a printer or print 730 server. 732 Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF 733 Targets". Conforming AC issuer implementations MUST only produce one 734 "Targets" element. Confirming AC users MUST be able to accept a 735 "SEQUENCE OF Targets". If more than one Targets element is found in 736 an AC, then the extension MUST be treated as if all Target elements 737 had been found within one Targets element. 739 name id-ce-targetInformation 740 OID { id-ce 55 } 741 syntax SEQUENCE OF Targets 742 criticality MUST be TRUE 744 4.3.3 Authority Key Identifier 746 The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY 747 be used to assist the AC verifier in checking the signature of the 748 AC. The [PKIXPROF] description should be read as if "CA" meant "AC 749 issuer." As with PKCs this extension SHOULD be included in ACs. 751 Note: An AC where the issuer field used the baseCertificateID CHOICE 752 would not need an authorityKeyIdentifier extension as it is 753 explicitly linked to the key in the referred certificate. However, 754 as this profile states (in section 4.2.3) that ACs MUST use the 755 v1Form CHOICE, this duplication does not arise. 757 name id-ce-authorityKeyIdentifier 758 OID { id-ce 35 } 759 syntax AuthorityKeyIdentifier 760 criticality MUST be FALSE 762 4.3.4 Authority Information Access 764 The authorityInformationAccess extension, as defined in [PKIXPROF], 765 MAY be used to assist the AC verifier in checking the revocation 766 status of the AC. Support for the id-ad-caIssuers accessMethod is 767 NOT REQUIRED by this profile since AC chains are not expected. 769 The following accessMethod is used to indicate that revocation 770 status checking is provided for this AC, using the OCSP protocol 771 defined in [OCSP]: 773 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 775 The accessLocation MUST contain a URI, and the URI MUST contain an 776 HTTP URL [URL] that specifies the location of an OCSP responder. The 777 AC issuer MUST, of course, maintain an OCSP responder at this 778 location. 780 name id-ce-authorityInfoAccess 781 OID { id-pe 1 } 782 syntax AuthorityInfoAccessSyntax 783 criticality MUST be FALSE 785 4.3.5 CRL Distribution Points 787 The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY 788 be used to assist the AC verifier in checking the revocation status 789 of the AC. See section 6 for details on revocation. 791 If the crlDistributionPoints extension is present, then exactly one 792 distribution point MUST be present. The crlDistributionPoints 793 extension MUST use the DistributionPointName option, which MUST 794 contain a fullName, which MUST contain a single name form. That name 795 MUST contain either a distinguished name or a URI. The URI MUST be 796 either an HTTP URL or an LDAP URL [URL]. 798 name id-ce-cRLDistributionPoints 799 OID { id-ce 31 } 800 syntax CRLDistPointsSyntax 801 criticality MUST be FALSE 803 4.3.6 No Revocation Available 805 The noRevAvail extension, defined in [X.509-2000], allows an AC 806 issuer to indicate that no revocation information will be made 807 available for this AC. 809 This extension MUST be non-critical. An AC verifier that does not 810 understand this extension might be able to find a revocation list 811 from the AC issuer, but the revocation list will never include an 812 entry for the AC. 814 name id-ce-noRevAvail 815 OID { id-ce 56 } 816 syntax NULL (i.e. '0500'H is the DER encoding) 817 criticality MUST be FALSE 819 4.4 Attribute Types 821 Some of the attribute types defined below make use of the 822 IetfAttrSyntax type, also defined below. The reasons for using this 823 type are: 825 1. It allows a separation between the AC issuer and the attribute 826 policy authority. This is useful for situations where a single 827 policy authority (e.g. an organization) allocates attribute 828 values, but where multiple AC issuers are deployed for 829 performance or other reasons. 830 2. The syntaxes allowed for values are restricted to OCTET STRING, 831 OBJECT IDENTIFIER, and UTF8String, which significantly reduces 832 the complexity associated with matching more general syntaxes. 833 All multi-valued attributes using this syntax are restricted so 834 that each value MUST use the same choice of value syntax. For 835 example, AC issuers must not use one value with an oid and a 836 second value with a string. 838 IetfAttrSyntax ::= SEQUENCE { 839 policyAuthority [0] GeneralNames OPTIONAL, 840 values SEQUENCE OF CHOICE { 841 octets OCTET STRING, 842 oid OBJECT IDENTIFIER, 843 string UTF8String 844 } 845 } 847 In the descriptions below, each attribute type is tagged as either 848 "Multiple Allowed" or "One Attribute value only; multiple values 849 within the IetfAttrSyntax". This refers to the SET OF 850 AttributeValue, the AttributeType still only occurs once, as 851 specified in section 4.2.7. 853 4.4.1 Service Authentication Information 855 The SvceAuthInfo attribute identifies the AC holder to the 856 server/service by a name, and the attribute MAY include optional 857 service specific authentication information. Typically this will 858 contain a username/password pair for a "legacy" application. 860 This attribute provides information that can be presented by the AC 861 verifier to be interpreted and authenticated by a separate 862 application within the target system. Note that this is a different 863 use to that intended for the accessIdentity attribute in 4.4.2 864 below. 866 This attribute type will typically be encrypted when the authInfo 867 field contains sensitive information, such as a password. 869 name id-aca-authenticationInfo 870 OID { id-aca 1 } 871 Syntax SvceAuthInfo 872 values: Multiple allowed 874 SvceAuthInfo ::= SEQUENCE { 875 service GeneralName, 876 ident GeneralName, 877 authInfo OCTET STRING OPTIONAL 878 } 880 4.4.2 Access Identity 882 The accessIdentity attribute identifies the AC holder to the 883 server/service. For this attribute the authInfo field MUST NOT be 884 present. 886 This attribute is intended to be used to provide information about 887 the AC holder, that can be used by the AC verifier (or a larger 888 system of which the AC verifier is a component) to authorize the 889 actions of the AC holder within the AC verifier's system. Note that 890 this is a different use to that intended for the svceAuthInfo 891 attribute described in 4.4.1 above. 893 name id-aca-accessIdentity 894 OID { id-aca 2 } 895 syntax SvceAuthInfo 896 values: Multiple allowed 898 4.4.3 Charging Identity 900 The chargingIdentity attribute identifies the AC holder for charging 901 purposes. In general, the charging identity will be different from 902 other identities of the holder. For example, the holder's company 903 may be charged for service. 905 name id-aca-chargingIdentity 906 OID { id-aca 3 } 907 syntax IetfAttrSyntax 908 values: One Attribute value only; multiple values within the 909 IetfAttrSyntax 911 4.4.4 Group 913 The group attribute carries information about group memberships of 914 the AC holder. 916 name id-aca-group 917 OID { id-aca 4 } 918 syntax IetfAttrSyntax 919 values: One Attribute value only; multiple values within the 920 IetfAttrSyntax 922 4.4.5 Role 924 The role attribute, specified in [X.509-2000], carries information 925 about role allocations of the AC holder. 927 The syntax used for this attribute is: 929 RoleSyntax ::= SEQUENCE { 930 roleAuthority [0] GeneralNames OPTIONAL, 931 roleName [1] GeneralName 932 } 934 The roleAuthority field MAY be used to specify the issuing authority 935 for the role specification certificate. There is no requirement that 936 a role specification certificate necessarily exists for the 937 roleAuthority. This differs from [X.500-2000], where the 938 roleAuthority field is assumed to name the issuer of a role 939 specification certificate. For example, to distinguish the 940 administrator role as defined by "Baltimore" from that defined by 941 "SPYRUS", one could put the value "administrator" in the roleName 942 field and the value "Baltimore" or "SPYRUS" in the roleAuthority 943 field. 945 The roleName field MUST be present, and roleName MUST use the 946 uniformResourceIdentifier CHOICE of the GeneralName. 948 name id-at-role 949 OID { id-at 72 } 950 syntax RoleSyntax 951 values: Multiple allowed 953 4.4.6 Clearance 955 The clearance attribute, specified in [X.501-1993], carries 956 clearance (associated with security labeling) information about the 957 AC holder. 959 The policyId field is used to identify the security policy to which 960 the clearance relates. The policyId indicates the semantics of the 961 classList and securityCategories fields. 963 This specification includes the classList field exactly as is 964 specified in [X.501-1993]. Additional security classification 965 values, and their position in the classification hierarchy, may be 966 defined by a security policy as a local matter or by bilateral 967 agreement. The basic security classification hierarchy is, in 968 ascending order: unmarked, unclassified, restricted, confidential, 969 secret, and top-secret. 971 An organization can develop its own security policy that defines 972 security classification values and their meanings. However, the BIT 973 STRING positions 0 through 5 are reserved for the basic security 974 classification hierarchy. 976 If present, the SecurityCategory field provides further 977 authorization information. The security policy identified by the 978 policyId field indicates the syntaxes that are allowed to be present 979 in the securityCategories SET. An OBJECT IDENTIFIER identifies each 980 of the allowed syntaxes. When one of these syntaxes is present in 981 the securityCategories SET, the OBJECT IDENTIFIER associated with 982 that syntax is carried in the SecurityCategory.type field. 984 Clearance ::= SEQUENCE { 985 policyId OBJECT IDENTIFIER, 986 classList ClassList DEFAULT {unclassified}, 987 securityCategories 988 SET OF SecurityCategory OPTIONAL 989 } 991 ClassList ::= BIT STRING { 992 unmarked (0), 993 unclassified (1), 994 restricted (2) 995 confidential (3), 996 secret (4), 997 topSecret (5) 998 } 1000 SecurityCategory ::= SEQUENCE { 1001 type [0] IMPLICIT OBJECT IDENTIFIER, 1002 value [1] ANY DEFINED BY type 1003 } 1005 -- This is the same as the original syntax which was defined 1006 -- using the MACRO construct, as follows: 1007 -- SecurityCategory ::= SEQUENCE { 1008 -- type [0] IMPLICIT SECURITY-CATEGORY, 1009 -- value [1] ANY DEFINED BY type 1010 -- } 1011 -- 1012 -- SECURITY-CATEGORY MACRO ::= 1013 -- BEGIN 1014 -- TYPE NOTATION ::= type | empty 1015 -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 1016 -- END 1018 name { id-at-clearance } 1019 OID { joint-iso-ccitt(2) ds(5) module(1) 1020 selected-attribute-types(5) clearance (55) } 1021 syntax Clearance - imported from [X.501-1993] 1022 values Multiple allowed 1024 4.5 Profile of AC issuer's PKC 1026 The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage 1027 extension in the PKC MUST NOT explicitly indicate that the AC 1028 issuer's public key cannot be used to validate a digital signature. 1029 In order to avoid confusion regarding serial numbers and 1030 revocations, an AC issuer MUST NOT also be a PKC Issuer. That is, 1031 an AC issuer cannot be a CA as well. So, the AC issuer's PKC MUST 1032 NOT have a basicConstraints extension with the cA BOOLEAN set to 1033 TRUE. 1035 5. Attribute Certificate Validation 1037 This section describes a basic set of rules that all valid ACs MUST 1038 satisfy. Some additional checks are also described which AC 1039 verifiers MAY choose to implement. 1041 To be valid an AC MUST satisfy all of the following: 1043 1. Where the holder uses a PKC to authenticate to the AC verifier, 1044 then the AC holder's PKC MUST be found, and the entire 1045 certification path of that PKC MUST be verified in accordance 1046 with [PKIXPROF]. As noted in the security considerations 1047 section, if some other authentication scheme is used, AC 1048 verifiers need to be very careful mapping the 1049 identities(authenticated identity, holder field) involved. 1050 2. The AC signature must be cryptographically correct, and the AC 1051 issuer's entire PKC certification path MUST be verified in 1052 accordance with [PKIXPROF]. 1053 3. The AC issuer's PKC MUST also conform to the profile specified 1054 in section 4.5 above. 1055 4. The AC issuer MUST be directly trusted as an AC issuer (by 1056 configuration or otherwise). 1057 5. The time for which the AC is being evaluated MUST be within the 1058 AC validity. If the evaluation time is equal to either 1059 notBeforeTime or notAfterTime, then the AC is timely and this 1060 check succeeds. Note that in some applications, the evaluation 1061 time MAY not be the same as the current time. 1062 6. The AC targeting check MUST pass as specified in section 4.3.2. 1063 7. If the AC contains an unsupported critical extension, then the 1064 AC MUST be rejected. 1066 Support for an extension in this context means: 1068 1. The AC verifier MUST be able to parse the extension value. 1069 2. Where the extension value SHOULD cause the AC to be rejected, 1070 the AC verifier MUST reject the AC. 1072 Additional Checks: 1074 1. The AC MAY be rejected on the basis of further AC verifier 1075 configuration. For example, an AC verifier may be configured to 1076 reject ACs which contain or lack certain attributes. 1077 2. If the AC verifier provides an interface that allows 1078 applications to query the contents of the AC, then the AC 1079 verifier MAY filter the attributes from the AC on the basis of 1080 configured information. For example, an AC verifier might be 1081 configured not to return certain attributes to certain servers. 1083 6. Revocation 1085 In many environments, the validity period of an AC is less than the 1086 time required to issue and distribute revocation information. 1087 Therefore, short-lived ACs typically do not require revocation 1088 support. However, long-lived ACs and environments where ACs enable 1089 high value transactions MAY require revocation support. 1091 Two revocation schemes are defined, and the AC issuer should elect 1092 the one that is best suited to the environment in which the AC will 1093 be employed. 1095 "Never revoke" scheme: 1097 ACs may be marked so that the relying party understands that no 1098 revocation status information will be made available. The 1099 noRevAvail extension is defined in section 4.3.6, and the 1100 noRevAvail extension MUST be present in the AC to indicate use 1101 of this scheme. 1103 Where no noRevAvail is not present, then the AC issuer is 1104 implicitly stating that revocation status checks are supported, 1105 and some revocation method MUST be provided to allow AC 1106 verifiers to establish the revocation status of the AC. 1108 "Pointer in AC" scheme: 1110 ACs may "point" to sources of revocation status information, 1111 using either an authorityInfoAccess extension or a 1112 crlDistributionPoints extension within the AC. 1114 For AC users, the "never revoke" scheme MUST be supported, and the 1115 "pointer in AC" scheme SHOULD be supported. If only the "never 1116 revoke" scheme is supported, then all ACs that do not contain a 1117 noRevAvail extension, MUST be rejected. 1119 For AC issuers, the "never revoke" scheme MUST be supported. If all 1120 ACs that will ever be issued by that AC issuer, will contain a 1121 noRevAvail extension, then the "pointer in AC" scheme need not be 1122 supported. If any AC can be issued that does not contain the 1123 noRevAvail extension, then the "pointer in AC" scheme MUST be 1124 supported. 1126 An AC verifier MAY use any source for AC revocation status 1127 information. 1129 7. Optional Features 1131 This section specifies features that MAY be implemented. Conformance 1132 to this profile does NOT require support for these features; 1133 however, if these features are offered, they MUST be offered as 1134 described below. 1136 7.1 Attribute Encryption 1138 Where an AC will be carried in clear within an application protocol 1139 or where an AC contains some sensitive information like a legacy 1140 application username/password, then encryption of AC attributes MAY 1141 be needed. 1143 When a set of attributes are to be encrypted within an AC, the 1144 Cryptographic Message Syntax, EnvelopedData structure [CMS] is used 1145 to carry the ciphertext and associated per-recipient keying 1146 information. 1148 This type of attribute encryption is targeted. Before the AC is 1149 signed, the attributes are encrypted for a set of predetermined 1150 recipients. 1152 The AC then contains the ciphertext inside its signed data. The 1153 EenvelopedData (id-envelopedData) ContentType is used, and the 1154 content field will contain the EnvelopedData type. 1156 The ciphertext is included in the AC as the value of an encAttrs 1157 attribute. Only one encAttrs attribute can be present in an AC; 1158 however, the encAttrs attribute MAY be multi-valued, and each of its 1159 values will contain an independent EnvelopedData. 1161 Each value can contain a set of attributes (each possibly a multi- 1162 valued attribute) encrypted for a set of predetermined recipients. 1164 The cleartext that is encrypted has the type: 1166 ACClearAttrs ::= SEQUENCE { 1167 acIssuer GeneralName, 1168 acSerial INTEGER, 1169 attrs SEQUENCE OF Attribute 1170 } 1172 The DER encoding of the ACClearAttrs structure is used as the 1173 encryptedContent field of the EnvelopedData. The DER encoding MUST 1174 be embedded in an OCTET STRING. 1176 The acIssuer and acSerial fields are present to prevent ciphertext 1177 stealing. When an AC verifier has successfully decrypted an 1178 encrypted attribute it MUST then check that the AC issuer and 1179 serialNumber fields contain the same values. This prevents a 1180 malicious AC issuer from copying ciphertext from another AC (without 1181 knowing its corresponding plaintext). 1183 The procedure for an AC issuer when encrypting attributes is 1184 illustrated by the following (any other procedure that gives the 1185 same result MAY be used): 1187 1. Identify the sets of attributes that are to be encrypted for 1188 each set of recipients. 1189 2. For each attribute set which is to be encrypted: 1190 2.1. Create an EnvelopedData structure for the data for this 1191 set of recipients. 1192 2.2. Encode the ContentInfo containing the EnvelopedData as a 1193 value of the encAttrs attribute 1194 2.3. Ensure the cleartext attributes are not present in the 1195 to-be-signed AC 1196 3. Add the encAttrs (with its multiple values) to the AC 1198 Note that there may be more than one attribute of the same type (the 1199 same OBJECT IDENTIFIER) after decryption. That is, an AC MAY contain 1200 the same attribute type both in clear and in encrypted form (and 1201 indeed several times if the same recipient is associated with more 1202 than one EnvelopedData). One approach implementers may choose, would 1203 be to merge attributes values following decryption in order to re- 1204 establish the "once only" constraint. 1206 name id-aca-encAttrs 1207 OID { id-aca 6} 1208 Syntax ContentInfo 1209 values Multiple Allowed 1211 If an AC contains attributes apparently encrypted for the AC 1212 verifier, then the decryption process MUST not fail. If decryption 1213 does fail, then the AC MUST be rejected. 1215 7.2 Proxying 1217 When a server acts as a client for another server on behalf of the 1218 AC holder, the server MAY need to proxy an AC. Such proxying MAY 1219 have to be done under the AC issuer's control, so that not every AC 1220 is proxiable and so that a given proxiable AC can be proxied in a 1221 targeted fashion. Support for chains of proxies (with more than one 1222 intermediate server) MAY also be required. Note that this does not 1223 involve a chain of ACs. 1225 In order to meet this requirement we define another extension, 1226 ProxyInfo, similar to the targeting extension. 1228 When this extension is present, the AC verifier must check that the 1229 entity from which the AC was received was allowed to send it and 1230 that the AC is allowed to be used by this verifier. 1232 The proxying information consists of a set of proxy information, 1233 each of which is a set of targeting information. If the verifier and 1234 the sender of the AC are both named in the same proxy set then the 1235 AC can be accepted (the exact rule is given below). 1237 The effect is that the AC holder can send the AC to any valid target 1238 which can then only proxy to targets which are in one of the same 1239 proxy sets as itself. 1241 The following data structure is used to represent the 1242 targeting/proxying information. 1244 ProxyInfo ::= SEQUENCE OF Targets 1246 As in the case of targeting, the targetCert CHOICE MUST NOT be used. 1248 A proxy check succeeds if either one of the conditions below is met: 1250 1. The identity of the sender as established by the underlying 1251 authentication service matches the holder field of the AC, and the 1252 current server "matches" any one of the proxy sets. Recall that 1253 "matches" is as defined section 4.3.2. 1255 2. The identity of the sender as established by the underlying 1256 authentication service "matches" one of the proxy sets (call it 1257 set "A"), and the current server is one of the targetName fields 1258 in the set "A", or the current server is a member of one of the 1259 targetGroup fields in set "A". 1261 When an AC is proxied more than once, a number of targets will be on 1262 the path from the original client, which is normally, but not 1263 always, the AC holder. In such cases, prevention of AC "stealing" 1264 requires that the AC verifier MUST check that all targets on the 1265 path are members of the same proxy set. It is the responsibility of 1266 the AC using protocol to ensure that a trustworthy list of targets 1267 on the path is available to the AC verifier. 1269 name id-pe-ac-proxying 1270 OID { id-pe 10 } 1271 syntax ProxyInfo 1272 criticality MUST be TRUE 1274 7.3 Use of ObjectDigestInfo 1276 In some environments, it may be required that the AC is not linked 1277 either to an identity (via entityName) or to a PKC (via 1278 baseCertificateID). The objectDigestInfo CHOICE in the holder field 1279 allows support for this requirement. 1281 If the holder is identified with the objectDigestInfo field, then 1282 the AC version field MUST contain v2 (the integer 1). 1284 The idea is to link the AC to an object by placing a hash of that 1285 object into the holder field of the AC. For example, this allows 1286 production of ACs that are linked to public keys rather than names. 1288 It also allows production of ACs which contain privileges associated 1289 with an executable object such as a Java class. However, this 1290 profile only specifies how to use a hash over a public key or PKC. 1291 That is, conformant ACs MUST NOT use the otherObjectTypes value for 1292 the digestedObjectType. 1294 To link an AC to a public key, the hash must be calculated over the 1295 representation of that public key which would be present in a PKC, 1296 specifically, the input for the hash algorithm MUST be the DER 1297 encoding of a SubjectPublicKeyInfo representation of the key. Note: 1298 This includes the AlgorithmIdentifier as well as the BIT STRING. The 1299 rules given in [PKIXPROF] for encoding keys MUST be followed. In 1300 this case the digestedObjectType MUST be publicKey and the 1301 otherObjectTypeID field MUST NOT be present. 1303 Note that if the public key value used as input to the hash function 1304 has been extracted from a PKC, then it is possible that the 1305 SubjectPublicKeyInfo from that PKC is NOT the value which should be 1306 hashed. This can occur if DSA Dss-parms are inherited as described 1307 in section 7.3.3 of [PKIXPROF]. The correct input for hashing in 1308 this context will include the value of the parameters inherited from 1309 the CA's PKC, and thus may differ from the SubjectPublicKeyInfo 1310 present in the PKC. 1312 Implementations which support this feature MUST be able to handle 1313 the representations of public keys for the algorithms specified in 1314 section 7.3 of [PKIXPROF]. In this case the digestedObjectType MUST 1315 be publicKey and the otherObjectTypeID field MUST NOT be present. 1317 In order to link an AC to a PKC via a digest, the digest MUST be 1318 calculated over the DER encoding of the entire PKC, including the 1319 signature value. In this case the digestedObjectType MUST be 1320 publicKeyCert and the otherObjectTypeID field MUST NOT be present. 1322 7.4 AA Controls 1324 During AC validation a relying party has to answer the question: is 1325 this AC issuer trusted to issue ACs containing this attribute? The 1326 AAControls PKC extension MAY be used to help answer the question. 1327 The AAControls extension is intended to be used in CA and AC issuer 1328 PKCs. 1330 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1332 AAControls ::= SEQUENCE { 1333 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1334 permittedAttrs [0] AttrSpec OPTIONAL, 1335 excludedAttrs [1] AttrSpec OPTIONAL, 1336 permitUnSpecified BOOLEAN DEFAULT TRUE 1337 } 1339 AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER 1341 The AAControls extension is used as follows: 1343 The pathLenConstraint, if present, is interpreted as in [PKIXPROF]. 1344 It restricts the allowed distance between the AA CA, (a CA directly 1345 trusted to include AAControls in its PKCs), and the AC issuer. 1347 The permittedAttrs field specifies a set of attribute types that any 1348 AC issuer below this AA CA is allowed to include in ACs. If this 1349 field is not present, it means that no attribute types are 1350 explicitly allowed. 1352 The excludedAttrs field specifies a set of attribute types that no 1353 AC issuer is allowed to include in ACs. If this field is not 1354 present, it means that no attribute types are explicitly disallowed. 1356 The permitUnSpecified field specifies how to handle attribute types 1357 which are not present in either the permittedAttrs or excludedAttrs 1358 fields. TRUE (the default) means that any unspecified attribute type 1359 is allowed in ACs; FALSE means that no unspecified attribute type is 1360 allowed. 1362 When AAControls are used, the following additional checks on an AA's 1363 PKC chain MUST all succeed for the AC to be valid: 1365 1. Some CA on the ACs certificate path MUST be directly trusted to 1366 issue PKCs which precede the AC issuer in the certification 1367 path, call this CA the "AA CA". 1368 2. All PKCs on the path from the AA CA down to and including the 1369 AC issuer's PKC MUST contain an AAControls extension; however, 1370 the AA CA's PKC need not contain this extension. 1371 3. Only those attributes in the AC which are allowed according to 1372 all of the AAControls extension values in all of the PKCs from 1373 the AA CA to the AC issuer, may be used for authorization 1374 decisions, all other attributes MUST be ignored. This check 1375 MUST be applied to the set of attributes following attribute 1376 decryption, and the id-aca-encAttrs type MUST also be checked. 1378 name id-pe-aaControls 1379 OID { id-pe 6 } 1380 syntax AAControls 1381 criticality MAY be TRUE 1383 8. Security Considerations 1385 The protection afforded for private keys is a critical factor in 1386 maintaining security. Failure of AC issuers to protect their 1387 private keys will permit an attacker to masquerade as them, 1388 potentially generating false ACs or revocation status. Existence of 1389 bogus ACs and revocation status will undermine confidence in the 1390 system. If the compromise is detected, all ACs issued by the AC 1391 issuer MUST be revoked. Rebuilding after such a compromise will be 1392 problematic, so AC issuers are advised to implement a combination of 1393 strong technical measures (e.g., tamper-resistant cryptographic 1394 modules) and appropriate management procedures (e.g., separation of 1395 duties) to avoid such an incident. 1397 Loss of an AC issuer's private signing key may also be problematic. 1398 The AC issuer would not be able to produce revocation status or 1399 perform AC renewal. AC issuers are advised to maintain secure backup 1400 for signing keys. The security of the key backup procedures is a 1401 critical factor in avoiding key compromise. 1403 The availability and freshness of revocation status will affect the 1404 degree of assurance that should be placed in a long-lived AC. While 1405 long-lived ACs expire naturally, events may occur during its natural 1406 lifetime which negate the binding between the AC holder and the 1407 attributes. If revocation status is untimely or unavailable, the 1408 assurance associated with the binding is clearly reduced. 1410 The binding between an AC holder and attributes cannot be stronger 1411 than the cryptographic module implementation and algorithms used to 1412 generate the signature. Short key lengths or weak hash algorithms 1413 will limit the utility of an AC. AC issuers are encouraged to note 1414 advances in cryptology so they can employ strong cryptographic 1415 techniques. 1417 Inconsistent application of name comparison rules may result in 1418 acceptance of invalid targeted or proxied ACs, or rejection of valid 1419 ones. The X.500 series of specifications defines rules for 1420 comparing distinguished names. These rules require comparison of 1421 strings without regard to case, character set, multi-character white 1422 space substrings, or leading and trailing white space. This 1423 specification and [PKIXPROF] relaxes these requirements, requiring 1424 support for binary comparison at a minimum. 1426 AC issuers MUST encode the distinguished name in the AC 1427 holder.entityName field identically to the distinguished name in the 1428 holder's PKC. If different encodings are used, implementations of 1429 this specification may fail to recognize that the AC and PKC belong 1430 to the same entity. 1432 If an attribute certificate is tied to the holder's PKC using the 1433 baseCertificateID component of the Holder field and the PKI in use 1434 includes a rogue CA with the same issuer name specified in the 1435 baseCertificateID component, this rogue CA could issue a PKC to a 1436 malicious party, using the same issuer name and serial number as the 1437 proper holder's PKC. Then the malicious party could use this PKC in 1438 conjunction with the AC. This scenario SHOULD be avoided by properly 1439 managing and configuring the PKI so that there cannot be two CAs 1440 with the same name. Another alternative is to tie ACs to PKCs using 1441 the publicKeyCert type in the ObjectDigestInfo field. Failing this, 1442 AC verifiers have to establish (using other means) that the 1443 potential collisions cannot actually occur, for example, the CPSs of 1444 the CAs involved may make it clear that no such name collisions can 1445 occur. 1447 Implementers MUST ensure that following validation of an AC, only 1448 attributes that the issuer is trusted to issue are used in 1449 authorization decisions. Other attributes, which MAY be present MUST 1450 be ignored. Given that the AA controls PKC extension is optional to 1451 implement, AC verifiers MUST be provided with this information by 1452 other means. Configuration information is a likely alternative 1453 means. This becomes very important if an AC verifier trusts more 1454 than one AC issuer. 1456 There is often a requirement to map between the authentication 1457 supplied by a particular security protocol (e.g. TLS, S/MIME) and 1458 the AC holder's identity. If the authentication uses PKCs, then this 1459 mapping is straightforward. However, it is envisaged that ACs will 1460 also be used in environments where the holder may be authenticated 1461 using other means. Implementers SHOULD be very careful in mapping 1462 the authenticated identity to the AC holder. 1464 9. References 1466 [CMC] Myers, M., et al. "Certificate Management Messages over 1467 CMS", RFC2797. 1468 [CMP] Adams, C., Farrell, S., "Internet X.509 Public Key 1469 Infrastructure - Certificate Management Protocols", 1470 RFC2510. 1471 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630. 1472 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 1473 RFC2634. 1474 [KRB] Kohl, J., Neuman, C., "The Kerberos Network 1475 Authentication Service (V5)", RFC 1510. 1476 [LDAP] Wahl, M., et al., "Lightweight Directory Access Protocol 1477 (v3)", RFC 2251. 1478 [OCSP] Myers, M., et al., " X.509 Internet Public Key 1479 Infrastructure - Online Certificate Status Protocol - 1480 OCSP", RFC 2560. 1481 [PKIXALGS] Polk, T., Bassham, L., "Internet X.509 Public Key 1482 Infrastructure Representation of Public Keys and Digital 1483 Signatures in Internet X.509 Public Key Infrastructure 1484 Certificates", draft-ietf-pkix-pkalgs-01.txt, work-in- 1485 progress. 1486 [PKINIT] Tung, B., et al., "Public Key Cryptography for Initial 1487 Authentication in Kerberos", draft-ietf-cat-kerberos-pk- 1488 init-12.txt, work-in-progress. 1489 [PKIXPROF] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet 1490 Public Key Infrastructure - X.509 Certificate and CRL 1491 Profile", draft-ietf-pkix-new-part1-03.txt, work-in- 1492 progress. 1493 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1494 3", RFC 2026, BCP 9, October 1996. 1495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1496 Requirement Levels", RFC 2119. 1497 [URL] Berners-Lee, T., Masinter L., and M. McCahill., "Uniform 1498 Resource Locators (URL)", RFC 1738. 1499 [X.208-1988]CCITT Recommendation X.208: Specification of Abstract 1500 Syntax Notation One (ASN.1). 1988. 1501 [X.209-88] CCITT Recommendation X.209: Specification of Basic 1502 Encoding Rules for Abstract Syntax Notation One (ASN.1). 1503 1988. 1504 [X.501-88] CCITT Recommendation X.501: The Directory - Models. 1505 1988. 1506 [X.501-1993]ITU-T Recommendation X.501 : Information Technology - 1507 Open Systems Interconnection - The Directory: Models, 1508 1993. 1509 [X.509-1988]CCITT Recommendation X.509: The Directory - 1510 Authentication Framework. 1988. 1511 [X.509-1997]ITU-T Recommendation X.509: The Directory - 1512 Authentication Framework. 1997. 1513 [X.509-2000]ITU-T Recommendation X.509: The Directory - Public-Key 1514 and Attribute Certificate Frameworks. 2000 1516 Author's Addresses 1518 Stephen Farrell 1519 Baltimore Technologies 1520 39/41 Parkgate Street 1521 Dublin 8 1522 IRELAND 1524 tel: +353-1-881-6000 1525 email: stephen.farrell@baltimore.ie 1527 Russell Housley 1528 SPYRUS 1529 381 Elden Street 1530 Suite 1120 1531 Herndon, VA 20170 1532 USA 1534 tel: +1-703-707-0696 1535 email: housley@spyrus.com 1537 Full Copyright Statement 1539 Copyright (C) The Internet Society (date). All Rights Reserved. 1541 This document and translations of it may be copied and furnished to 1542 others, and derivative works that comment on or otherwise explain it 1543 or assist in its implementation may be prepared, copied, published 1544 and distributed, in whole or in part, without restriction of any 1545 kind, provided that the above copyright notice and this paragraph 1546 are included on all such copies and derivative works. In addition, 1547 the ASN.1 module presented in Appendix B may be used in whole or in 1548 part without inclusion of the copyright notice. However, this 1549 document itself may not be modified in any way, such as by removing 1550 the copyright notice or references to the Internet Society or other 1551 Internet organizations, except as needed for the purpose of 1552 developing Internet standards in which case the procedures for 1553 copyrights defined in the Internet Standards process shall be 1554 followed, or as required to translate it into languages other than 1555 English. 1557 The limited permissions granted above are perpetual and will not be 1558 revoked by the Internet Society or its successors or assigns. This 1559 document and the information contained herein is provided on an "AS 1560 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1561 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1562 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1563 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1564 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1566 Appendix A: Object Identifiers 1568 This (normative) appendix lists the new object identifiers which are 1569 defined in this specification. Some of these are required only for 1570 support of optional features and are not required for conformance to 1571 this profile. This specification mandates support for OIDs which 1572 have arc elements with values that are less than 2^32, (i.e. they 1573 MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less 1574 than 2^31 (i.e. less than or equal to 2,147,483,647). This allows 1575 each arc element to be represented within a single 32 bit word. 1576 Implementations MUST also support OIDs where the length of the 1577 dotted decimal (see [LDAP], section 4.1.2) string representation can 1578 be up to 100 bytes (inclusive). Implementations MUST be able to 1579 handle OIDs with up to 20 elements (inclusive). AA's SHOULD NOT 1580 issue ACs which contain OIDs that breach these requirements. 1582 The following OIDs are imported from [PKIXPROF]: 1584 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1585 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 1586 id-mod OBJECT IDENTIFIER ::= { id-pkix 0 } 1587 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 1588 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 1589 id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } 1590 id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 } 1592 The following new ASN.1 module OID is defined: 1594 id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 } 1596 The following AC extension OIDs are defined: 1598 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1599 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 } 1600 id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 1602 The following PKC extension OIDs are defined: 1604 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1606 The following attribute OIDs are defined: 1608 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1609 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1610 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1611 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1612 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1613 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1614 id-at-role OBJECT IDENTIFIER ::= { id-at 72 } 1615 id-at-clearance OBJECT IDENTIFIER ::= 1616 { joint-iso-ccitt(2) ds(5) module(1) 1617 selected-attribute-types(5) clearance (55) } 1619 Appendix B: ASN.1 Module 1621 PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) 1622 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1623 id-mod-attribute-cert(12)} 1625 DEFINITIONS EXPLICIT TAGS ::= 1627 BEGIN 1629 -- EXPORTS ALL -- 1631 IMPORTS 1633 -- IMPORTed module OIDs MAY change if [PKIXPROF] changes 1634 -- PKIX Certificate Extensions 1635 Attribute, AlgorithmIdentifier, CertificateSerialNumber, 1636 Extensions, UniqueIdentifier, 1637 id-pkix, id-pe, id-kp, id-ad, id-at 1638 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 1639 dod(6) internet(1) security(5) mechanisms(5) 1640 pkix(7) id-mod(0) id-pkix1-explicit-88(1)} 1642 GeneralName, GeneralNames, id-ce 1643 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 1644 dod(6) internet(1) security(5) mechanisms(5) 1645 pkix(7) id-mod(0) id-pkix1-implicit-88(2)} ; 1647 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1648 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1649 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 } 1650 id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 1652 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1654 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1655 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1656 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1657 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1658 -- { id-aca 5 } is reserved 1659 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1661 id-at-role OBJECT IDENTIFIER ::= { id-at 72} 1662 id-at-clearance OBJECT IDENTIFIER ::= 1663 { joint-iso-ccitt(2) ds(5) module(1) 1664 selected-attribute-types(5) clearance (55) } 1666 -- Uncomment this if using a 1988 level ASN.1 compiler 1667 -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 1669 AttributeCertificate ::= SEQUENCE { 1670 acinfo AttributeCertificateInfo, 1671 signatureAlgorithm AlgorithmIdentifier, 1672 signatureValue BIT STRING 1673 } 1675 AttributeCertificateInfo ::= SEQUENCE { 1676 version AttCertVersion DEFAULT v1, 1677 holder Holder, 1678 issuer AttCertIssuer, 1679 signature AlgorithmIdentifier, 1680 serialNumber CertificateSerialNumber, 1681 attrCertValidityPeriod AttCertValidityPeriod, 1682 attributes SEQUENCE OF Attribute, 1683 issuerUniqueID UniqueIdentifier OPTIONAL, 1684 extensions Extensions OPTIONAL 1685 } 1687 AttCertVersion ::= INTEGER {v1(0), v2(1) } 1689 Holder ::= SEQUENCE { 1690 baseCertificateID [0] IssuerSerial OPTIONAL, 1691 -- the issuer and serial number of 1692 -- the holder's Public Key Certificate 1693 entityName [1] GeneralNames OPTIONAL, 1694 -- the name of the claimant or role 1695 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 1696 -- if present, version must be v2 1697 } 1699 ObjectDigestInfo ::= SEQUENCE { 1700 digestedObjectType ENUMERATED { 1701 publicKey (0), 1702 publicKeyCert (1), 1703 otherObjectTypes (2) }, 1704 -- otherObjectTypes MUST NOT 1705 -- MUST NOT be used in this profile 1706 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 1707 digestAlgorithm AlgorithmIdentifier, 1708 objectDigest BIT STRING 1709 } 1711 AttCertIssuer ::= CHOICE { 1712 v1Form GeneralNames, -- v1 or v2 1713 v2Form [0] V2Form -- v2 only 1714 } 1716 V2Form ::= SEQUENCE { 1717 issuerName GeneralNames OPTIONAL, 1718 baseCertificateID [0] IssuerSerial OPTIONAL, 1719 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 1720 -- at least one of issuerName, baseCertificateID 1721 -- or objectDigestInfo must be present 1722 } 1723 IssuerSerial ::= SEQUENCE { 1724 issuer GeneralNames, 1725 serial CertificateSerialNumber, 1726 issuerUID UniqueIdentifier OPTIONAL 1727 } 1729 AttCertValidityPeriod ::= SEQUENCE { 1730 notBeforeTime GeneralizedTime, 1731 notAfterTime GeneralizedTime 1732 } 1734 Targets ::= SEQUENCE OF Target 1736 Target ::= CHOICE { 1737 targetName [0] GeneralName, 1738 targetGroup [1] GeneralName, 1739 targetCert [2] TargetCert 1740 } 1742 TargetCert ::= SEQUENCE { 1743 targetCertificate IssuerSerial, 1744 targetName GeneralName OPTIONAL, 1745 certDigestInfo ObjectDigestInfo OPTIONAL 1746 } 1748 IetfAttrSyntax ::= SEQUENCE { 1749 policyAuthority[0] GeneralNames OPTIONAL, 1750 values SEQUENCE OF CHOICE { 1751 octets OCTET STRING, 1752 oid OBJECT IDENTIFIER, 1753 string UTF8String 1754 } 1755 } 1757 SvceAuthInfo ::= SEQUENCE { 1758 service GeneralName, 1759 ident GeneralName, 1760 authInfo OCTET STRING OPTIONAL 1761 } 1763 RoleSyntax ::= SEQUENCE { 1764 roleAuthority [0] GeneralNames OPTIONAL, 1765 roleName [1] GeneralName 1766 } 1768 Clearance ::= SEQUENCE { 1769 policyId OBJECT IDENTIFIER, 1770 classList ClassList DEFAULT {unclassified}, 1771 securityCategories 1772 SET OF SecurityCategory OPTIONAL 1773 } 1775 ClassList ::= BIT STRING { 1776 unmarked (0), 1777 unclassified (1), 1778 restricted (2), 1779 confidential (3), 1780 secret (4), 1781 topSecret (5) 1782 } 1784 SecurityCategory ::= SEQUENCE { 1785 type [0] IMPLICIT OBJECT IDENTIFIER, 1786 value [1] ANY DEFINED BY type 1787 } 1789 AAControls ::= SEQUENCE { 1790 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1791 permittedAttrs [0] AttrSpec OPTIONAL, 1792 excludedAttrs [1] AttrSpec OPTIONAL, 1793 permitUnSpecified BOOLEAN DEFAULT TRUE 1794 } 1796 AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER 1798 ACClearAttrs ::= SEQUENCE { 1799 acIssuer GeneralName, 1800 acSerial INTEGER, 1801 attrs SEQUENCE OF Attribute 1802 } 1804 ProxyInfo ::= SEQUENCE OF Targets 1806 END 1808 Appendix C: Change History 1810 <> 1812 This appendix lists major changes since the previous revision. 1814 Major changes since last revision: 1816 Changes from -05 to -06: 1818 1. Added new item 1 to validation rules in section 5. 1819 2. Added security considerations text about "rogue" CAs. 1820 3. Changed to allow holder.entityName = PKC.subject or 1821 PKC.subjectAltName for the relevant cases & clarified that Holder 1822 should only have one value. 1823 4. Changed to insist on version 2 to avoid clash with possibly ISO 1824 syntax issue. 1825 5. Updated references. 1827 Changes from -04 to -05: 1829 1. Changed from referencing rfc2459 to new-part1 and pkalgs. 1831 Changes from -03 to -04 1833 1. Folding in last call comments. 1834 2. Last bits of synchronizing with X.509 2000 spec. 1836 Changes from -02 to -03 1838 1. Many minor editorial changes 1839 2. Changed OID max element arc text in app. A 1840 3. Removed restriction on Clearance SecurityValue syntaxes to allow 1841 support for various existing clearance schemes 1842 4. Finalized alignment with 4th edition of X.509 1844 Changes from -01 to -02 1846 1. Re-Synchronized with X.509 DAM 1847 2. Deleted AC chains concept 1848 3. Moved AAControls to "optional features" section 1849 4. Samples will be a separate draft 1850 5. Revocation: now using X.509 DAM (noRevAvail) and standard 2459 1851 mechanisms only 1852 6. Deleted the special wildcard target "ALL" 1854 Changes from -00 to -01 1856 1. Re-structured conformance to profile + options as per Oslo 1857 consensus 1858 2. Moved acquisition protocol (LAAP)_to separate I-D 1859 3. Removed restrictions entirely 1860 4. Added new AC revocation options 1861 5. Added optional support for use of objectDigestInfo for keys 1862 6. Added optional support for chains of ACs 1863 7. Changed some syntax: 1864 Added UTF8String to IetfAttrSyntax value choice 1865 Split target & proxy extensions, removed owner from proxyInfo 1866 8. Allocated PKIX OIDs (note: check with repository before using 1867 these, the PKIX arc is currently available at 1868 http://www.imc.org/ietf-pkix/pkix-oid.asn) 1869 9. Added compiled ASN.1 module