Re: [ubl-security] Where to go from here

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

At 2010-08-28 02:19 +0200, Andrea Caccia wrote:
>Il giorno 27/ago/2010, alle ore 23.46, G. Ken Holman ha scritto:
> > You suggest we have multiple UBL extensions, each one satisfying 
> one of the business objects.
>If I understood correctly this is also Roberto's proposal to have 
>many extensions, each having a single signature.

Forgive me for not citing both of you.  Let's call this the "one 
signature per UBL extension method".

>Ok. Can we fix this using 2) and an Xpath without here()?
>Something like:
><XPath xmlns:dsig="&dsig;">
>              not(ancestor-or-self::sig:SignatureGroup)
></XPath>

I had considered that but rejected it because of the extension 
metadata.  When you add the first extension with the first signature 
and then add the second extension with the second signature, the UBL 
extension metadata of the second extension is included in the hash of 
the first signature and invalidates it.

However .... that can be worked around (below), but not without some 
worrisome requirements.

>well, I think there could be 2 possible approaches:
>
>1) use the transformation you propose:
><XPath xmlns:dsig="&dsig;">
>     count(ancestor-or-self::sig:SignatureInformation |
>     here()/ancestor::sig:SignatureInformation[1]) >
>     count(ancestor-or-self::sig:SignatureInformation)
></Xpath>
>
>that, if there is no need to protect by the signature the IDs 
>pointing to the document gives the maximum flexibility: you can add 
>whatever signatures and IDs you want at any stage without breaking 
>the signature. It has exactly all the flexibility of the solution 
>proposed by Roberto without removing all extensions from hash calculation
>
>2) use the transformation I proposed for solution 2), i.e.:
><XPath xmlns:dsig="&dsig;">
>              not(ancestor-or-self::sig:SignatureGroup)
></XPath>
>that keeps the scaffolding in the hash calculation, allowing 
>arbitrary addition of signatures in each SignatureGroup but not 
>allowing to add IDs after the first signature is calculated. This 
>means in this case it is required to build all the scaffolding 
>before applying any signature

I think building all the scaffolding first would be a challenge and 
inflexible to workflow changes.

But this expression would probably work and accommodate UBL extension metadata:

<XPath xmlns:dsig="&dsig;">
     not(ancestor-or-self::ext:UBLExtension[.//sig:SignatureInformation])
</XPath>

... which excludes from the hash all descendents of every UBL 
Extension that is added that has signature information in that 
extension.  *But* it would _not_ allow any white-space nodes between 
the extensions.

For users who are indenting their XML, adding an extension without 
adding new text nodes might be a challenge.

For example, consider the following as a first signature:

   <UBLExtensions>
    <UBLExtension>
     <ext:ExtensionURI>urn:oasis:...:signature</ext:ExtensionURI>
     <ext:ExtensionContent>
       <sig:SignatureInformation ...>
         <cbc:ID>...</cbc:ID>
         <sig:SignatureGroup>
            <ds:Signature>...</ds:Signature>
            <ds:Signature>...</ds:Signature>
         </sig:SignatureGroup>
       </sig:SignatureInformation ...>
     </ext:ExtensionContent>
    </UBLExtension>
   </UBLExtensions>

When a second signature is added without white-space in between, the 
following will be acceptable:

   <UBLExtensions>
    <UBLExtension>
     <ext:ExtensionURI>urn:oasis:...:signature</ext:ExtensionURI>
     <ext:ExtensionContent>
       <sig:SignatureInformation ...>
         <cbc:ID>...</cbc:ID>
         <sig:SignatureGroup>
            <ds:Signature>...</ds:Signature>
            <ds:Signature>...</ds:Signature>
         </sig:SignatureGroup>
       </sig:SignatureInformation ...>
     </ext:ExtensionContent>
    </UBLExtension><UBLExtension>
     <ext:ExtensionURI>urn:oasis:...:signature</ext:ExtensionURI>
     <ext:ExtensionContent>
       <sig:SignatureInformation ...>
         <cbc:ID>...</cbc:ID>
         <sig:SignatureGroup>
            <ds:Signature>...</ds:Signature>
            <ds:Signature>...</ds:Signature>
         </sig:SignatureGroup>
       </sig:SignatureInformation ...>
     </ext:ExtensionContent>
    </UBLExtension>
   </UBLExtensions>

... but the following will not be acceptable because there is a text 
node between the end of the first </UBLExtension> and the start of 
the second <UBLExtension> that is included in the hash ... I would 
guess that this nuance of the indentation white-space between the 
first and second extension would be lost on most users and they 
wouldn't understand the complex reasons why the above works but the 
following does not work, or if they do understand it they won't 
recognize the kind of error they've made:

   <UBLExtensions>
    <UBLExtension>
     <ext:ExtensionURI>urn:oasis:...:signature</ext:ExtensionURI>
     <ext:ExtensionContent>
       <sig:SignatureInformation ...>
         <cbc:ID>...</cbc:ID>
         <sig:SignatureGroup>
            <ds:Signature>...</ds:Signature>
            <ds:Signature>...</ds:Signature>
         </sig:SignatureGroup>
       </sig:SignatureInformation ...>
     </ext:ExtensionContent>
    </UBLExtension>
    <UBLExtension>
     <ext:ExtensionURI>urn:oasis:...:signature</ext:ExtensionURI>
     <ext:ExtensionContent>
       <sig:SignatureInformation ...>
         <cbc:ID>...</cbc:ID>
         <sig:SignatureGroup>
            <ds:Signature>...</ds:Signature>
            <ds:Signature>...</ds:Signature>
         </sig:SignatureGroup>
       </sig:SignatureInformation ...>
     </ext:ExtensionContent>
    </UBLExtension>
   </UBLExtensions>

>If you look at the resulting structure, adding an extension for each 
>signature (or group of signatures) lead to a more complex result 
>that having the scaffolding.

Good point.

Here is the comparison of a three-signature extension (one global 
group and two identified groups, two W3C signatures per group) using 
(A) the "one extension per signature method (proposed - 36 lines)" 
and (B) the "one extension for all signature methods (current - 27 
lines)".  So, my current scaffolding method would end up being 
shorter than one signature per extension method, plus it doesn't have 
the complexity of worrying about white-space indentation nodes 
between the signatures which is so nuanced that I worry our users 
won't understand it or recognize it happening.

(A)
   <UBLExtensions>
    <UBLExtension>
     <ext:ExtensionURI>urn:oasis:...:signature</ext:ExtensionURI>
     <ext:ExtensionContent>
       <sig:SignatureInformation ...>
         <sig:SignatureGroup>
            <ds:Signature>...</ds:Signature>
            <ds:Signature>...</ds:Signature>
         </sig:SignatureGroup>
       </sig:SignatureInformation ...>
     </ext:ExtensionContent>
    </UBLExtension><UBLExtension>
     <ext:ExtensionURI>urn:oasis:...:signature</ext:ExtensionURI>
     <ext:ExtensionContent>
       <sig:SignatureInformation ...>
         <cbc:ID>...</cbc:ID>
         <sig:SignatureGroup>
            <ds:Signature>...</ds:Signature>
            <ds:Signature>...</ds:Signature>
         </sig:SignatureGroup>
       </sig:SignatureInformation ...>
     </ext:ExtensionContent>
    </UBLExtension><UBLExtension>
     <ext:ExtensionURI>urn:oasis:...:signature</ext:ExtensionURI>
     <ext:ExtensionContent>
       <sig:SignatureInformation ...>
         <cbc:ID>...</cbc:ID>
         <sig:SignatureGroup>
            <ds:Signature>...</ds:Signature>
            <ds:Signature>...</ds:Signature>
         </sig:SignatureGroup>
       </sig:SignatureInformation ...>
     </ext:ExtensionContent>
    </UBLExtension>
   </UBLExtensions>

(B)
   <UBLExtensions>
    <UBLExtension>
     <ext:ExtensionURI>urn:oasis:...:signature</ext:ExtensionURI>
     <ext:ExtensionContent>
       <sig:SignatureInformation ...>
         <sig:SignatureGroup>
            <ds:Signature>...</ds:Signature>
            <ds:Signature>...</ds:Signature>
         </sig:SignatureGroup>
         <sig:IdentifiedSignatureGroup>
          <cbc:ID>...</cbc:ID>
          <sig:SignatureGroup>
            <ds:Signature>...</ds:Signature>
            <ds:Signature>...</ds:Signature>
          </sig:SignatureGroup>
         </sig:IdentifiedSignatureGroup>
         <sig:IdentifiedSignatureGroup>
          <cbc:ID>...</cbc:ID>
          <sig:SignatureGroup>
            <ds:Signature>...</ds:Signature>
            <ds:Signature>...</ds:Signature>
          </sig:SignatureGroup>
         </sig:IdentifiedSignatureGroup>
       </sig:SignatureInformation ...>
     </ext:ExtensionContent>
    </UBLExtension>
   </UBLExtensions>

Tim, my supposition above for the repetition of the <ds:Signature> is 
that UBL modelling rules require the containing <sig:SignatureGroup> 
so that that repeating group is not a sibling of the singleton 
<cbc:ID>.  However, since <ds:Signature> itself is a structure and 
not a leaf, is it acceptable in all the examples above to remove 
<sig:SignatureGroup> and make <ds:Signature> a sibling of 
<cbc:ID>?  I thought it important to make the <ds:Signature> siblings 
"pure" without other siblings, but removing the <sig:SignatureGroup> 
would make things a bit simpler.

>This is the most flexible solution and, at the end, it is even less 
>complex than the other approaches that we considered.

Sorry, Andrea, I've lost track in your message about which one you 
are referring to above when you say "this".

I think the example above shows the "scaffolding method" in the 
current schemas is more compact and less error/trouble prone than the 
"one signature per UBL extension method" that is being proposed.

. . . . . . . . . . . . . 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