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

[Andrea Caccia <andrea.caccia@studiocaccia.com>]

Il giorno 27/ago/2010, alle ore 23.46, G. Ken Holman ha scritto:

> At 2010-08-27 18:53 +0200, Andrea Caccia wrote:
>> Il giorno 27/ago/2010, alle ore 16.04, G. Ken Holman ha scritto:
>> > At 2010-08-27 15:43 +0200, Andrea Caccia wrote:
>> >> My last proposal is a vote for (A) trying to fix some of the issues you point out at the end of your email.
>> >
>> > Please advise how you perceive the fixes to be accomplished.  I pointed out that (A) does not provide for associations with UBL business objects.  I've already explained we cannot use the <ds:Signature Id=""> attribute for referencing UBL business objects.
>> Thanks for remembering this, you're absolutely right.
>> Here are the solutions I propose:
>> 
>> 1) add an optional cac:ID to the "zero scaffolding" - not very well following UBL rules but the simplest way:
>> <sig:SignatureInformation>
>>        <cbc:ID>…</cbc:ID> (optional)
>>        <ds:Signature>...</ds:Signature>
>>        …
>>        <ds:Signature>...</ds:Signature>
>> </sig:SignatureInformation>
>> The rule is: if no ID is present, the signature refers to the whole document. More than one extension containing signatures with no ID is exactly the same as having a single extension with no ID and all the signatures inside it.
>> In cases like COO where you can find many signatures you have at least an extension for any ID you have to reference end optionally another extension for the document wise signature. No need for cac:Signature if the parts to be referenced have a cbc:ID that can be referenced.
>> 
>> 2) same as above but following better UBL rules:
>> <sig:SignatureInformation>
>>        <cbc:ID>…</cbc:ID> (optional)
>>        <sig:SignatureGroup>
>>                <ds:Signature>...</ds:Signature>
>>                …
>>                <ds:Signature>...</ds:Signature>
>>        </sig:SignatureGroup>
>> </sig:SignatureInformation>
> 
> Forgive me, I do not want to sound critical, but I do not see either (1) or (2) working when there is more than one signature business object (e.g. CoO) with an identifier.
> 
> 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.

>  On the surface this looks like a good compromise.  Unfortunately, I think it does not work in day-to-day use because of the scope of the hash transformation calculation.
> 
> Consider the hash transformation:
> 
> count(ancestor-or-self::sig:SignatureInformation |
>       here()/ancestor::sig:SignatureInformation[1]) >
> count(ancestor-or-self::sig:SignatureInformation)
> 
> The "here()" function focuses the hash to everything outside of the extension with this expression.  With two or more UBL extensions of a signature, this means that one of the signature extensions signs all of the another signatures.  This means that when someone adds a signature to one of the other extensions, the earlier signature is invalidated because of the hash transformation.
> 
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>
As sig:SignatureGroup is defined by us, we can be sure that it can't appear in any other context that our signature extensions. On the contrary I think that cbc:ID, if present must be signed to avoid that a signature meant for a business object is moved from one extension to another one.
So if this Xpath (derived from the first example in "6.6.3 XPath Filtering" of XMLDSIG) works as expected then solution 2 is usable. But this way there is a good reason to reconsider 3) - see below

> In your scenario the common ancestor of all digital signatures is the UBL extension point itself that contains *all* extensions.
> 
> But, I believe we cannot have a hash transformation that excludes *all* extensions because other extensions may very well have extended business objects of import to a community of users that need to be signed.
> 
> Other examples of XAdES use (ref: ODF and OCF) are parallels to the above expression of identifying a single ancestor under which all signature information is maintained.
> 
>> 3) the full scaffolding approach, s proposed by Ken (in this case I would limit as it is now to have a single extension containing signatures)
> 
> Yes, and because the expression with the "here()" function in all of the <ds:Signature> elements identifies the same ancestral node <sig:SignatureInformation>, we allow all signatures to be added to the document in an arbitrary order with no impact on the standard business objects or business objects under other extensions.
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

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. 
This is the most flexible solution and, at the end, it is even less complex than the other approaches that we considered. 

Andrea