Re: Sample instances

[Oriol Bausą Peris <oriol@invinet.org>]

El 14/08/2010, a las 14:32, G. Ken Holman escribió:

> At 2010-08-14 08:38 +0200, Oriol Bausà Peris wrote:
>> I am sorry, I forgot to attach the files in my last mail. Here come both samples. They of course do not include all the new ideas and identifiers proposed by Ken.
> 
> But it does lead me to a question:  how did you accomplish the embedding of the extension elements in any form at all?  I see the correct use of <ext:*> elements and the embedding of the <odsig:document-signatures> element, even though that element is missing the version attribute required by the schema but inadvertently missed in the Security SC document.
> 
> So this leads me to believe that you were able to somehow add those scaffolding elements yourself and then trigger the signature software to embed the actual <ds:Signature> element.  Is this true?  Are we, then, safe to continue with our own wrapper specification and not be obliged to use an existing ODF or OCF wrapper?  If so, this is good news.
> 

Yes, you are true. We are using the scaffolding  

<ext:UBLExtension>/<ext:UBLExtensions>
	<ext:UBLExtensionContent>
		<odsig:document-signatures> 

where the ds:Signature is inserted.

The sofware developed to sign UBL Documents in CODICE has  another major difference that maybe we could evaluate to add to the Security SC document, the XPATH expressions for the ds:Transform are thought to avoid signing the signature, but there is more than one choice. This could maybe overcome the issue with the here() function.

-  This one does not avoid other signatures being signed:  http://www.w3.org/2000/09/xmldsig#enveloped-signature

-   Avoids other signatures in the document being signed:

<ds:XPath xmlns:odsig=” urn:oasis:names:tc:opendocument:xmlns:digitalsignature:1.0”>
not(ancestor-or-self::odsig:document-signatures)
</ds:XPath>

-   Avoids other signatures in the document being signed:

<ds:XPath>not(ancestor-or-self::ds:Signature)</ds:XPath>

-  Avoids other signatures in the document being signed, there is only one  <odsig:document-signatures> in the document:

<ds:XPath>
count(ancestor-or-self::odsig:document-signatures |
here()/ancestor::odsig:document-signatures[1]) >
count(ancestor-or-self::odsig:document-signatures)
</ds:XPath>

> My revelation was that even if we *did* try to save effort by adopting a standardized wrapper such as ODF or OCF, a UBL instance cannot use that wrapper without embedding the extension scaffolding we require to allow the schemas to still validate an instance.  So this scaffolding means we can never use any off-the-shelf signature software unless it gives us the flexibility to specify the wrapper for the wrapper, so we might as well have our own wrapper and put in the features we need.
> 
> Can you share with us, Oriol, the effort it took to configure your software to include the extension schema scaffolding in the instance?

Well it is not really complex to add this scaffolding in the instance.

> 
>> As we were talking about when defining the spec, you'll see that there is no signature aggregate, as adding this ABIE makes the signature process very complex.
>> 
>> Regarding the CoO, I think we should clarify the use and scope of the signatures that are enveloped inside this document, maybe adding some special paragraph in the recommendation. And regarding the UBL ABIE Signature, my recommendation is not using it as it is unnecessary, can create inconsistencies with the actual signature, and generates some problems when signing the xml instance.
> 
> As Tim pointed out it could be used for alternate methods of specifying a signature, like referencing a PDF file.
> 
> So I think the security committee can *recommend* the use of cac:Signature in conjunction with sig:Signatures and ds:Signature, but not require it.  That way it provides additional information if available, but the UBL document is still digitally signed even if <cac:Signature> is not present, and the schemas stay as they are in PRD1 so that the scaffolding for <ds:Signature> is standardized.
> 

Absolutely agree.

> So based what I hope your answer will be, Oriol, the schemas might finally be complete.  We standardize the scaffolding for <ds:Signature> in the extension schema fragments of UBL's namespace (not OCF nor ODF).  And the Security SC revises their document regarding the recommended association between a <cac:Signature> element and the extension, not making it a requirement.  A community of users can then, seeing the recommendation, choose to adopt the recommendation as a requirement.  But whether a sender of a UBL document adopts that recommendation or not, all recipients of the document will still be able to verify the digital signature in <ds:Signature> with or without the supplemental documentation in <cac:Signature>.
> 
> Unless anyone objects, then, I'll proceed with the SGTG schema production for PRD1.
> 

I agree 

> Thank you for taking from your time to look at this on the weekend!  I hope to have something published by the end of today (my time).
> 
> . . . . . . . . . . . Ken
> 
> --
> XSLT/XQuery training:   after http://XMLPrague.cz 2011-03-28/04-01
> Vote for your XML training:   http://www.CraneSoftwrights.com/o/i/
> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
> 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
>