Proposed change to the "signed information" transform expression

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

Hi all,

In my current proposal for the digital signature transform expression 
of those nodes of a UBL instance that participate in the signature 
hash calculation, I have this expression:

         count(ancestor-or-self::sig:SignatureGroup |
               here()/ancestor::sig:SignatureGroup[1]) >
         count(ancestor-or-self::sig:SignatureGroup)

... which excludes everything under the ancestral 
<sig:SignatureGroup> element.  This makes sense when there is only a 
single set of signatures.  In UBL there is a chance there will be 
multiple signature groups (so far only for the Certificate Of Origin, 
but who knows what document in the future might have multiple 
signature groups?).

Something came to mind this evening when writing my response to Oriol 
... we need to change the above to instead exclude everything outside 
of <sig:SignatureInformation>:

         count(ancestor-or-self::sig:SignatureInformation |
               here()/ancestor::sig:SignatureInformation[1]) >
         count(ancestor-or-self::sig:SignatureInformation)

... in order to allow the *different* groups of signatures to have 
their signatures added in a random order.  Since there is no business 
information inside of the <sig:SignatureInformation> element, there 
is nothing "unprotected" by making the proposed change above.

Also, if we don't make the change, we end up "signing other 
signatures" which means that once this is done, the "other 
signatures" cannot be augmented or the just completed signature is 
invalid.  So this is really a critically important change.

This does not involve a schema change, but it does require an 
instance change to one of the sample instances.  The documentation 
would also have to change in section 5.3.

I can prepare a new ZIP for Jon at any time with this change, but I 
would like someone from the Security SC to confirm my suspicions 
above and endorse my proposed change (or tell me I'm mistaken!) as 
soon as possible.

Thanks!  And thank you for your patience with me as I better 
understand each day how this security stuff works ... I *think* I 
have a real handle on it now and feel this proposal is an important 
improvement.

. . . . . . . . . . . Ken

--
XSLT/XQuery training:   after http://XMLPrague.cz 2011-03-28/04-01
Vote for your XML training:   http://www.CraneSoftwrights.com/o/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal