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

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

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

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.

>As the original proposal from Roberto is missing 
>to specify a way for linking document and 
>signatures, I consider 1) and 2) as refinements 
>of his proposal (if others can work, they can be 
>considered too). If we decide to go to PRD1 with 
>more than a single option, we can keep one between 1) and 2) and 3).
>
>Another possibility could be to use some 
>mechanism inside each ds:Signature to restrict 
>the signature to a portion of the UBL document, but I do not like this because:
>- the verification process becomes more complex 
>as controls have to be added to be sure that the signed part is the right one
>- an user interface used to show the document 
>become more complicated as it has to make aware 
>the user about the signed parts by each signer

I fully agree.  It is not parallel to the hash 
expressions we've seen in other applications of XAdES.

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