Internet Draft Phillip Hallam-Baker draft-ietf-pkix-ocspx-00.txt VeriSign Inc. September 03, 1999 Expires in six months OCSP Extensions Status of this memo This document is an Internet-Draft and is in full conformance with all pro- visions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The OCSP protocol [RFC2560] enables online validation of the reliability of a digital certificate. RFC2560 defines a mandatory-to-implement mechanism supporting the revocation status of the certificate and defines and op- tional extension mechanism to support a richer set of semantics (e.g. full path validation by the OCSP server). This document defines Internet-standard extensions to OCSP that enable a client to delegate processing of certificate acceptance functions to a trusted server. The client may control the degree to which delegation takes place. In addition limited support is provided for delegating authorization decisions. 1 Introduction For an application to make an informed decision as to whether it trusts a digital certificate the application must have knowledge of the certificate itself, a set of trusted public keys from which certificate chains may be constructed, a set of intermediate certificate authorities from which the trust chain may be constructed and the validation status of every certifi- cate used to construct the trust chain. In a typical PKI deployment these data frequently originate from multiple sources. Certificates and certificate status information will be issued by multiple Certification Authorities. In the typical case authorization data will be maintained separately. As the task of managing these disparate sources of data required to decide upon the acceptability of digital cer- tificates increases it is advantageous to delegate this task to one or more specialist applications. These data must then be integrated into certificate path processing compli- ant to RFC 2459 [RFC2459]. In some environments, it may be useful to defer this integration to a trusted server, thereby relieving certificate using functions of the need to acquire this information and integrate it into compliant path processing logic. It may also be useful to defer this inte- gration to a trusted server due to the serverÆs ability to more easily com- bine certificate path processing with other authorization data. Finally, a trusted-server approach to certificate validation enables straightforward design and implementation of a trust management system capable of immediate response to certificate or authorization revocation. The basic OCSP protocol [RFC2560] provides a simple mechanism for communi- cating certificate revocation status and an extension mechanism for commu- nicating additional types of certificate validation information. The exten- sibility mechanism can accommodate advanced needs for certificate valida- tion beyond simple revocation status. This document defines Internet-standard OCSP extensions to ensure interoperability among diverse PKI-based trust management systems or net- works. These extensions allow a client to delegate the tasks of deciding whether a certificate should be relied upon and whether it is acceptable for a par- ticular operation. 2 Principal Applications Before presenting the specific requirements for the extensions proposed we first consider some applications whose needs have motivated this protocol. 2.1 Embedded Systems We anticipate a substantial increase in the use of PKI by embedded systems. In the short term this increase will be driven by the deployment of IPSEC capable gateways such as routers and firewalls. In the longer term, how- ever, it is to be expected that most embedded systems will support some kind of security based on PKI. Such devices are typically subject to significant constraints in the proc- essing power and persistent storage that may be allocated to PKI support. Support for operator interaction is limited, if indeed the device has any I/O capability at all other than the network interface. Neither constraint is likely to be affected by progress in technology since market demand tends towards low cost devices. Moreover, embedded devices are typically expected to have an operating lifetime significantly longer than application software. Suppliers are con- cerned to minimize the amount of maintenance required. Offloading certifi- cate related processing functionality maximizes the useful lifetime of an installed base of such devices while trust management technology moves for- ward. 2.2 Wireless Devices We also anticipate a substantial increase in the use of PKI enabled wire- less devices. These devices share many of the constraints of embedded sys- tems. Processing and memory resources are highly constrained, in this case by battery lifetime as well as cost. Nor is it practical to support a com- plex user interface on a handheld device. It is possible for wireless devices to communicate directly with each other. In a typical application however the wireless device communicates with a static base station which in turn is connected to a network. It is highly desirable to offload processing tasks from the mobile unit to the base station. 2.3 Centralized Trust and Authorization Management As previously discussed, determination of the acceptability of a certifi- cate for a particular operation requires a substantial quantity of data, management of which is a complex task. In a large enterprise it is desir- able to centralize this task, or at least restrict the number of systems performing it. In addition to eliminating the need to distribute significant quantities of data to relying applications, centralization of certificate acceptance functions improves enterprise-wide consistency in the enforcement of poli- cies relating to certificate acceptance. Centralized management also yields advantages in auditing and control. Sus- picious behavior patterns may be more readily detected if audit information is centralized. If a suspicious behavior pattern is detected, further ac- cess may be denied, either by automatic revocation or suspension of the certificate, or by withdrawing authorization. 2.4 Use of Attribute Certificates Attribute Certificates provide a means of distributing auxiliary informa- tion which, for certain reasons, it is not desirable to include within a public key certificate. Such information is typically used to make authori- zation decisions. Attribute Certificates present the advantages of distributing authorization information in a non-repudiable form. However, use of attribute certifi- cates has been widely criticized as overburdening client implementations, particularly since effective use of authorization certificates appears to require application specific processing rules. Delegating certificate-based access control decision functions, including the processing of attribute certificate chains to an OCSP-X responder miti- gates these objections. Client implementations need only implement the OCSP-X request and response protocol. Sites may construct conventions and processing rules of arbitrary complexity for enforcement of authorization attributes and still rely on standard clients, regardless of the use or non-use of attribute certificates. 2.5 Single Sign-On A principal advantage for PKI based security is the ability to support sin- gle sign-on. Password based authentication has the substantial disadvantage that the authentication process itself requires the password to be revealed to or previously known by the authenticating party. Public key based authentication does not require a secret to be revealed or known in order for the authenticating party to know that it is known. Although PKI provides comprehensive support for authentication, access con- trol requires both authentication and authorization to take place. It is not enough to know who a person is, it is equally important to know what that person is permitted to do. Although many protocols already exist to support distribution of authoriza- tion information there is considerable advantage to supporting delegation to a single enterprise-level authority of all aspects of the access control decision that require external data. 3 Requirements The following requirements have been identified as important in the meeting of the needs of the applications described above. 3.1 Support for Aggregation of Trust Information On the basis of the prior analysis, there exists a need to aggregate at a trusted server all information relevant to determining the acceptability of a digital credential in a given context. This information includes but is not limited to: * End-user Public Key Certificates * CA public key certificates * Attribute Certificates * Certificate Revocation Lists or certificate status databases * Data provided by other OCSP and OCSP-X responders The means by which this information is obtained by an OCSP-X server is be- yond the scope of this specification. 3.2 Support for Intelligent Query The extensions SHOULD support intelligent queries, that is queries which are specifically relevant to the client decision to trust a certificate. This requirement is distinct from the type of query supported by directory servers, including LDAP servers and X.500 servers. The data model upon which these servers are designed does not support the specific types of query required. Nevertheless it would be highly appropriate for a single server to support both OCSP-X and LDAP retrievals from a common database. 3.3 Delegated Trust Decision The extensions SHOULD allow a client to delegate all aspects of deciding the authenticity and validity of a certificate. It is NOT a requirement that every response be justified by providing in- formation such as the certificate chain generated and relevant CRLs. The objective of OCSP-X is to permit a client to simplify certificate valida- tion decisions by offloading them to an external client. This objective is negated if the client is then required to duplicate the trust decision. 3.4 Delegated Authorization Decision The extensions SHOULD support the delegation of authorization decisions to the OCSP-X responder. It is not however a requirement for that the OCSP-X responder provide in- formation to the relying application so that the relying application may duplicate the authorization decision. 3.5 Support for Status Update Notification Protocols In many circumstances it is necessary for an application to track changes in the validity of a certificate after the initial decision to trust the certificate has been made. A wide variety of architectural approaches are appropriate to meet this re- quirement and the specification of a specific protocol for the purpose is outside the scope of this particular draft. It is not therefore a require- ment that these extensions propose a specific notification protocol but use of such a protocol SHOULD be supported. Pending the development of such a protocol, clients which need to track changes in certificate validity may do so by polling the OCSP-X responder. It is therefore a requirement that the protocol support this mode of use efficiently. 4 Non-Requirements Support for the following features was considered but rejected. 4.1 Delegated Key Exchange Support for delegation of key exchange processing was considered but re- jected as being more appropriate for independent discussion. A client relying on an OCSP server for trust path evaluation might also delegate other aspects of a cryptographic negotiation scheme such as key exchange. While it is highly desirable for embedded devices such as IPSEC routers to offload complex processing tasks to other processors support for such a feature would inevitably involve strong interdependencies with the key ex- change protocols to be supported. The complexity of such a protocol would therefore be considerable and it is not clear that a sufficient degree of generality across protocols could be achieved. 4.2 Alternate Response Syntax Support for an alternative response syntax was considered but rejected as being more appropriate for independent discussion. The advantage of an alternate response syntax is that it would permit de- vices with limited processing capability to receive responses encoded in a simpler syntax than ASN.1. While construction of an ASN.1 BER encoded re- quest message is not unduly burdensome on a client implementation the pars- ing of OCSP responses is considered unnecessarily complex by many. 4.3 Modification of Authorization Data Support for client requests to modify authorization data was considered but rejected as introducing an unacceptable degree of additional complexity into the protocol. Support for such a feature would permit implementation of client æowner- shipÆ of resources whose authorization data is managed by the OCSP-X server. Such support would however require a considerably more detailed definition of the authorization framework than specification of the re- sources for which authorization is requested and the mode of access re- quested. In particular it would be necessary to commit to a data model for the authorization data. While support for such a feature is likely to prove necessary in time, the substantial degree of additional complexity involved strongly suggests that it preferable to address the issue separately. 5 OCSP Message Framework The OCSP message format is defined in RFC 2560. This section describes the use made of the OCSP message format within this document. 5.1 Extension Framework The OCSP extension framework permits additional data to be incorporated in an OCSP message such that the extension data applies to an entire request or to specific certificate in a response. Similarly the framework permits extensions in a response to apply to either the response as a whole or to a specific certificate in the response. In this document we refer to extensions which apply to a message as a whole as æmessage extensionsÆ. Extensions which apply only to a specific certifi- cate are referred to as æcertificate specific extensionsÆ. Extensions that MAY be employed in either manner are referred to as simply æextensionsÆ. These terms correspond to the ASN.1 structures defined in RFC 2560 as fol- lows: Identification Structure Element Response Message OCSPRequest requestExtensions Certificate Specific Response Request singleRequestExtensions Reply Message ResponseData responseExtensions Certificate Specific Reply SingleResponse singleExtensions 5.2 Status Reporting OCSP-X defines a number of extended response codes. It is intended that these augment the response codes defined by RFC2560, providing additional status information where needed. OCSP-X extended status codes SHALL be reported using the id-pkix-ocspx- status extension OID in the response as defined bellow. 6 Extension Elements All extensions are tagged using OIDs formed of the existing OCSP arc. id-pkix-oscpx OBJECT IDENTIFIER ::= { id-pkix-ocsp [TBS] } An OCSP client MAY signal support for OCSP response extensions by including the id-pkix-ocspx-support OID as an OCSP acceptable response type. Alterna- tively, clients that include OCSP extensions in their request SHALL be ca- pable of support for OCSP response extensions in the manner defined by this specification. id-pkix-ocspx-support OBJECT IDENTIFIER ::= { id-pkix-ocspx 1 } A server MAY advertise that it supports the OCSP-X extensions by including the id-pkix-ocspx-support OID as a message extension in any OCSP response. The OID id-pkix-ocspx-support MUST NOT be included as a certificate spe- cific extension. If a server receives no signal from the client as defined above, it MAY in- clude response extensions, but MUST be capable of basic OCSP as defined in RFC2560. Where extended status codes are defined these are returned as response ex- tensions using the id-pkix-ocspx-status OID and ExtendedStatus structure: id-pkix-ocspx-support OBJECT IDENTIFIER ::= { id-pkix-ocspx 2 } ExtendedStatus :== SEQUENCE OF SingleExtendedStatus SingleExtendedStatus :== CHOICE { TRUST_NOT_SUPPORTED [1] EXPLICIT NULL ROOT_NOT_ACCEPTABLE [2] EXPLICIT NULL TRUST_ROOT_REQUIRED [3] EXPLICIT NULL RULE_NOT_SUPPORTED [4] EXPLICIT NULL TRUST_PATH_NOT_FOUND [5] EXPLICIT NULL TRUST_PATH_VALIDATED [6] EXPLICIT NULL CERTIFICATE_NOT_TRUSTED [7] EXPLICIT NULL REGISTRATION_NOT_SUPPORTED [8] EXPLICIT NULL AUTHORIZATION_NOT_SUPPORTED [9] EXPLICIT NULL } 6.1 Specify Trust Root The specify trust root extension is used to specify the trust root(s) for a trust delegation request. If the trust root is not specified in the request the selection of trust roots is delegated to the OCSP status server. Request id-pkix-ocspx-root OBJECT IDENTIFIER ::= { id-pkix-ocspx 3 } TrustRoot ::= SEQUENCE { certificates SEQUENCE OF CertID } By including a specific trust root, client indicate a need to determine if the certificate identified in the request is trusted by the server under the authority of the identified root. An affirmative response from the server confirms that the server has, among other functions, cryptographi- cally proven by trust path logic that the signature on the subject certifi- cate is valid under the indicated root. The means by which the server ac- quires the information necessary to arrive at this conclusion is beyond the scope of this specification. One means could be by prior acquisition of the appropriate cross-certificate. Response If the server is unable to develop a trust chain from the subject certifi- cate to the indicated trust root, an error code is returned. TRUST_NOT_SUPPORTED Trust Root Processing is not supported ROOT_NOT_ACCEPTABLE The specified trust root is not known to the server- TRUST_ROOT_REQUIRED Explicit specification of the trust root is required to permit trust delegation. 6.2 Specify Processing Rules In certain circumstances a client may require the OCSP server to apply a particular set of certificate path processing rules Request The client may specify the processing rules under which the trust chain is to be constructed. If no trust rules are specified the responder SHOULD em- ploy the processing rules specified by RFC2459. id-pkix-ocspx-rules OBJECT IDENTIFIER ::= { id-pkix-ocspx 4 } Rules ::= SEQUENCE { rules SEQUENCE OF Rule } Rule ::= SEQUENCE { oid OBJECT IDENTIFIER} Response If the server is unable to support all of the path processing rules speci- fied it MUST return an error. RULE_NOT_SUPPORTED The requested processing rules are not supported by the server. 6.3 Evaluate Trust Path The client requests that the OCSP-X responder attempt to construct a valid trust path originating from a trust root. Optionally the client may request that the responder return part or all of the data used to construct and validate the certificate chain. Request id-pkix-ocspx-evaluate OBJECT IDENTIFIER ::= { id-pkix-ocspx 5 } Evaluate ::= SEQUENCE { reportTrustChain [1] IMPLICIT NULL reportValidation [2] IMPLICIT NULL returnTrustChain [3] IMPLICIT NULL returnValidation [4] IMPLICIT NULL } Response CERTIFICATE_NOT_TRUSTED The certificate is not trusted TRUST_PATH_VALIDATED The certificate is trusted TRUST_PATH_NOT_FOUND The trust status of the certificate could not be determined. 6.4 Register Trust Path A client may employ the register trust path extension to notify the server that the validity of a trust path will be of ongoing significance to the client during a specified time interval A client MAY optionally request no- tification if a certificate reported to the client as being valid is re- voked during the specified time interval. The specific actions to be taken if a trust path be invalidated while a client is relying upon it are a matter for site specific policy. OCSP-X responders MAY support the use of an OCSP response as a notification mechanism. In this case the notifyUri member is present and specifies by means of a URI both the transfer protocol (e.g. HTTP) and the address to which the notification is to be sent. The use of OCSP-X messages over HTTP as a notification protocol is vulner- able to a denial of service attack however. An extension mechanism is sup- ported to allow improved notification mechanisms to be specified in future documents. Request id-pkix-ocspx-register OBJECT IDENTIFIER ::= { id-pkix-ocspx 6 } Register ::= SEQUENCE { until [0] EXPLICIT GeneralizedTime OPTIONAL notifyUri [1] EXPLICIT OCTET STRING OPTIONAL notificationExtensions [2] EXPLICIT Extensions OPTIONAL} Response REGISTRATION_NOT_SUPPORTED Registration is not supported NOTIFICATION_NOT_SUPPORTED Notification is not supported 6.5 Authorization Delegation The basic OCSP response provides only authentication information. In many applications it is desirable to supply both authentication and authoriza- tion from a centralized source. A request for authorization delegation must specify both the party which requests access and the resource for which access is requested. In addition a request for authorization MAY present a chain of attribute certificates containing information relevant to the authorization decision. Resources are identified using URIs according to a convention chosen by the client, the definition of which is outside this document. URIs provide a uniform syntax for identification of resources in a hierarchical fashion. A request for authorization delegation need specify only the URI of the re- source for which access is being requested and the specific mode of access requested. Four modes of access control are supported, GET, PUT, EXECUTE and LINK. The GET and PUT and EXECUTE modes correspond respectively to the traditional Read and Write and EXECUTE modes supported by conventional operating sys- tems. The LINK mode corresponds to a superset of the CONTROL mode of a con- ventional operating system and when granted permits the recipient to spec- ify and meta-information related to the resource, including authorization information. Where finer grained access control is required than is supported by these four modes implementations may specify access control at an arbitrary granularity by using an extended URI convention. Each authorization request specifies one or more URIs that identify re- sources for which authorization is requested. The convention by which URIs refer to resources is discussed further in Appendix A. Specification of this convention is outside the scope of this document. The responder SHALL either return the extended response code AUTHORIZATION_NOT_SUPPORTED or return an AuthorizationResponse certificate specific extension. The AuthorizationResponse SHALL consist of a number (possibly zero) of Re- sourceResponse structures. Each ResourceResponse structure SHALL describe the authorization status of the entity identified by the respective cer- tificate with respect to the range of resources identified by the specified URI. The range of resources identified by the URIs in the authorization response MAY be more specific, less specific or equally specific as the range speci- fied in the request. In cases where the party for whom authorization is requested has authoriza- tion to access a broad range of resources and the client requests access to a specific resource within that range the responder MAY specify the broader range in its response. This permits the client to cache the authorization response, eliminating the need for repeated authorization requests for closely related resources. In cases where the party for whom authorization is requested has authoriza- tion to access a specific range of resources the and client requests access to a broad range of resources which encompasses it the responder MAY spec- ify the more specific range in its response. This permits the client to provide navigation menus tailored to the specific set of resources to which the party is permitted access. Request The request specifies a list of one or more resources for which authoriza- tion is requested. id-pkix-ocspx-authorize OBJECT IDENTIFIER ::= { id-pkix-ocspx 7 } AuthorizationRequest ::= { requests SEQUENCE OF ResourceData certs [0] EXPLICIT SEQUENCE OF Certificate } ResourceData { uri Uri mode AuthorizationMode} AuthorizationMode ::= SEQUENCE { get [1] NULL put [2] NULL execute [3] NULL link [4] NULL } Uri ::= OCTET STRING Response The id-pkix-ocspx-authorize-response certificate specific response exten- sion specifies a sequence of one or more ResourceResponse structures each of which reports the authorization status of the party identified in the respective certificate with respect to a range of resources. The following authorization statuses may be reported: permit Access to the specified resource is permitted deny Access to the specified resource is denied unknown The responder does not know the authorization status of the resource. refused The responder refuses to disclose the authorization status of the resource. id-pkix-ocspx-authorize-response OBJECT IDENTIFIER ::= { id-pkix-ocspx 8 } AuthorizationResponse ::= SEQUENCE OF ResourceResponse ResourceResponse :== SEQUENCE { resource ResourceData status AuthorizationStatus } AuthorizationStatus :== CHOICE { permit [1] EXPLICIT deny [2] EXPLICIT unknown [3] EXPLICIT refused [4] EXPLICIT} AUTHORIZATION_NOT_SUPPORTED The OCSP-X responder does not support the authorization extensions. 7 Security Issues 7.1 Security of the OCSP-X Responder Compromise of an OCSP-X responder would severely impact the security of any application relying upon it. Centralized management of information required for trust path processing could potentially introduce the possibility of a denial of service attack. The scope for denial of service attacks does not appear to be substantially increased in the typical enterprise implementation scenarios however. In the case where applications delegate any or all of the trust decision process itself to the OCSP-X responder, compromise of the OCSP-X responder constitutes compromise of the application itself for all practical pur- poses. Both risks may if necessary be mitigated by means of deployment of multiple OCSP-X servers configured in such a manner that the decisions made by each server are audited by one or more other servers. 7.2 Audit An OCSP-X server may be employed to enforce system audit requirements. In such a configuration the use of wildcard responses in authorization re- sponses must be carefully considered if the audit trail is to be suffi- ciently detailed. 7.3 Notification Protocol Subject to Denial of Service Attack The simple notification protocol described is vulnerable to a denial of service attack. Nevertheless the protocol described has value in applica- tions where either the possibility of a denial of service attack is not present or where such an attack is prevented by a separate protocol, defi- nition of which is outside the scope of this draft. 8 Collected Syntax [To be specified] 9. References [RFC2560] X.509 Internet Public Key Infrastructure Online Certificate Status Protocol, M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams, RFC 2560, March 1999 10 Acknowledgements The author would like to acknowledge the extensive contribution made to this draft at an early stage by Michael Myers and Warwick Ford. In addition some of the ideas presented were previously presented by Ambarish Malpani and Paul Hoffman in their August 1999 Internet draft Simple Certificate Validation Protocol (SCVP). This draft builds upon this earlier work and on comments made on both documents and to the IETF mailing list by many people including Carlisle Adams, Barbara Fox, Todd Glassey, Mack Hicks, Bob Juene- man, Steve Kent, Dennis Pinkas, Brian LaMachia, Alan Lloyd, Rich Saltz, Pe- ter Williams and Michael Zolotarev. 11 AuthorÆs Address Dr Phillip M. Hallam-Baker VeriSign Inc. 301 Edgewater Place Wakefield MA 01880 pbaker@VeriSign.com Appendix A Authorization Example For either authorization or authentication to be performed in a uni- form manner across a network it is of course essential that the relevant parties agree on a uniform namespace for 'who' and 'what'. The case of 'who' is already dealt with by X.509v3 / PKIX. The case of 'what' is more complex since most of the resources to be identified are local. Some form of abstract namespace is required. It is essential that the central database(s) in which authorization data is maintained and the parties relying upon those databases have a common agreement as to whats what. Example: Widgets 'R Us (wideget.test) has two departments, manufacturing and sales. Both departments separately manage ERP systems which are primarily for their own use but a limited number of personnel need access to both. The sales ERP system is maintained on a collection of servers called: erp1.sales.widget.test erp2.sales.widget.test The ERP system supports three basic access levels, Salesman, Manager and Administrator. These access levels are mapped onto URIs as follows: Salesperson URN:sales-widget.test/erp/salesperson Manager URN:sales-widget.test/erp/manager Administrator URN:sales-widget.test/erp/administrator Note that the sysops have decided to hide the fact that the ERP sys- tem is maintained on two separate systems since they want both to use iden- tical In this particular case the delegation of authorization functions to the central system is only partial. The ERP system accepts external input that informs it of the seniority/access role of the individual concerned - the type of information that would generally be handled by a corporate admin and is usefully shared between applications. The ERP system is also tracking the ownership status of resources created by its users. When a salesman creates a particular customer ac- count, that salesman has 'ownership' of that resource and may well have privileged access to it. What the central authorization system is doing is offloading the need to create new user accounts in the ERP system as salespeople join and leave. A typical interaction therefore is: 1. Alice is hired as a salesperson. 1: She is issued a digital certificate 'alice' 2: An authorization record is created of the form PERMIT alice URN:sales-widget-test/erp/salesperson 2. Alice accesses the ERP system for the first time 1: There is no account for alice 2: An OCSP-X request is made to see if alice is authorized [access URN:sales-widget-test/erp/salesperson/menu] The responder reports Alice is authorized to do anything under URN:sales-widget-test/erp/salesperson 3: The ERP application notes that alice is authorized to be a salesperson and creates an account for her. 3. Alice accesses the ERP system for the second (or nth) time 1: The ERP system notes there is an account for alice 2: An OCSP-X request is made to see if alice is still authorized [access URN:sales-widget-test/erp/salesperson] 3: alice is still authorized - good! 4. Alice is promoted to manager 1: Her entry in the OCSP-X server is modified to reflect her new status. 5. Alice is suspended after refusing to use the CSR system to report that the CSR system is down and not accepting reports. 1: Her authorizations for operations are withdrawn at the OCSP-X system. Her certificate is neither revoked, nor suspended however since she still is Alice and she still needs access to her 401K plan (she is going to need it soon!) 6. Alice is fired 1: Her certificate is revoked 2: The OCSP-X server is informed 3: OPTIONAL, if the notification process has been used the OCSP-X server could notify the certificate management system of any applications currently relying on the certificate for authorization] 7. Alice attempts to access the ERP system 1: The ERP system notes there is an account for alice 2: An OCSP-X request is made to see if alice is still authorized [access URN:sales-widget-test/erp/salesperson] 3: alice is not authenticated - and refused access There is a variant of this scenario which is worth mention. In this variant it is important that Alice be only presented with menu items for which she is permitted access. The relying application must therefore know her per- missions without actually instigating an operation itself. Requirement: Support some sort of generic query interface. This may be supported by permitting a responder to reply with the least specific mode of access permitted when an over-general request is made. In this scenario the OCSP-X responder would generate its initial startup screen by requesting whether Alice had permission to access URN:sales- widget-test/erp/ The responder would then reply that she only had permis- sion to access URN:sales-widget-test/erp/salesperson Example 2: Manufacturing server The needs of manufacturing are slightly different. In this case there are many applications which need to share authorization data between them. For example, the machine shop contains a press and a lathe, each controlled by a computer. Jobs are passed from the press to the lathe. Authorization data attaches principally to the job and not to the specific machinery. Bob is authorized to use the lathe, the press and the fleam. Carol is authorized to use the lathe and the press Bob owns jobs 1, 2, 5 and 6 Carol owns jobs 3, 4 and 7 The two sets of authorization data are tracked separately by two separate OCSP-X servers. Access to the machinery is controlled by the accreditation group who run exams in the use of the machinery. Ownership of jobs is tracked by the job track and dispatch ERP system Bob's authorizations are therefore: URN:credit-widgets-test/machines/lathe URN:credit-widgets-test/machines/press URN:credit-widgets-test/machines/fleam URN:shop-widgets-test/jobs/1 URN:shop-widgets-test/jobs/2 URN:shop-widgets-test/jobs/5 URN:shop-widgets-test/jobs/6 Conclusion: Clearly configuration of such a system leaves much to the implementers who must decide issues such as namespace conventions. The objective is to permit application vendors to ship products in such a manner that it is possible to readily support the decisions made by the en- terprise without requiring custom code for each application - as use of API toolkits tends to do. The ERP applications in these examples establish the convention for the lower level of the hierarchy [i.e. the suffix]. The enterprise establishes the convention for the higher level of the hierarchy - the prefix. Quite where the boundary should lie is probably best left to the enter- prise. OCSP-X responders and applications should probably both provide a degree of flexibility. For example the sales ERP application could provide no more flexibility than allowing the enterprise to specify the prefix and a list of valid responder addresses with public keys to authenticate them by: OCSP-X Prefix = URN:sales-widget-test/erp Server = { url http://ocspx1.sales.widget.test/ priority 50 [key info] } Server { url http://ocspx2.sales.widget.test/ priority 50 [key info] } A more flexible approach however would allow each of the resources defined to be mapped to URIs of the enterprise's choosing. For example the enterprise may have already allocated roles for a particu- lar project and it may be simplest to map these roles in the application as opposed to the OCSP-X system. OCSP-X Resources = { salesperson URN:sales-widget-test/erp/user manager URN:sales-widget-test/erp/admin administrator URN:sales-widget-test/erp/admin } Server = { url http://ocspx1.sales.widget.test/ priority 50 [key info] } Server { url http://ocspx2.sales.widget.test/ priority 50 [key info] }