OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: Making references


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

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

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]