OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-security message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Hello,

I accidentally pressed send bu my considerations were not completed yet.

So please find below the integrations.

Roberto

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

   a) Issuer Endorsement
   b) Embassy Endorsement
   c) Insurance Endorsement

   Here the (a) is a signature for the issuer and probaly this signature
should be following the D.1/S.1 case to provide integrity and origin.

   (b) and (c) are just additional endorsements and these are applied
surely in a different time, location and by different parties
(D.2./S.2)


Finally I think we still have to provide a valid answer to these business
cases.

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


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]