[This local archive copy mirrored from the canonical site: http://www.w3.org/TR/1998/NOTE-SDML-19980619 980621, text only; links may not have complete integrity, so use the canonical document at this URL if possible.]

NOTE-SDML-19980619

SDML - Signed Document Markup Language

W3C Note 19-June-1998

This version:

http://www.w3.org/TR/1998/NOTE-SDML-19980619

Latest version:

http://www.w3.org/TR/NOTE-SDML

Authors:

Jeff Kravitz

Copyright © 1996, 1997, 1998 Financial Services Technology Consortium. All rights reserved.

Contents

• 1 Introduction
  • 1.1 Background
  • 1.2 Business Objectives
  • 1.3 Technical Decisions
  • 1.4 Structure
• 2 Notation
• 3 Document Formatting Rules
  • 3.1 Character Encoding
  • 3.2 Line Formatting
  • 3.3 Space Handling
  • 3.4 Tags
• 4 SDML Document Definition
  • 4.1 Electronic Document Definition
  • 4.2 Block Common Field Definitions
    • Common Block Field Definitions
  • 4.3 Block Definitions
    • 4.3.1 Action Block Definition
      • 4.3.1.1 Action Block Field Definitions
    • 4.3.2 Signature Block Definition
      • 4.3.2.1 Signature Block Field Definitions
      • 4.3.2.2 Signature Calculation
    • 4.3.3 Certificate Block Definition
      • 4.3.3.1 Certificate Block Field Definitions
    • 4.3.4 Attachment Block Definition
      • 4.3.4.1 Attachment Block Field Definitions
    • 4.3.5 Message Block Definition
      • 4.3.5.1 Message Block Field Definitions
• 5 Document Structure
  • 5.1 BNF Structure of SDML electronic documents
    • 5.1.1 BNF Meta-Notation
    • 5.1.2 BNF Definition of Non-Terminals
    • 5.1.3 BNF Definition of A Signed SDML Document
    • 5.1.4 BNF Definition of a Multiply-Signed SDML Document
    • 5.1.5 Document Structure Diagram
• 6 Combining Documents
• 7 ASN.1 Definition of X.509 Version 1 Certificates
• 8 Field Summary
  • 8.1 Field Attributes Table
• 9 Verifying Certificates
• 10 Bibliography
• 11 Issues and Directions
• Appendix A - SGML Document Type Definition (DTD)
• Appendix B - Definitions
• Appendix C - Acknowledgments

1 Introduction

A child of five would understand this. Send someone to fetch a child of five.

- Groucho Marx

Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin.

- John von Neumann

Make everything as simple as possible, but not simpler.

- Albert Einstein

Research is what I'm doing when I don't know what I'm doing.

- Wernher Von Braun

PROGRAM: n. A magic spell cast over a computer allowing it to turn one's input into error messages. tr.v. To engage in a pastime similar to banging one's head against a wall, but with fewer opportunities for reward.

Then anyone who leaves behind him a written manual, and likewise anyone who receives it, in the belief that such writing will be clear and certain, must be exceedingly simple-minded.

- Plato, Phaedrus 275d

Read over your compositions, and where ever you meet with a passage which you think is particularly fine, strike it out.

- Samuel Johnson, quoting a college tutor, 1773

The knowledge of Cyphering, hath drawn on with it a knowledge relative unto it, which is the knowledge of Discyphering, or of Discreting Cyphers ... Certainly it is an Art which requires great pains and a good wit, and is (as the other wits) consecrate to the Counsels of Princes.

- Sir Francis Bacon, 1623

1.1 Background

The Signed Document Markup Language (SDML) was developed by the Financial Services Technology Consortium (FSTC) as part of the Electronic Check Project. SDML is designed to:

• tag the individual text items making up a document,
• group the text items into document parts which can have business meaning and can be signed individually or together,
• allow document parts to be added and deleted without invalidating previous signatures, and
• allow signing, co-signing, endorsing, co-endorsing, and witnessing operations on documents and document parts.

The signatures become part of the SDML document and can be verified by subsequent recipients as the document travels through the business process. SDML does not define encryption, since encryption is between each sender and receiver in the business process and can differ for each link depending on the transport used.

SDML is the generic document structuring and signing part of the Financial Services Markup Language (FSML). FSML defines the specific document parts needed for electronic checks, the tags which identify check-specific data items, the semantics of the data items, and processing requirements for electronic checks. FSTC will be releasing the FSML specification implemented in the U.S. Treasury pilot along with a proposal for version 2.0 of FSML in the near future.

When development of FSML began in 1995, HTML was in its early stages of widespread deployment. SGML had been standardized some years earlier, software tools were readily available, and the use of tagged, readable text was attractive for its simplicity, ease of understanding, operational support, and ease of development and use. FSML/SDML were designed so that they could be defined using an SGML Document Type Definitions (see Appendix A). FSML also defined document formatting rules so that readable text electronic checks could be sent via electronic mail systems without the risk that the mail systems would modify the electronic check in ways that invalidate the signatures.

SDML is being published now to inform industry associations and standards bodies about the FSTC's experience, to show how cryptographic signatures can be embedded in structured, tagged-text documents, and to show how the business requirements of a typical application can be met. Given the standardization of XML and the widespread use of MIME attachments for sending documents with 8-bit transparency, FSTC wants to engage in discussions around how SDML and XML inter-relate and how these two approaches, which had different initial objectives, can be brought closer together and made compatible and as consistent as possible.

FSML has been implemented by the Electronic Check Project. A pilot implementation is in operation using payer and payee software to send, receive, and deposit electronic checks over the Internet. Cryptographic hardware, in the form of smart cards, has been developed to contain the private signing keys, perform the hashing and signing operations, and to perform other "electronic checkbook" functions, such as automatically numbering and logging checks written or deposited. Advice of payments are attached cryptographically to the checks when sent between payer and payee, and they are removed by the payee. Similarly, checks are attached cryptographically to deposit slips when they are sent to the payee's bank. Bank server systems have been developed to process the electronic checks, to interface with existing check processing systems in the banks, and to clear and settle electronic checks between banks. A Certificate Authority hierarchy has been established, and certificates have been issued to banks and checking account holders.

The Electronic Check project, from its inception, sought to develop a general solution to the issues of authentication and integrity associated with creating electronic financial instruments. The technical and business problems of implementing electronic check payments between payers and payees over the Internet provided a practical context for developing the solution.

Paper checks have a rich tradition, and support numerous options, check types, attached information, and sophisticated processing. However, paper checks are fundamentally a "signed writing directing a bank to pay money, after a date, from the payer's account." The Electronic Check project determined that the essence of the problem to be solved was to develop a generalized structure for creating, processing, and displaying electronic "signed writings," where cryptographic signatures would substitute for manual signatures and where an electronic message would take the place of the paper medium. The structure would need to support the same business operations as signed paper checks, such as signing, co-signing, and witnessing of signatures, and attaching and removing associated documents such as remittance slips, invoices, advice of payment, and deposit slips.

Since checks are a form of negotiable instruments, and negotiable instruments are a form of contracts, it is believed that SDML may be used to create signed documents suitable for a wide variety of purposes. For example, they may be used as messages to initiate electronic funds transfer, as orders and invoices needed for electronic commerce, or for other forms of signed contracts or agreements.

SDML documents, which are hashed and cryptographically signed using public key signature algorithms, can have the following security attributes:

• Verifiability of Origin --A document recipient can authenticate that the document was created by a specific person or institution, and that the signature was not forged or created by an impostor.
• Integrity -- A document recipient can determine that the document has not been altered in any way since it was signed.
• Accountability -- A document recipient can prove to a third party that the document was created by the signer even if the signer repudiates the document, unless the signer can also establish that someone else has possession or control of his private cryptographic signing key. 

The SDML signature mechanism allows documents to be combined, or added to, without loss of these attributes with respect to prior signatures or the pre-existing parts of the documents.

The Financial Services Technology Consortium (FSTC) is a not-for-profit organization whose goal is to enhance the competitiveness of the United States financial services industry. Members of the consortium include banks, financial services providers, research laboratories, universities, technology companies, and government agencies. 

1.2 Business Objectives

Some of the business objectives that were instrumental in the design of SDML were...

• To develop a general method for creating and verifying business documents at the application level with integrated digital signatures;
  • To provide assurance to the application and the customer;
  • To eliminate the need for paper source documents;
  • To allow incorporation into a number of different business applications;
  • To support peer-to-peer exchanges;
  • To keep, indeed to require, the signatures integrated with the documents;
  • To identify the individual or organization which created the documents;
  • To identify the individuals or organizations which process the documents;
  • To support signing, cosigning, counter signing, endorsing, and "initialing";
  • To be vendor-neutral;
  • To be cryptographic algorithm-neutral;
• To provide a high degree of flexibility in the information content and structure of the signed documents;
  • To support a wide range of different documents;
  • To allow for efficient processing;
  • To clearly define the scope of a signature such that different signers could sign different parts of the same document, or indeed, where needed, could sign someone else's signature;
• To provide for the attachment and removal of auxiliary documents while still maintaining the digital signature integrity;
  • To allow binding information together;
  • To allow removal of information when it reaches its intended recipient to protect privacy and improve efficiency of later handling;
• To be usable through any electronic transport media;
  • To enable an end recipient who does not expect a signed document to understand what he or she received;
  • To be independent of the network or electronic communication system used;
  • To work through online connections, such as provided by the WWW or secure sockets;
  • To work through any electronic mail system, including "plain old text e- mail;"
  • To work through legacy communications and computer systems;
• To allow documents to be as self-contained as possible;
  • To recognize and support different documents which have different security and time duration and immediacy requirements;
  • To simplify the processing;
  • To enable critical processing to occur in simple devices, such as smart cards, where appropriate to the application;
  • To provide reasonable assurance to off-line or off-network processing;
  • To minimize the reliance on third parties;
  • To minimize the need for third-party directories;
  • To minimize the need for security databases at the end users;
  • To simplify auditing and research;
• To provide control to the transacting parties;
  • By providing flexibility in managing transaction risk as needed;
  • By allowing direct peer-to-peer exchanges;
  • By minimizing systemic risk to transacting parties by supporting inexpensive secure processing devices such as smart cards;
  • By enabling document semantics to control issues such as transaction-effective dating and validity intervals;
  • By enabling third-party services, such as time stamping, electronic postage, third party processing, or archival storage as needed by the transacting parties;
  • By allowing separate control of the privacy requirements;

1.3 Technical Decisions

The above business objectives led to a number of technical decisions, based on much thought and discussion amongst the team members. Some of these technical decisions were:

• An SGML-derivative language was chosen because it was an ISO standard, and had the additional benefit of using standard "printable" ASCII text. Using a binary encoding method (e.g. ASN.1) would have meant that all SDML documents would require special decoding software just to be viewed or even detected. This seemed too much of a burden since the uses and platforms envisioned would have been too many and diverse for such viewing software to become easily available. Using an ASCII text-based language meant that a casual user could still look at and identify an SDML document, with only normal e-mail, Web, or other ASCII-text viewing capabilities.
• It was decided to subset many of the SGML features (e.g., limited use of SGML end-tags) to allow SDML documents to be more easily processed by devices and systems of lower complexity. It was envisioned that some of the processing may be done on "electronic tokens" meaning PDAs, PCMCIA cards, or even smart cards, with limited memory and processing capabilities.
• Formatting and encoding rules that are not part of the ISO SGML standard were added to allow SDML documents to pass, uncorrupted, through a variety of transport mechanisms, especially e-mail, and still allow the signatures to be valid. This decision has been very useful, and appears to be one of the key items in SDML.
• It was decided to keep SDML documents independent of the transport mechanism used to transfer them from party to party. Thus, they can be transported by a large variety of mechanisms, e.g., e-mail, Web (HTTP), FTP, or even as files on a diskette (sneaker-net).
• Although privacy is a very important requirement, it was decided not to incorporate a privacy encoding scheme into the SDML definition, as a number of privacy encoding methods and systems were being defined by others, and it was felt that this decision could best be left in the hands of the other groups who were doing that for the various transport mechanisms, e.g., S-MIME, PGP, etc.
• SDML is designed to be extensible. Additional document types and blocks (sub-elements) may be added for specific applications (The FSTC E-check project uses this feature extensively). In addition, SDML, as defined in this document, allows attachment and signing of virtually any kind of attached document or file, with no additional SDML changes or extensions required.
• The basic document signature mechanism was designed to allow attachments to be added to and detached from an SDML document, and for additional signatures to be added after original document was created. Thus, the signature mechanism was though of as a kind of "electronic staple."
• All the signature verification information (except for the public key of the root of the certificate hierarchy) is in the SDML document itself. Thus, any document recipient can perform a full cryptographic signature verification on the document without the need for access to external networks, directories, servers or databases. The only external information needed is the root public key, which can be easily distributed widely.
• It was decided to use X.509 certificates, even though they do not fit in well with other SDML design goals (e.g. use of binary ASN.1 instead of human-readable ASCII) because they have become a widely adopted standard for public-key certificates. Note, however, that the SDML language allows for specification of other certificate types.
• The signature algorithms chosen are the most popular at the time this specification was designed (e.g. RSA/MD5, DSA/SHA-1); however, the SDML language allows specification of other algorithms which may become available in the future.

1.4 Structure

Below is an example of a signed electronic document:

<sdml-doc docname="doc87" type="sample">

<action>
<blkname>act1
<crit>true
<vers>1.0
<function>sample
<reason>process
</action>

<attachment>
<blkname>att0123
<adata encoding="text">
This is a sample attachment
</adata>
</attachment>

<signature>
<blkname>sig7
<crit>true
<vers>1.0
<sigdata>
<blockref>act1
<hash alg="sha">278B7F348EECE3822A48C4D197FD5B920001C2E8
<blockref>att0123
<hash alg="sha">BC59D2FE5566F506910C5020B628E4136E1C6B39
<nonce>9D9BC5AA75
<sigref>cert-111111111-00000001
<algorithm>sha/dsa
<location>us
</sigdata>
<sig>
2489E1E376F5CD823274010B0A6028EA3F2763F2:290B95F8F02CF6616B9C3A03DF0B50295A1
62295
</signature>

<cert>
<blkname>cert-111111111-00000001
<crit>true
<vers>1.0
<certtype>x509v1
<certissuer>/C=US/ST=NY/O=FSTC/OU=NYCA/
<certserial>1
<certdata>
308201F0308201B0020101300906072A8648CE380403303D310B300906035504061302555331
0B3009060355040813024D44310E300C060355040A130542414E4B413111300F060355040B13
08636865636B696E67301E170D3937303431343031353930305A170D39373130313130313539
30305A3050310B3009060355040613025553310B3009060355040813024D44310E300C060355
040A130542414E4B413111300F060355040B1308636865636B696E673111300F060355040313
0831313131303041313081EE3081A606072A8648CE38040130819A02408DF2A494492276AA3D
25759BB06869CBEAC0D83AFB8D0CF7CBB8324F0D7882E5D0762FC5B7210EAFC2E9ADAC32AB7A
AC49693DFBF83724C2EC0736EE31C802910214C773218C737EC8EE993B4F2DED30F48EDACE91
5F0240626D027839EA0A13413163A55B4CB500299D5522956CEFCB3BFF10F399CE2C2E71CB9D
E5FA24BABF58E5B79521925C9CC42E9F6F464B088CC572AF53E6D7880203430002406BEFFB5F
20C39FFEE2E9574599EB606BCE9910086F9FF7F22FAA722E7CB028F1D2FADBCD7FBF4FD16AFF
C90D4BA82B2819FBA754873F2F49B6FC8C89528AE591300906072A8648CE380403032F00302C
0214524F78883CAFC10AA73BED1DDC24F2F4E821042902141C89356DBE7A77755F101E750310
910CE325DB7E
</cert>

<cert>
<blkname>cert-111111111
<crit>true
<vers>1.0
<certtype>x509v1
<certissuer>/C=US/O=FSTC/OU=FSTC CA/
<certserial>1
<certdata>
308201DF3082019F020101300906072A8648CE380403303F310B300906035504061302555331
0B3009060355040813024D44310D300B060355040A13044653544331143012060355040B130B
636865636B696E67204341301E170D3937303431343031353130305A170D3937313031313031
353130305A303D310B3009060355040613025553310B3009060355040813024D44310E300C06
0355040A130542414E4B413111300F060355040B1308636865636B696E673081EE3081A60607
2A8648CE38040130819A02408DF2A494492276AA3D25759BB06869CBEAC0D83AFB8D0CF7CBB8
324F0D7882E5D0762FC5B7210EAFC2E9ADAC32AB7AAC49693DFBF83724C2EC0736EE31C80291
0214C773218C737EC8EE993B4F2DED30F48EDACE915F0240626D027839EA0A13413163A55B4C
B500299D5522956CEFCB3BFF10F399CE2C2E71CB9DE5FA24BABF58E5B79521925C9CC42E9F6F
464B088CC572AF53E6D788020343000240732584AF3193B908F41D3AA68680421C6661EA259D
4146D48F2258669A189463375D4C38040278903992D18A2ECA9B66F4046962BA7A26433CA662
12314BDBEB300906072A8648CE380403032F00302C021456A0A84E997EB0772DD592753338E9
D65B0795750214269AAE91801D9E80B8004A89225E27915044EA40
</cert>

</sdml-doc>

The above sample consists of a simple attachment (containing merely the character string "This is a sample attachment"), which is then signed. It also contains an <action> block which indicates the action to be performed when the document is received, a <signature> block, which contains the digital signature of the relevant blocks in the document, and two <cert> blocks, which contain the certificates (and thus the public keys) of the document signer, and the issuer of the public key for that signer. These blocks will be described in detail below.

An SDML electronic document is comprised of a number of blocks. as defined in the SDML definitions below. Each block contains some common fields, or elements in SGML terminology, and also contains fields that are specific to the type of block. Blocks are not nested; however, they are contained in <sdml-doc> elements, which can be nested.

All blocks that must be protected from tampering and all blocks that must be authenticated are signed using a digital signature, which is contained in a signature block. The digital signature uses one of the standard digital signature algorithms, such as MD5/RSA or SHA/DSS, although the use of MD5 is deprecated. Each signature requires a public key, which also requires a certificate. Certificates are currently distributed as X.509 certificates.

Blocks may also be "bound" together by the signature block, which contains the block names of the blocks being bound, the digital hashes of these blocks, and a digital signature on these hashes along with the other contents of the signature block. This binding allows the receiving software to verify that all blocks that were bound are present and have not been tampered with.

The concept of the SDML electronic document is that it is a flexible structure. Separating signatures, certificates, actual data, etc., into separate blocks allows a rich, complex document to be built from these "primitives," while retaining a standard format which can be parsed and verified according to a standard syntax definition. 

2 Notation

In the pseudo-SGML definitions below, an attempt is being made to show examples of the SGML format for SDML electronic documents, rather than to use formal meta-linguistic notations to define them. A more accurate definition is later in the document using more formal notations (Extended BNF and SGML DTD).

In these definitions, the following simple notations are used to indicate the type of value being used for a particular field:

3 Document Formatting Rules

In order for the SDML electronic document to be easily transmitted by a variety of methods (e-mail, file transfer, storage media, etc.) it was designed to be a plain ASCII document. However, certain formatting rules must be adhered to in order to ensure that most of the usual transport mechanisms, in particular e-mail systems, will successfully transport the SDML electronic document unchanged.

Note that these rules supersede the white space and line end rules for SGML, in order to ensure that signed documents can be successfully verified. Therefore, the following document formatting rules are considered mandatory for document generators and receivers:

3.1 Character Encoding

• All characters in the document should be chosen from the ASCII subset known as printable characters (ASCII values 0x20-0x7E), except for line-ends (see below). Any characters found in the document that are not in this set (i.e., 0x00-0x09,0x0B,0x0C,0x0E-0x1F,0x7F-0xFF) are disallowed. Programs that create SDML documents should not allow them to be inserted into a document, and programs that receive SDML documents should reject documents that contain them.
• If a character is required that is not displayable as one of the above ASCII printable characters, it should be encoded in the document using an SGML entity name for the character, enclosed between an ampersand and a semicolon, e.g., &circumflex;.

  This rule applies in particular to the > and < characters, which can only be used as SGML tag delimiters. If they are to be used in normal text, they must be encoded as &gt; and &lt;

  Note that these SGML entities will not be translated during the processing and cryptographic hashing of an SDML electronic document. They are only used for the purpose of display or printing of characters not in the usual ASCII subset.

3.2 Line Formatting

• A line-end sequence usually consists of either a Carriage Return (ASCII 0x0D) or Line-Feed (ASCII 0x0A) or both, however this is operating system-specific.
• All lines in the document must be less than or equal to 76 characters in length. When it is necessary to create a line which will continue past 76 characters, a line-end sequence may be inserted into the line. (This is to protect the SDML document from e-mail systems which break up lines longer than 76 characters.)

  A line-end sequence must not be inserted, either during original document creation, or when attempting to modify a document to protect against e-mail systems, if any of the following would become true:

  • It would create a line consisting of a single period ('.'). (this is to protect SDML documents from e-mail systems which cease processing documents past a line consisting of a single period)
  • It would create a line consisting of the string 'From ', starting in the first position of a line. (this is to protect the line from certain e-mail systems which change such lines)
  • It is inserted after spaces, causing those spaces to be trailing spaces on a line.
  • It causes a line-end sequence to be inserted into a tag, either between the < and the tag name, or between the tag name and the >, or inside the tag name.
• In SDML document receiving programs, all line-end sequences will be removed before any processing is done on the SDML electronic document. In particular, they are not included in hash calculations, nor passed in field values to application programs. This line-end removal occurs for the SDML tags and values.

3.3 Space Handling

• Any spaces at the end of a line, i.e., trailing spaces, will be removed prior to processing the document. This means that spaces between the last non-space character on a line, and the line-end sequence for the line are not included in hash calculations and are not passed to applications as part of the field value. This is also done inside <adata> sub-blocks inside attached documents. (this is to protect SDML documents from e-mail systems that may truncate lines with trailing spaces, or may add trailing spaces to lines).
• Embedded spaces, i.e., spaces that are not immediately before a line-end are to be processed as is, i.e., they are not to be removed before processing, hashing, etc. The same is true for leading spaces on a line, i.e., spaces following a line-end sequence.
• Leading spaces, e.g., indentation, are allowed but not recommended, as leading spaces are not deleted from processing, and as line-ends are removed, the leading spaces on a line will be indistinguishable from the data ending the previous line, and thus may cause field length violations or field data misinterpretation. For example:

  <tag1>abcde
       <tag2>defghi

  would cause the value of tag1 to be `abcde '. This can be used, however, to place trailing spaces into a value, i.e., if the value if tag1 were desired to contain the trailing spaces.

• White space (either spaces or line-end sequences) may not be inserted into tags, either between the < and the tag name, or between the tag name and >, or inside the tag name. If a tag has a parameter, white space may not be inserted between the parameter name and the = or between the = and the parameter value, or inside the parameter name, or between the last character of the parameter value and the >. Multiple parameters must be separated by one or more spaces. Parameter values must be contained within quotes.

3.4 Tags

In order to allow SDML processing using limited resources, (for example, in a Smart Card using for signing) SDML requires that certain SGML features for tag handling not be allowed.

• End tags (e.g. </tag>) are not allowed except for </sdml-doc>, block-end tags (defined below), and specific sub-block end tags as defined below. All fields that do not have end-tags specified in the block and field definitions below must not have end-tags.
• SGML tag abbreviation is not supported.

4 SDML Document Definition

4.1 Electronic Document Definition

The definition begins with an SDML electronic document.

Every SDML electronic document consists of one or more enclosed documents. These documents are nested, with the nesting done by enclosing earlier forms of a document inside later additions to the document. Each enclosed document is built inside a <sdml-doc> tag structure. Inside a document are one or more blocks. Blocks may appear in any order, except that the <action> block (defined below) must the first block in the document.

  <sdml-doc docname="cccccccc" type="cccccccc">
        
     a sequence of one or more blocks and/or nested <sdml-doc> documents
     
  </sdml-doc>

The docname= attribute parameter is a document name, assigned by the software creating the document. This name will be used when combining documents. (See Combining Documents, below). If multiple SDML documents are being created at one time, as part of one file or transmission, the creating software should ensure that the document names are unique, within the file or transmission. This name should contain a maximum of 64 characters. Note: Attribute parameters must be enclosed in quotes.

The type= attribute parameter is a document type, used to specify the type of document. This type is used by the receiving software to ensure that it has received the correct type of document, i.e., one that it knows how to process. The document types are chosen from a list of pre-defined types, or may be types agreed upon by the sending and receiving parties, except that the latter agreed-upon types may not conflict with any pre-defined types. Note: Attribute parameters must be enclosed in quotes.

To prevent such conflict between pre-defined, standardized document types, and privately agreed-upon types, all privately agreed-upon document types should be prefixed with the characters "p-" (meaning private). For example, a document type used for auto loan applications, agreed to be used by a pair or small group of cooperating banks, could be written as type="p-autoloan". All pre-defined document types will be guaranteed not to start with the characters "p-".

4.2 Block Common Field Definitions

A block contains some common fields, along with other fields specific to the type of block. Except in a few cases and unless otherwise specified, the order of fields within a block is not predefined. Once created, however, fields may not be moved or rearranged inside a block, to permit the digital signatures and hashes to be valid.

Common Block Field Definitions

Each of the blocks contains some field definitions which are common to all block types, as follows:

    <blkname>ccccccc
    <crit>true|false
    <vers>nnn.nnn

4.3 Block Definitions

Each SDML block starts and ends with one of the following sets of block tags:

The block types are defined as follows:

4.3.1 Action Block Definition

This block contains information about the action to be performed by the recipient of the electronic document.

  <action>
    <blkname>cccccccc
    <crit>true
    <vers>1.0
    <function>cccccccc
    <reason>cccccccc
  </action>

4.3.1.1 Action Block Field Definitions

4.3.2 Signature Block Definition

This block contains a digital signature for another block, or set of blocks. It is required whenever a block must be authenticated, or tamper-proofed. It also contains the reference to the certificate block containing the public key used to verify the signature. It is also used to "bind" multiple blocks together, so that the resulting compound document can be verified.

Unless otherwise specified, the data being signed consists of the entire contents of the subject block, which is defined to be everything between the start and end tags for the block. The signature must include the blockname, criticality, and version fields, if present, as well as the contents of the block.

The actual hashes of the signed blocks are included to allow verification of the binding even if the actual contents of the bound blocks is not available.

  <signature>
    <blkname>cccccccc
    <crit>true
    <vers>1.0
    <sigdata>
      <blockref>cccccccc
      <hash alg="sha">hhhhhh
      <blockref>cccccccc
      <hash alg="sha">hhhhhh
        ...
      <blockref>cccccccc
      <hash alg="sha">hhhhhh
      <nonce>cccccccc
      <sigref>cccccccc
      <certissuer>cccccccc
      <certserial>nnnnnnnn
      <algorithm>sha/rsa
      <timestamp>cccccccc
      <location>cccccccc
      <username>cccccc
      <useraddr>cccccc
      <userphone>cccccc
      <useremail>cccccc
      <useridnum>cccccc
      <userotherid>cccccc
    </sigdata>
    <sig>hhhhhhhh
  </signature>

4.3.2.1 Signature Block Field Definitions

4.3.2.2 Signature Calculation

Calculation of the signature is performed as follows. If an electronic token is being used, then all of the following steps must be performed by that token.

4.3.3 Certificate Block Definition

This block contains an encoded certificate.

  <cert>
    <blkname>cccccccc-nnnnnnnn-nnnnnnnn
    <crit>true
    <vers>1.0
    <certtype>x509v1
    <certissuer>cccccccc
    <certserial>nnnnnnnn
    <certdata>hhhhhhhh
  </cert>

4.3.3.1 Certificate Block Field Definitions

     Country       C=
     Commonname    CN=
     Locality      L=
     Orgname       O=
     Orgunit       OU=
     State         ST=
     Streetaddress SA=
     Title         T=

/C=US/ST=New York/O=FIRSTBANK_ANYTOWN/OU=checking/

4.3.4 Attachment Block Definition

This block contains any document that is to be attached to the SDML electronic document (e.g., a remittance notice, contract, etc.).

  <attachment>
    <crit>false
    <vers>1.0
    <blkname>cccccccc
    <astatus>temporary
    <adata encoding="text">
    ...
    </adata>
  </attachment>

4.3.4.1 Attachment Block Field Definitions

The encoding= parameter for the <adata> tag is used to specify the encoding method for the data in the sub-block. It can have the following values:

Mime-Version 1.0
Content-Type: aaaaaa/bbbbbbbb
Content-Transfer-Encoding: xxxxx

<attachment>
<blkname>att0123
<adata encoding="mime">
Mime-Version 1.0
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAAQAAAAAA
AAAAEAAA/v///wAAAAD+////AAAAAAAAAAB7AAAA////////////////////////////////
</adata>
</attachment>

4.3.5 Message Block Definition

This block contains error messages and return information that indicates the reason that the attached SDML document was not processed successfully or it may contain other information about the attached document.

  <message>
    <blkname>cccccccc
    <crit>true
    <vers>1.0
    <retcode>cccccccc
    <msgtext>ccccccccccccc
    <msgdata>
    ...
    </msgdata>
  </message>

4.3.5.1 Message Block Field Definitions

5 Document Structure

5.1 BNF Structure of SDML electronic documents

The following is an Extended BNF description of the global block structure of an SDML electronic document.

5.1.1 BNF Meta-Notation

The meta-symbols of BNF are:

Names not enclosed in any of the above bracket symbols are called nonterminals and are used to define symbols internal to the BNF specification only.

Note: Blocks are not required to be in the exact order specified below, except that the <action> block must always appear as the first block in any <sdml-doc>.

5.1.2 BNF Definition of non-terminals

cert-chain ::=        all certificates in the hierarchy
                      leading up to, but not including
                      the Root certificate.

data-block ::=        <(attachment)> | <(message)> | user-defined-block

5.1.3 BNF Definition of A Signed SDML Document

signed_doc ::=
                      <sdml-doc>
                      <(action)> 
                    { data-block }
                      <(signature)> <(cert)>
                      cert-chain
                      </sdml-doc>

A signed SDML document consists of...

• An <sdml-doc> element
• An <action> block
• One or more data blocks (<attachment> or <message> or other blocks defined by the user of SDML)
• A <signature> block, which signs (contains the hash of) the <attachment> blocks
• The <cert> block containing the public key of the signer
• The <cert> blocks of the certificate hierarchy
• An </sdml-doc> element

5.1.4 BNF Definition of a Multiply-Signed SDML Document

multiply_signed_doc ::=
                      <sdml-doc>
                      <(action)> 
                    { data-block }
                      signed_doc | multiply_signed_doc
                      <(signature)> <(cert)>
                      cert-chain
                      </sdml-doc>

Thus, a multiply signed SDML document (i.e. a document which contains a
nested, inner document) consists of...

• An <sdml-doc> element
• An <action> block
• One or more data blocks (<attachment> or <message> or other blocks defined by the user of SDML)
• The entire inner document
• A <signature> block, which signs (contains the hash of) the <attachment> blocks, along with the hashes of the attachments and signature in the next inner document.
• The <cert> block containing the public key of the signer
• The <cert> blocks of the certificate hierarchy
• An </sdml-doc> element

This nesting of documents may be continued indefinitely as new information
is added and signed.

5.1.5 Document Structure Diagram

6 Combining Documents

As an SDML electronic document passes through the various steps and institutions that are part of the entire system that processes the document, new information may be added to the document. To allow the new information to be added, while still allowing the original information to be protected and verified using digital signatures, a document combining mechanism is defined.

To add new information to a document, the existing document is enclosed in a <sdml-doc> tag structure, which may also enclose new blocks containing the new information. New <signature> blocks may also be contained in the new information and may sign blocks in the inner nested documents. Each new, surrounding <sdml-doc> must also have a new <action> block, and TYPE parameter, and the <action> block and TYPE belonging to the outermost <sdml-doc> are used by the receiving system to determine the method used to process the modified document.

When combining original SDML documents into a larger, compound document, the names of the original blocks may not be unique. A document combining process must be used to handle naming conflicts when a number of documents are being combined (i.e., embedded) into a new document.

The document combining process is as follows:

As an example:

If there are two original documents:

    <sdml-doc docname="doc1">
      <attachment>
         <blkname>block1
         ....
      </attachment>
    </sdml-doc>
    
    <sdml-doc docname="doc2">
      <attachment>
         <blkname>block1
         ....
      </attachment>
    </sdml-doc>

When they are combined, the result is:

  <sdml-doc docname="newdoc">
  
    <sdml-doc docname="doc1">
      <attachment>
         <blkname>block1
         ...
      </attachment>
    </sdml-doc>
    
    <sdml-doc docname="doc2">
      <attachment>
         <blkname>block1
         ...
      </attachment>
    </sdml-doc>
    
    <signature>
    <blockref>doc1.block1
    ...
    <blockref>doc2.block1
    ...
    </signature>

  </sdml-doc>

Any external references to the <attachment> block in the first document would be 'doc1.block1', and the <attachment> block in the second document would be 'doc2.block1'. References inside doc1 to any blocks in doc1 must still use the original, single-level names. Similarly for internal references inside doc2.

This is extended if the nesting is continued to more than two levels, e.g. 'outerdoc.innerdoc.block'.

7 ASN.1 Definition of X.509 Version 1 Certificates

The ASN.1 definition of an X.509 Version 1 certificate is as follows:

Certificate     ::= SIGNED SEQUENCE{
             version                [0] Version DEFAULT 1988,
             serialNumber           SerialNumber,
             signature              AlgorithmIdentifier,
             issuer                 Name,
             validity               Validity,
             subject                Name,
             subjectPublicKeyInfo   SubjectPublicKeyInfo}

Version         ::= INTEGER < 1988(0)}

SerialNumber    ::= INTEGER

Validity        ::= SEQUENCE{
              notBefore              UTCTime
              notAfter               UTCTime}

SubjectPublicKeyInfo   ::= SEQUENCE{
              algorithm         AlgorithmIdentifier
              subjectPublicKey  BIT STRING}


AlgorithmIdentifier    ::= SEQUENCE{
              algorithm       OBJECT IDENTIFIER
              parameters      ANY DEFINED BY algorithm OPTIONAL}

The descriptions of the fields are as follows:

8 Field Summary

Below is a summary of the attributes of each of the entities or fields allowed in an SDML electronic document.

8.1 Field Attributes Table

9 Verifying Certificates

The rules for verifying certificates are:

The cryptographic verification process for X.509 certificates in an SDML document is as follows. For each sub-document in the SDML document, perform the following steps:

10 Bibliography

[2] R. Rivest. RFC 1321 The MD5 Message-Digest Algorithm. IETF, April 1992.

[3] R.L. Rivest, A. Shamir, and L.M. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM , 21(2):120-126, February 1978.

[4] U.S. Department of Commerce / National Institute of Standards and Technology . FIPS Pub 180 - Secure Hash Standard, May 1993.

[5] U.S. Department of Commerce / National Institute of Standards and Technology . FIPS Pub 186 - Digital Signature Standard, May 1993.

[6] CCITT, International Telegraphic Union, General Secretariat, Place Des Nations, CH-1211, Geneva 20, Switzerland. CCITT X.509 The Directory - Authentication Framework , January 1995.

[7] Nicklaus Wirth. What can we do about the unnecessary diversity of notation for syntactic definitions. Communications of the ACM , 22(11):822-823, November 1977.

[8] John Backus and Peter Naur. The syntax and semantics of the proposed international algebraic language of the Zurich ACM-GAMM conference. Proceedings of the International Conference on Information Processing , June 1959.

[9] N. Borenstein and N. Freed. RFC 1521 MIME (Multipurpose Internet Mail Extensions) - Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. IETF, September 1993.

[10] ISO, International Organization for Standardization, Cast Postale 56, CH-1211, Geneva 20, Switzerland. ISO 8601 Data elements and interchange formats - Information interchange - Representation of dates and times, 1988.

[11] ISO, International Organization for Standardization, Cast Postale 56, CH-1211, Geneva 20, Switzerland. ISO 8824 Information Processing Systems - Abstract Syntax Notation One (ASN 1), 1995.

[12] ISO, International Organization for Standardization, Cast Postale 56, CH-1211, Geneva 20, Switzerland. ISO 8825 Information Processing Systems - Abstract Syntax Notation One - Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER), 1995.

11 Issues and Directions

Certain issues are still being discussed and need further investigation. These include:

• Convergence with the new XML standard. XML, a new SDML-based standard from the W3C is a subset of SGML, as is SDML, but was developed in order to allow for more flexible documents on the World Wide Web. XML is essentially a subset of SGML. A number of issues related to the differences between XML and SGML, as well as some problems caused by the differences in goals for the two languages, will need to be resolved if SDML were to migrate to become XML-compatible.
• Use of X.509 V3 certificates, or other forms of certificates. SDML is currently "certificate-neutral" in that although it currently uses X.509 V1 certificates, by use of the <certtype> tag, other certificate types can be supported. Use of X.509 V3 certificates have a number of implications that need to be studied, and there are also reasons to investigate the use of SGML-based, "human-readable" certificates.
• SDML currently has a set of "Document Formatting Rules" which are mainly designed to allow SDML documents to pass through existing e-mail systems. As MIME becomes more widely used, these rules may become obsolete, and may be considered as optional.

Appendix A - SGML Document Type Definition (DTD)

<!SGML  "ISO 8879:1986"
--                                      --
--  DTD for SDML electronic documents   --
--  First Draft  27 Feb 1996            --
--  Written by J. Kravitz IBM Research  --
--  Last Revision 21 Jan 1998           --
--  Version  1.00                       --
--                                      --

CHARSET
     BASESET  "ISO 646:1983//CHARSET
               International Reference Version (IRV)//ESC 2/5 4/0"
     DESCSET  0   9   UNUSED
              9   2   9
              11  2   UNUSED
              13  1   13
              14  18  UNUSED
              32  95  32
              127 1   UNUSED
     BASESET  "ISO Registration Number 100//CHARSET
               ECMA-94 Right Part of Latin Alphabet Nr. 1//ESC 2/13 4/1"
     DESCSET  128 32  UNUSED
              160 95  32
              255  1  UNUSED

CAPACITY        SGMLREF
                TOTALCAP        150000
                GRPCAP          150000
  
SCOPE    DOCUMENT
SYNTAX   
         SHUNCHAR CONTROLS 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
                           19 20 21 22 23 24 25 26 27 28 29 30 31 127 255
         BASESET  "ISO 646:1983//CHARSET
                   International Reference Version (IRV)//ESC 2/5 4/0"
         DESCSET  0 128 0
         FUNCTION RE          13
                  RS          10
                  SPACE       32
                  TAB SEPCHAR  9
         NAMING   LCNMSTRT ""
                  UCNMSTRT ""
                  LCNMCHAR "-"
                  UCNMCHAR "-"
                  NAMECASE GENERAL YES
                           ENTITY  NO
         DELIM    GENERAL  SGMLREF
                  SHORTREF SGMLREF
         NAMES    SGMLREF
         QUANTITY SGMLREF
                  NAMELEN  34
                  TAGLVL   100
                  LITLEN   1024
                  GRPGTCNT 150
                  GRPCNT   64                   

FEATURES
  MINIMIZE
    DATATAG  NO
    OMITTAG  YES
    RANK     NO
    SHORTTAG NO
  LINK
    SIMPLE   NO
    IMPLICIT NO
    EXPLICIT NO
  OTHER
    CONCUR   NO
    SUBDOC   NO
    FORMAL   YES
  APPINFO    NONE
>

<!DOCTYPE sdml [

<!ELEMENT sdml o o ( sdml-doc )>
                            
<!ELEMENT sdml-doc - -      (
                             (
                             action        ,
                             (
                              sdml-doc     |
                              signature    |
                              cert         |
                              attachment   |
                              message
                              )+
                             )
                            )>
                            
<!ATTLIST sdml-doc docname CDATA #REQUIRED
                   type    CDATA #REQUIRED >
          
<!ELEMENT action    - -     (
                             (
                             blkname     ,
                             crit?       ,
                             vers?
                             ),(
                             function    &
                             reason
                             )
                             )>
                  
<!ELEMENT signature - -     (
                             (
                             blkname     ,
                             crit?       ,
                             vers?
                             ),(
                             sigdata     ,
                             sig
                              )
                             )>
                             
<!ELEMENT sigdata   - -     (
                             ( blockref , hash )+ &
                             nonce       &
                             sigref?     &
                             (certissuer , certserial)?  &
                             algorithm   &
                             timestamp?  &
                             location?   &
                             username?   &
                             useraddr?   &
                             userphone?  &
                             useremail?  &
                             useridnum?  &
                             userotherid?
                            )>

<!ELEMENT cert      - -     (
                             (
                             blkname     ,
                             crit?       ,
                             vers?
                             ),(
                             certtype    &
                             (certissuer , certserial)  &
                             certdata
                             )
                            )>
   
<!ELEMENT attachment - -    (
                             (
                             blkname     ,
                             crit?       ,
                             vers?
                             ),(
                             astatus?    ,
                             adata
                            )>
                            
<!ELEMENT message    - -    (
                             (
                             blkname     ,
                             crit?       ,
                             vers?
                             ),(
                             retcode     &
                             msgtext     &
                             msgdata?
                             )
                            )>

<!ELEMENT blkname       - O (#PCDATA)>
<!ELEMENT crit          - O (#PCDATA)>
<!ELEMENT vers          - O (#PCDATA)>

<!ELEMENT adata         - - (#CDATA)>
<!ATTLIST adata encoding (mime | text)  text >
<!ELEMENT algorithm     - O (#PCDATA)>
<!ELEMENT astatus       - O (#PCDATA)>
<!ELEMENT blockref      - O (#PCDATA)>
<!ELEMENT certdata      - O (#PCDATA)>
<!ELEMENT certissuer    - O (#PCDATA)>
<!ELEMENT certserial    - O (#PCDATA)>
<!ELEMENT certtype      - O (#PCDATA)>
<!ELEMENT function      - O (#PCDATA)>
<!ELEMENT hash          - O (#PCDATA)>
<!ATTLIST hash alg (md5 | sha) #REQUIRED >
<!ELEMENT location      - O (#PCDATA)>
<!ELEMENT msgtext       - O (#PCDATA)>
<!ELEMENT msgdata       - - (#PCDATA)>
<!ELEMENT nonce         - O (#PCDATA)>
<!ELEMENT reason        - O (#PCDATA)>
<!ELEMENT retcode       - O (#PCDATA)>
<!ELEMENT sig           - O (#PCDATA)>
<!ELEMENT sigref        - O (#PCDATA)>
<!ELEMENT timestamp     - O (#PCDATA)>
<!ELEMENT useraddr      - O (#PCDATA)>
<!ELEMENT useremail     - O (#PCDATA)>
<!ELEMENT useridnum     - O (#PCDATA)>
<!ELEMENT username      - O (#PCDATA)>
<!ELEMENT userotherid   - O (#PCDATA)>
<!ELEMENT userphone     - O (#PCDATA)>

]>

Appendix B - Definitions

Appendix C - Acknowledgements

The creation and continued enhancement of this document was greatly assisted by many people, including the following contributors from the FSTC E-Check Technical Team: