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

src/spki/ChangeLog

+2003-02-13  Niels Mller  <niels@s3.kth.se>
+
+	* README: Wrote down an SPKI overview and some ideas on how to
+	organize the information in the file system.
+
 2003-02-12  Niels Mller  <niels@s3.kth.se>
 
 	* testsuite/check-signature-test (test_valid, test_invalid):

src/spki/README

+LIBSPKI
+
+Libspki is a library and a set of tools for handling Simple Public Key
+Infrastructure certificates and other objects.
+
+
+OVERVIEW
+
+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
+
+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.
+
+
+LIMITATIONS OF LIBSPKI
+
+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.
+
+
+STORAGE
+
+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
+~/.spki.
+
+  ~/.spki/keys/foo
+
+     A private key. Should contain the public information in
+     cleartext, and the private information in cleartext or encrypted
+     by a password.
+     
+  ~/.spki/keys/foo.pub
+
+     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.
+
+  ~/.spki/certificates
+
+     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.
+
+  ~/.spki/log/delegations
+
+     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.