idnits 2.17.00 (12 Aug 2021) /tmp/idnits35215/draft-ietf-pkix-ac509prof-00.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 is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 10) being 554 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 31 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 9 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([XPDAM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 51 has weird spacing: '...MAY" in this ...' == Line 186 has weird spacing: '...erifier any...' == Line 606 has weird spacing: '...icality mus...' == Line 711 has weird spacing: '...call it set ...' == Line 734 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: 1. the AC signature must be cryptographically correct and the AC issuer's PKC MUST be verified in accordance with [RFC2459] 2. if the AC issuer is not directly trusted as an AC issuer (by configuration or otherwise), then the AC issuer's certification path must satisfy the additional PKC checks described below 3. the time of evaluation MUST be within the AC validity (if the evaluation time is equal to either notBeforeTime or notAfterTime then the AC is timely, i.e. this check succeeds) 4. 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 5. the AC targeting check MUST pass (see section 4.4.3 above) 6. if the AC contains any "unsupported" critical extensions 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 (April 1999) is 8436 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 1248 -- Looks like a reference, but probably isn't: '1' on line 1249 -- Looks like a reference, but probably isn't: '2' on line 1211 == Unused Reference: 'ESS' is defined on line 1347, 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) == Outdated reference: draft-ietf-smime-cms has been published as RFC 2630 == Outdated reference: draft-ietf-smime-ess has been published as RFC 2634 ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) -- Possible downref: Non-RFC (?) normative reference: ref. 'XPDAM' Summary: 9 errors (**), 0 flaws (~~), 14 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT S. Farrell 2 PKIX Working Group SSE 3 expires in six months R. Housley 4 Spryus 5 April 1999 7 An Internet AttributeCertificate 8 Profile for Authorization 10 12 Status of this memo 14 This document is an Internet-Draft and is in full 15 conformance with all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum 23 of six months and may be updated, replaced, or obsoleted 24 by other documents at any time. It is inappropriate to 25 use Internet-Drafts as reference material or to cite them 26 other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be 32 accessed at http://www.ietf.org/shadow.html. 34 <> 36 Abstract 38 Authorization support is required for various Internet 39 protocols, for example, TLS, CMS and their consumers, 40 and others. The X.509 AttributeCertificate provides a 41 structure that can form the basis for such services 42 ([X.509], [XPDAM]). This specification defines two 43 profiles (basic and proxiable) for the use of X.509 44 AttributeCertificates to provide such authorization 45 services. 47 Farrell & Housley [Page 1] 48 1. Introduction 50 The key words "MUST", "REQUIRED", "SHOULD", 51 "RECOMMENDED", and "MAY" in this document are to be 52 interpreted as described in [RFC2119]. 54 The provision of authentication, data integrity and 55 confidentiality services for current Internet protocols 56 is well understood and many secure transports are defined 57 (e.g. TLS, IPSEC, etc.). In many applications these 58 services are not sufficient (or too cumbersome to 59 administer) to provide the type of authorization services 60 required. 62 [RFC2459] specifies a profile for the use of X.509 public 63 key certificates in Internet protocols. This type of 64 certificate is typically used as an "identity" 65 certificate, that is, it contains a certified name and 66 public key, and any entity that can use the corresponding 67 private key is treated as the named entity. 69 When considering authorization, one is often less 70 interested in the identity of the entity than in some 71 other attributes, (e.g. roles, account limits etc.), 72 which should be used to make an authorization decision. 74 In many such cases, it is better to separate this 75 information from the identity for management, security, 76 interoperability or other reasons. However, this 77 authorization information also needs to be protected in a 78 fashion similar to a public key certificate - the name 79 for the structure used is an attribute certificate (an 80 AC) which is a digitally signed (certified) set of 81 attributes. 83 An AC is a structure that is similar to an X.509 public 84 key certificate [RFC2459] with the main difference being 85 that it contains no public key. The AC typically contains 86 group membership, role, clearance and other access 87 control information associated with the AC owner. The 88 base syntax for ACs is also defined in the X.509 standard 89 (making the term X.509 certificate ambiguous!). This 90 document specifies a profile of the X.509 AC suitable for 91 authorization purposes in Internet protocols. 93 Farrell & Housley [Page 2] 94 When making an access decision based on an AC, an access 95 decision function may need to ensure that the appropriate 96 AC owner is the entity that has requested access. For 97 example, one way in which the linkage between the request 98 and the AC can be achieved is if the AC has a "pointer" 99 to a PKC for the requestor and that PKC has been used to 100 authenticate the request. 102 As there is often confusion about the difference between 103 public key certificates (PKCs) and attribute certificates 104 (ACs), an analogy may help. A PKC can be considered to be 105 like a passport: it identifies the owner, tends to last 106 for a long period and shouldn't be too easy to get. An AC 107 is more like an entry visa in that it is typically issued 108 by a different authority and doesn't last as long. As 109 acquiring an entry visa typically requires presenting a 110 passport, getting a visa can be a simpler process. 112 In conjunction with authentication services ACs provide a 113 means to transport authorization information securely to 114 applications. However, there are a number of possible 115 communication paths that an AC may take: 117 In some environments it is suitable for a client to 118 "push" an AC to a server. This means that no new 119 connections between the client and server domains are 120 required. It also means that no search burden is imposed 121 on servers, which improves performance. 123 In other cases it is more suitable for a client simply to 124 authenticate to the server and for the server to request 125 ("pull") the client's AC from an AC issuer or a 126 repository. A major benefit of the "pull" model is that 127 it can be implemented without changes to the client and 128 client/server protocol. It is also more suitable for some 129 inter-domain cases where the client's rights should be 130 assigned within the server's domain, rather than within 131 the client's "home" domain. 133 There are a number of possible exchanges that can occur 134 and three entities involved (client, server and AC 135 issuer). In addition the use of a directory service or 136 other repository for AC retrieval MAY be supported. 138 Farrell & Housley [Page 3] 139 The diagram below shows an abstract view of the exchanges 140 that may involve ACs. This profile does not specify 141 protocol for all of these exchanges, though a limited 142 case of client and server acquisition is defined below. 144 +--------------+ +---------------+ 145 | | | | 146 | AC Issuer +----+ | Repository | 147 | | | | | 148 +--+-----------+ | Server +-------+-------+ 149 | | Acquisition | 150 |Client | |Server 151 |Acquisition +----------------------+ |Lookup 152 | | | 153 +--+-----------+ +--+----+-------+ 154 | | AC "push" | | 155 | Client +------------------------+ Server | 156 | | (part of app. protocol)| | 157 +--------------+ +---------------+ 158 | 159 | Client Lookup 160 +--+-----------+ 161 | | 162 | Repository | Figure 1: AC Exchanges 163 | | 164 +--------------+ 166 The remainder of the document is structured as follows:- 168 Section 2 defines some terminology 169 Section 3 specifies the requirements that this profile is 170 to meet 171 Section 4 contains the profile of the X.509 AC 172 Section 5 specifies rules for AC validation 173 Section 6 specifies rules for AC revocation checks 174 Section 7 specifies a limited AC acquisition protocol 175 Section 8 contains a conformance statement 177 Appendices contain samples, a "compilable" ASN.1 module 178 for this specification and a list of open issues. 180 2. Terminology 182 Term Meaning 184 AC AttributeCertificate 185 AC user any entity that parses or processes an AC 186 AC verifier any entity that checks the validity of an 187 AC and then makes use of the result 188 AC issuer the entity which signs the AC 190 Farrell & Housley [Page 4] 191 AC owner the entity indicated (perhaps indirectly) 192 in the subject field of the AC 193 Client the entity which is requesting the action 194 for which authorization checks are to be 195 made 196 LAAP Limited AC Acquisition Protocol 197 LRP LAAP responder 198 LRQ LAAP requestor 199 Proxying In this specification, Proxying is used 200 to mean the situation where an 201 application server acts as an application 202 client on behalf of a user. Proxying here 203 does not mean granting of authority. 204 PKC Public Key Certificate - uses the type 205 ASN.1 Certificate defined in X.509 and 206 profiled in RFC 2459. This (non-standard) 207 acronym is used in order to avoid 208 confusion about the term "X.509 209 certificate". 210 Server the entity which requires that the 211 authorization checks are made 213 3. Requirements 215 The following are the requirements that the "full" 216 profile defined here meets. 218 Time/Validity requirements: 220 1. Support for short-lived or long-lived ACs is 221 required. Typical validity periods might be measured in 222 hours, as opposed to months for X.509 public key 223 certificates. Short validity periods mean that ACs can be 224 useful without a revocation scheme. 226 Attribute Types: 228 2. Issuers of ACs should be able to define their own 229 attribute types for use within closed domains. 230 3. Some standard attribute types should be defined 231 which can be contained within ACs, for example "access 232 identity", "group", "role", "clearance", "audit 233 identity", "charging id" etc. 234 4. Standard attribute types should be defined so that 235 it is possible for an AC verifier to distinguish between 236 e.g. the "Administrators group" as defined by SSE and the 237 "Administrators group" as defined by Widgets inc. 238 5. ACs should support the encryption of some, or all, 239 attributes (e.g. passwords for legacy applications). It 240 should be possible for such an encrypted attribute to be 242 Farrell & Housley [Page 5] 243 deciphered by an appropriate AC verifier even where the 244 AC has not been received directly from the AC owner (i.e. 245 where the AC is proxied). 247 Targeting of ACs: 249 6. It should be possible to "target" an AC. This means 250 that a given AC may be "targeted" at one, or a number of, 251 servers/services in the sense that a trustworthy non- 252 target will reject the AC for authorization decisions. 254 Proxying: 256 7. It should be possible for a server to proxy an AC 257 when it acts as a client (for another server) on behalf 258 of the AC owner. 259 8. Proxying should be under the AC issuer's control, so 260 that not every AC is proxiable and so that a given 261 proxiable AC can be proxied in a targeted fashion. 262 9. Support for chains of proxies (with more than one 263 intermediate server) is required. 265 Push vs. Pull 267 10. ACs should be defined so that they can either be 268 "pushed" by the client to the server, or "pulled" by the 269 server from a network service (whether the AC issuer or 270 an online repository). 272 This profile specifically imposes no requirements for: 274 1. The meaning of a chain of ACs 275 2. AC translation 277 Support for such features may be part of some other 278 profile. 280 Farrell & Housley [Page 6] 281 4. The AC Profile 283 This section specifies the profile of the X.509 AC which 284 is to be supported by conforming implementations. 286 4.1 X.509 AttributeCertificate Definition 288 X.509 contains the definition of an AttributeCertificate 289 given below. Types that are not defined can be found in 290 [RFC2459]. 292 <> 294 AttributeCertificate ::= SIGNED { 295 acinfo AttributeCertificateInfo 296 } 298 AttributeCertificateInfo ::= SEQUENCE { 299 version AttCertVersion DEFAULT v1, 300 owner CHOICE{ 301 baseCertificateID [0] IssuerSerial, 302 -- the issuer and serial number of 303 -- the owner's Public Key Certificate 304 entityName [1] GeneralNames, 305 -- the name of the claimant or role 306 objectDigestInfo [2] ObjectDigestInfo 307 -- if present, version must be v2 308 }, 309 issuer CHOICE { 310 baseCertificateId [0] IssuerSerial, 311 issuerName [1] GeneralNames 312 }, 313 --AA that issued the attribute certificate 314 signature AlgorithmIdentifier, 315 serialNumber CertificateSerialNumber, 316 attrCertValidityPeriod AttCertValidityPeriod 317 attributes SEQUENCE OF Attribute, 318 issuerUniqueID UniqueIdentifier OPTIONAL, 319 extensions Extensions OPTIONAL 320 } 322 AttCertVersion ::= INTEGER {v1(0), v2(1) } 324 ObjectDigestInfo ::= SEQUENCE { 325 digestAlgorithm AlgorithmIdentifier, 326 objectDigest OCTET STRING 327 } 329 IssuerSerial ::= SEQUENCE { 330 issuer GeneralNames, 332 Farrell & Housley [Page 7] 333 serial CertificateSerialNumber, 334 issuerUID UniqueIdentifier OPTIONAL 335 } 337 AttCertValidityPeriod ::= SEQUENCE { 338 notBeforeTime GeneralizedTime, 339 notAfterTime GeneralizedTime 340 } 342 4.2 Object Identifiers 344 The following OIDs are used: 346 << 347 for interop testing purposes the SSE OID sse-ac-tst may 348 be used instead of ietf-ac. 349 sse-id OBJECT IDENTIFIER ::= { 1 3 6 1 4 1 1201 } 350 sse-ac-tst OBJECT IDENTIFIER ::= { sse-id 56 } 351 >> 353 ietf-ac OBJECT IDENTIFIER ::= <> 354 ietf-ac-extensions OBJECT IDENTIFIER ::= { ietf-ac 1} 355 ietf-ac-attributes OBJECT IDENTIFIER ::= { ietf-ac 2} 357 4.3 Profile of Standard Fields. 359 For all GeneralName fields in this profile the otherName, 360 x400Address, ediPartyName and registeredId options MUST 361 NOT be used unless otherwise specified (e.g. as in the 362 description of targeting extension). 364 4.3.1 version 366 This must be the default value of v1, i.e. not present in 367 encoding. 369 <> 373 4.3.2 owner 375 For any protocol where the AC is passed in an 376 authenticated message or session, and where the 377 authentication is based on the use of an X.509 public key 378 certificate (PKC), the owner field MUST use the 379 baseCertificateID. 381 With the baseCertificateID option, the owner's PKC 382 serialNumber and issuer MUST be identical to the AC owner 384 Farrell & Housley [Page 8] 385 field. The PKC issuer MUST have a non-NULL X.500 name 386 which is to be present as the single value of the of the 387 owner.issuerSerial.issuer construct in the directoryName 388 field. The owner.issuerSerial.issuerUID field MUST only 389 be used if the owner's PKC contains an issuerUniqueID 390 field. 392 The above means that the baseCertificateID is only usable 393 with PKC profiles (like RFC2459) which mandate that the 394 PKC issuer field contain a value. 396 If the owner field uses the entityName option and the 397 underlying authentication is based on a PKC, then the 398 entityName MUST be the same as the PKC subject field, or, 399 if the PKC subject is a "NULL" DN, then the entityName 400 field MUST be identical to one of the values of the PKC 401 subjectAltName field extension. Note that [RFC2459] 402 mandates that the subjectAltNames extension be present if 403 the PKC subject is a "NULL" DN. 405 In any other case where the owner field uses the 406 entityName option then only one name SHOULD be present. 408 AC's conforming to this profile MUST NOT use the 409 objectDigest field. 411 <> 413 Any protocol conforming to this profile SHOULD specify 414 which AC subject option is to be used and how this fits 415 with e.g. peer-entity authentication in the protocol. 417 4.3.3 issuer 419 ACs conforming to this profile MUST use the issuerName 420 choice which MUST contain one and only one GeneralName 421 which MUST contain its non-null value in the 422 directoryName field. This means that all AC issuers MUST 423 have non-NULL X.500 names. 425 Part of the reason for the use of the issuerName field is 426 that it allows the AC verifier to be independent of the 427 AC issuer's public key infrastructure. Using the 428 baseCertificateId field to reference the AC issuer would 429 mean that the AC verifier would have such a dependency. 431 4.3.4 signature 433 Contains the algorithm identifier used to validate the AC 434 signature. 436 Farrell & Housley [Page 9] 437 This MUST be one of the following algorithms defined in 438 [RFC2459] section 7.2: md5WithRSAEncryption, id-dsa-with- 439 sha1 or sha-1WithRSAEncryption. 441 id-dsa-with-sha1 MUST be supported by all AC users. The 442 other algorithms SHOULD be supported. 444 4.3.5 serialNumber 446 For any conforming AC, the issuer/serialNumber pair MUST 447 form a unique combination, even if ACs are very short- 448 lived (one second is the shortest possible validity due 449 to the use of GeneralizedTime). 451 AC issuers MUST force the serialNumber to be a positive 452 integer, that is, the topmost bit in the DER encoding of 453 the INTEGER value MUST NOT be a `1'B - this is to be done 454 by adding a leading (leftmost) `00'H octet if necessary. 455 This removes a potential ambiguity in mapping between a 456 string of octets and a serialNumber. 458 Given the uniqueness and timing requirements above serial 459 numbers can be expected to contain long integers, i.e. AC 460 users MUST be able to handle more than 32 bit integers 461 here. 463 There is no requirement that the serial numbers used by 464 any AC issuer follow any particular ordering, in 465 particular, they need not be monotonically increasing 466 with time. 468 4.3.6 attrCertValidityPeriod 470 The attrCertValidityPeriod (a.k.a. validity) field 471 specifies the period for which the AC issuer expects that 472 the binding between the owner and the attributes fields 473 will be valid. 475 GeneralizedTime encoding is restricted as specified in 476 [RFC2459] for the corresponding fields in a PKC. 478 Note that AC users MUST be able to handle the case where 479 an AC is issued, which (at the time of parsing), has its 480 entire validity period in the future (a "post-dated" AC). 481 This is valid for some applications, e.g. backup. 483 4.3.7 attributes 485 The attributes field gives information about the AC 486 owner. When the AC is used for authorization this will 487 often contain a set of privileges. However, authorization 488 may also require support for "restrictions" - these are 489 not carried within the attributes field (though they 490 "belong" to the AC owner) but in the extensions field. 492 The attributes field contains a SEQUENCE OF Attribute. 493 For a given AC each attribute type in the sequence MUST 494 be unique, that is, only one instance of each attribute 495 type can occur in a single AC. Each instance can however, 496 be multi-valued. 498 AC consumers MUST be able to handle multiple values for 499 all attribute types. 501 Note that a conforming AC MAY contain an empty SEQUENCE, 502 that is, no attributes at all. 504 Some standard attribute types are defined in section 4.5. 506 4.3.8 issuerUniqueID 508 This field MUST NOT be used. 510 4.3.9 extensions 512 The extensions field generally gives information about 513 the AC as opposed to information about the AC owner. The 514 exception is where restrictions are to be supported. If 515 one regards a restriction as a qualification on a 516 privilege then it is clear that restrictions must be 517 implemented as a critical extension. 519 Section 4.4 defines the extensions that MAY be used with 520 this profile. An AC that has no extensions conforms to 521 the profile. If any other critical extension is used, 522 then the AC does not conform to this profile. An AC that 523 contains additional non-critical extensions still 524 conforms. 526 4.4 Extensions. 528 4.4.1 Restrictions 530 <> 537 A restriction is a "negative" privilege, for example an 538 AC may "state" that the AC owner is a member of the 539 administrative group except for purposes of backup. 540 Restrictions would more properly be implemented as a 541 separate field of the AC, but with the current syntax can 542 only be supported via the use of a critical extension. 544 The value of this extension will be a SEQUENCE OF 545 Attribute. The rule stated above for the AC attributes 546 field (only one instance of each type etc.) applies here 547 also. 549 Each restriction MUST correspond to one attribute present 550 in the attributes field and must use the same attrType 551 OID as the related attribute. 553 name ietf-ac-restrictions 554 OID { ietf-ac-extensions 1 } 555 syntax SEQUENCE OF Attribute 556 criticality MUST be TRUE 558 4.4.2 Audit Identity 560 In some circumstances it is required (e.g. by data 561 protection/data privacy legislation) that audit trails do 562 not contain records which directly identify individuals. 563 This may make the use of the owner field of the AC 564 unsuitable for use in audit trails. 566 In order to allow for such cases an AC MAY contain an 567 audit identity extension. Ideally it SHOULD be infeasible 568 to derive the AC owner's identity from the audit identity 569 value except with the co-operation of the AC issuer. 571 The value of the audit identity plus the AC issuer/serial 572 should then be used for audit/logging purposes. If the 573 value of the audit identity is suitably chosen then a 574 server/service administrator can track the behaviour of 575 an AC owner without being able to identify the AC owner. 577 The server/service administrator in combination with the 578 AC issuer MUST be able to identify the AC owner in cases 579 where mis-behaviour is detected. This means that the AC 580 issuer MUST be able to map "backwards" from the audit 581 identity to the actual identity of the AC owner. 583 Of course, auditing could be based on the AC 584 issuer/serial pair, however, this method doesn't allow 585 tracking the same AC owner across different ACs. This 586 means that an audit identity is only useful if it lasts 587 for longer than the typical AC lifetime - how much longer 588 is an issue for the AC issuer implementation. Auditing 589 could also be based on the AC owner's PKC issuer/serial 590 however, this will often allow the server/service 591 administrator identify the AC owner. 593 As the AC verifier might otherwise use the AC subject or 594 some other identifying value for audit purposes, this 595 extension MUST be critical when used. 597 Protocols that use ACs will often expose the identity of 598 the AC owner in the bits on-the-wire. In such cases, an 599 "opaque" audit identity does not make use of the AC 600 anonymous, it simply ensures that the ensuing audit 601 trails are "semi-anonymous". 603 name ietf-ac-auditId 604 OID { ietf-ac-extensions 3 } 605 syntax OCTET STRING 606 criticality must be TRUE 608 4.4.3 AC Targeting and Proxying 610 In order to allow that an AC is "targeted" and to control 611 proxying, the proxy information extension MAY be used to 612 specify a number of servers/services. The intent is that 613 the AC should only be usable at the specified 614 servers/services - an (honest) AC verifier who is not 615 amongst the named servers/services MUST reject the AC. 617 If this extension is not present then the AC is not 618 proxiable. Any server which receives the AC such that the 619 owner and the authenticated peer-entity do not match MUST 620 reject the AC. 622 When this extension is present we are essentially 623 checking that the entity from which the AC was received 624 was allowed to send it and that the AC is allowed to be 625 used by this recipient. 627 The targeting information consists of the direct 628 information (targets field) and an optional set of proxy 629 information (proxies field). If the "direct check" or any 630 of the "proxy" checks (see below) pass then the 631 "targeting check" as a whole is successful. 633 The effect is that the AC owner can send to any valid 634 target which can then only proxy to targets which are in 635 one of the same "proxy sets" as itself. 637 The following data structure is used to represent the 638 targeting/proxying information. 640 ProxyInfo ::= SEQUENCE { 641 owner CHOICE { 642 baseCertificateID [0] IssuerSerial, 643 subjectName [1] GeneralNames, 644 objectDigestInfo [2] ObjectDigestInfo 645 }, 646 targets [0] Targets OPTIONAL, 647 proxies [1] SEQUENCE OF Targets OPTIONAL 648 } 649 Targets ::= SEQUENCE OF Target 650 Target ::= CHOICE { 651 targetName [0] GeneralName, 652 targetGroup [1] GeneralName 653 } 655 Where no proxies or targets are present then the entire 656 field MUST be omitted, that is, a zero-length sequence of 657 Targets MUST NOT be present. There MUST be at least one 658 target or one proxy present, that is, one of the targets 659 or proxies fields MUST be present. 661 We represent a special target, called "ALL" which is a 662 wildcard as a targetName with the registeredID choice and 663 a value of {ietf-ac-extensions 4 1}. This is an exception 664 to the general rule stated above about the use of 665 GeneralName choices. 667 The direct check passes if: 669 the identity of the client as established by the 670 underlying authentication service matches the owner 671 field 672 and 673 ( 674 the targets field contains one targetName which 675 is the "ALL" value 676 or 677 the current server (recipient) is one of the 678 targetName fields in the targets part 679 or 680 the current server is a member of one of the 681 targetGroup fields in the targets part. 682 ) 684 How the membership of a target within a targetGroup is 685 determined is not defined here. It is assumed that any 686 given target "knows" the names of the targetGroup's to 687 which it belongs or can otherwise determine its 688 membership. For example, if the targetGroup were to be a 689 DNS domain and the AC verifier knows the DNS domain to 690 which it belongs or it the targetGroup were "PRINTERS" 691 and the AC verifier "knows" that it's a printer or print 692 server. 694 A proxy check succeeds if 696 ( 697 the identity of the sender as established by 698 the underlying authentication service matches 699 the owner field 700 and 701 ( 702 the current server "matches" any one of 703 the proxy sets (where "matches" is as for 704 the direct check above) 705 ) 706 ) 707 or 708 ( 709 the identity of the sender as established by 710 the underlying authentication service "matches" 711 one of the proxy sets (call it set "A") 712 and 713 ( 714 the current server is one of the targetName 715 fields in the set "A" 716 or 717 the current server is a member of one of the 718 targetGroup fields in set "A". 719 ) 720 ) 722 Where an AC is proxied more than once a number of targets 723 will be on the path from the original client which is 724 normally, but not always, the AC owner. In such cases 725 prevention of AC "stealing" requires that the AC verifier 726 MUST check that all targets on the path are members of 727 the same proxy set. It is the responsibility of the AC 728 using protocol to ensure that a trustworthy list of 729 targets on the path is available to the AC verifier. 731 name ietf-ac-targeting 732 OID { ietf-ac-extensions 4 } 733 syntax ProxyInfo 734 criticality must be TRUE 736 4.4.4 authorityKeyIdentifier 738 The authorityKeyIdentifier extension as profiled in 739 [RFC2459] MAY be used to assist the AC verifier in 740 checking the signature of the AC. The [RFC2459] 741 description should be read as if "CA" meant "AC issuer". 742 As with PKCs this extension SHOULD be included in ACs. 744 name id-ce-authorityKeyIdentifier 745 OID { id-ce 35 } 746 syntax AuthorityKeyIdentifier 747 criticality MUST be FALSE 749 4.4.5 authorityInformationAccess 751 The authorityInformationAccess extension as profiled in 752 [RFC2459] MAY be used to assist the AC verifier in 753 checking the revocation status of the AC. See section 6 754 on revocation below for details. 756 The following accessMethod is used to indicate that 757 revocation status checking is not provided for this AC: 759 ietf-ac-norevstat OBJECT IDENTIFIER ::= 760 { ietf-ac-extensions 5} 762 The accessLocation field MUST contain a NULL 763 directoryName. 765 name id-ce-authorityInfoAccess 766 OID { id-pe 1 } 767 syntax AuthorityInfoAccessSyntax 768 criticality MUST be TRUE 770 4.5 Attribute Types 772 Some of the attribute types defined below make use of the 773 IetfAttrSyntax type defined below. The reasons for using 774 this type are: 776 1. It allows a separation between the AC issuer and the 777 attribute policy authority. This is useful for situations 778 where a single policy authority (e.g. an organisation) 779 allocates attribute values, but where multiple AC issuers 780 are deployed for performance, network or other reasons. 781 2. It allows the type of the attribute (privilege, 782 restriction) to be made explicit which helps server 783 implementations that provide an API on top of an AC 784 validation module. 786 3. The syntaxes allowed for values are restricted to 787 OCTET STRING and OID, which reduces some of the matching 788 complexities associated with GeneralName. 790 <> 795 IetfAttrSyntax ::= SEQUENCE OF { 796 type INTEGER { 797 privilege(0), 798 restriction(1), 799 other(2) 800 } 801 DEFAULT privilege, 802 policyAuthority[0] GeneralNames OPTIONAL, 803 values SEQUENCE OF CHOICE { 804 octets OCTET STRING, 805 oid OBJECT IDENTIFIER 806 } 807 } 809 4.5.1 Service Authentication Info 811 This attribute type identifies the AC owner to the 812 server/service by a name and with optional authentication 813 information. Typically this will contain a 814 username/password pair for a "legacy" application (and 815 hence MAY need to be encrypted). 817 This attribute type will typically be encrypted if the 818 authInfo field contains sensitive information (e.g. a 819 password). 821 name ietf-ac-authInfo 822 OID { ietf-ac-attributes 1} 823 Syntax SvceAuthInfo 824 values: Multiple allowed 826 SvceAuthInfo ::= SEQUENCE { 827 service GeneralName, 828 ident GeneralName, 829 authInfo OCTET STRING OPTIONAL 830 } 832 4.5.2 Access Identity 834 An access identity identifies the AC owner to the 835 server/service. For this attribute the authInfo field 836 MUST NOT be present. 838 name ietf-ac-accessId 839 OID { ietf-ac-attributes 2} 840 syntax SvceAuthInfo 841 values: Multiple allowed 843 4.5.3 Charging Identity 845 This attribute type identifies the AC owner for charging 846 purposes. 848 name ietf-ac-chargingId 849 OID { ietf-ac-attributes 3} 850 syntax IetfAttrSyntax 851 values: Multiple allowed 853 4.5.4 Group 855 This attribute carries information about group 856 memberships of the AC owner. 858 <> 864 name ietf-ac-group 865 OID { ietf-ac-attributes 4} 866 syntax IetfAttrSyntax 867 values: Multiple allowed 869 4.5.5 Role 871 This attribute carries information about role allocations 872 of the AC owner. 874 name ietf-ac-role 875 OID { ietf-ac-attributes 5} 876 syntax IetfAttrSyntax 877 values: Multiple allowed 879 4.5.6 Clearance 881 This attribute carries clearance (security labelling) 882 information about the AC owner. 884 name { id-at-clearance } 885 OID { joint-iso-ccitt(2) ds(5) module(1) selected- 886 attribute-types(5) clearance (55) } 887 syntax Clearance - imported from [X.5??] 888 values Multiple allowed 890 Clearance ::= SEQUENCE { 891 policyId OBJECT IDENTIFIER, 892 classList ClassList DEFAULT {unclassified}, 893 securityCategories 894 SET OF SecurityCategory OPTIONAL 895 } 897 ClassList ::= BIT STRING { 898 unmarked (0), 899 unclassified (1), 900 restricted (2) 901 confidential (3), 902 secret (4), 903 topSecret (5) 904 } 906 SecurityCategory ::= SEQUENCE { 907 type [0] IMPLICIT SECURITY-CATEGORY, 908 value [1] ANY DEFINED BY type 909 } 911 SECURITY-CATEGORY MACRO ::= 912 BEGIN 913 TYPE NOTATION ::= type | empty 914 VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 915 END 917 4.5.7 EncryptedAttributes 919 Where an AC will be carried in clear within an 920 application protocol or where an AC contains some 921 sensitive information (e.g. a legacy application 922 username/password) then encryption of AC attributes MAY 923 be needed. 925 When a set of attributes are to be encrypted within an 926 AC, the cryptographic message syntax, EnvelopedData 927 structure [CMS] is used to carry the ciphertext(s) and 928 associated per-recipient keying information. 930 This type of attribute encryption is targeted which means 931 that before the AC is signed the attributes have been 932 encrypted for a set of predetermined recipients. 934 The AC then contains the ciphertext(s) inside its signed 935 data. The "enveloped-data" (id-envelopedData) ContentType is 936 used and the content field will contain the EnvelopedData 937 type. 939 Only one encryptedAttributes attribute can be present in 940 an AC - however it MAY be multi-valued and each of its 941 values will contain an EnvelopedData. 943 Each value can contain a set of attributes (each possibly 944 a multi-valued attribute) encrypted for a set of 945 recipients. 947 The cleartext that is encrypted has the type: 949 ACClearAttrs ::= SEQUENCE { 950 acIssuer GeneralName, 951 acSerial INTEGER, 952 attrs SEQUENCE OF Attribute 953 } 955 The DER encoding of the ACClearAttrs structure is used as 956 the encryptedContent field of the EnvelopedData, i.e. the 957 DER encoding MUST be embedded in an OCTET STRING. 959 The acIssuer and acSerial fields are present to prevent 960 ciphertext stealing - when an AC verifier has 961 successfully decrypted an encrypted attribute it MUST 962 then check that the AC issuer and serialNumber fields 963 contain the same values. This prevents a malicious AC 964 issuer from copying ciphertext from another AC issuer's 965 AC into an AC issued by the malicious AC issuer. 967 The procedure for an AC issuer when encrypting attributes 968 is illustrated by the following (any other procedure that 969 gives the same result MAY be used): 971 1. Identify the sets of attributes that are to be 972 encrypted for each set of recipients. 973 2. For each attribute set which is to be encrypted: 974 2.1. Create an EnvelopedData structure for the data for 975 this set of recipients. 976 2.2. Encode the EnvelopedData as a value of the 977 EncryptedAttributes attribute 978 2.3. Ensure the cleartext attribute(s) are not present in 979 the to-be-signed AC 981 3. Add the EncryptedAttribute (with its multiple 982 values) to the AC 984 Note that the rule that each attribute type (the OID) 985 only occurs once may not hold after decryption. That is, 986 an AC MAY contain the same attribute type both in clear 987 and in encrypted form (and indeed more than once if the 988 decryptor is a recipient for more than one 989 EnvelopedData). One approach would be to merge attributes 990 following decryption in order to re-establish the "once 991 only" constraint. 993 name ietf-ac-encAttrs 994 OID { ietf-ac-attributes 6} 995 Syntax ContentInfo 996 values Multiple Allowed 998 4.6 PKC Extensions 1000 Public key certificate extensions which assist in AC 1001 handling are defined in this section. 1002 <> 1004 4.6.1 AAControls 1006 During AC validation a relying party has to answer the 1007 question "is this AC issuer trusted to issue ACs 1008 containing this attribute"? The AAControls PKC extension, 1009 intended to be used in CA and AC Issuer PKCs, MAY be used 1010 to help answer the question. The use of AAControls is 1011 further described in section 5. 1013 aaControls EXTENSION ::= { 1014 SYNTAX AAControls 1015 IDENTIFIED BY { ietf-ac-pkcexts-aaControls} 1016 } 1017 AAControls ::= SEQUENCE { 1018 pathLenConstraint INTEGER (0..MAX) OPTIONAL, 1019 permittedAttrs [0] AttrSpec OPTIONAL, 1020 excludedAttrs [1] AttrSpec OPTIONAL, 1021 permitUnSpecified BOOLEAN DEFAULT TRUE 1022 } 1023 AttrSpec::= SEQUENCE OF OBJECT IDENTIFIER 1025 The aaControls extension is used as follows: 1027 The pathLenConstraint if present is interpreted as in 1028 [RFC2459], but now restricts the allowed "distance" 1029 between the AA CA, (a CA directly trusted to include 1030 AAControls in its PKCs), and the AC issuer. 1032 The permittedAttrs field specifies a set of attribute 1033 types that any AC issuer below this AA CA is allowed to 1034 include in ACs. If this field is not present, it means 1035 that no attribute types are explicitly allowed (though 1036 the permitUnSpecified field may open things up). 1038 The excludedAttrs field specifies a set of attribute 1039 types that no AC issuer is allowed to include in ACs. If 1040 this field is not present, it means that no attribute 1041 types are explicitly disallowed (though the 1042 permitUnSpecified field may close things down). 1044 The permitUnSpecified field specifies how to handle 1045 attribute types which are not present in either the 1046 permittedAttrs or excludedAttrs fields. TRUE (the 1047 default) means that any unspecified attribute type is 1048 allowed in ACs; FALSE means that no unspecified attribute 1049 type is allowed. 1051 5. AttributeCertificate Validation 1053 This section describes a basic set of rules that all 1054 "valid" ACs MUST satisfy. Some additional checks are also 1055 described which AC verifiers MAY choose to implement. 1057 To be valid an AC MUST satisfy all of the following: 1059 1. the AC signature must be cryptographically correct 1060 and the AC issuer's PKC MUST be verified in accordance 1061 with [RFC2459] 1062 2. if the AC issuer is not directly trusted as an AC 1063 issuer (by configuration or otherwise), then the AC 1064 issuer's certification path must satisfy the additional 1065 PKC checks described below 1066 3. the time of evaluation MUST be within the AC 1067 validity (if the evaluation time is equal to either 1068 notBeforeTime or notAfterTime then the AC is timely, i.e. 1069 this check succeeds) 1070 4. if an AC contains attributes apparently encrypted 1071 for the AC verifier then the decryption process MUST not 1072 fail - if decryption fails then the AC MUST be rejected 1073 5. the AC targeting check MUST pass (see section 4.4.3 1074 above) 1075 6. if the AC contains any "unsupported" critical 1076 extensions then the AC MUST be rejected. 1078 "Support" for an extension in this context means: 1080 a. the AC verifier MUST be able to parse the extension 1081 value, and, 1082 b. where the extension value SHOULD cause the AC to be 1083 rejected, the AC verifier MUST reject the AC. 1085 The following additional certification path checks 1086 (referred to in (2) above) MUST all succeed: 1088 1. some CA on the AC's certificate path MUST be 1089 directly trusted to issue PKCs which preceed the AC 1090 issuer in the certification path, call this CA the "AA 1091 CA" 1092 2. all PKC's on the path from the AA CA down to and 1093 including the AC issuer's PKC MUST contain an aaControls 1094 extension as defined below (the PKC with the AA CA's as 1095 subject need not contain this extension) 1096 3. only those attributes in the AC which are allowed 1097 according to all of the aaControls extension values in 1098 all of the PKCs from the AA CA to the AC issuer, may be 1099 used for authorization decisions, all other attributes 1100 MUST be ignored (note that this check MUST be applied to 1101 the set of attributes following attribute decryption and 1102 that in such cases the ietf-ac-encAttrs type MUST also be 1103 checked) 1105 Additional Checks: 1107 1. The AC MAY be rejected on the basis of further AC 1108 verifier configuration, for example an AC verifier may be 1109 configured to reject ACs which contain or lack certain 1110 attribute types 1111 2. If the AC verifier provides an interface that allows 1112 applications to query the contents of the AC, then the AC 1113 verifier MAY filter the attributes from the AC on the 1114 basis of configured information, e.g. an AC verifier 1115 might be configured not to return certain attributes to 1116 certain targets. 1118 6. Revocation 1120 In many environments, the validity period of an AC is 1121 less than the time required to issue and distribute 1122 revocation information. Therefore, short-lived ACs do 1123 not require revocation support. However, long-lived ACs 1124 and environments where ACs enable high value transactions 1125 MAY require revocation support. 1127 In such cases, AC revocation status MAY be checked using 1128 the methods described in [RFC2459], but substituting the 1129 AC issuer wherever a CA is mentioned. 1131 Note however that this does not impose a requirement for 1132 conformant AC issuers to be able to issue CRLs. 1134 Where an AC issuer does not support revocation status 1135 checks for a particular AC, then an authority information 1136 access extension (id-pe-authorityInfoAccess) MUST be 1137 present and critical in the AC to indicate this. Where no 1138 authority information access is present, then the AC 1139 issuer is implicitly stating that revocation checks are 1140 supported and mechanisms in accordance with [RFC2459] 1141 MUST be provided to allow AC verifiers to establish the 1142 revocation status of the AC. 1144 The accessMethod used to handle this case is described 1145 above. 1147 7. Limited AC Acquisition Protocol 1149 <> 1158 There is clearly a requirement for an AC management 1159 protocol (or protocols, like [CMP] and [CMC]). Such 1160 management protocols are not specified in this document. 1161 There is also a requirement for a specification of an 1162 LDAP schema, which is also not specified here. 1164 In addition to such protocols, which may be more suited 1165 to management of long-term or more sensitive (i.e. more 1166 "powerful") ACs, there is a requirement for a very 1167 simple, explicitly limited AC acquisition protocol. 1169 This protocol is required for cases where an AC user 1170 wishes to acquire a "current" AC for an entity (possibly 1171 itself) leaving almost all details as to the content of 1172 the AC to the AA or whatever network service acts on its 1173 behalf. 1175 We call this protocol the Limited AC Acquisition Protocol 1176 (LAAP). The are two entities involved, the LAAP requestor 1177 (LRQ) and LAAP responder (LRP). The LR is typically an AC 1178 owner or an AC verifier; the LRP is typically the AA 1179 itself. 1181 LAAP is designed as a single-shot request/response 1182 protocol with no polling, retries, etc. 1184 The one and only feature of this protocol is to request 1185 an AC for a particular entity that may be either the 1186 requestor or some other entity. The response is the 1187 requested AC or an error. 1189 The security of the request and response (e.g. whether 1190 the requestor is authenticated or not) is out of scope 1191 and a matter for LAAP implementers. For example, an LRP 1192 may be configured so that it only ever issues ACs if the 1193 request is received over an authenticated channel (e.g. 1194 TLS with client authentication), or it may only issue 1195 "guest" privileges when the LRQ is not the owner of the 1196 AC. 1198 The protocol consists of a request message that may 1199 specify the identity of the AC owner (for the third party 1200 case), with an optional "profile". A profile is to be 1201 interpreted as a bilaterally agreed string that is mapped 1202 to a set of AC contents by the LRP. 1204 LACRequestMessage ::= SEQUENCE { 1205 owner [0] CHOICE{ 1206 baseCertificateID [0] IssuerSerial, 1207 -- the issuer and serial number of 1208 -- the owner's Public Key Certificate 1209 entityName [1] GeneralNames, 1210 -- the name of the claimant or role 1211 objectDigestInfo [2] ObjectDigestInfo 1212 -- if present, version must be v2 1213 } OPTIONAL, 1214 profile [1] UTF8String OPTIONAL 1215 } 1217 <> 1226 Each field is described below. 1228 "owner": when present this specifies that the LRQ wishes 1229 to acquire an AC for this owner. When absent, it means 1230 that the LRQ is requesting an AC for itself (the LRP 1231 should use the identity established from whatever 1232 underlying authentication is available). The rules for 1233 the owner field in the AC apply here (e.g. no use of 1234 objectDigestInfo). 1236 "profile": when present this is an request to the LRP 1237 that an AC matching a certain profile be returned. The 1238 definition of profiles is not in scope for this 1239 specification and is expected to be a local matter. This 1240 field allows some simple switching. 1242 Note that this definition means that the minimal LAAP 1243 request message consists of the octets `3000'H, an empty 1244 sequence. This message means "give me my current default 1245 AC please". 1247 LACResponseMessage ::= CHOICE { 1248 ac [0] AttributeCertificate, 1249 errorInfo [1] ErrorMsgContent -- from [CMP] 1250 } 1252 When an LRQ receives an AC from an LRP it SHOULD verify 1253 the AC. In addition the LRQ SHOULD ensure that the AC 1254 "matches" the LAAP request issued. The only matching 1255 which applies in general is to ensure that the LAAP 1256 request owner field and the AC owner field are identical. 1257 Implementations may of course include additional checks. 1259 We define the following HTTP based transport for LAAP. 1261 An LRQ should send a HTTP POST request to the LRP, the 1262 POST data should consist of the DER encoding of the 1263 LACRequestMessage. The response is expected to have the 1264 MIME type "application/x-laapmsg" with the message data 1265 containing the DER encoding of the LACResponseMessage. 1267 <> 1269 8. Conformance 1271 This specification defines two levels of conformance, 1272 basic and proxy-enabled. For each level the actors 1273 involved must meet different requirements. The intention 1274 is that support for basic conformance should allow for 1275 freely interoperable but fairly inflexible and 1276 "featureless" AC based authorization. Proxy-enabled 1277 conformance requires more effort from implementers, may 1278 not be as widely interoperable and is harder to 1279 administer, but does offer much more flexibility and many 1280 more features. 1282 A proxy-enabled AC issuer MUST be able to produce all of 1283 the attribute types and extensions specified above. 1285 A proxy-enabled AC verifier MUST "support" all of the 1286 attribute types and extensions specified above. 1288 "Support" in the previous paragraph means more than just 1289 parsing. It means that the AC verifier MUST be able to 1290 reject any AC which should not be valid at that target 1291 and MUST be able to make any attributes and extensions 1292 which were not fully processed available to the calling 1293 application. 1295 A proxy-enabled AC issuer is responsible to ensure that 1296 no AC produced could be accepted by a basic AC verifier 1297 in such a way as to cause a security breach. 1298 <> 1300 Basic conformance for an AC issuer means support for 1301 production of ACs which: 1303 1. MUST use the baseCertificateID owner field 1304 alternative 1305 2. MUST NOT be post-dated 1306 3. MAY contain AccessIdentity, Group and/or Role 1307 attributes with multiple values 1308 4. MUST NOT contain any other attributes which cannot 1309 safely be ignored by an AC verifier 1310 5. MAY contain the AuthorityKeyIdentifier extension 1311 6. MUST contain no critical extensions (and hence is 1312 not proxiable) except for authorityInformationAccess 1313 where revocation status checks are not provided 1314 7. MUST NOT contain encrypted attributes 1316 Basic conformance also requires support for the 1317 AAControls PKC extension. A basic AC issuer MUST also 1318 support LAAP as specified in section 7 above. 1320 Basic conformance for an AC verifier means support for 1321 the validation of ACs which are produced by basic AC 1322 issuers. 1324 A basic AC verifier MAY ignore the presence of any 1325 unsupported attributes or extensions (of course it must 1326 reject all ACs which contain unsupported critical 1327 extensions) and need only make the values of the 1328 remaining attributes available to applications. 1330 A basic AC verifier MUST support the AAControls PKC 1331 extension. 1333 9. Security Considerations 1335 <> 1337 10. References 1339 [CMC] Myers, M., et al. "Certificate Management 1340 Messages over CMS", 1341 draft-ietf-pkix-cmc-03.txt, March 1999. 1342 [CMP] Adams, C., Farrell, S., "Internet X.509 1343 Public Key Infrastructure - Certificate 1344 Management Protocols", RFC2510. 1345 [CMS] Housley, R., "Cryptographic Message Syntax", 1346 draft-ietf-smime-cms-12.txt, March 1999. 1347 [ESS] Hoffman, P., "Enhanced Security Services for 1348 S/MIME", 1349 draft-ietf-smime-ess-12.txt, March 1999. 1351 [RFC2459] Housley, R., Ford, W., Polk, T, & Solo, D., 1352 "Internet Public Key Infrastructure - X.509 1353 Certificate and CRL profile", RFC2459. 1354 [RFC2119] Bradner, S., "Key words for use in RFCs to 1355 Indicate Requirement Levels", RFC 2119. 1356 [X.509] ITU-T Recommendation X.509 (1997 E): 1357 Information Technology - Open Systems 1358 Interconnection - The Directory: 1359 Authentication Framework, June 1997. 1360 [X.208-88] CCITT. Recommendation X.208: Specification 1361 of Abstract Syntax Notation One (ASN.1). 1362 1988. 1363 [X.209-88] CCITT. Recommendation X.209: Specification 1364 of Basic Encoding Rules for Abstract Syntax 1365 Notation One (ASN.1). 1988. 1366 [X.501-88] CCITT. Recommendation X.501: The Directory - 1367 Models. 1988. 1368 [X.509-88] CCITT. Recommendation X.509: The Directory - 1369 Authentication Framework. 1988. 1371 [X.509-97] ITU-T. Recommendation X.509: The Directory - 1372 Authentication Framework. 1997. 1373 [XPDAM] ISO 9594-8 Information Technology - Open 1374 systems Interconnection - The Directory: 1375 Authentication Framework - Proposed Draft 1376 Amendment 1: Certificate Extensions, 1377 September 1998. 1379 Author's Addresses 1381 Stephen Farrell, 1382 SSE Ltd. 1383 Fitzwilliam Court, 1384 Leeson Close, 1385 Dublin 2, 1386 IRELAND 1388 tel: +353-1-216-2910 1389 email: stephen.farrell@sse.ie 1391 Russell Housley, 1392 SPYRUS, 1393 381 Elden Street, 1394 Suite 1120, 1395 Herndon, VA 20170, 1396 USA 1398 email: housley@spyrus.com 1400 Full Copyright Statement 1402 Copyright (C) The Internet Society (date). All Rights 1403 Reserved. 1405 This document and translations of it may be copied and 1406 furnished to others, and derivative works that comment on 1407 or otherwise explain it or assist in its implementation 1408 may be prepared, copied, published and distributed, in 1409 whole or in part, without restriction of any kind, 1410 provided that the above copyright notice and this 1411 paragraph are included on all such copies and derivative 1412 works. In addition, the ASN.1 module presented in 1413 Appendix B may be used in whole or in part without 1414 inclusion of the copyright notice. However, this 1415 document itself may not be modified in any way, such as 1416 by removing the copyright notice or references to the 1417 Internet Society or other Internet organizations, except 1418 as needed for the purpose of developing Internet 1419 standards in which case the procedures for copyrights 1420 defined in the Internet Standards process shall be 1421 followed, or as required to translate it into languages 1422 other than English. 1424 The limited permissions granted above are perpetual and 1425 will not be revoked by the Internet Society or its 1426 successors or assigns. This document and the information 1427 contained herein is provided on an "AS IS" basis and THE 1428 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 1429 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1430 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1431 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 1432 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1433 PARTICULAR PURPOSE. 1435 Appendix A: Samples 1437 tbs 1439 Appendix B: "Compilable" ASN.1 Module 1441 <> 1443 Appendix C: Open Issues 1445 This appendix lists open issues to be resolved (in order 1446 of occurrence in the body of the document). 1448 1. Additional introductory text is required to motivate 1449 the use of ACs 1450 2. The ASN.1 has to be synched with the ISO FPDAM where 1451 necessary 1452 3. An OID for ietf-ac has to be allocated 1453 4. The objectDigest choice for owner has to be a MUST 1454 NOT or else profiled (and explained!) 1455 5. Are "restrictions" needed? 1456 6. Is "IetfAttrSyntax" needed? 1457 7. Should OS-specific group attribute types be defined? 1458 8. More explanatory text for encryptedAttributes is 1459 needed. 1460 9. Is a new AC acquisition protocol required? If not, 1461 how are ACs acquired? If so, should it be part of this 1462 specification? 1463 10. Are different conformance levels needed? If so, are 1464 these the right ones? 1465 11. Security considerations text needed 1466 12. References section to be fixed 1467 13. Compilable ASN.1 and samples are needed