A starter page for a protocol of digital signing. This would be a set of customs and actions undertaken by agreeing parties. It is not clear yet whether it is possible or efficient to make a broad horizontal protocol across all CAcert users; there remain substantial details to work out.
See DigitalSigning for main information.
Requirements for Digital Signing
All good protocol design start with laying out the requirements (6.1). In order to usefully compete with human face-to-face signing with support from Pen v1.0, digital signing protocol needs to meet several requirements:
R1. The agreement
The agreement needs to be identified. That is, the contract(s) or document(s) need to be clearly identified.
R1.a Preservation of identification
Such identification needs to be preserved.
R1.b Preservation of document
The document itself needs to be preserved.
R2. The Parties
The parties need to be recorded.
R2.a Precision in identification
Some precision is desired as disputes happen much later. Normally this is done by putting the full name of the party on the contract, and some other ancillary info to reduce the pool. Traditionally, the place of residence of the person. More recently, companies have used SSNs (or similar) or DoBs.
R2.b Multiple Parties
There may be more than 2 parties.
R2.c Types of Parties
Organisation versus Individual. Where an organisation enters into an agreement, normally one or more Individuals are authorised to make that so. In this case there will be both the Organisation Identity and the individuals who act on behalf.
R2. The Intent
The real intent of the parties should be recorded. This generally suggests something like "I agree to ..." It can be more complex for more serious contracts, and can include things like checkboxes for clarifying actual intent as opposed to blind signing.
R3. The Entire Record
For record should be singular. That is, the record should include all the necessary components for further use, even after a long time.
This indicates one document, one file. Multiple files tend to become separated.
R4. The Date
The date of should be recorded.
R4.a The Date of Signing
The dates of each signature should be recorded. The protocol should preserve some convention as to which is the date of effect of the contract.
R4.b The Time
For digital applications, precise times should be recorded for forensic purposes.
R4.c Date of Effect
The Date of Effect is generally the point at which the agreement is fixed. As there are revocation issues in digital signing, it would be generally better to check revocation after the signing. Hence a contract could be null and void if no revocation occurs beforehand.
The concept should stretch as far as possible towards simplifying the future.
The contract should easily be printable, with as much or all necessary components in the paper form. Disputes normally are resolved around paper documents, because Desk (v200x100mm) has more resolution that Screen (v40x30mm). Paper documents are easily firewalled in the human mind whereas digital documents are not.
This approach says that text documents are best, because it is easy to audit the contents. PDFs might be a pragmatic second, but even they have special artifacts inside, features available to more advanced readers. OpenOffice or Word documents are the worst.
The salient details should be recorded in the text. Even if the digital components include extra features, they are opaque without the right tools, and lost on paper. Digital tool rot starts within a few months, and with several years is highly advanced.
R6 Custom and Clauses
Some context has to be preserved such that the scope and custom of the agreement is reached. This might be a reference to another document, or a boilerplate clause that refers to jurisdiction and law.
A signature means different things depending on the purpose of signing. The meaning needs to be captured. E.g., a signature that was meant to mean "received delivery of book by courier" is not to be misinterpreted later on as "agreed to purchase book for $100".
A signing protocol should be tunable to different value propositions. E.g., it needs to cope with the scrawl accepting the book delivery, above, and the affirmation on a Will / Last Testament.
Some signing protocol needs are short term, others are long term. The protocol needs to cope with needs as short as a day, and as long as 30 years.
R8 Technology Robust
R8.a Neutral to Technology
Ideally a protocol should be able to be employed using different technological methods, or should at least integrate those methods in a holistic fashion. E.g., short term, low value signing (see R7) might be done with checkboxes, whereas high value, long term signing could be augmented by voiceprints and witnesses.
R8.a Robust to Technological Quirks
The signing should not fall apart when the tech breaks. E.g., revocation, expiry, key rollover should be dealt with without undue difficulties.