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