tinc-vpn.org Git - fides/blob - FORMAT

   1 Certificate format
   2 ------------------
   3
   4 Currently, the format is in ASCII:
   5
   6 <KEYID> <TIMESTAMP> <DIGEST> <STATEMENT>
   7
   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.
  12
  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
  16 are implemented:
  17
  18 a+      Allow whatever follows
  19 a-      Deny
  20 a0      Don't care (neither explicitly allow or deny)
  21
  22 t+      Trust whatever follows
  23 t-      Distrust
  24 t0      Don't care (neither explicitly trust or distrust)
  25
  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
  30 denies Mallory.
  31
  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".
  36
  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.
  43
  44 The exact way trust and authorisation is calculated might not be optimal and
  45 may be changed later.
  46
  47 Future certificate types might be:
  48
  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
  58
  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.
  64
  65 Most of these certificate types should also have +, 0 or - postfixes, to revoke
  66 or negate certain statements.
  67