[xmlsec] XMLSEC Reference URI question

Aleksey Sanin aleksey at aleksey.com
Wed Jul 24 12:01:22 PDT 2002 

I hate to say this but XML DSig works very bad with compund documents.
And I am not sure that XInclude will help you here because if you have a 
standalone
document
    <Section>
        ...
        <dsig: Signature>
            ...
            <dsig:Reference URI=".....">
                ....
            </dsig:Reference>
        </dsig:Signature>
    </Section>
and after this it is embeded into another larger document then the path 
to <Section> changes
(and reference URI is signed with the message itself!). I really don't 
think that full xpointer
support can help you here.
However, I got another idea. There is a nice XPath extension in XML 
DSig: function "here()".
It is used to create enveloping signatures and I think it can help you. 
Please check the XMLDSig
spec for details on how it works and the enveloping transform description.

Aleksey




Moultrie, Ferrell (ISSAtlanta) wrote:

>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 [mailto:aleksey at aleksey.com] 
>Sent: Tuesday, July 23, 2002 6:48 PM
>To: Moultrie, Ferrell (ISSAtlanta)
>Cc: 'xmlsec at aleksey.com'; 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:
>
>  
>
>>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
>>    
>>
>commented
>  
>
>>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 (ferrell at iss.net)
>>Software Engineer
>>
>>Internet Security Systems, Inc.
>>6303 Barfield Road
>>Atlanta, Georgia 30328
>>Phone:  404-236-2600
>>Direct: 404-236-2849
>>Fax:    404-236-2632
>>http://www.iss.net
>>
>>Internet Security Systems -- The Power to Protect 
>>=====================================
>>_______________________________________________
>>xmlsec mailing list
>>xmlsec at aleksey.com http://www.aleksey.com/mailman/listinfo/xmlsec
>> 
>>
>>    
>>
>
>_______________________________________________
>xmlsec mailing list
>xmlsec at aleksey.com
>http://www.aleksey.com/mailman/listinfo/xmlsec
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.aleksey.com/pipermail/xmlsec/attachments/20020724/262ae428/attachment.htm

More information about the xmlsec mailing list