The contracts, financial instruments, and negotiable instruments used today by financial institutions are writings on paper which are authenticated by handwritten signatures. Electronic documents, authenticated by cryptographic digital signatures, can have the same properties of integrity, authenticity of origin, and non-repudiation as paper documents, and they can be used as direct replacements for the paper documents.

However, to replace paper documents signed electronic documents must be able to be processed like paper documents in multi-party work flows. A work flow node must be able to:

• receive signed documents from multiple prior nodes and verify the existing signatures,
• create new documents intended for subsequent nodes by selectively combining parts of the input documents without invalidating signatures on those parts, and
• signing appropriate parts of the new documents and forwarding them to subsequent nodes in the work flow.

As concrete examples of these functions, a payee must be able to remove attached remittance advices from an electronic check before endorsing and depositing it. A payee must also be able to combine endorsed electronic checks from multiple payers and create a single deposit to his bank.

While the FSTC's experience and existing trials relate to financial instruments, these capabilities are important to the use of XML for secured work flow documents in general applications.

FSML was based on SGML and differs from well-formed XML principally by omitting end tags on leaf elements and by using un-ordered lists. FSML 2.0 will be based on XML and will expand the types of information carried in FSML documents. However, based on our experience with FSML implementations, the currently defined structure of the digital signatures satisfies the business requirements for signing structured information in financial instruments.

Electronic checks in FSML are being used in a US Treasury Market Trial to pay suppliers to the Department of Defense. The electronic checks are drawn by the US Treasury Financial Management Service on a US Treasury account at the Federal Reserve Bank of Boston. They are emailed to suppliers who process the payments, and detach, endorse and deposit the electronic checks by email to their accounts at Bank of America and BankBoston. Checks of up to $100,000 each have been processed and cleared between Bank of America, BankBoston and the Federal Reserve Bank of Boston. The trial implementation followed security analyses and studies to satisfy banking and government auditors and regulators that payments over the Internet could be made safely using FSML signed electronic documents.

Bank servers which process FSML and verify signatures have been developed by IBM and Sun. Electronic check writing, endorsing and depositing applications have been developed by RDM Corporation for use with electronic checkbook smart cards from Information Resource Engineering (IRE). The public key infrastructure and card initialization and issuance processes have been implemented by GTE Internetworking and IRE.

Expansion of the trial, additional trials and standard commercial operations are planned for 1999, both domestically and internationally.

We expect and desire that the Workshop will result in a charter for a W3C Digital Signature Working Group which will standardize:

• an XML idiom for a digital signature element and sub-elements which is generally useful for XML work flow document signing, as well as for signing forms expressed in XML,
• the schema and semantics of common information contained in the digital signature element sub-tree,
• the naming and linking conventions by which other elements signed by the signature element are referenced, taking into account the need to be able to detach signed elements without invalidating the signature and the need to be able to combine signed content from multiple documents which may have name collisions,
• normalization, canonicalization and hashing functions taking into account the concrete encodings of the XML character set, the processing of character entities by XML processors, the name spaces of the signed elements, and so forth,
• the use of signature algorithms, how the signatures might be created using widely-available cryptographic APIs, and how they might be verified using widely-available public key infrastructure.

The Working Group should also study and recommend how:

• digital signatures relate to XML Schemas, Document Object Models, Style Language, Forms and other XML recommendations and standards.

Following are design objectives for FSML signatures which the Working Group should consider in its development of requirements for digital signatures.

Cryptographically Signed Financial Instrument -- FSML signatures were designed to allow the use of cryptographically signed electronic documents in place of paper financial instruments. The only exceptions are bearer instruments, which are not allowed due to the ability to make perfect copies of digital instruments. Otherwise, all signature operations commonly found on paper documents were intended to be supported.

Detaching of Parts of Signed Documents -- In the flow of financial documents, parts of the document may be removed by one of the parties to the flow. For example, the payee may remove an invoice attached to the payment. The FSML signatures are created by signing the hash of a set of hashes on individual blocks of information in the FSML documents. This supports removal of individual blocks without invalidating the signature with respect to the remaining blocks.

Combining of Signed Documents -- In a flow of financial documents, multiple documents individually signed by previous parties may be combined into a single document and sent on to one or more subsequent parties. An example is a deposit document, which includes multiple endorsed checks, deposit slip information, and the depositor's signatures. The FSML document structure provides for enveloping FSML documents within other FSML documents, and the name references are disambiguated with respect to the document structure.

Compatibility with Smart Card Processing -- FSML documents and the signature blocks have relatively simple structures. This allows FSML document parts to be passed to smart cards, with the hashing and signing taking place within the smart card. Hashing and creation of the signature block on the card enable the use of card-produced nonces during hashing and the insertion of user information secured by the card

Nonce to Strengthen Hashing -- One class of attacks on hash algorithms is to create two messages M1 and M2 which both hash to the same value H, dupe the victim into signing M1, and later substitute M2. The successful attack on MD4 by Hans Dobbertin was of this type. FSML specifies that the smart card compute a random nonce, prefix it to the blocks before hashing, and include the nonce in the part of the signature block that is hashed and signed. Since no one outside of the smart card can control the message being hashed, the type of attack described above is defeated.

User Information in Signature -- FSML signatures provide for the insertion of user identity information into the signature block by the smart card. The smart card allows the signer to choose which information is inserted (e.g. telephone number, drivers license, social security number) but the signer has no control of the values. The specific values are written into the card by the card issuer at initialization time. This provides a reasonable degree of assurance to recipients, such as merchants or check guarantee services, that the information is valid (up to the tamper-resistance of the smart cards), while providing signers with control of which information is disclosed with each signature in order to address signer's privacy concerns.

Signature Types -- FSML signatures include a signature type to identify a signature as one of the following types: check, endorsement, deposit, co-sign, counter-sign, co-endorse, counter-endorse, log-signature, bank account, certification, endorse to third party and generic. Signers are restricted to being able to make only specific types of signatures by parameters in information signed by the bank. Thus, one signer (e.g. a treasurer) may be able to make the original signature on checks while another signer (e.g. another officer of the corporation) may be restricted to only co-signing the checks. This allows finer control over key usage than the restrictions currently provided in standard X.509 Version 3 certificate extensions.

Logging to Provide Receipts -- FSML includes specific elements in the check and endorsement blocks which are logged in the smart card in order to satisfy Regulation E requirements for provision of receipts of a transactions.

Canonicalization and Hashing Rules -- FSML specifies the character repertoire, line lengths, white space treatment, allowed white space within tags, processing of character entities, and other rules related to hashing of the FSML blocks. Some of these issues will not apply to XML in general, but they must be specified in detail in order to ensure reliable signatures. It would be prefered to have a single canonicalized format which can be computed efficiently by smart cards using the external representation, by browsers from the document object model, and by high-volume servers using special-purpose parser/verifiers.

The FSML signature block has the following structure:

An FSML documents begins with an fsml-doc start tag which has the docname and type attributes. Type plays a role similar to referencing a DTD. An FSML document can contain FSML documents and/or FSML blocks, where a block is an element that has the standard first elements of blkname, crit, and vers. Since both the blkname value contained in the hashed block, and the blockref value in the sigdata scope of the signature block are hashed and signed, the values cannot be changed. Thus, if the same blockref value occurs in two signed documents being combined into a third document, there will be a name collision.

FSML avoids this name collision by assuming that a signature block contained in a document refers to signed blocks within the same document. Application of a subsequent signature is done by wrapping the two or more documents to be signed in an outer FSML document and placing the new signature block in the outer document. The new signature in the outer document may sign blocks in inner documents by referring to them by a dotted concatenation of docname and blkname values.

The FSML certificate block has the following structure:

As described above, the signature block can reference a certificate block by the blkname of the certificate block, or it can reference the certificate issuer and serial number. Therefore, both are carried in FSML syntax in the cert block, so that the application can easily recognize which block carries the certificate without decoding and parsing the certificate itself. The certificate references also allow certificates to be passed by reference, instead of by value, and the mechanism is able to support PKI approaches which do not use certificates, but rely on storage of public keys in association with customer account databases.

The FSTC is sharing its prior experience and current design with the W3C because we believe that a common approach to signed XML can be applied to a wide range of signed XML documents and forms. This is a fundamental security infrastructure component which can greatly encourage and assist the movement of business communications and financial information from paper to electronic form. Once it is available, the implementation of specific applications is largely a matter of establishing standards for the content of business documents, much of which can be based on business practice, law and regulation already established for paper documents.