XML Digital Signatures

Phillip Hallam-Baker, Principal Consultant, VeriSign Inc.
02/22/99

Motivation

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.

Issues

The following issues are considered:

Constraints

The following constraints should be borne in mind:

Cryptographic Message Syntax (PKCS #7)

The industry standard cryptographic message encapsulation is PKCS #7[3], currently in the IETF standards process as the Cryptographic Message Syntax[2].

CMS Detached Signatures

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

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.

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)
Attribute Type Value
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.

Example

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>┐

Use with other content formats

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.

Signing Content Ranges

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.

Canonical Forms

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.

Legal Markup

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[4].

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.

References

[1] 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

[2] Cryptographic Message Syntax IETF Working Group Draft, December 1998, Russ Housley http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-10.txt

[3] PKCS#7 Kaliski, B. PKCS #7: Cryptographic Message Syntax, Version 1.5. March 1998. http://www.rsa.com/

[4] International Chamber of Commerce, ETERMS Repository Guidebook, 1996 http://www.iccwbo.org/