[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: UBL Profile for XML Digital Signatures and XAdES implementation
(posted to the TC list as I do not have posting privileges to the Security SC list; I was invited to comment specifically on this posting and resulting thread: http://lists.oasis-open.org/archives/ubl-security/200911/msg00002.html ) At 2009-11-24 10:23 +0100, Julián Inza wrote: >Here is the last iteration of the document. Please forgive my tardy response to this posting, but I have just completed over a month full of teaching in Europe, US and Asia. I finally have had time to look over the details and post before I head home from Delhi, India. First let me say that I do not have a background in digital signatures, and I've approached this document as an implementer wanting to learn how digital signatures are to be used with UBL. I hope my comments are considered helpful, but be prepared that they may be naïve of security issues and that other readers of the document may be similarly naïve and would need guidance. I was asked specifically to comment on the referencing, and so will focus some points there. I also note some editorial issues that the editors of the document will likely need to address to make the document acceptable to the OASIS management. I first respond to some comments made in the email thread and then offer my comments on the document. In all, it looks remarkably straightforward. I thought it would be more complicated than what I see. >In yellow is marked what I think needs further discussion. Thank you for highlighting that which needs focus as doing so helps to save time. I see in the thread that Roberto and Andrea have both contributed to the discussion, so I will try to bring their comments into my proposal. >Originally the reference to the element ><ds:Signature> in <cac:Signature> was done >through >cac:DigitalSignatureAttachment/cac:ExternalReference/cbc:URI >using Id (unique identifier) from <ds:Signature>. > >Now there are two references >- cac:Signature/cbc:ID using Id (unique >identifier) from <ds:Signature>. >- >cac:DigitalSignatureAttachment/cac:ExternalReference/cbc:URI >using a #xpointer to ds:Signature Periodically, discussions are held over the benefits of XPointer and whether or not it is useful. Technically it seems to be well received, but very few projects use it, and I'm told that some who do use it are using it improperly. There is not a lot of vendor support for it. >I think this adds complexity and I don´t understand why could be useful. I feel that XPointer is not consistent with the ways in which identifiers are specified in UBL and that any signature solution should try to be consistent. It would not serve our users well to have different ways of making references. Currently no attributes are being used for identifiers. ID and IDREF are not employed in UBL. All information is in elements that are or are candidates to become core components, and attributes are only used as supplementary components to elements. Therefore, I think we need to eschew any use of attributes for referencing and find ways of making references by using elements and associating identifiers. Thankfully, I see in the XML Signature core specification that all id= attributes within <ds:Signature> are optional, so we are not obliged to use an attribute. So where we need one we should probably wrap <ds:Signature> in an aggregate in order to associate a cbc:ID sibling of ds:Signature to be consistent with UBL design practices (but not, of course, if their absence violates some of the rules of XML signatures). Also, by creating our own wrapper, if in the future we have to add more than just an identifier we now have a place to do so (if ds:* were the top-level element, we wouldn't). Similarly, while XPath is an ideal language for addressing components of XML documents, and while it is used in cac:DocumentReference/cbc:XPath to point into referenced documents, we haven't yet employed it to associate components of UBL documents with each other. Moreover, I think though the precedent has been set to embed XPath information in an XML document, from an implementation perspective this may be awkward. Some transformation technologies (notably XQuery and XSLT) are unable to evaluate XPath addresses at run time and can only work with XPath addresses at compile time. This may be sufficient reason not to use them. At 2009-11-27 22:13 +0100, Andrea Caccia wrote: >About identification of the signature: >ds:Signature has an ID so it must be unique in >the XML document; if I'm not >wrong, cac:Signature/cbc:ID is mandatory when >cac:Signature is present. Taking this into >account, if we put in cbc:ID the ID associated >with ds:Signature the link is unique and >unambiguous, so we can avoid to have >cac:DigitalSignatureAttachment/cac:ExternalReference/cbc:URI >with the #xpointer as it is redundant and, I >agree with you, does not add any additional information. Good ... I agree with anything that will take away the XPointer value. Unfortunately, though, we cannot follow through with your suggestion to utilize the cac:Signature/cbc:ID value as the ds:Signature/@id value as they have different lexical constraints. It is easily possible to have a cbc:ID value that violates the constraints of xsd:ID. Thus, we are back to my suggestion that we need to wrap ds:Signature with an aggregate in order to associate a cbc:ID with ds:Signature. The top-level element for a user extension under the UBL extension point cannot be in any of the UBL namespaces according to current practice. But we are creating this as a *standardized* UBL extension and not as an ad-hoc user extension. Thus, contrary to what one might consider, we could utilize the already-standardized aggregate namespace for this new aggregate. This would require some ratification by the TC as it would be the first time we've added an item to the common library for use in an extension that isn't being used in the body of UBL documents. Furthermore, since the common library has already been published, is it improper to have yet more elements added to the namespace? I suspect this last issue is not a problem since UBL 2.1 will be using the namespace for other new aggregates being added to the common library. But an argument not to use the common library namespace is that this signature method will *always* be under the UBL extension point and will not be "moved" into the document tree as part of UBL 2.1 or future releases of UBL. And it is our committee's first example of a standardized extension. Users creating their own ad-hoc extensions would see what we've done in using a non-CAC namespace for our own work. I invite debate on the above. In that debate I think I would side with the UBL committee creating a new non-CAC namespace as the namespace of the top-level element under the extension point for a UBL-Security extension. >About SignatoryParty I think the important >information is to identify what is the party >that is signing: the seller, the buyer or a >third party. This is specially important if the >signed document is an invoice. I'm not an UBL >expert but as SignatoryParty it's better to have >an identifier that is meaningful from the business point of view: We are unable to change the definition of SignatoryParty. I believe that throughout UBL it is not uncommon to have the same physical party details listed under different logical party elements. But it is not possible that I know of to use references from one logical party to another logical party to indicate the two parties are the same physical party. >in this sense we can also avoid to use the >Subject DN (it is likely that it is a parameter >you get from the signature verification process as part of the result). In my example below I've indicated how it might be specified if it is needed. >So my idea is to let the implementor the freedom >to insert here what could be relevant as >identification of the signing entity at the business/legal processing level. >I propose to use the optional cbc:Note field >available inside cac:Signature to bring the >mandatory note you have to mention if the >invoice is not signed by the seller (i.e. >"issued on behalf of the seller" or whatever the >regulation of the seller country mandates). I think this is entirely appropriate and see no problems, though we could only propose that as a guideline as I don't think we could mandate the wording of the content. So, looking at the "UBL [XAdES] Profile Version 1.0 3 September 2009" document, I offer the following technical and editorial comments. Again, please forgive any naïveté regarding the digital signature specification. I'm using the definitions for extension metadata embedded as annotation elements in: http://docs.oasis-open.org/ubl/os-UBL-2.0-update/xsd/common/UBL-CommonExtensionComponents-2.0.xsd Technical comments: Here is an example of how I might embed the signature information. Those items with #PCDATA surrounded by asterisks would be simple user input and not standardized or suggested content. Looking at each definition, I interpret those I've marked with asterisks as up to the writer of the UBL document to define, and the others as up to the UBL committee to define ... though I may be mistaken about this given they aren't distinguished in their name. In fact I'm now questioning my assumption because I suppose all of the items could be oriented to the *user* of the extension rather than to the *standardizer* of the extension. I welcome input on this, especially from Stephen Green who helped come up with the extension metadata. <ext:UBLExtension> <cbc:ID>*DemoSig*</cbc:ID> <cbc:Name>*Demonstration of signature*</cbc:Name> <ext:ExtensionAgencyID>UBL</ext:ExtensionAgencyID> <ext:ExtensionAgencyName>OASIS Universal Business Language</ext:ExtensionAgencyName> <ext:ExtensionVersionID>0.1</ext:ExtensionVersionID> <ext:ExtensionAgencyURI>http://www.oasis-open.org</ext:ExtensionAgencyURI> <ext:ExtensionURI>urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2</ext:ExtensionURI> <ext:ExtensionReasonCode listURI="*urn:x-Demo:Demo:ReasonCodes*">*1*</ext:ExtensionReasonCode> <ext:ExtensionReason>*Security*</ext:ExtensionReason> <ext:ExtensionContent> <sig:Signature xmlns:sig="urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2"> <cbc:ID>*AnySignatureID*</cbc:ID> <ds:Signature Id="AnySignatureID" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xades="http://uri.etsi.org/01903/v1.4.1#"> [...] </ds:Signature> </sig:Signature> </ext:ExtensionContent> </ext:UBLExtension> Note that I am consciously reusing the common basic component identifier rather than coming up with a new element (extensions should re-use components where already defined). I think the URI syntax we use should be consistent with other UBL URI strings (and my use of "-cd01" is consistent with an editorial comment below): <cac:Signature> <cbc:ID>*AnySignatureID*</cbc:ID> <cbc:Note>*issued on behalf of the seller*</cbc:Note> <cbc:SignatureMethod>urn:oasis:names:specification:ubl:method:dsigp-1.0-cd01</cbc:SignatureMethod> <cac:SignatoryParty> <cac:PartyIdentification> <cbc:ID schemeURI="<http://www.ietf.org/rfc/rfc4514.txt>http://www.ietf.org/rfc/rfc4514.txt">*Subject Distinguished Name*</cbc:ID> </cac:PartyIdentification> </cac:SignatoryParty> </cac:Signature> Note that I'm assuming the string "X509SubjectName" in the document wasn't an international standard and was merely a proposed string by the SC. Editorial comments: - "Editosr" -> "Editors" - in the "This version" section, one of the files must be marked as the authoritative copy - in the "This version" section, the URI strings should probably be: ..../securitysc/dsigp-1.0/dsigp-1.0-cd01.* - the "Latest version" must be a set of generic URI strings without versions: ..../securitysc/dsigp-1.0/dsigp-1.0.* ... and OASIS management will create the necessary links from the "Latest version" URIs to the "This version" URIs - the "Declared XML Namespace(s)" section is only for those namespaces created by this specification ... thus there would only be one (which I do not see in the list yet) which is the one we standardize for the UBL Extension namespace - the "Contributors" section is usually an annex titled "Acknowledgements (Non-Normative" and not included at the front of the document - under "Notices" the copyright year should be "2009" (or I suppose "2010" if we think it won't be done in the next month) - "3 Object" -> "3 Objectives" - I think attention should be paid to each major section to indicate if the section is normative or non-normative relative to the definition of the specification; for example, section one is normative as it is describing that which is being specified. But section two, while helpful information that should be included, I believe is non-normative (and should be marked as such) because the specification wouldn't change if you removed the section; it is supportive descriptive material but not support prescriptive material. The objectives are normative. Section 4 is, of course, normative. As is conformance. So my opinion is that section 2 and the annexes are the ones to be marked as "non-normative" - should section 4.1 become section 3.1 so that the fall under objectives of digital signatures in UBL? They are still normative, but they look out of place in section 4 and I think are more appropriate as a section 3.1 (or 3.2 if the current 3 becomes 3.1) ... that would leave section 4 purely for the specification details - I think sentences like "This guarantee that the signed document remains conformant to the UBL syntax." would be moved to a non-normative section - section 4.4 should be moved to be the conformance section ... those certainly read as if they were conformance clauses - I think conformance clauses should be numbered for easy distinction and identification I hope this input helps. I am sorry that it took so long for me to review this, but I wanted to write a considered response and not just a quickie. None of the above is cast in stone ... merely my input to your deliberations. Good luck finalizing the details! Do not hesitate to ask me any questions or to ask others on the committee if I've messed up in my suggestions. . . . . . . . . . . . . Ken -- Vote for your XML training: http://www.CraneSoftwrights.com/o/i/ Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18 Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18 G. Ken Holman mailto:gkholman@CraneSoftwrights.com Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/o/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]