XML-Signature Scenarios

1. Introduction

The XML 1.0 Recommendation [XML] describes the syntax of a class of data objects called XML documents. The mission of the XML DSig working group is to develop a XML syntax used for representing signatures on digital content and procedures for computing and verifying such signatures. Signatures will provide data integrity, authentication, and/or non-repudiatability.

The purpose of this document is to help inform the specification of XML signatures by providing specific examples of signature problems that should be considered and, whenever possible, solved by the XML Signature specification.

Each example consists of a textual description of the problem and XML markup demonstrating how to express the signature. Example markup presently use the syntax described in the Brown (990618) draft, but will changed to test/apply the syntax developed by the WG. Regardless, examples may leave out portions of the signature element (for example, Certificates, OriginatorInfo) if they have no bearing on the example.

2. Scenarios

1. Enveloped Embedded Content

The problem is to digitally sign an arbitrary piece of information.

The piece of information is not associated with any XML document type in particular, so the default dsig:Document element is used as the root element.

It is assumed that the application has obtained the piece of information and placed it into the package element prior to performing signature generation. It is also assumed that the digital fingerprint (hash) of the package element will be computed using the algorithm given in the Digest Algorithm element of the Manifest Resource that identifies the package. It is assumed that the application will place the computed hash into the Digest Value using the given encoding method prior to the generation of the digital signature.

QUESTIONS:

• Since the application layer must compute the hash, will this specification place any requirements on applications such as "the application must generate the hash of the canonical form of the package element?
• It appears to me that the connection between the signer and the content of the manifest is made by comparing the attributes of the IssuerAndSerialNumber in the OriginatorInfo to those in certificates. Is this correct? If so, you have two certificates that match, which one should be used to verify?
• The content of the resource digest value seems a bit long. Is it a real base64 encoded hash? Also, could Richard please modify this to use Sha-1?
• What is the %2f doing in the content info type? Why can't it just be urn:mime:application/msword? Also, perhaps we could pick something plain like image/jpeg.
• What is the purpose of DigestAlgorithms and the dsig:eval attribute in this example?
• Why does Certificate have a Locator? It has been stated many times to me that it should not be core behavior to chase links. Since verification is a core behavior, and the certificate is needed to verify, the value of the certificate should be placed in the certificate element.

<?xml version='1.0'?> <!DOCTYPE dsig:Document PUBLIC 'urn:ietf-org:xmldsig.dtd' SYSTEM 'http://www.dtd.reg.int/dtd/xmldsig.dtd'> <dsig:Document> <dsig:DigestAlgorithms> <dsig:Algorithm id='xhash' type='urn:com-globeset:xhash'/> </dsig:DigestAlgorithms> <dsig:Package id='data' dsig:eval='xhash'> <dsig:ContentInfo type='urn:mime:application%2fmsword'/> <dsig:Value>abncjflf311257gghn6mj2k134h64AANHdd12==</dsig:Value> </dsig:Package> <dsig:Signatures> <dsig:Signature> <dsig:Manifest> <dsig:Resources> <dsig:Resource> <dsig:Locator href='data'/> <dsig:Digest> <dsig:Algorithm type='urn:com-globeset:xhash'/> <dsig:Value encoding='base64'>bndWGryrt245u6t1dgURTIrr4ir5=</dsig:Value> </dsig:Digest> </dsig:Resource> </dsig:Resources> <dsig:Attributes> <dsig:Attribute type='urn:ietf-org:xmldsig-signing-time'> <dsig:Date value='1998-10-29T13:26-0500'/> </dsig:Attribute> </dsig:Attributes> <dsig:OriginatorInfo> <dsig:IssuerAndSerialNumber issuer='o=GlobeSet Inc., c=US' number='123456789102356'/> </dsig:OriginatorInfo> <dsig:SignatureAlgorithm> <dsig:Algorithm type='urn:rsasdi-com:rsa-encryption'> <dsig:Parameter type='digest-algorithm'> <dsig:Algorithm type='urn:globeset-com:xhash'/> </dsig:Parameter> </dsig:Algorithm> </dsig:SignatureAlgorithm> </dsig:Manifest> <dsig:Value>xsqsfasDys2h44u4ehJDe54he5j4dJYTJ=</dsig:Value> </dsig:Signature> </dsig:Signatures> <dsig:Certificates> <dsig:Certificate type='urn:X500:X509v3'> <dsig:IssuerAndSerialNumber issuer='o=GlobeSet Inc., c=US' number='123456789102356'/> <dsig:Locator href='http://certs.globeset.com/smith.der'/> </dsig:Certificate> <dsig:Certificate type='urn:X500:X509v3'> <dsig:IssuerAndSerialNumber issuer='o=GlobeSet Inc., c=US' number='123456789102356'/> <dsig:Value>xsqsfasDys2h44u4ehJDe54he5j4dJYTJ=</dsig:Value> </dsig:Certificate> </dsig:Certificates> </dsig:Document>

2. Two Lightweight Protocol Scenarios for XML-DSIG

Brian A. LaMacchia, Microsoft Corp. bal@microsoft.com

 Introduction

 This document describes some XML-DSIG scenarios involving lightweight protocols.  By “lightweight” we mean at least one of the following conditions is true:

1. The size of the content in protocol messages is sufficiently small that additional content related to digital signatures is a significant fraction of the overall message size.  In the extreme case, one can envision protocols in which the message content is a small fraction of the size of any attached signature content.
2. The message content can be parsed with limited XML processing capabilities.  That is, while the messages that make up the protocol are valid XML messages, they use a restricted subset that does not require a full-blown XML parser to interpret.  Typically such protocols involve at least one party operating on a severely restricted platform.

Example 1: An XML-based IMPP protocol

 The Internet Messaging and Presence Protocol (IMPP) WG within the IETF is working to create a standard for what are commonly called “instant messages” and “buddy lists.”  “Buddy lists” are services that provide presence information and change notifications  (e.g. “Is my friend Bob on-line right now?”)  Once you know that Bob is on-line, you can send him a real-time “instant message,” e.g., “Hey Bob, want to get some food?”  (See http://www.ietf.org/html.charters/impp-charter.html for details.  Current products in this space include AOL Instant Messaging, ICQ, MSN Messenger and Yahoo! Messenger.)  Assume that the IMPP protocol uses XML for message format, and assume further that we want to digitally sign IMPP messages using XML-DSIG for authentication and integrity protection.

IMPP messages have the property that their human-readable content is typically quite short, so signature-block size has a distinct impact on the overall bandwidth used by an IM system.  Furthermore, IM messages, being “instant,” tend not to be persisted in stable storage, so an IM messages will not a priori have a meaningful URL.  What we need, therefore, is a way to wrap an XML-DSIG signature around a small XML-IMPP node.  For example, here’s a sample IMPP message from one user (“impp://microsoft.com/bal”) asking to be notified whenever the status of another user (“impp://citibank.com/dsolo”) changes

<?namespace name="impp:" as="impp">

<impp:impp>

  <impp:subscribe>

    <impp:subject>”impp://citibank.com/dsolo”</impp:subject>

    <impp:property>status</impp:property>

    <impp:event-type>change</impp:event-type>

    <impp:subscriber-id>impp://microsoft.com/bal</impp:subscriber-id>

  </impp:subscribe>

</impp:impp>  

If we wanted to sign this message, ideally we’d be able to just wrap the IMPP message within a sigblock directly, instead of incorporating it into a sigblock by reference.  That is, I’d like to be able to say something as simple as this:

<sigblock> 

  <impp:impp>

    <impp:subscribe>

      <impp:subject>”impp://citibank.com/dsolo”</impp:subject>

      <impp:property>status</impp:property>

      <impp:event-type>change</impp:event-type>

      <impp:subscriber-id>impp://microsoft.com/bal</impp:subscriber-id>

    </impp:subscribe>

  </impp:impp>  

  <signature id="">

    <keyInfo sigAlg="RSA/SHA1" keyinfotype="???">KeyInfoValue</keyInfo>

    <sigValue value=”some-base64-encoded-string”/>

  </signature>

</sigblock>

The subject of the signature (the thing being signed) is the XML node immediately preceding the open tag of the <signature> element.  (Notice that were we to do this using a manifest, the manifest itself would be about as large as the IMPP message!)   The IMPP message is completely self-describing, and the receiving server could choose to accept/reject the subscription request based on the public key used to sign the request.

Obviously you could do the same sort of thing with the instant messages themselves:

<sigblock> 

  <impp:impp>

    <impp:message>

      <impp:subject>”impp://citibank.com/dsolo”</impp:subject>

      <impp:subscriber-id>impp://microsoft.com/bal</impp:subscriber-id>

      <impp:message-content>

        Hey Dave, want to get some <b>food</b>?

      </impp:message-content>

    </impp:subscribe>

  </impp:impp>  

  <signature id="">

    <keyInfo sigAlg="RSA/SHA1" keyinfotype="???">KeyInfoValue</keyInfo>

    <sigValue value=”some-base64-encoded-string”/>

  </signature>

</sigblock>

Example 2: WebDAV

(like IMPP, but typically more complex messages.  Need to pull some examples from RFC2518).

Example 3: SOAP

(again, like IMPP.  Method/Procedure calls w/ arguments.)

Deduced Requirements

...

3. Three

4. Four

5. Five

3. References

Brown-XML-DSig

Internet Draft. Digital Signatures for XML
http://www.w3.org/Signature/Drafts/xmldsig-signature-990618.html