XML-Signature scenario proposal

Hi,

We would like to ask if the following fits into the scenarios document.

Mutual agreement scenario:

There is an agreement to be signed between merchant  
M and customer C. They do it in three steps: 
  1. M signs the contract and sends the resulting Offer document to C
  2. C signs Offer and sends it back to M as the Accept message 
  3. M adds a third signature to Accept and sends the resulting 
  Confirmation message to C. 

The purpose of the three steps is non-repudiation: Both parties are
sure  
that the other cannot repudiate her knowledge of the existence of the 
doubly signed contract, i.e., the agreement. (These three steps are core
parts of a protocol called BAKO that hass been developed at GMD some 
time ago). The (partial) XML documents generated could coarsly look  as 
follows:

1. Offer 

<dsig:Document xmlns:BAKO="http://www.gmd.de/BAKO"> 
<BAKO:Offer>

  <BAKO:OfferLocator href="www.merchant.com/Offers/77393529247521"/>

  <BAKO:Contract Number="77393529247521"> 
    The content of the offered contract enters here. 
  </BAKO:Contract>

  <dsig:Signature>
    <dsig:Manifest> 
      <dsig:Algorithm> ... </dsig:Algorithm>

      <dsig:Resource> 
        <dsig:Locator href="#77393529247521"/> 
        <dsig:Digest> ... </dsig:Digest> 
      </dsig:Resource>

      <dsig:SignatureAlgorithm ... /> 
    </dsig:Manifest> 
    <dsig:Value> ... </dsig:Value> 
  <dsig:Signature>

</BAKO:Offer> 
</dsig:Document>

Comment: Here, M uses a local link to refer to the contract to be signed 
and provides C with an (unique) reference to the location where the 
_whole_ Offer is stored by M. Thus, C can detach the signature in the 
next step and need not provide a storage place and reference to Offer 
(in real-world scenarios he might even not be able to do this), This 
also saves bandwidth if Contract is large.

2. Accept: C endorses the whole Offer document to which he points with 
an external XLink.

<dsig:Document xmlns:BAKO="http://www.gmd.de/BAKO"> 
<BAKO:Accept>

  <dsig:Signature> 
    <dsig:Manifest> 
      <dsig:Algorithm> ...  </dsig:Algorithm>

      <dsig:Resource> 
        <dsig:Locator 
          href="www.merchant.com/Offers/77393529247521"/> 
        <dsig:Digest> ... </dsig:Digest> 
      </dsig:Resource>

      <dsig:SignatureAlgorithm ... /> 
    </dsig:Manifest> 
    <dsig:Value> ... </dsig:Value> 
  </dsig:Signature>

</BAKO:Accept> 
</dsig:Document>

3. Confirmation: M can now add his last signature by direct envelopment.

<dsig:Document xmlns:BAKO="http://www.gmd.de/BAKO"> 
<BAKO:Confirm>

  <dsig:Signature> 
    <dsig:Manifest> 
      ... 
      <BAKO:Accept> ... </BAKO:Accept>
      ...
    </dsig:Manifest> 
    <dsig:Value> ... </dsig:Value> 
  </dsig:Signature>

</BAKO:Confirm>
</dsig:Document>

The funny thing about this scenario is that one can show three different 
modes  of signing in one example.

Questions: 

- There is an obvious semantic flaw in the design of Offer: M signs the 
Contract  but not its context consisting of: a) that it is meant as an 
offer b) the BAKO DTD. As I know, the WG has considered problems of that
kind and possible remedies. E.g., with XPointers M could say: I am 
signing the whole <dsig:Document> except my own signature. How would 
that look like ?

- It seems to me, that 'sign all from root node except own signature' 
comes up often in reality. Could one make this kind of default or 
provide syntactic shortcuts ?

- The notorious c14n issue, but reviewed under security and 
non-repudiation aspects. What should be c10ed and to what level ?

- We are considering to explain this scenario in a short paper at 
appropriate location. Do You support this idea ?

Best regards, Andreas Schmidt
------------------------------------------------------------------------
snail:Dr. Andreas U. Schmidt, Dept. SIT |email:aschmidt@darmstadt.gmd.de
      GMD German National Research      |phone:+49-6151-869-712       
      Center for Information Technology |fax  :+49-6151-869-704
------------------------------------------------------------------------

Received on Friday, 17 September 1999 07:40:50 UTC