[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-security] Regarding detached signatures
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]