idnits 2.17.1 draft-ietf-pkix-ac509prof-01.txt: -(814): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 are 2 instances 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 30 longer pages, the longest (page 3) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 32 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. 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 250 has weird spacing: '...erifier any ...' == Line 644 has weird spacing: '...icality mus...' == Line 695 has weird spacing: '...icality mus...' == Line 1231 has weird spacing: '...call it set ...' == Line 1253 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). == 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 (October 1999) is 8952 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 1600 -- Looks like a reference, but probably isn't: '1' on line 1601 -- Looks like a reference, but probably isn't: '2' on line 1530 == Unused Reference: 'CMC' is defined on line 1360, but no explicit reference was found in the text == Unused Reference: 'CMP' is defined on line 1363, but no explicit reference was found in the text == Unused Reference: 'ESS' is defined on line 1368, but no explicit reference was found in the text == Unused Reference: 'FPDAM' is defined on line 1403, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-pkix-cmc-03 ** Obsolete normative reference: RFC 2510 (ref. 'CMP') (Obsoleted by RFC 4210) == Outdated reference: A later version (-13) exists of draft-ietf-smime-cms-12 == Outdated reference: A later version (-02) exists of draft-ietf-pkix-ipki-ecdsa-01 -- Possible downref: Normative reference to a draft: ref. 'ECDSA' ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) -- Possible downref: Non-RFC (?) normative reference: ref. 'FPDAM' Summary: 8 errors (**), 0 flaws (~~), 18 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PKIX Working Group S. Farrell 2 INTERNET-DRAFT Baltimore Technologies 3 Expires in six months R. Housley 4 SPYRUS 5 October 1999 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 <> 33 Abstract 35 Authorization services are required for numerous Internet protocols, 36 including TLS, IPSec, and S/MIME. The X.509 Attribute Certificate 37 provides a structure that can form the basis for such services 38 [X.509]. This specification defines a profile for the use of X.509 39 Attribute Certificates to provide authorization services for 40 Internet protocols. Some optional features are also specified which 41 are not required for conformance to the base profile. 43 Table of Contents 45 Status of this Memo.............................................1 46 Abstract........................................................1 47 Table of Contents...............................................1 48 1. Introduction.................................................3 49 2. Terminology..................................................5 50 3. Requirements.................................................6 51 4. The AC Profile...............................................7 52 4.1 X.509 Attribute Certificate Definition.................7 53 4.2 Object Identifiers.....................................8 54 4.3 Profile of Standard Fields.............................9 55 4.3.1 version..........................................9 56 4.3.2 owner...........................................10 57 4.3.3 issuer..........................................10 58 4.3.4 signature.......................................10 59 4.3.5 serialNumber....................................11 60 4.3.6 attrCertValidityPeriod..........................11 61 4.3.7 attributes......................................12 62 4.3.8 issuerUniqueID..................................12 63 4.3.9 extensions......................................12 64 4.4 Extensions............................................12 65 4.4.1 Audit Identity..................................12 66 4.4.2 AC Targeting....................................13 67 4.4.3 authorityKeyIdentifier..........................14 68 4.4.4 authorityInformationAccess......................14 69 4.4.5 crlDistributionPoints...........................15 70 4.5 Attribute Types.......................................15 71 4.5.1 Service Authentication Info.....................16 72 4.5.2 Access Identity.................................16 73 4.5.3 Charging Identity...............................16 74 4.5.4 Group...........................................17 75 4.5.5 Role............................................17 76 4.5.6 Clearance.......................................17 77 4.6 PKC Extensions........................................18 78 4.6.1 AAControls......................................18 79 4.7 Profile of AC Issuer's PKC............................19 80 5. Attribute Certificate Validation............................19 81 6. Revocation..................................................21 82 6.1.1 "Never revoke" method...........................21 83 6.1.2 "Pointer from above" method.....................22 84 6.1.3 "Pointer in AC" method..........................22 85 7. Optional Features...........................................22 86 7.1 Attribute Encryption..................................22 87 7.2 Proxying..............................................23 88 7.3 Use of ObjectDigestInfo...............................25 89 7.4 AC Chaining...........................................26 90 8. Security Considerations.....................................27 91 9. References..................................................27 92 Author's Addresses.............................................28 93 Full Copyright Statement.......................................28 94 Appendix A: "Compilable" ASN.1 Module..........................29 95 Appendix B: Samples............................................32 96 Appendix C: Changes this version / Open Issues.................32 98 1. Introduction 100 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 101 in this document are to be interpreted as described in [RFC2119]. 103 A server makes an access control decision when a client requests 104 access to a resource offered by that server. The server must ensure 105 that the client is authorized to access that resource. The server 106 decision is based on the access control policy, the context of the 107 request, and the identity and authorizations of the client. The 108 access control policy and the context of the request are readily 109 available to the server. Certificates may be used to provide 110 identity and authorization information about the client. 112 Similar access control decisions are made in other network 113 environments, such as a store-and-forward electronic mail 114 environment. That is, access control decisions are not limited to 115 client-server protocol environments. 117 X.509 public key certificates (PKCs) [X.509],[RFC2459] bind an 118 identity and a public key. The identity may be used to support 119 identity-based access control decisions after the client proves that 120 it has access to the private key that corresponds to the public key 121 contained in the PKC. The public key is used to validate digital 122 signatures or cryptographic key management operations. However, not 123 all access control decisions are identity-based. Rule-based, role- 124 based, and rank-based access control decisions require additional 125 information. For example, information about a client's ability to 126 pay for a resource access may be more important than the client's 127 identity. Authorization information to support such access control 128 decisions may be placed in a PKC extension or placed in a separate 129 attribute certificate (AC). 131 The placement of authorization information in PKCs is usually 132 undesirable for two reasons. First, authorization information does 133 not have the same lifetime as the binding of the identity and the 134 public key. When authorization information is placed in a PKC 135 extension, the general result is the shortening of the PKC useful 136 lifetime. Second, the PKC issuer is not usually authoritative for 137 the authorization information. This results in additional steps for 138 the PKC issuer to obtain authorization information from the 139 authoritative source. 141 For these reasons, it is often better to separate this authorization 142 information from the PKC. Yet, this authorization information also 143 needs to be protected in a fashion similar to a PKC. An attribute 144 certificate (AC) provides this protection, and it is simply a 145 digitally signed (or certified) set of attributes. 147 An AC is a structure similar to a PKC; the main difference being 148 that it contains no public key. An AC may contain attributes that 149 specify group membership, role, security clearance, and other access 150 control information associated with the AC owner. The syntax for the 151 AC is defined in Recommendation X.509 (making the term "X.509 152 certificate" ambiguous). This document specifies a profile of the 153 X.509 AC suitable for use with authorization information within 154 Internet protocols. 156 When making an access control decision based on an AC, an access 157 control decision function may need to ensure that the appropriate AC 158 owner is the entity that has requested access. For example, one way 159 in which the linkage between the request and the AC can be achieved 160 is if the AC has a "pointer" to a PKC for the requester and that PKC 161 has been used to authenticate the access request. 163 As there is often confusion about the difference between PKCs and 164 ACs, an analogy may help. A PKC can be considered to be like a 165 passport: it identifies the owner, tends to last for a long time and 166 should not be trivial to obtain. An AC is more like an entry visa: 167 it is typically issued by a different authority and does not last 168 for as long a time. As acquiring an entry visa typically requires 169 presenting a passport, getting a visa can be a simpler process. 171 In conjunction with authentication services, ACs provide a means to 172 securely provide authorization information to applications. However, 173 there are a number of possible communication paths that an AC may 174 take. 176 In some environments it is suitable for a client to "push" an AC to 177 a server. This means that no new connections between the client and 178 server are required. It also means that no search burden is imposed 179 on servers, which improves performance. 181 In other cases, it is more suitable for a client simply to 182 authenticate to the server and for the server to request ("pull") 183 the client's AC from an AC issuer or a repository. A major benefit 184 of the "pull" model is that it can be implemented without changes to 185 the client or client-server protocol. It is also more suitable for 186 some inter-domain cases where the client's rights should be assigned 187 within the server's domain, rather than within the client's "home" 188 domain. 190 There are a number of possible exchanges that can occur and three 191 entities involved (client, server and AC issuer). In addition the 192 use of a directory service or other repository for AC retrieval MAY 193 be supported. 195 Figure 1 shows an abstract view of the exchanges that may involve 196 ACs. This profile does not specify protocol for these exchanges. 198 +--------------+ 199 | | Server Acquisition 200 | AC Issuer +----------------------------+ 201 | | | 202 +--+-----------+ | 203 | | 204 | Client | 205 | Acquisition | 206 | | 207 +--+-----------+ +--+------------+ 208 | | AC "push" | | 209 | Client +-------------------------+ Server | 210 | | (part of app. protocol) | | 211 +--+-----------+ +--+------------+ 212 | | 213 | Client | Server 214 | Lookup +--------------+ | Lookup 215 | | | | 216 +---------------+ Repository +---------+ 217 | | 218 +--------------+ 220 Figure 1: AC Exchanges 222 The remainder of the document is structured as follows:- 224 Section 2 defines some terminology 225 Section 3 specifies the requirements that this profile is to meet 226 Section 4 contains the profile of the X.509 AC 227 Section 5 specifies rules for AC validation 228 Section 6 specifies rules for AC revocation checks 229 Section 7 specifies optional features which MAY be supported but for 230 which support is not required for conformance to this profile 232 Appendices contain a "compilable" ASN.1 module for this 233 specification, samples and a list of changes and open issues. 235 2. Terminology 237 For simplicity, we use the terms client and server in this 238 specification. This is not intended to indicate that ACs are only to 239 be used in client-server environments, e.g. in the S/MIME v3 240 context, the mail user agent would, by turns, be both "client" and 241 "server" in the sense the terms are used here. 243 Term Meaning 245 AA Attribute Authority, the entity that issues the 246 AC, synonymous in this specification with "AC 247 issuer" 248 AC Attribute Certificate 249 AC user any entity that parses or processes an AC 250 AC verifier any entity that checks the validity of an AC and 251 then makes use of the result 252 AC issuer the entity which signs the AC, synonymous in this 253 specification with "AA" 254 AC owner the entity indicated (perhaps indirectly) in the 255 owner field of the AC 256 Client the entity which is requesting the action for 257 which authorization checks are to be made 258 Proxying In this specification, Proxying is used to mean 259 the situation where an application server acts as 260 an application client on behalf of a user. 261 Proxying here does not mean granting of authority. 262 PKC Public Key Certificate - uses the type ASN.1 263 Certificate defined in X.509 and profiled in RFC 264 2459. This (non-standard) acronym is used in order 265 to avoid confusion about the term "X.509 266 certificate". 267 Server the entity which requires that the authorization 268 checks are made 270 3. Requirements 272 This Attribute Certificate profile meets the following requirements. 274 Time/Validity requirements: 276 1. Support for short-lived or long-lived ACs is required. Typical 277 validity periods might be measured in hours, as opposed to 278 months for X.509 public key certificates. Short validity 279 periods mean that ACs can be useful without a revocation 280 mechanism. 282 Attribute Types: 284 2. Issuers of ACs should be able to define their own attribute 285 types for use within closed domains. 286 3. Some standard attribute types should be defined which can be 287 contained within ACs, for example "access identity", "group", 288 "role", "clearance", "audit identity", "charging id" etc. 289 4. Standard attribute types should be defined so that it is 290 possible for an AC verifier to distinguish between e.g. the 291 "Administrators group" as defined by Baltimore and the 292 "Administrators group" as defined by SPYRUS. 294 Targeting of ACs: 296 5. It should be possible to "target" an AC. This means that a 297 given AC may be "targeted" at one, or a small number of, 298 servers in the sense that a trustworthy non- target will reject 299 the AC for authorization decisions. 301 Push vs. Pull 303 6. ACs should be defined so that they can either be "pushed" by 304 the client to the server, or "pulled" by the server from a 305 repository or other network service (which may be an online AC 306 issuer). 308 4. The AC Profile 310 This section presents a profile for attribute certificates that will 311 foster interoperability. This section is based upon the X.509 312 attribute certificate format defined in [X.509]. The ISO/IEC/ITU 313 documents use the 1993 version of ASN.1; while this document uses 314 the 1988 ASN.1 syntax, the encoded certificate and standard 315 extensions are equivalent. This section also defines private 316 extensions for the Internet community. 318 Attribute certificates may be used in a wide range of applications 319 and environments covering a broad spectrum of interoperability goals 320 and a broader spectrum of operational and assurance requirements. 321 The goal of this document is to establish a common baseline for 322 generic applications requiring broad interoperability and limited 323 special purpose requirements. In particular, the emphasis will be 324 on supporting the use of attribute certificates for informal 325 Internet electronic mail, IPSec, and WWW applications. 327 Conforming implementations MUST support the profile specified in 328 this section. 330 4.1 X.509 Attribute Certificate Definition 332 X.509 contains the definition of an Attribute Certificate given 333 below. Types that are not defined can be found in [RFC2459]. 335 AttributeCertificate ::= SEQUENCE { 336 acinfo AttributeCertificateInfo 337 signatureAlgorithm AlgorithmIdentifier, 338 signatureValue BIT STRING 339 } 341 AttributeCertificateInfo ::= SEQUENCE { 342 version AttCertVersion DEFAULT v1, 343 owner Owner, 344 issuer AttCertIssuer, 345 signature AlgorithmIdentifier, 346 serialNumber CertificateSerialNumber, 347 attrCertValidityPeriod AttCertValidityPeriod 348 attributes SEQUENCE OF Attribute, 349 issuerUniqueID UniqueIdentifier OPTIONAL, 350 extensions Extensions OPTIONAL 351 } 353 AttCertVersion ::= INTEGER {v1(0), v2(1) } 355 Owner ::= SEQUENCE { 356 baseCertificateID [0] IssuerSerial OPTIONAL, 357 -- the issuer and serial number of 358 -- the owner's Public Key Certificate 359 entityName [1] GeneralNames OPTIONAL, 360 -- the name of the claimant or role 361 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 362 -- if present, version must be v2 363 } 365 ObjectDigestInfo ::= SEQUENCE { 366 digestAlgorithm AlgorithmIdentifier, 367 objectDigest OCTET STRING 368 } 370 AttCertIssuer ::= SEQUENCE { 371 issuerName GeneralNames OPTIONAL, 372 baseCertificateId [0] IssuerSerial OPTIONAL 373 } 375 IssuerSerial ::= SEQUENCE { 376 issuer GeneralNames, 377 serial CertificateSerialNumber, 378 issuerUID UniqueIdentifier OPTIONAL 379 } 381 AttCertValidityPeriod ::= SEQUENCE { 382 notBeforeTime GeneralizedTime, 383 notAfterTime GeneralizedTime 384 } 386 4.2 Object Identifiers 388 This section lists the new object identifiers which are defined in 389 this specification. Some of these are required only for support of 390 optional features and are not required for conformance to this 391 profile. 393 The following OIDs are imported from [RFC2459]: 395 id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 396 dod(6) internet(1) security(5) mechanisms(5) pkix(7) } 397 id-mod OBJECT IDENTIFIER ::= { id-pkix 0 } 398 id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } 399 id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } 401 The following new ASN.1 module OID is defined: 403 id-mod-attribute-cert OBJECT IDENTIFIER ::= { id-mod 12 } 405 The following AC extension OIDs are defined: 407 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 408 id-pe-ac-targeting OBJECT IDENTIFIER ::= { id-pe 5 } 409 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 7 } 411 The following registeredID form of name for targets and proxies is 412 defined (see section 4.4.2 below): 414 id-pe-ac-targeting-all OBJECT IDENTIIFIER ::= 415 { id-pe-ac-targeting 1 } 417 The following PKC extension OIDs are defined: 419 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 421 The following attribute OIDs are defined: 423 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 424 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 425 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 426 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 427 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 428 id-aca-role OBJECT IDENTIFIER ::= { id-aca 5 } 429 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 431 The following new access methods for an authorityInfoAccess 432 extension are defined: 434 id-ad-noRevStat OBJECT IDENTIFIER ::= { id-ad 3 } 435 id-ad-acRevStatusLocation OBJECT IDENTIFIER ::= { id-ad 4 } 437 4.3 Profile of Standard Fields 439 For all GeneralName fields in this profile the otherName, 440 x400Address, ediPartyName and registeredID options MUST NOT be used 441 unless otherwise specified (e.g. as in the description of targeting 442 extension). 444 This means that conforming implementations MUST be able to support 445 the dNSName, directoryName, uniformResourceIdentifier and iPAddress 446 fields in all cases where GeneralName is used. The MUST support 447 requirements for each of these fields are as specified in [RFC2459], 448 (mainly in section 4.2.1.7). 450 4.3.1 version 452 This must be the default value of v1, i.e. not present in encoding, 453 except where the owner is identified using the optional 454 objectDigestInfo field, as specified in section 7.3. 456 4.3.2 owner 458 For any protocol where the AC is passed in an authenticated message 459 or session, and where the authentication is based on the use of an 460 X.509 public key certificate (PKC), the owner field SHOULD use the 461 baseCertificateID. 463 With the baseCertificateID option, the owner's PKC serialNumber and 464 issuer MUST be identical to the AC owner field. The PKC issuer MUST 465 have a non-NULL X.500 name which is to be present as the single 466 value of the owner.baseCertificateID.issuer construct in the 467 directoryName field. The owner.baseCertificateID.issuerUID field 468 MUST only be used if the owner's PKC contains an issuerUniqueID 469 field. 471 The above means that the baseCertificateID is only usable with PKC 472 profiles (like RFC2459) which mandate that the PKC issuer field 473 contain a value. 475 If the owner field uses the entityName option and the underlying 476 authentication is based on a PKC, then the entityName MUST be the 477 same as the PKC subject field, or, if the PKC subject is a "NULL" 478 DN, then the entityName field MUST be identical to one of the values 479 of the PKC subjectAltName field extension. Note that [RFC2459] 480 mandates that the subjectAltNames extension be present if the PKC 481 subject is a "NULL" DN. 483 In any other case where the owner field uses the entityName option 484 then only one name SHOULD be present. 486 Implementations conforming to this profile are not required to 487 support the use of the objectDigest field. However, section 7.3 488 specifies how this optional feature MAY be used. 490 Any protocol conforming to this profile SHOULD specify which AC 491 owner option is to be used and how this fits with e.g. peer-entity 492 authentication in the protocol. 494 4.3.3 issuer 496 ACs conforming to this profile MUST use the issuerName choice, which 497 MUST contain one and only one GeneralName, which MUST contain its 498 non-null value in the directoryName field. This means that all AC 499 issuers MUST have non-NULL X.500 names. 501 Part of the reason for the use of the issuerName field is that it 502 allows the AC verifier to be independent of the AC issuer's public 503 key infrastructure. Using the baseCertificateId field to reference 504 the AC issuer would mean that the AC verifier would have such a 505 dependency. 507 4.3.4 signature 508 Contains the algorithm identifier used to validate the AC signature. 510 This MUST be one of the following algorithms defined in [RFC2459] 511 section 7.2: md5WithRSAEncryption, id-dsa-with-sha1 or sha- 512 1WithRSAEncryption, or ecdsa-with-SHA1 defined in [ECDSA] section 513 3.2. 515 id-dsa-with-sha1 MUST be supported by all AC users. The other 516 algorithms SHOULD be supported. 518 4.3.5 serialNumber 520 For any conforming AC, the issuer/serialNumber pair MUST form a 521 unique combination, even if ACs are very short-lived (one second is 522 the shortest possible validity due to the use of GeneralizedTime). 524 AC issuers MUST force the serialNumber to be a positive integer, 525 that is, the topmost bit in the DER encoding of the INTEGER value 526 MUST NOT be a `1'B - this is to be done by adding a leading 527 (leftmost) `00'H octet if necessary. This removes a potential 528 ambiguity in mapping between a string of octets and a serialNumber. 530 Given the uniqueness and timing requirements above serial numbers 531 can be expected to contain long integers, i.e. AC users MUST be able 532 to handle more than 32 bit integers here. 534 There is no requirement that the serial numbers used by any AC 535 issuer follow any particular ordering, in particular, they need not 536 be monotonically increasing with time. 538 4.3.6 attrCertValidityPeriod 540 The attrCertValidityPeriod (a.k.a. validity) field specifies the 541 period for which the AC issuer expects that the binding between the 542 owner and the attributes fields will be valid. 544 The generalized time type, GeneralizedTime, is a standard ASN.1 type 545 for variable precision representation of time. Optionally, the 546 GeneralizedTime field can include a representation of the time 547 differential between local and Greenwich Mean Time. 549 For the purposes of this profile, GeneralizedTime values MUST be 550 expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., 551 times are YYYYMMDDHHMMSSZ), even where the number of seconds is 552 zero. GeneralizedTime values MUST NOT include fractional seconds. 554 (Note that the above is as specified in [RFC2459], section 555 4.1.2.5.2.) 557 Note that AC users MUST be able to handle the case where an AC is 558 issued, which (at the time of parsing), has its entire validity 559 period in the future (a "post-dated" AC). This is valid for some 560 applications, e.g. backup. 562 4.3.7 attributes 564 The attributes field gives information about the AC owner. When the 565 AC is used for authorization this will often contain a set of 566 privileges. 568 The attributes field contains a SEQUENCE OF Attribute. For a given 569 AC each attribute type in the sequence MUST be unique, that is, only 570 one instance of each attribute type can occur in a single AC. Each 571 instance can however, be multi-valued. 573 AC users MUST be able to handle multiple values for all attribute 574 types. 576 Note that a conforming AC MAY contain an empty SEQUENCE, that is, no 577 attributes at all. <> 581 Some standard attribute types are defined in section 4.5. 583 4.3.8 issuerUniqueID 585 This field MUST NOT be used. 587 4.3.9 extensions 589 The extensions field generally gives information about the AC as 590 opposed to information about the AC owner. 592 Section 4.4 defines the extensions that MAY be used with this 593 profile. An AC that has no extensions conforms to the profile. If 594 any other critical extension is used, then the AC does not conform 595 to this profile. An AC that contains additional non-critical 596 extensions still conforms. 598 4.4 Extensions. 600 4.4.1 Audit Identity 602 In some circumstances it is required (e.g. by data protection/data 603 privacy legislation) that audit trails do not contain records which 604 directly identify individuals. This may make the use of the owner 605 field of the AC unsuitable for use in audit trails. 607 In order to allow for such cases an AC MAY contain an audit identity 608 extension. Ideally it SHOULD be infeasible to derive the AC owner's 609 identity from the audit identity value except with the co-operation 610 of the AC issuer. 612 The value of the audit identity plus the AC issuer/serial should 613 then be used for audit/logging purposes. If the value of the audit 614 identity is suitably chosen then a server/service administrator can 615 track the behavior of an AC owner without being able to identify the 616 AC owner. 618 The server/service administrator in combination with the AC issuer 619 MUST be able to identify the AC owner in cases where misbehavior is 620 detected. This means that the AC issuer MUST be able to map 621 "backwards" from the audit identity to the actual identity of the AC 622 owner. 624 Of course, auditing could be based on the AC issuer/serial pair, 625 however, this method doesn't allow tracking the same AC owner across 626 different ACs. This means that an audit identity is only useful if 627 it lasts for longer than the typical AC lifetime - how much longer 628 is an issue for the AC issuer implementation. Auditing could also be 629 based on the AC owner's PKC issuer/serial however, this will often 630 allow the server/service administrator identify the AC owner. 632 As the AC verifier might otherwise use the AC subject or some other 633 identifying value for audit purposes, this extension MUST be 634 critical when used. 636 Protocols that use ACs will often expose the identity of the AC 637 owner in the bits on-the-wire. In such cases, an "opaque" audit 638 identity does not make use of the AC anonymous, it simply ensures 639 that the ensuing audit trails are "semi-anonymous". 641 name id-pe-ac-auditIdentity 642 OID { id-pe 4 } 643 syntax OCTET STRING 644 criticality must be TRUE 646 4.4.2 AC Targeting 648 In order to allow that an AC is "targeted", the target information 649 extension MAY be used to specify a number of servers/services. The 650 intent is that the AC should only be usable at the specified 651 servers/services - an (honest) AC verifier who is not amongst the 652 named servers/services MUST reject the AC. 654 If this extension is not present then the AC is not targeted and may 655 be accepted by any server. 657 The targeting information simply consists of a list of named targets 658 or groups. 660 The following syntax is used to represent the targeting information: 662 Targets ::= SEQUENCE OF Target 663 Target ::= CHOICE { 664 targetName [0] GeneralName, 665 targetGroup [1] GeneralName 666 } 668 We represent a special target, called "ALL" which is a wildcard as a 669 targetName with the registeredID choice and a value of {id-pe-ac- 670 targeting 1}. This is an exception to the general rule stated above 671 about the use of GeneralName choices. 673 The targets check passes if: 675 the targets field contains one targetName which 676 is the "ALL" value, 677 or, 678 the current server (recipient) is one of the 679 targetName fields in the targets part, 680 or, 681 the current server is a member of one of the 682 targetGroup fields in the targets part. 684 How the membership of a target within a targetGroup is determined is 685 not defined here. It is assumed that any given target "knows" the 686 names of the targetGroup's to which it belongs or can otherwise 687 determine its membership. For example, if the targetGroup were to be 688 a DNS domain and the AC verifier knows the DNS domain to which it 689 belongs or it the targetGroup were "PRINTERS" and the AC verifier 690 "knows" that it's a printer or print server. 692 name id-pe-ac-targeting 693 OID { id-pe 5 } 694 syntax Targets 695 criticality must be TRUE 697 4.4.3 authorityKeyIdentifier 699 The authorityKeyIdentifier extension as profiled in [RFC2459] MAY be 700 used to assist the AC verifier in checking the signature of the AC. 701 The [RFC2459] description should be read as if "CA" meant "AC 702 issuer". As with PKCs this extension SHOULD be included in ACs. 704 name id-ce-authorityKeyIdentifier 705 OID { id-ce 35 } 706 syntax AuthorityKeyIdentifier 707 criticality MUST be FALSE 709 4.4.4 authorityInformationAccess 711 The authorityInformationAccess extension as profiled in [RFC2459] 712 MAY be used to assist the AC verifier in checking the revocation 713 status of the AC. See section 6 on revocation below for details. 715 The following accessMethod is used to indicate that revocation 716 status checking is not provided for this AC: 718 id-ad-noRevStat OBJECT IDENTIFIER ::= 719 { id-ad 3 } 721 The following accessMethod is used to indicate that revocation 722 status checking is provided for this AC, using the OCSP protocol 723 defined in [RFC2560]: 725 id-ad-ocsp OBJECT IDENTIFIER ::= 726 { id-ad 1 } 728 The following accessMethod is used to indicate that revocation 729 status checking is provided "below" this PKC or AC: 731 id-ad-acRevStatusLocation OBJECT IDENTIFIER ::= 732 { id-ad 4 } 734 The accessLocation field MUST contain a NULL directoryName. 736 name id-ce-authorityInfoAccess 737 OID { id-pe 1 } 738 syntax AuthorityInfoAccessSyntax 739 criticality MUST be TRUE 741 4.4.5 crlDistributionPoints 743 The crlDistributionPoints extension as profiled in [RFC2459] MAY be 744 used to assist the AC verifier in checking the revocation status of 745 the AC. See section 6 on revocation below for details. 747 name id-ce-cRLDistributionPoints 748 OID { id-ce 31 } 749 syntax CRLDistPointsSyntax 750 criticality SHOULD be FALSE 752 4.5 Attribute Types 754 Some of the attribute types defined below make use of the 755 IetfAttrSyntax type defined below. The reasons for using this type 756 are: 758 1. It allows a separation between the AC issuer and the attribute 759 policy authority. This is useful for situations where a single 760 policy authority (e.g. an organization) allocates attribute 761 values, but where multiple AC issuers are deployed for 762 performance, network or other reasons. 763 2. The syntaxes allowed for values are restricted to OCTET STRING 764 and OID, which reduces some of the matching complexities 765 associated with GeneralName. All multi-valued attributes using 766 this syntax are restricted so that each value MUST use the same 767 choice of value syntax, that is, it is not allowed that one 768 value use an OID but that a second value uses a string. 770 IetfAttrSyntax ::= SEQUENCE OF SEQUENCE { 771 policyAuthority[0] GeneralNames OPTIONAL, 772 values SEQUENCE OF CHOICE { 773 octets OCTET STRING, 774 oid OBJECT IDENTIFIER, 775 string UTF8String 776 } 777 } 779 4.5.1 Service Authentication Info 781 This attribute type identifies the AC owner to the server/service by 782 a name and with optional authentication information. Typically this 783 will contain a username/password pair for a "legacy" application 784 (and hence MAY need to be encrypted). 786 This attribute type will typically be encrypted if the authInfo 787 field contains sensitive information (e.g. a password). 789 name id-aca-authenticationInfo 790 OID { id-aca 1 } 791 Syntax SvceAuthInfo 792 values: Multiple allowed 794 SvceAuthInfo ::= SEQUENCE { 795 service GeneralName, 796 ident GeneralName, 797 authInfo OCTET STRING OPTIONAL 798 } 800 4.5.2 Access Identity 802 An access identity identifies the AC owner to the server/service. 803 For this attribute the authInfo field MUST NOT be present. 805 name id-aca-accessIdentity 806 OID { id-aca 2 } 807 syntax SvceAuthInfo 808 values: Multiple allowed 810 4.5.3 Charging Identity 812 This attribute type identifies the AC owner for charging purposes. 813 Note that, in general, the charging identity will be different from 814 other identities of the owner, for example, when the owner�s company 815 is to be charged for service. 817 name id-aca-chargingIdentity 818 OID { id-aca 3 } 819 syntax IetfAttrSyntax 820 values: Multiple allowed 822 4.5.4 Group 824 This attribute carries information about group memberships of the AC 825 owner. 827 <> 833 name id-aca-group 834 OID { id-aca 4 } 835 syntax IetfAttrSyntax 836 values: Multiple allowed 838 4.5.5 Role 840 This attribute carries information about role allocations of the AC 841 owner. 843 name id-aca-role 844 OID { id-aca 5 } 845 syntax IetfAttrSyntax 846 values: Multiple allowed 848 4.5.6 Clearance 850 This attribute (imported from [X.501]) carries clearance (security 851 labeling) information about the AC owner. 853 name { id-at-clearance } 854 OID { joint-iso-ccitt(2) ds(5) module(1) selected- 855 attribute-types(5) clearance (55) } 856 syntax Clearance - imported from [X.501] 857 values Multiple allowed 859 Clearance ::= SEQUENCE { 860 policyId OBJECT IDENTIFIER, 861 classList ClassList DEFAULT {unclassified}, 862 securityCategories 863 SET OF SecurityCategory OPTIONAL 864 } 866 ClassList ::= BIT STRING { 867 unmarked (0), 868 unclassified (1), 869 restricted (2) 870 confidential (3), 871 secret (4), 872 topSecret (5) 874 } 876 SecurityCategory ::= SEQUENCE { 877 type [0] IMPLICIT OBJECT IDENTIFIER, 878 value [1] ANY DEFINED BY type 879 } 881 -- original syntax with MACRO 882 -- <> 883 -- SecurityCategory ::= SEQUENCE { 884 -- type [0] IMPLICIT SECURITY-CATEGORY, 885 -- value [1] ANY DEFINED BY type 886 -- } 887 -- 888 -- SECURITY-CATEGORY MACRO ::= 889 -- BEGIN 890 -- TYPE NOTATION ::= type | empty 891 -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 892 -- END 894 4.6 PKC Extensions 896 Public key certificate extensions which assist in AC handling are 897 defined in this section. At the moment only one new extension is 898 defined. 900 4.6.1 AAControls 902 During AC validation a relying party has to answer the question "is 903 this AC issuer trusted to issue ACs containing this attribute"? The 904 AAControls PKC extension, intended to be used in CA and AC Issuer 905 PKCs, MAY be used to help answer the question. The use of AAControls 906 is further described in section 5. 908 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 910 aaControls EXTENSION ::= { 911 SYNTAX AAControls 912 IDENTIFIED BY { id-pe-aaControls} 913 } 914 AAControls ::= SEQUENCE { 915 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 916 permittedAttrs [0] AttrSpec OPTIONAL, 917 excludedAttrs [1] AttrSpec OPTIONAL, 918 permitUnSpecified BOOLEAN DEFAULT TRUE 919 } 920 AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER 922 The aaControls extension is used as follows: 924 The pathLenConstraint if present is interpreted as in [RFC2459], but 925 now restricts the allowed "distance" between the AA CA, (a CA 926 directly trusted to include AAControls in its PKCs), and the AC 927 issuer. 929 The permittedAttrs field specifies a set of attribute types that any 930 AC issuer below this AA CA is allowed to include in ACs. If this 931 field is not present, it means that no attribute types are 932 explicitly allowed (though the permitUnSpecified field may open 933 things up). 935 The excludedAttrs field specifies a set of attribute types that no 936 AC issuer is allowed to include in ACs. If this field is not 937 present, it means that no attribute types are explicitly disallowed 938 (though the permitUnSpecified field may close things down). 940 The permitUnSpecified field specifies how to handle attribute types 941 which are not present in either the permittedAttrs or excludedAttrs 942 fields. TRUE (the default) means that any unspecified attribute type 943 is allowed in ACs; FALSE means that no unspecified attribute type is 944 allowed. 946 4.7 Profile of AC Issuer's PKC 948 The AC Issuer's PKC MUST conform to [RFC2459] and MUST NOT 949 explicitly indicate that the AC issuer can't sign. In order to avoid 950 confusion (e.g. over serial numbers or revocations) an AC issuer 951 MUST NOT also be a PKC Issuer (i.e. it can't be a CA as well), so 952 the AC Issuer's PKC MUST NOT have a basicConstraints extension with 953 isACA set to TRUE. 955 If the AC issuer supports revocation of ACs then the AC issuer's PKC 956 SHOULD contain an authorityInfoAccess extension with a new 957 accessMethod which assists the AC verifier in checking the status of 958 an AC. 960 The new accessMethod is: 962 id-ad-acRevStatusLocation OBJECT IDENTIFIER ::= { id-ad 4} 964 The accessLocation field MUST contain a single GeneralName 965 containing either an X.500 Name or a URL. If accessLocation contains 966 an X.500 Name, then this is the name of a directory entry where a 967 revocation list for ACs issued by this AC issuer should be present 968 as a value of the atributeCertificateRevocationList attribute. If 969 accessLocation contains a URI, then this specifies the transport 970 used for OCSP [RFC2560] requests. The AC issuer MUST, of course, 971 maintain an OCSP responder at this location. 973 Note that in contrast to the use of authorityInfoAccess described in 974 section 4.4.4, in this case the extension is not present in the AC, 975 but rather in the AC issuer's PKC. 977 5. Attribute Certificate Validation 978 This section describes a basic set of rules that all "valid" ACs 979 MUST satisfy. Some additional checks are also described which AC 980 verifiers MAY choose to implement. 982 To be valid an AC MUST satisfy all of the following: 984 1. The AC signature must be cryptographically correct and the AC 985 issuer's PKC MUST be verified in accordance with [RFC2459]. 986 2. The AC issuer's PKC MUST also conform to the profile specified 987 in section 4.7 above. 988 3. If the AC issuer is not directly trusted as an AC issuer (by 989 configuration or otherwise), then the AC issuer's certification 990 path must satisfy the additional PKC checks described below 991 4. The time for which the AC is being evaluated MUST be within the 992 AC validity (if the evaluation time is equal to either 993 notBeforeTime or notAfterTime then the AC is timely, i.e. this 994 check succeeds). Note that in some applications, the evaluation 995 time MAY not be the same as the current time. 996 5. The AC targeting check MUST pass (see section 4.4.3 above) 997 6. If the AC contains any "unsupported" critical extensions then 998 the AC MUST be rejected. 1000 "Support" for an extension in this context means: 1002 a. the AC verifier MUST be able to parse the extension value, and, 1003 b. where the extension value SHOULD cause the AC to be rejected, the 1004 AC verifier MUST reject the AC. 1006 The following additional certification path checks (referred to in 1007 (2) above) MUST all succeed: 1009 1. Some CA on the AC's certificate path MUST be directly trusted 1010 to issue PKCs which precede the AC issuer in the certification 1011 path, call this CA the "AA CA". 1012 2. All PKC's on the path from the AA CA down to and including the 1013 AC issuer's PKC MUST contain an aaControls extension as defined 1014 below (the PKC with the AA CA's as subject need not contain 1015 this extension). 1016 3. Only those attributes in the AC which are allowed according to 1017 all of the aaControls extension values in all of the PKCs from 1018 the AA CA to the AC issuer, may be used for authorization 1019 decisions, all other attributes MUST be ignored (note that this 1020 check MUST be applied to the set of attributes following 1021 attribute decryption and that in such cases the id-aca-encAttrs 1022 type MUST also be checked). 1024 Additional Checks: 1026 1. The AC MAY be rejected on the basis of further AC verifier 1027 configuration, for example an AC verifier may be configured to 1028 reject ACs which contain or lack certain attribute types. 1029 2. If the AC verifier provides an interface that allows 1030 applications to query the contents of the AC, then the AC 1031 verifier MAY filter the attributes from the AC on the basis of 1032 configured information, e.g. an AC verifier might be configured 1033 not to return certain attributes to certain targets. 1035 6. Revocation 1037 <> 1039 In many environments, the validity period of an AC is less than the 1040 time required to issue and distribute revocation information. 1041 Therefore, short-lived ACs typically do not require revocation 1042 support. However, long-lived ACs and environments where ACs enable 1043 high value transactions MAY require revocation support. 1045 The basic approach taken is to allow use of the following AC 1046 revocation related schemes. 1048 "Never revoke" scheme: ACs may be marked so that the relying party 1049 understands that no revocation status information will be made 1050 available. 1052 "Pointer from above" scheme: The PKC (or AC see section 7.4) of an 1053 AC issuer may "point" to sources of revocation status information 1054 for all ACs issued by that AC issuer, (with the exception of those 1055 marked using the never-revoke method above). 1057 "Pointer in AC" scheme: ACs may be marked (like PKCs) to "point" to 1058 sources of revocation status information (using an 1059 authorityInfoAccess or crlDistributionPoints extension in the AC 1060 itself). 1062 The never revoke scheme requires a new authorityInfoAccess 1063 accessMethod. The pointer from above scheme also requires a new 1064 authorityInfoAccess accessMethod. The pointer in AC scheme is as 1065 specified in [RFC2459] and [RFC2560]. 1067 The never revoke scheme MUST be supported, the other schemes SHOULD 1068 be supported. 1070 6.1.1 "Never revoke" method 1072 Where an AC issuer does not support revocation status checks for a 1073 particular AC, then an authority information access extension (id- 1074 pe-authorityInfoAccess) with an id-ad-noRevStat accessMethod as 1075 specified in section 4.4.4 above MUST be present and critical in the 1076 AC to indicate this. 1078 Where no authority information access is present with this 1079 accessMethod, then the AC issuer is implicitly stating that 1080 revocation status checks are supported and one of the other methods 1081 below MUST be provided to allow AC verifiers to establish the 1082 revocation status of the AC. 1084 6.1.2 "Pointer from above" method 1086 In this case the AC issuer's PKC contains an authority information 1087 access extension with an id-ad-acRevStatusLocation accessMethod as 1088 described in section 4.7 above. 1090 6.1.3 "Pointer in AC" method 1092 AC revocation status MAY be checked using the methods described in 1093 [RFC2459], but substituting the AC issuer wherever a CA is 1094 mentioned. 1096 In these cases, the AC contains either an authorityInfoAccess or 1097 crlDistributionPoints extensions as defined in [RFC2459] and 1098 [RFC2560] respectively. 1100 7. Optional Features 1102 This section specifies features that MAY be implemented. Conformance 1103 to this specification does NOT require support for these features. 1105 7.1 Attribute Encryption 1107 Where an AC will be carried in clear within an application protocol 1108 or where an AC contains some sensitive information (e.g. a legacy 1109 application username/password) then encryption of AC attributes MAY 1110 be needed. 1112 When a set of attributes are to be encrypted within an AC, the 1113 cryptographic message syntax, EnvelopedData structure [CMS] is used 1114 to carry the ciphertext(s) and associated per-recipient keying 1115 information. 1117 This type of attribute encryption is targeted, which means that 1118 before the AC is signed the attributes have been encrypted for a set 1119 of predetermined recipients. 1121 The AC then contains the ciphertext(s) inside its signed data. The 1122 "enveloped-data" (id-envelopedData) ContentType is used and the 1123 content field will contain the EnvelopedData type. 1125 The set of ciphertexts is included into the AC as the value of an 1126 encrypted attributes attribute. Only one encrypted attributes 1127 attribute can be present in an AC - however it MAY be multi-valued 1128 and each of its values will contain an EnvelopedData. 1130 Each value can contain a set of attributes (each possibly a multi- 1131 valued attribute) encrypted for a set of recipients. 1133 The cleartext that is encrypted has the type: 1135 ACClearAttrs ::= SEQUENCE { 1136 acIssuer GeneralName, 1137 acSerial INTEGER, 1138 attrs SEQUENCE OF Attribute 1139 } 1141 The DER encoding of the ACClearAttrs structure is used as the 1142 encryptedContent field of the EnvelopedData, i.e. the DER encoding 1143 MUST be embedded in an OCTET STRING. 1145 The acIssuer and acSerial fields are present to prevent ciphertext 1146 stealing - when an AC verifier has successfully decrypted an 1147 encrypted attribute it MUST then check that the AC issuer and 1148 serialNumber fields contain the same values. This prevents a 1149 malicious AC issuer from copying ciphertext from another AC issuer's 1150 AC into an AC issued by the malicious AC issuer. 1152 The procedure for an AC issuer when encrypting attributes is 1153 illustrated by the following (any other procedure that gives the 1154 same result MAY be used): 1156 1. Identify the sets of attributes that are to be encrypted for 1157 each set of recipients. 1158 2. For each attribute set which is to be encrypted: 1159 2.1. Create an EnvelopedData structure for the data for this 1160 set of recipients. 1161 2.2. Encode the EnvelopedData as a value of the 1162 EncryptedAttributes attribute 1163 2.3. Ensure the cleartext attribute(s) are not present in the 1164 to-be-signed AC 1165 3. Add the EncryptedAttribute (with its multiple values) to the 1166 AC 1168 Note that the rule that each attribute type (the OID) only occurs 1169 once may not hold after decryption. That is, an AC MAY contain the 1170 same attribute type both in clear and in encrypted form (and indeed 1171 more than once if the decryptor is a recipient for more than one 1172 EnvelopedData). One approach implementers may choose, would be to 1173 merge attributes values following decryption in order to re- 1174 establish the "once only" constraint. 1176 name id-aca-encAttrs 1177 OID { id-aca 6} 1178 Syntax ContentInfo 1179 values Multiple Allowed 1181 If an AC contains attributes apparently encrypted for the AC 1182 verifier then the decryption process MUST not fail - if decryption 1183 fails then the AC MUST be rejected. 1185 7.2 Proxying 1186 In some circumstances, a server needs to proxy an AC when it acts as 1187 a client (for another server) on behalf of the AC owner. Such 1188 proxying needs to be under the AC issuer's control, so that not 1189 every AC is proxiable and so that a given proxiable AC can be 1190 proxied in a targeted fashion. Support for chains of proxies (with 1191 more than one intermediate server) is also sometimes required. 1193 In order to meet this requirement we define another extension: 1194 ProxyInfo, similar to the targeting extension. 1196 When this extension is present the AC verifier must check that the 1197 entity from which the AC was received was allowed to send it and 1198 that the AC is allowed to be used by this verifier. 1200 The proxying information consists of a set of proxy information, 1201 each of which is a set of targeting information. If the verifier and 1202 the sender of the AC are both named in the same proxy set then the 1203 AC can be accepted (the exact rule is given below). 1205 The effect is that the AC owner can send the AC to any valid target 1206 which can then only proxy to targets which are in one of the same 1207 "proxy sets" as itself. 1209 The following data structure is used to represent the 1210 targeting/proxying information. 1212 ProxyInfo ::= SEQUENCE OF Targets 1214 A proxy check succeeds if 1216 ( 1217 the identity of the sender as established by 1218 the underlying authentication service matches 1219 the owner field of the AC 1220 and 1221 ( 1222 the current server "matches" any one of 1223 the proxy sets (where "matches" is as for 1224 the direct check above) 1225 ) 1226 ) 1227 or 1228 ( 1229 the identity of the sender as established by 1230 the underlying authentication service "matches" 1231 one of the proxy sets (call it set "A") 1232 and 1233 ( 1234 the current server is one of the targetName 1235 fields in the set "A" 1236 or 1237 the current server is a member of one of the 1238 targetGroup fields in set "A". 1239 ) 1240 ) 1242 Where an AC is proxied more than once a number of targets will be on 1243 the path from the original client, which is normally, but not 1244 always, the AC owner. In such cases prevention of AC "stealing" 1245 requires that the AC verifier MUST check that all targets on the 1246 path are members of the same proxy set. It is the responsibility of 1247 the AC using protocol to ensure that a trustworthy list of targets 1248 on the path is available to the AC verifier. 1250 name id-pe-ac-proxying 1251 OID { id-pe 7 } 1252 syntax ProxyInfo 1253 criticality must be TRUE 1255 7.3 Use of ObjectDigestInfo 1257 <> 1262 In some environments it may be required that the AC is not linked 1263 either to an identity (via entityName) or to a PKC (via 1264 baseCertificateID). The objectDigestInfo choice in the owner field 1265 allows support for this requirement. 1267 If the owner is identified via the objectDigestInfo field then the 1268 AC version field MUST contain v2 (i.e. the integer 1). 1270 The basic idea is to link the AC to an object by placing a hash of 1271 that object into the owner field of the AC. For example, this allows 1272 production of ACs that are linked to public keys rather than names 1273 or certificates, or production of ACs which contain privileges 1274 associated with an executable object (e.g. a Java class). 1276 In order to link an AC to a public key the hash must be calculated 1277 over the representation of that public key which would be present in 1278 a PKC, specifically, the input for the hash algorithm MUST be the 1279 DER encoding of a SubjectPublicKeyInfo representation of the key. 1280 Note: This includes the AlgorithmIdentifier as well as the BIT 1281 STRING. The rules given in [RFC2459] and [ECDSA] for encoding keys 1282 MUST be followed. 1284 Note that if the public key value used as input to the hash function 1285 has been extracted from a PKC, then it is possible that the 1286 SubjectPublicKeyInfo from that PKC is NOT the value which should be 1287 hashed. This can occur if, e.g. DSA Dss-parms are inherited as 1288 described in section 7.3.3 of [RFC2459]. The correct input for 1289 hashing in this context will include the value of the parameters 1290 inherited from the CA's PKC, and thus may differ from the 1291 SubjectPublicKeyInfo present in the PKC. 1293 Implementations which support this feature MUST be able to handle 1294 the representations of keys for the algorithms specified in section 1295 7.3 of [RFC2459] and those specified in [ECDSA]. 1297 7.4 AC Chaining 1299 Section 5 above specifies a way of embedding AAControls into PKCs in 1300 order to control the attribute types for which an AA will be trusted 1301 by an AC verifier. 1303 There are two drawbacks to this mechanism: 1305 - PKC issuers have to know about authorization attribute types 1306 - It is likely to require more frequent changes to AA's PKCs 1308 These problems can be avoided by placing the equivalent information 1309 into an AC for which the owner is an AA. However, this mechanism 1310 requires chaining of ACs and thus imposes possibly significant costs 1311 both in terms of implementation and deployment complexity. 1313 In order to use this feature, an AC verifier presented with an AC, 1314 (belonging say to an end entity, call this EE-AC), must retrieve an 1315 AC which is owned by the issuer of EE-AC (call this AA-AC). The AC 1316 verifier next verifies AA-AC, extracts the AAControls information 1317 from AA-AC and uses this to decide which attributes from EE-AC 1318 should be trusted. 1320 Of course, the issuer of AA-AC may or may not be directly trusted by 1321 the AC verifier for the required attributes. In such a case, the AC 1322 verifier may have to retrieve another AC (AA2-AC), etc. until it 1323 finds one issued by a directly trusted AC issuer for each of the 1324 relevant attributes. 1326 AC verifiers which support this feature MUST also support the use of 1327 aaControls placed within PKCs. 1329 When verifying an AC, the verifier needs to determine when a chain 1330 of ACs is needed. 1332 When AAControls are present in an AC, they are placed as an 1333 extension of the AC, using the same extension defined in section 1334 4.6.1 above. 1336 When chaining ACs the following additional verification rules apply 1338 1. EE-AC.issuer and AA-AC.owner MUST contain the same value 1339 2. At the time of evaluation all ACs in the chain MUST be valid 1341 <> 1343 8. Security Considerations 1345 Implementers MUST ensure that following validation of an AC, only 1346 attributes that the issuer is trusted to issue are used in 1347 authorization decisions. Other attributes, which MAY be present MUST 1348 be ignored. 1350 There is often a requirement to map between the authentication 1351 supplied by a particular protocol (e.g. TLS, S/MIME) and the AC 1352 owner's identity. If the authentication uses PKCs then this mapping 1353 is straightforward. However, it is envisaged that ACs will also be 1354 used in environments where the owner may be authenticated using 1355 other means. Implementers SHOULD be very careful in mapping the 1356 authenticated identity to the AC owner. 1358 9. References 1360 [CMC] Myers, M., et al. "Certificate Management Messages over 1361 CMS", 1362 draft-ietf-pkix-cmc-03.txt, March 1999. 1363 [CMP] Adams, C., Farrell, S., "Internet X.509 Public Key 1364 Infrastructure - Certificate Management Protocols", 1365 RFC2510. 1366 [CMS] Housley, R., "Cryptographic Message Syntax", 1367 draft-ietf-smime-cms-12.txt, March 1999. 1368 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 1369 draft-ietf-smime-ess-12.txt, March 1999. 1370 [ECDSA] D. Johnson, W. Polk, "Internet X.509 Public Key 1371 Infrastructure Representation of Elliptic Curve Digital 1372 Signature Algorithm (ECDSA) Keys and Signatures in 1373 Internet X.509 Public Key Infrastructure Certificates" 1374 draft-ietf-pkix-ipki-ecdsa-01.txt, June 1999. 1375 [RFC2459] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet 1376 Public Key Infrastructure - X.509 Certificate and CRL 1377 profile", RFC2459. 1378 [RFC2560] Myers, M., et al., " X.509 Internet Public Key 1379 Infrastructure - Online Certificate Status Protocol - 1380 OCSP", RFC2560. 1381 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1382 3", RFC 2026, BCP 9, October 1996. 1383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1384 Requirement Levels", RFC 2119. 1385 [X.501] ITU-T Recommendation X.501 : Information Technology - 1386 Open Systems Interconnection - The Directory: Models, 1387 1993. 1388 [X.509] ITU-T Recommendation X.509 (1997 E): Information 1389 Technology - Open Systems Interconnection - The 1390 Directory: Authentication Framework, June 1997. 1391 [X.208-88] CCITT Recommendation X.208: Specification of Abstract 1392 Syntax Notation One (ASN.1). 1988. 1394 [X.209-88] CCITT Recommendation X.209: Specification of Basic 1395 Encoding Rules for Abstract Syntax Notation One (ASN.1). 1396 1988. 1397 [X.501-88] CCITT Recommendation X.501: The Directory - Models. 1398 1988. 1399 [X.509-88] CCITT Recommendation X.509: The Directory - 1400 Authentication Framework. 1988. 1401 [X.509-97] ITU-T Recommendation X.509: The Directory - 1402 Authentication Framework. 1997. 1403 [FPDAM] ISO 9594-8 Information Technology � Open systems 1404 Interconnection - The Directory: Authentication 1405 Framework - Proposed Draft Amendment 1: Certificate 1406 Extensions, April 1999. 1408 Author's Addresses 1410 Stephen Farrell, 1411 Baltimore Technologies 1412 61/62 Fitzwilliam Lane, 1413 Dublin 2, 1414 IRELAND 1416 tel: +353-1-647-3000 1417 email: stephen.farrell@baltimore.ie 1419 Russell Housley, 1420 SPYRUS, 1421 381 Elden Street, 1422 Suite 1120, 1423 Herndon, VA 20170, 1424 USA 1426 email: housley@spyrus.com 1428 Full Copyright Statement 1430 Copyright (C) The Internet Society (date). All Rights Reserved. 1432 This document and translations of it may be copied and furnished to 1433 others, and derivative works that comment on or otherwise explain it 1434 or assist in its implementation may be prepared, copied, published 1435 and distributed, in whole or in part, without restriction of any 1436 kind, provided that the above copyright notice and this paragraph 1437 are included on all such copies and derivative works. In addition, 1438 the ASN.1 module presented in Appendix B may be used in whole or in 1439 part without inclusion of the copyright notice. However, this 1440 document itself may not be modified in any way, such as by removing 1441 the copyright notice or references to the Internet Society or other 1442 Internet organizations, except as needed for the purpose of 1443 developing Internet standards in which case the procedures for 1444 copyrights defined in the Internet Standards process shall be 1445 followed, or as required to translate it into languages other than 1446 English. 1448 The limited permissions granted above are perpetual and will not be 1449 revoked by the Internet Society or its successors or assigns. This 1450 document and the information contained herein is provided on an "AS 1451 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1452 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1453 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1454 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1455 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1457 Appendix A: "Compilable" ASN.1 Module 1459 PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) 1460 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1461 id-mod-attribute-cert(12)} 1463 DEFINITIONS EXPLICIT TAGS ::= 1465 BEGIN 1467 -- EXPORTS ALL -- 1469 IMPORTS 1471 -- PKIX Certificate Extensions 1472 Attribute, AlgorithmIdentifier, CertificateSerialNumber, 1473 Extensions, UniqueIdentifier, 1474 id-pkix, id-pe, id-kp, id-ad 1475 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 1476 dod(6) internet(1) security(5) mechanisms(5) 1477 pkix(7) id-mod(0) id-pkix1-explicit-88(1)} 1479 GeneralName, GeneralNames 1480 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 1481 dod(6) internet(1) security(5) mechanisms(5) 1482 pkix(7) id-mod(0) id-pkix1-implicit-88(2)} ; 1484 id-pe-ac-auditIdentity OBJECT IDENTIFIER ::= { id-pe 4 } 1485 id-pe-ac-targeting OBJECT IDENTIFIER ::= { id-pe 5 } 1486 id-pe-aaControls OBJECT IDENTIFIER ::= { id-pe 6 } 1487 id-pe-ac-proxying OBJECT IDENTIFIER ::= { id-pe 7 } 1489 id-pe-ac-targeting-all OBJECT IDENTIFIER ::= 1490 { id-pe-ac-targeting 1 } 1492 id-aca OBJECT IDENTIFIER ::= { id-pkix 10 } 1494 id-aca-authenticationInfo OBJECT IDENTIFIER ::= { id-aca 1 } 1495 id-aca-accessIdentity OBJECT IDENTIFIER ::= { id-aca 2 } 1496 id-aca-chargingIdentity OBJECT IDENTIFIER ::= { id-aca 3 } 1497 id-aca-group OBJECT IDENTIFIER ::= { id-aca 4 } 1498 id-aca-role OBJECT IDENTIFIER ::= { id-aca 5 } 1499 id-aca-encAttrs OBJECT IDENTIFIER ::= { id-aca 6 } 1501 id-ad-noRevStat OBJECT IDENTIFIER ::= { id-ad 3 } 1502 id-ad-acRevStatusLocation OBJECT IDENTIFIER ::= { id-ad 4 } 1504 AttributeCertificate ::= SEQUENCE { 1505 acinfo AttributeCertificateInfo, 1506 signatureAlgorithm AlgorithmIdentifier, 1507 signatureValue BIT STRING 1508 } 1510 AttributeCertificateInfo ::= SEQUENCE { 1511 version AttCertVersion DEFAULT v1, 1512 owner Owner, 1513 issuer AttCertIssuer, 1514 signature AlgorithmIdentifier, 1515 serialNumber CertificateSerialNumber, 1516 attrCertValidityPeriod AttCertValidityPeriod, 1517 attributes SEQUENCE OF Attribute, 1518 issuerUniqueID UniqueIdentifier OPTIONAL, 1519 extensions Extensions OPTIONAL 1520 } 1522 AttCertVersion ::= INTEGER {v1(0), v2(1) } 1524 Owner ::= SEQUENCE { 1525 baseCertificateID [0] IssuerSerial OPTIONAL, 1526 -- the issuer and serial number of 1527 -- the owner's Public Key Certificate 1528 entityName [1] GeneralNames OPTIONAL, 1529 -- the name of the claimant or role 1530 objectDigestInfo [2] ObjectDigestInfo OPTIONAL 1531 -- if present, version must be v2 1532 } 1534 ObjectDigestInfo ::= SEQUENCE { 1535 digestAlgorithm AlgorithmIdentifier, 1536 objectDigest OCTET STRING 1537 } 1539 AttCertIssuer ::= SEQUENCE { 1540 issuerName GeneralNames OPTIONAL, 1541 baseCertificateId [0] IssuerSerial OPTIONAL 1542 } 1544 IssuerSerial ::= SEQUENCE { 1545 issuer GeneralNames, 1546 serial CertificateSerialNumber, 1547 issuerUID UniqueIdentifier OPTIONAL 1548 } 1550 AttCertValidityPeriod ::= SEQUENCE { 1551 notBeforeTime GeneralizedTime, 1552 notAfterTime GeneralizedTime 1553 } 1555 Targets ::= SEQUENCE OF Target 1557 Target ::= CHOICE { 1558 targetName [0] GeneralName, 1559 targetGroup [1] GeneralName 1560 } 1562 IetfAttrSyntax ::= SEQUENCE OF SEQUENCE { 1563 policyAuthority[0] GeneralNames OPTIONAL, 1564 values SEQUENCE OF CHOICE { 1565 octets OCTET STRING, 1566 oid OBJECT IDENTIFIER, 1567 string UTF8String 1568 } 1569 } 1571 SvceAuthInfo ::= SEQUENCE { 1572 service GeneralName, 1573 ident GeneralName, 1574 authInfo OCTET STRING OPTIONAL 1575 } 1577 Clearance ::= SEQUENCE { 1578 policyId OBJECT IDENTIFIER, 1579 classList ClassList DEFAULT {unclassified}, 1580 securityCategories 1581 SET OF SecurityCategory OPTIONAL 1582 } 1584 ClassList ::= BIT STRING { 1585 unmarked (0), 1586 unclassified (1), 1587 restricted (2), 1588 confidential (3), 1589 secret (4), 1590 topSecret (5) 1591 } 1593 SecurityCategory ::= SEQUENCE { 1594 type [0] IMPLICIT OBJECT IDENTIFIER, 1595 value [1] ANY DEFINED BY type 1596 } 1598 AAControls ::= SEQUENCE { 1599 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1600 permittedAttrs [0] AttrSpec OPTIONAL, 1601 excludedAttrs [1] AttrSpec OPTIONAL, 1602 permitUnSpecified BOOLEAN DEFAULT TRUE 1603 } 1604 AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER 1606 ACClearAttrs ::= SEQUENCE { 1607 acIssuer GeneralName, 1608 acSerial INTEGER, 1609 attrs SEQUENCE OF Attribute 1610 } 1612 ProxyInfo ::= SEQUENCE OF Targets 1614 END 1616 Appendix B: Samples 1618 <> 1620 Appendix C: Changes this version / Open Issues 1622 This appendix lists major changes since the previous revision and 1623 open issues to be resolved (in order of occurrence in the body of 1624 the document). 1626 Major changes since last revision: 1628 1. Re-structured conformance to profile + options as per Oslo 1629 consensus 1630 2. Moved acquisition protocol (LAAP)_to separate I-D 1631 3. Removed restrictions entirely 1632 4. Added new AC revocation options 1633 5. Added optional support for use of objectDigestInfo for keys 1634 6. Added optional support for chains of ACs 1635 7. Changed some syntax: 1636 Added UTF8String to IetfAttrSyntax value choice 1637 Split target & proxy extensions, removed owner from proxyInfo 1638 8. Allocated PKIX OIDs (note: check with repository before using 1639 these, the PKIX arc is currently available at 1640 http://www.imc.org/ietf-pkix/pkix-oid.asn) 1641 9. Added compiled ASN.1 module 1643 Open issues remaining: 1645 1. Should an AC without any attributes be allowed? 1646 2. Should OS-specific group attribute types be defined? 1647 3. Is the expansion of the SecurityCategory MACRO correct? 1648 4. Are three revocation schemes needed? Correct? 1649 5. Should more types of objectDigestInfo be allowed? 1650 6. AC chain section needs more description of chain validation. 1651 7. Samples - should they be a separate draft?