Certificate Facility

The Certificate facility provides a utility for the signing and validation of standalone certificates in RFC 822 format. Such certificates may be used as orders, receipts, licenses etc. In some cases a certificate may perform more than one function. For example a certificate returned as the receipt for a transaction may also be the license key for the product.

Requirements

The requirements are divided into two parts. At the highest level the user requirements specify the main goals. The functional requirements define technical goals that are implied by the high level goals.

User Requirements

Provide proof of offer and acceptance of a contract.
Provide run time licensing for code and data modules.
Permit indexing, cataloging and other administrative tasks.
Permit distribution of cryptographic keys.

Functional Requirements

Machine Parsable: A certificate must be parsable using a simple finite state recogniser.
Human Readable: A certificate must have a clear format, instantly recognisable by human users. This format should be suitable for inclusion in other documents such as word processed files or mail. It is a desirable but not a necessary requirement for validation of certificates presented in such documents to be possible.
Permit Standalone Validation: It should be possible to validate a certificate without requiring instalation of network code.
Be Extensible: The format of the certificate should permit application to as wide a range of needs as possible
Utilise existing code and specifications where possible.

Suggested Implementation

RFC-822 provides a convenient format for presenting information.

Issuer:                      CERN
Authorization:               WEB-94-001
Authorized-User:             Phillip M. Hallam-Baker CERN ECP PTG
Product-Name:                Webmaker
Producer:                    CERN-PTG
Units:                       0
Version:                     1.0
Start-Date:                  01-Jan-1994
Expriy-Date:                 31-Dec-1995
Availability:                0
Options:
Hardware-ID:

Another presentation option would be to use SGML. This would however require a set of standards for the signing of SGML documents. Shen already provides a means of signing an RFC-822 module.

Possible Tags

In addition to the standard MIME tags it is convenient to give special meaning to the following:

Start-Date: Date and time at which Certificate is first valid. If unspecified defaults to current time.
Expriy-Date: Date and time at which certificate ceases to be valid. If unspecified defaults to no expiry date.
Hardware-ID: Hardware identifier or other machine specific attribute required for validity of the certificate.
Issuer: Distinguished name of the certificate issuer.
Authorization: Authorisation identifier. Must be guaranteed unique in same manner as RFC-822 Message-ID except that occurrence must be unique in all time.
MIC-External: Signature of a software component module referenced by the given URI.

In addition to the above it is desirable that other necessary commercial information be expressible. For example taxation registration codes (such as European Union V.A.T. numbers).

The definition of tags within a certificate should have a well defined legal meaning. If a certificate is to be signed which contains tags which do not have a recognised meaning within the specification these tags should be queried prior to the signature being applied.

The X- convention should be used for all application or contract specific tags. Provision should be made for ensuring that the definition of such tags be clearly defined legally. Eg by registering the definition of the tags within a contract with a third party or by enclosure of the contract terms within the certificate.

Implications for the FORMS interface.

The Certificate handling module should be closely related to the forms interface. A user must be protected from being tricked into signing a bogus order through use of hidden fields in a form. Provision must also be made to permit additional safeguards when a form is signed with a particular signature (eg one valid for monetary transactions). Such proceedures may involve a requirement for a particular form to be countersigned by another party or for an additional checking stage to be performed.

Adopting RFC822 header format as a standard for interchange of form data has a number of advantages. The format is easily understood by a user and it is practical to present a user with a form in the encoded format prior to final dispatch. There already exists an authority for defining semantics for header tags. Finaly an RFC822 system could be accessed by users with mail only access to the Internet while reusing substantial quantities of code.

Implementation.

A prototype implementation has been made in C and a grammar description language. This contains the following modules:

Main Calling Program: The main calling program binds the other modules together.
Command Line options Parser: Command line options are parsed to produce an abstract form convenient for the rest of the program.
MIME tag parser: MIME parsing is performed using a table driven parser. The tables and driving code are synthesized automatically from an abstract form.
Validation Module: Certain tags have a semantics which must be checked for validity such as the expiry date of the certificate etc.
Crypotographic Module (Shen): Digital signatures are applied and validated using the Shen security library.
Utilities: Micellaneous utilities provide for date format conversion and other tasks.

Unresolved Issues.

The following issues are not yet resolved:-

Canonical form: Should a certificate be translated into a cannonical form prior to signature? Such a transformation would permit certificates to be validated when included in documents that do not preserve structure exactly. Such a transformation would however require a cannonical form to be defined and might require information as to the particular data format being used to make generation possible.