RE: Detached Signatures Vs Detached Objects

The issue I foresee and am trying to identify how it should be solved is: if
I know that future generations of a document will be created and wish to
sign a reference to the future (as yet uncreated) generations how can I have
application independent support for this?.  

The clearest example of this I can think of is a digitally signed employment
contract that states the employee must comply with the current employee
handbook that is always maintained at
..../intranet/HR/current-employee-handbook.htm.  Since this is a legal
contract some form of non-repudiation may be required.

Since I cannot predict the content/DigestValue/Signature of
current-employee-handbook.htm all I can place into my electronic contract is
the uri to the location and the certificate details that will later be used.
I could do this using application specific logic (contract contains uri and
certificate and these are used by the application) in the same way that a
XML-sig document could always an embedded object that may contain the uri to
a detached object (and hence support for any detachment could be application
specific).  

My point is that, if there is an argument for supporting separating the
object and signature, this should support all the likely forms (my 3 cases).
To avoid the quagmire of application dependencies IMHO all 3 cases should be
addressed within the XML-sig standard.

Regards

Adam

-----Original Message-----
From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com]
Sent: 24 November 1999 18:56
To: Prince, Adam
Cc: w3c-ietf-xmldsig@w3.org
Subject: Re: Detached Signatures Vs Detached Objects 



I'm not sure I understand your question.

If you have a store with generations of an Object, each paired with a
<Signature>, I would think that each Signature would point to the
corresponding Object and you could accomplish your goal by just
pointing to the most recent version of the Signature.  It does
not matter if the Object is incorporated in the Signature or the
Signature has an Object Reference to it.

However, if you really want to point to them separately, it seems
pretty easy to define a

<SignatureReference ( URI= | IDREF= ) >
	(ObjectReference)?
</SignatureReference>

or the like where presumably ObjectReference, if present, overrides
the first ObjectReference inside the Signature pointed to by the
URI or IDREF.  Is it that you think we should define something like
that in the draft?

Thanks,
Donald

From:  "Prince, Adam" <adam.prince@scala.se>
Message-ID:  <01AE61A08304D211AD3900A0C995C2050363F2DA@serndexch.scala.se>
To:  dee3@torque.pothole.com, reagle@w3.org, dsolo@alum.mit.edu
Cc:  w3c-ietf-xmldsig@w3.org
Date:  Wed, 24 Nov 1999 18:31:24 +0100

>The current XML-sig working draft (
>http://www.w3.org/TR/1999/WD-xmldsig-core-19991119
><http://www.w3.org/TR/1999/WD-xmldsig-core-19991119> ) covers both the case
>when the signature and the source are within the same document (embedded
>signatures) and when the signature is sent with a reference to a separately
>located source (so called "detached signature").  There is a third case,
not
>yet covered when the XML signed message refers to two separate locations,
>one is where the source is located (ObjectReference) and a second that
>points to where the signature are located (I propose this is called
>SignatureReference).
> 
>This would be of use if I prepared a XML message that cross-referred to a
>trusted document storage system where the most recent version of the
>cross-referred document had a static (and importantly guaranteed) location.
>For example, a library of reference documents, polices & procedures may
>exist /library/trusted-references/standards.htm.  Over time new versions of
>the referenced document would be created, hence digest values and
signatures
>will change.  I might wish to create a cross-reference to the location of
>the most recent version of the document.  Under the current proposals I can
>refer to a "detached signature" which contains both the document and digest
>value(s) (to me this is actually a detached source), but not to the
>signature itself.
> 
>To paraphrase I foresee cases where I wish to provide signed reference to
>the most recent version of a document, not just the current version of a
>document.  I cannot see any mechanism to do this within the current working
>draft.
> 
><Question> Does anyone else foresee any use in providing the ability to
>provide within an XML-signed document the reference to both a remote source
>and a remote signature?  </Question>  Please respond to the working draft
>authors or the discussion group, not just to me :-)
> 
>There is, I acknowledge one problem with the above scenario in that when I
>refer to a remote signature I am creating a "web of trust", if the
>maintainer of the signature later becomes untrustworthy this cannot be
>determined.  This is where the only solutions I can think of become messy,
>in addition to other information, the remotely stored signature (what I
call
>the detached signature) needs to be signed in a way that can be verified
>from information provided in the initial XML-sig message.
> 
>Regards
> 
>Adam
> 
>
>----------------------------------------------------------
>
>The options expressed in this communication are those of the sender.  They
>may or may not reflect the opinions of Scala Business Solutions N.V.
>
>Contact Details: 
>*(Office)       +46 8 601 1300 
>* (mobile)        +46 709 608 666 
>*(fax)            +46 8 718 4751 
>"(web)            <http://www.scala.se/> http://www.scala.se 
>* (e-mail)      <mailto:adam.prince@scala.se> adam.prince@scala.se 
>* (snail-mail)  PO Box 104, SE-131 07 Nacka, Sweden