4 Currently, the format is in ASCII:
6 <KEYID> <TIMESTAMP> <DIGEST> <STATEMENT>
8 KEYID: hex-encoded fingerprint of the key that was used to create the digest
9 TIMESTAMP: UNIX timestamp of time of certificate creation, in decimal floating point format, with microsecond resolution (ie, 6 digits after the decimal)
10 DIGEST: base64 encoded digest of "<KEYID><TIMESTAMP><STATEMENT>", ie. the certificate without the digest and without the spaces between the parts.
11 STATEMENT: can be anything as long as it doesn't include a newline, linefeed or null-byte.
13 The STATEMENT can in principle be anything, but to make fides useful and to
14 allow programs to quickly find out if something is "allowed" or "trusted", the
15 first word can indicate the type of statement. Currently, the following types
18 a+ Allow whatever follows
20 a0 Don't care (neither explicitly allow or deny)
22 t+ Trust whatever follows
24 t0 Don't care (neither explicitly trust or distrust)
26 For example, a program that wants simple distributed access control, just
27 allowing or denying access to specific users, can work with certificates with
28 statements like "a+ Alice", "a0 Bob", "a- Mallory". This would allow Alice
29 access, does not care about Bob (so use default access level for him), and
32 When asking Fides "is Carol allowed?", it would find all the certificates from
33 trusted peers, which a+ Carol or a- Carol, and count the number of a+ and
34 number of a- certificates. If there are more a+ than a- certificates, the
35 answer of Fides would be "yes", otherwise "no".
37 The trust statements are intended for specifying trust of the Fides keys of
38 peers. Currently, it implements a crude web of trust, where a Fides instance
39 trusts/distrust keys based on t+/t- certificates it issued itself, and then
40 checks if there are more keys trusted by those Fides instances it trusts, and
41 so on. Keys who are trusted or distrusted early in this trust path discovery
42 process are never marked as distrusted or trusted later in this process.
44 The exact way trust and authorisation is calculated might not be optimal and
47 Future certificate types might be:
49 revoke Revocation certificate (followed by a keyID?)
50 subkey Links a strong key to a weaker one, like in PGP
51 newkey Links a key to a new one, obsoletes old key at same time?
52 person Link a key to a person (name, date of birth, passport number?)
53 email Link a key to an email address (like a PGP uid)
54 ssh Link a key to an SSH key
55 host Link a key to a hostname
56 x509 Link a key to a X.509 certificate
57 pgp Link a key to a PGP key
59 until Followed by a timestamp and a statement, limits that statement until a certain time.
60 ephemeral Followed by a statement, means this certificate is not to be made public,
61 and only holds for the duration of one session.
62 Ie, this certificate should not be stored in the database.
63 For example, this can be used to sign a session key.
65 Most of these certificate types should also have +, 0 or - postfixes, to revoke
66 or negate certain statements.