Re: [ubl-security] Questions regarding the XAdES Profile

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

At 2010-08-26 17:08 +0200, Oriol Bausą Peris wrote:

>El 26/08/2010, a las 02:36, G. Ken Holman escribió:
>
> > At 2010-08-25 18:24 +0200, Oriol Bausą Peris wrote:
> >> > No full agreement is reached as Oriol 
> reported some concern on the scaffolding structure:
> >> > http://lists.oasis-open.org/archives/ubl-security/201008/msg00031.html
> >>
> >> Why do you need SignatureGroup inside 
> SignatureInformation? Is it not enough with 
> sig:SignatureInformation as a container for all signatures?
> >
> > Because there could be many groups of 
> signatures, one group for each of the signature 
> business objects in the Certificate Of Origin 
> document.  Without the SignatureGroup element, 
> all of the signatures would be mixed ... I 
> don't know if that would impact on workflow or 
> not.  But, I feel the association is important 
> to express ... though it is only the 
> Certificate Of Origin for now, future document 
> types might need multiple groups of signatures 
> with each group associated to a different signature business object.
>
>I am not pretty sure about the business process 
>related with the CoO. I really don't know if 
>this document is intended for different 
>actors  start signing different parts of a 
>structured message whenever it is compiled, I 
>tend to think that the CoO is a collection of 
>documents, some of them can be signed and others 
>not, but I cannot see people signing parts of 
>the document.... What I mean is that we are 
>getting to something too complex to fulfill a 
>business process that (at least for me) is 
>unclear. If I am wrong and the CoO requires 
>different actors signing the same CoO (or 
>different parts thereof), then the solution could be fine.

The CoO work came out of Singapore and I don't 
think we have access to the people who had 
particular workflows in mind when they modeled 
multiple signature business objects in a single document.

Nevertheless, if our solution were structured as 
you proposed with only a single group of 
signatures, this would also preclude future UBL 
documents from supporting associations with 
multiple signature groups should that be necessary.

Regardless, a particular customization could 
choose to subset the use of the extension to only 
the unassociated signature group ... whereas 
another customization would find multiple groups 
useful for CoO or future documents.

I think in UBL we have been trying to present 
flexible solutions from which communities of 
users can pare down what is available into what 
they need.  Tags are cheap ... we don't have to 
make the length of them or the number of them the 
absolute smallest theoretically possible and 
thereby jeopardize simplicity or understandability.

> >> > 2) only for documents where more than a 
> single cac:Signature for different purposes can 
> be present (at present just COO) the 
> scaffolding can include an ID to reference to 
> the relevant UBL document part that the signature refers to:
> >> >  <sig:SignatureInformation>
> >> >    <sig:SignatureGroup> (one, if needed)
> >> >      <ds:signature>…</ds:signature> (one or more)
> >> >    </sig:SignatureGroup>
> >> >    <sig:IdentifiedSignatureGroup> (one or more, if needed)
> >> >      <cbc:ID></cbc:ID>
> >> >      <sig:SignatureGroup>
> >> >        <ds:Signature> … </ds:Signature> (one or more)
> >> >      </sig:SignatureGroup>
> >> >    </sig:IdentifiedSignatureGroup>
> >> >  </sig:SignatureInformation>
> >> >
> >>
> >> why we cannot simply use the identifier 
> attribute from the ds:Signature element as such signature identifier?
> >
> > Because the declared type of that attribute 
> named "Id" is "ID" which is a *source* 
> attribute ... it isn't an IDREF or a 
> *reference* attribute.  It is uniquely 
> identifying each individual signature.  All 
> instances of that attribute must be unique in 
> the XML document.  The semantic that is needed 
> is an association of a group of signatures to a 
> particular signature business object.
> >
> > Thus, if there are two signatures for one 
> business object with <cbc:ID>x</cbc:ID>, they 
> cannot both have Id="x" because of the schema 
> constraint that says all <ds:Signature Id="?"> 
> attributes must be unique.  There would be a 
> validation error.  The structure I proposed 
> creates the <sig:IdentifiedSignatureGroup> 
> associated with the <cac:Signature> business 
> object through the <cbc:ID>x</cbc:ID> child, 
> and then the one group of all <ds:Signature> 
> signatures for that association.  No validation errors.
> >
> > Also if the signing software wants to add 
> unique identifiers to those signatures, it can 
> do so without interfering with UBL semantics 
> because we will have avoided changing or 
> co-opting anything from the W3C specification 
> for our own purposes ... which on its own is, I think, a compelling reason.
> >
> > So, I'm of the opinion the current attributes 
> and elements in <ds:Signature> cannot give us 
> the association pointer we need to the 
> <cac:Signature> business object.  Therefore, 
> after considering your proposal I still think 
> we need the structure I've proposed.
> >
> > *BUT* thinking about the response to your 
> email, something came to mind.  I'll start a new thread with my question.
> >
>
>Again, i think all this comes from an unclear 
>business process related to the Certificate of 
>Origin, but maybe it is only unclear to me.

But I think I've also proven that the solution of 
using any <ds:Signature> attribute or descendant 
is not appropriate, thus necessitating us 
proposing a UBL-based solution for the 
association of a group of signatures to one of 
possibly many signature business objects in a 
document.  Yes, CoO is the only one thus far with 
multiple signature business objects, but I think 
having this flexibility will be important in case 
future documents need to have this feature.  If 
communities don't want the feature, they can subset its use.

But I will defer if people can propose an 
alternative.  Just that the alternative of using 
the <ds:Signature Id=""> attribute is technically 
inappropriate because of the uniqueness 
constraint on the attribute value.  And what 
about future documents that need flexibility if 
they choose to use more than one <cac:Signature> 
element in their design, which they have every right to choose?

I value that other proposals are being put 
forward ... this properly challenges what I've 
put forward so that we can search for a better 
solution if my proposal falls short.  If other 
proposals can be made as soon as possible, we can 
go to PRD1 with something for the community to test.

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

p.s. any immediate feedback on my other message 
of last night regarding the scope of the 
signature hash will be very helpful ... if 
someone endorses that change I'm proposing then I 
can make another ZIP for Jon for the packaging that has the revised example.

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