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

["Roberto Cisternino" <roberto@javest.com>]

> At 2010-08-27 11:42 +0200, Tim McGrath wrote:
>>I concur with Roberto's assessment.
>
> I have some comments below.
>
>>I am not sure i understand the technical implications of his
>>solution but if this is too hard then maybe the simplest solution is
>>that for the 'example' used in the 2.1 spec. we cover only the
>>simplest requirements. This is, after all, not a normative part of
>>the specification. So we dont have to try and cover the CoO -type
>> requirements.
>
> I thought this *is* normative.  What we are publishing is a
> standardized extension.  If people want to sign a UBL document in a
> way that other UBL users can expect to find it signed, they use the
> extension as we've designed it.
>
>>Roberto Cisternino wrote:
>>>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.
>
> Sometimes simpler solutions are ambiguous.  I am unclear on all the
> concerns about "complexity".
>
>>>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
>
> f) - Do not introduce ambiguity in the solution.

this can be solved easely, I just described how we can use existing
cac:Signatures to solve main issues.
I skipped other specific things here that have been already described before.

>
>>>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)
>
> Other UBL extensions are first-class parts of the UBL document and
> should, I believe, never be excluded from the signature.  When I sign
> a document, the signature area is excluded, but anything that isn't
> signature related (which includes all extensions) I believe must be
> signed and protected.  If I have line item extensions under another
> extension point, I would not want them excluded from the signature.

I agree, but this can be solved in two ways:

a) Sign just extensions containing signatures

b) add a separate ext:UBLSignatureExtension to solve ambiguities

>
>>>2) Continue using the cac:Signature as metadata where required
>>>
>>>    This solves b) e)
>
> I'm unclear on your point here.

cac:Signature is about metadata for the signature, also it is used in
different document contexts not just the root (see CoO) so I think could
be still valuable its usage in UBL.
I proposed to remove any cac:Signature from the signed content (through an
xpath filter) to allow people using cac:Signature extensively at any time
in the document life-cycle.
This is possible because cac:Signature will not invalidate anymore any
previous signature.
So we can avoid inserting too much rules to limit its usage or deprecate
it in some way.
My opinion is UBL is correct with cac:Signature from the business point of
view, so we should just find the way to play signature in an easy way for
software developers.

>
>>>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)
>
> Having multiple signatures with optional references introduces the
> ambiguity of interpreting two "un-referenced" signatures:  what is to
> be interpreted by having more than one?  Do they compete?  Are they
> unioned?  We have the opportunity through document modeling to
> prevent such ambiguities and I enforced that with the scaffolding I
> proposed.

Sorry to have used "optional", instead I am aware we are using specific
profiles to play the UBL signature the right way.  So optional is when
someone choose to don't use our profiles.

>
>>>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.
>
> Sounds good, but the devil is in the details.  And it is the details
> that I am worrying about here.  I agree broad statements are easy to
> agree with, but when it comes down to expressing the information in a
> flexible way it has to at the same time prevent ambiguity.  Or we end
> up handling exceptions that would have been prevented with suitable
> modeling.
>
> . . . . . . . . . Ken

Sorry Ken if I just provided a macro solution but I know I am not the only
one so I am sure you and others can help to refine my idea if well
accepted.

Ciao

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


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