Table of Contents

The Management of a SOX-conformant Server

The Issuer Infrastructure

The Issuer Infrastructure achieves the purpose of connecting up clients (WebFunds, et al) to a SOX-compliant server. It is a layer above SOX, and a part of the full Ricardo infrastructure.

There are the following elements in the Issuer Infrastructure:

The SOX Server Descriptor

On a SOX-compliant server there exists an info file called the SOX Server Descriptor (SSD) that describes information to do with that server. The contents of the SSD are one-to-one with a given server (although the file containing the SSD may be duplicated at several URLs, and there may be several alternate addresses for each server). The SSD instantiates the concept of the SOX-compliant Server (such as a Ricardian Issuance Server).

The addresses may be domain names or IP numbers, if DNS problems are indicated. This avoids primary DNS server lockup delays, and in a sense, implements a local form of DNS.

The syntax and layout formats of the SSD is defined in the same way as the Ricardian Contract.

The [sox] section

The [application] section

Remaining sections are application specific and not defined by the SOX definition.

The [misc] section

A Misc section has been added for random stuff.

Purposes of Keys

PGP keys have a userid field which for Ricardian Contract purposes includes a Ricardian key purpose tag. The tag is simply a word surrounded by [square] brackets.

The following intentional purposes for keys are defined. Appended numbers indicate minimum recommended key sizes, in bits.

The purpose is a lower case word surrounded by [square] brackets. It is stored in the user id.

The keys are used for differing purposes, allowing, for example, the [certification] key to be inefficient but strong, whilst the [comms] key can be efficient, and hence not as strong. To guard against a swapped key attack, user software should check that the purpose is correct.

Both the contract and the SOX protocol require a public key signing chain in order to authenticate dynamic actions initiated by a client such as WebFunds. The major purpose of this public key infrastructure (PKI) is to direct the authentication up a chain to a single key for each substantial question that might be asked.

SOX generally prescribes that the user id should also include the following substrings, currently only for human consumption:

Deprecated. This section does not relate to SOX 2 (which used x.509, whose keys had no purpose tag available).

Issuing a New Digital Financial Instrument

The digital financial instrument, more simply known as an item, can be managed by an issuer simply by honouring requests on a hash of a contract, and by injecting value into the item within the system.

As of the moment, there is no difficulty in any outside user creating their own currency. However, there is a lot of difficulty in them injecting value into the system. This is unlikely to remain so in the future, if only for marketing purposes. Currently, however, it is not a problem as there is no security implication in users creating a worthless currency.

Issuance of New Contracts

In the mounting of contracts, a phased approach is taken:

1. take the contract and conduct sanity checks on it to catch any errors that might have occurred. If an error is spotted, it is referred back to the Legal Issuer for correction and resigning. This phase is concerned with the technical format of the contract, not with its legal content. For example, misplaced or illegal characters that the software cannot read are checked for.

2. Place the contract within the domain of the server, and test that the various features are turned on and working. For example, balance sheet reporting is checked.

3. Await the notification for the mint account. A mint account is required for every contract, and this is created and controlled by the Legal Issuer (or more properly, his agent). Once the Legal Issuer designates which account is the Mint account, then that account is turned into a Mint, and the Legal Issuer can start to create and disburse value.

That is the end of the big steps, but bear in mind there is a lot of administrative detail behind those steps. There is much more information on issuance on the Ricardian Issuance Page.

Initiating the New Contract

To introduce the contract to the outside world, you will need your [contract] key, signed by the former (see above). Follow these steps

Injecting Value into the System

To manage the contract, you need to inject value into it in a controlled fashion. Follow these steps:

Take a moment to think about these steps. The total system is still at a net balance of zero. If you add up the amounts, it should all balance, and in fact, that is what has to happen always for the system to work.

In fact, if you run the special issuer management tool on your currency:

	lam_sheet -item MD5:abcdef1234567890

you will see that the net balance shown at the end is zero.

Annex 1: The PGP Key Ring Entry

A PGP Key Ring Entry is used as the unit of delivery for keys in the SOX key infrastructure. PGP (Pretty Good Privacy, as trademarked by PGP, Inc) is documented voluminously elsewhere. Only relevant sections are included here. See the file doc/pgformat.doc in your PGP documentation for more details.

The PGP Key Ring Entry, or Entry, consists of:

Other defined terms are: