idnits 2.17.1 draft-ietf-pkix-ocspx-00.txt: -(64): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(290): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(316): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(317): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(318): 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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. == There are 7 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 1 longer page, the longest (page 1) being 894 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 223 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 118 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2560], [RFC2459]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 207: '...The extensions SHOULD support intellig...' RFC 2119 keyword, line 218: '...The extensions SHOULD allow a client t...' RFC 2119 keyword, line 229: '...The extensions SHOULD support the dele...' RFC 2119 keyword, line 246: '...f such a protocol SHOULD be supported....' RFC 2119 keyword, line 336: '...ded status codes SHALL be reported usi...' (19 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 36 has weird spacing: '...tandard exten...' == Line 327 has weird spacing: '...nseData res...' == Line 328 has weird spacing: '...esponse singl...' -- 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 (September 03, 1999) is 8996 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) == Missing Reference: 'RFC2459' is mentioned on line 60, but not defined ** Obsolete undefined reference: RFC 2459 (Obsoleted by RFC 3280) == Missing Reference: 'TBS' is mentioned on line 343, but not defined -- Looks like a reference, but probably isn't: '1' on line 622 -- Looks like a reference, but probably isn't: '2' on line 623 -- Looks like a reference, but probably isn't: '3' on line 624 -- Looks like a reference, but probably isn't: '4' on line 625 -- Looks like a reference, but probably isn't: '5' on line 374 -- Looks like a reference, but probably isn't: '6' on line 375 -- Looks like a reference, but probably isn't: '7' on line 376 -- Looks like a reference, but probably isn't: '8' on line 377 -- Looks like a reference, but probably isn't: '9' on line 378 -- Looks like a reference, but probably isn't: '0' on line 578 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Phillip Hallam-Baker 2 draft-ietf-pkix-ocspx-00.txt VeriSign Inc. 3 September 03, 1999 4 Expires in six months 6 OCSP Extensions 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with all pro- 11 visions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months and 18 may be updated, replaced, or obsoleted by other documents at any time. It 19 is inappropriate to use Internet-Drafts as reference material or to cite 20 them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The OCSP protocol [RFC2560] enables online validation of the reliability of 31 a digital certificate. RFC2560 defines a mandatory-to-implement mechanism 32 supporting the revocation status of the certificate and defines and op- 33 tional extension mechanism to support a richer set of semantics (e.g. full 34 path validation by the OCSP server). 36 This document defines Internet-standard extensions to OCSP that enable a 37 client to delegate processing of certificate acceptance functions to a 38 trusted server. The client may control the degree to which delegation takes 39 place. In addition limited support is provided for delegating authorization 40 decisions. 42 1 Introduction 44 For an application to make an informed decision as to whether it trusts a 45 digital certificate the application must have knowledge of the certificate 46 itself, a set of trusted public keys from which certificate chains may be 47 constructed, a set of intermediate certificate authorities from which the 48 trust chain may be constructed and the validation status of every certifi- 49 cate used to construct the trust chain. 51 In a typical PKI deployment these data frequently originate from multiple 52 sources. Certificates and certificate status information will be issued by 53 multiple Certification Authorities. In the typical case authorization data 54 will be maintained separately. As the task of managing these disparate 55 sources of data required to decide upon the acceptability of digital cer- 56 tificates increases it is advantageous to delegate this task to one or more 57 specialist applications. 59 These data must then be integrated into certificate path processing compli- 60 ant to RFC 2459 [RFC2459]. In some environments, it may be useful to defer 61 this integration to a trusted server, thereby relieving certificate using 62 functions of the need to acquire this information and integrate it into 63 compliant path processing logic. It may also be useful to defer this inte- 64 gration to a trusted server due to the server�s ability to more easily com- 65 bine certificate path processing with other authorization data. Finally, a 66 trusted-server approach to certificate validation enables straightforward 67 design and implementation of a trust management system capable of immediate 68 response to certificate or authorization revocation. 70 The basic OCSP protocol [RFC2560] provides a simple mechanism for communi- 71 cating certificate revocation status and an extension mechanism for commu- 72 nicating additional types of certificate validation information. The exten- 73 sibility mechanism can accommodate advanced needs for certificate valida- 74 tion beyond simple revocation status. 76 This document defines Internet-standard OCSP extensions to ensure 77 interoperability among diverse PKI-based trust management systems or net- 78 works. 80 These extensions allow a client to delegate the tasks of deciding whether a 81 certificate should be relied upon and whether it is acceptable for a par- 82 ticular operation. 84 2 Principal Applications 86 Before presenting the specific requirements for the extensions proposed we 87 first consider some applications whose needs have motivated this protocol. 89 2.1 Embedded Systems 91 We anticipate a substantial increase in the use of PKI by embedded systems. 92 In the short term this increase will be driven by the deployment of IPSEC 93 capable gateways such as routers and firewalls. In the longer term, how- 94 ever, it is to be expected that most embedded systems will support some 95 kind of security based on PKI. 97 Such devices are typically subject to significant constraints in the proc- 98 essing power and persistent storage that may be allocated to PKI support. 99 Support for operator interaction is limited, if indeed the device has any 100 I/O capability at all other than the network interface. Neither constraint 101 is likely to be affected by progress in technology since market demand 102 tends towards low cost devices. 104 Moreover, embedded devices are typically expected to have an operating 105 lifetime significantly longer than application software. Suppliers are con- 106 cerned to minimize the amount of maintenance required. Offloading certifi- 107 cate related processing functionality maximizes the useful lifetime of an 108 installed base of such devices while trust management technology moves for- 109 ward. 111 2.2 Wireless Devices 113 We also anticipate a substantial increase in the use of PKI enabled wire- 114 less devices. These devices share many of the constraints of embedded sys- 115 tems. Processing and memory resources are highly constrained, in this case 116 by battery lifetime as well as cost. Nor is it practical to support a com- 117 plex user interface on a handheld device. 119 It is possible for wireless devices to communicate directly with each 120 other. In a typical application however the wireless device communicates 121 with a static base station which in turn is connected to a network. It is 122 highly desirable to offload processing tasks from the mobile unit to the 123 base station. 125 2.3 Centralized Trust and Authorization Management 127 As previously discussed, determination of the acceptability of a certifi- 128 cate for a particular operation requires a substantial quantity of data, 129 management of which is a complex task. In a large enterprise it is desir- 130 able to centralize this task, or at least restrict the number of systems 131 performing it. 133 In addition to eliminating the need to distribute significant quantities of 134 data to relying applications, centralization of certificate acceptance 135 functions improves enterprise-wide consistency in the enforcement of poli- 136 cies relating to certificate acceptance. 138 Centralized management also yields advantages in auditing and control. Sus- 139 picious behavior patterns may be more readily detected if audit information 140 is centralized. If a suspicious behavior pattern is detected, further ac- 141 cess may be denied, either by automatic revocation or suspension of the 142 certificate, or by withdrawing authorization. 144 2.4 Use of Attribute Certificates 146 Attribute Certificates provide a means of distributing auxiliary informa- 147 tion which, for certain reasons, it is not desirable to include within a 148 public key certificate. Such information is typically used to make authori- 149 zation decisions. 151 Attribute Certificates present the advantages of distributing authorization 152 information in a non-repudiable form. However, use of attribute certifi- 153 cates has been widely criticized as overburdening client implementations, 154 particularly since effective use of authorization certificates appears to 155 require application specific processing rules. 157 Delegating certificate-based access control decision functions, including 158 the processing of attribute certificate chains to an OCSP-X responder miti- 159 gates these objections. Client implementations need only implement the 160 OCSP-X request and response protocol. Sites may construct conventions and 161 processing rules of arbitrary complexity for enforcement of authorization 162 attributes and still rely on standard clients, regardless of the use or 163 non-use of attribute certificates. 165 2.5 Single Sign-On 167 A principal advantage for PKI based security is the ability to support sin- 168 gle sign-on. Password based authentication has the substantial disadvantage 169 that the authentication process itself requires the password to be revealed 170 to or previously known by the authenticating party. Public key based 171 authentication does not require a secret to be revealed or known in order 172 for the authenticating party to know that it is known. 174 Although PKI provides comprehensive support for authentication, access con- 175 trol requires both authentication and authorization to take place. It is 176 not enough to know who a person is, it is equally important to know what 177 that person is permitted to do. 179 Although many protocols already exist to support distribution of authoriza- 180 tion information there is considerable advantage to supporting delegation 181 to a single enterprise-level authority of all aspects of the access control 182 decision that require external data. 184 3 Requirements 186 The following requirements have been identified as important in the meeting 187 of the needs of the applications described above. 189 3.1 Support for Aggregation of Trust Information 191 On the basis of the prior analysis, there exists a need to aggregate at a 192 trusted server all information relevant to determining the acceptability of 193 a digital credential in a given context. This information includes but is 194 not limited to: 196 * End-user Public Key Certificates 197 * CA public key certificates 198 * Attribute Certificates 199 * Certificate Revocation Lists or certificate status databases 200 * Data provided by other OCSP and OCSP-X responders 202 The means by which this information is obtained by an OCSP-X server is be- 203 yond the scope of this specification. 205 3.2 Support for Intelligent Query 207 The extensions SHOULD support intelligent queries, that is queries which 208 are specifically relevant to the client decision to trust a certificate. 210 This requirement is distinct from the type of query supported by directory 211 servers, including LDAP servers and X.500 servers. The data model upon 212 which these servers are designed does not support the specific types of 213 query required. Nevertheless it would be highly appropriate for a single 214 server to support both OCSP-X and LDAP retrievals from a common database. 216 3.3 Delegated Trust Decision 218 The extensions SHOULD allow a client to delegate all aspects of deciding 219 the authenticity and validity of a certificate. 221 It is NOT a requirement that every response be justified by providing in- 222 formation such as the certificate chain generated and relevant CRLs. The 223 objective of OCSP-X is to permit a client to simplify certificate valida- 224 tion decisions by offloading them to an external client. This objective is 225 negated if the client is then required to duplicate the trust decision. 227 3.4 Delegated Authorization Decision 229 The extensions SHOULD support the delegation of authorization decisions to 230 the OCSP-X responder. 232 It is not however a requirement for that the OCSP-X responder provide in- 233 formation to the relying application so that the relying application may 234 duplicate the authorization decision. 236 3.5 Support for Status Update Notification Protocols 238 In many circumstances it is necessary for an application to track changes 239 in the validity of a certificate after the initial decision to trust the 240 certificate has been made. 242 A wide variety of architectural approaches are appropriate to meet this re- 243 quirement and the specification of a specific protocol for the purpose is 244 outside the scope of this particular draft. It is not therefore a require- 245 ment that these extensions propose a specific notification protocol but use 246 of such a protocol SHOULD be supported. 248 Pending the development of such a protocol, clients which need to track 249 changes in certificate validity may do so by polling the OCSP-X responder. 250 It is therefore a requirement that the protocol support this mode of use 251 efficiently. 253 4 Non-Requirements 255 Support for the following features was considered but rejected. 257 4.1 Delegated Key Exchange 259 Support for delegation of key exchange processing was considered but re- 260 jected as being more appropriate for independent discussion. 262 A client relying on an OCSP server for trust path evaluation might also 263 delegate other aspects of a cryptographic negotiation scheme such as key 264 exchange. 266 While it is highly desirable for embedded devices such as IPSEC routers to 267 offload complex processing tasks to other processors support for such a 268 feature would inevitably involve strong interdependencies with the key ex- 269 change protocols to be supported. The complexity of such a protocol would 270 therefore be considerable and it is not clear that a sufficient degree of 271 generality across protocols could be achieved. 273 4.2 Alternate Response Syntax 275 Support for an alternative response syntax was considered but rejected as 276 being more appropriate for independent discussion. 278 The advantage of an alternate response syntax is that it would permit de- 279 vices with limited processing capability to receive responses encoded in a 280 simpler syntax than ASN.1. While construction of an ASN.1 BER encoded re- 281 quest message is not unduly burdensome on a client implementation the pars- 282 ing of OCSP responses is considered unnecessarily complex by many. 284 4.3 Modification of Authorization Data 286 Support for client requests to modify authorization data was considered but 287 rejected as introducing an unacceptable degree of additional complexity 288 into the protocol. 290 Support for such a feature would permit implementation of client �owner- 291 ship� of resources whose authorization data is managed by the OCSP-X 292 server. Such support would however require a considerably more detailed 293 definition of the authorization framework than specification of the re- 294 sources for which authorization is requested and the mode of access re- 295 quested. In particular it would be necessary to commit to a data model for 296 the authorization data. 298 While support for such a feature is likely to prove necessary in time, the 299 substantial degree of additional complexity involved strongly suggests that 300 it preferable to address the issue separately. 302 5 OCSP Message Framework 304 The OCSP message format is defined in RFC 2560. This section describes the 305 use made of the OCSP message format within this document. 307 5.1 Extension Framework 309 The OCSP extension framework permits additional data to be incorporated in 310 an OCSP message such that the extension data applies to an entire request 311 or to specific certificate in a response. Similarly the framework permits 312 extensions in a response to apply to either the response as a whole or to a 313 specific certificate in the response. 315 In this document we refer to extensions which apply to a message as a whole 316 as �message extensions�. Extensions which apply only to a specific certifi- 317 cate are referred to as �certificate specific extensions�. Extensions that 318 MAY be employed in either manner are referred to as simply �extensions�. 320 These terms correspond to the ASN.1 structures defined in RFC 2560 as fol- 321 lows: 323 Identification Structure Element 325 Response Message OCSPRequest requestExtensions 326 Certificate Specific Response Request singleRequestExtensions 327 Reply Message ResponseData responseExtensions 328 Certificate Specific Reply SingleResponse singleExtensions 330 5.2 Status Reporting 332 OCSP-X defines a number of extended response codes. It is intended that 333 these augment the response codes defined by RFC2560, providing additional 334 status information where needed. 336 OCSP-X extended status codes SHALL be reported using the id-pkix-ocspx- 337 status extension OID in the response as defined bellow. 339 6 Extension Elements 341 All extensions are tagged using OIDs formed of the existing OCSP arc. 343 id-pkix-oscpx OBJECT IDENTIFIER ::= { id-pkix-ocsp [TBS] } 345 An OCSP client MAY signal support for OCSP response extensions by including 346 the id-pkix-ocspx-support OID as an OCSP acceptable response type. Alterna- 347 tively, clients that include OCSP extensions in their request SHALL be ca- 348 pable of support for OCSP response extensions in the manner defined by this 349 specification. 351 id-pkix-ocspx-support OBJECT IDENTIFIER ::= { id-pkix-ocspx 1 } 353 A server MAY advertise that it supports the OCSP-X extensions by including 354 the id-pkix-ocspx-support OID as a message extension in any OCSP response. 355 The OID id-pkix-ocspx-support MUST NOT be included as a certificate spe- 356 cific extension. 358 If a server receives no signal from the client as defined above, it MAY in- 359 clude response extensions, but MUST be capable of basic OCSP as defined in 360 RFC2560. 362 Where extended status codes are defined these are returned as response ex- 363 tensions using the id-pkix-ocspx-status OID and ExtendedStatus structure: 365 id-pkix-ocspx-support OBJECT IDENTIFIER ::= { id-pkix-ocspx 2 } 367 ExtendedStatus :== SEQUENCE OF SingleExtendedStatus 369 SingleExtendedStatus :== CHOICE { 370 TRUST_NOT_SUPPORTED [1] EXPLICIT NULL 371 ROOT_NOT_ACCEPTABLE [2] EXPLICIT NULL 372 TRUST_ROOT_REQUIRED [3] EXPLICIT NULL 373 RULE_NOT_SUPPORTED [4] EXPLICIT NULL 374 TRUST_PATH_NOT_FOUND [5] EXPLICIT NULL 375 TRUST_PATH_VALIDATED [6] EXPLICIT NULL 376 CERTIFICATE_NOT_TRUSTED [7] EXPLICIT NULL 377 REGISTRATION_NOT_SUPPORTED [8] EXPLICIT NULL 378 AUTHORIZATION_NOT_SUPPORTED [9] EXPLICIT NULL 379 } 381 6.1 Specify Trust Root 383 The specify trust root extension is used to specify the trust root(s) for a 384 trust delegation request. 386 If the trust root is not specified in the request the selection of trust 387 roots is delegated to the OCSP status server. 389 Request 391 id-pkix-ocspx-root OBJECT IDENTIFIER ::= { id-pkix-ocspx 3 } 393 TrustRoot ::= SEQUENCE { 394 certificates SEQUENCE OF CertID } 396 By including a specific trust root, client indicate a need to determine if 397 the certificate identified in the request is trusted by the server under 398 the authority of the identified root. An affirmative response from the 399 server confirms that the server has, among other functions, cryptographi- 400 cally proven by trust path logic that the signature on the subject certifi- 401 cate is valid under the indicated root. The means by which the server ac- 402 quires the information necessary to arrive at this conclusion is beyond the 403 scope of this specification. One means could be by prior acquisition of 404 the appropriate cross-certificate. 406 Response 408 If the server is unable to develop a trust chain from the subject certifi- 409 cate to the indicated trust root, an error code is returned. 411 TRUST_NOT_SUPPORTED Trust Root Processing is not supported 412 ROOT_NOT_ACCEPTABLE The specified trust root is not known to the server- 413 TRUST_ROOT_REQUIRED Explicit specification of the trust root is required 414 to permit trust delegation. 416 6.2 Specify Processing Rules 418 In certain circumstances a client may require the OCSP server to apply a 419 particular set of certificate path processing rules 421 Request 423 The client may specify the processing rules under which the trust chain is 424 to be constructed. If no trust rules are specified the responder SHOULD em- 425 ploy the processing rules specified by RFC2459. 427 id-pkix-ocspx-rules OBJECT IDENTIFIER ::= { id-pkix-ocspx 4 } 429 Rules ::= SEQUENCE { 430 rules SEQUENCE OF Rule } 432 Rule ::= SEQUENCE { 433 oid OBJECT IDENTIFIER} 435 Response 437 If the server is unable to support all of the path processing rules speci- 438 fied it MUST return an error. 440 RULE_NOT_SUPPORTED The requested processing rules are not supported by the 441 server. 443 6.3 Evaluate Trust Path 445 The client requests that the OCSP-X responder attempt to construct a valid 446 trust path originating from a trust root. Optionally the client may request 447 that the responder return part or all of the data used to construct and 448 validate the certificate chain. 450 Request 452 id-pkix-ocspx-evaluate OBJECT IDENTIFIER ::= { id-pkix-ocspx 5 } 454 Evaluate ::= SEQUENCE { 455 reportTrustChain [1] IMPLICIT NULL 456 reportValidation [2] IMPLICIT NULL 457 returnTrustChain [3] IMPLICIT NULL 458 returnValidation [4] IMPLICIT NULL } 460 Response 462 CERTIFICATE_NOT_TRUSTED The certificate is not trusted 464 TRUST_PATH_VALIDATED The certificate is trusted 466 TRUST_PATH_NOT_FOUND The trust status of the certificate could 467 not be determined. 469 6.4 Register Trust Path 471 A client may employ the register trust path extension to notify the server 472 that the validity of a trust path will be of ongoing significance to the 473 client during a specified time interval A client MAY optionally request no- 474 tification if a certificate reported to the client as being valid is re- 475 voked during the specified time interval. 477 The specific actions to be taken if a trust path be invalidated while a 478 client is relying upon it are a matter for site specific policy. 480 OCSP-X responders MAY support the use of an OCSP response as a notification 481 mechanism. In this case the notifyUri member is present and specifies by 482 means of a URI both the transfer protocol (e.g. HTTP) and the address to 483 which the notification is to be sent. 485 The use of OCSP-X messages over HTTP as a notification protocol is vulner- 486 able to a denial of service attack however. An extension mechanism is sup- 487 ported to allow improved notification mechanisms to be specified in future 488 documents. 490 Request 492 id-pkix-ocspx-register OBJECT IDENTIFIER ::= { id-pkix-ocspx 6 } 494 Register ::= SEQUENCE { 495 until [0] EXPLICIT GeneralizedTime OPTIONAL 496 notifyUri [1] EXPLICIT OCTET STRING OPTIONAL 497 notificationExtensions [2] EXPLICIT Extensions OPTIONAL} 499 Response 501 REGISTRATION_NOT_SUPPORTED Registration is not supported 503 NOTIFICATION_NOT_SUPPORTED Notification is not supported 505 6.5 Authorization Delegation 507 The basic OCSP response provides only authentication information. In many 508 applications it is desirable to supply both authentication and authoriza- 509 tion from a centralized source. 511 A request for authorization delegation must specify both the party which 512 requests access and the resource for which access is requested. In addition 513 a request for authorization MAY present a chain of attribute certificates 514 containing information relevant to the authorization decision. 516 Resources are identified using URIs according to a convention chosen by the 517 client, the definition of which is outside this document. URIs provide a 518 uniform syntax for identification of resources in a hierarchical fashion. 520 A request for authorization delegation need specify only the URI of the re- 521 source for which access is being requested and the specific mode of access 522 requested. 524 Four modes of access control are supported, GET, PUT, EXECUTE and LINK. The 525 GET and PUT and EXECUTE modes correspond respectively to the traditional 526 Read and Write and EXECUTE modes supported by conventional operating sys- 527 tems. The LINK mode corresponds to a superset of the CONTROL mode of a con- 528 ventional operating system and when granted permits the recipient to spec- 529 ify and meta-information related to the resource, including authorization 530 information. 532 Where finer grained access control is required than is supported by these 533 four modes implementations may specify access control at an arbitrary 534 granularity by using an extended URI convention. 536 Each authorization request specifies one or more URIs that identify re- 537 sources for which authorization is requested. The convention by which URIs 538 refer to resources is discussed further in Appendix A. Specification of 539 this convention is outside the scope of this document. 541 The responder SHALL either return the extended response code 542 AUTHORIZATION_NOT_SUPPORTED or return an AuthorizationResponse certificate 543 specific extension. 545 The AuthorizationResponse SHALL consist of a number (possibly zero) of Re- 546 sourceResponse structures. Each ResourceResponse structure SHALL describe 547 the authorization status of the entity identified by the respective cer- 548 tificate with respect to the range of resources identified by the specified 549 URI. 551 The range of resources identified by the URIs in the authorization response 552 MAY be more specific, less specific or equally specific as the range speci- 553 fied in the request. 555 In cases where the party for whom authorization is requested has authoriza- 556 tion to access a broad range of resources and the client requests access to 557 a specific resource within that range the responder MAY specify the broader 558 range in its response. This permits the client to cache the authorization 559 response, eliminating the need for repeated authorization requests for 560 closely related resources. 562 In cases where the party for whom authorization is requested has authoriza- 563 tion to access a specific range of resources the and client requests access 564 to a broad range of resources which encompasses it the responder MAY spec- 565 ify the more specific range in its response. This permits the client to 566 provide navigation menus tailored to the specific set of resources to which 567 the party is permitted access. 569 Request 571 The request specifies a list of one or more resources for which authoriza- 572 tion is requested. 574 id-pkix-ocspx-authorize OBJECT IDENTIFIER ::= { id-pkix-ocspx 7 } 576 AuthorizationRequest ::= { 577 requests SEQUENCE OF ResourceData 578 certs [0] EXPLICIT SEQUENCE OF Certificate 579 } 581 ResourceData { 582 uri Uri 583 mode AuthorizationMode} 585 AuthorizationMode ::= SEQUENCE { 586 get [1] NULL 587 put [2] NULL 588 execute [3] NULL 589 link [4] NULL } 591 Uri ::= OCTET STRING 593 Response 595 The id-pkix-ocspx-authorize-response certificate specific response exten- 596 sion specifies a sequence of one or more ResourceResponse structures each 597 of which reports the authorization status of the party identified in the 598 respective certificate with respect to a range of resources. 600 The following authorization statuses may be reported: 602 permit Access to the specified resource is permitted 604 deny Access to the specified resource is denied 606 unknown The responder does not know the authorization status of the 607 resource. 609 refused The responder refuses to disclose the authorization status 610 of the resource. 612 id-pkix-ocspx-authorize-response 613 OBJECT IDENTIFIER ::= { id-pkix-ocspx 8 } 615 AuthorizationResponse ::= SEQUENCE OF ResourceResponse 617 ResourceResponse :== SEQUENCE { 618 resource ResourceData 619 status AuthorizationStatus } 621 AuthorizationStatus :== CHOICE { 622 permit [1] EXPLICIT 623 deny [2] EXPLICIT 624 unknown [3] EXPLICIT 625 refused [4] EXPLICIT} 627 AUTHORIZATION_NOT_SUPPORTED The OCSP-X responder does not support the 628 authorization extensions. 630 7 Security Issues 632 7.1 Security of the OCSP-X Responder 634 Compromise of an OCSP-X responder would severely impact the security of any 635 application relying upon it. 637 Centralized management of information required for trust path processing 638 could potentially introduce the possibility of a denial of service attack. 639 The scope for denial of service attacks does not appear to be substantially 640 increased in the typical enterprise implementation scenarios however. 642 In the case where applications delegate any or all of the trust decision 643 process itself to the OCSP-X responder, compromise of the OCSP-X responder 644 constitutes compromise of the application itself for all practical pur- 645 poses. 647 Both risks may if necessary be mitigated by means of deployment of multiple 648 OCSP-X servers configured in such a manner that the decisions made by each 649 server are audited by one or more other servers. 651 7.2 Audit 653 An OCSP-X server may be employed to enforce system audit requirements. In 654 such a configuration the use of wildcard responses in authorization re- 655 sponses must be carefully considered if the audit trail is to be suffi- 656 ciently detailed. 658 7.3 Notification Protocol Subject to Denial of Service Attack 660 The simple notification protocol described is vulnerable to a denial of 661 service attack. Nevertheless the protocol described has value in applica- 662 tions where either the possibility of a denial of service attack is not 663 present or where such an attack is prevented by a separate protocol, defi- 664 nition of which is outside the scope of this draft. 666 8 Collected Syntax 668 [To be specified] 670 9. References 672 [RFC2560] X.509 Internet Public Key Infrastructure Online Certificate 673 Status Protocol, M. Myers, R. Ankney, A. Malpani, S. Galperin, 674 C. Adams, RFC 2560, March 1999 676 10 Acknowledgements 678 The author would like to acknowledge the extensive contribution made to 679 this draft at an early stage by Michael Myers and Warwick Ford. In addition 680 some of the ideas presented were previously presented by Ambarish Malpani 681 and Paul Hoffman in their August 1999 Internet draft Simple Certificate 682 Validation Protocol (SCVP). This draft builds upon this earlier work and on 683 comments made on both documents and to the IETF mailing list by many people 684 including Carlisle Adams, Barbara Fox, Todd Glassey, Mack Hicks, Bob Juene- 685 man, Steve Kent, Dennis Pinkas, Brian LaMachia, Alan Lloyd, Rich Saltz, Pe- 686 ter Williams and Michael Zolotarev. 688 11 Author�s Address 690 Dr Phillip M. Hallam-Baker 691 VeriSign Inc. 692 301 Edgewater Place 693 Wakefield 694 MA 01880 695 pbaker@VeriSign.com 697 Appendix A Authorization Example 699 For either authorization or authentication to be performed in a uni- 700 form manner across a network it is of course essential that the relevant 701 parties agree on a uniform namespace for 'who' and 'what'. 703 The case of 'who' is already dealt with by X.509v3 / PKIX. The case 704 of 'what' is more complex since most of the resources to be identified are 705 local. Some form of abstract namespace is required. It is essential that 706 the central database(s) in which authorization data is maintained and the 707 parties relying upon those databases have a common agreement as to whats 708 what. 710 Example: 712 Widgets 'R Us (wideget.test) has two departments, manufacturing and 713 sales. Both departments separately manage ERP systems which are primarily 714 for their own use but a limited number of personnel need access to both. 716 The sales ERP system is maintained on a collection of servers called: 718 erp1.sales.widget.test 719 erp2.sales.widget.test 721 The ERP system supports three basic access levels, Salesman, Manager 722 and Administrator. These access levels are mapped onto URIs as follows: 724 Salesperson URN:sales-widget.test/erp/salesperson 725 Manager URN:sales-widget.test/erp/manager 726 Administrator URN:sales-widget.test/erp/administrator 728 Note that the sysops have decided to hide the fact that the ERP sys- 729 tem is maintained on two separate systems since they want both to use iden- 730 tical 732 In this particular case the delegation of authorization functions to 733 the central system is only partial. The ERP system accepts external input 734 that informs it of the seniority/access role of the individual concerned - 735 the type of information that would generally be handled by a corporate 736 admin and is usefully shared between applications. 738 The ERP system is also tracking the ownership status of resources 739 created by its users. When a salesman creates a particular customer ac- 740 count, that salesman has 'ownership' of that resource and may well have 741 privileged access to it. 743 What the central authorization system is doing is offloading the need 744 to create new user accounts in the ERP system as salespeople join and 745 leave. A typical interaction therefore is: 747 1. Alice is hired as a salesperson. 748 1: She is issued a digital certificate 'alice' 749 2: An authorization record is created of the form 750 PERMIT alice URN:sales-widget-test/erp/salesperson 752 2. Alice accesses the ERP system for the first time 753 1: There is no account for alice 754 2: An OCSP-X request is made to see if alice is authorized 755 [access URN:sales-widget-test/erp/salesperson/menu] 756 The responder reports Alice is authorized to do anything under 757 URN:sales-widget-test/erp/salesperson 758 3: The ERP application notes that alice is authorized to be 759 a salesperson and creates an account for her. 761 3. Alice accesses the ERP system for the second (or nth) time 762 1: The ERP system notes there is an account for alice 763 2: An OCSP-X request is made to see if alice is still 764 authorized [access URN:sales-widget-test/erp/salesperson] 765 3: alice is still authorized - good! 767 4. Alice is promoted to manager 768 1: Her entry in the OCSP-X server is modified to reflect her 769 new status. 771 5. Alice is suspended after refusing to use the CSR system to report 772 that the CSR system is down and not accepting reports. 773 1: Her authorizations for operations are withdrawn at the 774 OCSP-X system. Her certificate is neither revoked, nor 775 suspended however since she still is Alice and she still 776 needs access to her 401K plan (she is going to need it 777 soon!) 779 6. Alice is fired 780 1: Her certificate is revoked 781 2: The OCSP-X server is informed 783 3: OPTIONAL, if the notification process has been used the 784 OCSP-X server could notify the certificate management system 785 of any applications currently relying on the certificate for 786 authorization] 788 7. Alice attempts to access the ERP system 789 1: The ERP system notes there is an account for alice 790 2: An OCSP-X request is made to see if alice is still 791 authorized [access URN:sales-widget-test/erp/salesperson] 792 3: alice is not authenticated - and refused access 794 There is a variant of this scenario which is worth mention. In this variant 795 it is important that Alice be only presented with menu items for which she 796 is permitted access. The relying application must therefore know her per- 797 missions without actually instigating an operation itself. 799 Requirement: Support some sort of generic query interface. 801 This may be supported by permitting a responder to reply with the least 802 specific mode of access permitted when an over-general request is made. 804 In this scenario the OCSP-X responder would generate its initial startup 805 screen by requesting whether Alice had permission to access URN:sales- 806 widget-test/erp/ The responder would then reply that she only had permis- 807 sion to access URN:sales-widget-test/erp/salesperson 809 Example 2: Manufacturing server 811 The needs of manufacturing are slightly different. In this case there are 812 many applications which need to share authorization data between them. For 813 example, the machine shop contains a press and a lathe, each controlled by 814 a computer. Jobs are passed from the press to the lathe. Authorization data 815 attaches principally to the job and not to the specific machinery. 817 Bob is authorized to use the lathe, the press and the fleam. Carol is 818 authorized to use the lathe and the press 820 Bob owns jobs 1, 2, 5 and 6 821 Carol owns jobs 3, 4 and 7 823 The two sets of authorization data are tracked separately by 824 two separate OCSP-X servers. Access to the machinery is controlled by the 825 accreditation group who run exams in the use of the machinery. Ownership of 826 jobs is tracked by the job track and dispatch ERP system 828 Bob's authorizations are therefore: 830 URN:credit-widgets-test/machines/lathe 831 URN:credit-widgets-test/machines/press 832 URN:credit-widgets-test/machines/fleam 834 URN:shop-widgets-test/jobs/1 835 URN:shop-widgets-test/jobs/2 836 URN:shop-widgets-test/jobs/5 837 URN:shop-widgets-test/jobs/6 839 Conclusion: 841 Clearly configuration of such a system leaves much to the implementers who 842 must decide issues such as namespace conventions. 844 The objective is to permit application vendors to ship products in such a 845 manner that it is possible to readily support the decisions made by the en- 846 terprise without requiring custom code for each application - as use of API 847 toolkits tends to do. 849 The ERP applications in these examples establish the convention for the 850 lower level of the hierarchy [i.e. the suffix]. The enterprise establishes 851 the convention for the higher level of the hierarchy - the prefix. 853 Quite where the boundary should lie is probably best left to the enter- 854 prise. OCSP-X responders and applications should probably both provide a 855 degree of flexibility. For example the sales ERP application could provide 856 no more flexibility than allowing the enterprise to specify the prefix and 857 a list of valid responder addresses with public keys to authenticate them 858 by: 860 OCSP-X 861 Prefix = URN:sales-widget-test/erp 862 Server = { 863 url http://ocspx1.sales.widget.test/ 864 priority 50 865 [key info] } 866 Server { 867 url http://ocspx2.sales.widget.test/ 868 priority 50 869 [key info] } 871 A more flexible approach however would allow each of the resources defined 872 to be mapped to URIs of the enterprise's choosing. 874 For example the enterprise may have already allocated roles for a particu- 875 lar project and it may be simplest to map these roles in the application as 876 opposed to the OCSP-X system. 878 OCSP-X 879 Resources = { 880 salesperson URN:sales-widget-test/erp/user 881 manager URN:sales-widget-test/erp/admin 882 administrator URN:sales-widget-test/erp/admin } 883 Server = { 884 url http://ocspx1.sales.widget.test/ 885 priority 50 886 [key info] } 887 Server { 888 url http://ocspx2.sales.widget.test/ 889 priority 50 890 [key info] }