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

["G. Ken Holman" <gkholman@CraneSoftwrights.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.

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

>>2) Continue using the cac:Signature as metadata where required
>>
>>    This solves b) e)

I'm unclear on your point here.

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

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


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