Andrea Caccia wrote:Reference to the ASiC standard in clause 4 (it should be published in1-2 days by ETSI, no URL is yet available)
I'm using the URL for your Work Item page as a stand-in until you send
the URL for the published spec.should be similar the reference to XAdES:[ASiC] Associated Signature Containers (ASIC). ETSI TS 102 918 V1.1.1[http://uri.etsi.org/...] 2011-04
Following your last set of comments, I put both ASiC and ESI in the same
biblio reference:
<bibliomixed id="b_asic">
<abbrev>ASiC</abbrev><citetitle>
<ulink
url="http://webapp.etsi.org/WorkProgram/Report_WorkItem.asp?WKI_ID=31946"
>Electronic Signatures and Infrastructures (ESI); Associated
Signature Containers (ASIC)</ulink>
</citetitle></bibliomixed>
Assuming that you want to keep this form, I'm interpreting your comment
above as meaning that you want this:
<bibliomixed id="b_asic">
<abbrev>ASiC</abbrev><citetitle>
<ulink
url="http://webapp.etsi.org/WorkProgram/Report_WorkItem.asp?WKI_ID=31946"
>Electronic Signatures and Infrastructures (ESI); Associated
Signature Containers (ASIC). ETSI TS 102 918 V1.1.1</ulink>
</citetitle></bibliomixed>
See the result in the attached PDF. I found a number of minor formatting
errors in this section as well (most of them probably my fault); please
review both References sections to make sure everything is correct.Them near the end of clause 7 please change the text: "The simple ASiCformat (ASiC-S) can be created" to: "The simple [ASiC] container(ASiC-S) can be created" (with [ASiC] pointing to its reference inclause 4)
Done; see generated PDF.I noted also that I used "ASiC-S" without updating 2.1 terms and definitions. A new term should then be added as follows:ASiC-S (Associated Signature Container - Simple form)A standard container that associates a single data object with one or more detached signature(s) that applies to it [ASiC]This should help the reader to understand the text in clause 7.
See generated PDF; is this OK?
Jon
<cd11-UBL-DSig-1.0.pdf><?xml version="1.0" encoding="UTF-8"?>
Committee Draft 11
24 April 2011
- Specification URIs:
- This Version:
- http://docs.oasis-open.org/ubl/cd11-UBL-DSig-1.0/UBL-DSig-1.0.html
http://docs.oasis-open.org/ubl/cd11-UBL-DSig-1.0/UBL-DSig-1.0.pdf
http://docs.oasis-open.org/ubl/cd11-UBL-DSig-1.0/UBL-DSig-1.0.xml (Authoritative)
- Previous Version:
- N/A
- Technical Committee:
- OASIS Universal Business Language Security SC
- Chairs:
- Andrea Caccia <andrea.caccia@studiocaccia.com>
Julián Inza <julian.inza@albalia.com>
- Editors:
- Oriol Bausà Peris <oriol@invinet.org>
Andrea Caccia <andrea.caccia@studiocaccia.com>
Roberto Cisternino <roberto@javest.com>
G. Ken Holman <gkholman@CraneSoftwrights.com>
Julián Inza <julian.inza@albalia.com>
- Abstract:
This specification defines two profiles for digitally signing Universal Business Language (UBL) 2.x documents and a standard digital signature extension for use with the enveloped profile.
The profiles are based on IETF/W3C XML Digital Signatures, with specific provisions to use XAdES extensions when the electronic signing of UBL documents addresses special advanced legal and technical requirements.
- Status:
This document was last revised or approved by the UBL TC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.
Technical Committee members should send comments on this specification to the Subcommittee's email list. Others should send comments to the Subcommittee by using the "Send A Comment" button on the Subcommittee's web page at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl-security.
For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page at http://www.oasis-open.org/committees/ubl/ipr.php.
Notices
Copyright © OASIS® Open 2011. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.
The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.
Table of Contents
- 1. Introduction (Non-Normative)
- 2. Terminology
- 3. Normative References
- 4. Non-Normative References
- 5. Referenced Namespaces
- 6. XML Digital Signatures
- 7. Profiles for UBL Digital Signatures
- 8. Conformance
Appendixes
There are certain circumstances in which it becomes necessary to electronically sign UBL documents. This can be the case when creating orders or invoices. In some countries, digitally signing electronic invoices is required by law.
UBL has an ABIE to define signatures and a number of ASBIEs to use such signatures in a document. (See current UBL documentation for more regarding these terms.) There are a number of standard initiatives in the electronic signature area that are being adopted or recommended by different organizations or bodies. This specification standardizes the use of the XML Signature Specification [XMLDSig] in and for UBL documents and recommends their association with the UBL BIEs.
Note
The implementation of the extension used in the "enveloped" profile described below also serves as a model of a typical UBL extension. Those wishing to create their own UBL extension can mimic the schema and namespace structures used here.
[XMLDSig] is a general framework for digitally signing XML documents. ETSI TS 101 903, also known as [XAdES], is an XML electronic signature standard that can be used to create different XML Advanced Electronic Signatures. XAdES extends XMLDSig for use with advanced and qualified electronic signatures as specified in European Union Directive [1999/93/EC]. Use of XAdES and the concept of Advanced Electronic Signature is not limited to Europe, as it is being adopted by many countries outside the EU, and, at the time of publication of this specification, it is undergoing standardization in ISO TC 154 as ISO/CD 14533-2.
One important benefit of XAdES is that it allows the addition of information and timestamps that extend the validity of a signature beyond the expiration or revocation of the electronic certificates involved in signature verification or the obsolescence of the underlying cryptographic keys and algorithms. By extending XMLDSig with additional embedded syntax and processing, XAdES satisfies the European Commission Directive on a Community Framework for Electronic Signatures as well as other use cases requiring long-term preservation of signed documents. XAdES contains several modules that permit various levels of security, such as non-repudiation with timestamps and long-term signature verification.
The work of standardizing electronic signatures was supported by the European Commission and assigned to the Information and Communication Technologies Standards Board (ICTSB), a round table of most European IT standards bodies and some international standards bodies such as the IETF and W3C.
This UBL Digital Signature Profiles specification defines two profiles that represent two approaches to signing UBL documents: enveloped and detached. Each of these approaches uses XMLDSig in a way that may or may not include XAdES features. In other words, the mechanisms implemented here can be used not only to implement XAdES in these two ways but also to implement other signature technologies based on XMLDSig as well.
Using UBL Digital Signature Profiles one can conform to, for example, the UN/CEFACT Signed Digital Evidence Interoperability Recommendation [UN/CEFACT Rec. 37]. [To date, this recommendation has not been published by UN/CEFACT.]
- ASiC-S
Associated Signature Container (simple form). A standard container that associates a single data object with one or more detached signature(s) that apply to it. See [ASiC].
- Digital Signature
A value generated from the application of a private key to a message via a cryptographic algorithm such that it has the properties of integrity and message authentication and/or signer authentication. A signature may be (non-exclusively) described as detached, enveloping, or enveloped ([XMLDSig], with modifications).
- Transform
The processing of data from its source to its derived form. Typical transforms include XML Canonicalization [XML C14N] and XSLT [XSLT 2.0].
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
- ABIE
Aggregate Business Information Entity
- AdES
Advanced Electronic Signature
- ASBIE
Association Business Information Entity
- BBIE
Basic Business Information Entity
- BIE
Business Information Entity
- C14N
Canonicalization
- DSig
Digital Signature
- QC
Qualified Certificate
- QS
Qualified Signature
- XAdES
XML Advanced Electronic Signatures [XAdES]
- XML
Extensible Markup Language
- XMLDSig
XML Digital Signature [XMLDSig]
- XPath
XML Path Language (an XML data model and addressing language) [XPath 2.0]
- XSLT
Extensible Stylesheet Language Transformations (a transformation language) [XSLT 2.0]
[XML C14N] John Boyer, Canonical XML Version 1.0, 15 March 2001.
[UN/CEFACT Rec. 37] Signed Digital Evidence Interoperability Recommendation, 27 September 2010.
[XPath 2.0] Anders Berglund, et al., XML Path Language (XPath) Version 2.0, 23 January 2007.
[XPointer] Steven DeRose, et al., XML Pointer Language (XPointer) Version 1.0 Working Draft, 16 August 2002.
[XSLT 2.0] Michael Kay, XSL Transformations (XSLT) Version 2.0, 2007-01-23.
The table below lists the namespaces referenced in this specification. The prefixes on the left are only documentary conventions; their choice is not constrained by XML.
Table 1. Referenced Namespaces
Prefix Namespace Reference dshttp://www.w3.org/2000/09/xmldsig#[XMLDSig] xadeshttp://uri.etsi.org/01903/v1.3.2#[XAdES] exturn:oasis:names:specification:ubl:schema: xsd:CommonExtensionComponents-2UBL extension namespace sigurn:oasis:names:specification:ubl:schema: xsd:CommonSignatureComponents-2UBL signature extension apex namespace sacurn:oasis:names:specification:ubl:schema: xsd:SignatureAggregateComponents-2UBL signature extension aggregate namespace sbcurn:oasis:names:specification:ubl:schema: xsd:SignatureBasicComponents-2UBL signature extension basic namespace Digital signatures, when appropriate rules and functions are used, can support the following properties for a document:
Integrity: the document has not been modified since it was signed.
Authenticity: the identity of the party creating the signature that applies to the document is certified.
Non-repudiation (or content commitment): the document signer cannot deny its involvement in creating and/or approving the document (depending on the context and signer role).
Anteriority: associating a time-stamp to the signature, a proof that the signature (and therefore the signed document) existed before a certain point in time.
[XMLDSig] defines XML Signature processing rules and syntax to provide integrity and message authentication and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere. [RFC3161] specifies a standard format for time-stamping that can be used with XMLDSig and XAdES.
The [1999/93/EC] directive defines the following technology-neutral requirements that an electronic signature must meet to be considered an Advanced Electronic Signature (AdES) and have legal validity:
it is uniquely linked to the signatory;
it is capable of identifying the signatory;
it is created using means that the signatory can maintain under his sole control; and
it is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable.
The Qualified Signature (QS) is also defined as an AdES based on Qualified Certificates (QC) and Secure Signature Creation Devices for signing operations. In Europe, QS is equivalent to handwritten signature provided it is based on a QC issued by an accredited Certificate Service Provider. These references are provided only for informational use and refer to the framework defined in [1999/93/EC].
XAdES extends XMLDSig to support AdES, but its adoption is not limited to an EU context, as similar requirements are in place in other countries. The introduction to [XAdES] reads, in part,
The XML advanced electronic signatures defined in the present document will be built by incorporating to the XML signatures as defined in XMLDSIG one new
ds:ObjectXML element containing the additional qualifying information.That XAdES is completely embedded in XMLDSig ensures that the UBL profiles for XMLDSig are sufficient to support XAdES. These profiles also support other existing or future extensions of XMLDSig that are completely embedded in XMLDSig syntax. These other possible UBL digital signature profiles may or may not use the XAdES extensions to XMLDSig.
It is important to note that XAdES and XMLDSig define digital signature processing rules and syntax but do not cover the implementation of security measures required for an AdES, which are out of scope for this document.
Implementation may depend on local regulations in place and specific provisions set by the authority issuing the certificates supporting the signature. The implementer has to determine the set of requirements that apply to the specific context of use and determine accordingly the suitability of the standards and the specific profiles to be used. XAdES can help in fulfilling legal requirements, but this is not just a matter of correctly applying a technical standard. Users are advised to examine the regulations applicable to their specific context of use.
An XML signature may be (non-exclusively) described (per XMLDSig and XAdES) as detached, enveloping, or enveloped.
Detached. The signature applies to content that is external to the
<ds:Signature>element and can be identified via a URI or transform. Consequently, the signature is "detached" from the content it signs. This definition typically applies to separate data objects, but it also includes the case where the<ds:Signature>and signed data object are sibling elements residing within the same XML document.Enveloping. The signature applies to content found within a
<ds:Object>element of the signature itself. The<ds:Object>(or its content) is identified via a<ds:Reference>(using a URI fragment identifier or transform).Enveloped. The signature applies to the XML content that contains
<ds:Signature>as an element. Implementations of enveloped signature(s) must take care not to include the signature in the calculation of the signature value.This specification defines two profiles for signing a UBL document: enveloped and detached.
A compliant implementation of XAdES guarantees wide acceptance in implementing legal regulations, such as EC Directive [1999/93/EC], and supports best practices in eInvoicing, eProcurement, and eBusiness in general as set forth by relevant standard bodies such as CEN [CWA15580] and [CWA15579].
The UBL implementation of XAdES provides the following additional properties:
A signed UBL document will be processed correctly by any compliant UBL software (including UBL software that is not XMLDSig/XAdES aware) and by any compliant XMLDSig/XAdES verification software (including software that is not UBL aware)
No change is required for currently defined UBL or XMLDSig/XAdES syntaxes
The extension mechanism specified here supports any XMLDSig/XAdES form, leaving to the implementer the choice of the most appropriate one according to the specific legal framework or application context.
XAdES defines a set of forms that extends XMLDSig and allows adding to the signature some validation data.
The two basic forms are:
XAdES-BES, which satisfies the minimum requirements for AdES; and
XAdES-EPES, which builds on XAdES-BES to include a security policy identifier that specifies the rules followed to validate the signature.
A conformant XAdES signature generation and verification implementation supports at least XAdES-BES or XAdES-EPES.
The other forms can be built by the signature generator or the signature verifier by extending one of the two basic forms. They are:
XAdES-T, where a timestamp is added to enforce non-repudiation and as a proof of anteriority. This envelope allows ascertaining the validity of a signature in case the signer certificate is later revoked;
XAdES-C, which adds to the signed document a complete reference to verification data (certificates and revocation lists) to support long-term signature verification;
XAdES-X, which adds timestamps to XAdES-C references to protect against future compromise of certificates;
XAdES-X-L, which is similar to XADES-X but adds real certificates and revocation lists instead of just references; and
XAdES-A, which adds timestamps (periodically, as required) to extend the validity period for long-term storage, taking into account a possible weakening of the algorithms used to sign the document and related certificates during the storage period.
This specification does not recommend any specific XAdES form for a UBL document, as this choice depends on the specific context of use, agreements between the parties, and local regulations.
This document specifies two profiles for use in digitally signing UBL documents:
Enveloped Signature Profile: One or more signatures are added to the UBL document inside a single identifiable and dedicated UBL Extension. Other UBL extensions MAY be present provided they have different identifiers so that they can be distinguished from the one that contains the document signature(s). This profile is defined such that UBL content processing can be separated from electronic signature processing, both on the issuing side and on the receiving side, and specialized applications can be devoted to each function. The UBL application doesn't need to be electronic signature aware, and the electronic signature application does not need to be involved in the management of the UBL syntax. A signature business object in the UBL document may reference a particular electronic signature in the extension.
Detached Signature Profile: The signature is outside the UBL document content in another information resource. Some mechanism has to be defined by the implementer to send or make available the signature to the recipient. This method of signing may be identified in the UBL document. This approach can be useful to avoid or minimize any kind of modification to the UBL document and is compatible with other signature methods not explicitly referenced by this profile.
The main requirements to be addressed when choosing a specific signature profile can be divided into the following categories:
Legal requirements. In some countries a digital signature is required on electronic invoices. It can also be compulsory in electronic procurement, especially in a cross border context, to have digital signature on the key document exchanged, e.g., on orders. Another important legal requirement is long-term document preservation, for a storage period that in general is specific in each country and can span many years. The requirement to guarantee the integrity and authenticity of all fiscally relevant archived documents, as specified, for example, by [CWA15580] for electronic invoices, can be met with digital signatures when proper XAdES forms are used.
Business requirements. A digital signature can reduce the risks associated with a business transaction (e.g., non-repudiation of a commercial order, proof-of-origin and integrity of an invoice) and its use can be provided for in the interchange agreement between parties. The choice of the signature format and its application is a key element for interoperability.
Process requirements.The presence of the digital signature should not add any specific constraints on UBL document content processing. If the signed document remains a valid UBL document, the signature can be verified at any stage of the process: it should be possible to validate a signed document at any time "as is" by UBL and XAdES verifiers.
The two profiles for adding one or more digital signatures to a UBL document are based on [XMLDSig]. These profiles and their associated methods decouple the UBL document to be signed from any specificity in the digital signature standard adopted within XMLDSig. The XAdES standard is an example of a standard use of XMLDSig. UBL users may use any standard built on XMLDSig or simply use XMLDSig as it stands without any extensions.
Managing XML signatures inside of a UBL document is described in Section 7.1, “Enveloped XML Signatures in UBL Documents”. Managing XML signatures outside of a UBL document is described in Section 7.2, “Detached XML Signatures for UBL Documents”.
Both profiles support co-signatures, i.e., a UBL document can be independently cosigned by multiple signers in any order and time. Both profiles support countersignatures, i.e., a UBL document can have its signatures signed by another signature. The enveloped signature profile supports a final signature, i.e., a UBL document once signed with a final signature cannot have any other signature added without invalidating the final signature.
The choice of the most suitable profile should take into account mainly the specific document processing and delivery infrastructure.
The main advantage of the enveloped profile is that the signature(s) are embedded in the UBL document (which syntactically remains a valid UBL document). This means that the transport of the signatures is guaranteed by the UBL document delivery infrastructure.
The detached signature profile has a simpler preparation phase and signature procedure, but specific means to send or make available the signature(s) to the recipient have to be implemented. A standard container like [ODFP] can be used to associate the UBL document with detached advanced electronic signature(s) that apply to it. The simple [ASiC] container (ASiC-S) can be created at a later time than signature generation so that it contains a UBL document and one or more detached signatures that apply to it.
Archiving of UBL documents also can be an important issue to consider, as document preservation has specific requirements.
This profile supports one or more signatures to be applied to a UBL document and embedded in the UBL document itself inside a dedicated extension. This profile can be used with all UBL documents under their respective
<ext:UBLExtensions>extension point.Note
The
xml/UBL-Invoice-2.0-Signed.xmlsample document in the UBL 2.1 distribution illustrates the embedding of three extensions in a single document, one of which is the signature extension.The user MAY choose to indicate in a
<cac:Signature>element that the signature details are found in the signature extension. The URIurn:oasis:names:specification:ubl:dsig:envelopedis reserved as a value for<cbc:SignatureMethod>to signal this. The URIurn:oasis:names:specification:ubl:dsig:enveloped:xadesMAY be used as a value for<cbc:SignatureMethod>to signal when XAdES is in use. Additionally, the user MAY include a<cbc:ID>child of<cac:Signature>for referencing purposes from the enveloped signature. The identifier used can be any value, but for convenience the URI of a URN beginning withurn:oasis:names:specification:ubl:signature:and ending with the local name of the parent of the signature business object and optionally followed with a colon and number, as in theurn:oasis:names:specification:ubl:signature:IssuerEndorsementexample, is reserved for this purpose for UBL users. As with all identifier references, the referenced identifier SHOULD exist and be unique across all such identifier values. An example is as follows:<cac:Signature> <cbc:ID>urn:oasis:names:specification:ubl:signature:Invoice</cbc:ID> <cbc:SignatureMethod >urn:oasis:names:specification:ubl:dsig:enveloped</cbc:SignatureMethod> <cac:SignatoryParty> <cac:PartyIdentification> <cbc:ID>MyParty</cbc:ID> </cac:PartyIdentification> </cac:SignatoryParty> </cac:Signature>There are two distinctive levels of syntax present: UBL-specified scaffolding under the extension point used to contain the signature information and IETF/W3C-specified information for each digital signature.
One or more signature extensions in a given document MAY each contain one or more sets of signature information. The standard UBL-specified scaffolding for a given signature extension begins with the
<ext:UBLExtension>element. The extension's role as a UBL signature extension is indicated with a child<ext:ExtensionURI>element with theurn:oasis:names:specification:ubl:dsig:envelopedvalue. Theurn:oasis:names:specification:ubl:dsig:enveloped:xadesvalue MAY be used to indicate the use of XAdES in the extension. Other extension metadata elements defined in UBL are allowed to be included for the convenience of users without changing the meaning or use of the extension.All uses of the optional
<cbc:ID>metadata SHOULD be unique so that each extension can be uniquely identified. For the convenience of users, a URI with the URN beginning withurn:oasis:names:specification:ubl:signature:and ending with a number value is reserved for this purpose for UBL users, and MAY be used. The valueurn:oasis:names:specification:ubl:signature:3is a suitable example.The mandatory
<ext:ExtensionContent>element is the extension scaffolding that contains the UBL signature scaffolding. The apex element of the UBL signature information is<sig:UBLDocumentSignatures>. Note that three namespaces are used for signature information, in parallel with the UBL design of having a document namespace, aggregate namespace and basic namespace. The apex element is in theurn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2namespace, a parallel to a UBL document namespace. Signature-related aggregate entities are in theurn:oasis:names:specification:ubl:schema:xsd:SignatureAggregateComponents-2namespace. Signature-related basic entities are in theurn:oasis:names:specification:ubl:schema:xsd:SignatureBasicComponents-2namespace. Accordingly, there are three W3C Schema fragments in the distribution accommodating these three namespaces.Note
Creators of other UBL extensions using this one as a model should review the UBL specification documentation for guidelines regarding this schema design pattern.
In each extension with signature information, the
<sig:UBLDocumentSignatures>apex element contains one or more individual<sac:SignatureInformation>aggregates. One aggregate is used to contain the information related to a single IETF/W3C digital signature.An aggregate MAY be identified for referencing purposes using the common library
<cbc:ID>element. Such an identifier MAY be used in scenarios where a particular signature needs to be identified external to the document, e.g. in workflow applications. The identifier used can be any value, but for convenience a URI consisting of a URN beginning withurn:oasis:names:specification:ubl:signature:and ending with a number value is reserved for this purpose for UBL users. An example isurn:oasis:names:specification:ubl:signature:3. As with all identifiers, each SHOULD be unique across all identifier values.An aggregate MAY make reference to an existing
<cac:Signature>business object in the same UBL document. 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 a URI consisting of a URN beginning withurn:oasis:names:specification:ubl:signature:and ending with the local name of the parent of the signature business object and optionally followed with a colon and number, as in theurn:oasis:names:specification:ubl:signature:IssuerEndorsementexample, is reserved for this purpose for UBL users. As with all identifier references, the referenced identifier SHOULD exist and be unique across all such identifier values.A single
<ds:Signature>element is a child of the aggregate. It MAY be absent from the document, thus supporting workflow scenarios where the element is added by a subsequent process after the UBL scaffolding is added by an earlier process. However, the signature information is semantically incomplete without the IETF/W3C-defined element. To support countersignatures countersigning this signature, either this element or its<ds:SignatureValue>child element MUST use theId=attribute with a value unique from other attributes of schema typeIDin the instance.A skeleton example of a single signature corresponding to the example
<cac:Signature>above 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:signature:1</cbc:ID> <sbc:ReferencedSignatureID >urn:oasis:names:specification:ubl:signature:Invoice</sbc:ReferencedSignatureID> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id=...> <ds:SignedInfo> ... <ds:Reference URI=...> ... <ds:Transform> ... </ds:Transform> ... </ds:Reference> </ds:SignedInfo> <ds:SignatureValue Id=...> ... </ds:SignatureValue> <ds:KeyInfo> ... </ds:KeyInfo> <ds:Object> ... </ds:Object> </ds:Signature> </sac:SignatureInformation> </sig:UBLDocumentSignatures> </ext:ExtensionContent>Note
The XAdES specification contains all qualifying XAdES information in a single
<ds:Object>element located as shown above.Note
A document with multiple
<sac:SignatureInformation>elements is simply a document that is co-signed. By the appropriate use of the<ds:Reference>element, all such signatures are signing the content of the document but not each other. A countersigning document signature, on the other hand, signs signatures already present in the document at the time it is countersigned. A digital countersignature<ds:Signature>includes additional<ds:Reference>elements, each pointing to either the<ds:Signature>element being signed or its respective<ds:SignatureValue>element.Note
The XAdES specification supports an alternative countersignature approach where a
<ds:Signature>element pointing to the countersigned signature's<ds:SignatureValue>is embedded in the<ds:Object>of the countersigning signature. The inclusion of an alternative method in this specification does not prohibit this approach.The content to be signed is indicated in the
URI=attribute of<ds:Reference>. Using the empty string indicates that the entire document (i.e., the enveloping UBL instance) is what is being signed:<ds:Reference URI="">A requirement when using digital signatures is to express in XPath that address that qualifies all nodes in the referenced content to be 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.
One of two such transformation expressions 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 in either case; when adding more signatures, the behaviour depends on the transformation expression used.
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>Multiple separate items of extra-document content (e.g., attachments) or embedded IETF/W3C signature content MAY be included in the signature by adding sibling
<ds:Reference>elements with otherURI=attribute values. For example, to countersign another signature in the same UBL document, make a local reference to that signature's unique identifier as in:<ds:Reference URI="#{Id attribute of ds:Signature}">To sign only a portion of a UBL document, an appropriate [XPointer] address for
URI=SHOULD be used because UBL business object elements do not have attributes of type ID. This requires XPointer awareness on the part of the digital signature tools being used.This profile supports the application to a UBL document of one or more signatures located outside of the document itself in some other resource.
It is important to note that externally signing a UBL document with a detached signature imposes no requirements on the UBL document itself. Such a signature, in any kind of signature container, can digitally sign the content of a UBL document regardless of whether this is reflected in the document.
If a user knows the document will have a detached conformant IETF/W3C XML digital signature, the user MAY choose to signal in their UBL document that it is so signed. The URI value
urn:oasis:names:specification:ubl:dsig:detachedis reserved to indicate that the detached signature is an IETF/W3C XML digital signature. The URIurn:oasis:names:specification:ubl:dsig:detached:xadesMAY be used as a value to signal when XAdES is in use. The value is used in the<cbc:SignatureMethod>child of<cac:Signature>.If the location of the digital signature is known, the user MAY choose to indicate the location in a
<cbc:URI>child element of a<cac:ExternalReference>child element of a<cac:DigitalSignatureAttachment>element.A complete example of a
<cac:Signature>business object in the UBL instance is:<cac:Signature> <cbc:ID>urn:oasis:names:specification:ubl:signature:Invoice</cbc:ID> <cbc:SignatureMethod >urn:oasis:names:specification:ubl:dsig:detached</cbc:SignatureMethod> <cac:SignatoryParty> <cac:PartyIdentification> <cbc:ID>MyParty</cbc:ID> </cac:PartyIdentification> </cac:SignatoryParty> <cac:DigitalSignatureAttachment> <cac:ExternalReference> <cbc:URI>sigFile.xml</cbc:URI> </cac:ExternalReference> </cac:DigitalSignatureAttachment> </cac:Signature>Note
A document with multiple detached signatures is simply a document that is co-signed. By the appropriate use of the
<ds:Reference>element pointing to the UBL document from a detached signature file, all such signatures are signing the content of the document but not each other. A countersigning document signature, on the other hand, signs signatures already created for and external to or present in the document at the time it is countersigned. A digital countersignature<ds:Signature>, which may be located internal to the UBL document or in an external file, includes additional<ds:Reference>elements, each pointing either to the<ds:Signature>element or<ds:SignatureValue>element child of the signature being signed. In the first case, where the signature is detached, the<ds:Reference>element points to the external file for that signature; in the second case, where the signature is enveloped, the<ds:Reference>element points to the Id= value of either the<ds:Signature>or<ds:SignatureValue>element for that signature.Note
The XAdES specification supports an alternative countersignature approach where a
<ds:Signature>element pointing to the countersigned signature's<ds:SignatureValue>is embedded in the<ds:Object>of the countersigning signature. The inclusion of an alternative method in this specification does not prohibit this approach.The content to be signed is addressed in the
URI=attribute of<ds:Reference>:<ds:Reference URI="myInvoice.xml">An option when using detached digital signatures is to express in XPath that address that qualifies all nodes in the referenced content to be included in the calculation of the digital signature hash. For a signature calculated for a document to remain valid, none of the signed information can change, nor can any information be added or removed from that portion of the document included in the hash calculation.
Consider the need to create a detached signature for a UBL file in which there already exists an enveloped signature. The following transformation element in a digital signature flexibly prevents the signature being invalidated by the subsequent addition of any signatures using the enveloped profile within the extension of the document being signed:
<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)=0 </XPath> </Transform>A non-final transformation algorithm used in the detached signature signs all content outside of any enveloped signatures in the UBL document. When the UBL document does not already have an enveloped signature, one cannot be added without invalidating the detached signature. In effect, the entire document has been signed and cannot change, but the addition of the scaffolding for a signature constitutes a change. However, when the UBL document already has an enveloped signature, other signatures can be added without invalidating the detached signature, because the scaffolding doesn't change when other signatures are added within the existing scaffolding; the non-final transformation algorithm does not include the signatures found in the existing scaffolding. When there is no preexisting enveloped signature, the entire document must be signed in the detached signature.
To sign only a portion of a UBL document, an appropriate [XPointer] address SHOULD be used because UBL business object elements do not have attributes of type ID. This requires XPointer awareness on the part of the digital signature tools being used.
Claiming syntax conformance to the enveloped profile of this specification requires:
the schema-valid expression of a UBL extension when the UBL Signature apex element is the apex of the extension;
the
<ext:Extension>element is present in the UBL extension and has eitherurn:oasis:names:specification:ubl:dsig:envelopedorurn:oasis:names:specification:ubl:dsig:enveloped:xadesas its value;the value in all uses of
<sbc:ReferencedSignatureID>, when present, correlates to a corresponding<cbc:ID>element of a<cac:Signature>element in the same instance; andthe
<cbc:SignatureMethod>element, when present, of signature business objects whose signatures are in the UBL extension has eitherurn:oasis:names:specification:ubl:dsig:envelopedorurn:oasis:names:specification:ubl:dsig:enveloped:xadesas its value.Claiming processing conformance to the enveloped profile of this specification requires the conformant processing of all contained
<ds:Signature>elements per [XMLDSig].Claiming syntax conformance to the detached profile of this specification requires that the
<cbc:SignatureMethod>element, when present, of signature business objects whose signatures are outside of the UBL document has eitherurn:oasis:names:specification:ubl:dsig:detachedorurn:oasis:names:specification:ubl:dsig:detached:xadesas its value.When conformance to XAdES in a UBL document is chosen, this specification requires the valid expression and processing of the XAdES syntax found in an XMLDSig per [XAdES].
Appendix A. Acknowledgments (Non-Normative)
The following OASIS members have participated in the creation of this specification and are gratefully acknowledged.
Iñigo Barreira, iZenpe S.A., ETSI/ESI member
Oriol Bausà Peris, Invinet Sistemes 2003, S.L.
Andrea Caccia, Associazione Italiana Tesorieri d'Impresa, ETSI/ESI member
Roberto Cisternino, JAVEST
Juan Carlos Cruellas, Centre d'aplicacions avançades d'Internet (UPC), ETSI/ESI member
G. Ken Holman, Crane Softwrights Ltd.
Julián Inza, Albalia Interactiva
<?xml-stylesheet type="text/xsl"
href="file:///z:/oasis/spec-0.5/stylesheets/oasis-specification-html.xsl"?>
<!DOCTYPE article
[
<!--the document properties-->
<!ENTITY standard "Committee Draft 11">
<!ENTITY stage "cd11">
<!ENTITY name "UBL-DSig">
<!ENTITY version "1.0">
<!ENTITY pversion "NONE">
<!ENTITY this-loc "http://docs.oasis-open.org/ubl/&stage;-&name;-&version;">
<!ENTITY previous-loc "http://docs.oasis-open.org/ubl/os-UBL-2.0">
<!ENTITY latest-loc "http://docs.oasis-open.org/ubl/&name;-&version;">
<!ENTITY pubdate "24 April 2011">
]>
<article status="&standard;">
<articleinfo>
<productname>&stage;-&name;</productname>
<productnumber>&version;</productnumber>
<releaseinfo role="OASIS-specification-this"&this-loc;/&name;-&version;.html</releaseinfo><releaseinfo role="OASIS-specification-this"<?nospell-start?>&this-loc;/&name;-&version;.pdf<?nospell-end?></releaseinfo><releaseinfo role="OASIS-specification-this-authoritative"<?nospell-start?>&this-loc;/&name;-&version;.xml<?nospell-end?></releaseinfo>
<!--
<releaseinfo role="OASIS-specification-previous"&previous-loc;/UBL-2.0.html</releaseinfo><releaseinfo role="OASIS-specification-previous"&previous-loc;/UBL-2.0.pdf</releaseinfo><releaseinfo role="OASIS-specification-previous"&previous-loc;/UBL-2.0.xml</releaseinfo>-->
<!-- generic form of above
<releaseinfo role="OASIS-specification-previous"&previous-loc;/&name;-&version;.html</releaseinfo><releaseinfo role="OASIS-specification-previous"&previous-loc;/&name;-&version;.pdf</releaseinfo><releaseinfo role="OASIS-specification-previous"&previous-loc;/&name;-&version;.xml</releaseinfo> -->
<releaseinfo role="OASIS-specification-latest"&latest-loc;/&name;-&version;.html</releaseinfo><releaseinfo role="OASIS-specification-latest"&latest-loc;/&name;-&version;.pdf</releaseinfo><releaseinfo role="OASIS-specification-latest-authoritative"&latest-loc;/&name;-&version;.xml</releaseinfo>
<!-- generic form of above
<releaseinfo role="OASIS-specification-latest"&latest-loc;/&name;-&version;.html</releaseinfo><releaseinfo role="OASIS-specification-latest"&latest-loc;/&name;-&version;.pdf</releaseinfo><releaseinfo role="OASIS-specification-latest-authoritative"&latest-loc;/&name;-&version;.xml</releaseinfo> -->
<title>UBL Digital Signature Profiles &version;</title>
<releaseinfo role="committee">
<!--<ulink
url="http://www.oasis-open.org/committees/ubl">OASIS Universal
Business Language TC</ulink><?lb?>-->
<ulink
url="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl-security"OASIS Universal Business Language Security SC</ulink></releaseinfo>
<authorgroup>
<editor>
<firstname>Oriol</firstname>
<surname><?nospell-start?>Bausà
Peris<?nospell-end?></surname>
<affiliation>
<address><email>oriol@invinet.org</email></address>
</affiliation>
</editor>
<editor>
<firstname>Andrea</firstname>
<surname><?nospell-start?>Caccia<?nospell-end?></surname>
<affiliation>
<address><email>andrea.caccia@studiocaccia.com</email></address>
</affiliation>
</editor>
<editor>
<firstname>Roberto</firstname>
<surname><?nospell-start?>Cisternino<?nospell-end?></surname>
<affiliation>
<address><email>roberto@javest.com</email></address>
</affiliation>
</editor>
<editor>
<firstname>G. Ken</firstname>
<surname>Holman</surname>
<affiliation>
<address><email>gkholman@CraneSoftwrights.com</email></address>
</affiliation>
</editor>
<editor>
<firstname>Julián</firstname>
<surname><?nospell-start?>Inza<?nospell-end?></surname>
<affiliation>
<address><email>julian.inza@albalia.com</email></address>
</affiliation>
</editor>
<othercredit>
<firstname>Andrea</firstname>
<surname><?nospell-start?>Caccia<?nospell-end?></surname>
<affiliation>
<address><email>andrea.caccia@studiocaccia.com</email></address>
</affiliation>
</othercredit>
<othercredit>
<firstname>Julián</firstname>
<surname><?nospell-start?>Inza<?nospell-end?></surname>
<affiliation>
<address><email>julian.inza@albalia.com</email></address>
</affiliation>
</othercredit>
</authorgroup>
<pubdate>&pubdate;</pubdate>
<legalnotice role="related">
<title>Related Work</title>
<para>This specification relates to all versions of OASIS
Universal Business Language (UBL) 2.x.</para>
</legalnotice>
<legalnotice role="namespaces">
<title>Declared XML Namespaces</title>
<simplelist>
<member>
urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2 </member>
<member>
urn:oasis:names:specification:ubl:schema:xsd:SignatureAggregateComponents-2 </member>
<member>
urn:oasis:names:specification:ubl:schema:xsd:SignatureBasicComponents-2
</member>
</simplelist>
</legalnotice>
<abstract>
<para>This specification defines two profiles for digitally
signing Universal Business Language (UBL) 2.x documents and a
standard digital signature extension for use with the enveloped
profile.</para>
<para>The profiles are based on IETF/W3C XML Digital Signatures,
with specific provisions to use XAdES extensions when the
electronic signing of UBL documents addresses special advanced
legal and technical requirements.</para>
</abstract>
<legalnotice role="status" id="STATUS">
<title>Status</title>
<para>This document was last revised or approved by the UBL TC on
the above date. The level of approval is also listed above.
Check the current location noted above for possible later
revisions of this document. This document is updated
periodically on no particular schedule.</para>
<para>Technical Committee members should send comments on this
specification to the Subcommittee's email list. Others should
send comments to the Subcommittee by using the "Send A Comment"
button on the Subcommittee's web page at <ulink
url="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl-security"http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl-security</ulink>.</para><para>For information on whether any patents have been disclosed
that may be essential to implementing this specification, and
any offers of patent licensing terms, please refer to the
Intellectual Property Rights section of the Technical Committee
web page at <ulink
url="http://www.oasis-open.org/committees/ubl/ipr.php"http://www.oasis-open.org/committees/ubl/ipr.php</ulink>.</para></legalnotice>
<legalnotice role="notices">
<title>Notices</title>
<para>Copyright © OASIS® Open 2011. All Rights Reserved. </para>
<para>All capitalized terms in the following text have the
meanings assigned to them in the OASIS Intellectual Property
Rights Policy (the "OASIS IPR Policy"). The full Policy may be
found at the OASIS website.</para>
<para>This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published, and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this section are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, including by removing the copyright
notice or references to OASIS, except as needed for the purpose
of developing any document or deliverable produced by an OASIS
Technical Committee (in which case the rules applicable to
copyrights, as set forth in the OASIS IPR Policy, must be
followed) or as required to translate it into languages other
than English.</para>
<para>The limited permissions granted above are perpetual and will
not be revoked by OASIS or its successors or assigns.</para>
<para>This document and the information contained herein is
provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.</para>
<para>OASIS requests that any OASIS Party or any other party that
believes it has patent claims that would necessarily be
infringed by implementations of this OASIS Committee
Specification or OASIS Standard, to notify OASIS TC
Administrator and provide an indication of its willingness to
grant patent licenses to such patent claims in a manner
consistent with the IPR Mode of the OASIS Technical Committee
that produced this specification.</para>
<para>OASIS invites any party to contact the OASIS TC
Administrator if it is aware of a claim of ownership of any
patent claims that would necessarily be infringed by
implementations of this specification by a patent holder that is
not willing to provide a license to such patent claims in a
manner consistent with the IPR Mode of the OASIS Technical
Committee that produced this specification. OASIS may include
such claims on its website, but disclaims any obligation to do
so.</para>
<para>OASIS takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; neither does
it represent that it has made any effort to identify any such
rights. Information on OASIS' procedures with respect to rights
in any document or deliverable produced by an OASIS Technical
Committee can be found on the OASIS website. Copies of claims of
rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this OASIS
Committee Specification or OASIS Standard, can be obtained from
the OASIS TC Administrator. OASIS makes no representation that
any information or list of intellectual property rights will at
any time be complete, or that any claims in such list are, in
fact, Essential Claims.</para>
<para>The name "OASIS" is a trademark of <ulink
url="http://www.oasis-open.org">OASIS</ulink>, the owner and
developer of this specification, and should be used only to
refer to the organization and its official outputs. OASIS
welcomes reference to, and implementation and use of,
specifications, while reserving the right to enforce its marks
against misleading uses. Please see <ulink
url="http://www.oasis-open.org/who/trademark.php"http://www.oasis-open.org/who/trademark.php</ulink> for aboveguidance.</para>
</legalnotice>
</articleinfo>
<section id="INTRO" role="non-normative">
<title>Introduction</title>
<para>There are certain circumstances in which it becomes necessary
to electronically sign UBL documents. This can be the case when
creating orders or invoices. In some countries, digitally signing
electronic invoices is required by law.</para>
<para>UBL has an ABIE to define signatures and a number of ASBIEs to
use such signatures in a document. (See current UBL documentation
for more regarding these terms.) There are a number of standard
initiatives in the electronic signature area that are being
adopted or recommended by different organizations or bodies. This
specification standardizes the use of the XML Signature
Specification <xref linkend="b_xmldsig"/> in and for UBL documents
and recommends their association with the UBL BIEs.</para>
<note>
<para>The implementation of the extension used in the "enveloped"
profile described below also serves as a model of a typical UBL
extension. Those wishing to create their own UBL extension can
mimic the schema and namespace structures used here.</para>
</note>
<para><xref linkend="b_xmldsig"/> is a general framework for
digitally signing XML documents. ETSI TS 101 903, also known as
<xref linkend="b_XAdES"/>, is an XML electronic signature standard
that can be used to create different XML Advanced Electronic
Signatures. XAdES extends XMLDSig for use with advanced and
qualified electronic signatures as specified in European Union
Directive <xref linkend="b_1999-93-EC"/>. Use of XAdES and the
concept of Advanced Electronic Signature is not limited to Europe,
as it is being adopted by many countries outside the EU, and, at
the time of publication of this specification, it is undergoing
standardization in ISO TC 154 as ISO/CD 14533-2.</para>
<para>One important benefit of XAdES is that it allows the
addition of information and timestamps that extend the validity
of a signature beyond the expiration or revocation of the
electronic certificates involved in signature verification or
the obsolescence of the underlying cryptographic keys and
algorithms. By extending XMLDSig with additional embedded
syntax and processing, XAdES satisfies the European Commission
Directive on a Community Framework for Electronic Signatures as
well as other use cases requiring long-term preservation of
signed documents. XAdES contains several modules that permit
various levels of security, such as non-repudiation with
timestamps and long-term signature verification.</para>
<para>The work of standardizing electronic signatures was
supported by the European Commission and assigned to the
Information and Communication Technologies Standards Board
(ICTSB), a round table of most European IT standards bodies and
some international standards bodies such as the IETF and
W3C.</para>
<para>This UBL Digital Signature Profiles specification defines two
profiles that represent two approaches to signing UBL documents:
enveloped and detached. Each of these approaches uses XMLDSig in a
way that may or may not include XAdES features. In other words,
the mechanisms implemented here can be used not only to implement
XAdES in these two ways but also to implement other signature
technologies based on XMLDSig as well.</para>
<para>Using UBL Digital Signature Profiles one can conform to, for
example, the UN/CEFACT Signed Digital Evidence Interoperability
Recommendation <xref linkend="b_rec37"/>. <emphasis>[To date, this
recommendation has not been published by UN/CEFACT.]</emphasis></para>
</section>
<section id="TERMINOLOGY">
<title>Terminology</title>
<section id="DEFS">
<title>Terms and Definitions</title>
<variablelist>
<varlistentry>
<term>
<emphasis role="bold">ASiC-S</emphasis>
</term>
<listitem>
<para>Associated Signature Container (simple form). A
standard container that associates a single data object
with one or more detached signature(s) that apply to
it. See <xref linkend="b_asic"/>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<emphasis role="bold">Digital Signature</emphasis>
</term>
<listitem>
<para>A value generated from the application of a private
key to a message via a cryptographic algorithm such that
it has the properties of integrity and message
authentication and/or signer authentication. A signature
may be (non-exclusively) described as detached,
enveloping, or enveloped (<xref
linkend="b_xmldsig"/>, with modifications).</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<emphasis role="bold">Transform</emphasis>
</term>
<listitem>
<para>The processing of data from its source to its
derived form. Typical transforms include XML
Canonicalization <xref linkend="b_c14n"/> and XSLT <xref
linkend="b_xslt20"/>.</para>
</listitem>
</varlistentry>
</variablelist>
<para>The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL, when they
appear in this document, are to be interpreted as described in
<xref linkend="rfc2119"/>.</para>
</section>
<section id="ABBR">
<title>Symbols and Abbreviations</title>
<variablelist>
<varlistentry>
<term>
<emphasis role="bold">ABIE</emphasis>
</term>
<listitem>
<para>Aggregate Business Information Entity</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<emphasis role="bold">AdES</emphasis>
</term>
<listitem>
<para>Advanced Electronic Signature</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<emphasis role="bold">ASBIE</emphasis>
</term>
<listitem>
<para>Association Business Information Entity</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<emphasis role="bold">BBIE</emphasis>
</term>
<listitem>
<para>Basic Business Information Entity</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<emphasis role="bold">BIE</emphasis>
</term>
<listitem>
<para>Business Information Entity</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<emphasis role="bold"<?nospell-start?>C14N<?nospell-end?></emphasis></term>
<listitem>
<para>Canonicalization</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<emphasis role="bold"<?nospell-start?>DSig<?nospell-end?></emphasis></term>
<listitem>
<para>Digital Signature</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<emphasis role="bold">QC</emphasis>
</term>
<listitem>
<para>Qualified Certificate</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<emphasis role="bold">QS</emphasis>
</term>
<listitem>
<para>Qualified Signature</para>
</listitem>
</varlistentry>
<!--
<varlistentry>
<term>
<emphasis role="bold">SSCD</emphasis>
</term>
<listitem>
<para>Secure Signature Creation Device</para>
</listitem>
</varlistentry>
-->
<varlistentry>
<term>
<emphasis role="bold"<?nospell-start?>XAdES<?nospell-end?></emphasis></term>
<listitem>
<para>XML Advanced Electronic Signatures <xref
linkend="b_XAdES"/></para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<emphasis role="bold">XML</emphasis>
</term>
<listitem>
<para>Extensible Markup Language</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<emphasis role="bold"<?nospell-start?>XMLDSig<?nospell-end?></emphasis></term>
<listitem>
<para>XML Digital Signature <xref linkend="b_xmldsig"
/></para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<emphasis role="bold">XPath</emphasis>
</term>
<listitem>
<para>XML Path Language (an XML data model and addressing
language) <xref linkend="b_xpath20"/></para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<emphasis role="bold">XSLT</emphasis>
</term>
<listitem>
<para>Extensible Stylesheet Language Transformations (a
transformation language) <xref linkend="b_xslt20"
/></para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section id="NORMATIVE">
<title>Normative References</title>
<para/>
<bibliography id="normbibl">
<title/>
<bibliomixed id="rfc2119">
<abbrev>RFC2119</abbrev><citetitle>
<ulink url="http://www.faqs.org/rfcs/rfc2119.html">Key words
for use in RFCs to Indicate Requirement Levels, March 1997</ulink>.
</citetitle>
</bibliomixed>
<bibliomixed id="b_XAdES">
<abbrev>XAdES</abbrev><citetitle>
<ulink
url="http://uri.etsi.org/01903/v1.4.1/ts_101903v010401p.pdf"XML Advanced Electronic Signatures. ETSI TS 101 903V1.4.1, June 2009</ulink>.
</citetitle>
</bibliomixed>
<bibliomixed id="b_xmldsig">
<abbrev>XMLDSig</abbrev><citetitle>
<ulink
url="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/"XML-Signature Syntax and Processing. W3C Recommendation,12 February 2002</ulink>.
</citetitle>
</bibliomixed>
</bibliography>
</section>
<section id="INFORMATIVE">
<title>Non-Normative References</title>
<para/>
<bibliography id="infobibl">
<title/>
<bibliomixed id="b_1999-93-EC">
<abbrev>1999/93/EC</abbrev><citetitle>
<ulink
url="http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31999L0093:EN:NOT"Directive 1999/93/EC of the European Parliament and ofthe Council of 13 December 1999 on a Community framework
for electronic signatures</ulink>.
</citetitle>
</bibliomixed>
<bibliomixed id="b_asic">
<abbrev>ASiC</abbrev><citetitle>
<ulink
url="http://webapp.etsi.org/WorkProgram/Report_WorkItem.asp?WKI_ID=31946"Electronic Signatures and Infrastructures (ESI); AssociatedSignature Containers (ASIC). ETSI TS 102 918 V1.1.1, April 2011</ulink>.
</citetitle>
</bibliomixed>
<bibliomixed id="b_cwa15579">
<abbrev>CWA15579</abbrev><citetitle>
<ulink url=
"ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eInvoicing/CWA15579-00-2006-Jul.pdf"CEN Workshop Agreement: E-invoices and digital signatures(CWA 15579), July 2006</ulink>.
</citetitle>
</bibliomixed>
<bibliomixed id="b_cwa15580">
<abbrev>CWA15580</abbrev><citetitle>
<ulink url=
"ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eInvoicing/CWA15580-00-2006-jul.pdf"CEN Workshop Agreement: Storage of Electronic Documents(CWA 15580), July 2006</ulink>.
</citetitle>
</bibliomixed>
<bibliomixed id="b_odfp">
<abbrev>ODFP</abbrev><citetitle>
<ulink url=
"http://docs.oasis-open.org/office/v1.2/csprd03/OpenDocument-v1.2-csprd03-part3.pdf"OASIS Standard, Open Document Format for OfficeApplications (<?nospell-start?>OpenDocument<?nospell-end?>)
Version 1.2 - Part 3 Packages, December 2006</ulink>.
</citetitle>
</bibliomixed>
<bibliomixed id="rfc3161">
<abbrev>RFC3161</abbrev><citetitle>
<ulink url="http://www.faqs.org/rfcs/rfc3161.html">Internet
X.509 Public Key Infrastructure Time-Stamp Protocol (TSP),
August 2001</ulink>.
</citetitle>
</bibliomixed>
<bibliomixed id="b_c14n"><abbrev>XML
C14N</abbrev><?nospell-start?>John Boyer,
<?nospell-end?><citetitle><ulink
url="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"Canonical XML Version 1.0, 15 March 2001</ulink>.</citetitle>
</bibliomixed>
<bibliomixed id="b_rec37"><abbrev>UN/CEFACT Rec.
37</abbrev><citetitle><ulink
url="http://www.unece.org/cefact/cf_plenary/plenary10/ECE_TRADE_C_CEFACT_2010_14E.pdf"Signed Digital Evidence InteroperabilityRecommendation, 27 September 2010</ulink>.</citetitle>
</bibliomixed>
<bibliomixed id="b_xpath20"><abbrev>XPath
2.0</abbrev><?nospell-start?>Anders Berglund, et al.,
<?nospell-end?><citetitle><ulink
url="http://www.w3.org/TR/2007/REC-xpath20-20070123/">XML
Path Language (XPath) Version 2.0, 23 January 2007</ulink>.
</citetitle>
</bibliomixed>
<bibliomixed id="b_xpointer"<abbrev>XPointer</abbrev><?nospell-start?>Steven DeRose, etal., <?nospell-end?><citetitle><ulink
url="http://www.w3.org/TR/xptr/">XML Pointer Language
(XPointer) Version 1.0 Working Draft, 16 August 2002</ulink>.
</citetitle>
</bibliomixed>
<bibliomixed id="b_xslt20"><abbrev>XSLT 2.0</abbrev>Michael Kay,
<citetitle><ulink url="http://www.w3.org/TR/xslt20/">XSL
Transformations (XSLT) Version 2.0, 2007-01-23</ulink>.
</citetitle>
</bibliomixed>
</bibliography>
</section>
<section>
<title>Referenced Namespaces</title>
<para>The table below lists the namespaces referenced in this
specification. The prefixes on the left are only documentary
conventions; their choice is not constrained by XML.</para>
<table rules="all" role="font-size-90%">
<title>Referenced Namespaces</title>
<tgroup cols="3">
<thead>
<row>
<entry>Prefix</entry>
<entry>Namespace</entry>
<entry>Reference</entry>
</row>
</thead>
<tbody>
<row>
<entry><literal>ds</literal></entry>
<entry><ulink url="http://www.w3.org/2000/09/xmldsig#"<literal>http://www.w3.org/2000/09/xmldsig#</literal></ulink></entry><entry><xref linkend="b_xmldsig"/></entry>
</row>
<row>
<entry><literal>xades</literal></entry>
<entry><ulink url="http://uri.etsi.org/01903/v1.3.2#"<literal>http://uri.etsi.org/01903/v1.3.2#</literal></ulink></entry><entry><xref linkend="b_XAdES"/></entry>
</row>
<row>
<entry><literal>ext</literal></entry>
<entry><literal>urn:oasis:names:specification:ubl:schema:
xsd:CommonExtensionComponents-2</literal></entry>
<entry>UBL extension namespace</entry>
</row>
<row>
<entry><literal>sig</literal></entry>
<entry><literal>urn:oasis:names:specification:ubl:schema:
xsd:CommonSignatureComponents-2</literal></entry>
<entry>UBL signature extension apex namespace</entry>
</row>
<row>
<entry><literal>sac</literal></entry>
<entry><literal>urn:oasis:names:specification:ubl:schema:
xsd:SignatureAggregateComponents-2</literal></entry>
<entry>UBL signature extension aggregate namespace</entry>
</row>
<row>
<entry><literal>sbc</literal></entry>
<entry><literal>urn:oasis:names:specification:ubl:schema:
xsd:SignatureBasicComponents-2</literal></entry>
<entry>UBL signature extension basic namespace</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
<section>
<title>XML Digital Signatures</title>
<section role="non-normative">
<title>Overview</title>
<para>Digital signatures, when appropriate rules and functions are
used, can support the following properties for a
document:</para>
<itemizedlist>
<listitem>
<para>Integrity: the document has not been modified since it
was signed.</para>
</listitem>
<listitem>
<para>Authenticity: the identity of the party creating the
signature that applies to the document is certified.</para>
</listitem>
<listitem>
<para>Non-repudiation (or content commitment): the document
signer cannot deny its involvement in creating and/or
approving the document (depending on the context and signer
role).</para>
</listitem>
<listitem>
<para>Anteriority: associating a time-stamp to the signature,
a proof that the signature (and therefore the signed document)
existed before a certain point in time.</para>
</listitem>
</itemizedlist>
<para><xref linkend="b_xmldsig"/> defines XML Signature processing
rules and syntax to provide integrity and message authentication
and/or signer authentication services for data of any type,
whether located within the XML that includes the signature or
elsewhere. <xref linkend="rfc3161"/> specifies a standard format
for time-stamping that can be used with XMLDSig and
XAdES.</para>
<para>The <xref linkend="b_1999-93-EC"/> directive defines the
following technology-neutral requirements that an electronic
signature must meet to be considered an Advanced Electronic
Signature (AdES) and have legal validity:</para>
<itemizedlist>
<listitem>
<para>it is uniquely linked to the signatory;</para>
</listitem>
<listitem>
<para>it is capable of identifying the signatory;</para>
</listitem>
<listitem>
<para>it is created using means that the signatory can
maintain under his sole control; and</para>
</listitem>
<listitem>
<para>it is linked to the data to which it relates in such a
manner that any subsequent change of the data is
detectable.</para>
</listitem>
</itemizedlist>
<para>The Qualified Signature (QS) is also defined as an AdES
based on Qualified Certificates (QC) and Secure Signature
Creation Devices for signing operations. In Europe, QS is
equivalent to handwritten signature provided it is based on a QC
issued by an accredited Certificate Service Provider. These
references are provided only for informational use and refer to
the framework defined in <xref linkend="b_1999-93-EC"/>.</para>
<para>XAdES extends XMLDSig to support AdES, but its adoption is
not limited to an EU context, as similar requirements are in
place in other countries. The introduction to <xref
linkend="b_XAdES"/> reads, in part,</para>
<blockquote>
<para>The XML advanced electronic signatures defined in the
present document will be built by incorporating to the XML
signatures as defined in XMLDSIG one new
<literal>ds:Object</literal> XML element containing the
additional qualifying information.</para>
</blockquote>
<para>That XAdES is completely embedded in XMLDSig ensures that
the UBL profiles for XMLDSig are sufficient to support
XAdES. These profiles also support other existing or future
extensions of XMLDSig that are completely embedded in XMLDSig
syntax. These other possible UBL digital signature profiles may
or may not use the XAdES extensions to XMLDSig.</para>
<para>It is important to note that XAdES and XMLDSig define
digital signature processing rules and syntax but do not cover
the implementation of security measures required for an AdES,
which are out of scope for this document.</para>
<para>Implementation may depend on local regulations in place and
specific provisions set by the authority issuing the
certificates supporting the signature. The implementer has to
determine the set of requirements that apply to the specific
context of use and determine accordingly the suitability of the
standards and the specific profiles to be used. XAdES can help
in fulfilling legal requirements, but this is not just a matter
of correctly applying a technical standard. Users are advised
to examine the regulations applicable to their specific context
of use.</para>
</section>
<section role="non-normative">
<title>XML Signature Types</title>
<para>An XML signature may be (non-exclusively) described (per
XMLDSig and XAdES) as detached, enveloping, or enveloped.</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Detached.</emphasis> The signature
applies to content that is external to the
<literal><ds:Signature></literal> element and can be
identified via a URI or transform. Consequently, the
signature is "detached" from the content it signs. This
definition typically applies to separate data objects, but
it also includes the case where the
<literal><ds:Signature></literal> and signed data object
are sibling elements residing within the same XML document.
</para>
</listitem>
<listitem>
<para><emphasis role="bold">Enveloping.</emphasis> The
signature applies to content found within a
<literal><ds:Object></literal> element of the signature
itself. The <literal><ds:Object></literal> (or its
content) is identified via a
<literal><ds:Reference></literal> (using a URI fragment
identifier or transform).</para>
</listitem>
<listitem>
<para><emphasis role="bold">Enveloped.</emphasis> The
signature applies to the XML content that contains
<literal><ds:Signature></literal> as an element.
Implementations of enveloped signature(s) must take care not
to include the signature in the calculation of the signature
value.</para>
</listitem>
</itemizedlist>
<para>This specification defines two profiles for signing a UBL
document: enveloped and detached.</para>
</section>
<section role="non-normative">
<title>XAdES</title>
<para>A compliant implementation of XAdES guarantees wide
acceptance in implementing legal regulations, such as EC
Directive <xref linkend="b_1999-93-EC" />, and supports best
practices in <?nospell-start?>eInvoicing<?nospell-end?>,
<?nospell-start?>eProcurement<?nospell-end?>, and
<?nospell-start?>eBusiness<?nospell-end?> in general as set
forth by relevant standard bodies such as CEN <xref
linkend="b_cwa15580"/> and <xref linkend="b_cwa15579" />.</para>
<para>The UBL implementation of XAdES provides the following
additional properties:</para>
<itemizedlist>
<listitem>
<para>A signed UBL document will be processed correctly by any
compliant UBL software (including UBL software that is not
XMLDSig/XAdES aware) and by any compliant XMLDSig/XAdES
verification software (including software that is not UBL
aware)</para>
</listitem>
<listitem>
<para>No change is required for currently defined UBL or
XMLDSig/XAdES syntaxes</para>
</listitem>
<listitem>
<para>The extension mechanism specified here supports any
XMLDSig/XAdES form, leaving to the implementer the choice of
the most appropriate one according to the specific legal
framework or application context.</para>
</listitem>
</itemizedlist>
<para>XAdES defines a set of forms that extends XMLDSig and allows
adding to the signature some validation data.</para>
<para>The two basic forms are:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">XAdES-BES</emphasis>, which
satisfies the minimum requirements for AdES; and</para>
</listitem>
<listitem>
<para><emphasis role="bold">XAdES-EPES</emphasis>, which builds
on XAdES-BES to include a security policy identifier
that specifies the rules followed to validate the
signature.</para>
</listitem>
</itemizedlist>
<para>A conformant XAdES signature generation and verification
implementation supports at least XAdES-BES or XAdES-EPES.</para>
<para>The other forms can be built by the signature generator or
the signature verifier by extending one of the two basic forms.
They are: </para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">XAdES-T</emphasis>, where a
timestamp is added to enforce non-repudiation and as a proof
of anteriority. This envelope allows ascertaining the
validity of a signature in case the signer certificate is
later revoked;</para>
</listitem>
<listitem>
<para><emphasis role="bold">XAdES-C</emphasis>, which adds to
the signed document a complete reference to verification
data (certificates and revocation lists) to support
long-term signature verification;</para>
</listitem>
<listitem>
<para><emphasis role="bold">XAdES-X</emphasis>, which adds
timestamps to XAdES-C references to protect against future
compromise of certificates;</para>
</listitem>
<listitem>
<para><emphasis role="bold">XAdES-X-L</emphasis>, which is
similar to XADES-X but adds real certificates and revocation
lists instead of just references; and</para>
</listitem>
<listitem>
<para><emphasis role="bold">XAdES-A</emphasis>, which adds
timestamps (periodically, as required) to extend the
validity period for long-term storage, taking into
account a possible weakening of the algorithms used to sign
the document and related certificates during the storage
period.</para>
</listitem>
</itemizedlist>
<para>This specification does not recommend any specific XAdES
form for a UBL document, as this choice depends on the specific
context of use, agreements between the parties, and local
regulations.</para>
</section>
<section>
<title>UBL Signature Profiles</title>
<para>This document specifies two profiles for use in digitally
signing UBL documents:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Enveloped Signature
Profile:</emphasis> One or more signatures are added to the
UBL document inside a single identifiable and dedicated UBL
Extension. Other UBL extensions MAY be present provided they
have different identifiers so that they can be distinguished
from the one that contains the document signature(s). This
profile is defined such that UBL content processing can be
separated from electronic signature processing, both on the
issuing side and on the receiving side, and specialized
applications can be devoted to each function. The UBL
application doesn't need to be electronic signature aware,
and the electronic signature application does not need to be
involved in the management of the UBL syntax. A signature
business object in the UBL document may reference a
particular electronic signature in the extension.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Detached Signature
Profile:</emphasis> The signature is outside the UBL
document content in another information resource. Some
mechanism has to be defined by the implementer to send or
make available the signature to the recipient. This method
of signing may be identified in the UBL document. This
approach can be useful to avoid or minimize any kind of
modification to the UBL document and is compatible with
other signature methods not explicitly referenced by this
profile.</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Requirements for Digital Signatures in UBL</title>
<para>The main requirements to be addressed when choosing a
specific signature profile can be divided into the following
categories:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">Legal requirements.</emphasis> In
some countries a digital signature is required on electronic
invoices. It can also be compulsory in electronic
procurement, especially in a cross border context, to have
digital signature on the key document exchanged, e.g., on
orders. Another important legal requirement is long-term
document preservation, for a storage period that in general
is specific in each country and can span many years. The
requirement to guarantee the integrity and authenticity of
all fiscally relevant archived documents, as specified, for
example, by <xref linkend="b_cwa15580"/> for electronic
invoices, can be met with digital signatures when proper
XAdES forms are used.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Business requirements.</emphasis> A
digital signature can reduce the risks associated with a
business transaction (e.g., non-repudiation of a commercial
order, proof-of-origin and integrity of an invoice) and its
use can be provided for in the interchange agreement between
parties. The choice of the signature format and its
application is a key element for interoperability.</para>
</listitem>
<listitem>
<para><emphasis role="bold">Process requirements.</emphasis>The
presence of the digital signature should not add any
specific constraints on UBL document content processing. If
the signed document remains a valid UBL document, the
signature can be verified at any stage of the process: it
should be possible to validate a signed document at any time
"as is" by UBL and XAdES verifiers.</para>
</listitem>
</itemizedlist>
</section>
</section>
<section>
<title>Profiles for UBL Digital Signatures</title>
<para>The two profiles for adding one or more digital signatures to
a UBL document are based on <xref linkend="b_xmldsig" />. These
profiles and their associated methods decouple the UBL document to
be signed from any specificity in the digital signature standard
adopted within XMLDSig. The XAdES standard is an example of a
standard use of XMLDSig. UBL users may use any standard built on
XMLDSig or simply use XMLDSig as it stands without any
extensions.</para>
<para>Managing XML signatures inside of a UBL document is described
in <xref linkend="enveloped"/>. Managing XML signatures outside of
a UBL document is described in <xref linkend="detached"/>.</para>
<para>Both profiles support co-signatures, i.e., a UBL document can
be independently cosigned by multiple signers in any order and
time. Both profiles support countersignatures, i.e., a UBL
document can have its signatures signed by another signature. The
enveloped signature profile supports a final signature, i.e., a
UBL document once signed with a final signature cannot have any
other signature added without invalidating the final
signature.</para>
<para>The choice of the most suitable profile should take into
account mainly the specific document processing and delivery
infrastructure.</para>
<para>The main advantage of the enveloped profile is that the
signature(s) are embedded in the UBL document (which syntactically
remains a valid UBL document). This means that the transport of
the signatures is guaranteed by the UBL document delivery
infrastructure.</para>
<para>The detached signature profile has a simpler preparation phase
and signature procedure, but specific means to send or make
available the signature(s) to the recipient have to be
implemented. A standard container like <xref linkend="b_odfp"/>
can be used to associate the UBL document with detached advanced
electronic signature(s) that apply to it. The simple <xref
linkend="b_asic"/> container (ASiC-S) can be created at a later
time than signature generation so that it contains a UBL document
and one or more detached signatures that apply to it.</para>
<para>Archiving of UBL documents also can be an important issue to
consider, as document preservation has specific
requirements.</para>
<section id="enveloped">
<title>Enveloped XML Signatures in UBL Documents</title>
<para>This profile supports one or more signatures to be applied
to a UBL document and embedded in the UBL document itself inside
a dedicated extension. This profile can be used with all UBL
documents under their respective
<literal><ext:UBLExtensions></literal> extension
point.</para>
<note>
<para>The <literal>xml/UBL-Invoice-2.0-Signed.xml</literal>
sample document in the UBL 2.1 distribution illustrates the
embedding of three extensions in a single document, one of
which is the signature extension. </para>
</note>
<para>The user MAY choose to indicate in a
<literal><cac:Signature></literal> element that the
signature details are found in the signature extension. The URI
<literal>urn:oasis:names:specification:ubl:dsig:enveloped</literal>
is reserved as a value for
<literal><cbc:SignatureMethod></literal> to signal this.
The URI
<literal>urn:oasis:names:specification:ubl:dsig:enveloped:xades</literal>
MAY be used as a value for
<literal><cbc:SignatureMethod></literal> to signal when
XAdES is in use. Additionally, the user MAY include a
<literal><cbc:ID></literal> child of
<literal><cac:Signature></literal> for referencing purposes
from the enveloped signature. The identifier used can be any
value, but for convenience the URI of a URN beginning with
<literal>urn:oasis:names:specification:ubl:signature:</literal>
and ending with the local name of the parent of the signature
business object and optionally followed with a colon and number,
as in the
<literal>urn:oasis:names:specification:ubl:signature:IssuerEndorsement</literal>
example, is reserved for this purpose for UBL users. As with all
identifier references, the referenced identifier SHOULD exist
and be unique across all such identifier values. An example is
as follows:</para>
<programlisting><![CDATA[ <cac:Signature>
<cbc:ID>urn:oasis:names:specification:ubl:signature:Invoice</cbc:ID>
<cbc:SignatureMethodurn:oasis:names:specification:ubl:dsig:enveloped</cbc:SignatureMethod><cac:SignatoryParty>
<cac:PartyIdentification>
<cbc:ID>MyParty</cbc:ID>
</cac:PartyIdentification>
</cac:SignatoryParty>
</cac:Signature>
]]></programlisting>
<section>
<title>Enveloped Signature Syntax</title>
<para>There are two distinctive levels of syntax present:
UBL-specified scaffolding under the extension point used to
contain the signature information and IETF/W3C-specified
information for each digital signature.</para>
<para>One or more signature extensions in a given document MAY
each contain one or more sets of signature information. The
standard UBL-specified scaffolding for a given signature
extension begins with the
<literal><ext:UBLExtension></literal> element. The
extension's role as a UBL signature extension is indicated
with a child <literal><ext:ExtensionURI></literal> element
with the
<literal>urn:oasis:names:specification:ubl:dsig:enveloped</literal>
value. The
<literal>urn:oasis:names:specification:ubl:dsig:enveloped:xades</literal>
value MAY be used to indicate the use of XAdES in the
extension. Other extension metadata elements defined in UBL
are allowed to be included for the convenience of users
without changing the meaning or use of the extension.</para>
<para>All uses of the optional <literal><cbc:ID></literal>
metadata SHOULD be unique so that each extension can be
uniquely identified. For the convenience of users, a URI with
the URN beginning with
<literal>urn:oasis:names:specification:ubl:signature:</literal>
and ending with a number value is reserved for this purpose
for UBL users, and MAY be used. The value
<literal>urn:oasis:names:specification:ubl:signature:3</literal>
is a suitable example.</para>
<para>The mandatory <literal><ext:ExtensionContent></literal>
element is the extension scaffolding that contains the UBL
signature scaffolding. The apex element of the UBL signature
information is
<literal><sig:UBLDocumentSignatures></literal>. Note that
three namespaces are used for signature information, in
parallel with the UBL design of having a document namespace,
aggregate namespace and basic namespace. The apex element is
in the
<literal>urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2</literal>
namespace, a parallel to a UBL document namespace.
Signature-related aggregate entities are in the
<literal>urn:oasis:names:specification:ubl:schema:xsd:SignatureAggregateComponents-2</literal>
namespace. Signature-related basic entities are in the
<literal>urn:oasis:names:specification:ubl:schema:xsd:SignatureBasicComponents-2</literal>
namespace. Accordingly, there are three W3C Schema fragments
in the distribution accommodating these three
namespaces.</para>
<note>
<para>Creators of other UBL extensions using this one as a
model should review the UBL specification documentation for
guidelines regarding this schema design pattern.</para>
</note>
<para>In each extension with signature information, the
<literal><sig:UBLDocumentSignatures></literal> apex
element contains one or more individual
<literal><sac:SignatureInformation></literal> aggregates.
One aggregate is used to contain the information related to a
single IETF/W3C digital signature.</para>
<para>An aggregate MAY be identified for referencing purposes
using the common library <literal><cbc:ID></literal>
element. Such an identifier MAY be used in scenarios where a
particular signature needs to be identified external to the
document, e.g. in workflow applications. The identifier used
can be any value, but for convenience a URI consisting of a URN
beginning with
<literal>urn:oasis:names:specification:ubl:signature:</literal>
and ending with a number value is reserved for this purpose
for UBL users. An example is
<literal>urn:oasis:names:specification:ubl:signature:3</literal>.
As with all identifiers, each SHOULD be unique across all
identifier values.</para>
<para>An aggregate MAY make reference to an existing
<literal><cac:Signature></literal> business object in the
same UBL document. When needed, the
<literal><sbc:ReferencedSignatureID></literal> basic
element is used to point to the <literal><cbc:ID></literal>
identifier value of the referenced
<literal><cac:Signature></literal>. The identifier used
can be any value, but for convenience a URI consisting of a URN
beginning with
<literal>urn:oasis:names:specification:ubl:signature:</literal>
and ending with the local name of the parent of the signature
business object and optionally followed with a colon and
number, as in the
<literal>urn:oasis:names:specification:ubl:signature:IssuerEndorsement</literal>
example, is reserved for this purpose for UBL users. As with
all identifier references, the referenced identifier SHOULD
exist and be unique across all such identifier values.</para>
<para>A single <literal><ds:Signature></literal> element is a
child of the aggregate. It MAY be absent from the document,
thus supporting workflow scenarios where the element is added
by a subsequent process after the UBL scaffolding is added by
an earlier process. However, the signature information is
semantically incomplete without the IETF/W3C-defined element.
To support countersignatures countersigning this signature,
either this element or its
<literal><ds:SignatureValue></literal> child element MUST
use the <literal>Id=</literal> attribute with a value unique
from other attributes of schema type <literal>ID</literal> in
the instance.</para>
<para>A skeleton example of a single signature corresponding to
the example <literal><cac:Signature></literal> above is as
follows:</para>
<programlisting><![CDATA[<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:signature:1</cbc:ID>
<sbc:ReferencedSignatureIDurn:oasis:names:specification:ubl:signature:Invoice</sbc:ReferencedSignatureID><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id=...>
<ds:SignedInfo>
...
<ds:Reference URI=...>
...
<ds:Transform>
...
</ds:Transform>
...
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue Id=...>
...
</ds:SignatureValue>
<ds:KeyInfo>
...
</ds:KeyInfo>
<ds:Object>
...
</ds:Object>
</ds:Signature>
</sac:SignatureInformation>
</sig:UBLDocumentSignatures>
</ext:ExtensionContent>
]]></programlisting>
<note>
<para>The XAdES specification contains all qualifying XAdES
information in a single <literal><ds:Object></literal>
element located as shown above.</para>
</note>
<note>
<para>A document with multiple
<literal><sac:SignatureInformation></literal> elements
is simply a document that is co-signed. By the appropriate
use of the <literal><ds:Reference></literal> element,
all such signatures are signing the content of the document
but not each other. A <emphasis
role="italics">countersigning</emphasis> document
signature, on the other hand, signs signatures already
present in the document at the time it is countersigned. A
digital countersignature
<literal><ds:Signature></literal> includes additional
<literal><ds:Reference></literal> elements, each
pointing to either the <literal><ds:Signature></literal>
element being signed or its respective
<literal><ds:SignatureValue></literal> element.</para>
</note>
<note>
<para>The XAdES specification supports an alternative
countersignature approach where a
<literal><ds:Signature></literal> element pointing to the
countersigned signature's
<literal><ds:SignatureValue></literal> is embedded in the
<literal><ds:Object></literal> of the countersigning
signature. The inclusion of an alternative method in this
specification does not prohibit this approach.</para>
</note>
</section>
<section>
<title>Digital Signature Transformation (Enveloped
Signatures)</title>
<para>The content to be signed is indicated in the
<literal>URI=</literal> attribute of
<literal><ds:Reference></literal>. Using the empty string
indicates that the entire document (i.e., the enveloping UBL
instance) is what is being signed:</para>
<programlisting><![CDATA[<ds:Reference URI="">
]]></programlisting>
<para>A requirement when using digital signatures is to express
in XPath that address that qualifies all nodes in the
referenced content to be 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.</para>
<para>One of two such transformation expressions 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 in
either case; when adding more signatures, the behaviour
depends on the transformation expression used.</para>
<para>The following transformation element in a digital
signature flexibly prevents the signature being invalidated by
the subsequent addition of other signatures within the
extension:</para>
<programlisting><![CDATA[ <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>
]]></programlisting>
<para>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:</para>
<programlisting><![CDATA[ <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>
]]></programlisting>
<para>Multiple separate items of extra-document content (e.g.,
attachments) or embedded IETF/W3C signature content MAY be
included in the signature by adding sibling
<literal><ds:Reference></literal> elements with other
<literal>URI=</literal> attribute values. For example, to
countersign another signature in the same UBL document, make a
local reference to that signature's unique identifier as
in:</para>
<programlisting><ds:Reference URI="#<emphasis>{Id attribute of ds:Signature}</emphasis>"></programlisting>
<para>To sign only a portion of a UBL document, an appropriate
<xref linkend="b_xpointer"/> address for
<literal>URI=</literal> SHOULD be used because UBL business
object elements do not have attributes of type ID. This
requires XPointer awareness on the part of the digital
signature tools being used.</para>
</section>
</section>
<section id="detached">
<title>Detached XML Signatures for UBL Documents</title>
<para>This profile supports the application to a UBL document of
one or more signatures located outside of the document itself in
some other resource.</para>
<para>It is important to note that externally signing a UBL
document with a detached signature imposes no requirements on the
UBL document itself. Such a signature, in any kind of signature
container, can digitally sign the content of a UBL document
regardless of whether this is reflected in the document.</para>
<para>If a user knows the document will have a detached conformant
IETF/W3C XML digital signature, the user MAY choose to signal in
their UBL document that it is so signed. The URI value
<literal>urn:oasis:names:specification:ubl:dsig:detached</literal>
is reserved to indicate that the detached signature is an
IETF/W3C XML digital signature. The URI
<literal>urn:oasis:names:specification:ubl:dsig:detached:xades</literal>
MAY be used as a value to signal when XAdES is in use. The value
is used in the <literal><cbc:SignatureMethod></literal> child
of <literal><cac:Signature></literal>.</para>
<para>If the location of the digital signature is known, the user
MAY choose to indicate the location in a
<literal><cbc:URI></literal> child element of a
<literal><cac:ExternalReference></literal> child element of
a <literal><cac:DigitalSignatureAttachment></literal>
element.</para>
<para>A complete example of a
<literal><cac:Signature></literal> business object in the
UBL instance is:</para>
<programlisting><![CDATA[ <cac:Signature>
<cbc:ID>urn:oasis:names:specification:ubl:signature:Invoice</cbc:ID>
<cbc:SignatureMethodurn:oasis:names:specification:ubl:dsig:detached</cbc:SignatureMethod><cac:SignatoryParty>
<cac:PartyIdentification>
<cbc:ID>MyParty</cbc:ID>
</cac:PartyIdentification>
</cac:SignatoryParty>
<cac:DigitalSignatureAttachment>
<cac:ExternalReference>
<cbc:URI>sigFile.xml</cbc:URI>
</cac:ExternalReference>
</cac:DigitalSignatureAttachment>
</cac:Signature>
]]></programlisting>
<note>
<para>A document with multiple detached signatures is simply a
document that is co-signed. By the appropriate use of the
<literal><ds:Reference></literal> element pointing to the
UBL document from a detached signature file, all such
signatures are signing the content of the document but not
each other. A <emphasis
role="italics">countersigning</emphasis> document signature,
on the other hand, signs signatures already created for and
external to or present in the document at the time it is
countersigned. A digital countersignature
<literal><ds:Signature></literal>, which may be located
internal to the UBL document or in an external file, includes
additional <literal><ds:Reference></literal> elements, each
pointing either to the <literal><ds:Signature></literal>
element or <literal><ds:SignatureValue></literal> element
child of the signature being signed. In the first case, where
the signature is detached, the
<literal><ds:Reference></literal> element points to the
external file for that signature; in the second case, where
the signature is enveloped, the
<literal><ds:Reference></literal> element points to the Id=
value of either the <literal><ds:Signature></literal> or
<literal><ds:SignatureValue></literal> element for that
signature.</para>
</note>
<note>
<para>The XAdES specification supports an alternative
countersignature approach where a
<literal><ds:Signature></literal> element pointing to the
countersigned signature's
<literal><ds:SignatureValue></literal> is embedded in the
<literal><ds:Object></literal> of the countersigning
signature. The inclusion of an alternative method in this
specification does not prohibit this approach.</para>
</note>
<section>
<title>Digital Signature Transformation (Detached Signatures)</title>
<para>The content to be signed is addressed in the
<literal>URI=</literal> attribute of
<literal><ds:Reference></literal>:</para>
<programlisting><![CDATA[<ds:Reference URI="myInvoice.xml">
]]></programlisting>
<para>An option when using detached digital signatures is to
express in XPath that address that qualifies all nodes in the
referenced content to be included in the calculation of the
digital signature hash. For a signature calculated for a
document to remain valid, none of the signed information can
change, nor can any information be added or removed from that
portion of the document included in the hash
calculation.</para>
<para>Consider the need to create a detached signature for a UBL
file in which there already exists an enveloped signature. The
following transformation element in a digital signature
flexibly prevents the signature being invalidated by the
subsequent addition of any signatures using the enveloped
profile within the extension of the document being
signed:</para>
<programlisting><![CDATA[ <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)=0
</XPath>
</Transform>
]]></programlisting>
<para>A non-final transformation algorithm used in the detached
signature signs all content outside of any enveloped
signatures in the UBL document. When the UBL document does
not already have an enveloped signature, one cannot be added
without invalidating the detached signature. In effect, the
entire document has been signed and cannot change, but the
addition of the scaffolding for a signature constitutes a
change. However, when the UBL document already has an
enveloped signature, other signatures can be added without
invalidating the detached signature, because the scaffolding
doesn't change when other signatures are added within the
existing scaffolding; the non-final transformation algorithm
does not include the signatures found in the existing
scaffolding. When there is no preexisting enveloped
signature, the entire document must be signed in the detached
signature.</para>
<para>To sign only a portion of a UBL document, an appropriate
<xref linkend="b_xpointer"/> address SHOULD be used
because UBL business object elements do not have attributes of
type ID. This requires XPointer awareness on the part of the
digital signature tools being used.</para>
</section>
</section>
</section>
<section>
<title>Conformance</title>
<para>Claiming syntax conformance to the enveloped profile of this
specification requires:</para>
<itemizedlist>
<listitem>
<para>the schema-valid expression of a UBL extension when the
UBL Signature apex element is the apex of the
extension;</para>
</listitem>
<listitem>
<para>the <literal><ext:Extension></literal> element is
present in the UBL extension and has either
<literal>urn:oasis:names:specification:ubl:dsig:enveloped</literal>
or
<literal>urn:oasis:names:specification:ubl:dsig:enveloped:xades</literal>
as its value;</para>
</listitem>
<listitem>
<para>the value in all uses of
<literal><sbc:ReferencedSignatureID></literal>, when
present, correlates to a corresponding
<literal><cbc:ID></literal> element of a
<literal><cac:Signature></literal> element in the same
instance; and</para>
</listitem>
<listitem>
<para>the <literal><cbc:SignatureMethod></literal> element,
when present, of signature business objects whose signatures
are in the UBL extension has either
<literal>urn:oasis:names:specification:ubl:dsig:enveloped</literal>
or
<literal>urn:oasis:names:specification:ubl:dsig:enveloped:xades</literal>
as its value.</para>
</listitem>
</itemizedlist>
<para>Claiming processing conformance to the enveloped profile of
this specification requires the conformant processing of all
contained <literal><ds:Signature></literal> elements per <xref
linkend="b_xmldsig"/>.</para>
<para>Claiming syntax conformance to the detached profile of this
specification requires that the
<literal><cbc:SignatureMethod></literal> element, when present,
of signature business objects whose signatures are outside of the
UBL document has either
<literal>urn:oasis:names:specification:ubl:dsig:detached</literal>
or
<literal>urn:oasis:names:specification:ubl:dsig:detached:xades</literal>
as its value.</para>
<section>
<title>XAdES Conformance</title>
<para>When conformance to XAdES in a UBL document is chosen, this
specification requires the valid expression and processing of
the XAdES syntax found in an XMLDSig per <xref
linkend="b_XAdES"/>.</para>
</section>
</section>
<appendix role="non-normative">
<title>Acknowledgments</title>
<para>The following OASIS members have participated in the creation of
this specification and are gratefully acknowledged.</para>
<itemizedlist>
<listitem>
<para><?nospell-start?>Iñigo Barreira, iZenpe S.A.,
ETSI/ESI member<?nospell-end?></para>
</listitem>
<listitem>
<para><?nospell-start?>Oriol Bausà Peris, Invinet Sistemes
2003, S.L.<?nospell-end?></para>
</listitem>
<listitem>
<para><?nospell-start?>Andrea Caccia, Associazione Italiana
Tesorieri d'Impresa, ETSI/ESI member<?nospell-end?></para>
</listitem>
<listitem>
<para><?nospell-start?>Roberto Cisternino,
JAVEST<?nospell-end?></para>
</listitem>
<listitem>
<para><?nospell-start?>Juan Carlos Cruellas, Centre
d'aplicacions avançades d'Internet (UPC), ETSI/ESI
member<?nospell-end?></para>
</listitem>
<listitem>
<para>G. Ken Holman, Crane Softwrights Ltd.</para>
</listitem>
<listitem>
<para><?nospell-start?>Julián Inza, Albalia
Interactiva<?nospell-end?></para>
</listitem>
</itemizedlist>
</appendix>
</article>