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] }