Commit 8663fac5 authored by Niels Möller's avatar Niels Möller
Browse files

Wrote down an SPKI overview and some ideas on how to

organize the information in the file system.

Rev: src/spki/ChangeLog:1.45
Rev: src/spki/README:1.2
parent 2c8dd73c
2003-02-13 Niels Mller <>
* README: Wrote down an SPKI overview and some ideas on how to
organize the information in the file system.
2003-02-12 Niels Mller <>
* testsuite/check-signature-test (test_valid, test_invalid):
Libspki is a library and a set of tools for handling Simple Public Key
Infrastructure certificates and other objects.
This section gives an overview of thw SPKI model of authorization.
Owners and ACLSs
The owner of a resource writes Access Control Lists (ACLs) specifying
who can access the resource. User's are identified by their public
key. A user will contact the server controlling the resource, and
provide a certificate chain and some proof of knowledge of a his or
her private key. The server checks the signatures, and then matches
the certificate chain, the requested access, and the owners ACL, to
make an access decision.
The root of authorization
The owner can write one ACL for each user that should have access to
the resource, or a single ACL giving full access to one of her own
keys. She can then use that key to sign certificates that delegate
some or all of her rights to other users.
There's no need for a trusted third party, because all valid
certificate chains will be rooted at a key listed in the owner's ACL.
Delegation is a central issue in SPKI. Any user that has access rights
to some resource, via the owner's ACL and a certificate chain, and
which has the delegation flag set in her certificate, can sign new
certificates delegating some or all of her rights further. When
delegating, giving somebody a new certifon a new certificate, one will
usually provide a complete certificate chain, i.e. the chain that
gives oneself the right to use and delegate the right, extended with
the newly signed certificate.
Libspki doesn't yet implement all aspects of SPKI. In particular, it
doesn't yet implement SPKI names, online validity checks, and the
"range" type in tag expressions.
The information that SPKI users and applications need is organized as
follows. ACL:s are stored anywhere the software controling a resource
finds it convenient. The rest of the information is stored in a
directory, for users it would be located in files ad directories under
A private key. Should contain the public information in
cleartext, and the private information in cleartext or encrypted
by a password.
The corresponding public key. Redundant, but may be useful.
~/.spki/sha1-keys/{xxxx...} --> ../keys/foo
A symlink from the public-key hash to the corresponding key file.
A big file containing all the user's certificate chains. To find
a relevant certificate, one have to read the file and filter out
interesting certificates, usually by looking at the SPKI tags.
A log file containing information about all the user's own
delegations. Not strictly necessary, but it seems desirable to
keep a log of created certificates. The log file can be rotated
if it gets large.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment