idnits 2.17.00 (12 Aug 2021) /tmp/idnits28795/draft-ietf-pkix-ac509prof-04.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 272 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 (14 July 2000) is 7980 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 1764 -- Looks like a reference, but probably isn't: '1' on line 1765 -- Looks like a reference, but probably isn't: '2' on line 1712 == Missing Reference: 'UNIVERSAL 12' is mentioned on line 1639, but not defined == Unused Reference: 'CMC' is defined on line 1445, but no explicit reference was found in the text == Unused Reference: 'CMP' is defined on line 1447, but no explicit reference was found in the text == Unused Reference: 'ESS' is defined on line 1451, 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) == 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 (~~), 9 warnings (==), 6 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 14 July 2000 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...............................................1 50 1. Introduction.................................................3 51 1.1 Delegation and AC chains...............................4 52 1.2 Attribute Certificate Distribution ("push" vs. "pull").4 53 1.3 Document Structure.....................................5 54 2. Terminology..................................................6 55 3. Requirements.................................................7 56 4. Attribute Certificate Profile................................8 57 4.1 X.509 Attribute Certificate Definition.................8 58 4.2 Profile of Standard Fields............................10 59 4.2.1 Version.........................................10 60 4.2.2 Holder..........................................10 61 4.2.3 Issuer..........................................11 62 4.2.4 Signature.......................................12 63 4.2.5 Serial Number...................................12 64 4.2.6 Validity Period.................................12 65 4.2.7 Attributes......................................13 66 4.2.8 Issuer Unique Identifier........................13 67 4.2.9 Extensions......................................13 68 4.3 Extensions............................................14 69 4.3.1 Audit Identity..................................14 70 4.3.2 AC Targeting....................................15 71 4.3.3 Authority Key Identifier........................16 72 4.3.4 Authority Information Access....................16 73 4.3.5 CRL Distribution Points.........................17 74 4.3.6 No Revocation Available.........................17 75 4.4 Attribute Types.......................................17 76 4.4.1 Service Authentication Information..............18 77 4.4.2 Access Identity.................................18 78 4.4.3 Charging Identity...............................19 79 4.4.4 Group...........................................19 80 4.4.5 Role............................................19 81 4.4.6 Clearance.......................................20 82 4.5 Profile of AC issuer's PKC............................21 83 5. Attribute Certificate Validation............................22 84 6. Revocation..................................................23 85 7. Optional Features...........................................24 86 7.1 Attribute Encryption..................................24 87 7.2 Proxying..............................................25 88 7.3 Use of ObjectDigestInfo...............................26 89 7.4 AA Controls...........................................27 90 8. Security Considerations.....................................29 91 9. 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-97, 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 The remainder of the document is structured as follows: 248 Section 2 defines some terminology; Section 3 specifies the 249 requirements that this profile is to meet; Section 4 contains the 250 profile of the X.509 AC; Section 5 specifies rules for AC 251 validation; Section 6 specifies rules for AC revocation checks; 252 Section 7 specifies optional features which MAY be supported but for 253 which support is not required for conformance to this profile; and 254 Appendices contain the list of OIDs required to support this 255 specification and a ASN.1 module. 257 2. Terminology 259 For simplicity, we use the terms client and server in this 260 specification. This is not intended to indicate that ACs are only to 261 be used in client-server environments. For example, ACs may be used 262 in the S/MIME v3 context, where the mail user agent would be both a 263 "client" and a "server" in the sense the terms are used here. 265 Term Meaning 267 AA Attribute Authority, the entity that issues the 268 AC, synonymous in this specification with "AC 269 issuer" 270 AC Attribute Certificate 271 AC user any entity that parses or processes an AC 272 AC verifier any entity that checks the validity of an AC and 273 then makes use of the result 274 AC issuer the entity which signs the AC, synonymous in this 275 specification with "AA" 276 AC holder the entity indicated (perhaps indirectly) in the 277 holder field of the AC 278 Client the entity which is requesting the action for 279 which authorization checks are to be made 280 Proxying In this specification, Proxying is used to mean 281 the situation where an application server acts as 282 an application client on behalf of a user. 283 Proxying here does not mean granting of authority. 284 PKC Public Key Certificate - uses the type ASN.1 285 Certificate defined in X.509 and profiled in RFC 286 2459. This (non-standard) acronym is used in order 287 to avoid confusion about the term "X.509 288 certificate". 289 Server the entity which requires that the authorization 290 checks are made 292 3. Requirements 294 This AC profile meets the following requirements. 296 Time/Validity requirements: 298 1. Support for short-lived as well as long-lived ACs is required. 299 Typical short-lived validity periods might be measured in 300 hours, as opposed to months for PKCs. Short validity periods 301 allow ACs to be useful without a revocation mechanism. 303 Attribute Types: 305 2. Issuers of ACs should be able to define their own attribute 306 types for use within closed domains. 307 3. Some standard attribute types should be defined which can be 308 contained within ACs. Examples include "access identity", 309 "group", "role", "clearance", "audit identity", and "charging 310 id". 311 4. Standard attribute types should be defined in a manner that 312 permits an AC verifier to distinguish between uses of the same 313 attribute in different domains. For example, the 314 "Administrators group" as defined by Baltimore and the 315 "Administrators group" as defined by SPYRUS should be easily 316 distinguished. 318 Targeting of ACs: 320 5. It should be possible to "target" an AC at one, or a small 321 number of, servers. This means that a trustworthy non-target 322 server will reject the AC for authorization decisions. 324 Push vs. Pull 326 6. ACs should be defined so that they can either be "pushed" by 327 the client to the server, or "pulled" by the server from a 328 repository or other network service, including an online AC 329 issuer. 331 4. Attribute Certificate Profile 333 ACs may be used in a wide range of applications and environments 334 covering a broad spectrum of interoperability goals and a broader 335 spectrum of operational and assurance requirements. The goal of 336 this document is to establish a common baseline for generic 337 applications requiring broad interoperability and limited special 338 purpose requirements. In particular, the emphasis will be on 339 supporting the use of attribute certificates for informal Internet 340 electronic mail, IPSec, and WWW applications. 342 This section presents a profile for ACs that will foster 343 interoperability. This section also defines some private extensions 344 for the Internet community. 346 While the ISO/IEC/ITU documents use the 1993 (or later) version of 347 ASN.1; this document uses the 1988 ASN.1 syntax, as has been done 348 for PKCs [PKIXPROF]. The encoded certificates and extensions from 349 either ASN.1 version are bit-wise identical. 351 Where maximum lengths for fields are specified, these lengths refer 352 to the DER encoding and do not include the ASN.1 tag or length 353 fields. 355 Conforming implementations MUST support the profile specified in 356 this section. 358 4.1 X.509 Attribute Certificate Definition 360 X.509 contains the definition of an AC given below. All types that 361 are not defined in this document can be found in [PKIXPROF]. 363 AttributeCertificate ::= SEQUENCE { 364 acinfo AttributeCertificateInfo, 365 signatureAlgorithm AlgorithmIdentifier, 366 signatureValue BIT STRING 367 } 369 AttributeCertificateInfo ::= SEQUENCE { 370 version AttCertVersion DEFAULT v1, 371 holder Holder, 372 issuer AttCertIssuer, 373 signature AlgorithmIdentifier, 374 serialNumber CertificateSerialNumber, 375 attrCertValidityPeriod AttCertValidityPeriod, 376 attributes SEQUENCE OF Attribute, 377 issuerUniqueID UniqueIdentifier OPTIONAL, 378 extensions Extensions OPTIONAL 379 } 381 AttCertVersion ::= INTEGER { v1(0), v2(1) } 382 Holder ::= SEQUENCE { 383 baseCertificateID [0] IssuerSerial OPTIONAL, 384 -- the issuer and serial number of 385 -- the holder's Public Key Certificate 386 entityName [1] GeneralNames OPTIONAL, 387 -- the name of the claimant or role 388 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 389 -- if present, version must be v2 390 } 392 ObjectDigestInfo ::= SEQUENCE { 393 digestedObjectType ENUMERATED { 394 publicKey (0), 395 publicKeyCert (1), 396 otherObjectTypes (2) }, 397 -- otherObjectTypes MUST NOT 398 -- be used in this profile 399 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 400 digestAlgorithm AlgorithmIdentifier, 401 objectDigest BIT STRING 402 } 404 AttCertIssuer ::= CHOICE { 405 v1Form GeneralNames, -- v1 or v2 406 v2Form [0] V2Form -- v2 only 407 } 409 V2Form ::= SEQUENCE { 410 issuerName GeneralNames OPTIONAL, 411 baseCertificateID [0] IssuerSerial OPTIONAL, 412 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 413 -- at least one of issuerName, baseCertificateID 414 -- or objectDigestInfo MUST be present 415 } 417 IssuerSerial ::= SEQUENCE { 418 issuer GeneralNames, 419 serial CertificateSerialNumber, 420 issuerUID UniqueIdentifier OPTIONAL 421 } 423 AttCertValidityPeriod ::= SEQUENCE { 424 notBeforeTime GeneralizedTime, 425 notAfterTime GeneralizedTime 426 } 428 Although the Attribute syntax is defined in [PKIXPROF], we repeat 429 the definition here for convenience. 431 Attribute ::= SEQUENCE { 432 type AttributeType, 433 values SET OF AttributeValue 434 -- at least one value is required 435 } 437 AttributeType ::= OBJECT IDENTIFIER 439 AttributeValue ::= ANY DEFINED BY AttributeType 441 Implementers should note that the DER encoding (see [X.509- 442 88],[X.208-88]) of the SET OF values requires ordering of the 443 encodings of the values. Though this issue arises with respect to 444 distinguished names, and has to be handled by [PKIXPROF] 445 implementations, its is much more significant in this context, since 446 the inclusion of multiple values is much more common in ACs. 448 4.2 Profile of Standard Fields 450 For all GeneralName fields in this profile the otherName (except as 451 noted below), x400Address, ediPartyName and registeredID options 452 MUST NOT be used. The use of Kerberos [KRB] principal names, 453 encoded into the otherName, SHOULD however, be supported using the 454 krb5PrincipalName OID and the KerberosName syntax as defined in 455 [PKINIT]. 457 Conforming implementations MUST be able to support the dNSName, 458 directoryName, uniformResourceIdentifier, and iPAddress fields in 459 all cases where GeneralName is used. This is compatible with the 460 GeneralName requirements in [PKIXPROF] (mainly in section 4.2.1.7). 462 4.2.1 Version 464 The version field MUST be the default value of v1. That is, the 465 version field is not present in the DER encoding, except when the 466 holder is identified using the optional objectDigestInfo field, as 467 specified in section 7.3. 469 4.2.2 Holder 471 For any environment where the AC is passed in an authenticated 472 message or session and where the authentication is based on the use 473 of an X.509 PKC, the holder field SHOULD use the baseCertificateID. 475 With the baseCertificateID option, the holder's PKC serialNumber and 476 issuer MUST be identical to the AC holder field. The PKC issuer MUST 477 have a non-empty distinguished name which is to be present as the 478 single value of the holder.baseCertificateID.issuer construct in the 479 directoryName field. The AC holder.baseCertificateID.issuerUID field 480 MUST only be used if the holder's PKC contains an issuerUniqueID 481 field. If both the AC holder.baseCertificateID.issuerUID and the PKC 482 issuerUniqueID fields are present, then the same value MUST be 483 present in both fields. Thus, the baseCertificateID is only usable 484 with PKC profiles (like [PKIXPROF]) which mandate that the PKC 485 issuer field contain a non-empty distinguished name value. 487 Note: An empty distinguished name is a distinguished name where the 488 SEQUENCE OF relative distinguished names is of zero length. In a DER 489 encoding this has the value '3000'H. 491 If the holder field uses the entityName option and the underlying 492 authentication is based on a PKC, then the entityName MUST be the 493 same as the PKC subject field, unless the PKC subject field contains 494 an empty distinguished name. If the PKC subject field contains an 495 empty distinguished name, then the entityName field MUST be 496 identical to one of the values of the PKC subjectAltName field 497 extension. Note that [PKIXPROF] mandates that the subjectAltNames 498 extension be present if the PKC subject is an empty distinguished 499 name. See the security consideration section which mentions some 500 name collision problems that may arise when using the entityName 501 option. 503 In any other case where the holder field uses the entityName option, 504 then only one name SHOULD be present. 506 Implementations conforming to this profile are not required to 507 support the use of the objectDigest field. However, section 7.3 508 specifies how this optional feature MAY be used. 510 Any protocol conforming to this profile SHOULD specify which AC 511 holder option is to be used and how this fits with the supported 512 authentication schemes defined in that protocol. 514 4.2.3 Issuer 516 ACs conforming to this profile MUST use the v1Form choice, which 517 MUST contain one and only one GeneralName, which MUST contain a non- 518 empty distinguished name in the directoryName field. This means that 519 all AC issuers MUST have non-empty distinguished names. 521 Part of the reason for the use of the v1Form field is that it means 522 that the AC issuer does not have to know which PKC the AC verifier 523 will use for it (the AC issuer). Using the baseCertificateID field 524 to reference the AC issuer would mean that the AC verifier would 525 have to trust the PKC that the AC issuer chose (for itself) at AC 526 creation time. 528 4.2.4 Signature 530 Contains the algorithm identifier used to validate the AC signature. 532 This MUST be one of the following algorithms defined in [PKIXPROF] 533 section 7.2: md5WithRSAEncryption, id-dsa-with-sha1 or sha- 534 1WithRSAEncryption.. 536 id-dsa-with-sha1 MUST be supported by all AC users. The other 537 algorithms SHOULD be supported. 539 4.2.5 Serial Number 541 For any conforming AC, the issuer/serialNumber pair MUST form a 542 unique combination, even if ACs are very short-lived. 544 AC issuers MUST force the serialNumber to be a positive integer, 545 that is, the sign bit in the DER encoding of the INTEGER value MUST 546 be zero - this can be done by adding a leading (leftmost) '00'H 547 octet if necessary. This removes a potential ambiguity in mapping 548 between a string of octets and an integer value. 550 Given the uniqueness and timing requirements above serial numbers 551 can be expected to contain long integers. AC users MUST be able to 552 handle serialNumber values longer than 4 octets. Conformant ACs MUST 553 NOT contain serialNumber values longer than 20 octets. 555 There is no requirement that the serial numbers used by any AC 556 issuer follow any particular ordering, in particular, they need not 557 be monotonically increasing with time. Each AC issuer MUST ensure 558 that each AC that it issues contain a unique serial number. 560 4.2.6 Validity Period 562 The attrCertValidityPeriod (a.k.a. validity) field specifies the 563 period for which the AC issuer certifies that the binding between 564 the holder and the attributes fields will be valid. 566 The generalized time type, GeneralizedTime, is a standard ASN.1 type 567 for variable precision representation of time. The GeneralizedTime 568 field can optionally include a representation of the time 569 differential between the local time zone and Greenwich Mean Time. 571 For the purposes of this profile, GeneralizedTime values MUST be 572 expressed in Coordinated universal time (UTC) (also known as 573 Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times 574 are YYYYMMDDHHMMSSZ), even when the number of seconds is zero. 575 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 parts of its validity period or all its validity 581 period in the past or in the future (a post-dated AC). This is valid 582 for some applications, such as backup. 584 4.2.7 Attributes 586 The attributes field gives information about the AC holder. When the 587 AC is used for authorization this will often contain a set of 588 privileges. 590 The attributes field contains a SEQUENCE OF Attribute. Each 591 Attribute MAY contain a SET OF values. For a given AC, each 592 AttributeType OBJECT IDENTIFIER in the sequence MUST be unique. That 593 is, only one instance of each attribute can occur in a single AC, 594 but each instance can be multi-valued. 596 AC users MUST be able to handle multiple values for all attribute 597 types. 599 An AC MUST contain at least one attribute. That is, the SEQUENCE OF 600 Attributes MUST NOT be of zero length. 602 Some standard attribute types are defined in section 4.5. 604 4.2.8 Issuer Unique Identifier 606 This field MUST NOT be used unless it is also used in the AC 607 issuer's PKC, in which case it MUST be used. Note that [PKIXPROF] 608 states that this field SHOULD NOT be used by conforming CAs, but 609 that applications SHOULD be able to parse PKCs containing the field. 611 4.2.9 Extensions 613 The extensions field generally gives information about the AC as 614 opposed to information about the AC holder. 616 An AC that has no extensions conforms to the profile; however, 617 section 4.3 defines the extensions that MAY be used with this 618 profile, and whether or not they may be marked criticial. If any 619 other critical extension is used, then the AC does not conform to 620 this profile. However, if any other non-critical extension is used, 621 then the AC does conform to this profile. 623 The extensions defined for ACs provide methods for associating 624 additional attributes with holders. This profile also allows 625 communities to define private extensions to carry information unique 626 to those communities. Each extension in an AC may be designated as 627 critical or non-critical. An AC using system MUST reject an AC if 628 it encounters a critical extension it does not recognize; however, a 629 non-critical extension may be ignored if it is not recognized. 630 Section 4.3 presents recommended extensions used within Internet ACs 631 and standard locations for information. Communities may elect to 632 use additional extensions; however, caution should be exercised in 633 adopting any critical extensions in ACs, which might prevent use in 634 a general context. 636 4.3 Extensions 638 4.3.1 Audit Identity 640 In some circumstances it is required (e.g. by data protection/data 641 privacy legislation) that audit trails do not contain records which 642 directly identify individuals. This circumstance may make the use of 643 the AC holder field unsuitable for use in audit trails. 645 To allow for such cases, an AC MAY contain an audit identity 646 extension. Ideally it SHOULD be infeasible to derive the AC holder's 647 identity from the audit identity value without the co-operation of 648 the AC issuer. 650 The value of the audit identity along with the AC issuer/serial 651 SHOULD then be used for audit/logging purposes. If the value of the 652 audit identity is suitably chosen, then a server/service 653 administrator can use audit trails to track the behavior of an AC 654 holder without being able to identify the AC holder. 656 The server/service administrator in combination with the AC issuer 657 MUST be able to identify the AC holder in cases where misbehavior is 658 detected. This means that the AC issuer MUST be able to determine 659 the actual identity of the AC holder from the audit identity. 661 Of course, auditing could be based on the AC issuer/serial pair; 662 however, this method doesn't allow tracking the same AC holder with 663 multiple ACs. Thus, an audit identity is only useful if it lasts for 664 longer than the typical AC lifetime. Auditing could also be based on 665 the AC holder's PKC issuer/serial; however, this will often allow 666 the server/service administrator to identify the AC holder. 668 As the AC verifier might otherwise use the AC holder or some other 669 identifying value for audit purposes, this extension MUST be 670 critical when used. 672 Protocols that use ACs will often expose the identity of the AC 673 holder in the bits on-the-wire. In such cases, an opaque audit 674 identity does not make use of the AC anonymous, it simply ensures 675 that the ensuing audit trails do not contain identifying 676 information. 678 The value of an audit identity MUST be longer than zero octets. The 679 value of an audit identity MUST NOT be longer than 20 octets. 681 name id-pe-ac-auditIdentity 682 OID { id-pe 4 } 683 syntax OCTET STRING 684 criticality MUST be TRUE 686 4.3.2 AC Targeting 688 To target an AC , the target information extension, imported from 689 [X.509-2000], MAY be used to specify a number of servers/services. 690 The intent is that the AC SHOULD only be usable at the specified 691 servers/services. An (honest) AC verifier who is not amongst the 692 named servers/services MUST reject the AC. 694 If this extension is not present, then the AC is not targeted and 695 may be accepted by any server. 697 In this profile, the targeting information simply consists of a list 698 of named targets or groups. 700 The following syntax is used to represent the targeting information: 702 Targets ::= SEQUENCE OF Target 704 Target ::= CHOICE { 705 targetName [0] GeneralName, 706 targetGroup [1] GeneralName, 707 targetCert [2] TargetCert 708 } 710 TargetCert ::= SEQUENCE { 711 targetCertificate IssuerSerial, 712 targetName GeneralName OPTIONAL, 713 certDigestInfo ObjectDigestInfo OPTIONAL 714 } 716 The targetCert CHOICE within the Target structure is only present to 717 allow future compatibility with [X.509-2000] and MUST NOT be used. 719 The targets check passes if the current server (recipient) is one of 720 the targetName fields in the Targets SEQUENCE, or if the current 721 server is a member of one of the targetGroup fields in the Targets 722 SEQUENCE. In this case, the current server is said to "match" the 723 targeting extension. 725 How the membership of a target within a targetGroup is determined is 726 not defined here. It is assumed that any given target "knows" the 727 names of the targetGroups to which it belongs or can otherwise 728 determine its membership. For example, the targetGroup specifies a 729 DNS domain, and the AC verifier knows the DNS domain to which it 730 belongs. For another example, the targetGroup specifies "PRINTERS," 731 and the AC verifier knows whether or not it is a printer or print 732 server. 734 Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF 735 Targets". Conforming AC issuer implementations MUST only produce one 736 "Targets" element. Confirming AC users MUST be able to accept a 737 "SEQUENCE OF Targets". If more than one Targets element is found in 738 an AC, then the extension MUST be treated as if all Target elements 739 had been found within one Targets element. 741 name id-ce-targetInformation 742 OID { id-ce 55 } 743 syntax SEQUENCE OF Targets 744 criticality MUST be TRUE 746 4.3.3 Authority Key Identifier 748 The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY 749 be used to assist the AC verifier in checking the signature of the 750 AC. The [PKIXPROF] description should be read as if "CA" meant "AC 751 issuer." As with PKCs this extension SHOULD be included in ACs. 753 Note: An AC where the issuer field used the baseCertificateID CHOICE 754 would not need an authorityKeyIdentifier extension as it is 755 explicitly linked to the key in the referred certificate. However, 756 as this profile states (in section 4.2.3) that ACs MUST use the 757 v1Form CHOICE, this duplication does not arise. 759 name id-ce-authorityKeyIdentifier 760 OID { id-ce 35 } 761 syntax AuthorityKeyIdentifier 762 criticality MUST be FALSE 764 4.3.4 Authority Information Access 766 The authorityInformationAccess extension, as defined in [PKIXPROF], 767 MAY be used to assist the AC verifier in checking the revocation 768 status of the AC. Support for the id-ad-caIssuers accessMethod is 769 NOT REQUIRED by this profile since AC chains are not expected. 771 The following accessMethod is used to indicate that revocation 772 status checking is provided for this AC, using the OCSP protocol 773 defined in [OCSP]: 775 id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } 777 The accessLocation MUST contain a URI, and theURI MUST contain an 778 HTTP URL [URL] that specifies the location of an OCSP responder. The 779 AC issuer MUST, of course, maintain an OCSP responder at this 780 location. 782 name id-ce-authorityInfoAccess 783 OID { id-pe 1 } 784 syntax AuthorityInfoAccessSyntax 785 criticality MUST be FALSE 787 4.3.5 CRL Distribution Points 789 The crlDistributionPoints extension, as profiled in [PKIXPROF], MAY 790 be used to assist the AC verifier in checking the revocation status 791 of the AC. See section 6 for details on revocation. 793 If the crlDistributionPoints extension is present, then exactly one 794 distribution point MUST be present. The crlDistributionPoints 795 extension MUST use the DistributionPointName option, which MUST 796 contain a fullName, which MUST contain a single name form. That name 797 MUST contain either a distinguished name or a URI. The URI MUST be 798 either an HTTP URL or an LDAP URL [URL]. 800 name id-ce-cRLDistributionPoints 801 OID { id-ce 31 } 802 syntax CRLDistPointsSyntax 803 criticality MUST be FALSE 805 4.3.6 No Revocation Available 807 The noRevAvail extension, defined in [X.509-2000], allows an AC 808 issuer to indicate that no revocation information will be made 809 available for this AC. 811 This extension MUST be non-critical. An AC verifier that does not 812 understand this extension might be able to find a revocation list 813 from the AC issuer, but the revocation list will never include an 814 entry for the AC. 816 name id-ce-noRevAvail 817 OID { id-ce 56 } 818 syntax NULL (i.e. '0500'H is the DER encoding) 819 criticality MUST be FALSE 821 4.4 Attribute Types 823 Some of the attribute types defined below make use of the 824 IetfAttrSyntax type, also defined below. The reasons for using this 825 type are: 827 1. It allows a separation between the AC issuer and the attribute 828 policy authority. This is useful for situations where a single 829 policy authority (e.g. an organization) allocates attribute 830 values, but where multiple AC issuers are deployed for 831 performance or other reasons. 832 2. The syntaxes allowed for values are restricted to OCTET STRING, 833 OBJECT IDENTIFIER, and UTF8String, which significantly reduces 834 the complexity associated with matching more general syntaxes. 835 All multi-valued attributes using this syntax are restricted so 836 that each value MUST use the same choice of value syntax. For 837 example, AC issuers must not use one value with an oid and a 838 second value with a string. 840 IetfAttrSyntax ::= SEQUENCE { 841 policyAuthority [0] GeneralNames OPTIONAL, 842 values SEQUENCE OF CHOICE { 843 octets OCTET STRING, 844 oid OBJECT IDENTIFIER, 845 string UTF8String 846 } 847 } 849 In the descriptions below, each attribute type is tagged as either 850 "Multiple Allowed" or "One Attribute value only; multiple values 851 within the IetfAttrSyntax". This refers to the SET OF 852 AttributeValue, the AttributeType still only occurs once, as 853 specified in section 4.2.7. 855 4.4.1 Service Authentication Information 857 The SvceAuthInfo attribute identifies the AC holder to the 858 server/service by a name, and the attribute MAY include optional 859 service specific authentication information. Typically this will 860 contain a username/password pair for a "legacy" application. 862 This attribute is intended to be used to provide information that 863 can be presented by the AC verifier to be interpreted and 864 authenticated by a separate application within the target system. 865 Note that this is a different use to that intended for the 866 accessIdentity attribute in 4.4.2 below. 868 This attribute type will typically be encrypted when the authInfo 869 field contains sensitive information, such as a password. 871 name id-aca-authenticationInfo 872 OID { id-aca 1 } 873 Syntax SvceAuthInfo 874 values: Multiple allowed 876 SvceAuthInfo ::= SEQUENCE { 877 service GeneralName, 878 ident GeneralName, 879 authInfo OCTET STRING OPTIONAL 880 } 882 4.4.2 Access Identity 884 The accessIdentity attribute identifies the AC holder to the 885 server/service. For this attribute the authInfo field MUST NOT be 886 present. 888 This attribute is intended to be used to provide information about 889 the AC holder, that can be used by the AC verifier (or a larger 890 system of which the AC verifier is a component) to authorize the 891 actions of the AC holder within the AC verifier's system. Note that 892 this is a different use to that intended for the svceAuthInfo 893 attribute described in 4.4.1 above. 895 name id-aca-accessIdentity 896 OID { id-aca 2 } 897 syntax SvceAuthInfo 898 values: Multiple allowed 900 4.4.3 Charging Identity 902 The chargingIdentity attribute identifies the AC holder for charging 903 purposes. In general, the charging identity will be different from 904 other identities of the holder. For example, the holder's company 905 may be charged for service. 907 name id-aca-chargingIdentity 908 OID { id-aca 3 } 909 syntax IetfAttrSyntax 910 values: One Attribute value only; multiple values within the 911 IetfAttrSyntax 913 4.4.4 Group 915 The group attribute carries information about group memberships of 916 the AC holder. 918 name id-aca-group 919 OID { id-aca 4 } 920 syntax IetfAttrSyntax 921 values: One Attribute value only; multiple values within the 922 IetfAttrSyntax 924 4.4.5 Role 926 The role attribute, specified in [X.509-2000], carries information 927 about role allocations of the AC holder. 929 The syntax used for this attribute is: 931 RoleSyntax ::= SEQUENCE { 932 roleAuthority [0] GeneralNames OPTIONAL, 933 roleName [1] GeneralName 934 } 936 The roleAuthority field MAY be used to specify the issuing authority 937 for the role specification certificate. There is no requirement that 938 a role specification certificate necessarily exists for the 939 roleAuthority. This differs from [X.500-2000], where the 940 roleAuthority field is assumed to name the issuer of a role 941 specification certificate. For example, to distinguish the 942 administrator role as defined by "Baltimore" from that defined by 943 "Spyrus", one could put the value "administrator" in the roleName 944 field and the value "Baltimore" or "Spyrus" in the roleAuthority 945 field. 947 The roleName field MUST be present, and roleName MUST use the 948 uniformResourceIdentifier CHOICE of the GeneralName. 950 name id-at-role 951 OID { id-at 72 } 952 syntax RoleSyntax 953 values: Multiple allowed 955 4.4.6 Clearance 957 The clearance attribute, specified in [X.501-93], carries clearance 958 (associated with security labeling) information about the AC holder. 960 The policyId field is used to identify the security policy to which 961 the clearance relates. The policyId indicates the semantics of the 962 classList and securityCategories fields. 964 This specification includes the classList field exactly as is 965 specified in [X.501-93]. Additional security classification values, 966 and their position in the classification hierarchy, may be defined 967 by a security policy as a local matter or by bilateral agreement. 968 The basic security classification hierarchy is, in ascending order: 969 unmarked, unclassified, restricted, confidential, secret, and top- 970 secret. 972 An organization can develop its own security policy that defines 973 security classification values and their meanings. However, the BIT 974 STRING positions 0 through 5 are reserved for the basic security 975 classification hierarchy. 977 If present, the SecurityCategory field provides further 978 authorization information. The security policy identified by the 979 policyId field indicates the syntaxes that are allowed to be present 980 in the securityCategories SET. An OBJECT IDENTIFIER identifies each 981 of the allowed syntaxes. When one of these syntaxes is present in 982 the securityCategories SET, the OBJECT IDENTIFIER associated with 983 that syntax is carried in the SecurityCategory.type field. 985 Clearance ::= SEQUENCE { 986 policyId OBJECT IDENTIFIER, 987 classList ClassList DEFAULT {unclassified}, 988 securityCategories 989 SET OF SecurityCategory OPTIONAL 990 } 992 ClassList ::= BIT STRING { 993 unmarked (0), 994 unclassified (1), 995 restricted (2) 996 confidential (3), 997 secret (4), 998 topSecret (5) 999 } 1001 SecurityCategory ::= SEQUENCE { 1002 type [0] IMPLICIT OBJECT IDENTIFIER, 1003 value [1] ANY DEFINED BY type 1004 } 1006 -- This is the same as the original syntax which was defined 1007 -- using the MACRO construct, as follows: 1008 -- SecurityCategory ::= SEQUENCE { 1009 -- type [0] IMPLICIT SECURITY-CATEGORY, 1010 -- value [1] ANY DEFINED BY type 1011 -- } 1012 -- 1013 -- SECURITY-CATEGORY MACRO ::= 1014 -- BEGIN 1015 -- TYPE NOTATION ::= type | empty 1016 -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 1017 -- END 1019 name { id-at-clearance } 1020 OID { joint-iso-ccitt(2) ds(5) module(1) 1021 selected-attribute-types(5) clearance (55) } 1022 syntax Clearance - imported from [X.501-93] 1023 values Multiple allowed 1025 4.5 Profile of AC issuer's PKC 1027 The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage 1028 extension in the PKC MUST NOT explicitly indicate that the AC 1029 issuer's public key cannot be used to validate a digital signature. 1030 In order to avoid confusion regarding serial numbers and 1031 revocations, an AC issuer MUST NOT also be a PKC Issuer. That is, 1032 an AC issuer cannot be a CA as well. So, the AC issuer's PKC MUST 1033 NOT have a basicConstraints extension with the cA BOOLEAN set to 1034 TRUE. 1036 5. Attribute Certificate Validation 1038 This section describes a basic set of rules that all valid ACs MUST 1039 satisfy. Some additional checks are also described which AC 1040 verifiers MAY choose to implement. 1042 To be valid an AC MUST satisfy all of the following: 1044 1. The AC signature must be cryptographically correct, and the AC 1045 issuer's entire PKC certification path MUST be verified in 1046 accordance with [PKIXPROF]. 1047 2. The AC issuer's PKC MUST also conform to the profile specified 1048 in section 4.5 above. 1049 3. The AC issuer MUST be directly trusted as an AC issuer (by 1050 configuration or otherwise). 1051 4. The time for which the AC is being evaluated MUST be within the 1052 AC validity. If the evaluation time is equal to either 1053 notBeforeTime or notAfterTime, then the AC is timely and this 1054 check succeeds. Note that in some applications, the evaluation 1055 time MAY not be the same as the current time. 1056 5. The AC targeting check MUST pass as specified in section 4.3.2. 1057 6. If the AC contains an unsupported critical extension, then the 1058 AC MUST be rejected. 1060 Support for an extension in this context means: 1062 1. The AC verifier MUST be able to parse the extension value. 1063 2. Where the extension value SHOULD cause the AC to be rejected, 1064 the AC verifier MUST reject the AC. 1066 Additional Checks: 1068 1. The AC MAY be rejected on the basis of further AC verifier 1069 configuration. For example, an AC verifier may be configured to 1070 reject ACs which contain or lack certain attributes. 1071 2. If the AC verifier provides an interface that allows 1072 applications to query the contents of the AC, then the AC 1073 verifier MAY filter the attributes from the AC on the basis of 1074 configured information. For example, an AC verifier might be 1075 configured not to return certain attributes to certain servers. 1077 6. Revocation 1079 In many environments, the validity period of an AC is less than the 1080 time required to issue and distribute revocation information. 1081 Therefore, short-lived ACs typically do not require revocation 1082 support. However, long-lived ACs and environments where ACs enable 1083 high value transactions MAY require revocation support. 1085 Two revocation schemes are defined, and the AC issuer should elect 1086 the one that is best suited to the environment in which the AC will 1087 be employed. 1089 "Never revoke" scheme: 1091 ACs may be marked so that the relying party understands that no 1092 revocation status information will be made available. The 1093 noRevAvail extension is defined in section 4.3.6, and the 1094 noRevAvail extension MUST be present in the AC to indicate use 1095 of this scheme. 1097 Where no noRevAvail is not present, then the AC issuer is 1098 implicitly stating that revocation status checks are supported, 1099 and some revocation method MUST be provided to allow AC 1100 verifiers to establish the revocation status of the AC. 1102 "Pointer in AC" scheme: 1104 ACs may "point" to sources of revocation status information, 1105 using either an authorityInfoAccess extension or a 1106 crlDistributionPoints extension within the AC. 1108 For AC users, the "never revoke" scheme MUST be supported, and the 1109 "pointer in AC" scheme SHOULD be supported. If only the "never 1110 revoke" scheme is supported, then all ACs that do not contain a 1111 noRevAvail extension, MUST be rejected. 1113 For AC issuers, the "never revoke" scheme MUST be supported. If all 1114 ACs that will ever be issued by that AC issuer, will contain a 1115 noRevAvail extension, then the "pointer in AC" scheme need not be 1116 supported. If any AC can be issued that does not contain the 1117 noRevAvail extension, then the "pointer in AC" scheme MUST be 1118 supported. 1120 An AC verifier MAY use any source for AC revocation status 1121 information. 1123 7. Optional Features 1125 This section specifies features that MAY be implemented. Conformance 1126 to this profile does NOT require support for these features; 1127 however, if these features are offered, they MUST be offered as 1128 described below. 1130 7.1 Attribute Encryption 1132 Where an AC will be carried in clear within an application protocol 1133 or where an AC contains some sensitive information like a legacy 1134 application username/password, then encryption of AC attributes MAY 1135 be needed. 1137 When a set of attributes are to be encrypted within an AC, the 1138 Cryptographic Message Syntax, EnvelopedData structure [CMS] is used 1139 to carry the ciphertext and associated per-recipient keying 1140 information. 1142 This type of attribute encryption is targeted. Before the AC is 1143 signed, the attributes are encrypted for a set of predetermined 1144 recipients. 1146 The AC then contains the ciphertext inside its signed data. The 1147 EenvelopedData (id-envelopedData) ContentType is used, and the 1148 content field will contain the EnvelopedData type. 1150 The ciphertext is included in the AC as the value of an encAttrs 1151 attribute. Only one encAttrs attribute can be present in an AC; 1152 however, the encAttrs attribute MAY be multi-valued, and each of its 1153 values will contain an independent EnvelopedData. 1155 Each value can contain a set of attributes (each possibly a multi- 1156 valued attribute) encrypted for a set of predetermined recipients. 1158 The cleartext that is encrypted has the type: 1160 ACClearAttrs ::= SEQUENCE { 1161 acIssuer GeneralName, 1162 acSerial INTEGER, 1163 attrs SEQUENCE OF Attribute 1164 } 1166 The DER encoding of the ACClearAttrs structure is used as the 1167 encryptedContent field of the EnvelopedData. The DER encoding MUST 1168 be embedded in an OCTET STRING. 1170 The acIssuer and acSerial fields are present to prevent ciphertext 1171 stealing. When an AC verifier has successfully decrypted an 1172 encrypted attribute it MUST then check that the AC issuer and 1173 serialNumber fields contain the same values. This prevents a 1174 malicious AC issuer from copying ciphertext from another AC (without 1175 knowing its corresponding plaintext). 1177 The procedure for an AC issuer when encrypting attributes is 1178 illustrated by the following (any other procedure that gives the 1179 same result MAY be used): 1181 1. Identify the sets of attributes that are to be encrypted for 1182 each set of recipients. 1183 2. For each attribute set which is to be encrypted: 1184 2.1. Create an EnvelopedData structure for the data for this 1185 set of recipients. 1186 2.2. Encode the ContentInfo containing the EnvelopedData as a 1187 value of the encAttrs attribute 1188 2.3. Ensure the cleartext attributes are not present in the 1189 to-be-signed AC 1190 3. Add the encAttrs (with its multiple values) to the AC 1192 Note that there may be more than one attribute of the same type (the 1193 same OBJECT IDENTIFIER) after decryption. That is, an AC MAY contain 1194 the same attribute type both in clear and in encrypted form (and 1195 indeed several times if the same recipient is associated with more 1196 than one EnvelopedData). One approach implementers may choose, would 1197 be to merge attributes values following decryption in order to re- 1198 establish the "once only" constraint. 1200 name id-aca-encAttrs 1201 OID { id-aca 6} 1202 Syntax ContentInfo 1203 values Multiple Allowed 1205 If an AC contains attributes apparently encrypted for the AC 1206 verifier, then the decryption process MUST not fail. If decryption 1207 does fail, then the AC MUST be rejected. 1209 7.2 Proxying 1211 When a server acts as a client for another server on behalf of the 1212 AC holder, the server MAY need to proxy an AC. Such proxying MAY 1213 have to be done under the AC issuer's control, so that not every AC 1214 is proxiable and so that a given proxiable AC can be proxied in a 1215 targeted fashion. Support for chains of proxies (with more than one 1216 intermediate server) MAY also be required. Note that this does not 1217 involve a chain of ACs. 1219 In order to meet this requirement we define another extension, 1220 ProxyInfo, similar to the targeting extension. 1222 When this extension is present the AC verifier must check that the 1223 entity from which the AC was received was allowed to send it and 1224 that the AC is allowed to be used by this verifier. 1226 The proxying information consists of a set of proxy information, 1227 each of which is a set of targeting information. If the verifier and 1228 the sender of the AC are both named in the same proxy set then the 1229 AC can be accepted (the exact rule is given below). 1231 The effect is that the AC holder can send the AC to any valid target 1232 which can then only proxy to targets which are in one of the same 1233 proxy sets as itself. 1235 The following data structure is used to represent the 1236 targeting/proxying information. 1238 ProxyInfo ::= SEQUENCE OF Targets 1240 As in the case of targeting, the targetCert CHOICE MUST NOT be used. 1242 A proxy check succeeds if either one of the conditions below is met: 1244 1. The identity of the sender as established by the underlying 1245 authentication service matches the holder field of the AC, and the 1246 current server "matches" any one of the proxy sets. Recall that 1247 "matches" is as defined section 4.3.2. 1249 2. The identity of the sender as established by the underlying 1250 authentication service "matches" one of the proxy sets (call it 1251 set "A"), and the current server is one of the targetName fields 1252 in the set "A", or the current server is a member of one of the 1253 targetGroup fields in set "A". 1255 When an AC is proxied more than once, a number of targets will be on 1256 the path from the original client, which is normally, but not 1257 always, the AC holder. In such cases, prevention of AC "stealing" 1258 requires that the AC verifier MUST check that all targets on the 1259 path are members of the same proxy set. It is the responsibility of 1260 the AC using protocol to ensure that a trustworthy list of targets 1261 on the path is available to the AC verifier. 1263 name id-pe-ac-proxying 1264 OID { id-pe 10 } 1265 syntax ProxyInfo 1266 criticality MUST be TRUE 1268 7.3 Use of ObjectDigestInfo 1270 In some environments, it may be required that the AC is not linked 1271 either to an identity (via entityName) or to a PKC (via 1272 baseCertificateID). The objectDigestInfo CHOICE in the holder field 1273 allows support for this requirement. 1275 If the holder is identified with the objectDigestInfo field, then 1276 the AC version field MUST contain v2 (the integer 1). 1278 The idea is to link the AC to an object by placing a hash of that 1279 object into the holder field of the AC. For example, this allows 1280 production of ACs that are linked to public keys rather than names. 1282 It also allows production of ACs which contain privileges associated 1283 with an executable object such as a Java class. However, this 1284 profile only specifies how to use a hash over a public key or PKC. 1285 That is, conformant ACs MUST NOT use the otherObjectTypes value for 1286 the digestedObjectType. 1288 To link an AC to a public key, the hash must be calculated over the 1289 representation of that public key which would be present in a PKC, 1290 specifically, the input for the hash algorithm MUST be the DER 1291 encoding of a SubjectPublicKeyInfo representation of the key. Note: 1292 This includes the AlgorithmIdentifier as well as the BIT STRING. The 1293 rules given in [PKIXPROF] for encoding keys MUST be followed. In 1294 this case the digestedObjectType MUST be publicKey and the 1295 otherObjectTypeID field MUST NOT be present. 1297 Note that if the public key value used as input to the hash function 1298 has been extracted from a PKC, then it is possible that the 1299 SubjectPublicKeyInfo from that PKC is NOT the value which should be 1300 hashed. This can occur if DSA Dss-parms are inherited as described 1301 in section 7.3.3 of [PKIXPROF]. The correct input for hashing in 1302 this context will include the value of the parameters inherited from 1303 the CA's PKC, and thus may differ from the SubjectPublicKeyInfo 1304 present in the PKC. 1306 Implementations which support this feature MUST be able to handle 1307 the representations of public keys for the algorithms specified in 1308 section 7.3 of [PKIXPROF]. In this case the digestedObjectType MUST 1309 be publicKey and the otherObjectTypeID field MUST NOT be present. 1311 In order to link an AC to a PKC via a digest, the digest MUST be 1312 calculated over the DER encoding of the entire PKC, including the 1313 signature value. In this case the digestedObjectType MUST be 1314 publicKeyCert and the otherObjectTypeID field MUST NOT be present. 1316 7.4 AA Controls 1318 During AC validation a relying party has to answer the question: is 1319 this AC issuer trusted to issue ACs containing this attribute? The 1320 AAControls PKC extension MAY be used to help answer the question. 1321 The AAControls extension is intended to be used in CA and AC issuer 1322 PKCs. 1324 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1326 AAControls ::= SEQUENCE { 1327 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1328 permittedAttrs [0] AttrSpec OPTIONAL, 1329 excludedAttrs [1] AttrSpec OPTIONAL, 1330 permitUnSpecified BOOLEAN DEFAULT TRUE 1331 } 1333 AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER 1335 The AAControls extension is used as follows: 1337 The pathLenConstraint, if present, is interpreted as in [PKIXPROF]. 1338 It restricts the allowed distance between the AA CA, (a CA directly 1339 trusted to include AAControls in its PKCs), and the AC issuer. 1341 The permittedAttrs field specifies a set of attribute types that any 1342 AC issuer below this AA CA is allowed to include in ACs. If this 1343 field is not present, it means that no attribute types are 1344 explicitly allowed. 1346 The excludedAttrs field specifies a set of attribute types that no 1347 AC issuer is allowed to include in ACs. If this field is not 1348 present, it means that no attribute types are explicitly disallowed. 1350 The permitUnSpecified field specifies how to handle attribute types 1351 which are not present in either the permittedAttrs or excludedAttrs 1352 fields. TRUE (the default) means that any unspecified attribute type 1353 is allowed in ACs; FALSE means that no unspecified attribute type is 1354 allowed. 1356 When AAControls are used, the following additional checks on an AA's 1357 PKC chain MUST all succeed for the AC to be valid: 1359 1. Some CA on the ACs certificate path MUST be directly trusted to 1360 issue PKCs which precede the AC issuer in the certification 1361 path, call this CA the "AA CA". 1362 2. All PKCs on the path from the AA CA down to and including the 1363 AC issuer's PKC MUST contain an AAControls extension; however, 1364 the AA CA's PKC need not contain this extension. 1365 3. Only those attributes in the AC which are allowed according to 1366 all of the AAControls extension values in all of the PKCs from 1367 the AA CA to the AC issuer, may be used for authorization 1368 decisions, all other attributes MUST be ignored. This check 1369 MUST be applied to the set of attributes following attribute 1370 decryption, and the id-aca-encAttrs type MUST also be checked. 1372 name id-pe-aaControls 1373 OID { id-pe 6 } 1374 syntax AAControls 1375 criticality MAY be TRUE 1377 8. Security Considerations 1379 The protection afforded private keys is a critical factor in 1380 maintaining security. Failure of AC issuers to protect their 1381 private keys will permit an attacker to masquerade as them, 1382 potentially generating false ACs or revocation status. Existence of 1383 bogus ACs and revocation status will undermine confidence in the 1384 system. If the compromise is detected, all ACs issued by the AC 1385 issuer MUST be revoked. Rebuilding after such a compromise will be 1386 problematic, so AC issuers are advised to implement a combination of 1387 strong technical measures (e.g., tamper-resistant cryptographic 1388 modules) and appropriate management procedures (e.g., separation of 1389 duties) to avoid such an incident. 1391 Loss of an AC issuer's private signing key may also be problematic. 1392 The AC issuer would not be able to produce revocation status or 1393 perform AC renewal. AC issuers are advised to maintain secure backup 1394 for signing keys. The security of the key backup procedures is a 1395 critical factor in avoiding key compromise. 1397 The availability and freshness of revocation status will affect the 1398 degree of assurance that should be placed in a long-lived AC. While 1399 long-lived ACs expire naturally, events may occur during its natural 1400 lifetime which negate the binding between the AC holder and the 1401 attributes. If revocation status is untimely or unavailable, the 1402 assurance associated with the binding is clearly reduced. 1404 The binding between an AC holder and attributes cannot be stronger 1405 than the cryptographic module implementation and algorithms used to 1406 generate the signature. Short key lengths or weak hash algorithms 1407 will limit the utility of an AC. AC issuers are encouraged to note 1408 advances in cryptology so they can employ strong cryptographic 1409 techniques. 1411 Inconsistent application of name comparison rules may result in 1412 acceptance of invalid targeted or proxied ACs, or rejection of valid 1413 ones. The X.500 series of specifications defines rules for 1414 comparing distinguished names. These rules require comparison of 1415 strings without regard to case, character set, multi-character white 1416 space substrings, or leading and trailing white space. This 1417 specification and [PKIXPROF] relaxes these requirements, requiring 1418 support for binary comparison at a minimum. 1420 AC issuers MUST encode the distinguished name in the AC 1421 holder.entityName field identically to the distinguished name in the 1422 holder's PKC. If different encodings are used, implementations of 1423 this specification may fail to recognize that the AC and PKC belong 1424 to the same entity. 1426 Implementers MUST ensure that following validation of an AC, only 1427 attributes that the issuer is trusted to issue are used in 1428 authorization decisions. Other attributes, which MAY be present MUST 1429 be ignored. Given that the AA controls PKC extension is optional to 1430 implement, AC verifiers MUST be provided with this information by 1431 other means. Configuration information is a likely alternative 1432 means. This becomes very important if an AC verifier trusts more 1433 than one AC issuer. 1435 There is often a requirement to map between the authentication 1436 supplied by a particular security protocol (e.g. TLS, S/MIME) and 1437 the AC holder's identity. If the authentication uses PKCs, then this 1438 mapping is straightforward. However, it is envisaged that ACs will 1439 also be used in environments where the holder may be authenticated 1440 using other means. Implementers SHOULD be very careful in mapping 1441 the authenticated identity to the AC holder. 1443 9. References 1445 [CMC] Myers, M., et al. "Certificate Management Messages over 1446 CMS", RFC2797. 1447 [CMP] Adams, C., Farrell, S., "Internet X.509 Public Key 1448 Infrastructure - Certificate Management Protocols", 1449 RFC2510. 1450 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630. 1451 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 1452 RFC2634. 1453 [KRB] Kohl, J., Neuman, C., "The Kerberos Network 1454 Authentication Service (V5)", RFC 1510. 1455 [LDAP] Wahl, M., et al., "Lightweight Directory Access Protocol 1456 (v3)", RFC 2251. 1457 [OCSP] Myers, M., et al., " X.509 Internet Public Key 1458 Infrastructure - Online Certificate Status Protocol - 1459 OCSP", RFC 2560. 1460 [PKINIT] Tung, B., et al., "Public Key Cryptography for Initial 1461 Authentication in Kerberos", draft-ietf-cat-kerberos-pk- 1462 init-11.txt, work-in-progress. 1463 [PKIXPROF] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet 1464 Public Key Infrastructure - X.509 Certificate and CRL 1465 Profile", RFC 2459. 1466 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1467 3", RFC 2026, BCP 9, October 1996. 1468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1469 Requirement Levels", RFC 2119. 1470 [URL] Berners-Lee, T., Masinter L., and M. McCahill., "Uniform 1471 Resource Locators (URL)", RFC 1738. 1472 [X.208-88] CCITT Recommendation X.208: Specification of Abstract 1473 Syntax Notation One (ASN.1). 1988. 1474 [X.209-88] CCITT Recommendation X.209: Specification of Basic 1475 Encoding Rules for Abstract Syntax Notation One (ASN.1). 1476 1988. 1477 [X.501-88] CCITT Recommendation X.501: The Directory - Models. 1478 1988. 1479 [X.501-93] ITU-T Recommendation X.501 : Information Technology - 1480 Open Systems Interconnection - The Directory: Models, 1481 1993. 1482 [X.509-88] CCITT Recommendation X.509: The Directory - 1483 Authentication Framework. 1988. 1484 [X.509-97] ITU-T Recommendation X.509: The Directory - 1485 Authentication Framework. 1997. 1486 [X.509-2000]ITU-T Recommendation X.509: The Directory - Public-Key 1487 and Attribute Certificate Frameworks. 2000 1489 Author's Addresses 1491 Stephen Farrell 1492 Baltimore Technologies 1493 61/62 Fitzwilliam Lane 1494 Dublin 2 1495 IRELAND 1497 tel: +353-1-647-3000 1498 email: stephen.farrell@baltimore.ie 1500 Russell Housley 1501 SPYRUS 1502 381 Elden Street 1503 Suite 1120 1504 Herndon, VA 20170 1505 USA 1507 tel: +1-703-707-0696 1508 email: housley@spyrus.com 1510 Full Copyright Statement 1512 Copyright (C) The Internet Society (date). All Rights Reserved. 1514 This document and translations of it may be copied and furnished to 1515 others, and derivative works that comment on or otherwise explain it 1516 or assist in its implementation may be prepared, copied, published 1517 and distributed, in whole or in part, without restriction of any 1518 kind, provided that the above copyright notice and this paragraph 1519 are included on all such copies and derivative works. In addition, 1520 the ASN.1 module presented in Appendix B may be used in whole or in 1521 part without inclusion of the copyright notice. However, this 1522 document itself may not be modified in any way, such as by removing 1523 the copyright notice or references to the Internet Society or other 1524 Internet organizations, except as needed for the purpose of 1525 developing Internet standards in which case the procedures for 1526 copyrights defined in the Internet Standards process shall be 1527 followed, or as required to translate it into languages other than 1528 English. 1530 The limited permissions granted above are perpetual and will not be 1531 revoked by the Internet Society or its successors or assigns. This 1532 document and the information contained herein is provided on an "AS 1533 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1534 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1535 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1536 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1537 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1539 Appendix A: Object Identifiers 1541 This (normative) appendix lists the new object identifiers which are 1542 defined in this specification. Some of these are required only for 1543 support of optional features and are not required for conformance to 1544 this profile. This specification mandates support for OIDs which 1545 have arc elements with values that are less than 2^32, (i.e. they 1546 MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less 1547 than 2^31 (i.e. less than or equal to 2,147,483,647). This allows 1548 each arc element to be represented within a single 32 bit word. 1549 Implementations MUST also support OIDs where the length of the 1550 dotted decimal (see [LDAP], section 4.1.2) string representation can 1551 be up to 100 bytes (inclusive). Implementations MUST be able to 1552 handle OIDs with up to 20 elements (inclusive). AA's SHOULD NOT 1553 issue ACs which contain OIDs that breach these requirements. 1555 The following OIDs are imported from [PKIXPROF]: 1557 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1558 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 1559 id-mod OBJECT IDENTIFIER ::= { id-pkix 0 } 1560 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 1561 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 1562 id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } 1563 id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 } 1565 The following new ASN.1 module OID is defined: 1567 id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 } 1569 The following AC extension OIDs are defined: 1571 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1572 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 } 1573 id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 1575 The following PKC extension OIDs are defined: 1577 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1579 The following attribute OIDs are defined: 1581 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1582 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1583 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1584 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1585 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1586 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1587 id-at-role OBJECT IDENTIFIER ::= { id-at 72 } 1588 id-at-clearance OBJECT IDENTIFIER ::= 1589 { joint-iso-ccitt(2) ds(5) module(1) 1590 selected-attribute-types(5) clearance (55) } 1592 Appendix B: ASN.1 Module 1594 PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) 1595 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1596 id-mod-attribute-cert(12)} 1598 DEFINITIONS EXPLICIT TAGS ::= 1600 BEGIN 1602 -- EXPORTS ALL -- 1604 IMPORTS 1606 -- PKIX Certificate Extensions 1607 Attribute, AlgorithmIdentifier, CertificateSerialNumber, 1608 Extensions, UniqueIdentifier, 1609 id-pkix, id-pe, id-kp, id-ad, id-at 1610 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 1611 dod(6) internet(1) security(5) mechanisms(5) 1612 pkix(7) id-mod(0) id-pkix1-explicit-88(1)} 1614 GeneralName, GeneralNames, id-ce 1615 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 1616 dod(6) internet(1) security(5) mechanisms(5) 1617 pkix(7) id-mod(0) id-pkix1-implicit-88(2)} ; 1619 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1620 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1621 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 10 } 1622 id-ce-targetInformation OBJECT IDENTIFIER ::= { id-ce 55 } 1624 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1626 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1627 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1628 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1629 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1630 -- { id-aca 5 } is reserved 1631 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1633 id-at-role OBJECT IDENTIFIER ::= { id-at 72} 1634 id-at-clearance OBJECT IDENTIFIER ::= 1635 { joint-iso-ccitt(2) ds(5) module(1) 1636 selected-attribute-types(5) clearance (55) } 1638 -- Uncomment this if using a 1988 level ASN.1 compiler 1639 -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 1641 AttributeCertificate ::= SEQUENCE { 1642 acinfo AttributeCertificateInfo, 1643 signatureAlgorithm AlgorithmIdentifier, 1644 signatureValue BIT STRING 1645 } 1647 AttributeCertificateInfo ::= SEQUENCE { 1648 version AttCertVersion DEFAULT v1, 1649 holder Holder, 1650 issuer AttCertIssuer, 1651 signature AlgorithmIdentifier, 1652 serialNumber CertificateSerialNumber, 1653 attrCertValidityPeriod AttCertValidityPeriod, 1654 attributes SEQUENCE OF Attribute, 1655 issuerUniqueID UniqueIdentifier OPTIONAL, 1656 extensions Extensions OPTIONAL 1657 } 1659 AttCertVersion ::= INTEGER {v1(0), v2(1) } 1661 Holder ::= SEQUENCE { 1662 baseCertificateID [0] IssuerSerial OPTIONAL, 1663 -- the issuer and serial number of 1664 -- the holder's Public Key Certificate 1665 entityName [1] GeneralNames OPTIONAL, 1666 -- the name of the claimant or role 1667 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 1668 -- if present, version must be v2 1669 } 1671 ObjectDigestInfo ::= SEQUENCE { 1672 digestedObjectType ENUMERATED { 1673 publicKey (0), 1674 publicKeyCert (1), 1675 otherObjectTypes (2) }, 1676 -- otherObjectTypes MUST NOT 1677 -- MUST NOT be used in this profile 1678 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 1679 digestAlgorithm AlgorithmIdentifier, 1680 objectDigest BIT STRING 1681 } 1683 AttCertIssuer ::= CHOICE { 1684 v1Form GeneralNames, -- v1 or v2 1685 v2Form [0] V2Form -- v2 only 1686 } 1688 V2Form ::= SEQUENCE { 1689 issuerName GeneralNames OPTIONAL, 1690 baseCertificateID [0] IssuerSerial OPTIONAL, 1691 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 1692 -- at least one of issuerName, baseCertificateID 1693 -- or objectDigestInfo must be present 1694 } 1696 IssuerSerial ::= SEQUENCE { 1697 issuer GeneralNames, 1698 serial CertificateSerialNumber, 1699 issuerUID UniqueIdentifier OPTIONAL 1700 } 1702 AttCertValidityPeriod ::= SEQUENCE { 1703 notBeforeTime GeneralizedTime, 1704 notAfterTime GeneralizedTime 1705 } 1707 Targets ::= SEQUENCE OF Target 1709 Target ::= CHOICE { 1710 targetName [0] GeneralName, 1711 targetGroup [1] GeneralName, 1712 targetCert [2] TargetCert 1713 } 1715 TargetCert ::= SEQUENCE { 1716 targetCertificate IssuerSerial, 1717 targetName GeneralName OPTIONAL, 1718 certDigestInfo ObjectDigestInfo OPTIONAL 1719 } 1721 IetfAttrSyntax ::= SEQUENCE { 1722 policyAuthority[0] GeneralNames OPTIONAL, 1723 values SEQUENCE OF CHOICE { 1724 octets OCTET STRING, 1725 oid OBJECT IDENTIFIER, 1726 string UTF8String 1727 } 1728 } 1730 SvceAuthInfo ::= SEQUENCE { 1731 service GeneralName, 1732 ident GeneralName, 1733 authInfo OCTET STRING OPTIONAL 1734 } 1736 RoleSyntax ::= SEQUENCE { 1737 roleAuthority [0] GeneralNames OPTIONAL, 1738 roleName [1] GeneralName 1739 } 1741 Clearance ::= SEQUENCE { 1742 policyId OBJECT IDENTIFIER, 1743 classList ClassList DEFAULT {unclassified}, 1744 securityCategories 1745 SET OF SecurityCategory OPTIONAL 1746 } 1748 ClassList ::= BIT STRING { 1749 unmarked (0), 1750 unclassified (1), 1751 restricted (2), 1752 confidential (3), 1753 secret (4), 1754 topSecret (5) 1755 } 1757 SecurityCategory ::= SEQUENCE { 1758 type [0] IMPLICIT OBJECT IDENTIFIER, 1759 value [1] ANY DEFINED BY type 1760 } 1762 AAControls ::= SEQUENCE { 1763 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1764 permittedAttrs [0] AttrSpec OPTIONAL, 1765 excludedAttrs [1] AttrSpec OPTIONAL, 1766 permitUnSpecified BOOLEAN DEFAULT TRUE 1767 } 1769 AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER 1771 ACClearAttrs ::= SEQUENCE { 1772 acIssuer GeneralName, 1773 acSerial INTEGER, 1774 attrs SEQUENCE OF Attribute 1775 } 1777 ProxyInfo ::= SEQUENCE OF Targets 1779 END