<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
I hate to say this but XML DSig works very bad with compund documents.<br>
And I am not sure that XInclude will help you here because if you have a
standalone<br>
document<br>
ššš <Section><br>
ššš ššš ...<br>
ššš ššš <dsig: Signature><br>
ššš ššš ššš ...<br>
ššš ššš ššš <dsig:Reference URI="....."><br>
ššš ššš ššš ššš ....<br>
ššš ššš ššš </dsig:Reference><br>
ššš ššš </dsig:Signature><br>
ššš </Section><br>
and after this it is embeded into another larger document then the path to
<Section> changes<br>
(and reference URI is signed with the message itself!). I really don't think
that full xpointer<br>
support can help you here.<br>
However, I got another idea. There is a nice XPath extension in XML DSig:
function "here()".<br>
It is used to create enveloping signatures and I think it can help you. Please
check the XMLDSig<br>
spec for details on how it works and the enveloping transform description.<br>
<br>
Aleksey<br>
<br>
<br>
<br>
<br>
Moultrie, Ferrell (ISSAtlanta) wrote:<br>
<blockquote type="cite"
cite="mid121184A7DB1F9143BB5E3FACCB548757066329@atlmaiexcp02.iss.local">
<pre wrap="">Aleksey:
Thanks for the background. My biggest problem is that my document is a
collection of logically unrelated documents (think of a file folder full of
signed letters). They were all created/signed independently of each other at
different times/places. Because of this, the "section#" attribute is a
problem since I have no globally unique ID to reference when
creating/validating the signature. Since I presume that the Id="tag" is
itself actually computed into the signature hash, I can't assign the tag
when building the compound document. If I'm wrong on that and only the
children of Section# would be signed/verified then I could work around this
by assigning section numbers on a document-by-document basis when assembling
the master document. The only other solution I've thought of would be to
clone the subdocuments into a new/empty document and sign/verify them there.
That seems like a lot of extra work but then an empty URI would work.
Does the above description make sense? Any other ideas on how to solve
this problem without having to implement full URI/xpointer support?
Thanks!
Ferrell
-----Original Message-----
From: Aleksey Sanin [<a class="moz-txt-link-freetext" href="mailto:aleksey@aleksey.com">mailto:aleksey@aleksey.com</a>]
Sent: Tuesday, July 23, 2002 6:48 PM
To: Moultrie, Ferrell (ISSAtlanta)
Cc: '<a class="moz-txt-link-abbreviated" href="mailto:xmlsec@aleksey.com">xmlsec@aleksey.com</a>'; Dodd, Tim (ISS Atlanta)
Subject: Re: [xmlsec] XMLSEC Reference URI question
Hi, Ferrell!
The current XMLDSig does not require full XInclude support and limits the
possible reference URIs to the URIs you've listed plus full
qualified URLs.
The xmlsec does not support full XIncude simply because there were no demand
for this yet :) The problem with "id" is that the according to the XML specs
attribute with
*any* name could have ID flag in the DTD/schema and by this used as "id".
For example, you can have something like this in your DTD:
<!ATTLIST Section ThisIsAnID ID #IMPLIED>
and attribute "ThisIsAnID" MUST be treated as an "id" (for example, when
you
are using "#xpointer(id('tag'))" to reference the element).
As you can see, the "id" attribute means nothing w/o DTD or shema :) I
decided that
it's a bad idea to require application to provide DTD/schema in order to
validate document.
So I've implemented a "hack" when application can tell xmlsec library
which attributes
are "ids" in the particular document.
Regarding your question, I think that can do something like this:
<Document>
<Section1 id="section1">
... content ...
<dsig:Signature>
<dsig:SignedInfo>
...
<dsig:Reference URI="#xpointer(id('section1'))">
<dsig:Transforms>
<!-- exclude dsig:Siganture element from digest! -->
<dsig:Transform />
</dsig:Transforms>
...
</dsig:Reference>
</dsig:SignedInfo>
...
</dsig:Signature>
</Section1>
<Section2 id="section2">
... content ...
<dsig:Signature>
<dsig:SignedInfo>
...
<dsig:Reference URI="#xpointer(id('section2'))">
<dsig:Transforms>
<!-- exclude dsig:Siganture element from digest! -->
<dsig:Transform />
</dsig:Transforms>
...
</dsig:Reference>
</dsig:SignedInfo>
...
</dsig:Signature>
</Section2>
...
</Document>
Please note, that you need to put additional XPath transform to exclude
<dsig:Signature> element
itself from digesting (XPath transofrm is supported by xmlsec)!
With best regards,
Aleksey
Moultrie, Ferrell (ISSAtlanta) wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Aleksey:
Looking in xmlSecTransformStateParseUri() [transforms.c:1069] it
appears that your support of current-document URI references is limited
to: o URI="" (empty URI, whole document signed/verified) o
URI="#xpointer(/)" o URI="#xpointer(id('tag'))"
Further, it looks like the id('tag') actually resolves to looking for the
first element in the document with the attribute Id="tag". This is
</pre>
</blockquote>
<pre wrap=""><!---->commented
</pre>
<blockquote type="cite">
<pre wrap="">as a hack for documents w/o schemas or DTDs. Can you explain what's behind
this "hack" and where you are headed with regard to the complete URI
specification?
Also, since the URI processing appears to be limited, I'm wondering
if you support the use of an <XPath> element child of the <Transform>
element fully, partially, or not at all.
The problem I'm trying to solve is that I have documents which
consist of multiple sections that each have an individual signature on
that section only. In other words,
<Document>
<Section1>
... content ...
<Signature ... />
</Section1>
<Section2>
... content ...
<Signature ... />
</Section2>
...
</Document>
I need to have some way (presumably the Reference URI or the
Transform) to limit the signature (and verification) to just the
content of <Section1> when computing <Section1>'s signature block, etc.
What is the best way to support this case with the current XMLSEC
library?
Thanks!
Ferrell
=====================================
Ferrell Moultrie (<a class="moz-txt-link-abbreviated" href="mailto:ferrell@iss.net">ferrell@iss.net</a>)
Software Engineer
Internet Security Systems, Inc.
6303 Barfield Road
Atlanta, Georgia 30328
Phone: 404-236-2600
Direct: 404-236-2849
Fax: 404-236-2632
<a class="moz-txt-link-freetext" href="http://www.iss.net">http://www.iss.net</a>
Internet Security Systems -- The Power to Protect
=====================================
_______________________________________________
xmlsec mailing list
<a class="moz-txt-link-abbreviated" href="mailto:xmlsec@aleksey.com">xmlsec@aleksey.com</a> <a class="moz-txt-link-freetext" href="http://www.aleksey.com/mailman/listinfo/xmlsec">http://www.aleksey.com/mailman/listinfo/xmlsec</a>
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
xmlsec mailing list
<a class="moz-txt-link-abbreviated" href="mailto:xmlsec@aleksey.com">xmlsec@aleksey.com</a>
<a class="moz-txt-link-freetext" href="http://www.aleksey.com/mailman/listinfo/xmlsec">http://www.aleksey.com/mailman/listinfo/xmlsec</a>
</pre>
</blockquote>
<br>
</body>
</html>