Re: [ubl-security] A Simpler Solution [was: Questions regarding the XAdES Profile]

[Andrea Caccia <andrea.caccia@studiocaccia.com>]

That's an interesting idea. 
I propose the following adjustment: keep current document approach to have a container to group signature with the same meaning/references, just a <sig:Signatures>…</sig:Signatures> element containing one or more ds:Signature
In most cases just an extension can fit all needs.
My main concern is that anyone can just change all cross references and is able to change the association and purpose of any signature: the information about the association of a signature to some purpose is unprotected and cannot be trusted. 
In paper world this is like if you have a form with sections marked for different purposes with a signature field, and you can move signatures from a part to the other one in a way that is undetectable.

What about keeping the current document approach as the recommended one (a single extension with xpath excluding the set of signatures inside it) and allowing to change xpath filter as you suggest advicing about the problem that, without previous agreement with counterparts, they can reject the document?

Andrea


Il giorno 27/ago/2010, alle ore 11.25, Roberto Cisternino ha scritto:

> Dear all,
> 
> I understood we do not share a common line actually and I believe the
> reason is we are worried about different requirements (business or
> technical) and probably we are trying to force a solution that could be
> simpler.
> 
> I try to provide an *alternative* solution that should fit all.
> This do not means the actual proposals are not good, but I please you to
> consider this new one to see if the read is shorter or cleaner.
> 
> Firstly, I want respect two conditions:
> - UBL is meant for business
> - XAdES is meant for electronic signatures
> 
> so I want keep isolated the two roles and this means I want keep the CoO
> as is and cac:Signature metadata as is meant to be used.
> 
> Requirements:
> a) - Add more signatures by different actors into different times,
> possibly into different part of the document.
> b) - Keep some specific metadata about the signer (see CoO) where required
> c) - Ensure that subsequent signatures are not difficult to be applied and
> are not invalidating the previous.
> d) - Do not add complexity with additional scaffolding
> e) - Preserve actual UBL documents
> 
> Solution steps:
> 
> 1) Change the xpath filter to be used for signing an UBL document this way:
> - Remove from the signed data any cac:Signature metadata
> - Remove from the signed data all ext:UBLExtensions
> 
> This filter should solve a) c)
> 
> 2) Continue using the cac:Signature as metadata where required
> 
>   This solves b) e)
> 3) Add a new extension for each new XAdES signature and optionally
> reference the cac:Signature metadata (using one of the latest
> methodologies we initially approved)
> 
>  This supports a) b) c) d) e)
> 
> 
> If I am not wrong the idea is to keep signature metadata out of the
> signature content this way we are free to add subsequent signatures
> without invalidating nothing.
> 
> Hope this helps.
> 
> Roberto
> 
> 
> -- 
> * 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
> 
>