Re: [ubl-security] Re: Sample instances

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

I agree with the "scaffolding approach" and the solutions found.

Roberto, do you think that requirements like D.2/S.2 can be dealt with by using counter-signatures and/or additional document-wide signatures with specific Signer Roles? 
A SignerRole is defined in XAdES as Anytype and can store an i.e an URI or URN or whatever identifying the business role of the signer. 
The advantage to move here this type of information is that we can always add signatures and countersignatures adding this properties at signing time without breaking other signatures. If we still need to relate signature with parts of the UBL document I suggest to use this scaffolding in the UBL extension:
<ublsig:document-signatures>
	<ds:signature>…</ds:signature>
...
	<ublsig:IdentifiedSignature>
		<cac:ID>…<cac:ID>
		<ds:signature>…</ds:signature>
	</ublsig:IdentifiedSignature>
...
</ublsig:document-signatures>

I think a schema can be implemented with a sequence of choices so that inside a ublsig:document-signatures container could be found a sequence of <ds:signature> or <ublsig:IdentifiedSignature> in any order and quantity.
The <ublsig:IdentifiedSignature> element can refer to a specific section of the UBL document via the cac:ID if this is required to disambiguate the reference and, as most of the UBL documents have just the document-wise signature, in this case there is no need to do any preparation work, they will contain just the simple scaffolding we already defined:
<ublsig:document-signatures>
	<ds:signature>…</ds:signature>
	<ds:signature>…</ds:signature>
…
</ublsig:document-signatures>

For other documents it should be quite easy to add something like:

<ublsig:document-signatures>
	<ds:signature>…</ds:signature> <ds:signature>…</ds:signature> … (these are the document-wise signature(s) )
	<ublsig:IdentifiedSignature>
		<cac:ID>…<cac:ID> (ID of cac:CertificateOfOriginApplication when required)
		<ds:signature>…</ds:signature> <ds:signature>…</ds:signature> … 
	</ublsig:IdentifiedSignature>
	<ublsig:IdentifiedSignature>
		<cac:ID>…<cac:ID> (ID of cac:IssuerEndorsement when required)
		<ds:signature>…</ds:signature> <ds:signature>…</ds:signature> … 
	</ublsig:IdentifiedSignature>
	<ublsig:IdentifiedSignature>
		<cac:ID>…<cac:ID> (ID of cac:EmbassyEndorsement when required)
		<<ds:signature>…</ds:signature> <ds:signature>…</ds:signature> … 
	</ublsig:IdentifiedSignature>
	<ublsig:IdentifiedSignature>
		<cac:ID>…<cac:ID> (ID of cac:InsuranceEndorsement when required)
		<ds:signature>…</ds:signature> <ds:signature>…</ds:signature> … 
	</ublsig:IdentifiedSignature>
...
</ublsig:document-signatures>


For detached signatures I think it's better to avoid any scaffolding other than the standard <ocf:signatures>…</ocf:signatures> container to allow standard packaging. With detached signatures we do not solve all the possible issues but we still have an useful tool for packaging i.e. an invoice, its stylesheet(s), the signature(s) and whatever element we need for a human readable object ready to be archived long term.

Another useful signature field is the Commitment Type. This is an URI that can be defined by the user but it's better to stay with the types already defined in XAdES (and CAdES), i.e.:
• Proof of origin indicates that the signer recognizes to have created, approved and sent the signed data object. The URI for this commitment is http://uri.etsi.org/01903/v1.2.2#ProofOfOrigin.
• Proof of receipt indicates that signer recognizes to have received the content of the signed data object. The URI for this commitment is http://uri.etsi.org/01903/v1.2.2#ProofOfReceipt.
• Proof of delivery indicates that the TSP providing that indication has delivered a signed data object in a local store accessible to the recipient of the signed data object. The URI for this commitment is http://uri.etsi.org/01903/v1.2.2#ProofOfDelivery.
• Proof of sender indicates that the entity providing that indication has sent the signed data object (but not necessarily created it). The URI for this commitment is http://uri.etsi.org/01903/v1.2.2#ProofOfSender.
• Proof of approval indicates that the signer has approved the content of the signed data object. The URI for this commitment is http://uri.etsi.org/01903/v1.2.2#ProofOfApproval.
• Proof of creation indicates that the signer has created the signed data object (but not necessarily approved, nor sent it). The URI for this commitment is http://uri.etsi.org/01903/v1.2.2#ProofOfCreation.

Staying aligned with these definitions allow us to be compatible with CEFACT security project rules. About this point, we can explicitly recommend to comply with the CEFACT recommendation as soon as it is published (this can be done later during the public review of our document, when the CEFACT one will be officially published).

About XAdES itself, it is under standardization in ISO/TC154 as the format for long term signatures for business documents, so it is not limited to Europe. The fact that XAdES, CAdES and PAdES are the only technical implementation in the CEFACT recommendation, even if in a not normative annex, is another reason to sustain its use.

Andrea


Il giorno 14/ago/2010, alle ore 17.23, G. Ken Holman ha scritto:

> At 2010-08-14 16:25 +0200, Oriol Bausà Peris wrote:
>> El 14/08/2010, a las 14:32, G. Ken Holman escribió:
>> > 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.
> 
> Right ... but my point was that you had to add the scaffolding and it wasn't a requirement of the signature software to add it for you, which means your software doesn't care what the scaffolding is, which means we can go with our own <sig:signatures> wrapper instead of the <odsig:document-signatures> wrapper.
> 
> This allows us to have the optional <cbc:ID> child, which is an example of using a UBL standard BBIE in the extension.
> 
> This will be our first standardized extension and an example for other people to follow.
> 
>> 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 understanding of the above is that the expression is true when the node returned by the here() function is not the current XPath node or one of its ancestors.  If the here() function returns the current XPath node or one of its ancestors, then the count of the union of the here() node and its ancestors is the same as the count of the current XPath node and the ancestors.  If the count of nodes is greater (it can never be less because a union never takes away nodes) then the here() function is not the current XPath node or one of its ancestors so it adds to the count.
> 
>> > 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.
> 
> Okay, I take it it was easy, but do you tell the software what scaffolding to add or do you add a placebo element in your instance and then have the software replace the placebo with the actual signature?  I am considering adapting the Apache digital signature software into a tool and I felt the latter would be the most general approach for such a utility:  feed the utility with an instance with an empty <ds:Signature> element (thus providing all of the arbitrary and necessary scaffolding) and the utility replaces the empty <ds:Signature> with a populated version signing everything outside of the arbitrary parent element of the empty <ds:Signature>.  The utility is then agnostic to the XML vocabulary being used, thus working for UBL, ETSI, OCF or ODF conventions.
> 
> But writing that utility will have to wait until I've done my other 2.1 PRD1 responsibilities.
> 
>> > Unless anyone objects, then, I'll proceed with the SGTG schema production for PRD1.
>> >
>> 
>> I agree
> 
> Thank you again, Oriol and Roberto, for contributing to the discussion today.
> 
> . . . . . . . . . . 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
> 
> 
> ---------------------------------------------------------------------
> 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
>