Table of Contents
In addition to the document constraints reflecting the business objects of the spreadsheets, the first standardized UBL extension is included in UBL 2.1 in support of the XAdES [XAdES] specification from ETSI.
This extension has been modeled as an example to follow when designing and writing other custom extensions.
This specification specifies the use of the UBL schemas in containing all of the digital signatures for a UBL document in a single instance of a UBL extension. A detailed analysis and description of the digital signature methodology is found in the UBL Security Subcommittee document titled "UBL Electronic Signature Profile Version 1.0".
The UBL-ExtensionContentDataType-2.1.xsd schema module engages the UBL signature extension in validation. Due to limitations of W3C Schema validation semantics, when there are many extensions in an instance a set of UBL schemas can only validate one of the extension namespaces at a time. Following the example given by this signature extension, one creates another directory of schemas replacing this signature extension with the other desired extension schema expression. A different set of parallel schemas will be needed for each extension namespace in use. A complete validation process then involves validating the document with the document schema in each of the parallel directories, thus covering each of the expected extensions.
As is true for the document schemas and common library, this extension is modeled with three namespaces: one for the apex element (a corollary to the document schema), one for new aggregate constructs (a corollary to the common aggregate schema) and one for new basic constructs (a corollary to the common basic schema).
It behooves the designers of an extension to follow this approach if they are considering proffering their new constructs to the UBL Technical Committee for consideration. Having already followed the UBL design for aggregate and basic constructs, the new constructs are properly structured to be included in a future version of the common library.
This signature extension defines and uses the urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2 namespace for the apex element, the urn:oasis:names:specification:ubl:schema:xsd:SignatureAggregateComponents-2 namespace for new aggregate elements and the urn:oasis:names:specification:ubl:schema:xsd:SignatureBasicComponents-2 namespace for new basic elements. The W3C digital signature [xmldsig]http://www.w3.org/2000/09/xmldsig# standard namespace is also used in this extension. In this specification these namespaces are bound, respectively, to the sig:, sac:, sbc: and ds: prefixes, but any prefix or even the default namespace can be used for any of these in an XML instance.
Where possible existing common library aggregate and basic constructs should be used in an extension, not duplicating an existing semantic when one is needed in a new context. However, a common library aggregate construct should only be used when the entire aggregate and all of its descendants are applicable in the extension context without any changes. If any items must be removed, then a new extension aggregate with a new local name should be used. If all the constructs are applicable but some items need to be added, then a new extension aggregate with the same local name as the common library should be used and the common library structure should be copied with the new constructs inserted. This guides the UBL Technical Committee in incorporating the new constructs in the corresponding aggregate in a future version of the common library.
This standardized UBL Signature Extension is distinguished from other extensions and identified using the URI urn:oasis:names:specification:ubl:profile:dsig:signature in the <ext:ExtensionURI> element.
The UBL-ExtensionContentDataType-2.1.xsd module is the distribution schema module that is replaced with support of a particular extension structure.
The distribution version of this module supports this specification for UBL digital signatures declaring the <ext:ExtensionContent> element always contains a single <sig:UBLDocumentSignatures> element as the apex of all the document's electronic signatures.
The <ext:ExtensionContent> element alternatively also allows any other non-signature namespace apex element in order not to disallow other extensions in the same document.
To support an alternative extension structure this schema module is replaced with a module modeling a similar apex element and an element of a non-apex element namespace. A custom extension schema would, therefore, have to declare similar constructs to those found in the signature extension.
The signature extension structure exists to contain one or more W3C standard digital schema constructs. The UBL scaffolding for this extension starts with the <ext:UBLExtension> element with two children: <ext:ExtensionURI> (for extension distinction and identification) and <ext:ExtensionContent> (for containing the extension information):
<ext:UBLExtension> <ext:ExtensionURI >urn:oasis:names:specification:ubl:profile:dsig:signature</ext:ExtensionURI> <ext:ExtensionContent>
All signature information for the document is then contained under the <sig:UBLDocumentSignatures> apex element, a single mandatory child of <ext:ExtensionContent>:
<ext:ExtensionContent> <sig:UBLDocumentSignatures>
Every signature added to the extension is done isolated under a separate <sac:SignatureInformation> aggregate element. As many of these aggregates can be in the extension as is needed, each one containing the information for a single digital extension.
Any of these aggregates can be optionally identified for referencing purposes using the common library <cbc:ID> element, but this is not obligatory. The identifier used can be any value, but for convenience the URI of a URN beginning with "urn:oasis:names:specification:ubl:signatures:" and ending with a number value is reserved for this purpose for UBL users. An example is "urn:oasis:names:specification:ubl:signatures:3". As with all identifiers each should be unique across all identifier values.
Such an identifier may be useful in workflow scenarios where a particular signature needs to be identified external to the document.
Any of these aggregates can optionally make reference to an existing <cac:Signature> business object in the same UBL document, but this is not obligatory. When needed the <sbc:ReferencedSignatureID> basic element is used to point to the <cbc:ID> identifier value of the referenced <cac:Signature>. The identifier used can be any value, but for convenience the URI of a URN beginning with "urn:oasis:names:specification:ubl:signatures:" and ending with the local name of the parent of the signature business object and optionally followed with a colon and number, as in "urn:oasis:names:specification:ubl:signatures:IssuerEndorsement", is reserved for this purpose for UBL users. As with all identifier references, the referenced identifier should exist and should be unique across all such identifier values.
A skeleton example of a single signature is as follows:
<ext:ExtensionContent>
<sig:UBLDocumentSignatures xmlns:sig=
"urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2"
xmlns:sac=
"urn:oasis:names:specification:ubl:schema:xsd:SignatureAggregateComponents-2"
xmlns:sbc=
"urn:oasis:names:specification:ubl:schema:xsd:SignatureBasicComponents-2">
<sac:SignatureInformation>
<cbc:ID>urn:oasis:names:specification:ubl:signatures:1</cbc:ID>
<sbc:ReferencedSignatureID>MyParty</sbc:ReferencedSignatureID>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
...
</SignedInfo>
<SignatureValue>
...
</SignatureValue>
<KeyInfo>
...
</KeyInfo>
</Signature>
</sac:SignatureInformation>
</sig:UBLDocumentSignatures>
</ext:ExtensionContent>
The document can have any number of <sac:SignatureInformation> elements, each containing at most one <ds:Signature> element.
An element with an absent <ds:Signature> could be used, for example, as a placeholder for workflow software to identify the placement for a signature to be added.
A requirement when using XAdES is to express in XPath that address that qualifies all nodes in an XML document included in the calculation of the digital signature hash. For a signature added to a document to remain valid none of the information can change nor can any information be added or removed from that portion of the document included in the hash calculation.
There are two such transformation expressions that should be used in the UBL signature extension; choose the appropriate one to meet the objectives of the signature being added to the document. Adding non-signature information to the UBL document will invalidate all signatures already in the extension. The choice to make is in regard to the support of adding additional signatures after the adding the signature with the transformation expression.
The following transformation element in a digital signature flexibly prevents the signature being invalidated by the subsequent addition of other signatures within the extension:
<Transform
Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
<XPath xmlns:sig=
"urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2">
count(ancestor-or-self::sig:UBLDocumentSignatures |
here()/ancestor::sig:UBLDocumentSignatures[1]) >
count(ancestor-or-self::sig:UBLDocumentSignatures)
</XPath>
</Transform>
The following transformation element in a digital signature is inflexible and thus would be considered a "final" signature to be added to the document. Such a signature will be invalidated by the subsequent addition of other signatures to the document:
<Transform
Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
<XPath xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
count(ancestor-or-self::ds:Signature |
here()/ancestor::ds:Signature[1]) >
count(ancestor-or-self::ds:Signature)
</XPath>
</Transform>
[XAdES] http://uri.etsi.org/01903/v1.2.2/ts_101903v010202p.pdf ETSI TS 101 903 V1.2.2 (2004-04)
[xmldsig] http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ XML-Signature Syntax and Processing (2002-02)