Re: Making references

[JAVEST by Roberto Cisternino <roberto@javest.com>]

G. Ken Holman ha scritto:

7.0.1.0.2.20091130214521.0278beb8@wheresmymailserver.com" type="cite">(copied to the UBL list again because I cannot post to the security list)

At 2009-11-30 15:33 +0100, JAVEST by Roberto Cisternino wrote:

>Thus, we are back to my suggestion that we need to wrap ds:Signature with an aggregate in order to associate a cbc:ID with >ds:Signature.

In the attached mail I propose to reference the enveloped signature by using the existing UBLExtension ID:

cac:Signature/cbc:ID   ---------reference---------> ext:UBLExtensions/ext:UBLExtension/cbc:ID

Is it acceptable ?

Not to my understanding ... that is not the identifier of a signature, it is the identifier of the extension.  If I had three different extensions in one UBL document, I might use ext:UBLExtension/cbc:ID to distinguish between the three extensions.  That identifier semantic is specified by the UBL committee and has nothing to do with the information *inside* the extension that is specified by creators of extensions.  They (including, I believe, the UBL Security SC) do not have the power to change the meaning of constructs defined by the UBL committee.

We are just using UBLExtensions and I agree IDs are up to the implementers 1, 2, 3, 4  so we are just saying that one of these IDs will have to match the ID of the cac:Signature in order to identify an enveloped signature using an UBLExtension

7.0.1.0.2.20091130214521.0278beb8@wheresmymailserver.com" type="cite">

We already use internal references between payment terms and payment means, so I think this is viable.

But those are already specified by the committee as identifiers of payment terms and payment means.  The cbc:ID you are proposing to use is not an identifier of a signature, it is already specified to be an identifier of the extension.  Not the extension content.

And, anyway, ext:UBLExtension/cbc:ID is optional and as I understand the signature requirement the associated identifier is mandatory, so the cardinality is inappropriate.

Of course as UBLExtensions are free noone can impose a cardinality on all the IDs, this is why we are going to provide a profile where it is described how an enveloped signature can be expressed into UBLExtensions.

We are not changing structures we are recommending a base profile to ensure the use of UBL with enveloped signature will be interoperable and driven by this guide. (of course we do not specify specific XAdES settings this is up to the implementers and communities)

7.0.1.0.2.20091130214521.0278beb8@wheresmymailserver.com" type="cite">
And, finally, if we go with a wrapper aggregate then the top-level of the extension is under UBL security committee control and not DSIG control (in case we decide we want to add more information other than a mandatory cbc:ID).

Okay so you suggest to provide a more specific container inside the generic extension container...
I am not sure we need to add further information... the cac:Signature has already many info that are already the domain of XAdES.

So we have to think if this is really necessary as we currently need just to make a reference as part of a template-guide for using UBL and enveloped signature with the UBLExtension methodology.

I would like to have other feedback to understand better.

In general I like the idea to better identify extensions using stantard containers... let's continue the discussion :)

7.0.1.0.2.20091130214521.0278beb8@wheresmymailserver.com" type="cite">
For all those reasons, I think we need:

cac:Signature/cbc:ID   ---------reference---------> ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/sig:Signature/cbc:ID

... with an associated:

ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/sig:Signature/ds:Signature


But this is only my idea and I would like to hear the opinion of others.  I feel quite confident, though, that my approach would be within the expectations of the committee.

I hope this is ocnsidered helpful.

. . . . . . . . . . Ken

--
Vote for your XML training:   http://www.CraneSoftwrights.com/o/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
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

Nessun virus nel messaggio in arrivo.
Controllato da AVG - www.avg.com 
Versione: 8.5.426 / Database dei virus: 270.14.87/2535 -  Data di rilascio: 11/29/09 19:31:00

  

--

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

PPlease consider the environment before printing this email.