Work on how signatures are applied to paper documents in
financial transactions has pretty much convinced me that
cryptographic signatures should be considered a property of a
document at the application level. This is in distinction to
signatures and/or encryption used at the transport or file
system security level.
In particular, documents are originated, flow from one party
to the next, and accumulate more sections and signatures as they
are used to implement a business process. As such, they
become part of the document, and need to be verifiable by anyone
acting on the document.
Encryption, on the other hand, protects the document while in
transit from one party to the next, or while a party has the
document in storage. Consequently, the document is usually
encrypted and decrypted multiple times during a business
process.
Consequently, the HTML syntax may be a good candidate for:
- defining a structure of blocks over which hashs
and signatures are computed, and
- identifying the hash values, signature values,
keys, algorithm parameters and other components needed by the
signature system (including certificates in HTML syntax
instead of ASN.1?).
The system should be flexible enough to support, as a starter,
the ability to:
- sign a document,
- co-sign a document (either including or not
including the previous signature),
- signing or cosigning a part of a document,
- hashing Part A of the document and including the
hash in Part B so that Part A can be detached without breaking
the signature on Part B,
- including Part A in the scope of the hash on Part B,
so that the signature on Part B signs Part A without repeating
it in line.
- appending a Part C and signing any of the previous
parts in combination with Part C,
- inserting a note in Part A and signing it, without breaking
a previous signature on Part A.
For a concrete example of how this might be used, consider a
check which you send along with an order or invoice. The
check should be attached to the invoice. It may be co-signed
if it is a two-signature account. It may be certified, which
adds information and a bank signature. The merchant detaches
the order or invoice document, adds an endorsement, and deposits
the check.
To implement this, the browser should have the capability to
let the user add sections to the document, mark sections of
the document for signature, sign, and send the document back to
the web server for forwarding to the next party. This seems a
little at odds with how the web works today.
Probably less controversial would be the notion that the
browser should be able to display the signatures, along with
some graphical indication (color shading) of the scope of the
signatures and/or hash values. Along with suitable indication
of whether the signatures verified correctly.
Since being able to create signatures at the browser would
determine the usefulness of any proposed HTML syntax for
signatures, it would be nice to first hear whether there
are any plans to enable browsers to modify and return HTML
documents, or whether HTML is only to be used from server to
client.
Milton Anderson
milton@bellcore.com