idnits 2.17.00 (12 Aug 2021) /tmp/idnits29214/draft-ietf-pkix-ac509prof-03.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. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The first octets (the first characters of the first line) of this draft are 'PK', which can make Internet Explorer erroneously think that it is a zip file. It is recommended that you change this, for instance by inserting a blank line before the line starting with 'PK'. == Line 269 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 1751 -- Looks like a reference, but probably isn't: '1' on line 1752 -- Looks like a reference, but probably isn't: '2' on line 1699 == Missing Reference: 'UNIVERSAL 12' is mentioned on line 1626, but not defined == Unused Reference: 'CMC' is defined on line 1425, but no explicit reference was found in the text == Unused Reference: 'CMP' is defined on line 1427, but no explicit reference was found in the text == Unused Reference: 'ESS' is defined on line 1436, but no explicit reference was found in the text == Outdated reference: draft-ietf-pkix-cmc has been published as RFC 2797 ** Obsolete normative reference: RFC 2510 (ref. 'CMP') (Obsoleted by RFC 4210) ** Obsolete normative reference: RFC 2630 (ref. 'CMS') (Obsoleted by RFC 3369, RFC 3370) -- Possible downref: Normative reference to a draft: ref. 'ECDSA' ** 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) == Outdated reference: draft-ietf-cat-kerberos-pk-init has been published as RFC 4556 ** Obsolete normative reference: RFC 2459 (ref. 'PKIXPROF') (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 1738 (ref. 'URL') (Obsoleted by RFC 4248, RFC 4266) Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group S. Farrell 2 INTERNET-DRAFT Baltimore Technologies 3 Expires in six months R. Housley 4 SPYRUS 5 May 2000 7 An Internet Attribute Certificate 8 Profile for Authorization 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of [RFC2026]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This specification defines a profile for the use of X.509 Attribute 34 Certificates in Internet Protocols. Attribute certificates may be 35 used in a wide range of applications and environments covering a 36 broad spectrum of interoperability goals and a broader spectrum of 37 operational and assurance requirements. The goal of this document is 38 to establish a common baseline for generic applications requiring 39 broad interoperability as well as limited special purpose 40 requirements. The profile places emphasis on attribute certificate 41 support for Internet electronic mail, IPSec, and WWW security 42 applications. 44 Table of Contents 46 Status of this Memo.............................................1 47 Abstract........................................................1 48 Table of Contents...............................................2 49 1. Introduction.................................................3 50 1.1 Delegation and AC chains...............................4 51 1.2 Attribute Certificate Distribution ("push" vs "pull")..4 52 1.3 Document Structure.....................................5 53 2. Terminology..................................................6 54 3. Requirements.................................................7 55 4. Attribute Certificate Profile................................8 56 4.1 X.509 Attribute Certificate Definition.................8 57 4.2 Profile of Standard Fields............................10 58 4.2.1 Version.........................................10 59 4.2.2 Holder..........................................10 60 4.2.3 Issuer..........................................11 61 4.2.4 Signature.......................................12 62 4.2.5 Serial Number...................................12 63 4.2.6 Validity Period.................................12 64 4.2.7 Attributes......................................13 65 4.2.8 Issuer Unique Identifier........................13 66 4.2.9 Extensions......................................13 67 4.3 Extensions............................................14 68 4.3.1 Audit Identity..................................14 69 4.3.2 AC Targeting....................................15 70 4.3.3 Authority Key Identifier........................16 71 4.3.4 Authority Information Access....................16 72 4.3.5 CRL Distribution Points.........................16 73 4.3.6 No Revocation Available.........................17 74 4.4 Attribute Types.......................................17 75 4.4.1 Service Authentication Information..............18 76 4.4.2 Access Identity.................................18 77 4.4.3 Charging Identity...............................18 78 4.4.4 Group...........................................19 79 4.4.5 Role............................................19 80 4.4.6 Clearance.......................................19 81 4.5 Profile of AC issuer's PKC............................21 82 5. Attribute Certificate Validation............................22 83 6. Revocation..................................................23 84 7. Optional Features...........................................24 85 7.1 Attribute Encryption..................................24 86 7.2 Proxying..............................................25 87 7.3 Use of ObjectDigestInfo...............................26 88 7.4 AA Controls...........................................27 89 8. Security Considerations.....................................29 90 9. References..................................................31 91 Author's Addresses.............................................32 92 Full Copyright Statement.......................................32 93 Appendix A: Object Identifiers.................................33 94 Appendix B: ASN.1 Module.......................................34 96 1. Introduction 98 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 99 in this document are to be interpreted as described in [RFC2119]. 101 A server makes an access control decision when a client requests 102 access to a resource offered by that server. The server must ensure 103 that the client is authorized to access that resource. The server 104 decision is based on the access control policy, the context of the 105 request, and the identity and authorizations of the client. The 106 access control policy and the context of the request are readily 107 available to the server. Certificates may be used to provide 108 identity and authorization information about the client. 110 Similar access control decisions are made in other network 111 environments, such as a store-and-forward electronic mail 112 environment. That is, access control decisions are not limited to 113 client-server protocol environments. 115 X.509 public key certificates (PKCs) [X.509-97, X.509-DAM, PKIXPROF] 116 bind an identity and a public key. The identity may be used to 117 support identity-based access control decisions after the client 118 proves that it has access to the private key that corresponds to the 119 public key contained in the PKC. The public key is used to validate 120 digital signatures or cryptographic key management operations. 121 However, not all access control decisions are identity-based. Rule- 122 based, role-based, and rank-based access control decisions require 123 additional information. For example, information about a client's 124 ability to pay for a resource access may be more important than the 125 client's identity. Authorization information to support such access 126 control decisions may be placed in a PKC extension or placed in a 127 separate attribute certificate (AC). 129 The placement of authorization information in PKCs is usually 130 undesirable for two reasons. First, authorization information often 131 does not have the same lifetime as the binding of the identity and 132 the public key. When authorization information is placed in a PKC 133 extension, the general result is the shortening of the PKC useful 134 lifetime. Second, the PKC issuer is not usually authoritative for 135 the authorization information. This results in additional steps for 136 the PKC issuer to obtain authorization information from the 137 authoritative source. 139 For these reasons, it is often better to separate this authorization 140 information from the PKC. Yet, this authorization information also 141 needs to be protected in a fashion similar to a PKC. An AC provides 142 this protection; it is simply a digitally signed (or certified) set 143 of attributes. 145 An AC is a structure similar to a PKC; the main difference being 146 that the AC contains no public key. An AC may contain attributes 147 that specify group membership, role, security clearance, or other 148 access control information associated with the AC holder. The syntax 149 for the AC is defined in Recommendation X.509, making the term 150 "X.509 certificate" ambiguous. This document specifies a profile of 151 the X.509 AC suitable for use with authorization information within 152 Internet protocols. 154 When making an access control decision based on an AC, an access 155 control decision function may need to ensure that the appropriate AC 156 holder is the entity that has requested access. For example, one way 157 in which the linkage between the request and the AC can be achieved 158 is if the AC has a reference to a PKC for the requester and that PKC 159 has been used to authenticate the access request. 161 Some people constantly confuse PKCs and ACs. An analogy may make the 162 distinction clear. A PKC can be considered to be like a passport: it 163 identifies the holder, tends to last for a long time, and should not 164 be trivial to obtain. An AC is more like an entry visa: it is 165 typically issued by a different authority and does not last for as 166 long a time. As acquiring an entry visa typically requires 167 presenting a passport, getting a visa can be a simpler process. 169 1.1 Delegation and AC chains 171 The X.509 standard [X.509-DAM] defines authorization as the 172 "conveyance of privilege from one entity that holds such privilege, 173 to another entity". An AC is one authorization mechanism. 175 An ordered sequence of ACs could be used to verify the authenticity 176 of a privilege asserter's privilege. In this way, chains or paths of 177 ACs could be employed to delegate authorization. 179 As the administration and processing associated with such AC chains 180 is more complex than use of one AC issued by a single authority, and 181 as the use of ACs in the Internet today is quite limited, this 182 specification does NOT RECOMMEND the use of AC chains. Other 183 (future) specifications may address the use of AC chains. 185 This means that conformant implementations are only REQUIRED to be 186 able to "handle" a single AC at a time. Note however, that 187 validation of that 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 access control decision functions. 194 However, there are a number of possible communication 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. 201 In other cases, it is more suitable for a client simply to 202 authenticate to the server and for the server to request ("pull") 203 the client's AC from an AC issuer or a repository. A major benefit 204 of the "pull" model is that it can be implemented without changes to 205 the client or to the client-server protocol. It is also more 206 suitable for some inter-domain cases where the client's rights 207 should be assigned within the server's domain, rather than within 208 the client's domain. 210 There are a number of possible exchanges involving three entities: 211 the client, the server, and the AC issuer. In addition, a directory 212 service or other repository for AC retrieval MAY be supported. 214 Figure 1 shows an abstract view of the exchanges that may involve 215 ACs. This profile does not specify protocol for these exchanges. 217 +--------------+ 218 | | Server Acquisition 219 | AC issuer +----------------------------+ 220 | | | 221 +--+-----------+ | 222 | | 223 | Client | 224 | Acquisition | 225 | | 226 +--+-----------+ +--+------------+ 227 | | AC "push" | | 228 | Client +-------------------------+ Server | 229 | | (part of app. protocol) | | 230 +--+-----------+ +--+------------+ 231 | | 232 | Client | Server 233 | Lookup +--------------+ | Lookup 234 | | | | 235 +---------------+ Repository +---------+ 236 | | 237 +--------------+ 239 Figure 1: AC Exchanges 241 1.3 Document Structure 243 The remainder of the document is structured as follows: 245 Section 2 defines some terminology; Section 3 specifies the 246 requirements that this profile is to meet; Section 4 contains the 247 profile of the X.509 AC; Section 5 specifies rules for AC 248 validation; Section 6 specifies rules for AC revocation checks; 249 Section 7 specifies optional features which MAY be supported but for 250 which support is not required for conformance to this profile; and 251 Appendices contain the list of OIDs required to support this 252 specification and a ASN.1 module. 254 2. Terminology 256 For simplicity, we use the terms client and server in this 257 specification. This is not intended to indicate that ACs are only to 258 be used in client-server environments. For example, ACs may be used 259 in the S/MIME v3 context, where the mail user agent would be both a 260 "client" and a "server" in the sense the terms are used here. 262 Term Meaning 264 AA Attribute Authority, the entity that issues the 265 AC, synonymous in this specification with "AC 266 issuer" 267 AC Attribute Certificate 268 AC user any entity that parses or processes an AC 269 AC verifier any entity that checks the validity of an AC and 270 then makes use of the result 271 AC issuer the entity which signs the AC, synonymous in this 272 specification with "AA" 273 AC holder the entity indicated (perhaps indirectly) in the 274 holder field of the AC 275 Client the entity which is requesting the action for 276 which authorization checks are to be made 277 Proxying In this specification, Proxying is used to mean 278 the situation where an application server acts as 279 an application client on behalf of a user. 280 Proxying here does not mean granting of authority. 281 PKC Public Key Certificate - uses the type ASN.1 282 Certificate defined in X.509 and profiled in RFC 283 2459. This (non-standard) acronym is used in order 284 to avoid confusion about the term "X.509 285 certificate". 286 Server the entity which requires that the authorization 287 checks are made 289 3. Requirements 291 This AC profile meets the following requirements. 293 Time/Validity requirements: 295 1. Support for short-lived as well as long-lived ACs is required. 296 Typical validity periods might be measured in hours, as opposed 297 to months for PKCs. Short validity periods allow ACs to be 298 useful without a revocation mechanism. 300 Attribute Types: 302 2. Issuers of ACs should be able to define their own attribute 303 types for use within closed domains. 304 3. Some standard attribute types should be defined which can be 305 contained within ACs. examples include "access identity", 306 "group", "role", "clearance", "audit identity", and "charging 307 id". 308 4. Standard attribute types should be defined in a manner that 309 permits an AC verifier to distinguish between uses of the same 310 attribute in different domains. For example, the 311 "Administrators group" as defined by Baltimore and the 312 "Administrators group" as defined by SPYRUS should be easily 313 distinguished. 315 Targeting of ACs: 317 5. It should be possible to "target" an AC at one, or a small 318 number of, servers. This means that a trustworthy non-target 319 server will reject the AC for authorization decisions. 321 Push vs. Pull 323 6. ACs should be defined so that they can either be "pushed" by 324 the client to the server, or "pulled" by the server from a 325 repository or other network service (which may be an online AC 326 issuer). 328 4. Attribute Certificate Profile 330 ACs may be used in a wide range of applications and environments 331 covering a broad spectrum of interoperability goals and a broader 332 spectrum of operational and assurance requirements. The goal of 333 this document is to establish a common baseline for generic 334 applications requiring broad interoperability and limited special 335 purpose requirements. In particular, the emphasis will be on 336 supporting the use of attribute certificates for informal Internet 337 electronic mail, IPSec, and WWW applications. 339 This section presents a profile for ACs that will foster 340 interoperability. This section also defines some private extensions 341 for the Internet community. 343 While the ISO/IEC/ITU documents use the 1993 (or later) version of 344 ASN.1; this document uses the 1988 ASN.1 syntax, as has been done 345 for PKCs [PKIXPROF]. However, the encoded certificate and standard 346 extensions are equivalent. 348 Where maximum lengths for fields are specified, these lengths refer 349 to the DER encoding and do not include the ASN.1 tag or length 350 fields. 352 Conforming implementations MUST support the profile specified in 353 this section. 355 4.1 X.509 Attribute Certificate Definition 357 X.509 contains the definition of an AC given below. All types that 358 are not defined in this document can be found in [PKIXPROF]. 360 AttributeCertificate ::= SEQUENCE { 361 acinfo AttributeCertificateInfo, 362 signatureAlgorithm AlgorithmIdentifier, 363 signatureValue BIT STRING 364 } 366 AttributeCertificateInfo ::= SEQUENCE { 367 version AttCertVersion DEFAULT v1, 368 holder Holder, 369 issuer AttCertIssuer, 370 signature AlgorithmIdentifier, 371 serialNumber CertificateSerialNumber, 372 attrCertValidityPeriod AttCertValidityPeriod, 373 attributes SEQUENCE OF Attribute, 374 issuerUniqueID UniqueIdentifier OPTIONAL, 375 extensions Extensions OPTIONAL 376 } 378 AttCertVersion ::= INTEGER { v1(0), v2(1) } 379 Holder ::= SEQUENCE { 380 baseCertificateID [0] IssuerSerial OPTIONAL, 381 -- the issuer and serial number of 382 -- the holder's Public Key Certificate 383 entityName [1] GeneralNames OPTIONAL, 384 -- the name of the claimant or role 385 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 386 -- if present, version must be v2 387 } 389 ObjectDigestInfo ::= SEQUENCE { 390 digestedObjectType ENUMERATED { 391 publicKey (0), 392 publicKeyCert (1), 393 otherObjectTypes (2) }, 394 -- otherObjectTypes MUST NOT 395 -- be used in this profile 396 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 397 digestAlgorithm AlgorithmIdentifier, 398 objectDigest BIT STRING 399 } 401 AttCertIssuer ::= CHOICE { 402 v1Form GeneralNames, -- v1 or v2 403 v2Form [0] V2Form -- v2 only 404 } 406 V2Form ::= SEQUENCE { 407 issuerName GeneralNames OPTIONAL, 408 baseCertificateID [0] IssuerSerial OPTIONAL, 409 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 410 -- at least one of issuerName, baseCertificateID 411 -- or objectDigestInfo MUST be present 412 } 414 IssuerSerial ::= SEQUENCE { 415 issuer GeneralNames, 416 serial CertificateSerialNumber, 417 issuerUID UniqueIdentifier OPTIONAL 418 } 420 AttCertValidityPeriod ::= SEQUENCE { 421 notBeforeTime GeneralizedTime, 422 notAfterTime GeneralizedTime 423 } 425 Although the Attribute syntax is defined in [PKIXPROF], we repeat 426 the definition here for convenience. 428 Attribute ::= SEQUENCE { 429 type AttributeType, 430 values SET OF AttributeValue 431 -- at least one value is required 432 } 434 AttributeType ::= OBJECT IDENTIFIER 436 AttributeValue ::= ANY 438 Implementers should note that the DER encoding (DER is defined in 439 [X.208-88]) of the SET OF values requires ordering of the encodings 440 of the values. Though this issue arises with respect to 441 distinguished names, and has to be handled by [PKIXPROF] 442 implementations, its is much more significant in this context, since 443 the inclusion of multiple values is much more common in ACs. 445 4.2 Profile of Standard Fields 447 For all GeneralName fields in this profile the otherName (except as 448 noted below), x400Address, ediPartyName and registeredID options 449 MUST NOT be used. The use of Kerberos [KRB] format names, encoded 450 into the otherName, SHOULD however, be supported using the 451 krb5PrincipalName OID and the KerberosName syntax as defined in 452 [PKINIT]. 454 Conforming implementations MUST be able to support the dNSName, 455 directoryName, uniformResourceIdentifier, and iPAddress fields in 456 all cases where GeneralName is used. This is compatible with the 457 GeneralName requirements in [PKIXPROF] (mainly in section 4.2.1.7). 459 4.2.1 Version 461 The version field MUST be the default value of v1. That is, the 462 version field is not present in the DER encoding, except when the 463 holder is identified using the optional objectDigestInfo field, as 464 specified in section 7.3. 466 4.2.2 Holder 468 For any environment where the AC is passed in an authenticated 469 message or session and where the authentication is based on the use 470 of an X.509 PKC, the holder field SHOULD use the baseCertificateID. 471 Note that this profile uses the field name "baseCertificateID" 472 everywhere, whereas [X.509-DAM] sometimes uses this, and sometimes 473 uses the field name "baseCertificateId" (i.e. ending with a 474 lowercase "d"). The use of different names causes programming 475 difficulties so developers may need to be aware of which ASN.1 476 module has been used (i.e. the [X.509-DAM] one, or the one from 477 Appendix B). 479 With the baseCertificateID option, the holder's PKC serialNumber and 480 issuer MUST be identical to the AC holder field. The PKC issuer MUST 481 have a non-empty distinguished name which is to be present as the 482 single value of the holder.baseCertificateID.issuer construct in the 483 directoryName field. The holder.baseCertificateID.issuerUID field 484 MUST only be used if the holder's PKC contains an issuerUniqueID 485 field. If both the holder.baseCertificateID.issuerUID and the 486 issuerUniqueID fields are present, then the same value MUST be 487 present in both _fields. Thus, the baseCertificateID is only usable 488 with PKC profiles (like [PKIXPROF]) which mandate that the PKC 489 issuer field contain a non-empty distinguished name value. 491 Note: An empty distinguished name is a distinguished name where the 492 SEQUENCE OF relative distinguished names is of zero length. In a DER 493 encoding this has the value '3000'H. 495 If the holder field uses the entityName option and the underlying 496 authentication is based on a PKC, then the entityName MUST be the 497 same as the PKC subject field, unless the PKC subject field contains 498 an empty distinguished name. If the PKC subject field contains an 499 empty distinguished name, then the entityName field MUST be 500 identical to one of the values of the PKC subjectAltName field 501 extension. Note that [PKIXPROF] mandates that the subjectAltNames 502 extension be present if the PKC subject is an empty distinguished 503 name. 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 allows 524 the AC verifier to be independent of the AC issuer's public key 525 infrastructure. Using the baseCertificateID field to reference the 526 AC issuer would mean that the AC verifier would have such a 527 dependency. 529 4.2.4 Signature 531 Contains the algorithm identifier used to validate the AC signature. 533 This MUST be one of the following algorithms defined in [PKIXPROF] 534 section 7.2 or [ECDSA] section 3.2: md5WithRSAEncryption, id-dsa- 535 with-sha1, sha-1WithRSAEncryption, or ecdsa-with-SHA1. 537 id-dsa-with-sha1 MUST be supported by all AC users. The other 538 algorithms SHOULD be supported. 540 4.2.5 Serial Number 542 For any conforming AC, the issuer/serialNumber pair MUST form a 543 unique combination, even if ACs are very short-lived. 545 AC issuers MUST force the serialNumber to be a positive integer, 546 that is, the sign bit in the DER encoding of the INTEGER value MUST 547 be zero - this can be done by adding a leading (leftmost) '00'H 548 octet if necessary. This removes a potential ambiguity in mapping 549 between a string of octets and an integer value. 551 Given the uniqueness and timing requirements above serial numbers 552 can be expected to contain long integers. AC users MUST be able to 553 handle serialNumber values longer than 4 octets. Conformant ACs MUST 554 NOT contain serialNumber values longer than 20 octets. 556 There is no requirement that the serial numbers used by any AC 557 issuer follow any particular ordering, in particular, they need not 558 be monotonically increasing with time. Each AC issuer MUST ensure 559 that each AC that it issues contain a unique serial number. 561 4.2.6 Validity Period 563 The attrCertValidityPeriod (a.k.a. validity) field specifies the 564 period for which the AC issuer expects that the binding between the 565 holder and the attributes fields will be valid. 567 The generalized time type, GeneralizedTime, is a standard ASN.1 type 568 for variable precision representation of time. The GeneralizedTime 569 field can optionally include a representation of the time 570 differential between the local time zone and Greenwich Mean Time. 572 For the purposes of this profile, GeneralizedTime values MUST be 573 expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., 574 times are YYYYMMDDHHMMSSZ), even where the number of seconds is 575 zero. GeneralizedTime values MUST NOT include fractional seconds. 576 (Note: this is the same as specified in [PKIXPROF], section 577 4.1.2.5.2.) 579 AC users MUST be able to handle an AC which, at the time of 580 processing, has its entire validity period in the future (a post- 581 dated AC). This is valid 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. If any other critical extension is used, then the AC does 618 not conform to this profile. However, if any other non-critical 619 extension is used, then the AC does conform to this profile. 621 The extensions defined for ACs provide methods for associating 622 additional attributes with holders. This profile also allows 623 communities to define private extensions to carry information unique 624 to those communities. Each extension in an AC may be designated as 625 critical or non-critical. An AC using system MUST reject an AC if 626 it encounters a critical extension it does not recognize; however, a 627 non-critical extension may be ignored if it is not recognized. 628 Section 4.3 presents recommended extensions used within Internet ACs 629 and standard locations for information. Communities may elect to 630 use additional extensions; however, caution should be exercised in 631 adopting any critical extensions in ACs, which might prevent use in 632 a general context. 634 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 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-DAM], 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 is only present to allow future compatibility 715 with [X.509-DAM] 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 name id-ce-targetInformation 733 OID { id-ce 55 } 734 syntax Targets 735 criticality MUST be TRUE 737 4.3.3 Authority Key Identifier 739 The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY 740 be used to assist the AC verifier in checking the signature of the 741 AC. The [PKIXPROF] description should be read as if "CA" meant "AC 742 issuer." As with PKCs this extension SHOULD be included in ACs. 744 Note: An AC where the issuer field used the baseCertificateID CHOICE 745 would not need an authorityKeyIdentifier extension as it is 746 explicitly linked to the key in the referred certificate. However, 747 as this profile states (in section 4.2.3) that ACs MUST use the 748 v1Form CHOICE, this duplication does not arise. 750 name id-ce-authorityKeyIdentifier 751 OID { id-ce 35 } 752 syntax AuthorityKeyIdentifier 753 criticality MUST be FALSE 755 4.3.4 Authority Information Access 757 The authorityInformationAccess extension, as defined in [PKIXPROF], 758 MAY be used to assist the AC verifier in checking the revocation 759 status of the AC. Support for the id-ad-caIssuers accessMethod is 760 NOT REQUIRED by this profile since AC chains are not expected. The 761 authorityInformationAccess extension is only used to support 762 revocation status checking, therefore conformant ACs containing this 763 extension MUST contain exactly one AccessDescription. 765 The following accessMethod is used to indicate that revocation 766 status checking is provided for this AC, using the OCSP protocol 767 defined in [OCSP]: 769 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 771 The accessLocation MUST contain a URI, and theURI MUST contain an 772 HTTP URL [URL] that specifies the location of an OCSP responder. The 773 AC issuer MUST, of course, maintain an OCSP responder at this 774 location. 776 name id-ce-authorityInfoAccess 777 OID { id-pe 1 } 778 syntax AuthorityInfoAccessSyntax 779 criticality MUST be FALSE 781 4.3.5 CRL Distribution Points 783 The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY 784 be used to assist the AC verifier in checking the revocation status 785 of the AC. See section 6 for details on revocation. 787 If the crlDistributionPoints extension is present, then exactly one 788 distribution point MUST be present. The crlDistributionPoints 789 extension MUST use the DistributionPointName option, which MUST 790 contain a fullName, which MUST contain a single name form. That name 791 MUST contain either a distinguished name or a URI. The URI MUST be 792 either an HTTP URL or an LDAP URL [URL]. 794 name id-ce-cRLDistributionPoints 795 OID { id-ce 31 } 796 syntax CRLDistPointsSyntax 797 criticality MUST be FALSE 799 4.3.6 No Revocation Available 801 The noRevAvail extension, defined in [X.509-DAM], allows an AC 802 issuer to indicate that no revocation information will be made 803 available for this AC. 805 This extension MUST be non-critical. An AC verifier that does not 806 understand this extension might be able to find a revocation list 807 from the AC issuer, but the revocation list will never include an 808 entry for the AC. 810 name id-ce-noRevAvail 811 OID { id-ce 56 } 812 syntax NULL (i.e. '0500'H is the DER encoding) 813 criticality MUST be FALSE 815 4.4 Attribute Types 817 Some of the attribute types defined below make use of the 818 IetfAttrSyntax type, also defined below. The reasons for using this 819 type are: 821 1. It allows a separation between the AC issuer and the attribute 822 policy authority. This is useful for situations where a single 823 policy authority (e.g. an organization) allocates attribute 824 values, but where multiple AC issuers are deployed for 825 performance or other reasons. 826 2. The syntaxes allowed for values are restricted to OCTET STRING, 827 OBJECT IDENTIFIER, and UTF8String, which significantly reduces 828 the complexity associated with matching more general syntaxes. 829 All multi-valued attributes using this syntax are restricted so 830 that each value MUST use the same choice of value syntax. For 831 example, AC issuers must not use one value with an oid and a 832 second value with a string. 834 IetfAttrSyntax ::= SEQUENCE { 835 policyAuthority [0] GeneralNames OPTIONAL, 836 values SEQUENCE OF CHOICE { 837 octets OCTET STRING, 838 oid OBJECT IDENTIFIER, 839 string UTF8String 840 } 841 } 843 In the descriptions below, each attribute type is tagged as either 844 "Multiple Allowed" or "One Attribute value only; multiple values 845 within the IetfAttrSyntax". This refers to the SET OF 846 AttributeValue, the AttributeType still only occurs once, as 847 specified in section 4.2.7. 849 4.4.1 Service Authentication Information 851 The SvceAuthInfo attribute identifies the AC holder to the 852 server/service by a name, and the attribute MAY include optional 853 service specific authentication information. Typically this will 854 contain a username/password pair for a "legacy" application. 856 This attribute type will typically be encrypted when the authInfo 857 field contains sensitive information, such as a password. 859 name id-aca-authenticationInfo 860 OID { id-aca 1 } 861 Syntax SvceAuthInfo 862 values: Multiple allowed 864 SvceAuthInfo ::= SEQUENCE { 865 service GeneralName, 866 ident GeneralName, 867 authInfo OCTET STRING OPTIONAL 868 } 870 4.4.2 Access Identity 872 The accessIdentity attribute identifies the AC holder to the 873 server/service. For this attribute the authInfo field MUST NOT be 874 present. 876 name id-aca-accessIdentity 877 OID { id-aca 2 } 878 syntax SvceAuthInfo 879 values: Multiple allowed 881 4.4.3 Charging Identity 883 The chargingIdentity attribute identifies the AC holder for charging 884 purposes. In general, the charging identity will be different from 885 other identities of the holder. For example, the holder's company 886 may be charged for service. 888 name id-aca-chargingIdentity 889 OID { id-aca 3 } 890 syntax IetfAttrSyntax 891 values: One Attribute value only; multiple values within the 892 IetfAttrSyntax 894 4.4.4 Group 896 The group attribute carries information about group memberships of 897 the AC holder. 899 name id-aca-group 900 OID { id-aca 4 } 901 syntax IetfAttrSyntax 902 values: One Attribute value only; multiple values within the 903 IetfAttrSyntax 905 4.4.5 Role 907 The role attribute, specified in [X.509-DAM], carries information 908 about role allocations of the AC holder. 910 The syntax used for this attribute is: 912 RoleSyntax ::= SEQUENCE { 913 roleAuthority [0] GeneralNames OPTIONAL, 914 roleName [1] GeneralName 915 } 917 The roleAuthority field MUST NOT be used. The roleName field MUST be 918 present, and roleName MUST use the uniformResourceIdentifier CHOICE 919 of the GeneralName. 921 name id-at-role 922 OID { id-at 72 } 923 syntax RoleSyntax 924 values: Multiple allowed 926 4.4.6 Clearance 928 The clearance attribute, specified in [X.501-93], carries clearance 929 (associated with security labeling) information about the AC holder. 931 The policyId field is used to identify the security policy to which 932 the clearance relates. The policyId indicates the semantics of the 933 classList and securityCategories fields. 935 This specification includes the classList field exactly as is 936 specified in [X.501-93]. Additional security classification values, 937 and their position in the classification hierarchy, may be defined 938 by a security policy as a local matter or by bilateral agreement. 939 The basic security classification hierarchy is, in ascending order: 940 unmarked, unclassified, restricted, confidential, secret, and top- 941 secret. 943 An organization can develop its own security policy that defines 944 security classification values and their meanings. However, the BIT 945 STRING positions 0 through 5 are reserved for the basic security 946 classification hierarchy. 948 If present, the SecurityCategory field provides further 949 authorization information. The security policy identified by the 950 policyId field indicates the syntaxes that are allowed to be present 951 in the securityCategories SET. An OBJECT IDENTIFIER identifies each 952 of the allowed syntaxes. When one of these syntaxes is present in 953 the securityCategories SET, the OBJECT IDENTIFIER associated with 954 that syntax is carried in the SecurityCategory.type field. 956 Clearance ::= SEQUENCE { 957 policyId OBJECT IDENTIFIER, 958 classList ClassList DEFAULT {unclassified}, 959 securityCategories 960 SET OF SecurityCategory OPTIONAL 961 } 963 ClassList ::= BIT STRING { 964 unmarked (0), 965 unclassified (1), 966 restricted (2) 967 confidential (3), 968 secret (4), 969 topSecret (5) 970 } 972 SecurityCategory ::= SEQUENCE { 973 type [0] IMPLICIT OBJECT IDENTIFIER, 974 value [1] ANY DEFINED BY type 975 } 977 -- This is the same as the original syntax which was defined 978 -- using the MACRO construct, as follows: 979 -- SecurityCategory ::= SEQUENCE { 980 -- type [0] IMPLICIT SECURITY-CATEGORY, 981 -- value [1] ANY DEFINED BY type 982 -- } 983 -- 984 -- SECURITY-CATEGORY MACRO ::= 985 -- BEGIN 986 -- TYPE NOTATION ::= type | empty 987 -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 988 -- END 990 name { id-at-clearance } 991 OID { joint-iso-ccitt(2) ds(5) module(1) 992 selected-attribute-types(5) clearance (55) } 993 syntax Clearance - imported from [X.501-93] 994 values Multiple allowed 996 4.5 Profile of AC issuer's PKC 998 The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage 999 extension in the PKC MUST NOT explicitly indicate that the AC 1000 issuer's public key cannot be used to validate a digital signature. 1001 In order to avoid confusion regarding serial numbers and 1002 revocations, an AC issuer MUST NOT also be a PKC Issuer. That is, 1003 an AC issuer cannot be a CA as well. So, the AC issuer's PKC MUST 1004 NOT have a basicConstraints extension with the cA BOOLEAN set to 1005 TRUE. 1007 5. Attribute Certificate Validation 1009 This section describes a basic set of rules that all valid ACs MUST 1010 satisfy. Some additional checks are also described which AC 1011 verifiers MAY choose to implement. 1013 To be valid an AC MUST satisfy all of the following: 1015 1. The AC signature must be cryptographically correct, and the AC 1016 issuer's entire PKC certification path MUST be verified in 1017 accordance with [PKIXPROF]. 1018 2. The AC issuer's PKC MUST also conform to the profile specified 1019 in section 4.5 above. 1020 3. The AC issuer MUST be directly trusted as an AC issuer (by 1021 configuration or otherwise). 1022 4. The time for which the AC is being evaluated MUST be within the 1023 AC validity. If the evaluation time is equal to either 1024 notBeforeTime or notAfterTime, then the AC is timelyand this 1025 check succeeds. Note that in some applications, the evaluation 1026 time MAY not be the same as the current time. 1027 5. The AC targeting check MUST pass as specified in section 4.3.2. 1028 6. If the AC contains a critical extension that is not listed in 1029 section 4.3, then the AC MUST be rejected. 1031 Support for an extension in this context means: 1033 1. The AC verifier MUST be able to parse the extension value. 1034 2. Where the extension value SHOULD cause the AC to be rejected, 1035 the AC verifier MUST reject the AC. 1037 Additional Checks: 1039 1. The AC MAY be rejected on the basis of further AC verifier 1040 configuration. For example, an AC verifier may be configured to 1041 reject ACs which contain or lack certain attributes. 1042 2. If the AC verifier provides an interface that allows 1043 applications to query the contents of the AC, then the AC 1044 verifier MAY filter the attributes from the AC on the basis of 1045 configured information. For example, an AC verifier might be 1046 configured not to return certain attributes to certain servers. 1048 6. Revocation 1050 In many environments, the validity period of an AC is less than the 1051 time required to issue and distribute revocation information. 1052 Therefore, short-lived ACs typically do not require revocation 1053 support. However, long-lived ACs and environments where ACs enable 1054 high value transactions MAY require revocation support. 1056 Two revocation schemes are defined, and the AC issuer should elect 1057 the one that is best suited to the environment in which the AC will 1058 be employed. 1060 "Never revoke" scheme: 1062 ACs may be marked so that the relying party understands that no 1063 revocation status information will be made available. The 1064 noRevAvail extension is defined in section 4.3.6, and the 1065 noRevAvail extension MUST be present in the AC to indicate use 1066 of this scheme. 1068 Where no noRevAvail is not present, then the AC issuer is 1069 implicitly stating that revocation status checks are supported, 1070 and some revocation method MUST be provided to allow AC 1071 verifiers to establish the revocation status of the AC. 1073 "Pointer in AC" scheme: 1075 ACs may "point" to sources of revocation status information, 1076 using either an authorityInfoAccess extension or a 1077 crlDistributionPoints extension within the AC. 1079 For AC users, the "never revoke" scheme MUST be supported, and the 1080 "pointer in AC" scheme SHOULD be supported. If only the "never 1081 revoke" scheme is supported, then all ACs that do not contain a 1082 noRevAvail extension, MUST be rejected. 1084 For AC issuers, the "never revoke" scheme MUST be supported. If all 1085 ACs that will ever be issued by that AC issuer, will contain a 1086 noRevAvail extension, then the "pointer in AC" scheme need not be 1087 supported. If any AC can be issued that does not contain the 1088 noRevAvail extension, then the "pointer in AC" scheme MUST be 1089 supported. 1091 All conformant ACs MUST contain exactly one of the noRevAvail, 1092 authorityInformationAccess or crlDistributionPoints extensions. That 1093 is, the crlDistributionPoints, authorityInformationAccess and 1094 noRevAvail extensions are mutually exclusive for a single AC, and 1095 one AC MUST NOT contain more than one of these extensions. This 1096 differs from PKCs, which permit both authorityInformationAccess and 1097 crlDistributionPoints extensions within one PKC. 1099 An AC verifier MAY any use source for AC revocation status 1100 information. 1102 7. Optional Features 1104 This section specifies features that MAY be implemented. Conformance 1105 to this profile does NOT require support for these features; 1106 however, if these features are offered, they MUST be offered as 1107 described below. 1109 7.1 Attribute Encryption 1111 Where an AC will be carried in clear within an application protocol 1112 or where an AC contains some sensitive information like a legacy 1113 application username/password, then encryption of AC attributes MAY 1114 be needed. 1116 When a set of attributes are to be encrypted within an AC, the 1117 Cryptographic Message Syntax, EnvelopedData structure [CMS] is used 1118 to carry the ciphertext and associated per-recipient keying 1119 information. 1121 This type of attribute encryption is targeted. Before the AC is 1122 signed, the attributes are encrypted for a set of predetermined 1123 recipients. 1125 The AC then contains the ciphertext inside its signed data. The 1126 EenvelopedData (id-envelopedData) ContentType is used, and the 1127 content field will contain the EnvelopedData type. 1129 The ciphertext is included in the AC as the value of an encAttrs 1130 attribute. Only one encAttrs attribute can be present in an AC; 1131 however, the encAttrs attribue MAY be multi-valued, and each of its 1132 values will contain an independent EnvelopedData. 1134 Each value can contain a set of attributes (each possibly a multi- 1135 valued attribute) encrypted for a set of predetermined recipients. 1137 The cleartext that is encrypted has the type: 1139 ACClearAttrs ::= SEQUENCE { 1140 acIssuer GeneralName, 1141 acSerial INTEGER, 1142 attrs SEQUENCE OF Attribute 1143 } 1145 The DER encoding of the ACClearAttrs structure is used as the 1146 encryptedContent field of the EnvelopedData. The DER encoding MUST 1147 be embedded in an OCTET STRING. 1149 The acIssuer and acSerial fields are present to prevent ciphertext 1150 stealing. When an AC verifier has successfully decrypted an 1151 encrypted attribute it MUST then check that the AC issuer and 1152 serialNumber fields contain the same values. This prevents a 1153 malicious AC issuer from copying ciphertext from another AC (without 1154 knowing its corresponding plaintext). 1156 The procedure for an AC issuer when encrypting attributes is 1157 illustrated by the following (any other procedure that gives the 1158 same result MAY be used): 1160 1. Identify the sets of attributes that are to be encrypted for 1161 each set of recipients. 1162 2. For each attribute set which is to be encrypted: 1163 2.1. Create an EnvelopedData structure for the data for this 1164 set of recipients. 1165 2.2. Encode the ContentInfo containing the EnvelopedData as a 1166 value of the encAttrs attribute 1167 2.3. Ensure the cleartext attributes are not present in the 1168 to-be-signed AC 1169 3. Add the encAttrs (with its multiple values) to the AC 1171 Note that there may be more than one attribute of the same type (the 1172 same OBJECT IDENTIFIER) after decryption. That is, an AC MAY contain 1173 the same attribute type both in clear and in encrypted form (and 1174 indeed several times if the same recipient is associated with more 1175 than one EnvelopedData). One approach implementers may choose, would 1176 be to merge attributes values following decryption in order to re- 1177 establish the "once only" constraint. 1179 name id-aca-encAttrs 1180 OID { id-aca 6} 1181 Syntax ContentInfo 1182 values Multiple Allowed 1184 If an AC contains attributes apparently encrypted for the AC 1185 verifier, then the decryption process MUST not fail. If decryption 1186 does fail, then the AC MUST be rejected. 1188 7.2 Proxying 1190 When a server acts as a client for another server on behalf of the 1191 AC holder, the server MAY need to proxy an AC. Such proxying MAY 1192 have to be done under the AC issuer's control, so that not every AC 1193 is proxiable and so that a given proxiable AC can be proxied in a 1194 targeted fashion. Support for chains of proxies (with more than one 1195 intermediate server) MAY also be required. Note that this does not 1196 involve a chain of ACs. 1198 In order to meet this requirement we define another extension, 1199 ProxyInfo, similar to the targeting extension. 1201 When this extension is present the AC verifier must check that the 1202 entity from which the AC was received was allowed to send it and 1203 that the AC is allowed to be used by this verifier. 1205 The proxying information consists of a set of proxy information, 1206 each of which is a set of targeting information. If the verifier and 1207 the sender of the AC are both named in the same proxy set then the 1208 AC can be accepted (the exact rule is given below). 1210 The effect is that the AC holder can send the AC to any valid target 1211 which can then only proxy to targets which are in one of the same 1212 proxy sets as itself. 1214 The following data structure is used to represent the 1215 targeting/proxying information. 1217 ProxyInfo ::= SEQUENCE OF Targets 1219 As in the case of targeting, the targetCert CHOICE MUST NOT be used. 1221 A proxy check succeeds if either one of the conditions below is met: 1223 1. The identity of the sender as established by the underlying 1224 authentication service matches the holder field of the AC, and the 1225 current server "matches" any one of the proxy sets. Recall that 1226 "matches" is as defined section 4.3.2. 1228 2. The identity of the sender as established by the underlying 1229 authentication service "matches" one of the proxy sets (call it 1230 set "A"), and the current server is one of the targetName fields 1231 in the set "A", or the current server is a member of one of the 1232 targetGroup fields in set "A". 1234 When an AC is proxied more than once, a number of targets will be on 1235 the path from the original client, which is normally, but not 1236 always, the AC holder. In such cases, prevention of AC "stealing" 1237 requires that the AC verifier MUST check that all targets on the 1238 path are members of the same proxy set. It is the responsibility of 1239 the AC using protocol to ensure that a trustworthy list of targets 1240 on the path is available to the AC verifier. 1242 name id-pe-ac-proxying 1243 OID { id-pe 7 } 1244 syntax ProxyInfo 1245 criticality MUST be TRUE 1247 7.3 Use of ObjectDigestInfo 1249 In some environments, it may be required that the AC is not linked 1250 either to an identity (via entityName) or to a PKC (via 1251 baseCertificateID). The objectDigestInfo CHOICE in the holder field 1252 allows support for this requirement. 1254 If the holder is identified with the objectDigestInfo field, then 1255 the AC version field MUST contain v2 (the integer 1). 1257 The idea is to link the AC to an object by placing a hash of that 1258 object into the holder field of the AC. For example, this allows 1259 production of ACs that are linked to public keys rather than names. 1261 It also allows production of ACs which contain privileges associated 1262 with an executable object such as a Java class. However, this 1263 profile only specifies how to use a hash over a public key or PKC. 1264 That is, conformant ACs MUST NOT use the otherObjectTypes value for 1265 the digestedObjectType. 1267 To link an AC to a public key, the hash must be calculated over the 1268 representation of that public key which would be present in a PKC, 1269 specifically, the input for the hash algorithm MUST be the DER 1270 encoding of a SubjectPublicKeyInfo representation of the key. Note: 1271 This includes the AlgorithmIdentifier as well as the BIT STRING. The 1272 rules given in [PKIXPROF] and [ECDSA] for encoding keys MUST be 1273 followed. In this case the digestedObjectType MUST be publicKey and 1274 the otherObjectTypeID field MUST NOT be present. 1276 Note that if the public key value used as input to the hash function 1277 has been extracted from a PKC, then it is possible that the 1278 SubjectPublicKeyInfo from that PKC is NOT the value which should be 1279 hashed. This can occur if DSA Dss-parms are inherited as described 1280 in section 7.3.3 of [PKIXPROF]. The correct input for hashing in 1281 this context will include the value of the parameters inherited from 1282 the CA's PKC, and thus may differ from the SubjectPublicKeyInfo 1283 present in the PKC. 1285 Implementations which support this feature MUST be able to handle 1286 the representations of public keys for the algorithms specified in 1287 section 7.3 of [PKIXPROF] and those specified in [ECDSA]. In this 1288 case the digestedObjectType MUST be publicKey and the 1289 otherObjectTypeID field MUST NOT be present. 1291 In order to link an AC to a PKC via a digest, the digest MUST be 1292 calculated over the DER encoding of the entire PKC, including the 1293 signature value. In this case the digestedObjectType MUST be 1294 publicKeyCert and the otherObjectTypeID field MUST NOT be present. 1296 7.4 AA Controls 1298 During AC validation a relying party has to answer the question: is 1299 this AC issuer trusted to issue ACs containing this attribute? The 1300 AAControls PKC extension MAY be used to help answer the question. 1301 The AAControls extension is intended to be used in CA and AC issuer 1302 PKCs. 1304 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1306 AAControls ::= SEQUENCE { 1307 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1308 permittedAttrs [0] AttrSpec OPTIONAL, 1309 excludedAttrs [1] AttrSpec OPTIONAL, 1310 permitUnSpecified BOOLEAN DEFAULT TRUE 1311 } 1313 AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER 1315 The AAControls extension is used as follows: 1317 The pathLenConstraint, if present, is interpreted as in [PKIXPROF]. 1318 It restricts the allowed distance between the AA CA, (a CA directly 1319 trusted to include AAControls in its PKCs), and the AC issuer. 1321 The permittedAttrs field specifies a set of attribute types that any 1322 AC issuer below this AA CA is allowed to include in ACs. If this 1323 field is not present, it means that no attribute types are 1324 explicitly allowed. 1326 The excludedAttrs field specifies a set of attribute types that no 1327 AC issuer is allowed to include in ACs. If this field is not 1328 present, it means that no attribute types are explicitly disallowed. 1330 The permitUnSpecified field specifies how to handle attribute types 1331 which are not present in either the permittedAttrs or excludedAttrs 1332 fields. TRUE (the default) means that any unspecified attribute type 1333 is allowed in ACs; FALSE means that no unspecified attribute type is 1334 allowed. 1336 When AAControls are used, the following additional checks on an AA's 1337 PKC chain MUST all succeed for the AC to be valid: 1339 1. Some CA on the ACs certificate path MUST be directly trusted to 1340 issue PKCs which precede the AC issuer in the certification 1341 path, call this CA the "AA CA". 1342 2. All PKCs on the path from the AA CA down to and including the 1343 AC issuer's PKC MUST contain an AAControls extension; however, 1344 the AA CA's PKC need not contain this extension. 1345 3. Only those attributes in the AC which are allowed according to 1346 all of the AAControls extension values in all of the PKCs from 1347 the AA CA to the AC issuer, may be used for authorization 1348 decisions, all other attributes MUST be ignored. This check 1349 MUST be applied to the set of attributes following attribute 1350 decryption, and the id-aca-encAttrs type MUST also be checked. 1352 name id-pe-aaControls 1353 OID { id-pe 6 } 1354 syntax AAControls 1355 criticality MAY be TRUE 1357 8. Security Considerations 1359 The protection afforded private keys is a critical factor in 1360 maintaining security. Failure of AC issuers to protect their 1361 private keys will permit an attacker to masquerade as them, 1362 potentially generating false ACs or revocation status. Existence of 1363 bogus ACs and revocation status will undermine confidence in the 1364 system. If the compromise is detected, all ACs issued to the AC 1365 issuer MUST be revoked. Rebuilding after such a compromise will be 1366 problematic, so AC issuers are advised to implement a combination of 1367 strong technical measures (e.g., tamper-resistant cryptographic 1368 modules) and appropriate management procedures (e.g., separation of 1369 duties) to avoid such an incident. 1371 Loss of a AC issuer's private signing key may also be problematic. 1372 The AC issuer would not be able to produce revocation status or 1373 perform AC renewal. AC issuer's are advised to maintain secure 1374 backup for signing keys. The security of the key backup procedures 1375 is a critical factor in avoiding key compromise. 1377 The availability and freshness of revocation status will affect the 1378 degree of assurance that should be placed in a long-lived AC. While 1379 long-lived ACs expire naturally, events may occur during its natural 1380 lifetime which negate the binding between the AC holder and the 1381 attributes. If revocation status is untimely or unavailable, the 1382 assurance associated with the binding is clearly reduced. 1384 The binding between an AC holder and attributes cannot be stronger 1385 than the cryptographic module implementation and algorithms used to 1386 generate the signature. Short key lengths or weak hash algorithms 1387 will limit the utility of an AC. AC issuers are encouraged to note 1388 advances in cryptology so they can employ strong cryptographic 1389 techniques. 1391 Inconsistent application of name comparison rules may result in 1392 acceptance of invalid targeted or proxied AC, or rejection of valid 1393 ones. The X.500 series of specifications defines rules for 1394 comparing distinguished names. These rules require comparison of 1395 strings without regard to case, character set, multi-character white 1396 space substrings, or leading and trailing white space. This 1397 specification and [PKIXPROF] relaxes these requirements, requiring 1398 support for binary comparison at a minimum. 1400 AC issuers MUST encode the distinguished name in the AC 1401 holder.entityName field identically to the distinguished name in the 1402 holder's PKC. If different encodings are used, implementations of 1403 this specification may fail to recognize that the AC and PKC belong 1404 to the same entity. 1406 Implementers MUST ensure that following validation of an AC, only 1407 attributes that the issuer is trusted to issue are used in 1408 authorization decisions. Other attributes, which MAY be present MUST 1409 be ignored. Given that the AA controls PKC extension is optional to 1410 implement, AC verifiers MUST be provided with this information by 1411 other means. Configuration information is a likely alternative 1412 means. This becomes very important if an AC verified trusts more 1413 than one AC issuer. 1415 There is often a requirement to map between the authentication 1416 supplied by a particular security protocol (e.g. TLS, S/MIME) and 1417 the AC holder's identity. If the authentication uses PKCs, then this 1418 mapping is straightforward. However, it is envisaged that ACs will 1419 also be used in environments where the holder may be authenticated 1420 using other means. Implementers SHOULD be very careful in mapping 1421 the authenticated identity to the AC holder. 1423 9. References 1425 [CMC] Myers, M., et al. "Certificate Management Messages over 1426 CMS", draft-ietf-pkix-cmc-05.txt, July 1999. 1427 [CMP] Adams, C., Farrell, S., "Internet X.509 Public Key 1428 Infrastructure - Certificate Management Protocols", 1429 RFC2510. 1430 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630. 1431 [ECDSA] D. Johnson, W. Polk, "Internet X.509 Public Key 1432 Infrastructure Representation of Elliptic Curve Digital 1433 Signature Algorithm (ECDSA) Keys and Signatures in 1434 Internet X.509 Public Key Infrastructure Certificates" 1435 draft-ietf-pkix-ipki-ecdsa-02.txt, October 1999. 1436 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 1437 RFC2634. 1438 [KRB] Kohl, J., Neuman, C., "The Kerberos Network 1439 Authentication Service (V5)", RFC 1510. 1440 [LDAP] Wahl, M., et al., "Lightweight Directory Access Protocol 1441 (v3)", RFC 2251. 1442 [OCSP] Myers, M., et al., " X.509 Internet Public Key 1443 Infrastructure - Online Certificate Status Protocol - 1444 OCSP", RFC 2560. 1445 [PKINIT] Tung, B., et al., "Public Key Cryptography for Initial 1446 Authentication in Kerberos", draft-ietf-cat-kerberos-pk- 1447 init-10.txt 1448 [PKIXPROF] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet 1449 Public Key Infrastructure - X.509 Certificate and CRL 1450 Profile", RFC 2459. 1451 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1452 3", RFC 2026, BCP 9, October 1996. 1453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1454 Requirement Levels", RFC 2119. 1455 [URL] Berners-Lee, T., Masinter L., and M. McCahill., "Uniform 1456 Resource Locators (URL)", RFC 1738. 1457 [X.208-88] CCITT Recommendation X.208: Specification of Abstract 1458 Syntax Notation One (ASN.1). 1988. 1459 [X.209-88] CCITT Recommendation X.209: Specification of Basic 1460 Encoding Rules for Abstract Syntax Notation One (ASN.1). 1461 1988. 1462 [X.501-88] CCITT Recommendation X.501: The Directory - Models. 1463 1988. 1464 [X.501-93] ITU-T Recommendation X.501 : Information Technology - 1465 Open Systems Interconnection - The Directory: Models, 1466 1993. 1467 [X.509-88] CCITT Recommendation X.509: The Directory - 1468 Authentication Framework. 1988. 1469 [X.509-97] ITU-T Recommendation X.509: The Directory - 1470 Authentication Framework. 1997. 1471 [X.509-DAM] ISO 9594-8 Information Technology - Open systems 1472 Interconnection - The Directory: Authentication 1473 Framework - Draft Amendment 1: Certificate Extensions, 1474 October 1999. 1476 Author's Addresses 1478 Stephen Farrell 1479 Baltimore Technologies 1480 61/62 Fitzwilliam Lane 1481 Dublin 2 1482 IRELAND 1484 tel: +353-1-647-3000 1485 email: stephen.farrell@baltimore.ie 1487 Russell Housley 1488 SPYRUS 1489 381 Elden Street 1490 Suite 1120 1491 Herndon, VA 20170 1492 USA 1494 tel: +1-703-707-0696 1495 email: housley@spyrus.com 1497 Full Copyright Statement 1499 Copyright (C) The Internet Society (date). All Rights Reserved. 1501 This document and translations of it may be copied and furnished to 1502 others, and derivative works that comment on or otherwise explain it 1503 or assist in its implementation may be prepared, copied, published 1504 and distributed, in whole or in part, without restriction of any 1505 kind, provided that the above copyright notice and this paragraph 1506 are included on all such copies and derivative works. In addition, 1507 the ASN.1 module presented in Appendix B may be used in whole or in 1508 part without inclusion of the copyright notice. However, this 1509 document itself may not be modified in any way, such as by removing 1510 the copyright notice or references to the Internet Society or other 1511 Internet organizations, except as needed for the purpose of 1512 developing Internet standards in which case the procedures for 1513 copyrights defined in the Internet Standards process shall be 1514 followed, or as required to translate it into languages other than 1515 English. 1517 The limited permissions granted above are perpetual and will not be 1518 revoked by the Internet Society or its successors or assigns. This 1519 document and the information contained herein is provided on an "AS 1520 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1521 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1522 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1523 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1524 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1526 Appendix A: Object Identifiers 1528 This (normative) appendix lists the new object identifiers which are 1529 defined in this specification. Some of these are required only for 1530 support of optional features and are not required for conformance to 1531 this profile. This specification mandates support for OIDs which 1532 have arc elements with values that are less than 2^32, (i.e. they 1533 MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less 1534 than 2^31 (i.e. less than or equal to 2,147,483,647). This allows 1535 each arc element to be represented within a single 32 bit word. 1536 Implementations MUST also support OIDs where the length of the 1537 dotted decimal (see [LDAP], section 4.1.2) string representation can 1538 be up to 100 bytes (inclusive). Implementations MUST be able to 1539 handle OIDs with up to 20 elements (inclusive). AA's SHOULD NOT 1540 issue ACs which contain OIDs that breach these requirements. 1542 The following OIDs are imported from [PKIXPROF]: 1544 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1545 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 1546 id-mod OBJECT IDENTIFIER ::= { id-pkix 0 } 1547 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 1548 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 1549 id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } 1550 id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 } 1552 The following new ASN.1 module OID is defined: 1554 id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 } 1556 The following AC extension OIDs are defined: 1558 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1559 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 7 } 1560 id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 1562 The following PKC extension OIDs are defined: 1564 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1566 The following attribute OIDs are defined: 1568 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1569 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1570 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1571 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1572 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1573 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1574 id-at-role OBJECT IDENTIFIER ::= { id-at 72 } 1575 id-at-clearance OBJECT IDENTIFIER ::= 1576 { joint-iso-ccitt(2) ds(5) module(1) 1577 selected-attribute-types(5) clearance (55) } 1579 Appendix B: ASN.1 Module 1581 PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) 1582 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1583 id-mod-attribute-cert(12)} 1585 DEFINITIONS EXPLICIT TAGS ::= 1587 BEGIN 1589 -- EXPORTS ALL -- 1591 IMPORTS 1593 -- PKIX Certificate Extensions 1594 Attribute, AlgorithmIdentifier, CertificateSerialNumber, 1595 Extensions, UniqueIdentifier, 1596 id-pkix, id-pe, id-kp, id-ad, id-at 1597 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 1598 dod(6) internet(1) security(5) mechanisms(5) 1599 pkix(7) id-mod(0) id-pkix1-explicit-88(1)} 1601 GeneralName, GeneralNames, id-ce 1602 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 1603 dod(6) internet(1) security(5) mechanisms(5) 1604 pkix(7) id-mod(0) id-pkix1-implicit-88(2)} ; 1606 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1607 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1608 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 7 } 1609 id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 1611 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1613 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1614 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1615 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1616 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1617 -- { id-aca 5 } is reserved 1618 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1620 id-at-role OBJECT IDENTIFIER ::= { id-at 72} 1621 id-at-clearance OBJECT IDENTIFIER ::= 1622 { joint-iso-ccitt(2) ds(5) module(1) 1623 selected-attribute-types(5) clearance (55) } 1625 -- Uncomment this if using a 1988 level ASN.1 compiler 1626 -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 1628 AttributeCertificate ::= SEQUENCE { 1629 acinfo AttributeCertificateInfo, 1630 signatureAlgorithm AlgorithmIdentifier, 1631 signatureValue BIT STRING 1632 } 1634 AttributeCertificateInfo ::= SEQUENCE { 1635 version AttCertVersion DEFAULT v1, 1636 holder Holder, 1637 issuer AttCertIssuer, 1638 signature AlgorithmIdentifier, 1639 serialNumber CertificateSerialNumber, 1640 attrCertValidityPeriod AttCertValidityPeriod, 1641 attributes SEQUENCE OF Attribute, 1642 issuerUniqueID UniqueIdentifier OPTIONAL, 1643 extensions Extensions OPTIONAL 1644 } 1646 AttCertVersion ::= INTEGER {v1(0), v2(1) } 1648 Holder ::= SEQUENCE { 1649 baseCertificateID [0] IssuerSerial OPTIONAL, 1650 -- the issuer and serial number of 1651 -- the holder's Public Key Certificate 1652 entityName [1] GeneralNames OPTIONAL, 1653 -- the name of the claimant or role 1654 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 1655 -- if present, version must be v2 1656 } 1658 ObjectDigestInfo ::= SEQUENCE { 1659 digestedObjectType ENUMERATED { 1660 publicKey (0), 1661 publicKeyCert (1), 1662 otherObjectTypes (2) }, 1663 -- otherObjectTypes MUST NOT 1664 -- MUST NOT be used in this profile 1665 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 1666 digestAlgorithm AlgorithmIdentifier, 1667 objectDigest BIT STRING 1668 } 1670 AttCertIssuer ::= CHOICE { 1671 v1Form GeneralNames, -- v1 or v2 1672 v2Form [0] V2Form -- v2 only 1673 } 1675 V2Form ::= SEQUENCE { 1676 issuerName GeneralNames OPTIONAL, 1677 baseCertificateID [0] IssuerSerial OPTIONAL, 1678 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 1679 -- at least one of issuerName, baseCertificateID 1680 -- or objectDigestInfo must be present 1681 } 1683 IssuerSerial ::= SEQUENCE { 1684 issuer GeneralNames, 1685 serial CertificateSerialNumber, 1686 issuerUID UniqueIdentifier OPTIONAL 1687 } 1689 AttCertValidityPeriod ::= SEQUENCE { 1690 notBeforeTime GeneralizedTime, 1691 notAfterTime GeneralizedTime 1692 } 1694 Targets ::= SEQUENCE OF Target 1696 Target ::= CHOICE { 1697 targetName [0] GeneralName, 1698 targetGroup [1] GeneralName, 1699 targetCert [2] TargetCert 1700 } 1702 TargetCert ::= SEQUENCE { 1703 targetCertificate IssuerSerial, 1704 targetName GeneralName OPTIONAL, 1705 certDigestInfo ObjectDigestInfo OPTIONAL 1706 } 1708 IetfAttrSyntax ::= SEQUENCE { 1709 policyAuthority[0] GeneralNames OPTIONAL, 1710 values SEQUENCE OF CHOICE { 1711 octets OCTET STRING, 1712 oid OBJECT IDENTIFIER, 1713 string UTF8String 1714 } 1715 } 1717 SvceAuthInfo ::= SEQUENCE { 1718 service GeneralName, 1719 ident GeneralName, 1720 authInfo OCTET STRING OPTIONAL 1721 } 1723 RoleSyntax ::= SEQUENCE { 1724 roleAuthority [0] GeneralNames OPTIONAL, 1725 roleName [1] GeneralName 1726 } 1728 Clearance ::= SEQUENCE { 1729 policyId OBJECT IDENTIFIER, 1730 classList ClassList DEFAULT {unclassified}, 1731 securityCategories 1732 SET OF SecurityCategory OPTIONAL 1733 } 1735 ClassList ::= BIT STRING { 1736 unmarked (0), 1737 unclassified (1), 1738 restricted (2), 1739 confidential (3), 1740 secret (4), 1741 topSecret (5) 1742 } 1744 SecurityCategory ::= SEQUENCE { 1745 type [0] IMPLICIT OBJECT IDENTIFIER, 1746 value [1] ANY DEFINED BY type 1747 } 1749 AAControls ::= SEQUENCE { 1750 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1751 permittedAttrs [0] AttrSpec OPTIONAL, 1752 excludedAttrs [1] AttrSpec OPTIONAL, 1753 permitUnSpecified BOOLEAN DEFAULT TRUE 1754 } 1756 AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER 1758 ACClearAttrs ::= SEQUENCE { 1759 acIssuer GeneralName, 1760 acSerial INTEGER, 1761 attrs SEQUENCE OF Attribute 1762 } 1764 ProxyInfo ::= SEQUENCE OF Targets 1766 END 1768 Appendix C: Change History 1770 <> 1772 This appendix lists major changes since the previous revision. 1774 Major changes since last revision: 1776 Changes from -02 to -03 1778 1. Many minor editorial changes 1779 2. Changed OID max element arc text in app. A 1780 3. Removed restriction on Clearance SecurityValue syntaxes to allow 1781 support for various existing clearance schemes 1782 4. Finalized alignment with 4th edition of X.509 1784 Changes from -01 to -02 1786 1. Re-Synchronized with X.509 DAM 1787 2. Deleted AC chains concept 1788 3. Moved AAControls to "optional features" section 1789 4. Samples will be a separate draft 1790 5. Revocation: now using X.509 DAM (noRevAvail) and standard 2459 1791 mechanisms only 1792 6. Deleted the special wildcard target "ALL" 1794 Changes from -00 to -01 1796 1. Re-structured conformance to profile + options as per Oslo 1797 consensus 1798 2. Moved acquisition protocol (LAAP)_to separate I-D 1799 3. Removed restrictions entirely 1800 4. Added new AC revocation options 1801 5. Added optional support for use of objectDigestInfo for keys 1802 6. Added optional support for chains of ACs 1803 7. Changed some syntax: 1804 Added UTF8String to IetfAttrSyntax value choice 1805 Split target & proxy extensions, removed owner from proxyInfo 1806 8. Allocated PKIX OIDs (note: check with repository before using 1807 these, the PKIX arc is currently available at 1808 http://www.imc.org/ietf-pkix/pkix-oid.asn) 1809 9. Added compiled ASN.1 module