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

Received on Wednesday, 24 November 1999 12:56:08 UTC