Re: Making references

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

If I understood correctly you suggest:
- to not put any constraint on ext:UBLExtensions/ext:UBLExtension/cbc:ID
- to add a new e.g. "sig" namespace and a Signature element containing a cbc:ID = cac:Signature/cbc:ID

This way the eventual ID in ds:Signature, the eventual cbc:ID in ext:UBLExtensions/ext:UBLExtension/cbc:ID are not constrained and implementors can use them with their original meaning.
At this point we can also add some useful property to sig:Signature (this is under our control) for possibly different signature content we can support in future such as detached CMS/CAdES, detached XAdES and so on. We could add a content-type to specify the mime type of the signature and its encoding to support binary signatures. 
On the other hand we are adding some complexity... It's not clear to me at the moment if the added complexity balances the advantages.

Andrea


Il giorno 30/nov/2009, alle ore 17.28, G. Ken Holman ha scritto:

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