Re: UBL Profile for XML Digital Signatures and XAdES implementation

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

(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