[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-security] Regarding detached signatures
I agree too. As Oriol suggests we should avoid to overlap with any local legislation and also other standard body scope. As there is no agreement on adding detached signature, I suggest we close this document fixing the small issues now open and start the public review. I also propose, to better understand real user requirements, to prepare a questionnaire asking about any format/form/issue that should be covered by this profile and/or new ones. Another issue we should start to think about is confidentiality. This will likely require some modification to the UBL syntax (or maybe we can use a minimal UBL with the real UBL message encrypted into an extension?). I also attach here the draft document from CEFACT TBG6 (Title: Digital Evidence Recommendation; this is the new name that was decided at the last CEFACT meeting last week; the document I have is not updated yet) . I can collect any comment and report back to TBG6. The same I'd like to do with our document, when it's in its final version. Andrea -------- This message is sent to one or more specific recipient. If you are not the intended recipient, please notify the sender and delete this message. -------- Questo messaggio è inviato a specifici destinatari. Se non siete i destinatari, siete pregati di informare il mittente e cancellare questo Messaggio. -----Original Message----- From: Oriol Bausà [mailto:ORIOL@INVINET.ORG] Sent: Wednesday, October 07, 2009 5:29 PM To: roberto@javest.com Cc: Julian Inza; ubl-security@lists.oasis-open.org Subject: Re: [ubl-security] Regarding detached signatures Absolutely agree, it is not up to UBL decide on the legislation that can be different in different countries. Regards, Oriol El 07/10/2009, a las 17:21, Roberto Cisternino escribió: > Dear collegues, > > The main issue was to describe how a specific signature like XAdES > can be > enveloped into UBL, because the cac:Signature alone was not > sufficient. > > Other kind of signatures can be referenced using the base > cac:Signature > aggregate, so I think we can just provide good samples for > implementers. > > Of course we can't say that UBL MUST be signed with a specific > version of > XAdES or other means, but we need to recommendate how the > implementer can > reference the signature into an UBL instance, in a way that the other > party will be able to: > 1) discover the location internal/external of the signature. > 2) the type and kind of signature and its version > ... so on > > It is an implementation profile, but for the use of XAdES (or other > means) > with UBL, so not about how can I use XAdES. > > Our recommendation could mention specific part of XAdES to be used to > solve specific issues, but in general. > > Prescribe is like mandate, and we can't do it, instead we can offer a > clear view of actual standards/technologies to be used to > accomplish main > business cases like B2G, eInvoicing, ... > > For instance... > - For basic procurement UBL recommends the use of the ETSI profile > xyz 2.1 > - For cross-border UBL recommend ... for e-Invoicing > - For Intra-EU UBL recommend ... > > But it is outside UBL, as we are tuning specific XAdES > characteristics, so > we can just recommendate, suggest... > > Once we are ready with the specification we can obtain the approval > from > third-party groups like EACT, ... and we can revise our > recommendations > through the public review. > > But the way we specify the signature should be clear, simple and > stable. > > My opinion, > > hope this helps > > Roberto > > --- >> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> >> <html> >> <head> >> </head> >> <body> >> <font color="#000000" face="arial, arial" size="2"><br> >> Dear friends,<br> >> <br> >> In the TS 101 903 standard (last version is </font>1.4.1 from >> 2009-06-15) are described several ways to creating electronic >> signatures, based on XMLDSig ( <a class="moz-txt-link-freetext" >> href="http://www.w3.org/TR/xmldsig-core/";>http://www.w3.org/TR/ >> xmldsig-core/</a> >> ) .<br> >> <br> >> So most of what is need to sign XML files electronically is in those >> standards.<br> >> <br> >> One powerful idea in the recommendation we are compiling is that a >> UBL >> signed file can be independently verified by an "electronic signature >> only" application and a "UBL aware" format processor.<br> >> <br> >> In fact, enveloped signatures are specific to XML files, while >> detached >> and enveloping signatures can also be done in CMS and CAdES.<br> >> <br> >> Also a powerful idea is that keeping a small specific way of doing >> electronic signatures simplifies generation and verification of those >> electronic signatures and eases interoperability.<br> >> <br> >> In fact, I would go deeper in the interoperability idea and would >> prescribe that UBL signatures are always encoded in the generating >> party in XAdES-XL format, including OCSP and timestamping, freeing >> the >> receiving party about the burden of Certification Service Provider >> validation (which can be very complex in an international >> multi-language environment). By the way, I wonder if we should take >> into account services as Trust-service Status List (<em>TSL</ >> em>) >> that >> are about to be generally deployed in Europe (one or more in every >> country).<br> >> <br> >> I know this discussion (XAdES-XL) has been intentionally left out of >> the scope of this document, precissely to try to ease agreements, but >> maybe is interesting to know that XAdES-T is in fact included in >> XAdES_XL. So, in those countries in which XAdES-T signature is >> mandatory, this can be prefectry complied with XAdES-XL.<br> >> <br> >> So to conclude, I would prefer to recommend a small subset of the >> standard to make interoperability easier, and in this sense I would >> prefer not to add a definition of detached signatures. But I can >> change >> my mind if anyone can convince me that there are environments in >> which >> a detached signature is a solution and an enveloped signature is a >> problem. Because, on the other hand we don´t need to make any >> recommendation just to repeat what already is in the standards.<br> >> <br> >> Best regards,<br> >> <br> >> >> <div class="moz-signature"> >> <p> <font color="#000000" face="arial, arial" size="2"> Julian Inza >> Aldaz <br> >> Presidente<br> >> <b>Albalia Interactiva, S.L.</b><br> >> <img src="cid:part1.01070805.00080104@albalia.com"; >> alt="Albalia Interactiva, S.L."><br> >> <img src="cid:part2.05090705.04060908@albalia.com"; alt="Web Portal" >> align="bottom">: <b><a href="http://www.albalia.com"; >> target="_blank">www.albalia.com</a> >> <img src="cid:part2.05090705.04060908@albalia.com"; alt="Blog" >> align="bottom">: <b><a href="http://inza.wordpress.com"; >> target="_blank">blog.inza.com</a> </b><br> >> <img src="cid:part4.02020104.02060007@albalia.com"; alt="E-Mail" >> align="bottom">: <b><a >> href="mailto:julian.inza@albalia.com";>julian.inza@albalia.com</a></ >> b><br> >> <img src="cid:part5.04070308.07040606@albalia.com"; alt="Phone" >> align="bottom">: +34 91 388 0789 <img >> src="cid:part5.04070308.07040606@albalia.com"; alt="Phone" >> align="bottom">: +34 902 365 612 <br> >> <br> >> Please update your address book. Our new postal address is: C/ >> Mentrida, 6 - 28043 - Madrid (Spain). <br> >> <br> >> <font color="#666666" size="1"> Este mensaje de correo >> electrónico >> puede contener INFORMACIÓN CONFIDENCIAL propiedad de Albalia >> Interactiva. Si lo ha recibido por error, por favor haga caso omiso, >> elimínelo y notifíquelo al remitente. La >> información >> personal puede ser >> añadida a un fichero de relaciones (que puede incluir >> información de >> marketing) en Albalia Interactiva, donde usted puede ejercer sus >> derechos de acceso, rectificación y cancelación de >> sus datos >> al amparo >> de la Ley Orgánica 15/1999. Usted está autorizado a >> utilizar >> los datos >> personales del firmante de este mensaje siempre que haya una >> manera de >> ejercer los mencionados derechos por el remitente. <br> >> <br> >> This e-mail message could contain CONFIDENTIAL INFORMATION >> property of >> Albalia Interactiva. If received by mistake, please ignore it, delete >> it and notify the sender. Your personal information can be added to a >> relationships file (that can include marketing information) at >> Albalia >> Interactiva where you can exercise your rights to access, rectify or >> cancel your data according spanish 15/1999 Organic Law. You are >> authorised to use personal data of the signer of this message as long >> as there is a way to exercise the mentioned rights by the sender. >> </font> >> <br> >> </b></font></p> >> </div> >> <br> >> </body> >> </html> >> > > > -- > * 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 > > > > --------------------------------------------------------------------- > 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 > --------------------------------------------------------------------- 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
Proposal for a common digital evidence format.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]