Re: Detached Signatures Vs Detached Objects

So, if I understand, you're proposing a mechanism whereby two URIs are
signed, one that points to the "current" document and another that points to
the "current" signature of that document.

I suggest that this is badly insecure.  Nothing prevents both URIs from being
spoofed and having the "current" document and signature be replaced.  The
signature on the document that combines the two URIs would still be valid, so
this kind of substitution would be hard to detect.

I think a better solution would be to sign, along with the document's URI, a
KeyInfo that represents the key to be used to sign the document.  As someone
else said earlier, this sort of thing is a bit outside the scope of XML
signatures.

		Marc


> "Prince, Adam" wrote:
> 
> 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

Received on Friday, 26 November 1999 12:56:39 UTC