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 specification specifies the use of the UBL schemas in containing digital signatures. 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.
This signature extension schema finds and validates extension elements in the urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2 namespace. In this specification this namespace is bound to the sig: prefix, but any prefix or even the default namespace can be used in the XML instance.
The standardized UBL Signature Extension is identified using the URI urn:oasis:names:specification:ubl:profile:dsig:signature in the <ext:ExtensionURI> element.
The <ext:ExtensionContent> element always contains a single <sig:SignatureInformation> element as the top of the document's electronic signatures.
The <ext:ExtensionContent> element alternatively also allows any other non-signature namespace element in order not to disallow other extensions in the same document.
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. Such an address necessarily disqualifies the container of the digital signature so as to allow additional signatures to be added to the document without disturbing the calculations for those added earlier.
The following transformation element satisfies the requirement in a UBL extension and should be used where required in the XAdES content:
<Transform
Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
<XPath>
count(ancestor-or-self::sig:SignatureGroup |
here()/ancestor::sig:SignatureGroup[1]) >
count(ancestor-or-self::sig:SignatureGroup)
</XPath>
</Transform>
The xml/UBL-Invoice-2.0-Signed.xml sample document illustrates the embedding of three extensions in a single document, one of which is the signature extension. The example signature includes but one of the many formats of XAdES and its available options.
The UBL scaffolding for holding the XAdES element {http://www.w3.org/2000/09/xmldsig#}Signature is at a minimum the two children <ext:ExtensionURI> and <ext:ExtensionContent>:
<ext:UBLExtension> <ext:ExtensionURI >urn:oasis:names:specification:ubl:profile:dsig:signature</ext:ExtensionURI> <ext:ExtensionContent>
All signature information for the document is contained under the <sig:SignatureInformation> element.
In its simplest form where there is only a single group of signatures applicable to the document, the UBL document either has a single <cac:Signature> business object or none at all. Thus, there is no requirement to relate the business object to the embedded digital signature information as there can be but a single group of signatures. In this situation the remainder of the extension scaffolding is the single element <sig:SignatureGroup> which contains the XAdES information. A skeleton example is as follows:
<sig:SignatureInformation xmlns:sig=
"urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2">
<sig:SignatureGroup>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
...
</SignedInfo>
<SignatureValue>
...
</SignatureValue>
<KeyInfo>
...
</KeyInfo>
</Signature>
</sig:SignatureGroup>
</sig:SignatureInformation>
Where the UBL document has more than one <cac:Signature> business object, or there is only one and the user wishes to explicitly express the correlation between the business object and the embedded signature, the signature group is said to be "identified". Here the signature group's <cbc:ID> value corresponds to the signature business object's <cbc:ID> value. Where the user does not readily have an identifier to use, this specification reserves the identifier "urn:oasis:names:specification:ubl:signatures" for this purpose.
Where multiple identifiers are needed to correlate more than one business object to its corresponding embedded signature, and the user does not readily have an identifier to use, this specification reserves the identifier structured with a numeric suffix as in "urn:oasis:names:specification:ubl:signatures:nnn" for this purpose.
The example from the simple instance has a single identified signature group:
<sig:SignatureInformation xmlns:sig=
"urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2">
<sig:IdentifiedSignatureGroup>
<cbc:ID>urn:oasis:names:specification:ubl:signatures</cbc:ID>
<sig:SignatureGroup>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
...
</SignedInfo>
<SignatureValue>
...
</SignatureValue>
<KeyInfo>
...
</KeyInfo>
</Signature>
</sig:SignatureGroup>
</sig:IdentifiedSignatureGroup>
</sig:SignatureInformation>
The content of <sig:SignatureInformation> is an optional <sig:SignatureGroup> element, followed optionally by any number of <sig:IdentifiedSignatureGroup> elements, but cannot be empty of all such elements.
[XAdES] http://uri.etsi.org/01903/v1.2.2/ts_101903v010202p.pdf ETSI TS 101 903 V1.2.2 (2004-04)