Bob:
I agree with your need for linking the individual or role identified by
a PEM certificate with the authorizations granted to that individual or
role by the organization that they represent. I believe that trying to
do so by forcing those authorizations into the DN is a very poor solution.
You are focusing on a narrow interpretation of what such authorizations
might be used for. A few possible examples include:
- specifying whether the individual has the authority to authorize
a purchase for an EDI transaction, and if so, what limits are
imposed and what counter signatures are required.
- limiting an Intelligence agent's access to certain levels of a
multilevel database within a DoD mail-enabled application
(Mandatory Access Control).
- determining whether or not an individual has the ability to sign
off on an engineering design as "Project Manager" in a "workflow"
environment.
PEM has the potential of becoming a very powerful framework upon which to
build distributed, security-enabled applications. The missing piece is
a general mechanism for linking authentication with authorization.
In a previous mailing Piers McMahon mentioned other possible approaches,
but you did not pursue his suggestions. In particular the ECMA Privilege
Attribute Certificate (PAC) would be a very natural extension to PEM.
The PAC is essentially a modified X.509 certificate that contains:
- a user's credentials encoded as a set of ASN.1 attributes.
- an initiator qualifier used to control what users, applications
or systems can use the PAC.
- a target qualifier used to control the applications or systems to
which a PAC may be presented.
- a validity period used to restrict the lifetime of the PAC.
- possible links to other, qualifying PACs.
And of course, being derived from the authentication certificate, the
whole thing is signed by the authority granting the authorizations to the
individual or role.
This mechanism is generic enought to encode virtually any desired type
of authorization information, and would be useful far beyond just PEM.
Its use wouldn't require any modifications or hacks to PEM or DNs, or
require explicit policy statements by a (P)CA. These can be pushed upon
the application or enduser. For example, for EDI transactions, a supplier
can make the simple policy statement that they will not accept any orders
unless there is an acceptable PAC for the originator signed by an appropriate
organization or organizational unit. The PAC can either be looked up
within the X.500 directory along with the originator's authentication
(PEM) certificate, or can be passed by the originator. The PAC can be
verified quite easily:
1) match the DN in the originator's authentication certificate with
that in the PAC.
2) match the authority in the originator's PAC to the organization
or OU within the originator's DN.
3) verify the signature on the PAC just as you would the
authentication certificate.
4) check the set of authorizations granted to the originator.
Using a separate PAC has a couple of nice advantages over forcing the
authorizations into the authentication certificate: multiple PACs can
pertain to the same DN granting them different sets of authorizations
for different functions; the PAC can be changed without modifying the
authentication certificate.
I think this would give you the capabilities you are looking for. A
company such as GTE could sign a number of PACs for each employee, perhaps
one for their role within the company and one for their authorizations
beyond GTE. You could even get specific and authorize someone only for
purchasing the Friday afternoon beer from the corner store for the company
meeting (within limits, of course).
Charlie Watt
SecureWare, Inc.