Comment from David Burdett re adding digital signature support toUBL documents

[Anne Hendry <anne.hendry@sun.com>]

As discussed in this morning's meeting,
here is the comment from David on the need for digital signatures,
as well as some of the discussion around it in the LCSC F2F and
final LCSC disposition.  FYI, there was quite a bit of discussion,
so the LCSCs final disposition is based on a fair amount of consideration.

-Anne

Comment:
UBL documents cannot be digitally signed directly.

Proposed Solution:
David:
Add an optional XML Dsig element to the root of each document and 
guidelines on how it should be used.  Often the authenticity of a UBL 
document will need to be determined using cryptographic techniques. One 
way of doing this is to sign the document together with the envelope in 
which it is contained as, for example, ebXML Messaging provides [1].  
However, this means that you HAVE to keep the message around in order to 
later prove authenticity when the message is being processed. This adds 
to complexity and only works if messaging protocols such as ebXML 
Messaging are being used.
A better alternative is to include an XML DSig digital signature [2] 
element as an *optional* element at the root level of every UBL 
document. I would also recommend that a guideline is provided that 
describes how XML digital signatures should be used inside a UBL 
document in order to improve interoperability.
[1] ebXML Messaging specifications, 
http://www.oasis-open.org/committees/ebxml-msg/#documents
[2] W3C XML Digital Signature Specification, 
http://www.w3.org/TR/xmldsig-core/ 

QA Team recognized importance of this area. Security was out of scope 
for 0p70, but will be taken up at F2F.  Asked for input from Eve Maler.

Response from Eve Maler:
I agree with David's comment.  If you rely on digital signing only at 
the message envelope layer, then the payload becomes dependent on having 
the message layer around when the latter would otherwise have been 
discarded.
An example of including the relevant XML Signature elements can be found 
in the SAML specification:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
See in particular the "core" specification and the schema modules:
http://www.oasis-open.org/committees/download.php/1371/oasis-sstc-saml-core-1.0.pdf
http://www.oasis-open.org/committees/download.php/1376/oasis-sstc-saml-schema-assertion-1.0.xsd
http://www.oasis-open.org/committees/download.php/1377/oasis-sstc-saml-schema-protocol-1.0.xsd

...though note that the SAML group is in the process of further 
tightening and expanding its usage of XML Signature. One thing we 
learned is that it's immensely useful to put ID attributes on the 
elements that are likely signing targets, as it's too expensive to use a 
more complicated XPath to refer to these elements.

Response from Arofan Gregory:
I hate to bring this up again, but this is exactly the kinf of issue 
being addressed by the UN/CEFACT "Generic Header" project. (Need to 
preserve envelope information when document itself is processed.) Is 
there any alignment between various groups worth pursuing here?

Response from Mark Crawford:
I agree.  Rather than look to expand our scope of work, let's defer the 
appliation/transMissionstuff to ATG an ebXML TRP .

LCSC F2F Disposition:
Simpler and easier if signature is stored in document (as last 
element).  Script will just generate and append.  Also document usage as 
part of user guide for UBL.  Contains: reference to things you're 
signing, transformation and cannonicalisation rules to convert even 
mangled things to equivalents, digital cryptography rules.  Put in document:
<order>
  <dsig:signature>
     User Guide
  </dsig:signature>
</order>
Need xml schema rules for this from NDR.  Need white paper / 
requirements statement from NDR.  AI for NDR.

Additional info:
I also recall that there was discussion on the idea of keeping the 
header around,
but that it was decided that this was not a good solution, added complexity,
increased dependencies, not as dependable/provable, etc.

I think this should be enough info for NDR to discuss,
but if you want more then you'll need to continue the email thread with 
David.

-Anne