[Fenfire-dev] PEG: Temporary and permanent signatures on pointer triples

[Benja Fallenstein]

This is pointer_tempsig_permsig--benja, the third in the series, and still a
couple of more to come... oh well. When the whole series is written, will
need to look through it again and see what can be expressed more concisely.

- Benja

=====================================================
Temporary and permanent signatures on pointer triples
=====================================================

:Author:  Benja Fallenstein
:Created: 2003-08-23
:Changed: $Date$
:Status:  Current
:Scope:   Major
:Type:    Architecture


The `pointers_overview--benja`__ defined a model of pointers
as URIs that authoritative triples can be associated with.
Triples can be associated with pointers through different means,
which we'll collectively call *signatures* (the pointer owner
signs triples about that pointer).

__ ../pointers_overview--benja/peg.gen.html

This PEG gives an overview of the different kinds of signatures
available.



Issues
======

.. None yet.



Temporary and permanent signatures
==================================

The major distinction is between *temporary* and *permanent* signatures.
Permanent signatures are guaranteed to last "forever"
(as long as the hash function isn't broken, and as long as Storm
is in use, and as long as no security holes are found in the Storm
specifications, that is), while temporary signatures have an
expiration date; before this date, they can be used to acquire a
permanent signature.

Permanent signatures are issued by a hierarchically organized set of
service providers, with a common root. Future PEGs will specify the
detailed mechanisms for permanent signatures, but the basic idea is
that if the root says that provider X says that provider Y says that
Z has signed a particular triple, and Y is authorized to make statements
about Z, and X is authorized to make statements about Y, then this
constitutes a permanent signature on the triple.

Signatures given through a public key cryptosystem fall under the
category of temporary signatures, because such a signature expires
when the key expires that the signature was given with. Temporary
signatures are necessary for a couple of reasons, most prominently:

- Permanent signatures aren't issued very often; I expect about
  twice a week. So you have to wait a few days before you can get
  a permanent signature on a triple, which is quite inconvenient.
- Off-line work. For example, you want to be able to sign a triple
  on one computer, store the signature on a floppy disk, and
  verify it on another computer, without either system being connected
  to the Internet.

In order to obtain a permanent signature on a triple, you submit a
temporary signature to the responsible provider. (Each pointer has
a provider that is responsible for signing triples for this pointer;
a future PEG will specify how this provider is determined.)
This provider will then take care that a permanent signature will be
issued on the triple at the next opportunity.

Sometimes temporary signatures are also called *tempsigs*, and
permanent signatures are called *permsigs*.



Pre- and post-revocation signatures
===================================

Keys used for signing tempsigs can be revoked, for example when they
are stolen by a cracker. However, while sometimes a verifier can check
whether a key has been revoked, at other times this is not possible;
for example, when working off-line.

Because of this, permsigs are issued even on tempsigs whose signing
key have expired. However, these permsigs are marked as *post-revocation*
signatures, i.e., signatures that were turned into permsigs after
their signing key expired.

Specifications that make use of triples about pointers can treat
post-revocation triples differently from pre-revocation triples.

In particular, when searching for the current version of a particular
document, post-revocation triples are not considered, even if their
timestamp is newer than that of any pre-revocation triple.

On the other hand, when viewing the history of a document, it is
expected that versions signed by a post-revocation signature
will be shown, but explicitly marked as post-revocation.
So after validating a tempsig, you can be sure that you can turn it
into *some* kind of permsig (as long as the key the signature
was given with hasn't expired).



Kinds of temp- and permsigs
===========================

There are actually two kinds of permsigs:

- The normal kind, given by the root saying something like,
  "Provider A said that provider B said that the owner of pointer P
  signed triple T."
- The triple is included in a list of triples in the pointer's *manifest*,
  the Storm block whose hash is the pointer's identity.

The latter kind is clearly permanent in the sense that it can be verified
as long as our hash function isn't broken.

There are also two kinds of temporary signatures:

- The kind discussed above, where signatures are given with a
  public key signature algorithm.
- For pointers maintained collaboratively by a group: Signatures given
  by one member of the group, and not yet certified by the provider
  responsible for the group pointer.

Basically, membership in a group is handled similarly to the association
of a public key with a pointer: A member is added to a group with a
membership expiration date, but the membership can be revoked before
it expires; in that case, only a post-revocation permsig is issued.

A future PEG will deal with groupwork functionality in detail.

\- Benja