idnits 2.17.00 (12 Aug 2021) /tmp/idnits31903/draft-ietf-pkix-ac509prof-02.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? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 35 longer pages, the longest (page 26) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 37 pages 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 2 instances of too long lines in the document, the longest one being 4 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 274 has weird spacing: '...erifier any ...' == Line 685 has weird spacing: '...icality mus...' == 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 fails 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 (March 2000) is 8101 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 1649 -- Looks like a reference, but probably isn't: '1' on line 1650 -- Looks like a reference, but probably isn't: '2' on line 1607 -- Looks like a reference, but probably isn't: '3' on line 1608 == Unused Reference: 'CMC' is defined on line 1351, but no explicit reference was found in the text == Unused Reference: 'CMP' is defined on line 1353, but no explicit reference was found in the text == Unused Reference: 'ESS' is defined on line 1357, 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 2251 (ref. 'LDAP') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 1510 (ref. 'KRB') (Obsoleted by RFC 4120, RFC 6649) == 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 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) Summary: 12 errors (**), 0 flaws (~~), 13 warnings (==), 9 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 March 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................................................1 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.....................................6 53 2. Terminology..................................................7 54 3. Requirements.................................................8 55 4. The AC Profile...............................................9 56 4.1 X.509 Attribute Certificate Definition.................9 57 4.2 Profile of Standard Fields............................11 58 4.2.1 Version.........................................11 59 4.2.2 Holder..........................................11 60 4.2.3 Issuer..........................................12 61 4.2.4 Signature.......................................12 62 4.2.5 Serial Number...................................13 63 4.2.6 Validity Period.................................13 64 4.2.7 Attributes......................................13 65 4.2.8 Issuer Unique Identifier........................14 66 4.2.9 Extensions......................................14 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....................17 72 4.3.5 CRL Distribution Points.........................17 73 4.3.6 No Revocation Available.........................17 74 4.4 Attribute Types.......................................18 75 4.4.1 Service Authentication Information..............18 76 4.4.2 Access Identity.................................19 77 4.4.3 Charging Identity...............................19 78 4.4.4 Group...........................................19 79 4.4.5 Role............................................19 80 4.4.6 Clearance.......................................20 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..................................................30 91 Author's Addresses..............................................31 92 Full Copyright Statement........................................31 93 Appendix B: Object Identifiers..................................32 94 Appendix B: "Compilable" ASN.1 Module...........................33 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], 116 [PKIXPROF] bind an identity and a public key. The identity may be 117 used to support identity-based access control decisions after the 118 client proves that it has access to the private key that corresponds 119 to the public key contained in the PKC. The public key is used to 120 validate digital signatures or cryptographic key management 121 operations. However, not all access control decisions are identity- 122 based. Rule-based, role-based, and rank-based access control 123 decisions require additional information. For example, information 124 about a client's ability to pay for a resource access may be more 125 important than the client's identity. Authorization information to 126 support such access control decisions may be placed in a PKC 127 extension or placed in a separate attribute certificate (AC). 129 The placement of authorization information in PKCs is usually 130 undesirable for two reasons. First, authorization information does 131 not have the same lifetime as the binding of the identity and the 132 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 attribute 142 certificate (AC) provides this protection, and it is simply a 143 digitally signed (or certified) set of attributes. 145 An AC is a structure similar to a PKC; the main difference being 146 that it contains no public key. An AC may contain attributes that 147 specify group membership, role, security clearance, and other access 148 control information associated with the AC holder. The syntax for 149 the AC is defined in Recommendation X.509 (making the term "X.509 150 certificate" ambiguous). This document specifies a profile of the 151 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 "pointer" to a PKC for the requester and that PKC 159 has been used to authenticate the access request. 161 As there is often confusion about the difference between PKCs and 162 ACs, an analogy may help. A PKC can be considered to be like a 163 passport: it identifies the holder, tends to last for a long time 164 and should not be trivial to obtain. An AC is more like an entry 165 visa: it is typically issued by a different authority and does not 166 last for as long a time. As acquiring an entry visa typically 167 requires presenting a passport, getting a visa can be a simpler 168 process. 170 1.1 Delegation and AC chains 172 The X.509 standard defines delegation as "Conveyance of privilege 173 from one entity that holds such privilege, to another entity". It 174 further defines a delegation path as "An ordered sequence of 175 certificates which, together with authentication of a privilege 176 asserter's identity can be processed to verify the authenticity of a 177 privilege asserter's privilege". It then goes on to define various 178 mechanisms for use in delegation cases involving "chains" of ACs. 180 As the administration and processing associated with such AC chains 181 is potentially much more complex than use of a single AC, and as the 182 use of ACs in the Internet is today in its infancy, this 183 specification does not address such AC chains. Other (future) 184 specifications may address the use of AC chains. 186 This means that conformant implementations are only REQUIRED to be 187 able to "handle" a single AC at a time. Note however, that 188 validation of that AC MAY require validation of a full PKC chain, as 189 specified in [PKIXPROF]. 191 1.2 Attribute Certificate Distribution ("push" vs "pull") 193 As discussed above, ACs provide a mechanism to securely provide 194 authorization information to access control decision functions. 195 However, there are a number of possible communication paths that an 196 AC may take. 198 In some environments it is suitable for a client to "push" an AC to 199 a server. This means that no new connections between the client and 200 server are required. It also means that no search burden is imposed 201 on servers, which improves performance. 203 In other cases, it is more suitable for a client simply to 204 authenticate to the server and for the server to request ("pull") 205 the client's AC from an AC issuer or a repository. A major benefit 206 of the "pull" model is that it can be implemented without changes to 207 the client or client-server protocol. It is also more suitable for 208 some inter-domain cases where the client's rights should be assigned 209 within the server's domain, rather than within the client's "home" 210 domain. 212 There are a number of possible exchanges that can occur and three 213 entities involved (client, server and AC issuer). In addition the 214 use of a directory service or other repository for AC retrieval MAY 215 be supported. 217 Figure 1 shows an abstract view of the exchanges that may involve 218 ACs. This profile does not specify 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 249 Section 3 specifies the requirements that this profile is to meet 250 Section 4 contains the profile of the X.509 AC 251 Section 5 specifies rules for AC validation 252 Section 6 specifies rules for AC revocation checks 253 Section 7 specifies optional features which MAY be supported but for 254 which support is not required for conformance to this profile 256 Appendices contain the list of OIDs required to support this 257 specification and a "compilable" ASN.1 module. 259 2. Terminology 261 For simplicity, we use the terms client and server in this 262 specification. This is not intended to indicate that ACs are only to 263 be used in client-server environments, e.g. in the S/MIME v3 264 context, the mail user agent would, by turns, be both "client" and 265 "server" in the sense the terms are used here. 267 Term Meaning 269 AA Attribute Authority, the entity that issues the 270 AC, synonymous in this specification with "AC 271 issuer" 272 AC Attribute Certificate 273 AC user any entity that parses or processes an AC 274 AC verifier any entity that checks the validity of an AC and 275 then makes use of the result 276 AC issuer the entity which signs the AC, synonymous in this 277 specification with "AA" 278 AC holder the entity indicated (perhaps indirectly) in the 279 holder field of the AC 280 Client the entity which is requesting the action for 281 which authorization checks are to be made 282 Proxying In this specification, Proxying is used to mean 283 the situation where an application server acts as 284 an application client on behalf of a user. 285 Proxying here does not mean granting of authority. 286 PKC Public Key Certificate - uses the type ASN.1 287 Certificate defined in X.509 and profiled in RFC 288 2459. This (non-standard) acronym is used in order 289 to avoid confusion about the term "X.509 290 certificate". 291 Server the entity which requires that the authorization 292 checks are made 294 3. Requirements 296 This Attribute Certificate profile meets the following requirements. 298 Time/Validity requirements: 300 1. Support for short-lived or long-lived ACs is required. Typical 301 validity periods might be measured in hours, as opposed to 302 months for X.509 public key certificates. Short validity 303 periods mean that ACs can be useful without a revocation 304 mechanism. 306 Attribute Types: 308 2. Issuers of ACs should be able to define their own attribute 309 types for use within closed domains. 310 3. Some standard attribute types should be defined which can be 311 contained within ACs, for example "access identity", "group", 312 "role", "clearance", "audit identity", "charging id" etc. 313 4. Standard attribute types should be defined so that it is 314 possible for an AC verifier to distinguish between e.g. the 315 "Administrators group" as defined by Baltimore and the 316 "Administrators group" as defined by SPYRUS. 318 Targeting of ACs: 320 5. It should be possible to "target" an AC. This means that a 321 given AC may be "targeted" at one, or a small number of, 322 servers in the sense that a trustworthy non- target will reject 323 the AC for authorization decisions. 325 Push vs. Pull 327 6. ACs should be defined so that they can either be "pushed" by 328 the client to the server, or "pulled" by the server from a 329 repository or other network service (which may be an online AC 330 issuer). 332 4. The AC Profile 334 Attribute certificates may be used in a wide range of applications 335 and environments covering a broad spectrum of interoperability goals 336 and a broader spectrum of operational and assurance requirements. 337 The goal of this document is to establish a common baseline for 338 generic applications requiring broad interoperability and limited 339 special purpose requirements. In particular, the emphasis will be 340 on supporting the use of attribute certificates for informal 341 Internet electronic mail, IPSec, and WWW applications. 343 This section presents a profile for attribute certificates that will 344 foster interoperability. This section also defines some private 345 extensions for the Internet community. 347 While the ISO/IEC/ITU documents use the 1993 (or later) version of 348 ASN.1; as has been done for PKCs [PKIXPROF], this document uses the 349 1988 ASN.1 syntax, the encoded certificate and standard extensions 350 are equivalent. 352 Where maximum lengths for fields are specified, these lengths refer 353 to the DER encoding and do not include the ASN.1 tag or length 354 fields. 356 Conforming implementations MUST support the profile specified in 357 this section. 359 4.1 X.509 Attribute Certificate Definition 361 X.509 contains the definition of an Attribute Certificate given 362 below. Types that are not defined can be found in [PKIXPROF]. 364 AttributeCertificate ::= SEQUENCE { 365 acinfo AttributeCertificateInfo, 366 signatureAlgorithm AlgorithmIdentifier, 367 signatureValue BIT STRING 368 } 370 AttributeCertificateInfo ::= SEQUENCE { 371 version AttCertVersion DEFAULT v1, 372 holder Holder, 373 issuer AttCertIssuer, 374 signature AlgorithmIdentifier, 375 serialNumber CertificateSerialNumber, 376 attrCertValidityPeriod AttCertValidityPeriod, 377 attributes SEQUENCE OF Attribute, 378 issuerUniqueID UniqueIdentifier OPTIONAL, 379 extensions Extensions OPTIONAL 380 } 382 AttCertVersion ::= INTEGER {v1(0), v2(1) } 383 Holder ::= SEQUENCE { 384 baseCertificateID [0] IssuerSerial OPTIONAL, 385 -- the issuer and serial number of 386 -- the holder's Public Key Certificate 387 entityName [1] GeneralNames OPTIONAL, 388 -- the name of the claimant or role 389 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 390 -- if present, version must be v2 391 } 393 ObjectDigestInfo ::= SEQUENCE { 394 digestedObjectType ENUMERATED { 395 publicKey (0), 396 publicKeyCert (1), 397 otherObjectTypes (2) }, 398 -- otherObjectTypes MUST NOT 399 -- MUST NOT be used in this profile 400 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 401 digestAlgorithm AlgorithmIdentifier, 402 objectDigest BIT STRING 403 } 405 AttCertIssuer ::= CHOICE { 406 oldForm GeneralNames, 407 newForm [0] SEQUENCE { 408 issuerName GeneralNames OPTIONAL, 409 baseCertificateId [0] IssuerSerial OPTIONAL, 410 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 411 --at least one of issuerName, baseCertificateId or -- 412 -- objectDigestInfo must be present -- 413 -- if newForm is used, version must be v2-- 414 } 416 IssuerSerial ::= SEQUENCE { 417 issuer GeneralNames, 418 serial CertificateSerialNumber, 419 issuerUID UniqueIdentifier OPTIONAL 420 } 422 AttCertValidityPeriod ::= SEQUENCE { 423 notBeforeTime GeneralizedTime, 424 notAfterTime GeneralizedTime 425 } 427 Although the Attribute syntax is defined in [PKIXPROF], we repeat 428 the definition here for convenience. 430 Attribute ::= SEQUENCE { 431 type AttributeType, 432 values SET OF AttributeValue 433 -- at least one value is required -- 434 } 435 AttributeType ::= OBJECT IDENTIFIER 437 AttributeValue ::= ANY 439 Implementers should note that the DER encoding (DER is defined in 440 [X.208-88]) of the SET OF values requires ordering of the encodings 441 of the values. Though this issue arises with respect to 442 distinguished names, and has to be handled by [PKIXPROF] 443 implementations, its is much more significant in this context, since 444 the inclusion of multiple values is much more common in ACs. 446 4.2 Profile of Standard Fields 448 For all GeneralName fields in this profile the otherName, 449 x400Address, ediPartyName and registeredID options MUST NOT be used 450 unless otherwise specified (e.g. as in the description of targeting 451 extension). 453 The use of Kerberos [KRB] format names, encoded into the otherName, 454 SHOULD however, be supported using the krb5PrincipalName OID and the 455 KerberosName syntax as defined in [PKINIT]. 457 This means that unless otherwise indicated,(e.g. for the role 458 attribute), conforming implementations MUST be able to support the 459 dNSName, directoryName, uniformResourceIdentifier and iPAddress 460 fields in all cases where GeneralName is used. The MUST support 461 requirements for each of these fields are as specified in 462 [PKIXPROF], (mainly in section 4.2.1.7). 464 4.2.1 Version 466 This MUST be the default value of v1, i.e. not present in the DER 467 encoding, except where the holder is identified using the optional 468 objectDigestInfo field, as specified in section 7.3. 470 4.2.2 Holder 472 For any environment where the AC is passed in an authenticated 473 message or session, and where the authentication is based on the use 474 of an X.509 public key certificate (PKC), the holder field SHOULD 475 use the baseCertificateID. 477 With the baseCertificateID option, the holder's PKC serialNumber and 478 issuer MUST be identical to the AC holder field. The PKC issuer MUST 479 have a non empty distinguished name which is to be present as the 480 single value of the holder.baseCertificateID.issuer construct in the 481 directoryName field. The holder.baseCertificateID.issuerUID field 482 MUST only be used if the holder's PKC contains an issuerUniqueID 483 field (in which case, the same value MUST be present in the 484 holder.baseCertificateID.issuerUID_field). Thus, the 485 baseCertificateID is only usable with PKC profiles (like [PKIXPROF]) 486 which mandate that the PKC issuer field contain a non empty 487 distinguished name value. 489 Note: An "empty" distinguished name is a distinguished name where 490 the SEQUENCE OF relative distinguished names is of zero length. In a 491 DER encoding this has the value '3000'H. 493 If the holder field uses the entityName option and the underlying 494 authentication is based on a PKC, then the entityName MUST be the 495 same as the PKC subject field, unless the PKC subject field contains 496 an empty distinguished name. In that case, the entityName field MUST 497 be identical to one of the values of the PKC subjectAltName field 498 extension. Note that [PKIXPROF] mandates that the subjectAltNames 499 extension be present if the PKC subject is a non empty distinguished 500 name. 502 In any other case where the holder field uses the entityName option 503 then only one name SHOULD be present. 505 Implementations conforming to this profile are not required to 506 support the use of the objectDigest field. However, section 7.3 507 specifies how this optional feature MAY be used. 509 Any protocol conforming to this profile SHOULD specify which AC 510 holder option is to be used and how this fits with the supported 511 authentication schemes define in that protocol. 513 4.2.3 Issuer 515 ACs conforming to this profile MUST use the newForm.issuerName 516 choice, which MUST contain one and only one GeneralName, which MUST 517 contain a non empty distinguished name in the directoryName field. 518 This means that all AC issuers MUST have non empty distinguished 519 names. 521 Part of the reason for the use of the issuerName field is that it 522 allows the AC verifier to be independent of the AC issuer's public 523 key infrastructure. Using the baseCertificateId field to reference 524 the AC issuer would mean that the AC verifier would have such a 525 dependency. 527 4.2.4 Signature 529 Contains the algorithm identifier used to validate the AC signature. 531 This MUST be one of the following algorithms defined in [PKIXPROF] 532 section 7.2: md5WithRSAEncryption, id-dsa-with-sha1 or sha- 533 1WithRSAEncryption, or ecdsa-with-SHA1 defined in [ECDSA] section 534 3.2. 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 (one second is 543 the shortest possible validity due to the use of GeneralizedTime). 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 32 bits. Conformant ACs MUST 554 NOT use 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, but they MUST be unique for a 559 given AC issuer. 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. Optionally, the 569 GeneralizedTime field can include a representation of the time 570 differential between local 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. 577 (Note that the above is as specified in [PKIXPROF], section 578 4.1.2.5.2.) 580 Note that AC users MUST be able to handle the case where an AC is 581 issued, which (at the time of parsing), has its entire validity 582 period in the future (a "post-dated" AC). This is valid for some 583 applications, e.g. backup. 585 4.2.7 Attributes 587 The attributes field gives information about the AC holder. When the 588 AC is used for authorization this will often contain a set of 589 privileges. 591 The attributes field contains a SEQUENCE OF Attribute. Each 592 Attribute MAY contain a SET OF values. For a given AC each attribute 593 type OID in the sequence MUST be unique, that is, only one instance 594 of each attribute can occur in a single AC. All instances can 595 however, be multi-valued. 597 AC users MUST be able to handle multiple values for all attribute 598 types. 600 Note that an AC MUST contain at least one attribute, that is, the 601 SEQUENCE OF Attributes MUST NOT be of zero length. 603 Some standard attribute types are defined in section 4.5. 605 4.2.8 Issuer Unique Identifier 607 This field MUST NOT be used unless it is also used in the AC 608 issuer's PKC, in which case it MUST be used. Note that [PKIXPROF] 609 states that this field "SHOULD NOT" be used by conforming CAs, but 610 that applications SHOULD be able to parse PKCs containing the field. 612 4.2.9 Extensions 614 The extensions field generally gives information about the AC as 615 opposed to information about the AC holder. 617 Section 4.3 defines the extensions that MAY be used with this 618 profile. An AC that has no extensions conforms to the profile. If 619 any other critical extension is used, then the AC does not conform 620 to this profile. An AC that contains additional non-critical 621 extensions still conforms. 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 631 certificates and standard locations for information. Communities 632 may elect to use additional extensions; however, caution should be 633 exercised in adopting any critical extensions in ACs, which might 634 prevent use in 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 may make the use of the holder 643 field of the AC unsuitable for use in audit trails. 645 In order 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 except with the co-operation 648 of the AC issuer. 650 The value of the audit identity plus the AC issuer/serial SHOULD 651 then be used for audit/logging purposes. If the value of the audit 652 identity is suitably chosen then a server/service administrator can 653 use audit trails to track the behavior of an AC holder without being 654 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 map 659 "backwards" from the audit identity to the actual identity of the AC 660 holder. 662 Of course, auditing could be based on the AC issuer/serial pair, 663 however, this method doesn't allow tracking the same AC holder 664 across different ACs. This means that an audit identity is only 665 useful if it lasts for longer than the typical AC lifetime - how 666 much longer is an issue for the AC issuer implementation. Auditing 667 could also be based on the AC holder's PKC issuer/serial however, 668 this will often allow the server/service administrator identify the 669 AC holder. 671 As the AC verifier might otherwise use the AC subject or some other 672 identifying value for audit purposes, this extension MUST be 673 critical when used. 675 Protocols that use ACs will often expose the identity of the AC 676 holder in the bits on-the-wire. In such cases, an "opaque" audit 677 identity does not make use of the AC anonymous, it simply ensures 678 that the ensuing audit trails are "semi-anonymous". 680 The value of an audit identity MUST NOT be longer than 20 octets. 682 name id-pe-ac-auditIdentity 683 OID { id-pe 4 } 684 syntax OCTET STRING 685 criticality must be TRUE 687 4.3.2 AC Targeting 689 In order to allow that an AC is "targeted", the target information 690 extension MAY be used to specify a number of servers/services. The 691 intent is that the AC SHOULD only be usable at the specified 692 servers/services - an (honest) AC verifier who is not amongst the 693 named servers/services MUST reject the AC. 695 If this extension is not present then the AC is not targeted and may 696 be accepted by any server. 698 In this profile, the targeting information simply consists of a list 699 of named targets or groups. 701 The following syntax is used to represent the targeting information: 703 Targets ::= SEQUENCE OF Target 704 Target ::= CHOICE { 705 targetName [0] GeneralName, 706 targetGroup [1] GeneralName, 707 targetCertificate [2] IssuerSerial, 708 targetDigest [3] ObjectDigestInfo 709 } 711 The targetCertificate and targetDigest fields are only present to 712 allow future compatibility with [X.509-DAM] and MUST NOT be used. 714 The targets check passes if the current server (recipient) is one of 715 the targetName fields in the targets part, or, the current server is 716 a member of one of the targetGroup fields in the targets part. In 717 this case, the current server is said to "match" the targeting 718 extension. 720 How the membership of a target within a targetGroup is determined is 721 not defined here. It is assumed that any given target "knows" the 722 names of the targetGroup's to which it belongs or can otherwise 723 determine its membership. For example, if the targetGroup were to be 724 a DNS domain and the AC verifier knows the DNS domain to which it 725 belongs. Another example would be where the targetGroup is 726 "PRINTERS" and the AC verifier "knows" that it's a printer or print 727 server. 729 name id-pe-ac-targeting 730 <> 733 OID { id-pe 5 } 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 entityName choice, this does not arise here. 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. Note that support for the id-ad-caIssuers 760 accessMethod defined in [PKIXPROF] is NOT REQUIRED as in this 761 profile, the authorityInformationAccess is only used for revocation 762 status checking. Conformant ACs containing this extension MUST 763 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, this MUST contain an HTTP 772 URL, specifying the location of an OCSP responder. The AC issuer 773 MUST, of course, maintain an OCSP responder at this location. 775 name id-ce-authorityInfoAccess 776 OID { id-pe 1 } 777 syntax AuthorityInfoAccessSyntax 778 criticality MUST be FALSE 780 4.3.5 CRL Distribution Points 782 The crlDistributionPoints extension as profiled in [PKIXPROF] MAY be 783 used to assist the AC verifier in checking the revocation status of 784 the AC. See section 6 on revocation below for details. 786 Exactly one distribution point MUST be present, it MUST use the 787 DistributionPointName option, which MUST contain a fullName, which 788 MUST contain a single name form. That name MUST contain either an 789 HTTP URL or a distinguished name. 791 name id-ce-cRLDistributionPoints 792 OID { id-ce 31 } 793 syntax CRLDistPointsSyntax 794 criticality MUST be FALSE 796 4.3.6 No Revocation Available 798 This extension (imported from [X.509-DAM]) allows an AC issuer to 799 indicate that no revocation information will be made available for 800 this AC. 802 This extension MUST be non-critical, on the basis that an AC 803 verifier that does not understand it can still find a revocation 804 list (for example), but won't ever find an entry for the AC. 806 name id-ce-noRevAvail 807 OID { id-ce 56 } 808 syntax NULL (i.e. '0500'H is the DER encoding) 809 criticality MUST be FALSE 811 4.4 Attribute Types 813 Some of the attribute types defined below make use of the 814 IetfAttrSyntax type defined below. The reasons for using this type 815 are: 817 1. It allows a separation between the AC issuer and the attribute 818 policy authority. This is useful for situations where a single 819 policy authority (e.g. an organization) allocates attribute 820 values, but where multiple AC issuers are deployed for 821 performance, network or other reasons. 822 2. The syntaxes allowed for values are restricted to OCTET STRING 823 OID and UTF8String, which reduces some of the matching 824 complexities associated with more general syntaxes. All multi- 825 valued attributes using this syntax are restricted so that each 826 value MUST use the same choice of value syntax, that is, it is 827 not allowed that one value use an OID but that a second value 828 uses a string. 830 IetfAttrSyntax ::= SEQUENCE { 831 policyAuthority [0] GeneralNames OPTIONAL, 832 values SEQUENCE OF CHOICE { 833 octets OCTET STRING, 834 oid OBJECT IDENTIFIER, 835 string UTF8String 836 } 837 } 839 In the descriptions below, each attribute type is tagged as either 840 "Multiple Allowed" or "One Attribute value only; multiple values 841 within the IetfAttrSyntax". This refers to the SET OF 842 AttributeValue, the AttributeType still only occurs once, as 843 specified in section 4.2.7. 845 4.4.1 Service Authentication Information 847 This attribute type identifies the AC holder to the server/service 848 by a name and MAY include optional service specific authentication 849 information. Typically this will contain a username/password pair 850 for a "legacy" application. 852 This attribute type will typically need to be encrypted if the 853 authInfo field contains sensitive information (e.g. a password). 855 name id-aca-authenticationInfo 856 OID { id-aca 1 } 857 Syntax SvceAuthInfo 858 values: Multiple allowed 860 SvceAuthInfo ::= SEQUENCE { 861 service GeneralName, 862 ident GeneralName, 863 authInfo OCTET STRING OPTIONAL 864 } 866 4.4.2 Access Identity 868 An access identity identifies the AC holder to the server/service. 869 For this attribute the authInfo field MUST NOT be present. 871 name id-aca-accessIdentity 872 OID { id-aca 2 } 873 syntax SvceAuthInfo 874 values: Multiple allowed 876 4.4.3 Charging Identity 878 This attribute type identifies the AC holder for charging purposes. 879 Note that, in general, the charging identity will be different from 880 other identities of the holder, for example, when the holderĘs 881 company is to be charged for service. 883 name id-aca-chargingIdentity 884 OID { id-aca 3 } 885 syntax IetfAttrSyntax 886 values: One Attribute value only; multiple values within the 887 IetfAttrSyntax 889 4.4.4 Group 891 This attribute carries information about group memberships of the AC 892 holder. 894 name id-aca-group 895 OID { id-aca 4 } 896 syntax IetfAttrSyntax 897 values: One Attribute value only; multiple values within the 898 IetfAttrSyntax 900 4.4.5 Role 902 This attribute (imported from [X.509-DAM]) carries information about 903 role allocations of the AC holder. 905 The syntax used for this attribute is: 907 RoleSyntax ::= SEQUENCE { 908 roleAuthority [0] GeneralNames OPTIONAL, 909 roleName [1] GeneralName 910 } 912 The roleAuthority field MUST NOT be used. The roleName field MUST be 913 present and MUST use the uniformResourceIdentifier field of the 914 GeneralName. 916 name id-at-role 917 OID { id-aca 5 } 918 syntax RoleSyntax 919 values: Multiple allowed 921 4.4.6 Clearance 923 This attribute (imported from [X.501]) carries clearance (security 924 labeling) information about the AC holder. 926 Clearance ::= SEQUENCE { 927 policyId OBJECT IDENTIFIER, 928 classList ClassList DEFAULT {unclassified}, 929 securityCategories 930 SET OF SecurityCategory OPTIONAL 931 } 933 ClassList ::= BIT STRING { 934 unmarked (0), 935 unclassified (1), 936 restricted (2) 937 confidential (3), 938 secret (4), 939 topSecret (5) 940 } 942 SecurityCategory ::= SEQUENCE { 943 type [0] IMPLICIT OBJECT IDENTIFIER, 944 value [1] ANY DEFINED BY type 945 } 947 -- This is the same as the original syntax which was defined 948 -- using the MACRO construct, as follows: 949 -- SecurityCategory ::= SEQUENCE { 950 -- type [0] IMPLICIT SECURITY-CATEGORY, 951 -- value [1] ANY DEFINED BY type 952 -- } 953 -- 954 -- SECURITY-CATEGORY MACRO ::= 955 -- BEGIN 956 -- TYPE NOTATION ::= type | empty 957 -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 958 -- END 960 The security category value above can uses the ASN.1 ANY construct. 961 Conformant ACs MUST only use UTF8String, OID and OCTET STRING 962 syntaxes for this value. 964 name { id-at-clearance } 965 OID { joint-iso-ccitt(2) ds(5) module(1) selected- 966 attribute-types(5) clearance (55) } 967 syntax Clearance - imported from [X.501] 968 values Multiple allowed 970 4.5 Profile of AC Issuer's PKC 972 The AC Issuer's PKC MUST conform to [PKIXPROF] and its keyUsage MUST 973 NOT explicitly indicate that the AC issuer can't sign. In order to 974 avoid confusion (e.g. over serial numbers or revocations) an AC 975 issuer MUST NOT also be a PKC Issuer (i.e. it can't be a CA as 976 well), so the AC Issuer's PKC MUST NOT have a basicConstraints 977 extension with isACA set to TRUE. 979 5. Attribute Certificate Validation 981 This section describes a basic set of rules that all "valid" ACs 982 MUST satisfy. Some additional checks are also described which AC 983 verifiers MAY choose to implement. 985 To be valid an AC MUST satisfy all of the following: 987 1. The AC signature must be cryptographically correct and the AC 988 issuer's entire certification path (including the AC issuer's 989 PKC) MUST be verified in accordance with [PKIXPROF]. 990 2. The AC issuer's PKC MUST also conform to the profile specified 991 in section 4.5 above. 992 3. The AC issuer MUST be directly trusted as an AC issuer (by 993 configuration or otherwise). 994 4. The time for which the AC is being evaluated MUST be within the 995 AC validity (if the evaluation time is equal to either 996 notBeforeTime or notAfterTime then the AC is timely, i.e. this 997 check succeeds). Note that in some applications, the evaluation 998 time MAY not be the same as the current time. 999 5. The AC targeting check MUST pass (see section 4.3.2 above) 1000 6. If the AC contains any "unsupported" critical extensions then 1001 the AC MUST be rejected. 1003 "Support" for an extension in this context means: 1005 a. the AC verifier MUST be able to parse the extension value, and, 1006 b. where the extension value SHOULD cause the AC to be rejected, the 1007 AC verifier MUST reject the AC. 1009 Additional Checks: 1011 1. The AC MAY be rejected on the basis of further AC verifier 1012 configuration, for example an AC verifier may be configured to 1013 reject ACs which contain or lack certain attribute types. 1014 2. If the AC verifier provides an interface that allows 1015 applications to query the contents of the AC, then the AC 1016 verifier MAY filter the attributes from the AC on the basis of 1017 configured information, e.g. an AC verifier might be configured 1018 not to return certain attributes to certain targets. 1020 6. Revocation 1022 In many environments, the validity period of an AC is less than the 1023 time required to issue and distribute revocation information. 1024 Therefore, short-lived ACs typically do not require revocation 1025 support. However, long-lived ACs and environments where ACs enable 1026 high value transactions MAY require revocation support. 1028 The basic approach taken is to allow use of the following AC 1029 revocation related schemes. 1031 "Never revoke" scheme: ACs may be marked so that the relying party 1032 understands that no revocation status information will be made 1033 available. A noRevAvail extension as defined in section 4.3.6 above 1034 MUST be present in the AC to indicate this. 1036 Where no noRevAvail is not present, then the AC issuer is implicitly 1037 stating that revocation status checks are supported and some method 1038 MUST be provided to allow AC verifiers to establish the revocation 1039 status of the AC. 1041 "Pointer in AC" scheme: ACs may be marked (like PKCs) to "point" to 1042 sources of revocation status information (using an 1043 authorityInfoAccess or crlDistributionPoints extension in the AC 1044 itself). 1046 For AC users, the "never revoke" scheme MUST be supported, the 1047 "pointer in AC" scheme SHOULD be supported. If only the "never 1048 revoke" scheme is supported, then all ACs that do not contain a 1049 noRevAvail extension, MUST be rejected. 1051 For AC issuers, the "never revoke" scheme MUST be supported. If all 1052 ACs that will ever be issued by that AC issuer, will contain a 1053 noRevAvail extension, then the "pointer in AC" scheme NEED NOT be 1054 supported. If any AC can be issued that does not contain the 1055 noRevAvail extension, then the "pointer in AC" scheme MUST be 1056 supported. 1058 All conformant ACs MUST contain exactly one of the noRevAvail, 1059 authorityInformationAccess or crlDistributionPoints extensions. That 1060 is, the crlDistributionPoints, authorityInformationAccess and 1061 noRevAvail extensions are mutually exclusive for a single AC and an 1062 AC MUST NOT contain more than one of these extensions. This differs 1063 from the case with PKCs. An AC verifier MAY use other (e.g. 1064 configured) sources for AC revocation status information. 1066 7. Optional Features 1068 This section specifies features that MAY be implemented. Conformance 1069 to this specification does NOT require support for these features. 1071 7.1 Attribute Encryption 1073 Where an AC will be carried in clear within an application protocol 1074 or where an AC contains some sensitive information (e.g. a legacy 1075 application username/password) then encryption of AC attributes MAY 1076 be needed. 1078 When a set of attributes are to be encrypted within an AC, the 1079 cryptographic message syntax, EnvelopedData structure [CMS] is used 1080 to carry the ciphertext(s) and associated per-recipient keying 1081 information. 1083 This type of attribute encryption is targeted, which means that 1084 before the AC is signed the attributes have been encrypted for a set 1085 of predetermined recipients. 1087 The AC then contains the ciphertext(s) inside its signed data. The 1088 "enveloped-data" (id-envelopedData) ContentType is used and the 1089 content field will contain the EnvelopedData type. 1091 The set of ciphertexts is included into the AC as the value of an 1092 encrypted attributes attribute. Only one encrypted attributes 1093 attribute can be present in an AC - however it MAY be multi-valued 1094 and each of its values will contain an EnvelopedData. 1096 Each value can contain a set of attributes (each possibly a multi- 1097 valued attribute) encrypted for a set of recipients. 1099 The cleartext that is encrypted has the type: 1101 ACClearAttrs ::= SEQUENCE { 1102 acIssuer GeneralName, 1103 acSerial INTEGER, 1104 attrs SEQUENCE OF Attribute 1105 } 1107 The DER encoding of the ACClearAttrs structure is used as the 1108 encryptedContent field of the EnvelopedData, i.e. the DER encoding 1109 MUST be embedded in an OCTET STRING. 1111 The acIssuer and acSerial fields are present to prevent ciphertext 1112 stealing - when an AC verifier has successfully decrypted an 1113 encrypted attribute it MUST then check that the AC issuer and 1114 serialNumber fields contain the same values. This prevents a 1115 malicious AC issuer from copying ciphertext from another AC issuer's 1116 AC into an AC issued by the malicious AC issuer. 1118 The procedure for an AC issuer when encrypting attributes is 1119 illustrated by the following (any other procedure that gives the 1120 same result MAY be used): 1122 1. Identify the sets of attributes that are to be encrypted for 1123 each set of recipients. 1124 2. For each attribute set which is to be encrypted: 1125 2.1. Create an EnvelopedData structure for the data for this 1126 set of recipients. 1127 2.2. Encode the EnvelopedData as a value of the 1128 EncryptedAttributes attribute 1129 2.3. Ensure the cleartext attribute(s) are not present in the 1130 to-be-signed AC 1131 3. Add the EncryptedAttribute (with its multiple values) to the 1132 AC 1134 Note that the rule that each attribute type (the OID) only occurs 1135 once may not hold after decryption. That is, an AC MAY contain the 1136 same attribute type both in clear and in encrypted form (and indeed 1137 more than once if the decryptor is a recipient for more than one 1138 EnvelopedData). One approach implementers may choose, would be to 1139 merge attributes values following decryption in order to re- 1140 establish the "once only" constraint. 1142 name id-aca-encAttrs 1143 OID { id-aca 6} 1144 Syntax ContentInfo 1145 values Multiple Allowed 1147 If an AC contains attributes apparently encrypted for the AC 1148 verifier then the decryption process MUST not fail - if decryption 1149 fails then the AC MUST be rejected. 1151 7.2 Proxying 1153 In some circumstances, a server needs to proxy an AC when it acts as 1154 a client (for another server) on behalf of the AC holder. Such 1155 proxying may have to be under the AC issuer's control, so that not 1156 every AC is proxiable and so that a given proxiable AC can be 1157 proxied in a targeted fashion. Support for chains of proxies (with 1158 more than one intermediate server) is also sometimes required. Note 1159 that this does not involve a chain of ACs. 1161 In order to meet this requirement we define another extension, 1162 ProxyInfo, similar to the targeting extension. 1164 When this extension is present the AC verifier must check that the 1165 entity from which the AC was received was allowed to send it and 1166 that the AC is allowed to be used by this verifier. 1168 The proxying information consists of a set of proxy information, 1169 each of which is a set of targeting information. If the verifier and 1170 the sender of the AC are both named in the same proxy set then the 1171 AC can be accepted (the exact rule is given below). 1173 The effect is that the AC holder can send the AC to any valid target 1174 which can then only proxy to targets which are in one of the same 1175 "proxy sets" as itself. 1177 The following data structure is used to represent the 1178 targeting/proxying information. 1180 ProxyInfo ::= SEQUENCE OF Targets 1182 As in the case of targeting, the targetCertificate and targetDigest 1183 fields MUST NOT be used. 1185 A proxy check succeeds if either one of the conditions below is met: 1187 1. 1188 The identity of the sender as established by the underlying 1189 authentication service matches the holder field of the AC, and, 1190 the current server "matches" any one of the proxy sets (where 1191 "matches" is as defined for the targeting check in section 4.3.2 1192 above). 1194 2. 1195 The identity of the sender as established by the underlying 1196 authentication service "matches" one of the proxy sets (call it 1197 set "A"), and, the current server is one of the targetName fields 1198 in the set "A", or, the current server is a member of one of the 1199 targetGroup fields in set "A". 1201 Where an AC is proxied more than once a number of targets will be on 1202 the path from the original client, which is normally, but not 1203 always, the AC holder. In such cases prevention of AC "stealing" 1204 requires that the AC verifier MUST check that all targets on the 1205 path are members of the same proxy set. It is the responsibility of 1206 the AC using protocol to ensure that a trustworthy list of targets 1207 on the path is available to the AC verifier. 1209 name id-pe-ac-proxying 1210 OID { id-pe 7 } 1211 syntax ProxyInfo 1212 criticality MUST be TRUE 1214 7.3 Use of ObjectDigestInfo 1216 In some environments it may be required that the AC is not linked 1217 either to an identity (via entityName) or to a PKC (via 1218 baseCertificateID). The objectDigestInfo choice in the holder field 1219 allows support for this requirement. 1221 If the holder is identified via the objectDigestInfo field then the 1222 AC version field MUST contain v2 (i.e. the integer 1). 1224 The basic idea is to link the AC to an object by placing a hash of 1225 that object into the holder field of the AC. For example, this 1226 allows production of ACs that are linked to public keys rather than 1227 names, or production of ACs which contain privileges associated with 1228 an executable object (e.g. a Java class). 1230 However, this profile only specifies how to use a hash over a public 1231 key or PKC, that is, conformant ACs MUST NOT use the 1232 otherObjectTypes value for the digestedObjectType. 1234 In order to link an AC to a public key the hash must be calculated 1235 over the representation of that public key which would be present in 1236 a PKC, specifically, the input for the hash algorithm MUST be the 1237 DER encoding of a SubjectPublicKeyInfo representation of the key. 1238 Note: This includes the AlgorithmIdentifier as well as the BIT 1239 STRING. The rules given in [PKIXPROF] and [ECDSA] for encoding keys 1240 MUST be followed. In this case the digestedObjectType MUST be 1241 publicKey and the otherObjectTypeID field MUST NOT be present. 1243 Note that if the public key value used as input to the hash function 1244 has been extracted from a PKC, then it is possible that the 1245 SubjectPublicKeyInfo from that PKC is NOT the value which should be 1246 hashed. This can occur if, e.g. DSA Dss-parms are inherited as 1247 described in section 7.3.3 of [PKIXPROF]. The correct input for 1248 hashing in this context will include the value of the parameters 1249 inherited from the CA's PKC, and thus may differ from the 1250 SubjectPublicKeyInfo present in the PKC. 1252 Implementations which support this feature MUST be able to handle 1253 the representations of keys for the algorithms specified in section 1254 7.3 of [PKIXPROF] and those specified in [ECDSA]. In this case the 1255 digestedObjectType MUST be publicKey and the otherObjectTypeID field 1256 MUST NOT be present. 1258 In order to link an AC to a PKC via a digest, the digest MUST be 1259 calculated over the DER encoding of the entire PKC (i.e. including 1260 the signature bits). In this case the digestedObjectType MUST be 1261 publicKeyCert and the otherObjectTypeID field MUST NOT be present. 1263 7.4 AA Controls 1265 During AC validation a relying party has to answer the question: "is 1266 this AC issuer trusted to issue ACs containing this attribute?" The 1267 AAControls PKC extension, intended to be used in CA and AC Issuer 1268 PKCs, MAY be used to help answer the question. 1270 Note that this extension is quite likely to change in future based 1271 on experience with the use of ACs in the Internet. 1273 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1275 AAControls ::= SEQUENCE { 1276 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1277 permittedAttrs [0] AttrSpec OPTIONAL, 1278 excludedAttrs [1] AttrSpec OPTIONAL, 1279 permitUnSpecified BOOLEAN DEFAULT TRUE 1280 } 1281 AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER 1283 The aaControls extension is used as follows: 1285 The pathLenConstraint, if present, is interpreted as in [PKIXPROF], 1286 but now restricts the allowed "distance" between the AA CA, (a CA 1287 directly trusted to include AAControls in its PKCs), and the AC 1288 issuer. 1290 The permittedAttrs field specifies a set of attribute types that any 1291 AC issuer below this AA CA is allowed to include in ACs. If this 1292 field is not present, it means that no attribute types are 1293 explicitly allowed (though the permitUnSpecified field may open 1294 things up). 1296 The excludedAttrs field specifies a set of attribute types that no 1297 AC issuer is allowed to include in ACs. If this field is not 1298 present, it means that no attribute types are explicitly disallowed 1299 (though the permitUnSpecified field may close things down). 1301 The permitUnSpecified field specifies how to handle attribute types 1302 which are not present in either the permittedAttrs or excludedAttrs 1303 fields. TRUE (the default) means that any unspecified attribute type 1304 is allowed in ACs; FALSE means that no unspecified attribute type is 1305 allowed. 1307 Where aaControls are used then the following additional checks on an 1308 AA's PKC chain MUST all succeed for the AC to be valid: 1310 1. Some CA on the AC's certificate path MUST be directly trusted 1311 to issue PKCs which precede the AC issuer in the certification 1312 path, call this CA the "AA CA". 1313 2. All PKC's on the path from the AA CA down to and including the 1314 AC issuer's PKC MUST contain an aaControls extension as defined 1315 below (the PKC with the AA CA's as subject need not contain 1316 this extension). 1317 3. Only those attributes in the AC which are allowed according to 1318 all of the aaControls extension values in all of the PKCs from 1319 the AA CA to the AC issuer, may be used for authorization 1320 decisions, all other attributes MUST be ignored (note that this 1321 check MUST be applied to the set of attributes following 1322 attribute decryption and that in such cases the id-aca-encAttrs 1323 type MUST also be checked). 1325 name id-pe-aaControls 1326 OID { id-pe 6 } 1327 syntax AAControls 1328 criticality MAY be TRUE 1330 8. Security Considerations 1332 Implementers MUST ensure that following validation of an AC, only 1333 attributes that the issuer is trusted to issue are used in 1334 authorization decisions. Other attributes, which MAY be present MUST 1335 be ignored. Given that the AA controls PKC extension is optional to 1336 implement, this means that AC verifiers MUST be provided with the 1337 required information by other means - e.g. by configuration. This 1338 becomes very important if an AC verified trusts more than one AC 1339 issuer. 1341 There is often a requirement to map between the authentication 1342 supplied by a particular protocol (e.g. TLS, S/MIME) and the AC 1343 holder's identity. If the authentication uses PKCs then this mapping 1344 is straightforward. However, it is envisaged that ACs will also be 1345 used in environments where the holder may be authenticated using 1346 other means. Implementers SHOULD be very careful in mapping the 1347 authenticated identity to the AC holder. 1349 9. References 1351 [CMC] Myers, M., et al. "Certificate Management Messages over 1352 CMS", draft-ietf-pkix-cmc-05.txt, July 1999. 1353 [CMP] Adams, C., Farrell, S., "Internet X.509 Public Key 1354 Infrastructure - Certificate Management Protocols", 1355 RFC2510. 1356 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630. 1357 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 1358 RFC2634. 1359 [ECDSA] D. Johnson, W. Polk, "Internet X.509 Public Key 1360 Infrastructure Representation of Elliptic Curve Digital 1361 Signature Algorithm (ECDSA) Keys and Signatures in 1362 Internet X.509 Public Key Infrastructure Certificates" 1363 draft-ietf-pkix-ipki-ecdsa-02.txt, October 1999. 1364 [LDAP] Wahl, M., et al., "Lightweight Directory Access Protocol 1365 (v3)", RFC 2251. 1366 [KRB] Kohl, J., Neuman, C., "The Kerberos Network 1367 Authentication Service (V5)", RFC 1510. 1368 [PKINIT] Tung, B., et al., "Public Key Cryptography for Initial 1369 Authentication in Kerberos", draft-ietf-cat-kerberos-pk- 1370 init-10.txt 1371 [PKIXPROF] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet 1372 Public Key Infrastructure - X.509 Certificate and CRL 1373 profile",RFC 2459. 1374 [OCSP] Myers, M., et al., " X.509 Internet Public Key 1375 Infrastructure - Online Certificate Status Protocol - 1376 OCSP", RFC 2560. 1377 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1378 3", RFC 2026, BCP 9, October 1996. 1379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1380 Requirement Levels", RFC 2119. 1381 [X.501] ITU-T Recommendation X.501 : Information Technology - 1382 Open Systems Interconnection - The Directory: Models, 1383 1993. 1384 [X.208-88] CCITT Recommendation X.208: Specification of Abstract 1385 Syntax Notation One (ASN.1). 1988. 1386 [X.209-88] CCITT Recommendation X.209: Specification of Basic 1387 Encoding Rules for Abstract Syntax Notation One (ASN.1). 1388 1988. 1389 [X.501-88] CCITT Recommendation X.501: The Directory - Models. 1390 1988. 1391 [X.509-88] CCITT Recommendation X.509: The Directory - 1392 Authentication Framework. 1988. 1393 [X.509-97] ITU-T Recommendation X.509: The Directory - 1394 Authentication Framework. 1997. 1395 [X.509-DAM] ISO 9594-8 Information Technology - Open systems 1396 Interconnection - The Directory: Authentication 1397 Framework - Draft Amendment 1: Certificate Extensions, 1398 October 1999. 1400 Author's Addresses 1402 Stephen Farrell, 1403 Baltimore Technologies 1404 61/62 Fitzwilliam Lane, 1405 Dublin 2, 1406 IRELAND 1408 tel: +353-1-647-3000 1409 email: stephen.farrell@baltimore.ie 1411 Russell Housley, 1412 SPYRUS, 1413 381 Elden Street, 1414 Suite 1120, 1415 Herndon, VA 20170, 1416 USA 1418 email: housley@spyrus.com 1420 Full Copyright Statement 1422 Copyright (C) The Internet Society (date). All Rights Reserved. 1424 This document and translations of it may be copied and furnished to 1425 others, and derivative works that comment on or otherwise explain it 1426 or assist in its implementation may be prepared, copied, published 1427 and distributed, in whole or in part, without restriction of any 1428 kind, provided that the above copyright notice and this paragraph 1429 are included on all such copies and derivative works. In addition, 1430 the ASN.1 module presented in Appendix B may be used in whole or in 1431 part without inclusion of the copyright notice. However, this 1432 document itself may not be modified in any way, such as by removing 1433 the copyright notice or references to the Internet Society or other 1434 Internet organizations, except as needed for the purpose of 1435 developing Internet standards in which case the procedures for 1436 copyrights defined in the Internet Standards process shall be 1437 followed, or as required to translate it into languages other than 1438 English. 1440 The limited permissions granted above are perpetual and will not be 1441 revoked by the Internet Society or its successors or assigns. This 1442 document and the information contained herein is provided on an "AS 1443 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1444 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1445 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1446 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1447 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1449 Appendix B: Object Identifiers 1451 This (normative) appendix lists the new object identifiers which are 1452 defined in this specification. Some of these are required only for 1453 support of optional features and are not required for conformance to 1454 this profile. 1456 This specification mandates support for OIDs which have arc elements 1457 with values that are less than 2^28, i.e. they MUST be between 0 and 1458 268,435,455 inclusive. This allows each arc element to be 1459 represented within a single 32 bit word. Implementations MUST also 1460 support OIDs where the length of the dotted decimal (see [LDAP], 1461 section 4.1.2) string representation can be up to 100 bytes 1462 (inclusive). Implementations MUST be able to handle OIDs with up to 1463 20 elements (inclusive). AA's SHOULD NOT issue ACs which contain 1464 OIDs that breach these requirements. 1466 The following OIDs are imported from [PKIXPROF]: 1468 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 1469 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 1470 id-mod OBJECT IDENTIFIER ::= { id-pkix 0 } 1471 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 1472 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 1474 The following new ASN.1 module OID is defined: 1476 id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 } 1478 The following AC extension OIDs are defined: 1480 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1481 id-pe-ac-targeting OBJECT IDENTIFIER ::= { id-pe 5 } 1482 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 7 } 1484 The following PKC extension OIDs are defined: 1486 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1488 The following attribute OIDs are defined: 1490 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1491 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1492 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1493 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1494 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1495 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1497 Appendix B: "Compilable" ASN.1 Module 1499 PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) 1500 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1501 id-mod-attribute-cert(12)} 1503 DEFINITIONS EXPLICIT TAGS ::= 1505 BEGIN 1507 -- EXPORTS ALL -- 1509 IMPORTS 1511 -- PKIX Certificate Extensions 1512 Attribute, AlgorithmIdentifier, CertificateSerialNumber, 1513 Extensions, UniqueIdentifier, 1514 id-pkix, id-pe, id-kp, id-ad 1515 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 1516 dod(6) internet(1) security(5) mechanisms(5) 1517 pkix(7) id-mod(0) id-pkix1-explicit-88(1)} 1519 GeneralName, GeneralNames 1520 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 1521 dod(6) internet(1) security(5) mechanisms(5) 1522 pkix(7) id-mod(0) id-pkix1-implicit-88(2)} ; 1524 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1525 id-pe-ac-targeting OBJECT IDENTIFIER ::= { id-pe 5 } 1526 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1527 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 7 } 1529 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1531 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1532 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1533 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1534 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1535 -- { id-aca 5 } is reserved 1536 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1538 AttributeCertificate ::= SEQUENCE { 1539 acinfo AttributeCertificateInfo, 1540 signatureAlgorithm AlgorithmIdentifier, 1541 signatureValue BIT STRING 1542 } 1544 AttributeCertificateInfo ::= SEQUENCE { 1545 version AttCertVersion DEFAULT v1, 1546 holder Holder, 1547 issuer AttCertIssuer, 1548 signature AlgorithmIdentifier, 1549 serialNumber CertificateSerialNumber, 1550 attrCertValidityPeriod AttCertValidityPeriod, 1551 attributes SEQUENCE OF Attribute, 1552 issuerUniqueID UniqueIdentifier OPTIONAL, 1553 extensions Extensions OPTIONAL 1554 } 1556 AttCertVersion ::= INTEGER {v1(0), v2(1) } 1558 Holder ::= SEQUENCE { 1559 baseCertificateID [0] IssuerSerial OPTIONAL, 1560 -- the issuer and serial number of 1561 -- the holder's Public Key Certificate 1562 entityName [1] GeneralNames OPTIONAL, 1563 -- the name of the claimant or role 1564 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 1565 -- if present, version must be v2 1566 } 1568 ObjectDigestInfo ::= SEQUENCE { 1569 digestedObjectType ENUMERATED { 1570 publicKey (0), 1571 publicKeyCert (1), 1572 otherObjectTypes (2) }, 1573 -- otherObjectTypes MUST NOT 1574 -- MUST NOT be used in this profile 1575 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 1576 digestAlgorithm AlgorithmIdentifier, 1577 objectDigest BIT STRING 1578 } 1580 AttCertIssuer ::= CHOICE { 1581 oldForm GeneralNames, 1582 newForm [0] SEQUENCE { 1583 issuerName GeneralNames OPTIONAL, 1584 baseCertificateId [0] IssuerSerial OPTIONAL, 1585 objectDigestInfo [1] ObjectDigestInfo OPTIONAL 1586 -- at least one of issuerName, baseCertificateId or -- 1587 -- objectDigestInfo must be present -- 1588 -- if newForm is used, version must be v2-- 1589 } 1591 IssuerSerial ::= SEQUENCE { 1592 issuer GeneralNames, 1593 serial CertificateSerialNumber, 1594 issuerUID UniqueIdentifier OPTIONAL 1595 } 1597 AttCertValidityPeriod ::= SEQUENCE { 1598 notBeforeTime GeneralizedTime, 1599 notAfterTime GeneralizedTime 1600 } 1602 Targets ::= SEQUENCE OF Target 1604 Target ::= CHOICE { 1605 targetName [0] GeneralName, 1606 targetGroup [1] GeneralName, 1607 targetCertificate [2] IssuerSerial, 1608 targetDigest [3] ObjectDigestInfo 1609 } 1611 IetfAttrSyntax ::= SEQUENCE { 1612 policyAuthority[0] GeneralNames OPTIONAL, 1613 values SEQUENCE OF CHOICE { 1614 octets OCTET STRING, 1615 oid OBJECT IDENTIFIER, 1616 string UTF8String 1617 } 1618 } 1620 SvceAuthInfo ::= SEQUENCE { 1621 service GeneralName, 1622 ident GeneralName, 1623 authInfo OCTET STRING OPTIONAL 1624 } 1626 Clearance ::= SEQUENCE { 1627 policyId OBJECT IDENTIFIER, 1628 classList ClassList DEFAULT {unclassified}, 1629 securityCategories 1630 SET OF SecurityCategory OPTIONAL 1631 } 1633 ClassList ::= BIT STRING { 1634 unmarked (0), 1635 unclassified (1), 1636 restricted (2), 1637 confidential (3), 1638 secret (4), 1639 topSecret (5) 1640 } 1642 SecurityCategory ::= SEQUENCE { 1643 type [0] IMPLICIT OBJECT IDENTIFIER, 1644 value [1] ANY DEFINED BY type 1645 } 1647 AAControls ::= SEQUENCE { 1648 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1649 permittedAttrs [0] AttrSpec OPTIONAL, 1650 excludedAttrs [1] AttrSpec OPTIONAL, 1651 permitUnSpecified BOOLEAN DEFAULT TRUE 1652 } 1654 AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER 1655 ACClearAttrs ::= SEQUENCE { 1656 acIssuer GeneralName, 1657 acSerial INTEGER, 1658 attrs SEQUENCE OF Attribute 1659 } 1661 ProxyInfo ::= SEQUENCE OF Targets 1663 END 1665 Appendix C: Changes History 1667 <> 1669 This appendix lists major changes since the previous revision. 1671 Major changes since last revision: 1673 Changes from -01 to -02 1675 1. Re-Synchronized with X.509 DAM 1676 2. Deleted AC chains concept 1677 3. Moved AAControls to "optional features" section 1678 4. Samples will be a separate draft 1679 5. Revocation: now using X.509 DAM (noRevAvail) and standard 2459 1680 mechanisms only 1681 6. Deleted the special wildcard target "ALL" 1683 Changes from -00 to -01 1685 1. Re-structured conformance to profile + options as per Oslo 1686 consensus 1687 2. Moved acquisition protocol (LAAP)_to separate I-D 1688 3. Removed restrictions entirely 1689 4. Added new AC revocation options 1690 5. Added optional support for use of objectDigestInfo for keys 1691 6. Added optional support for chains of ACs 1692 7. Changed some syntax: 1693 Added UTF8String to IetfAttrSyntax value choice 1694 Split target & proxy extensions, removed owner from proxyInfo 1695 8. Allocated PKIX OIDs (note: check with repository before using 1696 these, the PKIX arc is currently available at 1697 http://www.imc.org/ietf-pkix/pkix-oid.asn) 1698 9. Added compiled ASN.1 module