Re: [spam] Re: [ubl-security] UBL-XAdES-Profile 1.0-RC1

["Roberto Cisternino" <roberto@javest.com>]

This seems however to leave unsolved the Certificate Of Origin (CoO) issue.
We have BIEs for specific actors that are endorsing the CoO.

I expect the signature for endorsement/approval in the real world is
something driven by a workflow.
I mean here a human workflow so there are different times where signatures
are added to the same document.

This is a requirement, and it seems to me very common not only for the CoO.
The are environments where the approval cycle is really important.

Also an electronic document like the CoO adds an additional issue as we
cannot be sure the endorser name and its signature will be predefined
before or during the endorsement/approval cycle.

I think we have two main kind of documents:

D.1) Write-once Electronic Document (issued once)

D.2) Live Electronic Document (integrated, enhanced during its life-cycle
like in FreightWise)

and two main kind of document signatures:

S.1) Signature for integrity and origin (applied to the document)

S.2) Signature for approval and/or endorsement
      This signature has a different role in the document and it seems to
me that could be just applied to the unique identifier/date of the
Document and not the whole document.

S.2 could solve the complexity of adding new endorsements along with the
other information abount the endorser and even during the life-cycle of
the document (D.2).

The signing difference between the Invoice and the CertificateOfOrigin are:

- the Invoice is following the D.1/S.1 case

- the CoO is more complex as we have different contexts where the
signature is applied and different roles for the signatures:

close to D.1/S.2 case.
Infact the invoice signature is in the root and the CoO signatures are in
different contexts.

The


> The main problem we are addressing is that when trying to us cac:Signature
> we need to create them jointly with the stamping of the digital signature
> in the extension. This makes the signature and verification process very
> complex.
>
> When facing the problem of really signing a UBL document we encountered
> that issue: We were not able to proceed to change the cac:Signature xml
> instance fragment and adding the signature easily. We were not able to use
> already existant software tools to place enveloped signatures due to the
> fact of this specific new functionality,
>
> Besides that, the existance of the UBL cac:Signature element does not add
> any value. It can only be a source of inconsistencies between the items
> stated in cac:Signature and the ones stated inside the digital signature.
> UBL already had the cac:Signature element, so we just kept it as optional
> for backwards compatibility. But the idea is not using it, as it is not
> required.
>
> Regards, Oriol
>
> El 13/08/2010, a las 18:50, G. Ken Holman escribió:
>
>> At 2010-08-13 12:09 -0400, I wrote:
>>> I've attached a ZIP file with a signed example reflecting the above (I
>>> hope!) and schema fragments that I will put into the release candidate
>>> later today ... and you can see that it validates by two W3C Schema
>>> processors:
>>>
>>> ~/u/UBL/UBL2.1/sig $ w3cschema xsd/maindoc/UBL-Invoice-2.1.xsd
>>> sigtest.xml
>>> Xerces...
>>> Attempting validating, namespace-aware parse
>>> Parse succeeded (0.877) with no errors and no warnings.
>>> Saxon...
>>> No validation errors
>>> ~/u/UBL/UBL2.1/sig $
>>>
>>> Oriol, are you in a position to remove from the example the
>>> faux-signature and replace it with a bona-fide signature and test it?
>>
>> I've attached a ZIP with a repaired example, not affecting validation
>> but I hadn't used the new URN that I had proposed and now I am.  And in
>> the spirit of using "ext:" for the extension namespace prefix, I'm now
>> using "sig:" for the signature namespace prefix (instead of "csc:").
>>
>> . . . . . . . . . . . Ken <gkholman-sigtest-20100813-1740z.zip>
>> --
>> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>


-- 
* JAVEST by Roberto Cisternino
*
* Document Engineering Services Ltd. - Alliance Member
* UBL Italian Localization SubCommittee (ITLSC), co-Chair
* UBL Online Community editorial board member (ubl.xml.org)
* Italian UBL Advisor

  Roberto Cisternino

  mobile: +39 328 2148123 begin_of_the_skype_highlighting              +39
328 2148123      end_of_the_skype_highlighting
  skype:  roberto.cisternino.ubl-itlsc

[UBL Technical Committee]
    http://www.oasis-open.org/committees/ubl

[UBL Online Community]
    http://ubl.xml.org

[UBL International Conferences]
    http://www.ublconference.org

[UBL Italian Localization Subcommittee]
    http://www.oasis-open.org/committees/ubl-itlsc

[Iniziativa divulgativa UBL Italia]
    http://www.ubl-italia.org