[6437] in cryptography@c2.net mail archive
Trust Establishment on AlphaWorks
daemon@ATHENA.MIT.EDU (yosimass@il.ibm.com)
Thu Jan 20 14:38:31 2000
From: yosimass@il.ibm.com
To: ietf-pkix@imc.org, spki@c2.net, cryptography@c2.net, trustmgt@EAST.ISI.EDU
Cc: amir.herzberg@il.ibm.com
Message-ID: <C125686C.004B3F91.00@d12mta02.de.ibm.com>
Date: Thu, 20 Jan 2000 15:45:14 +0200
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi,
TrustEstablishment (available now on AlphaWorks at
http://www.alphaworks.ibm.com) is a set of Java packages that can be used to
solve the Trust Management problem. Below is a short description of the Trust
problem and how TE can be used to solve it. More info can be found at
http://www.hrl.il.ibm.com/TrustEstablishment. Any feedback is most appreciated.
Regards, Yosi Mass
Trust Establishment Project Manager,
IBM Haifa Research Lab, Tel Aviv Site
E-mail: YosiMass@il.ibm.com
Tel +972-3-6978624, Fax +972-3-6914736
A new approach to the deployment of public key infrastructure is presented,
based on a separation between the issuing of certificates and the usage of
certificates. Certificates are signed assertions by the issuer about the
subject of the certificate (holder of corresponding private key), not
necessarily identifying the subject. Typical use of certificate is for
access control decisions, to determine whether the subject is allowed to
perform a certain action (on some resource); this decision is based on the
policy of the owner of the resource. Issuers do not need to be known to
resource owners in advance; it is sufficient that they, in turn, will
provide sufficient certificates to be considered a trusted authority
according to the owner's policy. This allows bottom-up, `grassroots`
build-up of trusted issuers.
Our approach extends, rather than replaces, existing role-based access
control mechanisms, by providing automated role assignment. Existing access
control mechanisms use the identities to map the subject to a given role,
based on a static table. Our system maps the subject of the certificates to a
role, based on the subject's certificates, on a given role-assignment policy
set by the owner of the resource, and on the roles of the issuers of the
certificates. The role is then fed as input to the existing role-based
access control mechanism. This provides a simple, modular architecture and
role-assignment policies.
We describe an implementation called "Trust Establishment (TE)" , which can
be used to provide a complete PKI-enabled web server (or other e-commerce
server), or to extend access control systems. A central element in our
implementation is a simple yet powerful Certificate-based Role-Assignment
Policy Language specified using XML. We believe that the policy language is
expressive enough to allow complex policies, including e.g. non monotone
(negative) certificates while being simple enough to allow automated policy
checking and processing. Processing of the policy is essential, to ensure
reasonable efficiency (e.g. in handling a new certificate or revocation), to
check policy e.g. for conflicts, to collect missing certificates, to compose
policies, and to allow subjects to select which certificates to present. Our
system includes an intelligent certificate collector that automatically
collects missing certificates from peer servers, allowing the use of
standard browsers (that pass only one certificate to the server).
Trust Establishment Software
========================
The TE module is written in Java and therefore includes the cross platform
advantages available to
Java applications. The module also includes an API toolkit that programmers
can use to extend
the access control abilities of existing applications or web servers.
All certificates and signatures are implemented through the Zurich Crypto
Framework package
from ZRL. The TE software uses a reduced version that does not include
encryption and therefore
has no problems with export regulations.
Certificate Format
===============
The Trust Establishment module uses the X509 V3 certificate format . TE is
designed to support
other certificate types; this type was chosen since it is currently the most
commonly used. The
certificate subject and issuer are identified by X500 names, where X500
defines a global directory
for all names and DN is the distinguished name. The TE does not use these
X500 names, but
keeps a unique identifier for a subject/issuer which is derived from their
public key and is kept in
the standard extensions : issuer/subject altName.
The TE module decides on the role for the key so it is not interested in the
identity of the user;
hence, the X500 names are not really important. TE uses them because they
are obligatory for the
X509 format.
Related Documents
=================
For further information on Trust Establishment, see the following:
Trust Establishment home page at
http://www.hrl.il.ibm.com/TrustEstablishment
White paper accepted to the 2000 IEEE Symposium on Security
and Privacy available at
http://www.hrl.il.ibm.com/TrustEstablishment/paper.asp
