[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft 10 of the UBL Digital Signature Profile for review
Hello UBL Security Subcommittee, Attached is an edited version of the UBL Digital Signature Profiles 1.0 Draft 09 of 19 January 2011. I have labeled it Draft 10. Both the XML (DocBook) source and generated PDF are attached, together with a diff file showing precisely the changes between the two drafts. Please review this new draft carefully, keeping in mind that the editor (me) has very little knowledge of digital signature technology and can easily introduce technical errors in the process of working with the language. This document is intended to form part of UBL 2.1 and will be included in UBL 2.1 PRD2. In order to keep to our projected schedule for PRD2, I am setting a one-week review cycle for the draft attached. If any member of the Security SC sees something that needs to be corrected or added to this draft, please register the change to this mail list before COB Sunday 27 March 2011. UBL 2.1 PRD3, currently scheduled for 3Q2011, will offer one more opportunity to modify the Digital Signature Profile, but since many implementers will be looking to PRD2 for the technical direction we are taking in UBL 2.1, it is important that we try to keep such modifications to a minimum. I would therefore appreciate the attention of every SC member to this draft. Best regards, Jon Bosak Chair, OASIS UBL TC
7,8c7,8 < <!ENTITY standard "Committee Draft 09"> < <!ENTITY stage "cd09"> --- > <!ENTITY standard "Committee Draft 10"> > <!ENTITY stage "cd10"> 15c15 < <!ENTITY pubdate "19 January 2011"> --- > <!ENTITY pubdate "20 March 2011"> 257c257 < <section id="INTRO" role="informative"> --- > <section id="INTRO" role="non-normative"> 262,264c262,264 < creating orders or invoices. In some countries, existing < legislation requires the invoices to be electronically < signed.</para> --- > creating orders or invoices. In some countries, digitally signing > electronic invoices is required by law.</para> > 266c266,267 < use such signatures in a document. There are a number of standard --- > use such signatures in a document. (See current UBL documentation > for more regarding these terms.) There are a number of standard 274,278c275,305 < <para>The implementation of the extension used in the enveloped < profile 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>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 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, certification data, and certification > archives.</para> 280,302c307,308 < <para>TS 101 903 is a XML electronic signature standard that can be < used to create different XML Advanced Electronic Signatures <xref < linkend="b_XAdES"/>. As XMLDSig is a general framework for < digitally signing XML documents, XAdES extends XMLDSig for use < with advanced and qualified electronic signature in the meaning of < European Union Directive 1999/93/EC. Use of XAdES is not limited < to Europe as it being adopted by many countries outside the EU < and, at the time of publication of this specification, it is under < standardization process in ISO TC 154 [ISO/CD 14533-2]. One < important benefit from XAdES is that electronically signed < documents validity can be extended for long periods, longer than < the expiration of the electronic certificates involved in < signature verification and also if underlying cryptographic keys < and algorithms security becomes inadequate.</para> < <para>XAdES extends XMLDSig with additional embedded syntax and < processing necessary to satisfy 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 itself contains several modules that permit < various levels of security such as non-repudiation with time- < stamps, certification data and certification archives.</para> < <para>The technical work of standardization of electronic signatures < was supported by the European Commission and mandated to the --- > <para>The work of standardizing electronic signatures was > supported by the European Commission and assigned to the 308,324d313 < <!-- < <para>The goals of UBL Security Subcommittee, according to its Charter, are:</para> < < <itemizedlist> < <listitem><para>To create a UBL profile of XAdES to enable the advanced electronic signature of UBL documents requiring special advanced legal and technical requirements not available in the base XMLDSig;</para> < </listitem> < <listitem><para>To recommend best practices for use of XAdES with UBL documents in order to facilitate consistent UBL implementations of XAdES;</para> < </listitem> < <listitem><para>To address other aspects of UBL security as requested by the UBL TC;</para> < </listitem> < <listitem><para>To establish informational liaisons with relevant standards body activities such as ETSI and CEN working groups; and</para> < </listitem> < <listitem><para>To gather security requirements via the UBL TC comment form.</para> < </listitem> < </itemizedlist> < --> < 326,328c315,320 < profiles (approaches) to signing UBL documents: enveloped and < detached. Each of those approaches uses XMLDSig that may or may < not include XAdES features.</para> --- > 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> 333a326 > <!-- 341a335 > --> 357,365c351,358 < of integrity, message authentication and/or signer < authentication. (However, this specification sometimes < uses the term signature generically such that it < encompasses Authentication Code values as well, but this < specification is careful to make the distinction when < the property of signer authentication is relevant to the < exposition.) A signature may be (non-exclusively) < described as detached, enveloping, or enveloped <xref < linkend="b_xmldsig"/>.</para> --- > of integrity and message authentication and/or signer > authentication. (This specification sometimes also uses > the term signature generically in a way that encompasses > Authentication Code values as well, but care has been > taken to make the distinction clear when signer > authentication is relevant.) A signature may be > (non-exclusively) described as detached, enveloping, or > enveloped <xref linkend="b_xmldsig"/>.</para> 373c366 < <para>The processing of a data from its source to its --- > <para>The processing of data from its source to its 564d556 < 574a567,570 > > http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31999L0093:en:HTML > > 621c617 < <?nospell-end?><title><ulink --- > <?nospell-end?><citetitle><ulink 623c619 < >Canonical XML Version 1.0</ulink></title> --- > >Canonical XML Version 1.0</ulink></citetitle> 627c623 < 37</abbrev><title><ulink --- > 37</abbrev><citetitle><ulink 630c626 < Recommendation</ulink></title> 2010-09-27</bibliomixed> --- > Recommendation</ulink></citetitle> 2010-09-27</bibliomixed> 634c630 < <?nospell-end?><title><ulink --- > <?nospell-end?><citetitle><ulink 636c632 < Path Language (XPath) Version 2.0</ulink></title> --- > Path Language (XPath) Version 2.0</ulink></citetitle> 641c637 < al <?nospell-end?><title><ulink --- > al <?nospell-end?><citetitle><ulink 643c639 < (XPointer) Version 1.0 Working Draft</ulink></title> --- > (XPointer) Version 1.0 Working Draft</ulink></citetitle> 647,648c643,644 < <title><ulink url="http://www.w3.org/TR/xslt20/";>XSL < Transformations (XSLT) Version 2.0</ulink></title> --- > <citetitle><ulink url="http://www.w3.org/TR/xslt20/";>XSL > Transformations (XSLT) Version 2.0</ulink></citetitle> 654c650 < <title>Referenced namespaces</title> --- > <title>Referenced Namespaces</title> 656,659c652,655 < specification, and the prefixes used only as documentary < conventions.</para> < <table rules="all"> < <title>Referenced namespaces</title> --- > 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> 713,714c709,710 < <section> < <title>Overview (informative)</title> --- > <section role="non-normative"> > <title>Overview</title> 730c726 < <para>Non-reputability (or content commitment): the document --- > <para>Non-repudiation (or content commitment): the document 737c733 < a proof that the signature (and thereof the signed document) --- > a proof that the signature (and therefore the signed document) 743c739 < rules and syntax to provide integrity, message authentication, --- > rules and syntax to provide integrity and message authentication 751,753c747,750 < following technology neutral requirements that an electronic < signature has to meet to have specific legal validity and have < an Advanced Electronic Signature (AdES):</para> --- > following technology-neutral requirements that an electronic > signature must meet to be considered an Advanced Electronic > Signature (AdES) and have legal validity:</para> > 774,775c771,772 < Creation Devices for signing operations. QS is equivalent to < handwritten signature in Europe provided it is based on a QC --- > Creation Devices for signing operations. In Europe, QS is > equivalent to handwritten signature provided it is based on a QC 778c775,780 < <xref linkend="b_1999-93-EC"/> defined framework.</para> --- > 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> 780,783d781 < <para>XAdES extends XMLDSig to support AdES but its adoption is < not limited to EU context, as similar requirements are in place < in other countries. The introduction to XAdES reads, in < part,</para> 785,788c783,786 < <para><xref linkend="b_XAdES"/>: 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 --- > <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 792,797c790,795 < <para>That XAdES is completely embedded in XMLDSig ensures 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. < Accordingly, these UBL digital signature profiles may be < identified as using XAdES extensions to XMLDSig or not.</para> --- > <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> 801,809c799,811 < the implementation of security measures required for an AdES < that are therefore out of the scope of this document and may < depend on local regulations in place and specific provisions set < by the CA issuing the certificates supporting the signature. The < implementer has to determine the set of requirements that < applies to the specific context of use and determine accordingly < the suitability if the standards and the specific profiles to be < used: an explicit advice is given to reference directly to any < regulation applicable to the specific context of use.</para> --- > 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> 813,814c815,816 < <section> < <title>XML Signature Types (informative)</title> --- > <section role="non-normative"> > <title>XML Signature Types</title> 816,818c818,819 < <para>An XML signature maybe (non-exclusively) described (as per < XMLDSig and XAdES) as detached, enveloping, or enveloped < types.</para> --- > <para>An XML signature may be (non-exclusively) described (per > XMLDSig and XAdES) as detached, enveloping, or enveloped.</para> 822,824c823,826 < <para><emphasis role="bold">Detached</emphasis> The signature < is over content that is external to the < <literal><ds:Signature></literal> element, and can be --- > > <para><emphasis role="bold">Detached.</emphasis> The signature > applies to content that is external to the > <literal><ds:Signature></literal> element and can be 828,831c830,834 < it also includes the instance where the < <literal><ds:Signature></literal> and signed data < object reside within the same XML document but are sibling < elements.</para> --- > 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> > 832a836 > 834,836c838,841 < <para><emphasis role="bold">Enveloping</emphasis> The < signature is over content found within a < <literal><ds:Object></literal> element of the signature --- > > <para><emphasis role="bold">Enveloping.</emphasis> The > signature applies to content found within a > <literal><ds:Object></literal> element of the signature 839c844 < <literal><ds:Reference></literal> (via a URI fragment --- > <literal><ds:Reference></literal> (using a URI fragment 840a846 > 841a848 > 843,847c850,855 < <para><emphasis role="bold">Enveloped</emphasis> The signature < is over the XML content that contains the < <literal><ds:Signature></literal> as an element. < Enveloped signature(s) implementations must take care not to < include the signature in the calculation of the signature --- > > <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 849c857,858 < </listitem> --- > > </listitem> 854,855c863,876 < <section> < <title>XAdES (informative)</title> --- > <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> 857,858d877 < <para>A compliant implementation implementing XAdES guarantees the < following properties:</para> 861,884c880,894 < <para>Wide acceptance in implementing legal regulations, such < as EC Directive [99/93/EC], and good practices to support < <?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> < </listitem> < <listitem> < <para>A signed UBL document should be processed correctly by < any UBL software (possibly not XMLDSig/XAdES aware) and by < any XMLDSig/XAdES verification software (possibly not UBL < aware);</para> < </listitem> < <listitem> < <para>No change required for presently defined UBL or < XMLDSig/XAdES syntaxes; and</para> < </listitem> < <listitem> < <para>Support any XMLDSig/XAdES form leaving to the < implementer the choice of the most appropriate one according < to its specific legal framework or application < context.</para> --- > <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> 890c900 < <para>The basic forms are:</para> --- > <para>The two basic forms are:</para> 893c903 < <para><emphasis role="bold">XAdES-BES</emphasis> that --- > <para><emphasis role="bold">XAdES-BES</emphasis>, which 897,899c907,909 < <para><emphasis role="bold">XAdES-EPES</emphasis>, that builds < up on XAdES-BES and includes a security policy identifier < that specify the rules followed to validate the --- > <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 907,909c917,919 < <para>The other forms are listed here after and can be built both < by the signature generator and/or the signature verifier < extending one of the basic forms.</para> --- > <para>The other forms extend one of these two basic forms and can > be built by the signature generator or the signature verifier. > They are: </para> 914,917c924,927 < timestamp is added to enforce non-repudiation and as an < anteriority proof. This envelope allows ascertaining the < validity of a signature in case the signer certificate < becomes revoked;</para> --- > 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> 920,923c930,933 < <para><emphasis role="bold">XAdES-C</emphasis>, add to the < signed document a complete reference to verification data < (certificates and revocation lists) to support long term < signature verification;</para> --- > <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> 926,928c936,938 < <para><emphasis role="bold">XAdES-X</emphasis> add timestamps < on XAdES-C references to protect against eventual future < certificates compromise;</para> --- > <para><emphasis role="bold">XAdES-X</emphasis>, which adds > timestamps to XAdES-C references to protect against eventual > compromise of future certificates;</para> 931,933c941,943 < <para><emphasis role="bold">XAdES-X-L</emphasis>, like XADES-X < but adding real certificates and revocation lists instead of < just references; and</para> --- > <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> 936,940c946,950 < <para><emphasis role="bold">XAdES-A</emphasis> to add < (periodically, as required) timestamps for very long-time < storage to extend the validity period, considering also < possible weakening of the algorithms used to sign the < document and related certificates in the storage --- > <para><emphasis role="bold">XAdES-A</emphasis>, which adds > timestamps (periodically, as required) to extend the > validity period for very long-time storage, taking into > account a possible weakening of the algorithms used to sign > the document and related certificates during the storage 945,948c955,958 < <para>It is out of the scope of this specification to indicate the < suitability of any specific XAdES form for a UBL document as < this is a matter of specific context of use, agreement between < parties and local regulations.</para> --- > <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> 954c964,965 < <para>This document specifies two profiles:</para> --- > <para>This document specifies two profiles for use in digitally > signing UBL documents:</para> 959,960c970,971 < Profile</emphasis> One or more signatures are added to the < UBL document inside a single, identifiable and dedicated UBL --- > Profile:</emphasis> One or more signatures are added to the > UBL document inside a single identifiable and dedicated UBL 962,966c973,977 < have a different identifier so they can be distinguished by < the one that contains the document signature(s). This < profile is defined such as the UBL content processing can be < separated from electronic signature processing, both in the < issuing side and in the receiving side, and specialized --- > 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 968c979 < application doesn't need to be electronic signature aware --- > application doesn't need to be electronic signature aware, 971c982 < business objects in the UBL document may reference a --- > business object in the UBL document may reference a 976c987 < Profile</emphasis> The signature is outside the UBL --- > Profile:</emphasis> The signature is outside the UBL 982,984c993,995 < modification to the UBL document and is applicable by < compatible implementations with other signature methods not < explicitly referenced by this profile.</para> --- > modification to the UBL document and is compatible with > other signature methods not explicitly referenced by this > profile.</para> 992c1003 < specific signature profile can be divided in the following --- > specific signature profile can be divided into the following 997c1008 < <para><emphasis role="bold">Legal requirements</emphasis> In --- > <para><emphasis role="bold">Legal requirements.</emphasis> In 1001,1010c1012,1020 < digital signature on the key document exchanged, e.g. on < orders. Another important legal requirement is on the < long-term document preservation, for a storage period that < in general is specific in any country and can span many < years: there is a requirement to guarantee the integrity and < authenticity of all fiscally relevant document archived and < this requirement can be met with digital signatures when < proper XAdES forms are used. This requirement is addressed, < for example, by <xref linkend="b_cwa15580"/> for electronic < invoices.</para> --- > 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> 1013c1023 < <para><emphasis role="bold">Business requirements</emphasis> A --- > <para><emphasis role="bold">Business requirements.</emphasis> A 1015c1025 < business transaction (e.g. non-repudiation of a commercial --- > business transaction (e.g., non-repudiation of a commercial 1022c1032 < <para><emphasis role="bold">Process requirements</emphasis>The --- > <para><emphasis role="bold">Process requirements.</emphasis>The 1025c1035 < the signed document remains a valid UBL document the --- > the signed document remains a valid UBL document, the 1040,1045c1050,1056 < 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.</para> --- > 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> 1051c1062 < <para>Both profiles support co-signatures, i.e. a UBL document can --- > <para>Both profiles support co-signatures, i.e., a UBL document can 1053,1057c1064,1069 < 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> --- > 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> 1063c1075 < signature(s) are embedded in the UBL document (that syntactically --- > signature(s) are embedded in the UBL document (which syntactically 1138c1150 < contain the signature information, and IETF/W3C-specified --- > contain the signature information and IETF/W3C-specified 1187,1189c1199,1201 < <para>Creators of other extensions should review the UBL < specification documentation for guidelines regarding < following this schema design pattern.</para> --- > <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> 1204c1216 < can be any value, but for convenience the URI of a URN --- > can be any value, but for convenience a URI consisting of a URN 1220c1232 < can be any value, but for convenience the URI of a URN --- > can be any value, but for convenience a URI consisting of a URN 1290,1301c1302,1315 < <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 countersigning document signature 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> --- > <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> 1304,1311c1318,1327 < <note> < <para>The XAdES specification supports an alternative < countersignature approach where a < <literal><ds:Signature></literal> element pointing to < the countersigned <literal><ds:SignatureValue></literal> < is embedded in the <literal><ds:Object></literal> of the < countersigning 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> 1316c1332,1333 < <title>Digital Signature Transformation</title> --- > <title>Digital Signature Transformation (Enveloped > Signatures)</title> 1319,1321c1336,1338 < <literal>URI=</literal> attribute of < <literal><ds:Reference></literal>. Using the empty string < indicates that the entire document (i.e. the enveloping UBL --- > <literal>URI=</literal> attribute of > <literal><ds:Reference></literal>. Using the empty string > indicates that the entire document (i.e., the enveloping UBL 1339,1342c1356,1359 < will invalidate all signatures already in the extension. The < choice to make is in regard to the support of adding < additional signatures after adding the signature with the < transformation expression.</para> --- > will invalidate all signatures already in the extension in > either case; the choice to be made is in regard to support for > adding additional signatures after adding the signature with > the transformation expression.</para> 1376c1393 < <para>Multiple separate items of extra-document content (e.g. --- > <para>Multiple separate items of extra-document content (e.g., 1378,1380c1395,1397 < included in the same signature by having sibling < <literal><ds:Reference></literal> elements with other < <literal>URI=</literal> attribute values. For example, to --- > included in the signature by adding sibling > <literal><ds:Reference></literal> elements with other > <literal>URI=</literal> attribute values. For example, to 1388c1405 < XPointer <xref linkend="b_xpointer"/> address for --- > <xref linkend="b_xpointer"/> address for 1394,1395d1410 < < 1403,1411c1418,1426 < <para>This profile supports one or more signatures to be applied < to a UBL document from outside of the document itself in some < other resource.</para> < < <para>It is important to note that there are no obligations < imposed on a UBL document to be externally signed with a < detached signature. Such a signature, in any kind of signature < container, can digitally sign the content of a UBL document with < or without reflecting such in the document itself.</para> --- > <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> 1416,1420c1431,1434 < <literal>urn:oasis:names:specification:ubl:dsig:detached</literal> < is reserved to indicate the detached signature is as defined in < this profile, that being a IETF/W3C XML digital signature. The < URI < <literal>urn:oasis:names:specification:ubl:dsig:detached:xades</literal> --- > <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> 1429c1443 < a <literal><cac:DigitalSignatureAttachmen></literal> --- > a <literal><cac:DigitalSignatureAttachment></literal> 1432c1446 < <para>A complete example of the --- > <para>A complete example of a 1456,1469c1470,1491 < <literal><ds:Reference></literal> element pointing to the < UBL document, all such signatures are signing the content of < the document but not each other. A countersigning document < signature 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> < 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. That pointer is to an external < file for a detached signature. That pointer is to the < <literal>Id=</literal> attribute of the target < element.</para> --- > <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> 1479c1501,1502 < signature.</para> --- > signature. The inclusion of an alternative method in this > specification does not prohibit this approach.</para> 1483c1506 < <title>Digital Signature Transformation</title> --- > <title>Digital Signature Transformation (Detached Signatures)</title> 1518,1523c1541,1555 < <para>Because of the UBL extension scaffolding being added for a < signature and for non-signature extensions, it is not possible < to protect from invalidation a detached signature for a UBL < document that does not already have an enveloped signature. In < this case of having no preexisting enveloped signature, the < entire document must be signed in the detached --- > <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 1526d1557 < 1528c1559 < XPointer <xref linkend="b_xpointer"/> address SHOULD be used --- > <xref linkend="b_xpointer"/> address SHOULD be used 1533d1563 < 1578,1585c1608,1610 < this specification requires:</para> < <itemizedlist> < <listitem> < <para>the conformant processing of all contained < <literal><ds:Signature></literal> elements per <xref < linkend="b_xmldsig"/>.</para> < </listitem> < </itemizedlist> --- > this specification requires the conformant processing of all > contained <literal><ds:Signature></literal> elements per <xref > linkend="b_xmldsig"/>.</para> 1588,1599c1613,1620 < specification requires:</para> < <itemizedlist> < <listitem> < <para>the <literal><cbc:SignatureMethod></literal> element, < when present, of each 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> < </listitem> < </itemizedlist> --- > 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> 1602c1623 < <title>XAdES conformance</title> --- > <title>XAdES Conformance</title> 1605,1611c1626,1628 < specification requires:</para> < <itemizedlist> < <listitem> < <para>the valid expression and processing of the XAdES syntax < found in an XMLDSig per <xref linkend="b_XAdES"/></para> < </listitem> < </itemizedlist> --- > specification requires the valid expression and processing of > the XAdES syntax found in an XMLDSig per <xref > linkend="b_XAdES"/>.</para> 1619c1636 < <para>The following individuals have participated in the creation of --- > <para>The following OASIS members have participated in the creation of 1621d1637 < <para>Participants: </para>
<?xml version="1.0" encoding="UTF-8"?>
<?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 10">
<!ENTITY stage "cd10">
<!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 "20 March 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 above
guidance.</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 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, certification data, and certification
archives.</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"/>.</para>
<!--
<note>
<title><emphasis>Temporary note (not for final
publication)</emphasis></title>
<para><emphasis>The above reference to the UN/CEFACT
recommendation may be removed if the recommendation has not
been adopted by the time this specification is
finalized.</emphasis></para>
</note>
-->
<section id="TERMINOLOGY">
<title>Terminology</title>
<section id="DEFS">
<title>Terms and Definitions</title>
<variablelist>
<varlistentry>
<term>
<emphasis role="bold">Digital Signature</emphasis>
</term>
<listitem>
<para>Formally speaking, 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. (This specification sometimes also uses
the term signature generically in a way that encompasses
Authentication Code values as well, but care has been
taken to make the distinction clear when signer
authentication is relevant.) A signature may be
(non-exclusively) described as detached, enveloping, or
enveloped <xref linkend="b_xmldsig"/>.</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 Signature <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</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 903
V1.4.1</ulink>
</citetitle> 2009-06 </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 of
the Council of 13 December 1999 on a Community framework
for electronic signatures </ulink>
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31999L0093:en:HTML
</citetitle>
</bibliomixed>
<bibliomixed id="b_asig">
<abbrev>ASIG</abbrev><citetitle>
<ulink
url="http://webapp.etsi.org/WorkProgram/Report_WorkItem.asp?WKI_ID=31946";
>Electronic Signatures and Infrastructure; Associated
Advanced Electronic Signatures</ulink>
</citetitle> ETSI work in progress </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";
>E-invoices and digital signatures</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";
>Storage of Electronic Documents</ulink>
</citetitle>
</bibliomixed>
<bibliomixed id="b_odfp">
<abbrev>ODFP</abbrev><citetitle>
<ulink url="http://docs.oasis-open.org/ubl/os-UBL-2.0";>OASIS
Standard, Open Document Format for Office Applications
(<?nospell-start?>OpenDocument<?nospell-end?>) Version 1.2
- Part 3 Packages, </ulink>
</citetitle> December 2006 </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)
</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</ulink></citetitle>
2001-03-15</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 Interoperability
Recommendation</ulink></citetitle> 2010-09-27</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</ulink></citetitle>
2007-01-23</bibliomixed>
<bibliomixed id="b_xpointer"
><abbrev>XPointer</abbrev><?nospell-start?>Steven DeRose, et
al <?nospell-end?><citetitle><ulink
url="http://www.w3.org/TR/xptr/";>XML Pointer Language
(XPointer) Version 1.0 Working Draft</ulink></citetitle>
2002-08-16</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</ulink></citetitle>
2007-01-23</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>
<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>
</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 extend one of these two basic forms and can
be built by the signature generator or the signature verifier.
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 eventual
compromise of future 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 very long-time 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 its signature(s).
Work is in progress in ETSI on Associated Signatures <xref
linkend="b_asig"/> to specify standard containers for
associating a document with related detached advanced electronic
signature(s) 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: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>
]]></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: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>
]]></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; the choice to be made is in regard to support for
adding additional signatures after adding the signature with
the transformation expression.</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: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>
]]></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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]