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

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

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