Phillip Hallam-Baker, Principal Consultant, VeriSign Inc.
Digital Signatures offer a means of achieving non-repudiation, a useful property which allows:
Contract non-repudiation is a legal as well as a technical construct. The question at issue in that case is whether a contract may be enforced in a court of law. It is important to bear in mind that contract formation is only one of the purposes for which digital signatures may be employed, unfortunately a significant portion of state legislation fails to make this distinction.
The following issues are considered:
The following constraints should be borne in mind:
The industry standard cryptographic message encapsulation is PKCS #7, currently in the IETF standards process as the Cryptographic Message Syntax.
PKCS#7 was originally designed as a cryptographic envelope format. Subsequently developers requested a means of using PKCS#7 to define a signature which could be detached from the message - as is used in an S/MIME email for example. Embedding the signature inside the message itself is another reason to want a detached signature.
CMS attributes provide a convenient means of expressing signature semantics. Moreover they are the industry standard means of stating signature semantics.
The embedded signatures problem
It is highly desirable to be able to embed a signature in a message. Embedded signatures require no support from operating systems or proxy gateways to avoid inadvertent removal.
The fundamental problem embedded signatures raise is that the purpose of the signature is to authenticate the message and embedding the signature modifies the message.
This is a hard problem, probably best avoided absent a clear demand.
The signature validation incorporation process must therefore provide sufficient information to determine both the signature value and its exact scope. If a program adds additional linefeed or carriage return characters in addition to the signature tags these must also be identified.
Straw-man Tag Proposal
|Tag <DIGSIG> (non-empty, but no content permitted)|
|SIG||BASE64||The CMS detached signature|
|LEADING||INTEGER||Number of leading octets prior to the first character of the start tag which are NOT included in the signature (default 0, maximum 7)|
|TRAILING||INTEGER||Number of leading octets following to the final character of the close tag which are NOT included in the signature (default 0, maximum 7)|
|ID||ID||Identifier for this signature block|
|ATFOOT||TRUE/FALSE||If TRUE, the real signature block is at the foot of the document.|
|EXCLUDE||ID||Identifier of signature block to exclude from signature scope|
Note that it is essential that the tag NOT be allowed to include content. Otherwise a signature could be used to attach additional data to the document which the signature checker would not check.
For clarity the carriage returns are shown in the original text:
<!doctype HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">┐ <HTML>┐ <HEAD>┐ <TITLE>Example Text┐ </TITLE>┐ </HEAD>┐ <BODY>┐ <H1>Example</H1>┐ </BODY>┐
The text is then signed and the signature embedded in the text as shown below. The underlined text is the scope of the digital signature.
<!doctype HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">┐ <HTML>┐ <HEAD>┐ <DIGSIG ID=SIG1 LEADING=1 SIG=Ae987234hd2983fdu987 > </DIGSIG>┐ <TITLE>Example Text┐ </TITLE>┐ </HEAD>┐ <BODY>┐ <H1>Example</H1>┐ </BODY>┐
The message is then sent on to Alice and Bob who both counter sign the document, the scope of both signatures is the original document scope plus SIG1. Both signatures are forwarded (e.g. through some workflow infrastructure) to a gateway which assembles the compound document. Note that the need for multiple signatures which do not incorporate each other only occurs in such a gateway, hence the most convenient representation of this condition is using an exclude attribute, possibly a counter-intuitive notion.
<!doctype HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">┐ <HTML>┐ <HEAD> >┐ <DIGSIG ID=SIG1 LEADING=1 SIG=Ae987234hd2983fdu9872 > </DIGSIG>┐ <DIGSIG ID=SIG2a LEADING=1 SIG=fj039q329tujfv093j909 > </DIGSIG>┐ <DIGSIG ID=SIG2b LEADING=1 SIG=czw209ufjw09uj23r09uf > </DIGSIG>┐ <TITLE>Example Text┐ </TITLE>┐ </HEAD>┐ <BODY>┐ <H1>Example</H1>┐ </BODY>┐
The same principles may be extended to other content formats such as TIFF, JPEG (strictly, JPEG in FIF), PNG etc.CMS unauthenticated attributes may be used in cases where such formats do not provide for an unambiguous definition of the scope of the signature, or there is no opportunity to add attributes to express linkage semantics.
The tag set could be extended to define a signature scope. Satisfactory definition may be problematic however. Must the signed sub-section constitute a well-formed subtree of the XML document? If not the problem of structure clash occurs. Otherwise the tag may be allowed to incorporate content.
There should never be a requirement to encode a document in canonical form before signature.
While a canonical encoding may have utility for some users of XML, such an encoding is for others at best an inconvenience and more frequently a barrier to reliable operation.
It is not a sensible proposition for a group of non-lawyers to propose a set of legal semantics for signatures. Nor is it the case that such a formulation is in any case practicable. Even simple constructs such as 'This is not a contract' become problematic. Work on these issues is taking place in the International Chamber of Commerce E-Terms working group.
There is however considerable utility in a standard signature attribute which provides a link to the governing contract for the signature. Such an attribute tag would have the semantics of 'incorporate by reference, this document as the terms by which this message is to be interpreted.' The tag would require an ASN.1 OID and some syntax to allow one or more references to the governing terms. Each references would be a URI, either a URL of a particular document or a URN specifying a unique name for the document - such as a message digest.
 Extensible Markup Language (XML) W3C Recommendation 10-February-1998, Tim Bray, Jean Paoli and C. M. Sperberg-McQueen. http://www.w3.org/TR/1998/REC-xml-19980210
 Cryptographic Message Syntax IETF Working Group Draft, December 1998, Russ Housley http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-10.txt
 PKCS#7 Kaliski, B. PKCS #7: Cryptographic Message Syntax, Version 1.5. March 1998. http://www.rsa.com/
 International Chamber of Commerce, ETERMS Repository Guidebook, 1996 http://www.iccwbo.org/