[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [integration] Re: [ubl-security] UBL-XAdES-Profile 1.0-RC1
I agree with Roberto in the different situations, and I think we need to cover D1/S1 for UBL documents. Workflow can be done by any other means, There could be a problem trying to identify what to sign and so on in the CoO. Regards, Oriol El 14/08/2010, a las 11:34, Roberto Cisternino escribió: > 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]