Re: [ubl-security] Re: [ubl] Re: Making references

[Oriol Bausą <ORIOL@INVINET.ORG>]

I am sorry but my personal opinion on all that issue is that you are  
getting all that more and more complex, and I cannot understand why  
this should be that way.

I cannot understand why you need a wrapper inside a wrapper of  
another wrapper.

I would recommend to keep this as simple as possible, and maybe the  
recommendation should be NOT using the cac:Signature component at all.

Thanks
Oriol


El 02/12/2009, a las 18:26, G. Ken Holman escribió:

> At 2009-12-02 11:36 +0100, Andrea Caccia wrote:
>> Having thought more, it make sense to consider the enveloped form  
>> only with XAdES (or the basic XMLDSIG).
>> Fot detached forms the cac:Signature should be enough, we should  
>> consider to update later the document or to prepare a new one if  
>> UBL TC ask us to do so.
>
> Is there an opportunity (i.e. enough time) for the one document to  
> guide UBL users in both embedded and detached signatures so that  
> they can make an informed decision regarding which way to go with  
> their own work?  I hope this is the case as (1) users unfamiliar  
> with the options (like me!) would learn more of what is available  
> and (2) the review/approval/publication process for committee  
> documents is onerous enough to give weight to doing this once  
> instead of twice.
>
>> 4) avoid to reuse "Signature" as tag name for the wrapping  
>> structure, as it can be confusing; a generic structure can be  
>> defined instead
>
> This has been a common question in SGML and XML vocabulary  
> development over the years and the confusion you anticipate may in  
> fact not come to be.  Moreover, using generic names may create even  
> more confusion than using similar names as the generic names need  
> then to be documented and can possibly be misinterpreted.  The  
> choice of labels is *so* very important.  BUT!!  A light bulb has  
> just turned on for me and I have some comments below.
>
>> Point 1 alone justify to wrap the signature, so I propose to:
>> a) Have a single cac:Signature with a cac:ID pointing to  
>> wrap:Envelope/cbc:ID, contained in an UBL extension, containing  
>> one or more signatures that applies to the whole document  
>> (excluding the signature itself of course, using already defined  
>> XAdES/XMLDSIG rules).
>
> Interesting!  I didn't realize there was a one-to-many relationship  
> here.  In my naïveté I thought it was always one-to-one.
>
>> The content could be:
>
> Looks good!
>
>> b) Have a generic wrapping structure that can be reused in similar  
>> cases, be part of UBL 2.1,
>
> I think we still need to have this as a standalone Security SC  
> specification of an extension, and then include the use of that  
> extension in the delivered UBL 2.1 schemas.  I don't think it  
> should be part of the UBL 2.1 specification (other than the  
> inclusion in the schemas).
>
>> and could be something like:
>> <wrap:Envelope>
>>  <cbc:ID>”AnySignatureID”</cbc:ID> [mandatory and unique among all  
>> extensions in the document]
>>  <wrap:Item> [at least one present]
>>   <cbc:ID>”AnyItemID”</cbc:ID> [optional; absent for this profile]
>>   <wrap:MimeType> mime type of the signatures</wrap:MimeType> 
>> [optional, it's the mime type of Value]
>>   <wrap:Encoding> encoding of the signatures</wrap:Encoding> 
>> [optional, if not present Value contains well formed XML, must be  
>> present for binary content and specify the base64 filter]
>>   <wrap:Value>
>>    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#";
>>                      xmlns:xades="http://uri.etsi.org/01903/v1.4.1#";>
>>          [...]
>>    </ds:Signature>
>>   </wrap:Value>
>>  </wrap:Item>
>>  <wrap:Item>
>> ...same as above...
>>  </wrap:Item>
>> </wrap:Envelope>
>>
>> Does it makes sense?
>
> Looks great!  I like the <wrap:Value> concept, but didn't realize  
> that this specification was flexible enough to allow different  
> signature expressions to be used.  Not "flexible enough from a  
> technical perspective" but "flexible enough from a policy  
> perspective":  I thought this guideline was a "what to do"  
> specification, not simply a "how to do" specification.
>
> Is it your intention in the published specification to cite  
> <ds:Signature> as *the* way sign a UBL document or *one* way to  
> sign a UBL document?
>
> Note that <wrap:Encoding> won't be needed, as it is not possible in  
> XML to have a portion of the tree using a different character  
> encoding than the rest of the tree.  You state "must be present for  
> binary content and specify base64" which while it makes sense from  
> a programming data perspective cannot be expressed using UBL's  
> naming and design rules.
>
> Which leads me to assume that was the only reason for  
> <wrap:MimeType> and therefore that is no longer needed.
>
> Following the NDR for structuring (which doesn't allow for  
> alternation), then, the structure would be using a pseudo notation:
>
>    wrap:Envelope
>      cbc:ID
>      wrap:Item+
>        cbc:ID
>        wrap:XMLValue?
>        wrap:Base64Value?
>
> ... with the business rule that one or the other of XMLValue and  
> Base64Value must be specified but not both.  This is not uncommon  
> in UBL because of the prohibition of alternation in the NDR modeling.
>
> Now, back to the labels:  I was "cheating" when I arbitrarily  
> picked the names <sig:Signatures> and <sig:Signature> out of thin  
> air.  Though I still like these names (I do not see them as  
> potentially confusing as I noted above), these names should rather  
> be derived from properly developed ISO/IEC 11179 names.
>
> When the Security SC ends up deciding on the structure to use, we  
> should go through the appropriate naming exercise to determine the  
> names to use for the elements.  I don't have the time right now,  
> and I would be worried of wasting the time if the committee does  
> not agree with the proposal you've put forward and my comments above.
>
> . . . . . . . . . . . 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>