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

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

I think your thoughts confirm that the solution found is enough flexible to accommodate additional requirements (with some tuning) but, at this stage, I'm reluctant to change the document, for the following reasons:
- the processing model of XMLDSIG is quite special. The 2 XPATH I mentioned in my previous email are sue, as one is a copy&paste from the W3C recommendation, the other has been derived from it and tested by Juan Carlos (with just a change in the name of the tag). I prefer to be able to test any new xpath and to verify if this is the best approach to follow. Also detached signature can be used within the same XML document, provided that the signed data belong to a different XML tree, and this is always the case for an UBL extension and the content to be signed. This is not to argument now what is the best solution, I rather prefer to be not too much specific now and ask developers for comments.
- there are other options in XAdES that we can use for the type of commitment, the signer role and so on. They can be defined quite flexibly and, if there is such a need, we can add guidelines so that user communities can define their ones in a standard way, so that signature software can understand and display them in a standard way
- I'm absolutely not sure we can imagine by ourself all possible use cases and to prioritize them. We'll get for example feedback from people working on VCD: as they are, among others, Chambre of Commerces, they can provide us with feedback that can be managed within the Security SC.

In conclusion I'd like to keep the last structure you defined and documented and ask for feedback. What do you think?

Andrea


Il giorno 30/ago/2010, alle ore 17.57, G. Ken Holman ha scritto:

> At 2010-08-30 08:29 -0400, I wrote:
>> True.  Consider that (I believe) a user could use the following to digitally sign a single line item whose ID is '12345', thus allowing any of the remainder of the document to change but this signature to remain valid:
>> 
>>   <Transform
>>     Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116";>
>>    <XPath xmlns:cac="..." xmlns:cbc="...">
>>      ancestor-or-self::cac:InvoiceLine[cbc:ID='12345']
>>    </XPath>
>>   </Transform>
>> ...
>> And one could scope the signing of *only* the attachment and nothing else through this XML signature hash transformation expression:
>> 
>> <Transform
>>   Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116";>
>>  <XPath xmlns:cac="..." xmlns:cbc="...">
>> ancestor-or-self::cac:ExternalReference[cbc:FileName='Invoice1234OCR.gif']
>>  </XPath>
>> </Transform>
>> 
>> ... provided, of course, that aggregate has the hash and algorithm filled in.
> 
> What the flexibility in the above has brought to mind is that a user wanting to do any of the above may wish to document with the signature the reason or purpose in adding the particular signature.  In parallel with extension reasons, this suggests augmenting the structure as follows with new optional signature metadata constructs:
> 
>  <sac:SignatureInformation>
>    <cbc:ID>...</cbc:ID>
>    <sbc:ReferencedSignatureID>...</sbc:ReferencedSignatureID>
>    <sbc:SignatureReasonCode>(code value)</sbc:SignatureReasonCode>
>    <sbc:SignatureReason>(text value)</sbc:SignatureReason>
>    <ds:Signature>
>      ...
>    </ds:Signature>
>  </sac:SignatureInformation>
> 
> The above would allow the user to formally document the signatures being added to the document.  And for a user community to dictate that, say, "five different signatures are possible for a document and this is the code list of possible values for the reason code".  Such reasons are inappropriate for the <ext:ExtensionReasonCode> and <ext:ExtensionReason> elements, because those elements relate to the entire extension, not just to a single signature.
> 
> For a moment I thought of adding <cac:SignatoryParty> but then it became too much a copy of <cac:Signature> and too much of a business object, so I took it out.  I think the above metadata is suitably restrictive to be considered as metadata for the digital signature and not business information.  The party information can likely be found anyway in the <ds:Signature> content.
> 
> Any objections to adding this reason-related signature metadata to the model?
> 
> . . . . . . . . . . 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
>